summaryrefslogtreecommitdiff
path: root/src/string/strrchr.c
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2014-07-16 21:32:06 -0400
committerRich Felker <dalias@aerifal.cx>2014-07-28 00:27:59 -0400
commit5ee811110444a615bbbf84a3daacccf734e4ef2c (patch)
treec1954a0456a797a290a4b4d0e12d02b2ba1767df /src/string/strrchr.c
parentcad5e1c8baf0d97d3b4195864c46fa68f0a1b0b6 (diff)
downloadmusl-5ee811110444a615bbbf84a3daacccf734e4ef2c.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. (cherry picked from commit a6adb2bcd8145353943377d6119c1d7a4242bae1)
Diffstat (limited to 'src/string/strrchr.c')
0 files changed, 0 insertions, 0 deletions