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

2024-04-28 Thread neil.n.carlson at gmail dot com via Gcc-bugs
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

2024-04-25 Thread neil.n.carlson at gmail dot com via Gcc-bugs
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

2024-04-24 Thread neil.n.carlson at gmail dot com via Gcc-bugs
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

2024-04-24 Thread neil.n.carlson at gmail dot com via Gcc-bugs
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

2024-04-23 Thread neil.n.carlson at gmail dot com via Gcc-bugs
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

2024-04-23 Thread neil.n.carlson at gmail dot com via Gcc-bugs
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- I'm trying to pin down a malloc corruption error ("malloc(): corrupted top size") that happens during finalization of a derived type object. I

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

2023-12-11 Thread neil.n.carlson at gmail dot com via Gcc-bugs
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- I'm getting an internal compiler error with the following reduced example. Note that the ICE disappears if CLASS(

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

2023-08-07 Thread neil.n.carlson at gmail dot com via Gcc-bugs
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

2023-06-22 Thread neil.n.carlson at gmail dot com via Gcc-bugs
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

2023-06-20 Thread neil.n.carlson at gmail dot com via Gcc-bugs
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

2023-06-20 Thread neil.n.carlson at gmail dot com via Gcc-bugs
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

2023-06-20 Thread neil.n.carlson at gmail dot com via Gcc-bugs
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

2023-06-20 Thread neil.n.carlson at gmail dot com via Gcc-bugs
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

2023-06-12 Thread neil.n.carlson at gmail dot com via Gcc-bugs
Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- According to 9.2 of the F18 standard, a function reference that returns a data pointer is a variable and can

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

2023-05-29 Thread neil.n.carlson at gmail dot com via Gcc-bugs
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

2023-05-29 Thread neil.n.carlson at gmail dot com via Gcc-bugs
Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- In the following example, the associate name Y corresponds to a coarray. According to 11.1.3.3

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

2023-05-27 Thread neil.n.carlson at gmail dot com via Gcc-bugs
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- I get an ICE with the following example: module pde_class type, abstract :: pde(npde) integer,len :: npde end type end module module navier_stokes_type

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

2023-05-24 Thread neil.n.carlson at gmail dot com via Gcc-bugs
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

2023-05-13 Thread neil.n.carlson at gmail dot com via Gcc-bugs
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

2023-05-13 Thread neil.n.carlson at gmail dot com via Gcc-bugs
Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- Gfortran rejects the following example. module foo type :: parameter_list contains procedure :: sublist

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

2022-02-21 Thread neil.n.carlson at gmail dot com via Gcc-bugs
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- Consider this minimal example. File module.f90: module modA private type, public :: typeA contains procedure :: foo end type

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

2021-11-23 Thread neil.n.carlson at gmail dot com via Gcc-bugs
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

2021-11-23 Thread neil.n.carlson at gmail dot com via Gcc-bugs
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- Bad object code is being generated for the structure constructor expression in the example below. This occurs for the current 12.0 trunk and any of the earlier 9.x, 10.x

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

2021-05-28 Thread neil.n.carlson at gmail dot com via Gcc-bugs
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

2021-05-28 Thread neil.n.carlson at gmail dot com via Gcc-bugs
: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- The current head of the gcc-11 branch segfaults on the assignment statement in the following program. The program

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

2021-03-12 Thread neil.n.carlson at gmail dot com via Gcc-bugs
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

[Bug fortran/94909] Rejects valid code for recursion where there is none

2020-05-04 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94909 --- Comment #3 from Neil Carlson --- Richard, this is just a typical declaration of an abstract type. An extension of this type will have to define the deferred dot_ function with an interface that happens to match the interface of dot. The dot f

[Bug fortran/94909] New: Rejects valid code for recursion where there is none

2020-05-01 Thread neil.n.carlson at gmail dot com
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- The compiler rejects the following valid code that contains no recursion. module example type, abstract :: foo contains procedure :: dot procedure

[Bug fortran/94463] New: Bad object code / reference to undefined symbol

2020-04-02 Thread neil.n.carlson at gmail dot com
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- In the following example (two files) the compiler is generating a reference to the undefined symbol __vtab_scalar_func_class_Scalar_func.3804. This is probably meant

[Bug fortran/89925] [9 Regression] Wrong array bounds from ALLOCATE with SOURCE or MOLD

2019-04-05 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89925 --- Comment #2 from Neil Carlson --- Right, when I said it failed on 8, I had misunderstood my colleague; he had only tried 9.

[Bug fortran/89925] New: [8,9 Regression] Wrong array bounds from ALLOCATE with MOLD

2019-04-02 Thread neil.n.carlson at gmail dot com
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- My colleague passed this example on to me to report. This runs correctly with a 8.2.1 and 9 from Sept, but fails with the current 8 and

[Bug fortran/89174] [8 Regression] Allocation segfault with CLASS(*) MOLD

2019-02-24 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174 --- Comment #14 from Neil Carlson --- The comment for r268313 calls out a change to gfc_find_and_cut_at_last_class_ref -- same function Thomas worked on for the fix on the trunk.

[Bug fortran/89174] [8 Regression] Allocation segfault with CLASS(*) MOLD

2019-02-24 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174 --- Comment #13 from Neil Carlson --- I've pinpointed were the regression was introduced on the 8 branch. r268313 segfaults, but r268311 (the preceding change to 8) works fine.

[Bug fortran/87566] ICE with class(*) and select

2019-02-23 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566 Neil Carlson changed: What|Removed |Added CC||neil.n.carlson at gmail dot com

[Bug fortran/89174] [8/9 Regression] Allocation segfault with CLASS(*) MOLD

2019-02-23 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89174 --- Comment #3 from Neil Carlson --- r265171 is the commit that broke the 9.0 trunk; r265171 segfaults but r265170 works correctly. I haven't been able to pinpoint where this stuff was back-ported to the 8 branch, but it definitely was. This exam

[Bug fortran/89174] New: [8/9 Regression] Allocation segfault with CLASS(*) MOLD

2019-02-03 Thread neil.n.carlson at gmail dot com
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- Some relatively recent change (since ~Sept) has broken 8.2.1 and 9.0. Code that contained the type of allocation given in the following

[Bug fortran/87625] [OOP] (re)allocate on assignment fails for polymorphic array

2019-02-02 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87625 --- Comment #6 from Neil Carlson --- Yes, can this please be back-ported? Still broken on at least 8.

[Bug fortran/88169] Rejects USE rename of namelist group

2018-11-24 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #10 from Neil Carlson --- Also a remark about the output of comment 7 just in case someone is thinking it ought to say "&BAR" (like I was expecting/hoping when I started experimenting with the original example). 13.11.3.1 says 1 I

[Bug fortran/88169] Rejects USE rename of namelist group

2018-11-24 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #9 from Neil Carlson --- Actually I think the usage in comment 8 is an intentional extension. There is a test in the dg test suite that does exactly this if I remember correctly. The test was namelist_use.f90. I was told that gfortran

[Bug fortran/88169] Rejects USE rename of namelist group

2018-11-23 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #5 from Neil Carlson --- Stated a bit more clearly, the question is, whether in The namelist-group-name shall not be a name accessed by use association. the name (in the scope of the declaration) is accessed by use association, or

[Bug fortran/88169] Rejects USE rename of namelist group

2018-11-23 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88169 --- Comment #4 from Neil Carlson --- I think the intent of C8102 (R868) The namelist-group-name shall not be a name accessed by use association. is to say you can't define a namelist with a name accessed by use association. That seems to fit be

[Bug fortran/88169] New: Rejects USE rename of namelist group

2018-11-23 Thread neil.n.carlson at gmail dot com
Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- The current 8.2.1 compiler rejects this example, module foo_nml real :: x namelist /foo/ x end module program main use foo_nml, only: bar => foo x =

[Bug fortran/88043] Runtime Error when calling deferred member function

2018-11-15 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88043 --- Comment #1 from Neil Carlson --- I've been poking at Zach's example and trimmed it down a bit: In one file: module typeA implicit none private type, abstract, public :: A contains procedure :: call_sub procedure(z), deferr

[Bug fortran/82996] ICE and segfault with derived type finalization

2018-09-28 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996 --- Comment #10 from Neil Carlson --- A reader on c.l.f suggested this workaround for the bug. I'm sharing it here because I think it may help to isolate where the problem is. The suggestion was to make the B array component allocatable and allo

[Bug fortran/84539] ICE and segfault with assignment to CLASS(*) array

2018-08-16 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84539 --- Comment #4 from Neil Carlson --- Update with 8.2.0 The ICE is gone, but a run time segfault remains: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f82986c06df in ??? #1 0x

[Bug fortran/86100] New: Spurious error with -fcheck=bounds and allocatable class(*) array components

2018-06-10 Thread neil.n.carlson at gmail dot com
: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- When compiled with -fcheck=bounds, the following example gives a spurious runtime bound mismatch error on the 

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

2018-05-22 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213 Neil Carlson changed: What|Removed |Added Version|8.0.1 |8.1.1 --- Comment #27 from Neil Carlson

[Bug fortran/83118] [7/8/9 Regression] Bad intrinsic assignment of class(*) array component of derived type

2018-05-22 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 Neil Carlson changed: What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE

[Bug fortran/84546] [7/8 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component

2018-03-11 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84546 --- Comment #6 from Neil Carlson --- Thank you, thank you Paul! This also fixes my test case for PR83118 which I think must have been due to the same underlying problem

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

2018-03-02 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381 --- Comment #13 from Neil Carlson --- And one more missed file due to a line split between the "call" and "abort". Here's the patch: diff --git a/overload_1.f90 b/overload_1.f90 index afd4f81..66fbea4 100644 --- a/overload_1.f90 +++ b/overload_

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

2018-03-02 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381 --- Comment #12 from Neil Carlson --- Argh... here's the *correct* patch diff --git a/literal_character_constant_1.inc b/literal_character_constant_1.inc index ba24966..40375cd 100644 --- a/literal_character_constant_1.inc +++ b/literal_characte

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

2018-03-02 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381 --- Comment #11 from Neil Carlson --- One more missed file, an include file included by literal_character_constant_1_x.F. Here's the patch: diff --git a/literal_character_constant_1.inc b/literal_character_constant_1.inc index ba24966..8beea79

[Bug fortran/84546] New: [7/8 Regression] Bad sourced allocation of CLASS(*) with source with CLASS(*) component

2018-02-24 Thread neil.n.carlson at gmail dot com
Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- The following example produces the expected result with 6.4.1, but not with the latest 7 and 8 trunk

[Bug fortran/84432] [F08] Detect illegal component initialization in pdt_27.f03

2018-02-24 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84432 --- Comment #6 from Neil Carlson --- ... and this would also be invalid type t(a) integer, len :: a = 3 character(len=a) :: c = 'foo' end type

[Bug fortran/84432] [F08] Detect illegal component initialization in pdt_27.f03

2018-02-24 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84432 --- Comment #5 from Neil Carlson --- No, both of those are valid. The constraint is on component initialization, and type parameters are *not* components. So something like this would be invalid by F08:C458 type t(a) integer, len :: a

[Bug fortran/84543] New: undefined reference to __copy_INTEGER_4_.3788

2018-02-24 Thread neil.n.carlson at gmail dot com
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- I stumbled across this problem while reducing an actual error to a minimal test case (PR84539). I wasn't going to bother reporting it (it seems a bit too silly

[Bug fortran/83118] [7/8 Regression] Bad intrinsic assignment of class(*) array component of derived type

2018-02-23 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #4 from Neil Carlson --- Note that if the sourced allocation in the comment 0 test case allocate(x%v,source=['foo','bar']) is replaced by the equivalent (I think) assignment x%v = ['foo','bar'] Then the code produces a run tim

[Bug fortran/84539] ICE and segfault with assignment to CLASS(*) array

2018-02-23 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84539 --- Comment #1 from Neil Carlson --- And same example but using character data. This compiles but gives a segfault when run at the assignment statement. class(*), allocatable :: x(:) x = ['foo','bar'] select type (x) type is (character(*)) if

[Bug fortran/84539] New: ICE and segfault with assignment to CLASS(*) array

2018-02-23 Thread neil.n.carlson at gmail dot com
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- Here are some issues with array assignment to an allocatable CLASS(*) array using the current 8.0 trunk. class(*), allocatable :: x(:) x = [4,2] select type (x

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

2018-02-23 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213 Neil Carlson changed: What|Removed |Added Version|4.7.0 |8.0.1 --- Comment #26 from Neil Carlson

[Bug fortran/69563] Generic TBP incorrectly resolves to elemental

2018-02-23 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69563 Neil Carlson changed: What|Removed |Added Version|6.0 |8.0.1 --- Comment #2 from Neil Carlson -

[Bug fortran/79072] ICE with class(*) pointer function result and character value

2018-02-21 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072 --- Comment #22 from Neil Carlson --- I just verified with 8.0 trunk (r257868) that all three of my examples continue to work as expected.

[Bug fortran/84432] [F08] Detect illegal component initialization in pdt_27.f03

2018-02-18 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84432 Neil Carlson changed: What|Removed |Added CC||neil.n.carlson at gmail dot com

[Bug fortran/82996] ICE and segfault with derived type finalization

2018-02-17 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996 --- Comment #9 from Neil Carlson --- With today's version (r257782) I'm still seeing the same thing Dominique reported in comment 7, except that there is no longer any abort -- the programs terminate successfully (0 exit code) despite the reporte

[Bug fortran/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

2018-02-16 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381 --- Comment #5 from Neil Carlson --- Thomas, I saw you generated a patch with "stop n". I'd love to see how you did it -- the regexp and counting magic.

[Bug testsuite/84381] replace non-std 'call abort' by 'stop 1' in gfortran testsuite

2018-02-14 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381 Neil Carlson changed: What|Removed |Added CC||neil.n.carlson at gmail dot com

[Bug fortran/84218] ICE in free_expr0, at fortran/expr.c:451

2018-02-07 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84218 Neil Carlson changed: What|Removed |Added CC||neil.n.carlson at gmail dot com

[Bug fortran/84122] Incorrect statement sequence in PDT definition

2018-02-03 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84122 --- Comment #3 from Neil Carlson --- Here's a related invalid example that gfortran accepts: module mod type foo(dim) integer,len,public :: dim integer :: array(dim) end type end module PUBLIC/PRIVATE attributes are not valid attributes for

[Bug fortran/84189] Internal procedure allowed as type bound procedure

2018-02-02 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84189 Neil Carlson changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|---

[Bug fortran/84189] New: Internal procedure allowed as type bound procedure

2018-02-02 Thread neil.n.carlson at gmail dot com
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- C465 (F08) prohibits an internal procedure from being a type bound procedure, but gfortran mistakenly allows it when the TPB has the NOPASS attribute. The

[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters

2018-01-31 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143 --- Comment #2 from Neil Carlson --- (In reply to Dominique d'Humieres from comment #1) > > gives 0. Should not it be 3? Yeah. I noticed the same thing myself. It is 3 if the type parameters are removed. I was intending to report it, but I th

[Bug fortran/84143] New: Intrinsic output of PDT incorrectly includes type parameters

2018-01-30 Thread neil.n.carlson at gmail dot com
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- In the continuing theme of the PDT implementation incorrectly regarding type parameters as components (see PR84119, PR84120, PR84122

[Bug fortran/84120] Syntax for used for PDT constructors is incorrect

2018-01-30 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84120 --- Comment #1 from Neil Carlson --- This explains the problem underlying PR82205

[Bug fortran/84122] New: Incorrect statement sequence in PDT definition

2018-01-30 Thread neil.n.carlson at gmail dot com
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- Here's yet another case of where the PDT implementation has not correctly distinguished derived type parameters from the components of the type. (c.f. PR8411

[Bug fortran/84120] New: Syntax for used for PDT constructors is incorrect

2018-01-29 Thread neil.n.carlson at gmail dot com
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- Consider the PDT type foo(dim) integer,len :: dim integer :: array(dim) end type While investigating how other compilers do on the gfortran testsuite programs

[Bug fortran/84119] New: Type parameter inquiry for PDT returns array instead of scalar

2018-01-29 Thread neil.n.carlson at gmail dot com
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- There seems to be a misconception in the implementation of PDT that the type parameters are (in part) just regular components of the

[Bug fortran/84093] Invalid nested derived type constructor not rejected

2018-01-29 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84093 --- Comment #2 from Neil Carlson --- The forced cascade of keyword use is rather annoying, so perhaps someone was thinking the current gfortran behavior is a useful extension, and it almost is. But consider this example: type :: parent type(pa

[Bug fortran/84093] New: Invalid nested derived type constructor not rejected

2018-01-28 Thread neil.n.carlson at gmail dot com
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- Gfortran allows invalid nested derived type constructors. Consider this example: type parent integer :: a, b end type type, extends(parent) :: child real

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

2017-12-26 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149 --- Comment #7 from Neil Carlson --- Perhaps this modification of comment 2 code is clearer. Put this in one file: module mod1 integer :: ncells end module module mod2 contains function get() result(array) use mod1 real array(ncell

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

2017-12-26 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149 --- Comment #5 from Neil Carlson --- I disagree (in part) with comment 4. Ncells is a valid specification statement (see 7.1.11, par 2 (4), Fortran 2008). Its value need not be known at compile time; only when the get() function is executed. I

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

2017-11-24 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149 --- Comment #3 from Neil Carlson --- Unlike comment 0 code, comment 2 code also gives an ICE with 7.2.1 and 6.4.1

[Bug fortran/83149] [8 Regression] ICE on SELECT CASE: crash_signal in toplev.c:325

2017-11-24 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83149 --- Comment #2 from Neil Carlson --- Here's another example. The ICE is coming at the same place, toplev.c:325, so I think it may be the same underlying problem. Like the original example, the ICE occurs only when the main program is in a separ

[Bug fortran/83149] New: ICE on SELECT CASE: crash_signal in toplev.c:325

2017-11-24 Thread neil.n.carlson at gmail dot com
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- The current 8.0 trunk gives an ICE on the following example, but only when then the program units are in two separate files. Works fine with 7.2.1 and 6.4.1. module

[Bug fortran/79929] [7/8 Regression] Bogus Warning: '__builtin_memset': specified size 4294967291 exceeds maximum object size 2147483647

2017-11-24 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929 Neil Carlson changed: What|Removed |Added CC||neil.n.carlson at gmail dot com

[Bug fortran/83148] New: [7.2 regression] ICE: crash_signal from toplev.c:325

2017-11-24 Thread neil.n.carlson at gmail dot com
Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- The following example gives an ICE with the current 8.0 trunk, but not with 7.2.1 or 6.4.1. module fhypre use iso_c_binding, only: c_ptr, c_null_ptr use

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

2017-11-24 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213 --- Comment #25 from Neil Carlson --- Here's another example similar to those above but even simpler IMHO and involving a CLASS(*) pointer component type box class(*), pointer :: uptr => null() end type integer, target :: n call sub(box(n)) co

[Bug fortran/49213] [OOP] gfortran rejects structure constructor expression

2017-11-24 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213 --- Comment #24 from Neil Carlson --- Ping. This bug has been around for over 6 years now.

[Bug fortran/83146] ICE on SELECT CASE statement with associate name

2017-11-24 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83146 --- Comment #2 from Neil Carlson --- Turns out you don't need anything at all in the associate block to get an ICE: type foo integer n end type type bar type(foo) array(2) end type type(bar) b associate (n_array => b%array%n) end associate e

[Bug fortran/83146] ICE on SELECT CASE statement with associate name

2017-11-24 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83146 --- Comment #1 from Neil Carlson --- I thought that assigning the select case expression to a temporary integer and using that variable in the select case statement would be a workaround, but no. You can put anything unrelated to the associate na

[Bug fortran/83146] New: ICE on SELECT CASE statement with associate name

2017-11-24 Thread neil.n.carlson at gmail dot com
: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- The current 8.0 trunk gives an ICE on the following example. 6.4.1 also gives an ICE. type foo integer n end type type bar type(foo) array(2) end type type(bar

[Bug fortran/83118] Bad intrinsic assignment of class(*) array component of derived type (8.0 regression)

2017-11-22 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #1 from Neil Carlson --- Note that the incorrect string "b" is not actually 1 character long, but 3 characters: a "b" followed by 2 non-printing characters. Vim shows them as ^@

[Bug fortran/83118] New: Bad intrinsic assignment of class(*) array component of derived type (8.0 regression)

2017-11-22 Thread neil.n.carlson at gmail dot com
Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- Intrinsic assignment of a derived type with allocatable CLASS(*) array component is not being done correctly

[Bug fortran/79072] ICE with class(*) pointer function result and character value

2017-11-22 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072 --- Comment #19 from Neil Carlson --- This fixes the code of comment 12 for me. All the other test cases continue to work as expected. This can be closed as "fixed" as far as I'm concerned. Thanks Paul!

[Bug fortran/79072] ICE with class(*) pointer function result and character value

2017-11-20 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072 --- Comment #16 from neil.n.carlson at gmail dot com --- I've confirmed Dominique's findings: Code in comments 0, 5, 11 are working now with Paul's commit (Thanks!), but comment 12 code still gives an ICE. Should I create a

[Bug fortran/79072] ICE with class(*) pointer function result and character value

2017-11-18 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072 --- Comment #13 from neil.n.carlson at gmail dot com --- Correction to Comment 11. That example gives the *correct* result on 6.4.1

[Bug fortran/79072] ICE with class(*) pointer function result and character value

2017-11-18 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072 --- Comment #12 from neil.n.carlson at gmail dot com --- The second adds a select case and print to get at the result value before its handed back. This produces an ICE with 6.4.1, 7.2.1, and 8.0.0 (20171028) character(3), target :: a = 

[Bug fortran/79072] ICE with class(*) pointer function result and character value

2017-11-18 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79072 --- Comment #11 from neil.n.carlson at gmail dot com --- Paul, I'm organizing all my bug report examples, and ran across these two test cases from September that I can't find I ever reported. They are VERY similar to the original

[Bug fortran/82996] ICE and segfault with derived type finalization

2017-11-16 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996 --- Comment #8 from neil.n.carlson at gmail dot com --- > If I remove 'elemental' for 'subroutine foo_destroy', the segfault is gone. In that case the final procedure doesn't match the array component and wouldn

[Bug fortran/83012] New: Simply contiguous pointer function not recognized as contiguous

2017-11-15 Thread neil.n.carlson at gmail dot com
Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- In the following example the pointer assignment "p => x%dataptr()" is rejected because the compiler does not recognize

[Bug fortran/82996] ICE and segfault with derived type finalization

2017-11-15 Thread neil.n.carlson at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82996 --- Comment #5 from neil.n.carlson at gmail dot com --- I've built the svn trunk and tested the examples with it. The ICEs with the comment 2 and 3 examples are gone, as Dominique found. The comment 1 example continues to segfault when exe

  1   2   >