This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 26/31] Do not redirect calls to __GI_* symbols, when redirecting to *ieee128


Hi, Florian,

On Wed, 16 Oct 2019, Florian Weimer wrote:

>Why don't we see this problem with the existing dual ABIs for long
>double?

That would be because, on the previous transition (from long double being
the same as double to long double with some other, whatever format), the
old format was the same as double, which meant that no files had to be
compiled in the old mode (-mlong-double-64).  The [at-the-time-]new compat
symbols got created during the compilation of the double-typed functions,
which could be built with -mlong-double-128.

For the new ABI, we rely on a lot of builds with -mlong-double-128 and
-mfloat128, which work fine without this patch.  However, we need a couple
of builds in -mabi=ieeelongdouble mode, and the use of this flag causes
build errors such as these:

  In file included from ../sysdeps/ieee754/ldbl-128ibm-compat/ieee128-qefgcvt.c:20:
  ../include/stdio.h:174:1: error: asm declaration ignored due to conflict with previous rename [-Werror=pragmas]
    174 | libc_hidden_proto (dprintf)
        | ^~~~~~~~~~~~~~~~~
  ../include/stdio.h:178:1: error: asm declaration ignored due to conflict with previous rename [-Werror=pragmas]
    178 | libc_hidden_proto (fprintf)
        | ^~~~~~~~~~~~~~~~~
  ../include/stdio.h:179:1: error: asm declaration ignored due to conflict with previous rename [-Werror=pragmas]
    179 | libc_hidden_proto (vfprintf)
        | ^~~~~~~~~~~~~~~~~
  ../include/stdio.h:180:1: error: asm declaration ignored due to conflict with previous rename [-Werror=pragmas]
    180 | libc_hidden_proto (sprintf)
        | ^~~~~~~~~~~~~~~~~
  cc1: all warnings being treated as errors
  make[2]: *** [/home/gabriel/build/powerpc64le/glibc/sysd-rules:1663: /home/gabriel/build/powerpc64le/glibc/misc/ieee128-qefgcvt.os] Error 1
  make[2]: Leaving directory '/home/gabriel/src/glibc/misc'

When we started working on this effort, we went on a path that led to a
lot more files being built with -mabi=ieeelongdouble, now it's just cvt*
functions, really.  So I'm updating this patch to touch less files.

>> +#  if !defined __LONG_DOUBLE_USES_FLOAT128 \
>> +  || (defined __LONG_DOUBLE_USES_FLOAT128 && __LONG_DOUBLE_USES_FLOAT128 == 0)
>>  libc_hidden_proto (__snprintf)
>> +#  endif
>>  extern int __vfscanf (FILE *__restrict __s,
>>  		      const char *__restrict __format,
>>  		      __gnuc_va_list __arg)  
>
>This leads to a build failure on most architectures because
>__LONG_DOUBLE_USES_FLOAT128 is not defined at this point.
>
>(I tried the gabriel/powerpc-ieee128-printscan branch at commit
>1c4f7fffc4f1cc186906dd47812e725e51bb036a.)

I'm sorry.  It is perfectly reasonable that I should have tested it on
other platforms before sending this patchset.  I'm fixing this and testing
on more platforms using build-many-glibcs.py (using b-m-g sent me on a
search for *other* problems with the patchset, so thanks for testing the
branch, much appreciated :).

The actual snippet that causes the problem is the following:

>@@ -72,7 +75,8 @@ libc_hidden_proto (__isoc99_vfscanf)
>    Unfortunately, symbol redirection is not transitive, so the
>    __REDIRECT in the public header does not link up with the above
>    libc_hidden_proto.  Bridge the gap with a macro.  */
>-#  if !__GLIBC_USE (DEPRECATED_SCANF)
>+#  if !__GLIBC_USE (DEPRECATED_SCANF) \
>+      && __LONG_DOUBLE_USES_FLOAT128 == 0
> #   undef sscanf
> #   define sscanf __isoc99_sscanf
> #  endif

It's missing the check for __LONG_DOUBLE_USES_FLOAT128 being defined.  I
have locally changed this to a check for the macro being defined, then for
a value (which solves the problem according to b-m-g), but I'm wondering if
I should switch to defining it to 0 (zero) on all other long-double.h
files (for all platforms), thus avoiding the problems with undefined
macros [1].  Do you have an opinion on that?

I'll send a v2, soon.

[1] https://sourceware.org/glibc/wiki/Wundef


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]