http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047
Bug #: 56047
Summary: [4.6 Regression] ICE in in gfc_conv_expr_op
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047
--- Comment #9 from Jürgen Reuter juergen.reuter at desy dot de 2013-01-20
11:55:31 UTC ---
Janus, long time no see! XD Greetings to my old home state!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047
--- Comment #12 from Jürgen Reuter juergen.reuter at desy dot de 2013-01-20
22:11:30 UTC ---
Am 20/1/13 1:53 PM, schrieb janus at gcc dot gnu.org:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047
--- Comment #11 from janus at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047
--- Comment #14 from Jürgen Reuter juergen.reuter at desy dot de 2013-01-21
17:28:12 UTC ---
On Monday 21 January 2013 16:34:27 you wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047
--- Comment #13 from janus at gcc dot gnu.org 2013
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047
--- Comment #15 from Jürgen Reuter juergen.reuter at desy dot de 2013-01-23
20:26:48 UTC ---
Am 23/1/13 5:25 PM, schrieb rguenth at gcc dot gnu.org:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56047
Richard Biener rguenth at gcc dot gnu.org
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
The following code produces a warning, but is valid code:
gfortran -c phs_single.f90
phs_single.f90:14.16:
call func1 (phs%decay_p ())
1
Warning: Actual argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59143
--- Comment #1 from Jürgen Reuter juergen.reuter at desy dot de ---
The problem is back in 4.8, 4.7, 4.6.
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Created attachment 31254
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31254action=edit
Code triggering the ICE
Triggers ICE with gfortran 4.9.0 v204344. It compiles with gfortran 4.6.3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
This happens in one of the most important codes in High energy physics, Pythia,
(Janus may well know its importance), I would kindly urge you to solve this
problem before the 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59229
--- Comment #3 from Jürgen Reuter juergen.reuter at desy dot de ---
Haha, thanks for the comment. To save my colleagues, they completely rewrote
the program in C++ in a modern way, but experimental physicists are changing
running system extremely
: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59688
Jürgen Reuter juergen.reuter at desy dot de changed:
What|Removed |Added
Host||MAC OS X
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59688
--- Comment #1 from Jürgen Reuter juergen.reuter at desy dot de ---
Created attachment 31578
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31578action=edit
config log of my gcc build
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
This is our libtool command which does the invocation. I hope that you don't
need any parts of the code to track this down:
{{{
libtool: link: gfortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421
--- Comment #1 from Jürgen Reuter juergen.reuter at desy dot de ---
I couldn't check up to now but I assume this also happens with 4.8.1.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421
--- Comment #3 from Jürgen Reuter juergen.reuter at desy dot de ---
I'll try to cook it down as much as possible.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421
--- Comment #5 from Jürgen Reuter juergen.reuter at desy dot de ---
Well, we have Fortran 2003 code into which via Bind(C) some c++ code is linked.
For static builds, on MAC OS X because of the properties of the single-pass
linker we need
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421
--- Comment #7 from Jürgen Reuter juergen.reuter at desy dot de ---
Ok, true, now I got it. But now it really looks like a problem of the library,
and not our linking procedure. About this I was not totally sure before.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421
--- Comment #8 from Jürgen Reuter juergen.reuter at desy dot de ---
Somehow, your example works for me :(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421
--- Comment #9 from Jürgen Reuter juergen.reuter at desy dot de ---
Well, I checked gcc/gfortran/g++ 4.8.1 today. There, the problem DOES NOT
occur,
so it seems to be a problem of gcc 4.9-LATEST.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421
--- Comment #10 from Jürgen Reuter juergen.reuter at desy dot de ---
After I completely recompiled the trunk version (r199585) the problem is gone.
So most probably it resulted from an incomplete update and recompilation of the
code
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Our code, WHIZARD 2.2.2, crashes in its self test smtest_5 with the following
runtime error:
whizard(46878) malloc: *** error for object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
Jürgen Reuter juergen.reuter at desy dot de changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #2 from Jürgen Reuter juergen.reuter at desy dot de ---
(In reply to kargl from comment #1)
Can you rebuild your code with compile with the -fcheck=all option?
I did. This does not change anything. And it does not give any further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #7 from Jürgen Reuter juergen.reuter at desy dot de ---
(In reply to Dominique d'Humieres from comment #5)
Confirmed with 4.9.1 revision r212339. AFAICT revision r210749 is OK.
I suspect r211405 for 4.10 and r212329 for 4.9. Can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #8 from Jürgen Reuter juergen.reuter at desy dot de ---
Created attachment 33138
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33138action=edit
Test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #9 from Jürgen Reuter juergen.reuter at desy dot de ---
I added the test case which is at least freed from a lot of docu and the heavy
autotools/libtool setup. The makefile compiles the code and creates a binary
seg_prod. Run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #11 from Jürgen Reuter juergen.reuter at desy dot de ---
Sorry, wrong makefile logic. I will send a working and more reduced case later
this afternoon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #13 from Jürgen Reuter juergen.reuter at desy dot de ---
Created attachment 33140
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33140action=edit
Abridged and hopefully working test case.
In the middle of reducing the test case.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #14 from Jürgen Reuter juergen.reuter at desy dot de ---
By the way, the -fcheck=all triggered other problems with definitely valid
code, so I guess there is another compiler bug.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #18 from Jürgen Reuter juergen.reuter at desy dot de ---
I didn't get an ICE (yet) but it must in the auto_components part of the code.
I'll try to reduce the case a little further.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #20 from Jürgen Reuter juergen.reuter at desy dot de ---
Ok, Dominique, you mean: compile everything with 4.9.1, then recompile
commands.f90 with 4.9.0 and build the executable with 4.9.0?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
Jürgen Reuter juergen.reuter at desy dot de changed:
What|Removed |Added
Attachment #33138|0 |1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #24 from Jürgen Reuter juergen.reuter at desy dot de ---
Created attachment 33153
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33153action=edit
Further cutting down the example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #25 from Jürgen Reuter juergen.reuter at desy dot de ---
Created attachment 33158
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33158action=edit
Reduced test case, 140 lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #26 from Jürgen Reuter juergen.reuter at desy dot de ---
I cooked down the problem to a 140 line test case with which you should be able
to find the culprit. Just do:
gfortran iso_varying_string.o whizard_test.f90
and run
./a.out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #27 from Jürgen Reuter juergen.reuter at desy dot de ---
Dominique, I tested your proposed fix from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831#c23
But it doesn't work, the problem still occurs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #29 from Jürgen Reuter juergen.reuter at desy dot de ---
A trivial workaround for the problem is to replace
(In reply to Dominique d'Humieres from comment #28)
Created attachment 33158 [details]
Reduced test case, 140 lines
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Created attachment 31891
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31891action=edit
Tar ball that produces code triggering the memory corruption
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881
--- Comment #2 from Jürgen Reuter juergen.reuter at desy dot de ---
Created attachment 31895
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31895action=edit
bit smaller test case
This is a bit smaller test case. The main program is basically
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59941
--- Comment #1 from Jürgen Reuter juergen.reuter at desy dot de ---
Created attachment 31951
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=31951action=edit
Code triggering the ICE
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
This is the code that triggers the ICE:
$ gfortran -c ICE.f90
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59941
--- Comment #2 from Jürgen Reuter juergen.reuter at desy dot de ---
The bug appears only with 4.7.x, with 4.8 and 4.9 it is working.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Setting a dimension zero array to a constant value triggers an ICE:
Failing code:
module foo
logical, dimension(0) :: is_allowed = .true.
end
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
On MAC OS X at least, I was not able to compile gcc-4.10 due to the following
problem (svn rev 211463):
{{{
/usr/local/packages/gcc-4.10.0_trunk/build/./gcc/xgcc
-B/usr/local/packages/gcc-4.10.0_trunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61477
--- Comment #1 from Jürgen Reuter juergen.reuter at desy dot de ---
Created attachment 32925
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32925action=edit
config.log
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
I tried to compile the software package LHAPDF from http://lhapdf.hepforge.org
and this triggered this compiler error:
PDF.cc: In member function 'virtual void
boost::exception_detail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506
Jürgen Reuter juergen.reuter at desy dot de changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506
--- Comment #1 from Jürgen Reuter juergen.reuter at desy dot de ---
This is the author of the package: andy.buck...@cern.ch
With version 6.1.2 of LHAPDF I get the error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506
--- Comment #2 from Jürgen Reuter juergen.reuter at desy dot de ---
This is the remark what I got from Andy Buckley:
Line 29 of PDF.cc is the end of the file, which suggests to me an
unclosed scope or similar higher up. The reported errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506
--- Comment #3 from Jürgen Reuter juergen.reuter at desy dot de ---
Created attachment 32937
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32937action=edit
Code that triggers the ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506
--- Comment #4 from Jürgen Reuter juergen.reuter at desy dot de ---
I reduced the case to the code attached. But you need to include the boost
headers (which are pretty standard tho; I have version 1.55.0).
/opt/local/include is my path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506
--- Comment #6 from Jürgen Reuter juergen.reuter at desy dot de ---
(In reply to Markus Trippelsdorf from comment #5)
Please provide a preprocessed file, see: https://gcc.gnu.org/bugs/ .
Uff, I never had to do this in my 30 or so bug reports
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506
--- Comment #8 from Jürgen Reuter juergen.reuter at desy dot de ---
The .ii file is too big, you can find it here:
http://desy.de/~reuter/PDF.ii
Note that the headers I attached (besides of the boost headers, of course) are
marked as being
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506
--- Comment #10 from Jürgen Reuter juergen.reuter at desy dot de ---
$ g++ --version
g++ (GCC) 4.10.0 20140613 (experimental)
It's svn r211649
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61506
--- Comment #12 from Jürgen Reuter juergen.reuter at desy dot de ---
Here it is:
g++ -v -c PDF.ii
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-apple-darwin11.4.2
Configured with: ../configure --prefix=/usr/local/ --with-gmp=/usr/local
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
The following code triggers an ICE with 4.9.0 but seems to work with 4.7.X,
4.8.X, and 4.10:
gfortran -c prc_gosam.f90
prc_gosam.f90: In function ‘__final_prc_gosam_Gosam_writer_t’:
prc_gosam.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61766
--- Comment #1 from Jürgen Reuter juergen.reuter at desy dot de ---
Created attachment 33097
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33097action=edit
Code that triggers the ICE
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Created attachment 34701
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34701action=edit
File that triggers the ICE
The following code leads to internal compiler error with the message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198
--- Comment #21 from Jürgen Reuter juergen.reuter at desy dot de ---
(In reply to Paul Thomas from comment #20)
Patch posted last night: https://gcc.gnu.org/ml/fortran/2015-03/msg00069.html
A somewhat better version might emerge tonight now
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
The following code
{{{
module selectors
type :: selector_t
integer, dimension(:), allocatable :: map
real, dimension(:), allocatable :: weight
contains
procedure :: init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548
--- Comment #1 from Jürgen Reuter juergen.reuter at desy dot de ---
Created attachment 35129
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35129action=edit
Code that triggers the ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548
--- Comment #2 from Jürgen Reuter juergen.reuter at desy dot de ---
I'd also appreciate a short workaround.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548
--- Comment #27 from Jürgen Reuter juergen.reuter at desy dot de ---
And Example #2 is:
module foo
type :: t
integer :: n
character(32), dimension(:), allocatable :: md5
contains
procedure :: init = t_init
end type t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
--- Comment #1 from Jürgen Reuter juergen.reuter at desy dot de ---
Ok, here is a bit shorter test case, untar the attached file,
do ./make.
This produces an executable seg_prod. With r222305 I get the desired result:
$ ./seg_prod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
--- Comment #2 from Jürgen Reuter juergen.reuter at desy dot de ---
Created attachment 35401
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35401action=edit
Code that triggers the segmentation fault.
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Between the commits r222305 and r222439 a severe regression has been
introducing segfaults in our code:
http://whizard.hepforge.org/versions/unofficial/whizard-2.2.6_alpha-20150426
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548
--- Comment #21 from Jürgen Reuter juergen.reuter at desy dot de ---
(In reply to vehre from comment #20)
Juergen, could you meanwhile check, that the patch fixes the issue?
Damn, it seems my text didn't get posted. Being in Japan at the moment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548
--- Comment #22 from Jürgen Reuter juergen.reuter at desy dot de ---
One thing is:
allocate (foo (0:this%dim-1), source=this%get_integral())
where this is some derived type with integer component dim
and TBP get_integral which is a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548
--- Comment #23 from Jürgen Reuter juergen.reuter at desy dot de ---
The other failure occurs for
allocate (foo (this%n), source=this%bar)
where n is integer, foo has type
character(32), dimension(:), allocatable
and bar as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548
--- Comment #25 from Jürgen Reuter juergen.reuter at desy dot de ---
Example 1:
module foo
type :: t
integer :: n
real, dimension(:,:), allocatable :: val
contains
procedure :: make = t_make
generic :: get_int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548
--- Comment #30 from Jürgen Reuter juergen.reuter at desy dot de ---
I can apply this patch on r222550 of
https://gcc.gnu.org/svn/gcc/branches/gcc-5-branch/
correct?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
--- Comment #10 from Jürgen Reuter juergen.reuter at desy dot de ---
(In reply to Dominique d'Humieres from comment #9)
With the attached patch your small test case and the test suite runs
w/o segfault now. Furthermore does gcc6 bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548
--- Comment #32 from Jürgen Reuter juergen.reuter at desy dot de ---
With gcc-6.0 trunk I cannot test our complete code because of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
For gcc 5 trunk I have massive problems in checking out the svn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
--- Comment #11 from Jürgen Reuter juergen.reuter at desy dot de ---
Here is the small test case for the ICE with the patch provided Andre
Vehreschild:
gfortran -c evaluators.f90
evaluators.f90:40:0:
.or. qn_mask_rest
1
internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
--- Comment #7 from Jürgen Reuter juergen.reuter at desy dot de ---
Created attachment 35404
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35404action=edit
Code that triggers the segmentation fault.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
--- Comment #5 from Jürgen Reuter juergen.reuter at desy dot de ---
Here is a reduced test case (where iso_varying_string.f90 is the standard
module with 1 or 2 modifications by us). As this is at the core of our program,
we do rely on a timely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
--- Comment #6 from Jürgen Reuter juergen.reuter at desy dot de ---
Created attachment 35403
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35403action=edit
Auxiliary module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548
--- Comment #34 from Jürgen Reuter juergen.reuter at desy dot de ---
Andre, I checked your patch with r222305 of the gcc 6.0 trunk. Our complete
code (without workarounds for the two remaining cases reported) compiles, and
our complete testsuite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548
--- Comment #37 from Jürgen Reuter juergen.reuter at desy dot de ---
(In reply to vehre from comment #36)
I am waiting for an official review of the patch, to be allowed to commit to
trunk. So I am not waiting on you. :-)
I see. Got it. :D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
--- Comment #17 from Jürgen Reuter juergen.reuter at desy dot de ---
(In reply to vehre from comment #16)
Patch submitted at:
https://gcc.gnu.org/ml/fortran/2015-05/msg00025.html
This patch also fixes the issue in comment #15.
First
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
--- Comment #23 from Jürgen Reuter juergen.reuter at desy dot de ---
That would be cool. If you have OCaml installed (version 3.12 or newer, and as
a French you couldn't complain about that^^) you could run a lot more from the
test suite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
--- Comment #21 from Jürgen Reuter juergen.reuter at desy dot de ---
No this is not expected. There seems to be another problem inside gfortran
6.0.0 trunk. I cannot test things before tomorrow/weekend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
--- Comment #28 from Jürgen Reuter juergen.reuter at desy dot de ---
Dominique, comment #27 looks perfect. That would be great for us with the
upcoming revision of gfortran 6.0.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58586
--- Comment #7 from Jürgen Reuter juergen.reuter at desy dot de ---
Hm, ok, these are not just in a single file, cannot promise that I will be able
to look into them. :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
--- Comment #13 from Jürgen Reuter juergen.reuter at desy dot de ---
I will give it a try as soon as possible. Any idea how long propagation into
the trunk might last?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
--- Comment #33 from Jürgen Reuter juergen.reuter at desy dot de ---
Great, with that comment everything in our code works again, thanks, Mikael.
So, what about Dominique's comment with the fix for PR 58586 and that this
breaks our code again
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
--- Comment #31 from Jürgen Reuter juergen.reuter at desy dot de ---
Shall I do any checks now? It seems that Mikael's patch is doing the right
thing, and you found the one that breaks it again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58586
--- Comment #5 from Jürgen Reuter juergen.reuter at desy dot de ---
Contrary to Dominique's comment in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894#c30
adding the patch in
https://gcc.gnu.org/ml/fortran/2015-04/msg00058.html
on top
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548
--- Comment #35 from Jürgen Reuter juergen.reuter at desy dot de ---
What are u waiting for?^^ already confirmed in comment #34 that rverything in
our code works with the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
--- Comment #19 from Jürgen Reuter juergen.reuter at desy dot de ---
Of course, we are fine (or even happy) if you take our code examples for your
regression tests.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
--- Comment #25 from Jürgen Reuter juergen.reuter at desy dot de ---
Just do the configuration without the --disable-ocaml flag (the default is
that OCaml is enabled). The configure should show then something like that
(Ocamlweb is not needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548
--- Comment #14 from Jürgen Reuter juergen.reuter at desy dot de ---
(In reply to vehre from comment #13)
Created attachment 35318 [details]
Follow-up patch fixing latest regression.
The attached patch fixes the ICE.
Juergen, please
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548
--- Comment #17 from Jürgen Reuter juergen.reuter at desy dot de ---
I applied the patch, and did a make in the built folder. I still get the ICE.
Or do I have to change the file gcc/fortran/trans-stmt.c and do a completely
new built of the gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66929
--- Comment #8 from Jürgen Reuter juergen.reuter at desy dot de ---
Just confirmed that the fix in comment #1 works with our code and doesn't (at
least in our code) introduce any new regression.
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
An ICE happens when trying to allocate an allocatable array with explicit array
bounds in combination with a source expression:
gfortran -c processes.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66927
--- Comment #1 from Jürgen Reuter juergen.reuter at desy dot de ---
Forgot: my gcc svn revision is r224763.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66927
--- Comment #4 from Jürgen Reuter juergen.reuter at desy dot de ---
Actually, we are using now
allocate (obj(1:size (func ()))
obj = func ()
as you are saying
allocate (obj, source = func ())
had problems in gfortran 4.7.X.
So the issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66929
Jürgen Reuter juergen.reuter at desy dot de changed:
What|Removed |Added
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66929
--- Comment #5 from Jürgen Reuter juergen.reuter at desy dot de ---
Maybe stressing again: this is pretty much a blocker for us because it is in a
'standard' module which we don't want to modify, and on which all parts of our
code depend. We'd
1 - 100 of 678 matches
Mail list logo
