[Bug fortran/117797] New: [15 Regression] ICE in gfc_get_array_span

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117797 Bug ID: 117797 Summary: [15 Regression] ICE in gfc_get_array_span Product: gcc Version: 14.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fort

[Bug fortran/117774] New: ICE passing imaginary part of complex array to assumed rank dummy

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117774 Bug ID: 117774 Summary: ICE passing imaginary part of complex array to assumed rank dummy Product: gcc Version: 14.1.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #10 from Neil Carlson --- Thanks Harald for hunting this down! I've tested your patch on master with -fsanitize=address against my library that turned up these errors and it all looks good now. Is it possible to back port this to th

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #6 from Neil Carlson --- Here's a variation of the example involving arrays. I expect the source of the failure here is the same, but I want to be sure this example is also fixed by the eventual patch. program main call run contai

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #4 from Neil Carlson --- Same results with 13.2.0 configured with --enable-valgrind-annotations. Here's the output with 13.2.0 and gfortran -g -O0 -fsanitize=address foo.f90 : ==1126830==ERROR: AddressSanitizer: heap-buffer-overflo

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #3 from Neil Carlson --- Those results are with 12.3.0 configured with --enable-valgrind-annotations. I'm building 13.2.0 now with the same to see if more info is generated. (I don't typically use 13.x because it finalization is brok

[Bug fortran/114827] Valgrind reports errors with class(*) assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #1 from Neil Carlson --- I should add that I get the same results with gcc versions going back to at least gcc 11.

[Bug fortran/114827] New: Valgrind reports errors with class(*) assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 Bug ID: 114827 Summary: Valgrind reports errors with class(*) assignment Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Componen

[Bug fortran/112964] New: ICE for recursive subroutine with assumed rank class(*) argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112964 Bug ID: 112964 Summary: ICE for recursive subroutine with assumed rank class(*) argument Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #9 from Neil Carlson --- Bug is still present in 13.2.0.

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #12 from Neil Carlson --- Paul, > [...] there are some humdingers going back a long way that I will take a look > at, > once I am done with associate. That would be great, thanks!

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #9 from Neil Carlson --- > > (i) Have I got the lot? > I believe so. > (ii) Are there existing PRs for the two most recent? > I always try to report the bugs at the same time they go into my "database". The first is here: https:/

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #7 from Neil Carlson --- > Was it as a result of the nagfor error, perhaps? If so, have you already sent > them a bug report? I actually didn't originally try that commented-out assignment with nagfor, but confirm that it gets it w

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #5 from Neil Carlson --- >> !x%var_ptr() = 2.0 ! THIS IS NOT REJECTED AS EXPECTED > > I could have phrased the comment better. I expected that assignment to be okay > (i.e., not rejected) and it wasn't. Sorry for the confusion. A

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #4 from Neil Carlson --- Hi Paul, > !x%var_ptr() = 2.0 ! THIS IS NOT REJECTED AS EXPECTED I could have phrased the comment better. I expected that assignment to be okay (i.e., not rejected) and it wasn't. Sorry for the confusion

[Bug fortran/110224] New: Rejects valid: function reference with data pointer result as lhs in assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 Bug ID: 110224 Summary: Rejects valid: function reference with data pointer result as lhs in assignment Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severi

[Bug fortran/110033] rejects-valid: associate name corresponding to coarray selector should be considered a coarray

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110033 --- Comment #1 from Neil Carlson --- This must be related to PR78152

[Bug fortran/110033] New: rejects-valid: associate name corresponding to coarray selector should be considered a coarray

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110033 Bug ID: 110033 Summary: rejects-valid: associate name corresponding to coarray selector should be considered a coarray Product: gcc Version: 13.1.0 Status: UNCONFIRMED

[Bug fortran/110012] New: ICE involving parametrized polymorphic variable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110012 Bug ID: 110012 Summary: ICE involving parametrized polymorphic variable Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #8 from Neil Carlson --- We've been bitten by what looks to be the same bug in our large Fortran code: 245 | end module kuprat_mapper_type | 1 Error: Contained procedure ‘__final_integer_set_type_

[Bug fortran/109846] [rejects valid] Pointer-valued function reference rejected as actual argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846 --- Comment #2 from Neil Carlson --- Amusing! I have a regression in 13.1 (which I need to create a reproducer for) where the workaround for a segfault is to use a RESULT variable -- just the opposite :-)

[Bug fortran/109846] New: [rejects valid] Pointer-valued function reference rejected as actual argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109846 Bug ID: 109846 Summary: [rejects valid] Pointer-valued function reference rejected as actual argument Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity

[Bug fortran/104630] New: module subroutine not accessible from submodule

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104630 Bug ID: 104630 Summary: module subroutine not accessible from submodule Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component

[Bug fortran/103394] Bad object code for structure constructor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103394 --- Comment #1 from Neil Carlson --- I've experimented some more and have reduced things further to this example. I'm not positive it captures everything that is going wrong in the original. program example type :: foo end type type :: bar

[Bug fortran/103394] New: Bad object code for structure constructor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103394 Bug ID: 103394 Summary: Bad object code for structure constructor Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortra

[Bug fortran/100815] [10.3, 11 regression] Segfault assigning to scalar allocatable polymorphic LHS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100815 --- Comment #1 from Neil Carlson --- Actually it looks like the regression was introduced in 10.3. It works in 10.2 and earlier.

[Bug fortran/100815] New: [11 regression] Segfault assigning to scalar allocatable polymorphic LHS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100815 Bug ID: 100815 Summary: [11 regression] Segfault assigning to scalar allocatable polymorphic LHS Product: gcc Version: 11.1.1 Status: UNCONFIRMED Severity: nor

[Bug fortran/93762] Truncation of deferred-length string when passing as optional

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93762 --- Comment #4 from Neil Carlson --- It would be great if somebody possessing the necessary skills could invest the time to fix this. For me this is bug breaks a common usage pattern of including optional stat, errmsg arguments to procedure inter