: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
Created attachment 48734
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48734&action=edit
Test progr
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
Created attachment 49351
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49351&action=edit
program that reprodu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97380
--- Comment #2 from federico ---
I have an update:
if I remove the ELEMENTAL property from the assignment routines, I get this
error in both the PACK and the array assignments:
Error: Nonallocatable variable must not be polymorphic in intrins
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
Created attachment 49383
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49383&action=edit
Test program
Hi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97380
--- Comment #3 from federico ---
Created attachment 49392
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49392&action=edit
Other test program highlights issue in accessing polymorphic arrays with arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97380
--- Comment #4 from federico ---
I've attached another program that perhaps highlights the problem better.
Even just *accessing* a polymorphic array with an array causes wrong output
with gfortran 9.2.0:
The attached program sends elements [3,
mal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
Created attachment 49898
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49898&action=edit
test program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98558
federico changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59202
federico changed:
What|Removed |Added
CC||federico.perini at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59202
--- Comment #4 from federico ---
The self-assignment issue is present even if the derived type has no
allocatable components. Here is a sample test program that gives an error with
gfortran 10.2.0:
module assign
implicit none
pr
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
Consider the following tiny program:
program test_huge
use iso_fortran_env, only: int8
integer(int8) :: i
do i=-huge(i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108431
federico changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
Hello gfortran/gcc team,
I've reduced my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109076
--- Comment #2 from federico ---
Sorry I meant it does not compile what I think is valid code:
subroutine i_expand matches the given abstract interface exactly, I can't find
a shape mismatch. I wound two ways that will make the error go away:
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
Created attachment 52627
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52627&action=edit
test program
A low priority bug, I guess.
The following inval
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104927
federico changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
A derived type that has user-defined I/O causes ICE on all gfortran versions 7
to 12.1.0, whenever it's being used as an automatic object.
The error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
--- Comment #2 from federico ---
For the sake of completeness, fixed-size does not cause an ICE:
type(t) :: fixed(5) ! works
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
--- Comment #4 from federico ---
The TREE_STATIC assert should be valid according to what reported in the
implementation at report https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48298
But, I can't tell what that means.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
--- Comment #6 from federico ---
Yeah this popped up playing with DTIO, this feature is not widely used
apparently. I'll also try to get a copy of the gcc source code and build
pipeline to see if I can help.
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
Running a large CFD program I've found a memory leak gfortran 9.2.0 (sorry:
unable to test other versions on
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
I'm getting an ICE using the PACK intrinsic from within a polymorphic e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106771
--- Comment #3 from federico ---
Right: here is a version where the object is initialized:
https://godbolt.org/z/o566cPG8P
I also see that for the versions that compile (e.g., 11.1.0), there's a weird
SEGFAULT error at this line:
eleme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106771
--- Comment #5 from federico ---
My bad, the SEGFAULT is my mistake, I've made a half-baked example that does
not work. Here's the fixed one:
module test
implicit none
type::t
integer, allocatable :: iloc(:)
contains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106750
--- Comment #3 from federico ---
Thank you for checking this.
So if I make the temporary array explicit, the leak goes away.
In the case of the example i.e. 1) fixed-size and 2) very few elements are
passed to the routine, it seems it would j
NCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
I'm getting a weird SIGSEV error when running the following code with full
optimization (-O3)
y: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
I'm in trouble reducing this problem to a minimum viable example, so I'm asking
for help - I have a nested derived type that contains allocat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107362
federico changed:
What|Removed |Added
CC||federico.perini at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107362
--- Comment #4 from federico ---
OK I will report a new bug.
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
I'm getting the same issue on a recursive tree structure.
I see a segfault in the default finaliz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
--- Comment #11 from federico ---
Thank you.
I can confirm the patch works.
I thought that, while fixing the issue, removing the assert was not the best
solution as automatic arrays are not supposed to be static. My bad.
Happy holidays,
Fe
: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
Created attachment 52950
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105558
--- Comment #2 from federico ---
Ok so we have:
gfortran | [...] -fno-tree-vectorize | [...] -fno-vect-cost-model
10.3 |OK | ERROR
9.3 |OK | ERROR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105558
--- Comment #3 from federico ---
-fno-vect-cost model also does not change behavior on gcc 11/7/6/5 (all OK)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78492
--- Comment #5 from federico ---
Created attachment 53145
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53145&action=edit
test program: call non_overridable function from generic interface within
polymorphic procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78492
--- Comment #6 from federico ---
I've attached a simple test program that confirms ICE on gfortran 11.3.0.
ICE is returned only if
- the non_overridable procedure is part of a generic type-bound interface
- that same generic is being called from
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
Created attachment 53321
--> https://gcc.gnu.org/bugzi
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
Created attachment 51251
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51251&action=edit
test prog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101757
--- Comment #1 from federico ---
Actually, the results are not "off-seted": whatever was to be set to 0 is
properly set; values that should be set "+1" are given "-1" instead:
itest(1)= 0 itest(2)=-1
test(1)= F test(2)= T
Federico
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101757
--- Comment #2 from federico ---
Tested on godbolt.org:
https://godbolt.org/z/sPsdE6Y3W
works on: 5.5, 6.3, all 10, all 11
error on: all 7, all 8, all 9
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
Test program:
```
module v
public :: with_allocatable
type, public :: t
real :: r
contains
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
Created attachment 58464
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58464&action=edit
Finalization test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78492
--- Comment #8 from federico ---
Amazing, thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114023
federico changed:
What|Removed |Added
CC||federico.perini at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105558
--- Comment #10 from federico ---
Hi Sam,
Thanks for looking into it - here is a simplified version of the test program:
you can also test it live at the Compiler Explorer, at this link:
https://godbolt.org/z/r63G348hM
Thanks,
Federico
modul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118580
--- Comment #3 from federico ---
Sorry, I introduced a typo while editing the post.
Here is a slightly shorter version of the sample:
```
program complex_eye
implicit none
integer, parameter :: k = 2
integer :: j
complex, dimension(k,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118580
--- Comment #7 from federico ---
Thanks Harald and Steve, great hints. Looking at the `-fdump-tree-original`, I
see:
- the on-the-fly expression seems the difference between a complex(8) and a
complex(4) expressions:
```
__builtin_cabs ( COMP
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
Sample program:
```
program complex_eye
implicit none
integer, parameter :: dp = kind(0.d0)
integer, parameter :: sp = kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119106
--- Comment #1 from federico ---
The `-fdump-tree-original` seems to highlight that:
The `save`d variable data is accessed with unrolled indices
[...] = n[(integer(kind=8)) i[0] + -1][1]{lb: 1 sz: 1};
The `parameter` variable data is access
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: federico.perini at gmail dot com
Target Milestone: ---
Created attachment 60649
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60649&action=ed
50 matches
Mail list logo
