Re: [PATCH] libgfortran: Fix -Wincompatible-pointer-types errors

[Florian Weimer]

* Richard Earnshaw:

> On 05/12/2023 10:51, Jakub Jelinek wrote:
>> On Tue, Dec 05, 2023 at 10:47:34AM +, Richard Earnshaw wrote:
 The following patch makes libgfortran build on i686-linux after hacking up
 --- kinds.h.xx 2023-12-05 00:23:00.133365064 +0100
 +++ kinds.h2023-12-05 11:19:24.409679808 +0100
 @@ -10,8 +10,8 @@ typedef GFC_INTEGER_2 GFC_LOGICAL_2;
#define HAVE_GFC_LOGICAL_2
#define HAVE_GFC_INTEGER_2
 -typedef int32_t GFC_INTEGER_4;
 -typedef uint32_t GFC_UINTEGER_4;
 +typedef long GFC_INTEGER_4;
 +typedef unsigned long GFC_UINTEGER_4;
>>>
>>> That doesn't look right for a 64-bit processor.  Presumably 4 means 4 bytes,
>> i686-linux is an ILP32 target, which I chose exactly because I
>> regularly build
>> it, had a tree with it around and because unlike 64-bit targets there are 2
>> standard 32-bit signed integer types.  Though, normally int32_t there is
>> int rather than long int and so the errors only appeared after this hack.
>> 
>
> My point is that on aarch64/x86_64 etc, this will make GFC_INTEGER_4 a
> 64-bit type, whereas previously it was 32-bit.

I think it's not part of the submission, it was for local testing only.
It confused me as well. 8-)

Thanks,
Florian

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Florian Weimer]

* Andreas Schwab:

> On Okt 09 2021, Thomas Koenig via Fortran wrote:
>
>> There is no choice - we need to make object code compiled by the user
>> incompatible between the old and the new format on the systems where
>> we make the switch.
>
> If you link, but not recompile, object files compiled against different
> versions of glibc, you are in for surprises, too.  This isn't something
> new.  There is no guarantee of API stability.

This is of course true, but we nevertheless try to accommodate
existing static linking patterns with glibc if possible.  Maybe those
are more common with Fortran?  Then more compatibility for static
linking could be pretty much required there.  (I don't know enough
about Fortran to judge that.)

Re: On pull request workflows for the GNU toolchain

[Florian Weimer]

* Jonathan Wakely:

> The discussion is about how we do patch submission and patch review.
> The GitHub pull request workflow is widely seen as simpler than our
> current email-based workflow (not everybody agrees, of course). The
> idea is to *lower* the barrier of entry for contributors, not raise
> it.

It should also help those who feel unsure about their use of Git because
the reviewers see exactly what ends up getting merged (at least with the
default workflow).  With the email-based workflow, that isn't the case,
and I know it makes some people feel nervous.

Thanks,
Florian

libquadmath, glibc, and the Q format flag

[Florian Weimer via Fortran]

I recently discovered that libquadmath registers custom printf callbacks
on load.  As far as I can tell, this is done so that the Q format flag
can be used to print floating point numbers, using format strings such
as "%Qf".  To enable Q flag processing, libquadmath has to register
replacements for all floating point format specifiers (aAeEfFgG).

Unfortunately, this has the side effect that even with out the Q flag,
printing any floating point number enters a generic, slow path in glibc,
prior to the number formatting itself.  The effect is quite pronounced.
For example this admittedly silly benchmarking script

for i=1,500 do
print(i, i * math.pi)
end

runs for 5.8 seconds without libquadmath.so.0 loaded on my x86-64
system.  With libquadmath.so.0 from GCC 12 loaded, it runs for 6.3
seconds.

This impacts most (all?) Fortran code on GNU/Linux because libgfortran
depends on libquadmath.

Would it make sense to transplant the implementation of the Q specifier
from libquadmath to glibc, and disable the registration code in
libquadmath if glibc is recent enough?  At least for the targets that
today have float128 support in glibc?

Thanks,
Florian

Re: libquadmath, glibc, and the Q format flag

[Florian Weimer via Fortran]

* Jakub Jelinek:

> On Wed, Feb 01, 2023 at 11:56:42AM +0100, Florian Weimer via Gcc wrote:
>> I recently discovered that libquadmath registers custom printf callbacks
>> on load.  As far as I can tell, this is done so that the Q format flag
>> can be used to print floating point numbers, using format strings such
>> as "%Qf".  To enable Q flag processing, libquadmath has to register
>> replacements for all floating point format specifiers (aAeEfFgG).
>> 
>> Unfortunately, this has the side effect that even with out the Q flag,
>> printing any floating point number enters a generic, slow path in glibc,
>> prior to the number formatting itself.  The effect is quite pronounced.
>> For example this admittedly silly benchmarking script
>> 
>> for i=1,500 do
>> print(i, i * math.pi)
>> end
>> 
>> runs for 5.8 seconds without libquadmath.so.0 loaded on my x86-64
>> system.  With libquadmath.so.0 from GCC 12 loaded, it runs for 6.3
>> seconds.
>> 
>> This impacts most (all?) Fortran code on GNU/Linux because libgfortran
>> depends on libquadmath.
>
> Not anymore.
> If GCC is configured against new enough glibc (with _Float128 support)
> libgfortran.so.5 is no longer linked against -lquadmath, and -lquadmath
> is added only --as-needed to ld command line, so if all the Fortran object
> files that need real(kind=16) (or quad complex) are built by such configured
> GCC, -lquadmath is not linked in (just needs to be present).

Hmm, I missed that recent change.

Would it make sense to drop the libgfortran RPM dependency on
libquadmath in Fedora rawhide?

> And, even for C, users can just use the standard glibc _Float128 support
> (if they don't mind strfromf128) if they target new enough glibc.
> So, libquadmath should be left over for non-glibc uses or uses with old
> glibc.
>
>> Would it make sense to transplant the implementation of the Q specifier
>> from libquadmath to glibc, and disable the registration code in
>> libquadmath if glibc is recent enough?  At least for the targets that
>> today have float128 support in glibc?
>
> Thus I'm not sure it is worth it.

Yeah, if most implicit libquadmath uses are history, then it's probably
not going to be needed (unless some standard suggests to use the Q
flag).

Thanks,
Florian

Re: libsanitizer: sync from master

[Florian Weimer via Fortran]

* Martin Liška:

> On 11/15/22 16:47, Martin Liška wrote:
>> Hi.
>> 
>> I've just pushed libsanitizer update that was tested on x86_64-linux and 
>> ppc64le-linux systems.
>> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
>> abidiff.
>
> Hello.
>
> And I've done the same now and merged upstream version 3185e47b5a8444e9fd.

So … we have the issue that involves interceptors outside of libc.so.6,
namely crypt, crypt_r, and I posted an upstream patch for this:

  sanitizers: Disable crypt, crypt_r interceptors for glibc
  

Can we just apply this downstream for now?  It blocks various folks from
using the sanitizers in their projects.

Thanks,
Florian

Re: libsanitizer: sync from master

[Florian Weimer via Fortran]

* Martin Liška:

> On 4/26/23 20:31, Florian Weimer wrote:
>> * Martin Liška:
>> 
>>> On 11/15/22 16:47, Martin Liška wrote:
>>>> Hi.
>>>>
>>>> I've just pushed libsanitizer update that was tested on x86_64-linux and 
>>>> ppc64le-linux systems.
>>>> Moreover, I run bootstrap on x86_64-linux and checked ABI difference with 
>>>> abidiff.
>>>
>>> Hello.
>>>
>>> And I've done the same now and merged upstream version 3185e47b5a8444e9fd.
>> 
>> So … we have the issue that involves interceptors outside of libc.so.6,
>> namely crypt, crypt_r, and I posted an upstream patch for this:
>> 
>>   sanitizers: Disable crypt, crypt_r interceptors for glibc
>>   <https://reviews.llvm.org/D144073>
>> 
>> Can we just apply this downstream for now?  It blocks various folks from
>> using the sanitizers in their projects.
>
> Hello.
>
> Your upstream revision has been already accepted, so please apply it
> and I'm going to do one more merge from upstream in the following
> days. Does it work for you?

It's moving in a different direction now: <https://reviews.llvm.org/D149403>

But that's okay for me as well.

Thanks,
Florian

Re: Work on the power-ieee128 branch has hit a snag...

[Florian Weimer via Fortran]

* Thomas Koenig via Gcc:

> ... in
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103476, a very
> strange error where an invalid Makefile is generated with
> --enable-maintainer-mode on POWER.
>
> I'm not sure how to proceed from here.  Maybe somebody
> with more make debug fu could take a look?

What's the whitespace situation?  Usually the error means that the
recipe is indented using spaces instead of tab.

It's spaces in Bugzilla, but that doesn't mean much.

Thanks,
Florian