https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89069
--- Comment #3 from Antony Lewis ---
This bug is still valid as of gcc 11.2.1 20220114
15 | end module test
| 1
internal compiler error: Segmentation fault
0x160a5b7 internal_error(char const*, ...)
???:0
0x764849
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103942
--- Comment #1 from Antony Lewis ---
Also broken in 9.4.1 20220107.
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
The code works as expected in 9.3.1 20200614. In 10.3.1 20220107 and trunk it
gives
Program received signal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390
--- Comment #10 from Antony Lewis ---
I think you are right, it does not seem to fix it.
I made
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103898
(may also be duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103391)
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
For full log see
https://app.travis-ci.com/github/cmbant/CosmoMC/jobs/552809686.
The relevant stack trace is
[ 94/125] Processing src/bflike/long_intrinsic_smw.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103390
--- Comment #7 from Antony Lewis ---
I see similar error in another fortran code, full trace in
https://app.travis-ci.com/github/cmbant/CosmoMC/jobs/552809686
ty: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89067
--- Comment #4 from Antony Lewis ---
I agree it may be technically correct, but it is not helpful (esp. if your base
class is an empty hierarchy root class, so all derived classes in the program
would give this same error).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #20 from Antony Lewis ---
Tried trunk and gcc8, and both look good - many thanks for the fixes!
Is there no way to update 7.x? Since the buggy 7/8/9 version has also
propagated quite widely, if you know any likely workaround that mig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #12 from Antony Lewis ---
Valgrid report is
HEAP SUMMARY:
==23446== in use at exit: 40,000 bytes in 1 blocks
==23446== total heap usage: 26 allocs, 25 frees, 93,657 bytes allocated
==23446==
==23446== 40,000 bytes in 1 blocks a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #11 from Antony Lewis ---
It took ages to narrow this down, but here's a simple test case that still
gives a leak with valgrind in gcc-8 HEAD, 8.4.0, 9.3.0 (OK with 7.4.0)
module debug
implicit none
Type Tester
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #7 from Antony Lewis ---
However the reduced case of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361
now seems to be OK.
However on trunk, the fix for 94361 seems to have introduced a leak that was
not there before: https://travis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #6 from Antony Lewis ---
Thanks for looking in to it. I tried rebuilding my gcc8 docker and rerunning.
It now reports GNU Fortran (GCC) 8.4.1 20200602, however the leak still seems
to be there?
https://travis-ci.org/github/cmbant/CAM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361
--- Comment #3 from Antony Lewis ---
On Windows 8.1.0 does not leak, and on NERSC 8.3.0 20190222 (Cray Inc.) also
does not (but 9.2.0 does)... so not exactly sure what this means about when it
was introduced.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361
--- Comment #2 from Antony Lewis ---
I tried it on another system where gfortran 6.5 and 7.4.0 that don't leak, but
8.4.0 does, so in that sense at least I think it is a regression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #4 from Antony Lewis ---
Not sure why no one has at least picked up on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361
since it is a reproducible regression with a simple test case, an a bug that
effectively kills some previousl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #3 from Antony Lewis ---
Although my reduced test in the other id case is one problem, it appears that
is not the only memory leak. Someone tested else on various gcc versions and
still found:
versionmemory leak
7.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #2 from Antony Lewis ---
This may be the test case, though I'm not 100% sure:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94361
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
The code below leaks memory (mem grows with each loop interation), but does not
if the "FINAL" is commented. The issue is also present in trunk (10.0.1
20200218), an
ran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
I see an apparent memory leak introduced in running code between
ubuntu-toolchain-r/test gfortran 8.3.0 OK
Source 20200106 build gfortran 8.3.1 bad (also current 8 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90927
--- Comment #4 from Antony Lewis ---
Not sure why that rather than other dependency options, been like that for ages
(guessing: maybe because of mpif.h?).
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
ICE with version GNU Fortran (GCC) 10.0.0 20190618 compiling
https://github.com/cmbant/forutils.git
For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566
--- Comment #11 from Antony Lewis ---
I posted remaining ICE in 9.0.0 20190119 as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89069
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
Follow up to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566, seg fault ICE
with gfortran 6.5-9.0
module test
contains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89067
--- Comment #1 from Antony Lewis ---
The error message on this code
subroutine test
type x
end type
type, extends(x):: y
integer ii
end type
type(y) yy
yy%i=1
end subroutine
is
Error: 'i' at (1)
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87566
--- Comment #10 from Antony Lewis ---
In the latest 9.0 trunk I still see what looks like a similar ICE error (though
I have not tried to isolate it again). See
https://travis-ci.org/cmbant/forutils/builds/483365115
when running test script in
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
This code gives seg fault in 9.0.0 20181010 and 9.0.0 20190103, OK in 8.2.1:
(same with P pointer or allocatable)
program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88685
--- Comment #2 from Antony Lewis ---
I think the individual elements are correct, it's the array indexing operations
that are wrong (this is clearer in the longer example; looks a like wrong
stride). E.g. printing this in the main program after c
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
Created attachment 45333
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45333&action=edit
Test case
This code works in 7.3.1, but gives wrong
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
Bounds of vec2 are wrong in this example (0, 9) instead of (1, 10) as expected
(which can lead to all sorts of wrong results). Also in 6.4.
program tester
real(kind
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
Created attachment 44818
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44818&action=edit
Full test case
Segmentation fault ICE compiling with 6.4. 7.3 or 8.2.0.
sub
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
This worked for a long time in gcc 7, I think it broke in gcc 7.3 (not exactly
sure which minor version). It is also broken in gcc 8 and latest master:
gfortran -c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70748
Antony Lewis changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70748
--- Comment #2 from Antony Lewis ---
I just tried this with 7.0.0 20160603, and seems it may have been fixed?
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
Run "make Debug" on code at https://github.com/cmbant/forutils/
gfortran -cpp -ffree-line-length-none -fmax-errors=4 -MMD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69422
--- Comment #4 from Antony Lewis ---
But "source" is allocatable, not a pointer? (the pointer P is explicitly
allocated in the example)
: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
Using latest svn master branch, the follow code produces wrong results when
compiled with -O1 and higher optimizations:
program tester
character(LEN=:), allocatable :: S
S= test(2
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Target Milestone: ---
With the current svn master branch the following code prints out nothing for
'test result':
module funcs
imp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61275
--- Comment #6 from Antony Lewis ---
Not sure about that - 7.1.12 of 2008 is about constants, but in the example the
type instance is not a constant? The example is fine in ifort (and used in
cosmomc?).
Antony
> -Original Message-
> Fro
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
On trunk
module X
contains
subroutine AddCopy(C)
class(*), intent(in) :: C
class(*), pointer :: P
allocate(P, source=C)
end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64678
--- Comment #3 from Antony Lewis ---
Indeed, that's the easy workaround. I'd have thought the obvious definition for
the single multi-associate statement would be to be a shortcut exactly
equivalent to nested associates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64692
--- Comment #2 from Antony Lewis ---
May be same/related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60322
Antony Lewis changed:
What|Removed |Added
CC||antony at cosmologist dot info
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
The following code gives incorrect output in trunk ('array 1' and 'array 2'
should be the same):
module Y
contains
subroutine AddArray(P)
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
In trunk
module X
Type T
integer :: map
end Type T
contains
subroutine DoBug
Type(T) TT
associate(A=>TT, B=>A%map)
end associate
end subrouti
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
On latest trunk
module X
Type T
integer :: map
end Type T
contains
subroutine DoBug
class(T), allocatable :: Cls(:,:)
allocate(T::Cls
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
module A
Type T
character(LEN=:), allocatable :: S
end type
Type(T) :: TestObj = T('string')
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
module A
implicit none
Type T
contains
final :: testfree
end type
Type, extends(T) :: T2
real, allocatable :: Y(:)
class(T), allocatable :: XX
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
module A
implicit none
Type T
integer :: val = 2
contains
final :: testfree
end type
contains
subroutine testfree(this)
Type(T) this
print *,'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60458
--- Comment #4 from Antony Lewis ---
OK, will do. (thought the underlying cause might be same issue with associate
variables)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60458
--- Comment #2 from Antony Lewis ---
Here's a related example:
module A
implicit none
Type T
integer :: val = 2
contains
final :: testfree
end type
contains
subroutine testfree(this)
Type(T) this
pri
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
module A
Type T
contains
procedure :: Test
procedure :: TestP
end type
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
module testmod
Type T
contains
procedure :: FWrite
procedure :: FWriteArr
generic :: Write => FWrite, FWriteArr
end Type
contains
subroutine FWrite(this,X)
clas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60359
--- Comment #2 from Antony Lewis ---
This was reduced already, but actually wasn't too hard to find something much
simpler- just this:
module IO
implicit none
contains
subroutine FWRite(S)
class(*) :: S
end subroutine F
erity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Created attachment 32226
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32226&action=edit
Source and makefile
make getdist
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
This valid F2008 code is rejected:
module testmod
Type A
integer :: X = 1
integer, allocatable :: y
end type A
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60255
--- Comment #5 from Antony Lewis ---
The patch generated a SIGSEGV in test code (which works with ifort), but could
be another unrelated issue.
Here's another simple test case for the original issue:
program test
character(LEN=:), allocata
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60334
--- Comment #2 from Antony Lewis ---
I looked for a while for a reproducible crash, which wasn't easy - mostly
behaviour was errratic crashes - I was using 4.9 trunk from a week ago. But
there was definitely a general problem with the code generat
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
This compiles OK
program tester
implicit none
character(LEN=:), pointer :: Y
character(LEN=0), target :: Empty_String = ''
Y => test()
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
class(*), pointer :: P
allocate(character(5)::P)
gives error
Error: Allocating p at (1) with type-spec requires
: UNCONFIRMED
Severity: major
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Created attachment 32157
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32157&action=edit
OOP modu
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Not really a bug, but ifort (and also going back, CVF) allow a clean array
initialization sytnax like this
integer :: indices(3)
indices=[3:5]
as an alternative to the ugly
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Created attachment 32146
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32146&action=edit
OOP module implementing lists of arrays of objects (wit
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
module defining inherited class
module Samples
use ObjectLists
implicit none
Type, extends(TObjectList):: TSampleList
contains
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
SampleTest.f90 containing
module Objects
Type TObjectList
contains
procedure :: Add1
procedure :: Add2
generic :: Add => Add1, Add2
end Type TObjectList
end module Objects
gives
gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59414
--- Comment #5 from Antony Lewis ---
Thanks for the quick fix!
The sourced allocate errors crop up in various places in the full code, and
already seem to be known in several bug reports, e.g.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44672
Fo
Severity: blocker
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: antony at cosmologist dot info
Created attachment 31394
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31394&action=edit
OOP module implementing l
nassigned at gcc dot gnu dot org
ReportedBy: antony at cosmologist dot info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35470
69 matches
Mail list logo
