ro added a comment.
In D64482#1579850 <https://reviews.llvm.org/D64482#1579850>, @MaskRay wrote:
>
> Honestly I find such enforced C/C++ difference very unfortunate... e.g.
>
> if (Opts.CPlusPlus)
> Builder.defineMacro("_GNU_SOURCE");
You may not like them, but there are plenty of examples in `OSTargets.h` (for
kFreeBSD, Hurd, Linux, RTEMS, AIX, Windows, NaCl and
several more). Why take offense in the Solaris case if this is already common
practice?
> Solaris seems the only exception that defines these Large File Support
> extension macros on the compiler driver side. Isn't it possible to do it in a
> common system header file?
Even if it were, this would only affect future releases. The user experience
of "you need to upgrade to Solaris 11.x" or install update y
to get this" seems pretty dismal to me. Besides, that ship has sailed and GCC
9 is released.
Apart from that, I strongly suspect that there are other reasons. Large file
support is only relevant for 32-bit targets. However, many
OSes have switched to 64-bit only by now. And testing non-default multilibs
just doesn't happen in LLVM: I haven't found a way to do
so yet, while it's quite easy to run all gcc testsuites for a common set of
multilibs. Even building LLVM for Linux/i686 or Solaris/i386
proved to be highly problematic and not (regularly) tested.
> That rationale will be better than this paragraph in the description:
>
>> make check-all currently fails on x86_64-pc-solaris2.11 when building with
>> GCC 9:
>
> With the current description, a casual reader (like I) would just think this
> patch is probably not doing things at the correct layer.
That description only served to show what problem as hand is being solved, not
just an abstract desire for g++ compatibiliy.
Repository:
rC Clang
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D64482/new/
https://reviews.llvm.org/D64482
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
