Re: [PATCH] fortran, libgfortran, v3: Avoid using libquadmath for glibc 2.26+

2022-06-28 Thread Jakub Jelinek via Fortran
On Mon, Jun 27, 2022 at 03:30:49PM +0200, Jakub Jelinek via Gcc-patches wrote: > Ok, here is an updated patch that uses _Float128/_Complex _Float128 for all > of GFC_REAL_{16,17}_IS_FLOAT128, but still uses q/Q suffixes on literal > constants etc. when using libquadmath and f128/F128 otherwise. > T

Re: [PATCH] fortran, libgfortran, v3: Avoid using libquadmath for glibc 2.26+

2022-06-28 Thread Tobias Burnus
On 27.06.22 15:30, Jakub Jelinek via Gcc-patches wrote: Ok, here is an updated patch that uses _Float128/_Complex _Float128 for all of GFC_REAL_{16,17}_IS_FLOAT128, but still uses q/Q suffixes on literal constants etc. when using libquadmath and f128/F128 otherwise. This patch also includes the

Re: [PATCH] fortran, libgfortran, v3: Avoid using libquadmath for glibc 2.26+

2022-06-28 Thread Jakub Jelinek via Fortran
On Tue, Jun 28, 2022 at 10:35:03AM +0200, Tobias Burnus wrote: > On 27.06.22 15:30, Jakub Jelinek via Gcc-patches wrote: > > > Ok, here is an updated patch that uses _Float128/_Complex _Float128 for all > > of GFC_REAL_{16,17}_IS_FLOAT128, but still uses q/Q suffixes on literal > > constants etc.

[PATCH] Fortran: improve error recovery for EXTENDS_TYPE_OF() [PR106121]

2022-06-28 Thread Harald Anlauf via Fortran
Dear all, the simplification of EXTENDS_TYPE_OF() did not handle the situation that one of its arguments were a CLASS variable that was improperly declared. NULL pointer dereference. The fix is obvious. Steve found a similar solution, which is why I added him as co-author. Regtested on x86_64-