https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54070
--- Comment #31 from neil.n.carlson at gmail dot com ---
Sorry, ignore the example of comment 30. I had already reported this in PR
67564 (not a duplicate of this one). I'm getting old ...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786
Summary: Relational operators .eq. and == are not recognized as
equivalent
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786
--- Comment #2 from neil.n.carlson at gmail dot com 2010-09-25 00:27:24 UTC ---
Note also that the problem isn't restricted to .eq./== ; it appears to occur
with all the other pairs of equivalent operators: .ne./!=, .lt./<, etc. At
l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45794
Summary: internal compiler error: Segmentation fault
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
Summary: [OOP] gfortran rejects structure constructor
expression
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45786
--- Comment #7 from neil.n.carlson at gmail dot com 2011-05-28 18:14:04 UTC ---
So what is the status of this defect? It would appear to be "will not fix".
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #3 from neil.n.carlson at gmail dot com 2011-06-16 20:35:48 UTC ---
(In reply to comment #1)
> Note: Intrinsic assignments to polymorphic variables are forbidden [...]
This was really about the structure constructor; the assignm
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #4 from neil.n.carlson at gmail dot com 2011-06-16 20:49:32 UTC ---
An intuitive way of viewing (and maybe even implementing I guess) the process
triggered by a structure constructor is as a sequence of assignment statements
for the
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #6 from neil.n.carlson at gmail dot com 2011-06-16 22:12:17 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > An intuitive way of viewing (and maybe even implementing I guess) the
> > process
> > tri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49213
--- Comment #7 from neil.n.carlson at gmail dot com 2011-06-16 22:18:14 UTC ---
I want to emphasize again that the error I wanted to report was that gfortran
is rejecting valid structure constructor expressions (see comment 3). It looks
from you
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
The following example triggers an ICE with gfortran 6.1.0:
subroutine ice_example
type :: inner
integer :: n
end type
type :: outer
type(inner), allocatable
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
: 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=100815
--- Comment #1 from Neil Carlson ---
Actually it looks like the regression was introduced in 10.3. It works in 10.2
and earlier.
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
: 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=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684
--- Comment #9 from Neil Carlson ---
Bug is still present in 13.2.0.
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
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 :-)
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
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.
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
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
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
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
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_
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
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
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: ---
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=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
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
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
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:/
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!
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(
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 compiler segfaults on the line where the imaginary
part of a complex array is passed to an
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
The following example trips a recent regression. It segfaults with 13.3.1,
14.2.1, and 15, but not with 13.3.0 or 14.2.0.
module foo
type, public :: any_matrix
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
The follow example outputs incorrect results.
program main
type :: my_type
complex, allocatable :: phi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119986
--- Comment #4 from Neil Carlson ---
(In reply to kargls from comment #3)
> Also note, that the above generates the expected temporary arrays.
A tangential question: Why is this expected? I would have naively thought that
a dope
vector with a s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994
--- Comment #1 from Neil Carlson ---
Here's a similar example using an internal subroutine. The rejected
specification expression is also valid, as again THIS is accessible by host
association.
module foo
type :: bar
integer :: n
end t
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: neil.n.carlson at gmail dot com
Target Milestone: ---
The following example is rejected with the following error:
19 | real :: array(this%n)
|1
Error: Dummy argument '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119994
--- Comment #4 from Neil Carlson ---
(In reply to kargls from comment #3)
> Note, Neil has asked on the J3 mailing list for clarification as there
> seems to be a conflict on the requirements of a restricted expression.
I think the list given i
101 - 144 of 144 matches
Mail list logo
