ro added a comment. In D133405#3779190 <https://reviews.llvm.org/D133405#3779190>, @MaskRay wrote:
> So, sparc64 gcc does seem to define the macro by default. (I am using Debian > testing and can't tell whether it's distro setting or upstream default) > ¯\_(ツ)_/¯ > > % sparc64-linux-gnu-gcc -E -dM -xc /dev/null -nostdinc | grep NO_INLINE > #define __NO_INLINE__ 1 True, as does `clang`. However, both define it only at `-O0`. This is common upstream behaviour in both cases. The following reduced testcase demonstrates the issue: $ cat vfprintf-ldbl.c struct _IO_FILE; typedef struct _IO_FILE FILE; extern FILE *stdout; typedef __builtin_va_list __gnuc_va_list; extern int vfprintf (FILE *__restrict __s, const char *__restrict __format, __gnuc_va_list __arg); extern int __inline __attribute__ ((__gnu_inline__)) vprintf (const char *__restrict __fmt, __gnuc_va_list __arg) { return vfprintf (stdout, __fmt, __arg); } extern __typeof (vfprintf) vfprintf __asm ("" "_nldbl" "vfprintf"); makes `clang` choke $ clang -c vfprintf-ldbl.c vfprintf-ldbl.c:12:28: error: cannot apply asm label to function after its first use extern __typeof (vfprintf) vfprintf __asm ("" "_nldbl" "vfprintf"); ^ ~~ 1 error generated. while gcc compiles this without issues. > This needs a test in `clang/test/Preprocessor/init.c` (find `SPARC`) with a > comment linking to the canonical place to discuss the glibc problem > (@zatrazz). Done now and tested on `sparcv9-sun-solaris2.11`. Will also test on `sparc64-unknown-linux-gnu` once the currently running release build is finished (this box is **slow**). Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D133405/new/ https://reviews.llvm.org/D133405 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits