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

2021-10-09 Thread 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

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

2021-10-09 Thread Thomas Koenig via Fortran
On 09.10.21 01:18, Iain Sandoe wrote: I meant the case where the user writes, with an old, KIND=16 is double double compiler, subroutine foo(a) real(kind=16) :: a a = a + 1._16 end subroutine foo and puts it in a library or an old object file, and in new code with an IEEE QP compi

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

2021-10-09 Thread Jakub Jelinek via Fortran
On Sat, Oct 09, 2021 at 11:11:51AM +0200, Thomas Koenig wrote: > The question is still if we can avoid a new SONAME for >99% of our users > for no gain at all for them. Is there a possibility of aliasing the > SONAME somehow (grasping at straws here)? I'd hope Debian can just ln -sf libgfortran.s

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

2021-10-09 Thread Iain Sandoe
> On 9 Oct 2021, at 10:11, Thomas Koenig wrote: > > > On 09.10.21 01:18, Iain Sandoe wrote: >>> I meant the case where the user writes, with an old, KIND=16 is double >>> double compiler, >>> >>> subroutine foo(a) >>>real(kind=16) :: a >>>a = a + 1._16 >>> end subroutine foo >>> >

Re: [PATCH] PR fortran/65454 - accept both old and new-style relational operators

2021-10-09 Thread Harald Anlauf via Fortran
Hi Jerry, > Gesendet: Samstag, 09. Oktober 2021 um 00:28 Uhr > Looks all good Harald, OK and thanks for the support! Thanks for the quick review! Harald

*PING* [PATCH] PR fortran/99348, 102521 - ICEs when initializing DT parameter arrays from scalar

2021-10-09 Thread Harald Anlauf via Fortran
*Ping* Am 03.10.21 um 21:20 schrieb Harald Anlauf via Fortran: Dear Fortranners, when initializing parameter arrays from scalars, we did handle only the case init->expr_type == EXPR_CONSTANT, which misses the case of derived types. As a consequence the constructor for the r.h.s. was not set up

Re: [Patch] [v2] Fortran: Fix Bind(C) Array-Descriptor Conversion (Move to Front-End Code)

2021-10-09 Thread Tobias Burnus
Re-sent with gzipped attachment as gcc-patches@ did reject it as being too large. Alternatively, you can find it at https://gcc.gnu.org/pipermail/fortran/attachments/20211009/dc26f92d/attachment-0001.bin as fortran@ contrary to gcc-patches@ did accept the patch ... Tobias On 09.10.21 23:48

Re: *PING* [PATCH] PR fortran/99348, 102521 - ICEs when initializing DT parameter arrays from scalar

2021-10-09 Thread Jerry D via Fortran
This one looks OK.  Sorry I missed it earlier. Thanks again for the patch! Jerry On 10/9/21 12:27 PM, Harald Anlauf via Fortran wrote: *Ping* Am 03.10.21 um 21:20 schrieb Harald Anlauf via Fortran: Dear Fortranners, when initializing parameter arrays from scalars, we did handle only the case