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
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
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:
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
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.
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'm sti
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #9 from Neil Carlson ---
Bug is still present in 13.2.0.
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!
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://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
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.
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110033
--- Comment #1 from Neil Carlson ---
This must be related to PR78152
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
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
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
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 :-)
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
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
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
: 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
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.
: 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
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
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
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
: 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
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.
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
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.
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566
Neil Carlson changed:
What|Removed |Added
CC||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
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
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.
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 "" (like I was expecting/hoping when I started experimenting
with the original example). 13.11.3.1 says
1
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
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,
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
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 =
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),
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
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
: 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 'b
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118
Neil Carlson changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|DUPLICATE
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
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
+++
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
+++
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
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
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
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
: 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
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
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
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
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
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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84432
Neil Carlson changed:
What|Removed |Added
CC||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
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84381
Neil Carlson changed:
What|Removed |Added
CC||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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84189
Neil Carlson changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
: 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
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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84120
--- Comment #1 from Neil Carlson ---
This explains the problem underlying PR82205
: 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. PR84119
: 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
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
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
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
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
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.
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
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
: 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79929
Neil Carlson changed:
What|Removed |Added
CC||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
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))
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.
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
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
: 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
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 ^@
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
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!
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 new PR
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
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 = 'foo
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 example I
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't
be called. I susp
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
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 executed
1 - 100 of 137 matches
Mail list logo
