This matches other C++ drivers e.g. Linux that define
_GNU_SOURCE. This lets clang compiler more code by default
without explicitly passing _GNU_SOURCE on command line.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Basic/Targets/ARM.cpp | ||
---|---|---|
710–711 | I think this should apply to both C and C++ |
Is this an upstream GCC behavior or a behavior from some gcc-none-eabi distributions?
GCC's C++ mode defines _GNU_SOURCE historically due to a libstdc++ limitation https://gcc.gnu.org/onlinedocs/libstdc++/faq.html#faq.predefined and nowadays "the ship has sailed" and many targets do the same for compatibility.
For C, most targets don't force defining _GNU_SOURCE.
@tomhughes has more details on this but if we do not define it in clang itself, we'll need to define it for every package manually at build time since the usage goes deep inside newlib headers.
I remember facing a similar issue while I was trying to build a baremetal llvm toolchain for riscv. I think I defined it in libcxx config for newlib.
More context: https://issuetracker.google.com/254916723
I take back my earlier comment about it applying for both C and C++. Checking locally I see the behavior @MaskRay describes:
_GNU_SOURCE not defined:
gcc -E -dD -o empty empty.c
_GNU_SOURCE defined:
g++ -E -dD -o empty empty.c
I'm just looking for compatibility with gcc/g++ behavior.
The _GNU_SOURCE definition needs to be guarded by if (Opts.CPlusPlus).
clang/test/Driver/arm-baremetal-defines.cpp | ||
---|---|---|
1 ↗ | (On Diff #470611) | Move this to test/Preprocessor/init-arm.c |
clang/test/Driver/arm-baremetal-defines.cpp | ||
---|---|---|
1 ↗ | (On Diff #470611) | test/Preprocessor/init-* tests use %clang_cc1 -triple xxx -E -dM %s |
I think this should apply to both C and C++