Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The following code is expected to give:
a [before] = 2 3 4
arr = 2 3 4
bounds = 2 4
arr2= 200 200 200
a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85507
--- Comment #21 from Jürgen Reuter ---
Actually, did the commits by Andre in May resolve this issue, or is there still
something left open?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87239
--- Comment #2 from Jürgen Reuter ---
Dominique, my apologies, I don't know why my browser did send the form data
twice.
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The following code posted on c.l.f. on Apr 28, 2018 leads to an ICE with
gfortran, but it seems this was never posted here:
$ gfortran alloc_string.f90
alloc_string.f90:24:0:
24 | out
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The following code posted on c.l.f. on Apr 28, 2018 leads to an ICE with
gfortran, but it seems this was never posted here:
$ gfortran alloc_string.f90
alloc_string.f90:24:0:
24 | out
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
this is a question on the constraint C1279 from J3/04-007
"In the scoping unit of an elemental subprogram, an object desig
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The following is from c.l.f. Jan 26, 2018 but seems to never have been filed as
a bug report here (?), though Dominique d'Hum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86907
--- Comment #3 from Jürgen Reuter ---
(In reply to janus from comment #2)
> I cannot reproduce this at r263854.
>
> I think the error you report requires GCC to be configured with
> --enable-checking (this is on by default for non-release builds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83113
--- Comment #2 from Jürgen Reuter ---
Still present in 9.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82036
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81849
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86907
--- Comment #1 from Jürgen Reuter ---
As remark, the renaming of types t2 => t1 is needed to produce the bug, as well
as the components of t1 being allocatable. The used revision of gfortran was
262687.
ty: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Created attachment 44522
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44522&action=edit
Minimal reproduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52473
--- Comment #18 from Jürgen Reuter ---
The example by posted on May 20, 2017 on c.l.f. improved by Stefano Zaghi below
shows a factor of 10-20 improvement now in gfortran 9.0.0 including the work by
Thomas Koenig.
$ ./a.out
Elapsed CPU time =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34705
--- Comment #2 from Jürgen Reuter ---
Is this still an open issue? 10 years gone by now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86533
--- Comment #3 from Jürgen Reuter ---
(In reply to Jonathan Wakely from comment #2)
> My best guess is that you've messed up your GCC installation, because
> _GLIBCXX20_CONSTEXPR should be defined in like so:
>
> #ifndef _GLIBCXX20_CONSTEXPR
>
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Created attachment 44400
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44400&action=edit
Minimal reproducer
The attached code leads to a compile error on valid code, it was working with
r261434 but fails with r2626
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79886
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The code below leads to an ICE:
$ gfortran -fopenmp omp2.f90
during GIMPLE pass: omplower
omp2.f90:5:0:
!$OMP PARALLEL private(val)
internal compiler error: Segmentation fault: 11
libbacktrace could
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The following coarray code from c.l.f. 2016, Nov 16 leads to an ICE:
$ gfortran -fcoarray=single coarr1.f90
coarr1.f90:18:0:
subroutine wrapped_point_add(self, to_add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77703
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77652
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The following example from c.l.f. July 12, 2016 gives an ICE in the actual
gfortran trunk, 9.0.0. This is the ICE from gfortran:
$ gfortran f08_4.f90
f951: internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86297
--- Comment #3 from Jürgen Reuter ---
Sorry, I should have scanned a little better for existing PRs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86297
--- Comment #1 from Jürgen Reuter ---
This is the error message from gfortran:
Error: 'p' at (1) must have the same number of formal arguments as the
overridden procedure
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The following code is rejected my gfortran 9.0 (I also checked 5.4.0). It is
accepted by nagfor 6.2 and ifort 18 and 19beta, but was rejected by ifort 17
with the same argument as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71612
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71565
--- Comment #3 from Jürgen Reuter ---
Sorry, in ifort this got fixed in the meanwhile. Only gfortran rejects this
code still.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71565
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71412
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The following code adapted from a code example posted on the Intel forum here
(with an obvious programming error there):
https://software.intel.com/en-us/forums/intel-fortran
: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
This is from c.l.f. posted by Beliavsky on April 27, 2016, it gave (at that
time) an ICE in gfortran 5.3, and still does so in the actual trunk. I think
this was never reported here on bugzilla. Here is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64120
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86089
--- Comment #12 from Jürgen Reuter ---
(In reply to Martin Liška from comment #11)
> Patch candidate sent here:
> https://gcc.gnu.org/ml/gcc-patches/2018-06/msg00546.html
Thanks for the patch, Martin. I checked that our code works again also wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86089
--- Comment #10 from Jürgen Reuter ---
I can confirm that re-introducing the line
case BUILT_IN_STRCPY_CHK:
in lines 619/20 in tree-ssa-strlen.c does indeed solve this problem and also
the problem (ICE) with our code reported in PR86103.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86089
--- Comment #7 from Jürgen Reuter ---
Ah I see, so when Martin Liska removed the MPX-support in r261304 you removed
too much from the tree-ssa-strlen.c file? Then a rather fast fix is hopefully
possible.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86089
--- Comment #5 from Jürgen Reuter ---
And this is the assembler code when executing -S -O1 (cf. below), while for the
-O2
version the compilation leads to an assembler file showing only the .text line:
.text
.globl _hoo
_hoo:
LFB1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86089
--- Comment #4 from Jürgen Reuter ---
This is the dump-tree-original file, which is produced despite of the ICE, and
which is identical for -O1 and -O2:
;; Function __sputc (null)
;; enabled by -tree-original
{
if ( --_p->_w >= 0 || _p->_w >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86089
--- Comment #3 from Jürgen Reuter ---
I can definitely confirm this problem. Works with -O0 and -O1. Fails with -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86089
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Created attachment 44256
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44256&action=edit
Reproducer for the ICE.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30373
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86052
--- Comment #3 from Jürgen Reuter ---
Paul, it is not my example, it was posted by Alberto Fco. Martín-Huertas in
December 2015 on c.l.f., and you commented at that time that you were
contemplating on how to implement PDTs together with recursive
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The following example from c.l.f. (Dec 14, 2015, "explicit specialization for
Fortran2003 recursively-defined parameterized data types?" leads to an ICE with
the curren
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85942
--- Comment #3 from Jürgen Reuter ---
Paul, from my side absolutely no urgency. Just stumbled over this example on
c.l.f. and wanted to play a bit.
: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The following code from c.l.f. thread from Sep 28, 2015. ("Vectors on everyday
physics") leads to an ICE with gfortran 9.0, but works without problems with
ifort 18 and 19, cf. code below.
Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85850
--- Comment #6 from Jürgen Reuter ---
This was indeed introduced in r260343 and was fixed in r260620. I tried out
r260633 today, and it compiles and bootstraps again without any problem. So I
think this can be closed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85850
--- Comment #4 from Jürgen Reuter ---
Sorry, I meant Marc, of course. Confused this was another PR.
(In reply to Jürgen Reuter from comment #3)
> Indeed, Janne is correct, this change in libcpp/system.h solves the problem,
> i.e. moving the de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85850
--- Comment #3 from Jürgen Reuter ---
Indeed, Janne is correct, this change in libcpp/system.h solves the problem,
i.e. moving the definition up:
# diff -u system.h system.h.260425
--- system.h2018-05-20 23:00:01.0 +0200
+++ system.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85850
--- Comment #2 from Jürgen Reuter ---
So is there a quick workaround for this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82091
--- Comment #6 from Jürgen Reuter ---
I do see this error now also with the trunk version [r260425] under Darwin 17.5
with Xcode 9.3.1.
ormal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
gcc doesn't compile any more under Darwin 17.5 with Xcode 9.3.1 producing the
following error (cf. below).
# g++ --version
Confi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392
--- Comment #17 from Jürgen Reuter ---
Sorry, I don't want to generate unnecessary traffic, I'm just scrolling thru
old c.l.f. discussions and stumble over some old reports there from time to
time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50392
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575
--- Comment #10 from Jürgen Reuter ---
(In reply to Dominique d'Humieres from comment #9)
> AFAICT
>
> (1) The behavior is present even without module: add
>
> implicit none
> integer :: cl
>
> to the test in comment 4 and it compiles if -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575
--- Comment #8 from Jürgen Reuter ---
module foo
implicit none
contains
function constr_quark_loopline(ho,sho) result(cl)
integer, dimension(sho), intent(in) :: ho
integer, dimension(sho) :: hor
integer, intent(in)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575
--- Comment #6 from Jürgen Reuter ---
In addition, it also throws the error
Error: GNU Extension: Symbol ‘sho’ is used before it is typed at (1)
for the case of a contained module procedure with implicit none as in comment
#5.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575
--- Comment #5 from Jürgen Reuter ---
Yes, as external function the error is thrown, but not as module procedure.
So do
module foo
implicit none
contains
function quark ...
end function ...
end module ...
This will compile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65086
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63371
Jürgen Reuter changed:
What|Removed |Added
CC||dominiq at lps dot ens.fr,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575
--- Comment #3 from Jürgen Reuter ---
This seems to be a GNU extension. In fact, when compiling with -std=f2008
gfortran throws an error. So my guess is this a wanted extension for backwards
compatibility with old programs, well not too old, as t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85507
--- Comment #7 from Jürgen Reuter ---
Thanks for the proposed bugfix. Did you check that also OpenCoarrays 2.0
compiles again with this fix?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85575
--- Comment #1 from Jürgen Reuter ---
Ok, after discussion on the Intel Forum I found out that this is based on
Section 7.1.11p7 of the f2008 standard , Specification expression:
A variable in a specication expression shall have its type an
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
I think I saw discussions on this topic already on c.l.f. I am having the
following subroutine (and the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85561
--- Comment #2 from Jürgen Reuter ---
One more addition: I was using mpich-3.2, which compiled without error and also
fulfilled its complete test suite.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85561
--- Comment #1 from Jürgen Reuter ---
I just started playing around with OpenCoarrays. Not sure whether I should also
report this to the OpenCoarrays team.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
When compiling OpenCoarrays 2.0.0 I get the following ICE:
cd
/usr/local/packages/OpenCoarrays-2.0.0/_build/src/tests
,
||janus at gcc dot gnu.org,
||juergen.reuter at desy dot de,
||tkoenig at gcc dot gnu.org
--- Comment #4 from Jürgen Reuter ---
This example works for me with the 8.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61606
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85131
--- Comment #1 from Jürgen Reuter ---
Created attachment 43806
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43806&action=edit
Reproducer for the ICE
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The following code fails with gfortran 4.8.4, 5.4 and 8.0.1, so probably has
never worked correctly in gfortran. It works on ifort v17 and v18:
gfortran -c quantum_numbers.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #16 from Jürgen Reuter ---
In addition to what Tobias remarked, NAG now gives a clear error message:
NAG Fortran Compiler Release 6.1(Tozai) Build 6138
Error: data.f90, line 13: Object TRLKOLD of type ACTIVE is default-initialised,
t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155
--- Comment #23 from Jürgen Reuter ---
All our code is fine also with this fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155
--- Comment #22 from Jürgen Reuter ---
I just started building r257550 of the trunk and will check our code. I'll
report back of there are any issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #34 from Jürgen Reuter ---
So, to summarise all of our code, at least our basic and extended tests, work
again with this (second) patch by Paul Thomas, for all different kind types of
our default reals (64, 80, emulated 128 bit). Than
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #33 from Jürgen Reuter ---
Mea culpa. I had to recompile the external libraries again. Then those tests
depending on the external libraries did also work (headbang).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #31 from Jürgen Reuter ---
Unfortunately, the problem with our external libraries still persist. Don't
know how to provide you with a test case for this without providing our
complete code and their external complete code. :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #30 from Jürgen Reuter ---
Yep, that looks good. Paul's fix is now the change in trans-array.c only, or
still the change in trans-io.c ? I guess only the trans-array.c patch. I'll try
it out later tonight.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155
--- Comment #11 from Jürgen Reuter ---
There was another test case that I submitted for #84141. It still failed after
the first preliminary fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #28 from Jürgen Reuter ---
Created attachment 43329
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43329&action=edit
Shortened test case (after prelim. fix)
This is a shortened test case that still failed after the first prelim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #26 from Jürgen Reuter ---
Paul, let me know whether you want me to reduce the "Additional failing test
case" any further. Really have to go to sleep now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #25 from Jürgen Reuter ---
The other errors actually appear in I/O procedures of external libraries that
we link to our code. It would be hard(er) to come up with a test case here.
Hope you can fix all of that, keeping fingers crossed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #24 from Jürgen Reuter ---
Created attachment 43322
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43322&action=edit
Additional failing test case (after the prelim. fix)
This is still lengthy, and I can reduce it further but ma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155
--- Comment #9 from Jürgen Reuter ---
This fixes almost all of our unit and functional test, but not all of them.
There are still 19 functional tests failing, all of them seem to have to do
with some sort of I/O . And one unit tests, which I cann
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #22 from Jürgen Reuter ---
I'm actually running our code right now. It fixes _almost all_ of our unit and
functional tests. There is still one failing unit test and at least one failing
functional test. Still waiting for the full resu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #17 from Jürgen Reuter ---
Maybe also look at the PR84155 with a similar (possibly the same?) problem, and
a workaround, or a direct case for the culprit in a single line.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155
--- Comment #2 from Jürgen Reuter ---
This regression has been also introduced within revisions r256722 and r257131.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84155
--- Comment #1 from Jürgen Reuter ---
Created attachment 43313
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43313&action=edit
Reproducer, 48 lines
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The following file compiles and hangs, unless the other line is commented out.
Probably a duplicate of #84141, it is a second example from our code.
When uncommenting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #15 from Jürgen Reuter ---
Created attachment 43311
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43311&action=edit
Isolated file: small reproducer, 250 lines
This should print
1: 2: INSIDE MCI_VAMP_WRITE
VAMP integrator:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #11 from Jürgen Reuter ---
When you run the binary created (seg_prod), you'll get
|
| Running self-test: mci_vamp
| -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #10 from Jürgen Reuter ---
Created attachment 43307
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43307&action=edit
Reproducer_2, a little smaller
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #9 from Jürgen Reuter ---
Let me put a little smaller reproducer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #7 from Jürgen Reuter ---
We reproduced this on Darwin 17.4.0 and OpenSuSe Leap 42.2 Linux and within a
Docker Image running Ubuntu LTS. The two cases on Linux are the test example of
which I extracted the smaller reproducer.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
Jürgen Reuter changed:
What|Removed |Added
Summary|[8 Regression] Internal |[8.0.1 regression] Internal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #4 from Jürgen Reuter ---
The reproducer will build an executable ./seg_prod which generates the run time
error in the 7. unit test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #3 from Jürgen Reuter ---
Created attachment 43304
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43304&action=edit
Corrected reproducer, please ignore the first one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
--- Comment #2 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #1)
> Created attachment 43303 [details]
> Reproducer for the RT error
Ooops, one correction in the makefile, system_dependencies.f90 must come before
diagnostics.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84141
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
401 - 500 of 701 matches
Mail list logo
