: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Unfortunately, just a week or so before the release there was a very severe
regression, which leads to a double free corruption in tcache, cf. below.
Unfortunately
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #1 from Jürgen Reuter ---
The change must have happened between Sunday, April 16 and Monday, April 27.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #2 from Jürgen Reuter ---
This is our unit test, we now confirmed that this is the only problem, so the
only failing test: it really looks like that the finalizer for the subroutine
crashes, all routines inside the subroutine get exec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #4 from Jürgen Reuter ---
It is definitely this routine in our code that triggers this double free error:
call simulation%init ([procname1], .true., .true., global, alt_env=alt_env)
It really looks like that the garbage collector is m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #5 from Jürgen Reuter ---
(In reply to Richard Biener from comment #3)
> Can you maybe bisect this to a specific (fortran) commit in GCC?
This does not necessarily be a Fortran specific commit, it could also be a
change in the middle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #9 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #8)
> I'd like to understand what went wrong here... I suspect that
> the fix exposed another bug somewhere :-(
>
> Is it possible to isolate a test case like that? I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #11 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #10)
> (In reply to Richard Biener from comment #3)
> > Can you maybe bisect this to a specific (fortran) commit in GCC?
>
> Richard, when is the last time (presumabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #12 from Jürgen Reuter ---
fuck, sdill too big :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #13 from Jürgen Reuter ---
I will submit a reproducer, unpack it, do 'make', then execute
./whizard_test --check simulations.
Still trying to get this below 1 MB. :(
In case you cannot fix this, please, Thomas, please, revert this. Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #14 from Jürgen Reuter ---
Created attachment 48387
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48387&action=edit
Reproducer, first try
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #15 from Jürgen Reuter ---
Wow, I have a first version, finally.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #16 from Jürgen Reuter ---
Created attachment 48388
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48388&action=edit
2nd reproducer, down to 800 kb
Now you can do just ./whizard_check to run the test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #20 from Jürgen Reuter ---
Thanks a lot for reverting, Thomas, shall I further reduce the reproducer, or
can you work with it now?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #22 from Jürgen Reuter ---
Ok, I stop shrinking the reproducer further down for the moment, let me know if
you need more help. Thanks for your efforts.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #25 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #23)
> (In reply to Jürgen Reuter from comment #20)
> > Thanks a lot for reverting, Thomas, shall I further reduce the reproducer,
> > or can you work with it now?
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #26 from Jürgen Reuter ---
At least there is no time pressure at the moment ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #28 from Jürgen Reuter ---
Created attachment 48392
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48392&action=edit
3rd reproducer, down to 600 kb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #29 from Jürgen Reuter ---
Is this now small enough?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #30 from Jürgen Reuter ---
Thomas, can you work with this now!?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #31 from Jürgen Reuter ---
Created attachment 48402
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48402&action=edit
Reproducer 4, down to 210 kb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #32 from Jürgen Reuter ---
Created attachment 48404
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48404&action=edit
Reproducer 5, now single file, C code gone, just needs empty Test.mdl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #34 from Jürgen Reuter ---
Created attachment 48411
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48411&action=edit
Final reproducer, less than 300 lines ;)
This one should be sufficient. No further files or input is necessary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #36 from Jürgen Reuter ---
Hm, I hope I didn't change the flavor of the bug, but you can cross-check with
the very first reproducer which contains our code more or less unchanged
(except for the build setup with autotools etc.).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #38 from Jürgen Reuter ---
Created attachment 48426
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48426&action=edit
Correct 'final' final reproducer
Indeed,
rt_data_t should have an additional
component
type(rt_data_t), pointe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788
--- Comment #39 from Jürgen Reuter ---
I submitted a corrected 'final' reproducer, sorry about that. Was too tired
yesterday.
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Created attachment 48507
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48507&action=edit
Reproducer
In some of our legacy code which we are still using, the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #1 from Jürgen Reuter ---
I shrank the example even further:
SUBROUTINE MNSTIN
132 FORMAT (' UNIT',I3,' ALREADY OPENED WITH NAME:',A/
+' NEW NAME IGNORED:',A)
RETURN
END
It looks like
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #3 from Jürgen Reuter ---
Just as a quick cross check: the 10.1 release works without problems, so this
indeed must have been introduced in one of the earliest commits after the 10.1
was branched off.
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Probably a commit within the last 2-3 days introduced a regression in
gfc_format_decoder:
n gfc_format_decoder, at fortran/error.c:970
I will provide the exact
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96073
--- Comment #1 from Jürgen Reuter ---
Next step, full error message:
ibtool: compile: gfortran -I../basics -I../utilities -I../testing -I../system
-I../combinatorics -I../rng -I../physics -I../fastjet -I../qft -I../types
-I../particles -I../../
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96073
Jürgen Reuter changed:
What|Removed |Added
Summary|[11 Regression] regression |[11.0 regression]
|in
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
I am using the following setup:
Darwin 19.6.0, macOS Catalina 10.15.6, XCode v11.6, with clang
Apple clang version 11.0.3 (clang-1103.0.32.62)
Target: x86_64-apple-darwin19.6.0
Thread
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
After I upgraded to Darwin 19.6.0 (MACOSX 10.15.6) and XCode 11.6
bootstrapping/compiling gcc does not work any more with the following error:
make[3]: Nothing to be done for `all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96540
--- Comment #1 from Jürgen Reuter ---
It seems that the problem is in the declaration of the following variables in
value_range.h:
template friend void gt_ggc_mx (int_range *);
template friend void gt_pch_nx (int_range *);
template frien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96540
--- Comment #2 from Jürgen Reuter ---
Most likely this was that commit:
4ba9fb0a3e65 (Aldy Hernandez2020-07-30 11:30:18 +0200 150) template
friend void gt_ggc_mx (int_range *);
4ba9fb0a3e65 (Aldy Hernandez2020-07-30 11:30:18 +0200 151)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96540
--- Comment #3 from Jürgen Reuter ---
Just uncommenting the declarations doesn't help because later on compilation
fails with
n file included from gtype-desc.c:52:
../../gcc/value-range.h:352:21: error: 'm_ranges' is a private member of
'int_rang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96540
--- Comment #5 from Jürgen Reuter ---
(In reply to Aldy Hernandez from comment #4)
> Does this patch fix the problem?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551660.html
It looks like, still compiling. In the meantime I change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96541
--- Comment #1 from Jürgen Reuter ---
Sorry, this is a duplicate of #96540.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96540
--- Comment #7 from Jürgen Reuter ---
(In reply to Aldy Hernandez from comment #4)
> Does this patch fix the problem?
>
> https://gcc.gnu.org/pipermail/gcc-patches/2020-August/551660.html
Yes, with that fix (as anticipated by you) build and boo
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The attached code (I will shorten the reproducer soon) gives the following ICE
below. The offending commit should have taken place between Sunday Aug 9 and
now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96556
--- Comment #1 from Jürgen Reuter ---
Created attachment 49036
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49036&action=edit
First reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96556
--- Comment #2 from Jürgen Reuter ---
Created attachment 49037
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49037&action=edit
2nd reproducer, single file, shortening further
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96556
--- Comment #3 from Jürgen Reuter ---
Created attachment 49038
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49038&action=edit
Final reproducer, some 70 lines
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Under macOS Catalina (Darwin 19.0.0) bootstrap fails with the following error
message:
libtool: compile: /usr/local/packages/gcc_10.0/_build/./gcc/xgcc
-shared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92445
--- Comment #1 from Jürgen Reuter ---
Did anybody look into this one here? At the moment, I cannot build gcc on
MACOSX Catalina.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #21 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #20)
> As of XCode 11.3beta, the contained SDK works OK:
>
> https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01439.html
>
> We still have the underlying problems - w
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
I tested both OCaml 4.02.3 and 4.09.0. For both, linking with gcc 10.0, your
development version r278668 svn://gcc.gnu.org/svn/gcc fails (cf. below). This
problem was observed both on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92673
Jürgen Reuter changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #2 from Jürgen Reuter
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: gfo
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421
--- Comment #1 from Jürgen Reuter ---
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 ---
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 ---
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 to explicitly link the C++ static libr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421
--- Comment #7 from Jürgen Reuter ---
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 ---
Somehow, your example works for me :(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57421
--- Comment #9 from Jürgen Reuter ---
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 ---
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,
or was in an intermediate step of the devel
: 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 ---
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=31254&action=edit
Code triggering the ICE
Triggers ICE with gfortran 4.9.0 v204344. It compiles with gfortra
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 ---
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 reluctantly (remember what the
: 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 changed:
What|Removed |Added
Host||MAC OS X
Severity|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59688
--- Comment #1 from Jürgen Reuter ---
Created attachment 31578
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31578&action=edit
config log of my gcc build
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Apparently this feature of F2008 is still flagged as unimplemented in the F2008
chart on the gfortran wiki
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
This is really tricky, in our test-suite, we do have a static test. You can get
our code from
http://whizard.tp.nt.uni-siegen.de/tarballs/whizard-nightly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #2 from Jürgen Reuter ---
The tests worked till yesterday, but only today major parts of gcc recompiled
because all files in gcc got a new timstamp. I am now trying to recompile also
gmp, mpfr and mpc with the llvm-clang from XCode 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #3 from Jürgen Reuter ---
And I am seeing the same problem on another Macbook (Macbook Air) since roughly
Christmas (maybe a bit before).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #4 from Jürgen Reuter ---
The linker before throws this warning:
ld: warning: direct access in function 'operator new[](unsigned long,
std::nothrow_t const&) [clone .cold]' from file
'/usr/local/lib/libstdc++.a(new_opvnt.o)' to global
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #5 from Jürgen Reuter ---
Indeed, things are more complicated. With a slim build of our software I don't
get the error, but only if we link the external library LCIO. This can be
downloaded from here: https://github.com/iLCSoft/LCIO/a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #6 from Jürgen Reuter ---
In the linking before I do see the following warning:
ld: warning: direct access in function 'operator new[](unsigned long,
std::nothrow_t const&) [clone .cold]' from file
'/usr/local/lib/libstdc++.a(new_opvn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #8 from Jürgen Reuter ---
Yes I know:
here is the non-working library resolution:
static_1.exe:
lib/libcuttools.dylib (compatibility version 0.0.0, current version 0.0.0)
lib/libopenloops.dylib (compatibility version 0.0.0, c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #10 from Jürgen Reuter ---
The trunk, svn 267657, all newest versions of gmp, mpfr, mpc. It seems that the
problem is also solved when I use the libtool flag -static instead of
-static-libtool-libs for libtool to build these executabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #12 from Jürgen Reuter ---
No, unfortunately a working svn # is difficult, I first observed it by doing
svn up on another Macbook around Christmas. What do you mean by transcripts?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #14 from Jürgen Reuter ---
Well, it seems that r267488 from Dec 31 was still working, on the other hand, I
saw a problem on the other MACbook definitely around at latest Dec 26 or so.
Probably before Christmas. It might be that small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #16 from Jürgen Reuter ---
Yes, after the problem occurred, I did a completely clean new build of gmp,
mpfr, mpc, gcc (configured with ../configure --prefix=/usr/local/
--with-gmp=/usr/local/ --with-mpfr=/usr/local/ --with-mpc=/usr/lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #19 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #18)
> (In reply to Jürgen Reuter from comment #14)
>
> does the application use exceptions?
No exceptions, only a poor man's C signal catcher.
>
> > /usr/local/lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #20 from Jürgen Reuter ---
Created attachment 45387
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45387&action=edit
DYLD_PRINT output non-working example
DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_BINDINGS=1 ./static_1.exe >
non_workin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #21 from Jürgen Reuter ---
Created attachment 45388
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45388&action=edit
DYLD_PRINT output working example
DYLD_PRINT_LIBRARIES=1 DYLD_PRINT_BINDINGS=1 ./static_1.exe > working_output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #22 from Jürgen Reuter ---
This is the output from the lldb command (but this was not a debug build of gcc
yet):
$ lldb ./static_1.exe
(lldb) target create "./static_1.exe"
Current executable set to './static_1.exe' (x86_64).
(lldb) r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #25 from Jürgen Reuter ---
(In reply to Richard Biener from comment #24)
> (In reply to Iain Sandoe from comment #23)
> > (In reply to Jürgen Reuter from comment #22)
>
> Indeed - somehow you didn't get a statically linked executabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #29 from Jürgen Reuter ---
-rdynamic doesn't change anything, and ld doesn't understand -export-dynamic.
I am a bit confused what to do now, as we have a workaround, i.e. using -static
instead of -static-libtool-libs as libtool flag.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #31 from Jürgen Reuter ---
Then I get tons of duplicate symbol lines.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
--- Comment #33 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #32)
> (In reply to Jürgen Reuter from comment #31)
> > Then I get tons of duplicate symbol lines.
>
> ah well, not so simple then,
>
> then I think the next step is f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81849
--- Comment #8 from Jürgen Reuter ---
I think this fix or something very near by causes an ICE in our code, I will
provide a bug report soon.
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Created attachment 45436
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45436&action=edit
File that triggers the ICE.
The following (legacy) code included
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871
--- Comment #1 from Jürgen Reuter ---
My suspicion goes toward the fix for PR81849, so maybe also the gcc-7 and gcc-8
branches are affected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871
--- Comment #2 from Jürgen Reuter ---
Here is a more minimal example:
SUBROUTINE MNREAD(IFLGIN,IFLGUT)
IMPLICIT DOUBLE PRECISION (A-H,O-Z)
PARAMETER (MNE=100 , MNI=50)
PARAMETER (MNIHL=MNI*(MNI+1)/2)
CHARACTER*10 CPN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871
--- Comment #4 from Jürgen Reuter ---
(In reply to Richard Biener from comment #3)
> Seems to work on the branches but I can't reproduce on trunk either.
That is strange. Did you try to compile several
times? Sometimes it comes, sometimes it doe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871
--- Comment #7 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #6)
> Could be a result of my recent commit, r267953. I'll take a look tonight.
That would be my guess, too,
I think it has to do with the array
descriptor together w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81849
--- Comment #10 from Jürgen Reuter ---
Actually, it was Thomas Koenig in r267953, so not your commits, but very
close.^^ The report is PR88871.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871
--- Comment #12 from Jürgen Reuter ---
I can also confirm that with the provided patch our code completely compiles,
and all tests work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88871
--- Comment #13 from Jürgen Reuter ---
Is this ready to be submitted?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24878
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25095
--- Comment #7 from Jürgen Reuter ---
Indeed, ifort and PGI fortran flag this as an error in the implied DO
expression. Nagfor flags it just as an extension.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25714
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30123
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30438
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30733
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31009
--- Comment #7 from Jürgen Reuter ---
Seems also to me that this should be reconsidered whether there is still need
for optimization for the case of arrays not declared as contiguous.
1 - 100 of 725 matches
Mail list logo
