https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88455
--- Comment #2 from Adam Hirst ---
Slightly reduced - the issue occurs even in the MAIN program:
program test
implicit none
integer :: a, b, c
character(:), allocatable :: line(:)
a = 1; b = 10; c = 30
allocat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88455
--- Comment #1 from Adam Hirst ---
I'm not sure whether they're related, but I found a handful of
potentially-similar bugs, which might be worth collating here for quicker
reference.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28660
https://gcc
: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: adam at aphirst dot karoo.co.uk
Target Milestone: ---
program test
implicit none
call F(1, 10, 30)
contains
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83927
--- Comment #3 from Adam Hirst ---
In reference to my initial attachment 43173, and by adding the following
annotations:
```
! case 1
M = v_array_par(1)%MyFunc()
print *, M
! case 2
M = v_scalar_par%MyFunc()
print *, M
! case 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58750
--- Comment #19 from Adam Hirst ---
Apologies for the excess traffic. I realised my error soon after posting. I'll
try to be patient until I have GCC8 "release" on my system before I follow up
any similar issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58750
--- Comment #17 from Adam Hirst ---
I'm afraid to say that this issue is, in fact, not solved.
[235
7 11 ]
5
[0 ]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83927
--- Comment #2 from Adam Hirst ---
I don't think this is a duplicate of pr59298 because, unlike pr59298, this
doesn't cause an ICE.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: adam at aphirst dot karoo.co.uk
Target Milestone: ---
Created attachment 43173
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43173&action=edit
short program demonstrat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298
--- Comment #8 from Adam Hirst ---
After another year, the issue still seems present. ICE when compiling the file
I attached, and Janus' reduced case.
The removal of the parenthesis still has the effect of avoiding the ICE.
Using built-in specs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79930
--- Comment #12 from Adam Hirst ---
Created attachment 40940
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40940&action=edit
call graph of my "real" application
Thanks Thomas,
My "real" application is of course not using random numbers f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79946
--- Comment #2 from Adam Hirst ---
Just for clarification: is this only occuring for the case where one does
Dx = D%x
tmp = matmul(NU,Dx);
tensorproduct%x = dot_product(tmp,NV)
or is it also applicable to
tmp = matmul(NU,D%x);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79930
--- Comment #8 from Adam Hirst ---
Ah, it seems that Jerry was tinkering with tp_array.f90 (intrinsic array
version of the Vector type), while I was with tp_xyz.f90 (explicit separate
elements). I was going to remark at how he didn't need to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79930
--- Comment #7 from Adam Hirst ---
OK, I tried a little harder, and was able to get a performance increase.
type(Vect3D) pure function TP_LEFT(NU, D, NV) result(tensorproduct)
real(dp), intent(in) :: NU(4), NV(4)
type(Vect3D), inte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79930
--- Comment #5 from Adam Hirst ---
Hmm, even with -Ofast, I don't get any noticeable performance increase if I
change, say, TP_LEFT, to be:
type(Vect3D) pure function TP_LEFT(NU, D, NV) result(tensorproduct)
real(dp), intent(in) :: NU(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79930
--- Comment #3 from Adam Hirst ---
Created attachment 40898
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40898&action=edit
Implementation using dimension(3) member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79930
--- Comment #2 from Adam Hirst ---
Created attachment 40897
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40897&action=edit
Implementation using %x %y and %z members
Will post the source code here as attachments.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: adam at aphirst dot karoo.co.uk
Target Milestone: ---
In my codebase I'm performing many "Tensor Products", which is by far the
hottest routine. This is something like
tp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79676
--- Comment #2 from Adam Hirst ---
Could this be related? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52846#c14
> Paul Thomas 2015-07-16 14:52:58 UTC
> OK - this compiles and runs if the PRIVATE statement is removed. As soon as I
> return to t
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: adam at aphirst dot karoo.co.uk
Target Milestone: ---
Demonstration code:
https://gist.github.com/aphirst/aacfe1eb5eda1151364ddbf2feef5ed3
Build log:
http://sprunge.us/iYaP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298
--- Comment #7 from Adam Hirst ---
It's been almost a year, and I wanted to confirm that this bug is still present
for the test case I attached to the thread, and for Janus' reduced example.
Also relevant might be that my comment at 2014-11-12 13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58861
--- Comment #5 from Adam Hirst ---
It's been over a year, and I can confirm that this bug is present for all 3
examples in this thread, in the following version:
gcc (GCC) 6.2.1 20160830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58750
--- Comment #11 from Adam Hirst ---
It's been almost another year, and I just wanted to confirm that this bug is
still present in the following version:
GNU Fortran (GCC) 6.2.1 20160830
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298
--- Comment #6 from Adam Hirst ---
As with another bug I keep in my Bookmarks, I just decided to check this again
and it seems that in 5.2.0 we're still getting the same behaviour.
$ gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58750
--- Comment #10 from Adam Hirst ---
It's been another year, and I would like to confirm that this behaviour is
indeed still present for me in 5.2.0, and adding _i8 as Tobias pointed out
still does cause correct code to result.
$ gfortran -v
Usin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298
--- Comment #5 from Adam Hirst ---
I decided to check on the status of this bug in 4.9.2, as it's been a little
while, and the segmentation fault still occurs.
Interestingly, the test case that Janus posted on 2013-01-03 can be made to
compile a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58750
--- Comment #9 from Adam Hirst ---
As it's been over a year since the last update, I just thought I'd ping back
with the comment that this bug is still present in 4.9.2.
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: adam at aphirst dot karoo.co.uk
Created attachment 32885
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32885&action=edit
demonstration of ICE for ASSOCIATE with array literal
Association of a na
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58861
Adam Hirst changed:
What|Removed |Added
CC||adam at aphirst dot karoo.co.uk
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59298
Adam Hirst changed:
What|Removed |Added
Attachment #31294|0 |1
is obsolete|
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: adam at aphirst dot karoo.co.uk
Created attachment 31294
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31294&action=edit
Minimal te
30 matches
Mail list logo
