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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475
Bug ID: 114475
Summary: [14.0 Regression] Regression with iso_c_binding and
submodules
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113471
Bug ID: 113471
Summary: [14 regression] wrong array bound check failure on
valid code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112460
Bug ID: 112460
Summary: ICE with parameterized derived types (incorrect code,
should be rejected)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110698
Bug ID: 110698
Summary: Bootstrap fails with [-Werror=unused-but-set-variable]
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110691
Bug ID: 110691
Summary: Segmentation fault on valid F2018 code
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110576
Bug ID: 110576
Summary: ICE on compilation
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee:
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110326
Bug ID: 110326
Summary: [gcc 14.0 regression]
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110311
Bug ID: 110311
Summary: [gfortran 14.0 regression]
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109209
Bug ID: 109209
Summary: [13.0 regression] erroneous error on assignment of
alloctables
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107253
Bug ID: 107253
Summary: gcc does not compile with XCode 14.0.1 / clang 14.0.0
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106720
Bug ID: 106720
Summary: gcc does not compile with XCode 13.4.1 / clang 13.1.6
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104164
Bug ID: 104164
Summary: Bogus warning issued by -Wsurprising
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102992
Bug ID: 102992
Summary: Piping in a file does no longer work on macOS Monterey
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102968
Bug ID: 102968
Summary: macOS Monterey not yet supported in configure
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102304
Bug ID: 102304
Summary: Internal compiler error: in gen_lowpart_general,
rtlhooks.c: 57
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
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:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100340
Bug ID: 100340
Summary: Bootstrap fails with Clang 12.0.5 (XCode 12.5)
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
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 149 matches
Mail list logo
