[PATCH] D133405: [Linux] Hack around Linux/sparc <bits/stdio-ldbl.h>

[Rainer Orth via Phabricator via cfe-commits]

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