Re: libgfortran.so SONAME and powerpc64le-linux ABI changes (work in progress patches)

2021-10-28 Thread Michael Meissner via Fortran
Here are the patches I worked on today. It does seem to fix KIND=16 to use Float128, but by not considering long double for KIND processing, it breaks the tests that want to do ISO C binding to long double. Feel free to completely ignore the patches and go off in a different direction. But I tho

Re: [PATCH,FORTRAN 28/29] Free type-bound procedure structs

2021-10-28 Thread Bernhard Reutner-Fischer via Fortran
ping [Rebased, re-regtested cleanly. Ok for trunk?] On Wed, 5 Sep 2018 14:57:31 + Bernhard Reutner-Fischer wrote: > From: Bernhard Reutner-Fischer > > compiling gfortran.dg/typebound_proc_31.f90 leaked the type-bound > structs: > > 56 bytes in 1 blocks are definitely lost. > at 0x4C2CC0

Re: [PATCH,Fortran 0/1] Correct CAF locations in simplify

2021-10-28 Thread Bernhard Reutner-Fischer via Fortran
On Wed, 27 Oct 2021 23:29:40 +0200 Bernhard Reutner-Fischer wrote: > Hi! > > I found this lying around in an oldish tree. > Regtest running over night, ok for trunk if it passes? Regtest turned up no regressions. Ok for trunk? thanks, > > Bernhard Reutner-Fischer (1): > Tweak locations arou

Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers

2021-10-28 Thread Bernhard Reutner-Fischer via Fortran
On Wed, 27 Oct 2021 23:39:43 +0200 Bernhard Reutner-Fischer wrote: > Ping > [hmz. it's been a while, I'll rebase and retest this one. > Ok if it passes?] Testing passed without any new regressions. Ok for trunk? thanks, > > On Mon, 15 Oct 2018 10:23:06 +0200 > Bernhard Reutner-Fischer wrote: >

[PATCH,Fortran 1/2] Add uop/name helpers

2021-10-28 Thread Bernhard Reutner-Fischer via Fortran
From: Bernhard Reutner-Fischer Introduce a helper to construct a user operator from a name and the reverse operation, i.e. a helper to construct a name from a user operator. Cc: Jakub Jelinek gcc/fortran/ChangeLog: 2017-10-29 Bernhard Reutner-Fischer * gfortran.h (gfc_get_uop_from

[PATCH,Fortran 2/2] Fix write_omp_udr for user-operator REDUCTIONs

2021-10-28 Thread Bernhard Reutner-Fischer via Fortran
From: Bernhard Reutner-Fischer Due to a typo a user operator used in a reduction was not found in the symtree so would have been written multiple times (in theory). E.g. user operator ".add." was looked up as ".ad" instead of "add". For gcc-11 branch and earlier one would - memcpy (name

Re: [PATCH,FORTRAN] Fix memory leak of gsymbol

2021-10-28 Thread Bernhard Reutner-Fischer via Fortran
On Thu, 28 Oct 2021 23:37:59 +0200 Harald Anlauf wrote: > Hi Bernhard, > > Am 27.10.21 um 23:43 schrieb Bernhard Reutner-Fischer via Gcc-patches: > > ping > > [I'll rebase and retest this too since it's been a while. > > Ok if it passes?] > > > > On Sun, 21 Oct 2018 16:04:34 +0200 > > Bernhard R

Re: [PATCH,FORTRAN] Fix memory leak of gsymbol

2021-10-28 Thread Harald Anlauf via Fortran
Hi Bernhard, Am 27.10.21 um 23:43 schrieb Bernhard Reutner-Fischer via Gcc-patches: ping [I'll rebase and retest this too since it's been a while. Ok if it passes?] On Sun, 21 Oct 2018 16:04:34 +0200 Bernhard Reutner-Fischer wrote: Hi! Regtested on x86_64-unknown-linux, installing on aldot/

[PATCH] PR fortran/99853 - ICE: Cannot convert 'LOGICAL(4)' to 'INTEGER(8)' (etc.)

2021-10-28 Thread Harald Anlauf via Fortran
Dear Fortranners, the original fix by Steve was lingering in the PR. We did ICE in situations where in a SELECT CASE a kind conversion was deemed necessary, but it did involve different types. The check gfc_convert_type_warn () was invoked with arguments requesting to generate an internal error.