Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: liakhdi at ornl dot gov
Target Milestone: ---
Created attachment 47304
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47304&action=edit
Complete reproducer of the reported ICE
There is a regress
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587
--- Comment #2 from DIL ---
Created attachment 47742
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47742&action=edit
Updated ICE reproducer
Fixed build issues for gfortran-8. Builds with gfortran-8.x but produces ICE
with gfortran-9.x.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587
--- Comment #3 from DIL ---
(In reply to Martin Liška from comment #1)
> For older GCC 8 I see:
>
> tensor_recursive.F90:738:36:
>
> private TensBodyGetDataDescr
> 1
> Error: Symbol ‘tensbodygetdatad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587
--- Comment #4 from DIL ---
Sorry, I was removing unnecessary dependencies in order to reduce the
reproducer source size, but forgot to remove PRIVATE declaration for the
deleted procedures. Now fixed. It builds with gfortran-8.x but produces ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587
--- Comment #5 from DIL ---
If this helps, the gcc/gfortran svn repository from 17 Jan 2019 already had
this regression bug while gcc/gfortran 8.2.0 did not. Hopefully this may help
shorten the length of bisection.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587
--- Comment #7 from DIL ---
Please download the Updated ICE reproducer as I explain in the comments above
(the reproducer archive uploaded 2020-01-30). It builds with gcc/8.x just fine,
but causes ICE in gfortranc/9.x. As I mentioned, this ICE sh
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: liakhdi at ornl dot gov
Target Milestone: ---
Code: https://github.com/DmitryLyakh/GFC.git
To reproduce: Open Makefile, make line 138 look exactly like line 140:
NO_GNU := -DNO_GNU
Type "make"
If you need a debuggab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515
--- Comment #2 from DIL ---
For GFORTRAN 6.4.0 and earlier, the relevant compiler bug has been fixed in
78300.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515
--- Comment #5 from DIL ---
(In reply to Thomas Schwinge from comment #4)
> (In reply to DIL from comment #2)
> > For GFORTRAN 6.4.0 and earlier, the relevant compiler bug has been fixed in
> > 78300.
>
> Are you saying that the exact same bug r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515
--- Comment #6 from DIL ---
(In reply to Thomas Schwinge from comment #4)
> (In reply to DIL from comment #2)
> > For GFORTRAN 6.4.0 and earlier, the relevant compiler bug has been fixed in
> > 78300.
>
> Are you saying that the exact same bug r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515
--- Comment #11 from DIL ---
(In reply to Dominique d'Humieres from comment #10)
> With the patch in comment 8 all the tests compile and the original test in
> comment 0 gives ta runtime
>
> gfc::bank testing status:0 (PASSED): Perf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515
--- Comment #14 from DIL ---
(In reply to anlauf from comment #13)
> (In reply to Dominique d'Humieres from comment #12)
> > > Sorry, I am confused, I think Comment 1 already has such a reduced test.
> > > At least the what it says there ...
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83515
--- Comment #20 from DIL ---
(In reply to anlauf from comment #19)
> Fixed on trunk and all open branches (7/8).
>
> Closing, as no reduced run-time testcase was provided.
> Please reopen or create a new PR if an issue is found.
>
> Thanks for
: unassigned at gcc dot gnu.org
Reporter: liakhdi at ornl dot gov
Target Milestone: ---
It seems like something is seriously wrong with GFORTRAN 7.x virtual table
constructor. I observe an incorrect association of type-bound procedures to
their calling names. For example, in
procedure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850
--- Comment #11 from DIL ---
The additional problem you observe with gfortran/7.1 described in the comment
"2017-05-26 22:43:21 UTC" seems to be another gfortran compiler bug introduced
in GCC/7.0. I have just filed a bug report for it (#81758).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758
--- Comment #2 from DIL ---
No, at this point I do not, unfortunately. These OOP bugs tend to show up at
higher levels, so it is not always clear how to reduce it to something small. I
will try to reduce it to something smaller, but not sure how
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850
--- Comment #12 from DIL ---
Could you please tell me if there is a way I can check whether the dissociated
unlimited polymorphic pointer (class(*), pointer), which is set to NULL, is
indeed set to a clean state internally? That is, could you ple
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79311
--- Comment #10 from DIL ---
Thanks for fixing.
: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: liakhdi at ornl dot gov
Target Milestone: ---
Hello,
Code repo:
https://gitlab.com/DmitryLyakh/GFC
Build:
Type make.
Problem (bug):
Please run the binary test_gfc.x 5-10 times (it is quick). On my Ubuntu laptop
some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850
--- Comment #2 from DIL ---
I have fixed all issues reported by VALGRIND so the code now is valgrind-clean.
However, the problem I reported still shows up from time to time (only when the
code is compiled with -g and no optimization: BUILD_TYPE =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850
--- Comment #4 from DIL ---
Offset of zero is fine. I have never observed this SegFault before. I ran the
test on multiple machines with GCC/5.3.0, GCC/5.4.0, and GCC/6.3.1. Also, as I
mentioned before, the test passed the VALGRIND check. Would y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850
--- Comment #10 from DIL ---
Sorry, just wanted to clarify few things. I am still struggling with this issue
I reported. However I am not sure if you could every reproduce it (it seemed
like you observed a different issue)? Namely, if by running
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: liakhdi at ornl dot gov
Target Milestone: ---
Created attachment 40641
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40641&action=edit
Source reproducer
Below is the GFORTRAN internal compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758
--- Comment #5 from DIL ---
Created attachment 42373
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42373&action=edit
Debugger screenshot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758
--- Comment #7 from DIL ---
P.S. I do not have GCC-8.0 installed anywhere.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758
--- Comment #6 from DIL ---
It is not that I am not willing to, I just do not see an easy way to reduce the
relevant code. For now, I have attached a debugger screenshot (jpg above) to
show you the details of the problem. The segfault occurs when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758
--- Comment #10 from DIL ---
(In reply to Thomas Koenig from comment #9)
> I just checked on powerpc64 with a rather current trunk with
>
> gfc::bank testing status:0 (PASSED): Performance:
> 2888199.6889235629
> gfc::vecto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758
--- Comment #16 from DIL ---
Hi Paul,
Thanks for looking into this issue. I ran the debugger again. The vtab
corruption occurs upon the first encounter in function VectorIterElement() in
line 720 of gfc_vector.F90. Just to make sure, that line b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758
--- Comment #19 from DIL ---
Hi Paul,
Great, thanks a lot! That was pretty quick. Upon a chance, as there is still a
momentum :), could you please take a brief look at bug #80850 to see whether it
may be related since you mentioned "allocation w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81758
--- Comment #21 from DIL ---
Greatly appreciate!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850
--- Comment #19 from DIL ---
On my Ubuntu 16.04, removing STAT= from the allocate() statement does not help
unfortunately, but it now crashes via a different path, although for the same
reason. I will experiment more to see if I can finally repro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850
--- Comment #20 from DIL ---
So, if we for a second trust valgrind executed on an -O3 optimized binary, then
line 1402 of gfc_graph.F90, namely,
ierr=git%append_vertex(vrt)
should be the origin. The object vrt (type graph_vertex_t) is the object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850
--- Comment #21 from DIL ---
Paul,
And as you have noticed, this characteristic construct is there
(gfc_vector:806) :)
call
this%container%vec_tile(q(4))%tile_batch(q(3))%batch_seg(q(2))%seg_elem(q(1))%&
&vector_elem_ctor(elem_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850
--- Comment #22 from DIL ---
On the other hand, I have another test which also crashes in clone_object() for
the same reason, but does not involve gfc_vector.F90. It goes through line 710
of gfc_list.F90, function ListIterAppend(), where again a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850
--- Comment #23 from DIL ---
Paul,
Great work! Thanks a lot for fixing this. This bug was a stopper for me for 6
months, so I am really looking forward to fully switching back to my favorite
gcc/gfortran compiler :)
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: liakhdi at ornl dot gov
Target Milestone: ---
Source code: https://gitlab.com/DmitryLyakh/GFC.git
The minimal reproducer can be created by taking only three source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300
--- Comment #2 from DIL ---
Created attachment 40017
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40017&action=edit
Source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300
--- Comment #3 from DIL ---
Created attachment 40018
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40018&action=edit
Source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300
--- Comment #4 from DIL ---
Created attachment 40019
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40019&action=edit
Source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300
--- Comment #8 from DIL ---
Is there a way to download the GCC source with this patch applied?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300
--- Comment #10 from DIL ---
Thanks!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78300
--- Comment #12 from DIL ---
Indeed, thanks again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587
--- Comment #17 from DIL ---
Thanks for fixing this!
43 matches
Mail list logo
