https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475
--- Comment #1 from Jürgen Reuter ---
I suspect this commit here,
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=44c0398e65347def316700911a51ca8b4ec0a411
but not totally certain.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Between ca. March 18 and March 25, a regression has been introduced into the
gfortran 14.0.1 code, which makes the following valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113471
--- Comment #3 from Jürgen Reuter ---
(In reply to anlauf from comment #2)
> The following patch fixes the reduced testcase for me, as well as the
> full testcase in comment#0:
>
> diff --git a/gcc/fortran/trans-array.cc
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Created attachment 57136
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57136=edit
Reproducer, 154 lines
Very lik
: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
This is probably known (then it can be marked as duplicate), but let me report
it nevertheless. The following code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #56 from Jürgen Reuter ---
What do we do now? We know the offending commit, and the commit that fixed (or
"fixed") it. Closing? Do we understand what happened here, so why it went wrong
and why it got fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #55 from Jürgen Reuter ---
Actually, according to my testing, the last commit where the gfortran produced
failing code,
ishttps://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c496d15954cdeab7f9039328f94a6f62cf893d5f
(Aldy Hernandez A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #54 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #53)
> Additional comment: the commit which fixed/"fixed" this offending commit
> came between July 3 and July 10.
Wildly speculating, it would be this commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #53 from Jürgen Reuter ---
Additional comment: the commit which fixed/"fixed" this offending commit came
between July 3 and July 10.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #52 from Jürgen Reuter ---
(In reply to Jakub Jelinek from comment #51)
> The easiest would be to bisect gcc in the suspected ranges, that way you'd
> know for sure which git commit introduced the problem and which
> fixed/"fixed"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #50 from Jürgen Reuter ---
How to proceed here? Since almost exactly a month the current gcc git master
doesn't show this problem anymore, from our CI I can deduce that the version on
July 3rd still failed, while the version on July
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
This seems to be a very recent problem: last week (as of July 10) the bootstrap
did still work with the gcc master, and now it is failing, cf. below
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110691
--- Comment #1 from Jürgen Reuter ---
Created attachment 55560
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55560=edit
Shorter reproducer that gives bogus entries.
This shorter reproducer gives (with gfortran 11.3) bogus output, and
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Created attachment 7
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=7=edit
Reproducer
The attached code (which I believe to be valid F2018) le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576
--- Comment #4 from Jürgen Reuter ---
Created attachment 55526
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55526=edit
Minimal reproducer, also as attachment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576
--- Comment #3 from Jürgen Reuter ---
Here is a mininal reproducer:
module process_mci
implicit none
private
public :: process_mci_entry_t
type :: process_mci_entry_t
integer :: i_mci = 0
integer, dimension(:), allocatable ::
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576
Jürgen Reuter changed:
What|Removed |Added
Known to fail||11.3.0
--- Comment #2 from Jürgen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576
--- Comment #1 from Jürgen Reuter ---
Created attachment 55525
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55525=edit
Simpler reproducer in a single file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #49 from Jürgen Reuter ---
(In reply to anlauf from comment #48)
> (In reply to anlauf from comment #47)
> > However, when I use -O2 together with an -march= flag, the code works.
> > I've tested -march=sandybridge, -march=haswell,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #46 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #45)
> Created attachment 55492 [details]
> Smaller stand-alone reproducer
>
> I will give more information in a comment, this contains 3 files and a
> Makefile.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #45 from Jürgen Reuter ---
Created attachment 55492
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55492=edit
Smaller stand-alone reproducer
I will give more information in a comment, this contains 3 files and a
Makefile.
: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Created attachment 55490
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55490=edit
reproducer
The following reproducer leads to an ICE which I see already with gfortran
1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #44 from Jürgen Reuter ---
(In reply to anlauf from comment #43)
> Mabye the fprem issue was a red herring from the beginning, pointing to a
> problem in a different place.
>
> I recompiled each module in a loop with -O0 until the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #42 from Jürgen Reuter ---
(In reply to Jakub Jelinek from comment #41)
>
> 0x04f5dc90 is pseudo NaN:
> Pseudo Not a Number. The sign bit is meaningless. The 8087 and 80287 treat
> this as a Signaling Not a Number. The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #38 from Jürgen Reuter ---
At the moment unfortunately too busy to provide a smaller reproducer (which
also still has a small dependency on a dynamic library), but one more info:
inserting the explicit operations instead of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #29 from Jürgen Reuter ---
(In reply to anlauf from comment #28)
> Update: recompiling that file with 13-branch fails for me, too.
> Playing with the one-line patch for pr86277 makes no difference, fortunately.
>
> Compiling the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #26 from Jürgen Reuter ---
(In reply to anlauf from comment #25)
> Unfortunately, there is no main.f90, which is needed to build whizard.
>
Indeed, sorry, cf. below
> The Makefile needs to be modified to take into account that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #24 from Jürgen Reuter ---
Here is a first reproducer without the need for OCaml, unfortunately a bit too
big to be uploaded, here is the link:
https://www.desy.de/~reuter/downloads/repro001.tar.xz
the tarball contains Fortran files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #22 from Jürgen Reuter ---
(In reply to anlauf from comment #21)
> I forgot to mention that you need to check that the location where a symptom
> is seen sometimes may not be the location of the cause.
Indeed, I think you are right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #19 from Jürgen Reuter ---
(In reply to anlauf from comment #18)
> (In reply to Jürgen Reuter from comment #17)
> > How would I set up such a bisection for the n git commits between June 12 to
> > June 19? Unfortunately, I cannot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #17 from Jürgen Reuter ---
How would I set up such a bisection for the n git commits between June 12 to
June 19? Unfortunately, I cannot really get a small reproducer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #16 from Jürgen Reuter ---
It seems that it is this function where the NaNs appear:
function mult_mod (a, b, c, m) result (v)
real(default), intent(in) :: a
real(default), intent(in) :: b
real(default), intent(in) :: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #14 from Jürgen Reuter ---
Did anybody manage to reproduce this?
Download https://whizard.hepforge.org/downloads/?f=whizard-3.1.2.tar.gz
You need OCaml as a prerequisite, though.
Then configure, make,
cd tests/functional_tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #13 from Jürgen Reuter ---
I changed the component from fortran to tree-optimization, as the problematic
commit during that week was in that component. The only commit in the fortran
component turns out to be unproblematic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #12 from Jürgen Reuter ---
Any idea which commit could cause such an issue? At least I now understand that
in our program the random number object gets undefined and produces NaNs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
Jürgen Reuter changed:
What|Removed |Added
Component|tree-optimization |fortran
Keywords|wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #10 from Jürgen Reuter ---
*** Bug 110326 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110326
Jürgen Reuter changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110326
--- Comment #2 from Jürgen Reuter ---
Closed as a duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110326
--- Comment #1 from Jürgen Reuter ---
This should be closed as a duplicate of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #9 from Jürgen Reuter ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Jürgen Reuter from comment #7)
> > The problem seems really connected to optimization, if I compile our code
> > with -g -O0 or -g -O1, everything
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #7 from Jürgen Reuter ---
The problem seems really connected to optimization, if I compile our code with
-g -O0 or -g -O1, everything works ok. Next, I will try to check why it is
actually failing (my guess, unconfirmed yet, is that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #5 from Jürgen Reuter ---
(In reply to anlauf from comment #4)
> Jürgen,
>
> I'm afraid we need a reproducer. Or can you bisect the regression further?
In principle, I could. But I just undid this commit of yours which is just
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Hi,
let me open up an issue already. I believe there was a regression introduced in
gcc between June 11 and June 19, as our CI with a git-clone built gcc worked
last week, and fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #3 from Jürgen Reuter ---
I redid this change here:
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index
e1c75e9fe0266d760b635f0dc7869a00ce53bf48..e7c51bae052b1e0e3a60dee35484c093d28d4653
100644 (file)
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
Jürgen Reuter changed:
What|Removed |Added
CC||anlauf at gmx dot de
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
--- Comment #1 from Jürgen Reuter ---
It looks like there were no specific changes in the fortran backend or the
libgfortran but a lot of optimization in the middle-end. Maybe that is
responsible for this issue. Need to see what is going on.
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Hi,
let me open up an issue already. I believe there was a regression introduced in
gfortran between June 11 and June 19, as our CI with a git-clone built
gcc/gfortran worked last week
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #16 from Jürgen Reuter ---
(In reply to Paul Thomas from comment #14)
> For the record, the fix is:
>
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 1d973d12ff1..1a03e458d99 100644
> ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #10 from Jürgen Reuter ---
(In reply to Tobias Burnus from comment #8)
> The debugger shows for the example in comment 4 for the line
>
>69 | history_new(1:s) = res_set%history(1:s)
>
> the following expression:
>
> (gdb)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #9 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #4)
>
> module subroutine t3_set_expand (res_set)
> class(t3_set_t), intent(inout) :: res_set
> type(t3_t), dimension(:), allocatable :: history_new
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #7 from Jürgen Reuter ---
It looks like it is NOT Harald's and Tobias' commit,
https://github.com/gcc-mirror/gcc/commit/901edd99b44976b3c2b13a7d525d9e315540186a
I reverted that one, and still get the error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #6 from Jürgen Reuter ---
Actually could be also this commit here:
commit 901edd99b44976b3c2b13a7d525d9e315540186a
Author: Harald Anlauf
Date: Tue Mar 14 20:23:06 2023 +0100
Fortran: rank checking with explicit-/assumed-size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #5 from Jürgen Reuter ---
This could be either this commit
commit d7caf313525a46f200d7f5db1ba893f853774aee
Author: Paul Thomas
Date: Sat Mar 18 07:56:23 2023 +
/Fortran
I think, it is NOT this one:
commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #4 from Jürgen Reuter ---
Here is the promised reproducer, which fails even when not using submodules:
$ gfortran -c reproducer.f90
reproducer.f90:69:4:
69 | history_new(1:s) = res_set%history(1:s)
|1
Error:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #3 from Jürgen Reuter ---
Created attachment 54713
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54713=edit
Promised short reproducer, 73 lines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #2 from Jürgen Reuter ---
Created attachment 54712
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54712=edit
Second, single-file reproducer, still 6295 lines
Still further reducing, stay tuned.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
--- Comment #1 from Jürgen Reuter ---
Created attachment 54710
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54710=edit
First still pretty large reproducer
I will provide a smaller reproducer soon.
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Some commit between last week and now, so between March 12 and March 19, has
created a regression, so gfortran throws a (presumably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568
--- Comment #13 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #12)
.
>
> Next, I guess I'll pick up the xc 14.2 release.
Sorry, my bad, I misplaced the position of the argument
BOOT_CFLAGS, I erroneously (like for configure,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568
--- Comment #10 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #9)
> (I don't have a macOS13 setup yet, limited hardware available here)
>
> ... so, if it is not fixed in the Xcode 14.x releases, we'll have to work
> around it in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107568
--- Comment #8 from Jürgen Reuter ---
What is the status of this problem? I checked with Darwin 22.2 and XCode 14.2,
and the problem still persists with the Git master, cf. below. Is there a
workaround for the moment? Will this be resolved
Component: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The linking during bootstrap on Darwin 21.6.0 with Xcode 14.0.1 chokes on the
error message below, the configure line has been:
../configure --prefix=/usr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106720
Jürgen Reuter changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106720
--- Comment #2 from Jürgen Reuter ---
Hi Jakub,
this is the compilation command:
g++ -std=c++11 -I../../libcpp -I. -I../../libcpp/../include -I./../intl
-I../../libcpp/include -g -W -Wall -Wno-narrowing -Wwrite-strings
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Trying to compile the full gcc on Darwin x86_64 (not M1, darwin-arm64, not
checked yet), the gcc 13.0.0 (git clone as of today) fails to compile
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The code below (using iso_varying_string and a child module in the same module
gives a bogus warning from -Wsurprsing
reproducendum.f90:110:6:
110 | use diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #35 from Jürgen Reuter ---
Now that macOS 12.1 is out (and XCode 13.2) could someone please check whether
the problem has been solved from the side of the Darwin kernel?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115
--- Comment #6 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #5)
> I can confirm the ICE with current trunk both on x86_64 and
> on POWER.
>
> x86_64:
>
> $ gfortran -v
> Es werden eingebaute Spezifikationen verwendet.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #31 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #29)
> (In reply to Francois-Xavier Coudert from comment #28)
> I've posted a fix for this (it is the fix for darwin21 DTORs in general)
> however CAVEAT : there is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #24 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #23)
> (In reply to Jürgen Reuter from comment #22)
> > (In reply to Thomas Koenig from comment #20)
> > > (In reply to Iain Sandoe from comment #16)
> > > > (In reply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #22 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #20)
> (In reply to Iain Sandoe from comment #16)
> > (In reply to Thomas Koenig from comment #14)
>
> There is always the reason of not breaking compatibility, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #21 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #19)
> (In reply to Jürgen Reuter from comment #18)
>
> > write(0x1, " Hello, world!\\n\n\0", 0x11)= 17 0
>
> Hmm, was this actually the string that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #18 from Jürgen Reuter ---
(In reply to Thomas Koenig from comment #13)
> Here is a complete strace of a "Hello, world" program on Linux, compiled
> with -static-libgfortran (to remove some of the shared library loading :-)
> and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103007
--- Comment #8 from Jürgen Reuter ---
(In reply to Jürgen Reuter from comment #6)
> Created attachment 51716 [details]
> gfortran appearance of the ICE
Just for completeness, this example needs to be compiled with -O2, while
-O0 and -O1 work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103007
--- Comment #6 from Jürgen Reuter ---
Created attachment 51716
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51716=edit
gfortran appearance of the ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103007
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #12 from Jürgen Reuter ---
I'm not an expert on the I/O system, but could it be that the unit to which the
stdout of a compiled Fortran program goes does not provide the unit that the
redirect function (now) expects under macOS 12?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #10 from Jürgen Reuter ---
Reassuringly, the gfortran 11.2 from Macports has the same problem as the
gfortran 12.0.0 installed by hand: no redirecting into files.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #9 from Jürgen Reuter ---
I also tried that for a Fortran program ./a.out | less (pipe to less) works.
It's just the redirection that does not work. I'm waiting for the compilation
to check whether gfortran 11.2 from Macports shares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #5 from Jürgen Reuter ---
I checked that the assembler code on macOS Big Sur and Monterey is identical
(up to the date in the .ident line). So either the assembler works differently,
or one of the routines from the libgfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #4 from Jürgen Reuter ---
The problem is not related to XCode 13.1 which appeared at roughly the same
time. On Big Sur with XCode 13.1 still all works as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
--- Comment #1 from Jürgen Reuter ---
Using a C program compiled with the same version (recent trunk with the fix by
Iain Sandoe for Monterey) leads to a program that can pipe to a file.
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
I don't know whether this is really an issue with gfortran or a screwed setting
of my macOS installation, I have macOS 12.0.1 Monterey, Darwin 21.1.0
: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
Under macOS Monterey 12.0.1 Darwin 21.1.0 the configure doesn't work, but bails
out with the message:
"Error: configuring for an unreleased masOS version x86_64-
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
The compilation of gcc (using gcc-10.2.1 from Debian) fails with an Internal
Compiler Error of .xgcc.
I don't know whether
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87980
--- Comment #8 from Jürgen Reuter ---
The actual workaround that I'm using (the code is from of our stale branches
which recently became active again) is:
[...]
subroutine qn_string_set (qns, col)
class(qn_string_t), intent(inout) :: qns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87980
--- Comment #7 from Jürgen Reuter ---
Is anybody ever looked into this? Any updates?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #12 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #11)
> > 1. Update to XCode 12.5.1 (which apparently exists, but I don't know if it
> > has the fixes?)
>
> not yet checked - but if someone has time I'd like to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199
--- Comment #5 from Jürgen Reuter ---
(In reply to ygal klein from comment #4)
>)
>
> Thank you for the reply.
>
> After posting the bug report - I saw that implementing (inout) as your
> number 1 suggestion - dodges the problem - though as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101199
Jürgen Reuter changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86206
--- Comment #4 from Jürgen Reuter ---
Still present in v12.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881
--- Comment #5 from Jürgen Reuter ---
I checked again, and I don't see any issues any more. There might still be some
memory leaks, I haven't checked. Would it make sense to close this one and open
a new report in case there is a definite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #8 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #6)
>
> 1. (re-)install xcode 12.4 command line tools and select them for use
> 2. disable debug comparison in the bootstrap ( --without-build-config )
Just to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #4 from Jürgen Reuter ---
(In reply to Dominique d'Humieres from comment #3)
> Confirmed.
Merci, Dominique. Would you actually advise to compile without bootstrap and
start using gcc, or wait until the reason for the bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #2 from Jürgen Reuter ---
I just check, with --disable-bootstrap, gcc compiles to the end. Just the
checksums of the object files for bootstrap between stage 2 and 3 don't agree.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
--- Comment #1 from Jürgen Reuter ---
After update to macOS Big Sur 11.3 with XCode 12.5 and Apple Clang
clang-1205.0.22.9, bootstrap doesn't work any more:
Comparing stages 2 and 3
warning: gcc/cc1obj-checksum.o differs
warning:
: bootstrap
Assignee: unassigned at gcc dot gnu.org
Reporter: juergen.reuter at desy dot de
Target Milestone: ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602
--- Comment #36 from Jürgen Reuter ---
I can confirm that the push by Paul, 297363774e6a5dca2f46a85ab086f1d9e59431ac,
does fix all compilations and tests in our code and test suite.
1 - 100 of 678 matches
Mail list logo
