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 cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits