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
