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

I've played with some patches to PowerPC to set the defaults for fortran. But without doing a full rebuild like you would do with a new distribution, I think it will be problematical, unless you build everything with the default long double set to IEEE 128-bit. First off all, libquadmath is curre

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

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/fortran-fe-stringpool. > > We did not free global symbols. For a simplified abs

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

Ping [hmz. it's been a while, I'll rebase and retest this one. Ok if it passes?] On Mon, 15 Oct 2018 10:23:06 +0200 Bernhard Reutner-Fischer wrote: > If a finalization is not required we created a namespace containing > formal arguments for an internal interface definition but never used > any o

[PATCH,Fortran 1/1] Tweak locations around CAF simplify

From: Bernhard Reutner-Fischer addresses: FIXME: gfc_current_locus is wrong by using the locus of the current intrinsic. Regtests clean, ok for trunk? gcc/fortran/ChangeLog: 2018-09-20 Bernhard Reutner-Fischer * simplify.c (gfc_simplify_failed_or_stopped_images): Use current

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

Hi! I found this lying around in an oldish tree. Regtest running over night, ok for trunk if it passes? Bernhard Reutner-Fischer (1): Tweak locations around CAF simplify gcc/fortran/simplify.c | 28 +++- 1 file changed, 15 insertions(+), 13 deletions(-) -- 2.33.0

[PATCH,Fortran] Fortran: Delete unused decl in gfortran.h

From: Bernhard Reutner-Fischer Hi! Delete some more declarations without definitions and make some functions static. Bootstrapped and regtested on x86_64-unknown-linux without regressions. Ok for trunk? gcc/fortran/ChangeLog: * decl.c (gfc_insert_kind_parameter_exprs): Make static.

Re: [Patch, Fortran] PR 86935: Bad locus in ASSOCIATE statement

On Wed, 27 Oct 2021 21:44:52 +0200 Harald Anlauf via Fortran wrote: > Hi Bernhard, > > Am 27.10.21 um 19:40 schrieb Bernhard Reutner-Fischer via Fortran: > > AFAICS current trunk still has this issue. > > Any takers? > > thanks, > > can you create a PR tracking this issue? now https://gcc.gn

Re: [Patch, Fortran] PR 86935: Bad locus in ASSOCIATE statement

Hi Bernhard, Am 27.10.21 um 19:40 schrieb Bernhard Reutner-Fischer via Fortran: AFAICS current trunk still has this issue. Any takers? thanks, can you create a PR tracking this issue? AFAICS PR86935 has been fixed for gcc-9+. Harald On Sun, 2 Sep 2018 17:16:07 +0200 Bernhard Reutner-Fische

[PATCH] PR fortran/69419 - ICE: tree check: expected array_type, have real_type in gfc_conv_array_initializer, at fortran/trans-array.c:5618

Dear Fortranners, when debugging the testcase, I noticed that a coarray declaration in a COMMON statement wrongly set the dimension attribute instead of the codimension. As a consequence, subsequent checks that catch this invalid situation would not trigger. I see two possible solutions: - in g

Re: [Patch, Fortran] PR 86935: Bad locus in ASSOCIATE statement

AFAICS current trunk still has this issue. Any takers? thanks, On Sun, 2 Sep 2018 17:16:07 +0200 Bernhard Reutner-Fischer wrote: >i spotted one > (pre-existing) possible inconsistency that i did overlook back then: > > gfc_match_associate () reads