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

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

Hi Thomas, Am 27.09.21 um 14:07 schrieb Tobias Burnus: While playing I stumbled over the fact that when allocating an array with a dimension that has extent 0, e.g. 4:-5, the lbound gets reset to 1 and ubound set to 0. I am not sure, whether I fully understand what you wrote. For:  

Aw: Re: [PATCH] PR fortran/102458 - ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

Hi Thomas, > > Regtested on x86_64-pc-linux-gnu. OK for mainline? > > It was actually 10.1.12 :-) dang, you're right. Steve had it right, and I failed miserably on copy I should fix the comment. > OK for trunk. > > Thanks for the patch! Thanks for the review, which came after Jerry's! I

[PATCH] PR fortran/102458 - ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136

Dear Fortranners, we missed certain intrinsics as being disallowed in constant expressions, which lead to an ICE when these intrinsics were used in a specification expression with an initializer. The intrinsics in question are listed in F2018:10.1.2. As discussed in the PR, Steve recommended to

Re: [Patch] Fortran: Improve -Wmissing-include-dirs warnings [PR55534]

Hi Tobias, Am 21.09.21 um 21:22 schrieb Tobias Burnus: While the previous patch fixed -Wno-missing-include-dirs and sorted out some inconsistencies with libcpp warnings, it had two issues: * Some superfluous warnings were printed, e.g. for     gfortran nonexisting/file.f90   there was a

Re: [Patch] Fortran: Fix -Wno-missing-include-dirs handling [PR55534]

Hi Tobias, Am 20.09.21 um 22:33 schrieb Tobias Burnus: And v3 – I realized that testcases would be useful. Thus, now with added testcases. :-) I was about to recommend a testcase I prepared when your revised patch arrived. Will not bother you with it, as you seem to provide really good

[PATCH, committed] PR fortran/102366] [10/11/12 Regression] large arrays no longer become static

->state == COMP_NONE, which defeated my attempts to an ultimate solution. I have opened https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102390 to track this. Thanks, Harald commit 51166eb2c534692c3c7779def24f83c8c3811b98 Author: Harald Anlauf Date: Fri Sep 17 21:45:33 2021 +0200 Fort

[PATCH] PR fortran/102287 - optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines

As nicely described in the PR, we mishandled the case of passing optional allocatable DT arguments with allocatable components when the INTENT was declared as INTENT(OUT), as we unconditionally tried to deallocate these components even when the argument was not present. The obvious solution is to

[PATCH, committed] PR fortran/102311 - fix ICE during error recovery checking entry characteristics

Committed as obvious as r12-3533. The fix to PR87737 did work for the given testcase, but could lead to a bad internal compiler state for a variation of the testcase. (Found by Gerhard...) The solution was to not return too early after emitting the error message but going through a 'cleanup'

[PATCH] PR fortran/85130 - Handling of substring range

Dear all, in find_substring_ref we erroneously handled given substring start and end indices as unsigned integers. However, gives indices could be negative, which is legal as long as end < start, leading to a string of length zero. The current behavior could lead to a wrong length as well as an

*PING* [PATCH] PR fortran/82314 - ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972

Early *PING*. > Gesendet: Dienstag, 07. September 2021 um 23:44 Uhr > Von: "Harald Anlauf" > An: "fortran" , "gcc-patches" > Betreff: [PATCH] PR fortran/82314 - ICE in gfc_conv_expr_descriptor, at > fortran/trans-array.c:6972 > > When adding

[PATCH, committed] PR fortran/98490 - Unexpected out of bounds in array constructor with implied do loop

The following patch by Steve was lingering in the PR for some time. For an implied do loop within an array constructor we would generate an additional, bogus substring bounds check for the index variable before it actually became defined. The check thus depended on the previous value of the

[PATCH] PR fortran/82314 - ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972

When adding the initializer for an array, we need to make sure that array bounds are properly simplified if that array is a PARAMETER. Otherwise the generated initializer could be wrong and screw up subsequent simplifications, see PR. The minimal solution is to attempt simplification of array

Re: [Patch] Fortran: Handle allocated() with coindexed scalars [PR93834] (was: [PATCH] PR fortran/93834 - [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469)

d apart from any required for synchronization. ..." So a dirty shortcut could be allowed if the ALLOCATED() is considered valid. Harald > Gesendet: Dienstag, 07. September 2021 um 16:33 Uhr > Von: "Tobias Burnus" > An: "Harald Anlauf" > Cc: "fortran" , &quo

*PING* [PATCH] PR fortran/101327 - ICE in find_array_element, at fortran/expr.c:1355

PING. > Gesendet: Montag, 30. August 2021 um 23:40 Uhr > Von: "Harald Anlauf" > An: "fortran" , "gcc-patches" > Betreff: [PATCH] PR fortran/101327 - ICE in find_array_element, at > fortran/expr.c:1355 > > There was an issue when trying

Re: [PATCH] PR fortran/93834 - [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469

Hi Tobias, > Consider: > > type t >integer, allocatable :: a > end type t > > type(t) :: var[*] > print *, allocated(var%a) > print *, allocated(var[1]%a) > end what is the problem here? Can you elaborate? BTW: Intel accepts it, we (currently) accept it, my patch does not change

*PING* [PATCH] PR fortran/93834 - [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469

PING! > Gesendet: Dienstag, 24. August 2021 um 22:36 Uhr > Von: "Harald Anlauf" > An: "fortran" , "gcc-patches" > Betreff: [PATCH] PR fortran/93834 - [9/10/11/12 Regression] ICE in > trans_caf_is_present, at fortran/trans-intrinsic.c:8469 > >

[PATCH] PR fortran/56985 - gcc/fortran/resolve.c:920: "'%s' in cannot appear in COMMON ..."

I intend to commit the fix to the error message using the patch below within the next 24h unless there are objections or better suggestions. The unchanged part of the error message is already covered by gcc/testsuite/gfortran.dg/unlimited_polymorphic_2.f03 and does not need to be adapted.

[PATCH] PR fortran/101327 - ICE in find_array_element, at fortran/expr.c:1355

There was an issue when trying to use an element from an array constructor which was a broken in a way probably only Gerhard could conceive. We hit an assert that can be replaced by more robust code. Patch is basically Steve's. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald

[PATCH, committed] PR fortran/102113 - parsing error in assigned goto

A whitespace issue during parsing. Committed Steve's patch as obvious after regtesting on x86_64-pc-linux-gnu. Thanks, Harald Fortran - fix whitespace issue during parsing of assigned goto gcc/fortran/ChangeLog: PR fortran/102113 * match.c (gfc_match_goto): Allow for

[PATCH, committed] PR fortran/101349 - ICE in gfc_get_descriptor_field, at fortran/trans-array.c:140

The check of arguments to ALLOCATE did not properly implement F2008:C628 / F2018:C932, as it excluded unlimited polymophics, in contrast to the standard text. Fix this. Committed Steve's patch as obvious after regtesting on x86_64-pc-linux-gnu. Thanks, Harald Fortran - correct check for

[PATCH] PR fortran/87737 - ICE tree check: expected ssa_name, have addr_expr in remap_gimple_op_r, at tree-inline.c:923

Dear all, the ICE in the original testcase does no longer occur but leads to an error in a later stage of compilation, and we accepted invalid code. (Cross-checked with other compilers, such as Intel and NAG). F2018 states: 15.6.2.6 ENTRY statement (3) ... If the characteristics of the result

[PATCH] PR fortran/93834 - [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469

Dear Fortranners, here's a pretty obvious one: we didn't properly check the arguments for intrinsics when these had to be ALLOCATABLE and in the case that argument was a coarray object. Simple solution: just reuse a check that was used for pointer etc. Regtested on x86_64-pc-linux-gnu. OK for

Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

Hi Tobias, > LGTM – I am fine with either variant, but I am slightly inclined to > removing the gcc_assert* > – as I believe that the existing checks come early enough and do seem to > work well. I played some more and found additional cases that we hadn't discussed before. (At least I hadn't

Aw: Re: Re: Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

> Gesendet: Freitag, 20. August 2021 um 14:01 Uhr > Von: "Tobias Burnus" > On 20.08.21 12:53, Harald Anlauf wrote: > > > I played with variations of the testcase by specifying illegal > > substring bounds, but all these cases were caught in a different &g

[PATCH, committed] Fix bootstrap breakage caused by r12-3033 (PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514)

Dear all, I've just pushed the fix for the bootstrap breakage as confirmed by Jakub. commit r12-3043-g12f22906d3c025e7edb60e3264dc9cd27a49e3e1 Author: Harald Anlauf Date: Fri Aug 20 13:38:00 2021 +0200 Fortran - use temporary char buffer for passing HOST_WIDE_INT to gfc_error gcc

Aw: Re: Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

> Gesendet: Freitag, 20. August 2021 um 12:12 Uhr > Von: "Jakub Jelinek" > I have verified it fixes i686-linux bootstrap. > But the new testcase doesn't trigger any of those new errors, is something > else in the testsuite covering those or do you have some short snippet that > could verify the

Aw: Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

Hi Jakob, thanks for the detailed explanation! > The other much easier but uglier option is to use a temporary buffer: > char buffer[21]; > sprintf (buffer, HOST_WIDE_INT_PRINT_DEC, hwint_val); > gfc_error ("... %s ...", ... buffer ...); > This works, as it uses the host sprintf i.e.

Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

Hi! > Gesendet: Freitag, 20. August 2021 um 02:21 Uhr > Von: "H.J. Lu" > This may have broken bootstrap on 32-bit hosts: > > https://gcc.gnu.org/pipermail/gcc-regression/2021-August/075209.html I do not understand the error message: ../../src-master/gcc/fortran/simplify.c: In function ‘bool

Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

Hi Tobias, > I am inclined to say that the Intel compiler has a bug by not > accepting it – but as written before, I regard sub-string length > (esp. with const expr) inquiries as an odd corner case which > is unlikely to occur in real-world code. ok. > Still does not work – or rather:

Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

Hi Tobias, > Gesendet: Mittwoch, 18. August 2021 um 12:22 Uhr > Von: "Tobias Burnus" > > Note, however, that gfc_simplify_len still won't handle neither > > deferred strings nor their substrings. > > > > I think there is nothing to simplify at compile time here. > > Obviously, nonsubstrings

*PING* [PATCH, part2] PR fortran/98411 [10/11/12 Regression] Pointless: Array larger than ‘-fmax-stack-var-size=’, ...

*Ping* > Gesendet: Mittwoch, 04. August 2021 um 23:09 Uhr > Von: "Harald Anlauf" > An: "fortran" , "gcc-patches" > Betreff: [PATCH, part2] PR fortran/98411 [10/11/12 Regression] Pointless: > Array larger than ‘-fmax-stack-var-size=’, ... > >

*PING* Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

*Ping* > Gesendet: Dienstag, 03. August 2021 um 23:17 Uhr > Von: "Harald Anlauf" > An: "Harald Anlauf" > Cc: "Tobias Burnus" , "Bernhard Reutner-Fischer" > , "Harald Anlauf via Gcc-patches" > , "fortran" > Be

[PATCH] PR fortran/99351 - ICE in gfc_finish_var_decl, at fortran/trans-decl.c:695

Dear all, the checks for the STAT= and ERRMSG= arguments to the coarray SYNC statements did not properly handle several cases, such as named constants (parameters). While fixing this, I adjusted the code similarly to what was recently done for (DE)ALLOCATE. We now also accept function references

[PATCH] PR fortran/68568 - ICE with automatic character object and save, in combination with some options

Dear Fortranners, I intend to commit the following pretty obvious fix within the next 24 hours unless there are objections. Regtested on x86_64-pc-linux-gnu. Thanks, Harald Fortran: ICE with automatic character object, save, and various options gcc/fortran/ChangeLog: PR fortran/68568

[PATCH, part2] PR fortran/98411 [10/11/12 Regression] Pointless: Array larger than ‘-fmax-stack-var-size=’, ...

Dear all, here's the second part that should fix this regression for good. The patch also adjusts the warning message to make it easier to understand, using the suggestion by Tobias (see PR). Since F2018 in principle makes RECURSIVE the default, which might conflict with the purpose of the

Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

Here's now my third attempt to fix this PR, taking into account the comments by Tobias and Bernhard. > > On 10.06.21 20:52, Harald Anlauf via Fortran wrote: > > > +static bool > > > +substring_has_constant_len (gfc_expr *e) > > > +{ > > > + ptrd

Re: [PATCH] PR fortrsn/101564 - ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169

Hi Tobias, > > We should rather open a separate PR on auditing the related uses > > of gfc_match. > > I concur – I just wanted to quickly check how many %v are there – > besides %v, there are also direct calls to gfc_match_variable. > > Can you open a PR? this is now

Re: [PATCH] PR fortrsn/101564 - ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169

Hi Tobias, > > This works as expected with Intel and AOCC, but gives a > > syntax error with every gfortran tested because of match.c: > > > > alloc_opt_list: > >m = gfc_match (" stat = %v", ); > > I think we can simply change that one to %e; the definable > check should ensure that any

Re: [PATCH] PR fortran/101536 - ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7324

Hi Tobias, > > However, an additional plain check on e->rank != 0 also in the > > CLASS cases fixes the original issue as well as your example: > [...] > > And regtests ok. :-) > > See attached updated patch. > > I think you still need to remove the 'return true;' from > the 'if (e->rank != 0 &&

Re: [PATCH] PR fortrsn/101564 - ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169

Hi Tobias, I am afraid we're really opening a can of worms here > Additionally, I wonder whether that will work with: > > integer, pointer :: ptr > integer function f() >pointer :: f >f = ptr > end > allocate(A, stat=f()) > > The f() is a variable and definable – but I am currently

Re: [PATCH] PR fortran/101536 - ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7324

Hi Tobias, you are right in that I was barking up the wrong tree. I was focussed too much on the testcase in the PR. > I think that one is wrong. While CLASS_DATA (e) accesses > e->ts.u.derived->components, > which always works, your code assumes that there is only 'c' and not 'x%c' > where >

[PATCH] PR fortrsn/101564 - ICE in resolve_allocate_deallocate, at fortran/resolve.c:8169

I have the impression that Gerhard is a hydra: one PR down, he submits two new ones... :-( Anyway, here's a straightforward fix for a NULL pointer dereference for an invalid argument to STAT. For an alternative patch by Steve see PR. Regtested on x86_64-pc-linux-gnu. OK for mainline / 11-branch

[PATCH] PR fortran/101536 - ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7324

Another one of Gerhard's infamous testcases. We did not properly detect and reject array elements of type CLASS as argument to an intrinsic when it should be an array. Regtested on x86_64-pc-linux-gnu. OK for mainline / 11-branch when it reopens? Thanks, Harald Fortran: extend check for

[PATCH] PR fortran/101514 - ICE: out of memory allocating 18446744073709551600 bytes

While investigating one of Gerhard's latest bug reports, which was almost obvious to fix after a hint by Richard Biener, I found further variants of valid and invalid code that lead to either NULL pointer dereferences or similar OOM situations. Regtested on x86_64-pc-linux-gnu. OK for mainline /

[PATCH] PR fortran/100949 - [9/10/11/12 Regression] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1975

Hello world, we rather shouldn't consider a presence check for a non-dummy variable. Regtested on x86_64-pc-linux-gnu. OK for all affected branches? Thanks, Harald Fortran - ICE in gfc_conv_expr_present while initializing a non-dummy class variable gcc/fortran/ChangeLog: PR

Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

Hi Tobias, > On 10.06.21 20:52, Harald Anlauf via Fortran wrote: > > +static bool > > +substring_has_constant_len (gfc_expr *e) > > +{ > > + ptrdiff_t istart, iend; > > + size_t length; > > + bool equal_length = false; > > + > > + i

*Ping* [PATCH] PR fortran/101084 - [10/11/12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1124

*Ping* > Gesendet: Dienstag, 15. Juni 2021 um 21:31 Uhr > Von: "Harald Anlauf" > An: "fortran" , "gcc-patches" > Betreff: [PATCH] PR fortran/101084 - [10/11/12 Regression] ICE in > gfc_typenode_for_spec, at fortran/trans-types.c:1124 > > A

PING [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

*PING* > Gesendet: Mittwoch, 09. Juni 2021 um 23:39 Uhr > Von: "Harald Anlauf" > An: "fortran" , "gcc-patches" > Betreff: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, > at varasm.c:5514 > > Dear Fortranners, > >

[Patch, committed] PR fortran/101123 - [11/12 Regression] Invalid code for MAX0 with -fdefault-integer-8

As confirmed in the PR by Jakub, there was a bad conversion of the result of min0/max0 to the result type. We should just unconditionally convert in all cases. As a benefit, this also fixes pr100283. Committed after regtesting. Thanks, Harald Fortran - fix conversion to result type for the

[PATCH] PR fortran/101084 - [10/11/12 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1124

A recent change to the checking of legacy FORMAT tags did not handle cases where the type is not set. Adjust the check. Regtested on x86_64-pc-linux-gnu. OK for mainline / 11- / 10-branch? Thanks, Harald Fortran: reject FORMAT tag of unknown type. gcc/fortran/ChangeLog: PR

PING [PATCH] PR fortran/95502 - ICE in gfc_check_do_variable, at fortran/parse.c:4446

*PING* BTW this patch also addresses PR95501, so I'll update the Changelog. Thanks, Harald > Gesendet: Freitag, 04. Juni 2021 um 23:12 Uhr > Von: "Harald Anlauf" > An: "fortran" , "gcc-patches" > Betreff: [PATCH] PR fortran/95502 - ICE in gfc_che

Re: [PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

Hi Bernhard, > > +static bool > > +substring_has_constant_len (gfc_expr *e) > > +{ > > + ptrdiff_t istart, iend; > > + size_t length; > > + bool equal_length = false; > > + > > + if (e->ts.type != BT_CHARACTER > > + || !(e->ref && e->ref->type == REF_SUBSTRING) > > iff we ever can get

[PATCH] PR fortran/100950 - ICE in output_constructor_regular_field, at varasm.c:5514

Dear Fortranners, we should be able to simplify the length of a substring with known constant bounds. The attached patch adds this. Regtested on x86_64-pc-linux-gnu. OK for mainline? Since this should be rather safe, to at least 11-branch? Thanks, Harald Fortran - simplify length of

[PATCH] PR fortran/95502 - ICE in gfc_check_do_variable, at fortran/parse.c:4446

ICE-on-invalid issues during error recovery. Testcase by Gerhard, initial patch by Steve. I found another variant which needed an additional fix for a NULL pointer dereference. Regtested on x86_64-pc-linux-gnu. OK for mainline / 11-branch? Thanks, Harald Fortran - ICE in

PING [PATCH] PR fortran/99839 - [9/10/11/12 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234

*PING* > Gesendet: Donnerstag, 27. Mai 2021 um 22:20 Uhr > Von: "Harald Anlauf" > An: "fortran" , "gcc-patches" > Betreff: [PATCH] PR fortran/99839 - [9/10/11/12 Regression] ICE in > inline_matmul_assign, at fortran/frontend-passes.c:4234 > >

[PATCH] PR fortran/99839 - [9/10/11/12 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234

Dear Fortranners, frontend optimization tries to inline matmul, but then it also needs to take care of the assignment to the result array. If that one is not of canonical type, we currently get an ICE. The straightforward solution is to simply punt in those cases and avoid inlining. Regtested

[PATCH] PR fortran/100656 - ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934

Dear Fortranners, Gerhard found a case where bounds-checking for an optional, allocatable character dummy resulted in an ICE. We'd better not call the presence check on a non-dummy symbol, as this will hit an assert... Regtested on x86_64-pc-linux-gnu. OK for mainline? And backport to 11?

PING [PATCH] PR fortran/100602 - [11/12 Regression] Erroneous "pointer argument is not associated" runtime error

*PING* > Gesendet: Dienstag, 18. Mai 2021 um 20:36 Uhr > Von: "Harald Anlauf" > An: "fortran" , "gcc-patches" > Betreff: [PATCH] PR fortran/100602 - [11/12 Regression] Erroneous "pointer > argument is not associated" runtime erro

[PATCH] PR fortran/100551 - [11/12 Regression] Passing return value to class(*) dummy argument

The fix for PR93924/5 has caused a regression for code such as given in the present PR. This can be remedied by adjusting the check when to invoke the implicit conversion of actual argument to an unlimited polymorphic procedure argument. Regtested on x86_64-pc-linux-gnu. OK for mainline and

Aw: [Patch] Testsuite/Fortran: gfortran.dg/pr96711.f90 - fix expected value for PowerPC [PR96983]

Hi Tobias, > @All, Harald: Does the attached patch make sense? first of all: sorry for the really badly designed testcase. The best solution has already been discussed in this thread, which is to replace integer(16), parameter :: m1 = 9007199254740992_16!2**53

[PATCH] PR fortran/100602 - [11/12 Regression] Erroneous "pointer argument is not associated" runtime error

The generation of the new runtime check picked up the wrong attributes in the case of CLASS array arguments. There is related new code in gfc_conv_procedure_call which served as reference for the fix. Regtested on x86_64-pc-linux-gnu. OK for mainline / 11-branch? Thanks, Harald Fortran: Fix

[PATCH] PR fortran/98411 - [10/11/12 Regression] Pointless warning for static variables

A simple, self-explaining patch to avoid a wrong warning. Regtested on x86_64-pc-linux-gnu. OK for mainline? Affected branches? Thanks, Harald PR fortran/98411 - Pointless warning for static variables Variables with explicit SAVE attribute cannot end up on the stack. There is no point in

*PING* [PATCH] PR fortran/100274 - [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

PING! --- Dear Fortranners, Gerhard found a case where the mismatch of actual and formal argument lead to an ICE instead of the relevant warning. Furthermore, the special case of character argument avoided the check that the actual argument must be definable if the formal one is INTENT-OUT or

[PATCH] PR fortran/100274 - [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

Dear Fortranners, Gerhard found a case where the mismatch of actual and formal argument lead to an ICE instead of the relevant warning. Furthermore, the special case of character argument avoided the check that the actual argument must be definable if the formal one is INTENT-OUT or -INOUT. The

Re: [Patch] PR fortran/100218 - target of pointer from evaluation of function-reference

Hi Paul, > Is there a test for an error with -std=f2003? If not, you should, perhaps, > include one. after checking for the corresponding error message, I found that ptr-func-2.f90 already covers this case. Considering this, I'll rename the current testcase from pr100218.f90 to ptr-func-4.f90.

[Patch] PR fortran/100154 - [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

Now with the correct patch attached ... Sorry for the confusion! --- Dear Fortranners, we need to check the arguments to the affected GNU intrinsic extensions properly, and - as pointed out in the PR by Tobias - we need to allow function references that have a data pointer result. Also the

[Patch] PR fortran/100154 - [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

Dear Fortranners, we need to check the arguments to the affected GNU intrinsic extensions properly, and - as pointed out in the PR by Tobias - we need to allow function references that have a data pointer result. Also the argument names of the character arguments of the subroutine versions

[Patch] PR fortran/100218 - target of pointer from evaluation of function-reference

Dear Fortranners, while analyzing a different PR (PR100154), Tobias pointed out that the target of a pointer from the evaluation of function-reference is allowed to be used in a variable definition context and thus as an actual argument to a function or subroutine. This seems to be a more

Re: [PATCH] PR fortran/63797 - Bogus ambiguous reference to 'sqrt'

Hi Paul, all,   having really enjoyed the review process, I've now committed Paul's version including his comment. See also attached. Thanks, Harald   Gesendet: Freitag, 16. April 2021 um 13:02 Uhr Von: "Paul Richard Thomas" An: "Bernhard Reutner-Fischer" Cc: "

[PATCH] PR fortran/63797 - Bogus ambiguous reference to 'sqrt'

Hello everybody, we currently write the interface for intrinsic procedures to module files although that should not be necessary. (F2018:15.4.2.1 actually states that interfaces e.g. of intrinsic procedures are 'explicit'.) This lead to bogus errors due to an apparently bogus ambiguity. A simple

[PATCH] PR fortran/99840 - [8/9/10/11 Regression] ICE in gfc_simplify_matmul, at fortran/simplify.c:4777

Dear all, the simplification of the TRANSPOSE of a zero-sized array would lead to an ICE if the result was used in a subsequent simplification of a MATMUL. The reason was the lack of the proper initialization of the shape, which is mpz_t. Use mpz_init_set instead of mpz_set. Regtested on

Aw: Re: [Patch, fortran] PR99602 - [11 regression] runtime error: pointer actual argument not associated

Hi Tobias, > Shouldn't there be also a testcase which triggers this run-time error? The testcase is there, it simply has the wrong dg-foo: ! { dg-do compile } which should be ! { dg-do run } *-*-* There are certainly more cases which should insert checks but currently don't, like:

Aw: Re: [PATCH] PR fortran/99112 - [11 Regression] ICE with runtime diagnostics for SIZE intrinsic function

see: > contrib/gcc-changelog/test_patches.txt I've done it as described above. In the git log I see the co-author, while > git show -1 | ./contrib/gcc-changelog/git_check_commit.py -p produces: Checking c2d7c39fcb8a3cb67600cdb6fde49ecb0e951589: OK -- gcc/fortran/ChangeLog -- 20

[PATCH] PR fortran/99112 - [11 Regression] ICE with runtime diagnostics for SIZE intrinsic function

Dear all, the addition of runtime checks for the SIZE intrinsic created a regression that showed up for certain CLASS arguments to procedures. Paul did most of the work (~ 99%), but asked me to dig into an issue with an inappropriately selected error message. This actually turned out to be a

Re: [PATCH] PR fortran/99205 - [10/11 Regression] Out of memory with undefined character length

Dear Tobias, all, > The reason that it is not permitted is the "automatic data object" > (see *...* highlighted parts in the quote): > > C876 (R839) A *variable* whose *designator* appears as a > *data-stmt-object* or a data-i-do-object hall not be a > dummy argument, accessed by use or host

Re: [PATCH] PR fortran/99205 - [10/11 Regression] Out of memory with undefined character length

Dear Tobias, thanks for your comments. > > A variable that is a data statement object shall be a designator, > > thus a character variable shall have a constant length. > > This comment is wrong: A designator does not imply this – nor is > F2018:C875 violated, not even the substring

[PATCH] PR fortran/99205 - [10/11 Regression] Out of memory with undefined character length

Dear all, character variables with undefined length are not allowed as objects in DATA statements. We better reject them. Regtested on x86_64-pc-linux-gnu. OK for master / backport? Thanks, Harald PR fortran/99205 - Out of memory with undefined character length A variable that is a data

Re: [PATCH] PR libfortran/99218 - [8/9/10/11 Regression] matmul on temporary array accesses invalid memory

Dear all, I finally figured out that the array dimensions simply need to be large enough to get invalid memory accesses that actual lead to a crash. I will commit the following testcase along with the fix to libfortran: ! { dg-do run } ! PR libfortran/99218 - matmul on temporary array accesses

Aw: Re: [PATCH] PR libfortran/99218 - [8/9/10/11 Regression] matmul on temporary array accesses invalid memory

Hi Jerry, > Yes, OK, however, have you been able to test performance. I am only > curious. There was a test program we used back when this code was first > implemented in bugzilla. I do not remember the PR number off hand. as you mentioned in a private mail, it was PR51119, and the timing

*PING* [PATCH] PR libfortran/99218 - [8/9/10/11 Regression] matmul on temporary array accesses invalid memory

Early ping. Harald > Gesendet: Dienstag, 23. Februar 2021 um 22:46 Uhr > Von: "Harald Anlauf" > An: "fortran" , "gcc-patches" > Betreff: [PATCH] PR libfortran/99218 - [8/9/10/11 Regression] matmul on > temporary array accesses invalid memory

[Patch, part1] PR fortran/49278 - ICE when combining DATA with default initialization

Dear all, the present PR has two issues. The first one, addressed by this patch, was about accepting invalid code where a variable appeared both in a declaration with PARAMETER as well as in a DATA statement, which could lead to an ICE. We now reject this. (There is a separate issue about

[PATCH] PR libfortran/99218 - [8/9/10/11 Regression] matmul on temporary array accesses invalid memory

Dear all, under certain circumstances a call to MATMUL for rank-2 times rank-1 would invoke a highly tuned rank-2 times rank-2 algorithm which could lead to invalid reads and writes. The solution is to check the rank of the second argument to matmul and fall back to a regular algorithm for

[PATCH] PR fortran/99206 - [11 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:1980

Dear all, when simplifying the RESHAPE intrinsic we lost the string length when the resulting array had size zero. The attached patch sets the resulting length from the source. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald PR fortran/99206 - ICE in add_init_expr_to_sym,

[PATCH] PR fortran/99169 - [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument

Dear all, we should not clobber the pointer in case of an allocatable scalar being an intent(out) dummy argument to a procedure. Regtested on x86_64-pc-linux-gnu. OK for master? Since this is a regression, also for backports to 10/9? Thanks, Harald PR fortran/99169 - Do not clobber

[PATCH] PR fortran/99147 - Sanitizer detects heap-use-after-free in gfc_add_flavor

Dear all, the PR reports an issue detected with an ASAN instrumented compiler, which can also be verified with valgrind. It appears that the state of gfc_new_block could be such that it should not be dereferenced. Reversing the order of condition evaluation helped. I failed to find out why this

Re: [PATCH] [8/9/10/11 Regression] [OOP] PR fortran/86470 - ICE with OpenMP

Hi Thomas, > > Should the testcase be moved to the gomp/ subdirectory? > Yes. It's a compile-time test, and it will then only be run > if the the compiler can do OpenMP. > > You will not need the > > +! { dg-options "-fopenmp" } > > line, then. Adjusted and committed as

[PATCH] [8/9/10/11 Regression] [OOP] PR fortran/86470 - ICE with OpenMP

Dear all, the fix for this ICE is obvious: make gfc_call_malloc behave as documented. Apparently the special case in question was not exercised in the testsuite. Regtested on x86_64-pc-linux-gnu. OK for master / backports? Should the testcase be moved to the gomp/ subdirectory? Thanks, Harald

Re: [PATCH] PR fortran/70070 - ICE on initializing character data beyond min/max bound

Hi Thomas, > Gesendet: Montag, 25. Januar 2021 um 19:58 Uhr > Von: "Thomas Koenig" > a.f90:3:10: > > 3 | print a(0:3) >| 1 > Error: Substring start index at (1) is less than one > a.f90:4:10: > > 4 | print a(1:4) >| 1 > Error: Substring end index

[PATCH] PR fortran/70070 - ICE on initializing character data beyond min/max bound

Dear all, the attached patch is pretty much self-explaining: check for bounds violation when initializing a substring in a data statement and treat the resulting error. If more detailed information should be emitted with the error message, I'm open for suggestions. Regtested on

[PATCH] PR fortran/98661 - valgrind issues with error recovery

Dear all, the former Fortran testcase charlen_03.f90, which some time ago used to ICE, could still display issues during error recovery. As Dominique pointed out, this required either an instrumented compiler, or valgrind. The issue turned out to not have anything to do with CHARACTER, but with

[Patch, RFC] PR fortran/93340 - [8/9/10/11 Regression] fix missed substring simplifications

Dear all, when playing around with the issues exposed by PR93340, particularly visible in the tree dump, I tried to find ways to simplify substrings in those cases where they are eligible as designator, which is required e.g. in DATA statements. Given my limited understanding, I finally arrived

[PATCH] PR fortran/78746 - invalid access after error recovery

Dear all, the PR contains a lengthy discussion of several testcases, some which were considered invalid and thus removed from the testsuite (charlen_03.f90, charlen_10.f90), charlen_15.f90 was resolved elsewhere, so that only class_61.f90 was left with an invalid access after error recovery with

[PATCH] PR fortran/96381 - invalid read in gfc_find_derived_vtab

Dear all, happy New Year! The testcase committed with the fix for PR93337 uncovered a latent issue with an invalid read that was discovered with an ASAN instrumented compiler but which could also be verified by running f951 under valgrind. According to my gdb sessions the invalid read happens

[PATCH] PR fortran/93685 - [9/10/11 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135

Dear all, the patch is almost self-explaining. We mishandled the case of initializing pointer components to derived types of type CHARACTER via DATA, which screwed up both legal and illegal uses. The attached patch fixes that, and checks that the legal cases work. Regtests cleanly on

[PATCH] PR fortran/98307 - Dependency check fails when using "allocatable"

Dear all, since the introduction of check_forall_dependencies() we mishandled the dependencies of ALLOCATABLE components of derived types, while POINTER was dealt with. Fix that. Regtested on x86_64-pc-linux-gnu. OK for master? Since we generate wrong code under the given circumstances, what

[PATCH] PR fortran/98284 - ICE in get_array_index

Dear all, ICE-on-invalid: testcase by Arseny, draft patch by Steve, slightly polished and regtested by me on x86_64-pc-linux-gnu. OK for master? Thanks, Harald PR fortran/98284 - ICE in get_array_index Reject DATA elements with the ALLOCATABLE attribute also when they are components of a

[PATCH] PR fortran/95372 - ICE in find_array_section, at fortran/expr.c:1687

ICE on valid code. Original patch by Steve, slightly adjusted and regtested on x86_64-pc-linux-gnu. OK for master? Backports? Should be safe everywhere, as it replaces an assert by an if condition. Thanks, Harald PR fortran/95372 - ICE in find_array_section, at fortran/expr.c:1687 Fix

Re: [PATCH] PR fortran/98017 - [8/9/10/11 Regression] Suspected regression using PACK

Hi Thomas, > I don't think that this is a feature of gfc_copy_expr, I think it is a > bug which probably also bites us in other circumstances which we may > work around in other places and/or which causes other instances of > wrong code. > > So, I'd very much prefer that the character length is

[PATCH] PR fortran/98017 - [8/9/10/11 Regression] Suspected regression using PACK

When substituting an array-valued character parameter variable, the call to gfc_copy_expr returns character length 1. Fix up the resulting length. I could not figure out whether this is a bug or a feature of gfc_copy_expr. But the fix to simplify_parameter_variable would not do any harm in any

<    2   3   4   5   6   7   8   9   >