https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
--- Comment #23 from GCC Commits ---
The master branch has been updated by Tobias Burnus :
https://gcc.gnu.org/g:25f5e60eaa8b9ab7938c3e1a9c8ad4ffa444d997
commit r16-1430-g25f5e60eaa8b9ab7938c3e1a9c8ad4ffa444d997
Author: Yuao Ma
Date: Wed Ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120636
David Binderman changed:
What|Removed |Added
Keywords||needs-bisection,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614
--- Comment #10 from kugan at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #9)
> > > as mentioned by Andrew, it is important to clone and also resolve indirect
> > > calls. Those auto-FDO 0 may prevent it from happening.
> > > It is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77650
--- Comment #13 from Kees Cook ---
We've been systematically cleaning up Linux in preparation for enabling
-Wflex-array-member-not-at-end, but it's a long road.
I had to go digging into the Linux kernel to figure out why Clang was _not_
warning:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12596
pietro changed:
What|Removed |Added
CC||pietro at gcc dot gnu.org
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78251
pietro changed:
What|Removed |Added
CC||pietro at gcc dot gnu.org
--- Comment #15 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48026
--- Comment #13 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:dcb9af06212e8bb36e84a1b8498c625c29abeb6f
commit r16-1429-gdcb9af06212e8bb36e84a1b8498c625c29abeb6f
Author: Gwenole Beauchesne
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48026
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120216
--- Comment #3 from Benjamin Schulz ---
I now noticed that nvidia's hmm is denoted as
#pragma omp requires unified_address
I do not know what unified_shared memory then is. Perhaps thats really reserved
for onboard gpu's then.
The followin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41201
--- Comment #10 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:dcb9af06212e8bb36e84a1b8498c625c29abeb6f
commit r16-1429-gdcb9af06212e8bb36e84a1b8498c625c29abeb6f
Author: Gwenole Beauchesne
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115740
--- Comment #17 from Zhao Wei Liew ---
Oops, I meant
#if defined(__clang__) && (defined(__CUDA__) || defined(__HIP__))
The __HIP__ macro comes from
https://clang.llvm.org/docs/HIPSupport.html#predefined-macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115740
--- Comment #16 from Zhao Wei Liew ---
Upon further thought, the required macro should be
#if defined(__clang__) && defined(__CUDA__) && defined(__HIP__)
without any the guard on device mode or host mode. This is because we want
__builtin_abor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #19 from Jakub Jelinek ---
Note, we call in that function get_range_pos_neg first on _54
on the _55 = (sizetype) _54; statement (same block 11), that is the first
ranger query during expansion of that function and already there it re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115740
--- Comment #15 from Jonathan Wakely ---
https://llvm.org/docs/CompileCudaWithLLVM.html#detecting-clang-vs-nvcc-from-code
suggests that __CUDA_ARCH__ is the right macro (thanks to zhao)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115740
--- Comment #14 from Jonathan Wakely ---
I wonder if this would work:
--- a/libstdc++-v3/include/bits/c++config
+++ b/libstdc++-v3/include/bits/c++config
@@ -610,7 +610,9 @@ namespace std
# define _GLIBCXX_EXTERN_TEMPLATE -1
#endif
+#if !(__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118995
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77650
--- Comment #12 from uecker at gcc dot gnu.org ---
I don't know, but Clang warns even by default.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120510
--- Comment #7 from GCC Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:0ede0508cc6e249f6759ac1e51b34d0e905eae80
commit r16-1425-g0ede0508cc6e249f6759ac1e51b34d0e905eae80
Author: Martin Uecker
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77650
uecker at gcc dot gnu.org changed:
What|Removed |Added
CC||uecker at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82480
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77650
--- Comment #11 from qinzhao at gcc dot gnu.org ---
(In reply to uecker from comment #10)
> Should this warning be added to -Wall ?
I think that's a good idea to add it to -Wall.
but I am not sure whether it's too early to do it? my understanding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #21 from Andrew Macleod ---
In reply to Jakub Jelinek from comment #19)
> Note, we call in that function get_range_pos_neg first on _54
> on the _55 = (sizetype) _54; statement (same block 11), that is the first
> ranger query during
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120637
Bug ID: 120637
Summary: Memory leak in finalization gfortran 15.1.1
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119975
--- Comment #9 from GCC Commits ---
The master branch has been updated by Robert Dubner :
https://gcc.gnu.org/g:582dda08eabc8f7dc9c504c0010d778bd6ff09b2
commit r16-1424-g582dda08eabc8f7dc9c504c0010d778bd6ff09b2
Author: Robert Dubner
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #49 from John David Anglin ---
Testing this patch to try fix padding:
Index: gcc-15-15.1.0/src/gcc/ada/libgnarl/s-linux__hppa.ads
===
--- gcc-15-15.1.0.orig/src/gcc/ada/
foundBugs $ ../results.20250611.asan.ubsan/bin/gcc -w -Werror=return-type
-Werror=uninitialized -Werror=overflow -Werror=sequence-point -O3 bug1103.c
foundBugs $ (ulimit -t 60; time valgrind -q ./a.out)
real1m11.622s
user0m59.860s
sys 0m0.146s
foundBugs $
So no results in a time six
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116792
--- Comment #14 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:f867196566c8aa51fd8b18dc5956daeea49e7518
commit r16-1422-gf867196566c8aa51fd8b18dc5956daeea49e7518
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #20 from Jakub Jelinek ---
In all 3 cases the addition of the BB_RTL bbs looks like if we'd split one of
the edges (in the first case the ENTRY->succs[0] edge, in the latter case the
EDGE_FALSE_VALUE edge I think. So handling it in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
Jakub Jelinek changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #15 from Jakub Jelinek ---
Ok, managed to reproduce with
../configure 'CFLAGS= -O2 -funwind-tables -fasynchronous-unwind-tables
-fstack-clash-protection -Werror=return-type -g' 'CXXFLAGS= -O2 -funwind-tables
-fasynchronous-unwind-tab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #16 from Jakub Jelinek ---
Ok, self-contained testcase, this is miscompiled by stage1:
// PR middle-end/120629
// { dg-do run }
// { dg-options "-O2 -fprofile-generate -fno-exceptions -fno-rtti" }
__attribute__((noipa, noreturn, col
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #48 from John David Anglin ---
There is an endian issue in the call to ___pthread_cond_timedwait64
which breaks v18 on hppa:
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #18 from Jakub Jelinek ---
With --param=ranger-debug=all I see
21 range_of_expr(_57) at stmt __builtin_memset (_60, 0, _57);
22 range_of_stmt (_57) at stmt _57 = _56 * 4;
23 ROS dependence fill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120635
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83931
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120625
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120635
Bug ID: 120635
Summary: Support something like [[clang::no_specializations]]
attribute
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120634
Bug ID: 120634
Summary: Memory leak in prime-paths.cc selftests (and possibly
in general?)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83931
thakis at chromium dot org changed:
What|Removed |Added
CC||thakis at chromium dot org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 120604, which changed state.
Bug 120604 Summary: runtime error in ix86_expand_int_movcc
i386/i386-expand.cc:3612:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120604
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #14 from Andreas Schwab ---
It fails also with the generic target.
https://build.opensuse.org/package/live_build_log/devel:gcc:next/gcc16/openSUSE_Tumbleweed/x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #13 from Jakub Jelinek ---
Anyway, my main ws is Intel skylake-avx512, so can't easily do LTO
-march=znver2 profiledbootstraps. So unless it is reproduceable with some
other options (say -mavx512{bw,cd,dq} -mbmi2 -mlzcnt or somethin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120604
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119064
--- Comment #5 from Jakub Jelinek ---
(In reply to Jason Merrill from comment #3)
> This sounds fine, perhaps with a -Wc++26-compat warning about those names in
> earlier modes.
Ok, done now (but still just starting work on testcases).
> I'd l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116400
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120604
--- Comment #11 from GCC Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:76cbd678d123ed93f99c4c52456bc14290f19b7f
commit r16-1420-g76cbd678d123ed93f99c4c52456bc14290f19b7f
Author: Uros Bizjak
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116400
--- Comment #21 from GCC Commits ---
The master branch has been updated by Francois-Xavier Coudert
:
https://gcc.gnu.org/g:94e0f29b6b216a85a03b732a90f900b8b0e99c6b
commit r16-1419-g94e0f29b6b216a85a03b732a90f900b8b0e99c6b
Author: Francois-Xavi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119100
--- Comment #7 from GCC Commits ---
The master branch has been updated by Paul-Antoine Arras :
https://gcc.gnu.org/g:3ada458d344b13a49183278435d372fe9c7fef4b
commit r16-1418-g3ada458d344b13a49183278435d372fe9c7fef4b
Author: Paul-Antoine Arras
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119064
Jakub Jelinek changed:
What|Removed |Added
Attachment #61616|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120633
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #1 from Jian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #47 from John David Anglin ---
I have v18 patch installed into the build infrastructure for the Debian
gcc-15-15.1.0 package. I'm still seeing timeouts. For example,
WARNING: program timed out.
FAIL: gnat.dg/array39.adb execution
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119975
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> I did try to do a test for the existence of clock_gettime in
> libgcobol/configure.ac. That test is
>
> # Copied from gcc/configure.ac. 2025-06-05 R.J.Dubner
> # At least for glibc,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120422
Robert Dubner changed:
What|Removed |Added
Resolution|--- |INVALID
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119975
--- Comment #7 from Robert Dubner ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #6)
> > commit r16-1193-g2e334900f4ddcd804e3b324402544a572d306ab6
> > Author: Robert Dubner
> > Date: Thu Jun 5 10:53:02 2025 -0400
> >
> > cobo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #12 from Jakub Jelinek ---
(In reply to Andreas Schwab from comment #10)
> 8154fc95f097a146f9c80edcaafb2baff73065b5 is the first bad commit
> commit 8154fc95f097a146f9c80edcaafb2baff73065b5
> Author: Jakub Jelinek
> Date: Tue Jun
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
Sam James changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #11 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
Andreas Schwab changed:
What|Removed |Added
Blocks||120434
Component|ipa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120622
--- Comment #7 from Martin Jambor ---
Thank you very much for your analysis. The commit you referenced indeed does
not help.
I have filed a new upstream issue:
https://github.com/serge-sans-paille/pythran/issues/2324
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120633
Bug ID: 120633
Summary: std::is_trivially_copyable_v in C++20
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120632
Bug ID: 120632
Summary: AArch64 SVE build of GROMACS measurably slower with
GCC than LLVM
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: aarch64-sve,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120303
--- Comment #5 from GCC Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:556a882feeaa7be7518fed3d97a3986a61ca9e45
commit r16-1416-g556a882feeaa7be7518fed3d97a3986a61ca9e45
Author: Martin Uecker
Date: W
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120610
--- Comment #2 from David Malcolm ---
Keeping open: the above patch merely mitigates the worst of it, but the
unbalanced tokens still occur, and still lead to suboptimal html.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
--- Comment #22 from GCC Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:d14d9793bfb795193b3ed972c4930d75cf8a026b
commit r12-11135-gd14d9793bfb795193b3ed972c4930d75cf8a026b
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120604
--- Comment #10 from David Binderman ---
(In reply to David Binderman from comment #9)
> Bootstrapping now. It will take 6-12 hours to complete.
Completed with success with flags "-g -O2 -march=znver3".
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120548
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614
--- Comment #9 from Jan Hubicka ---
> > as mentioned by Andrew, it is important to clone and also resolve indirect
> > calls. Those auto-FDO 0 may prevent it from happening.
> > It is easy to see in perf profile if the functions are cloned.
> >
orithms: zlib zstd
gcc version 16.0.0 20250611 (experimental) (GCC)
> > as mentioned by Andrew, it is important to clone and also resolve indirect
> > calls. Those auto-FDO 0 may prevent it from happening.
> > It is easy to see in perf profile if the functions are cloned.
> >
> > My overall plan is to combine autofdo with guessed profile, when autofdo
> > samples
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #9 from Sam James ---
OK, reproduced with:
```
$ ~/git/gcc/configure --prefix=/usr --with-build-config="bootstrap-lto
bootstrap-O3" BOOT_CFLAGS="-O3 -march=znver2" BOOT_CXXFLAGS="-O3 -march=znver2"
$ make profiledbootstrap -j$(nproc)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #46 from hainque at adacore dot com ---
Thanks for this check and for you input, Dave, this is really helpful.
I'm setting up to test v18 here as well.
Cheers,
Olivier
On Sun, 8 Jun 2025 at 23:30, danglin at gcc dot gnu.org <
gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120390
--- Comment #9 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:01789efaea25a48ac45dae8facb6db8abd8ebb14
commit r16-1412-g01789efaea25a48ac45dae8facb6db8abd8ebb14
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115606
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118444
Bug 118444 depends on bug 115606, which changed state.
Bug 115606 Summary: C++ front-end marks the return slot as addressable early on
which prevents tail call being marked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115606
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115740
Jonathan Wakely changed:
What|Removed |Added
Resolution|MOVED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115606
--- Comment #9 from Andrew Pinski ---
>- why return slot opt at the gimple level is target specific?
TO answer this question is simple, RSO is only for aggregates that returns in
memory. Which happens for Foo for the arm target. While on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614
--- Comment #7 from kugan at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #6)
> Also BTW, I think it is useful to do the dumps wth -details-blocks since
> that also dumps BB count inconsistencies caused by AutoFDO that are
> otherwis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82705
Andrew Pinski changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614
--- Comment #8 from kugan at gcc dot gnu.org ---
(In reply to Jan Hubicka from comment #6)
> Also BTW, I think it is useful to do the dumps wth -details-blocks since
> that also dumps BB count inconsistencies caused by AutoFDO that are
> otherwis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115740
--- Comment #12 from Jonathan Wakely ---
Apparently this is still a problem (pytorch just stopped using std::clamp
apparently) but I'm unable to reproduce any errors:
https://cuda.godbolt.org/z/EM4aqqczx
In the absence of a reproducer nothing i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115606
Andrew Pinski changed:
What|Removed |Added
Depends on||82705
--- Comment #7 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115606
--- Comment #6 from Andrew Pinski ---
Here is a reduced testcase for aarch64:
```
class Foo {
public:
int a, b[1024];
Foo(int a, int b);
};
Foo __attribute__((noinline,noclone,noipa))
callee (int i);
Foo __attribute__((noinline,noclone,noi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120598
--- Comment #5 from Manjul Mohan ---
Created attachment 61622
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61622&action=edit
Attached the preprocessed source file generated using -save-temps. Let me know
if further cleanup is needed.
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120628
Jakub Jelinek changed:
What|Removed |Added
Status|REOPENED|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120628
--- Comment #3 from Jakub Jelinek ---
Created attachment 61621
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61621&action=edit
gcc16-pr120628.patch
Untested fix on top of the
https://gcc.gnu.org/pipermail/gcc-patches/2025-June/686210.htm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57485
Andrew Pinski changed:
What|Removed |Added
CC||roland.illig at gmx dot de
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44675
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57485
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> *** Bug 104316 has been marked as a duplicate of this bug. ***
Funny I Did the same analysis there as I have here :). Without realizing it
too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104316
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57485
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |tree-optimization
Depends on|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120548
--- Comment #7 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:c92bc1e435e48e85fecf08dafe9d62a30a46a773
commit r14-11838-gc92bc1e435e48e85fecf08dafe9d62a30a46a773
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99832
--- Comment #21 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:b5d386495b3f8e638acaab3f7f2ada2c7a3d0f55
commit r14-11836-gb5d386495b3f8e638acaab3f7f2ada2c7a3d0f55
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44675
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44675
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |INVALID
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #8 from Andrew Pinski ---
(In reply to Andreas Schwab from comment #7)
> There are crashes also on arm64 and ppc64le, while compiling stage1
> libstdc++:
>
> https://build.opensuse.org/package/live_build_log/devel:gcc:next/gcc16/
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #7 from Andreas Schwab ---
There are crashes also on arm64 and ppc64le, while compiling stage1 libstdc++:
https://build.opensuse.org/package/live_build_log/devel:gcc:next/gcc16/openSUSE_Factory_ARM/aarch64
https://build.opensuse.org
h: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 16.0.0 20250611 (experiment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Summary|[16 regre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #6 from Andrew Pinski ---
Since this happening during the building of gengtype, you could reduce the
enable languages down to just `c,c++` at least that will speed up the building
that way.
1 - 100 of 101 matches
Mail list logo
