Re: DGBSV: incorrect numerical results with -L/usr/lib64/atlas ?

Hi Jorge, I do not know if this forum is the most appropriate, but as it based using gfortran I will try to start here. I usually build the ATLAS library in some beta version without any numerical problem that I remember. In a circumstantial way, I have to use the system ATLAS library and, toda

DGBSV: incorrect numerical results with -L/usr/lib64/atlas ?

Hi all, I do not know if this forum is the most appropriate, but as it based using gfortran I will try to start here. I usually build the ATLAS library in some beta version without any numerical problem that I remember. In a circumstantial way, I have to use the system ATLAS library and, toda

Re: [PATCH] PR fortran/102520 - [10/11/12 Regression] ICE in expand_constructor, at fortran/array.c:1802

Hi Harald, Gerhard's testcase triggers a NULL pointer dereference during the attempt to expand an invalid constructor. The simple and obvious solution is to catch that case. Regtested on x86_64-pc-linux-gnu. OK for all affected branches? OK. Thanks for the patch! Best regards Tho

[PATCH] PR fortran/102520 - [10/11/12 Regression] ICE in expand_constructor, at fortran/array.c:1802

Dear Fortranners, Gerhard's testcase triggers a NULL pointer dereference during the attempt to expand an invalid constructor. The simple and obvious solution is to catch that case. Regtested on x86_64-pc-linux-gnu. OK for all affected branches? Thanks, Harald Fortran: fix error recovery for i

Re: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070]

Hi Tobias, let me first reach for my brown bag... > Otherwise, the quote from F2018 of my previous email applies: > > F2018:16.9.109 LBOUND has for "case(i)", i.e. with a 'dim' > argument the following. The case without 'dim' just iterates > through case (i) for each dim. Thus: > > "If DIM is pre

[Patch] Fortran: Fix same_type_as

Found when looking at Sandra's c535b-1.f90 and playing around. When fixing same_type_as, I spotted by code reading another issue, related to not catering for derived types. (Untested whether it failed indeed.) I added now a bunch of testcases. OK for mainline? Tobias - Siemens

Re: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070]

Hi! On 2021-09-27T14:07:53+0200, Tobias Burnus wrote: > now committed r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0 > Conclusion: Reviews are very helpful :-) Ha! :-) (... and I wasn't even involed here!) ;-P As testing showed here: > --- /dev/null > +++ b/gcc/testsuite/gfortran.dg/a

Re: [committed] libgomp.oacc-fortran/privatized-ref-2.f90: Fix dg-note (was: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070])

Hi! On 2021-09-27T14:38:56+0200, Tobias Burnus wrote: > On 27.09.21 14:07, Tobias Burnus wrote: >> now committed r12-3897-g00f6de9c69119594f7dad3bd525937c94c8200d0 > > I accidentally changed dg-note to dg-message when updating the expected > output, as the dump has changed. (Copying seemingly the

[committed] gfortran.dg/include_15.f90: Add dg-prune-output [PR102500]

It turned out that one warning output depended on details how the testsuite it run. Thus, just ignore that bit that did not always appear or not by using dg-prune-output. Those subtle differences in test runs which make a test fail or not fail, depending on how GCC's testsuite is run, make life l