summaryrefslogtreecommitdiff
path: root/arch/mips
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2014-07-16 21:32:06 -0400
committerRich Felker <dalias@aerifal.cx>2014-07-16 21:32:06 -0400
commita6adb2bcd8145353943377d6119c1d7a4242bae1 (patch)
tree0ea88fa60243c6ac696917cbb4264da0f59b786b /arch/mips
parentc463e11eda8326aacee2ac1d516954a9574a2dcd (diff)
downloadmusl-a6adb2bcd8145353943377d6119c1d7a4242bae1.tar.gz
work around constant folding bug 61144 in gcc 4.9.0 and 4.9.1
previously we detected this bug in configure and issued advice for a workaround, but this turned out not to work. since then gcc 4.9.0 has appeared in several distributions, and now 4.9.1 has been released without a fix despite this being a wrong code generation bug which is supposed to be a release-blocker, per gcc policy. since the scope of the bug seems to affect only data objects (rather than functions) whose definitions are overridable, and there are only a very small number of these in musl, I am just changing them from const to volatile for the time being. simply removing the const would be sufficient to make gcc 4.9.1 work (the non-const case was inadvertently fixed as part of another change in gcc), and this would also be sufficient with 4.9.0 if we forced -O0 on the affected files or on the whole build. however it's cleaner to just remove all the broken compiler detection and use volatile, which will ensure that they are never constant-folded. the quality of a non-broken compiler's output should not be affected except for the fact that these objects are no longer const and thus possibly add a few bytes to data/bss. this change can be reconsidered and possibly reverted at some point in the future when the broken gcc versions are no longer relevant.
Diffstat (limited to 'arch/mips')
0 files changed, 0 insertions, 0 deletions