summaryrefslogtreecommitdiffstats
path: root/llvm/lib/MC/ELFObjectWriter.cpp
diff options
context:
space:
mode:
authorRichard Smith <richard-llvm@metafoo.co.uk>2011-12-09 02:04:48 +0000
committerRichard Smith <richard-llvm@metafoo.co.uk>2011-12-09 02:04:48 +0000
commit10c7c9090e167a2acb327a068cd3a7509b58bd51 (patch)
treef744a82af27bd325bcd6a2955819680647818147 /llvm/lib/MC/ELFObjectWriter.cpp
parent7033127b4e5f430736f32a1e861e2b320f4cf773 (diff)
downloadbcm5719-llvm-10c7c9090e167a2acb327a068cd3a7509b58bd51.tar.gz
bcm5719-llvm-10c7c9090e167a2acb327a068cd3a7509b58bd51.zip
Replace the implementation of __builtin_constant_p (which was based on the GCC
documentation) with one based on what GCC's __builtin_constant_p is actually intended to do (discovered by asking a friendly GCC developer). In particular, an expression which folds to a pointer is now only considered to be a "constant" by this builtin if it refers to the first character in a string literal. This fixes a rather subtle wrong-code issue when building with glibc. Given: const char cs[4] = "abcd"; int f(const char *p) { return strncmp(p, cs, 4); } ... the macro magic for strncmp produces a (potentially crashing) call to strlen(cs), because it expands to an expression starting with: __builtin_constant_p(cs) && strlen(cs) < 4 ? /* ... */ Under the secret true meaning of __builtin_constant_p, this is guaranteed to be safe! llvm-svn: 146236
Diffstat (limited to 'llvm/lib/MC/ELFObjectWriter.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud