https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120630
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:00aa59e5b120e4f5f70dcabafa57f7d4b5b9ad5d
commit r16-1489-g00aa59e5b120e4f5f70dcabafa57f7d4b5b9ad5d
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117030
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119496
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Giuseppe D'Angelo :
https://gcc.gnu.org/g:c9a6c1b5a763d0d3f7a369ed281f9009f270939a
commit r16-1488-gc9a6c1b5a763d0d3f7a369ed281f9009f270939a
Author: Giuseppe D'Angelo
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120587
--- Comment #2 from GCC Commits ---
The master branch has been updated by Stafford Horne :
https://gcc.gnu.org/g:c0694f95f591ee49dd0fc3d3bef4765bf36ab5a4
commit r16-1486-gc0694f95f591ee49dd0fc3d3bef4765bf36ab5a4
Author: Stafford Horne
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117030
--- Comment #5 from Marek Polacek ---
Fixed?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120641
--- Comment #2 from Pierre Ossman ---
It's problematic when you are trying to adopt a "no warnings" approach to your
development. This severely undermines that, as you train the developers back in
to ignoring warning messages.
It also seems exc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120640
--- Comment #2 from Vlad Serebrennikov ---
Yes, because in this case it's an elaborated-type-specifier, and name lookup is
type-only. The original example should be diagnosed in pedantic mode at the
very least.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120640
--- Comment #1 from Daniel Krügler ---
It looks to me like an extension of the "struct stat" hack, where typename
takes the role of struct such as in:
```
namespace N {
class A {};
int A();
}
class N::A a; // everyone accepts
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120641
--- Comment #1 from Andrew Pinski ---
I am not sure this is not unwanted. The abi is changed between 6 and 7 (fixed
to be following the specs). And we are warning about that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120604
--- Comment #14 from GCC Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:03e87c78d399e7fd9510a7db3025a9ed1393e874
commit r16-1483-g03e87c78d399e7fd9510a7db3025a9ed1393e874
Author: Uros Bizjak
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120639
--- Comment #1 from Robin Dapp ---
I'm just realizing that without knowing the stride statically, we'd generate a
lot of code as we don't have a way of setting an element size for loads
dynamically. Although riscv offers a dynamic element size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #25 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:701a7cceba56217b466b5854d1e145bbf52679ac
commit r16-1482-g701a7cceba56217b466b5854d1e145bbf52679ac
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120641
Bug ID: 120641
Summary: Parameter passing warning from libstdc++ header
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #50 from John David Anglin ---
On second thought, maybe the tv_nsec field in the ada timspec record
should also be type time_t?
#if __TIMESIZE == 64
# define __timespec64 timespec
#else
#include
/* The glibc Y2038-proof struct __ti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120625
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120625
--- Comment #2 from GCC Commits ---
The releases/gcc-15 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:bbe9ec92138b1dfc7c61a3d8db7351ee57586388
commit r15-9828-gbbe9ec92138b1dfc7c61a3d8db7351ee57586388
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
Jonathan Wakely changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120640
Bug ID: 120640
Summary: Keyword 'typename' should not affect qualified name
lookup
Product: gcc
Version: 15.1.1
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
--- Comment #6 from chenglulu ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 61628 [details]
> gcc16-pr120638.patch
>
> Untested fix.
So cool! My problem can be resolved!
Thanks very much!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120630
--- Comment #3 from Zhendong Su ---
Here is a test without using any flags (fails at -O{s,2,3}), assuming it's due
to the same root cause:
[595] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120295
Martin Jambor changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Eve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120295
--- Comment #12 from GCC Commits ---
The releases/gcc-15 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:f5fc1c6a169bfa6ebe569c701f293b55e5a3490e
commit r15-9827-gf5fc1c6a169bfa6ebe569c701f293b55e5a3490e
Author: Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120624
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:8546265e2ee386ea8a4b2f9150ddfed32c9d15ea
commit r16-1476-g8546265e2ee386ea8a4b2f9150ddfed32c9d15ea
Author: Richard Sandiford
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120630
--- Comment #2 from Jakub Jelinek ---
I guess one more testcase doesn't hurt. If/when the PR120629 patch is
approved, I'll commit this one too and close.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120636
Sam James changed:
What|Removed |Added
Target Milestone|--- |16.0
Summary|-O3 runtime problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120630
--- Comment #1 from Sam James ---
This seems to pass with Jakub's fix for PR120629. Up to him if he wants a
non-PGO case or not. Given this involves disabling some passes too, not sure
it's strictly better as a testcase, but up to him.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120624
Richard Sandiford changed:
What|Removed |Added
Known to work||16.0
Summary|aarch64: In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109
--- Comment #23 from Antony Lewis ---
New report, possibly related to underlying finalization issues:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120637
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
--- Comment #4 from chenglulu ---
(In reply to Jakub Jelinek from comment #3)
> Ah, that seems like a bug in the recip pass.
> Before that we have
> # RANGE [frange] float [1.0e+0 (0x0.8p+1), 4.294967296e+9 (0x0.8p+33)]
> _4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
--- Comment #3 from Jakub Jelinek ---
Ah, that seems like a bug in the recip pass.
Before that we have
# RANGE [frange] float [1.0e+0 (0x0.8p+1), 4.294967296e+9 (0x0.8p+33)]
_4 = (float) _3;
# RANGE [frange] float [1.0e+0 (0x0.8p+1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614
--- Comment #13 from Jan Hubicka ---
> I re-tested and can confirm that it is working now. Sorry for the false alarm.
I was fixing bug in this area recently, so perhaps you just had older
tree. Should have mentioned that - sorry for that.
I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120629
--- Comment #23 from Sam James ---
(In reply to Jakub Jelinek from comment #22)
> Created attachment 61626 [details]
> gcc16-pr120629.patch
>
> Untested fix.
Thanks. This restores bootstrap for me and regtests fine (one "regression" in
c761007
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120608
--- Comment #11 from Jakub Jelinek ---
Untested patch which fixes the #c5 testcase at -O0 -fsanitize=address.
There all that needs to be done is emit the asan epilogue sequence before the
musttail call(s) instead of disabling the tail call when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120639
Robin Dapp changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120625
--- Comment #1 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:76bf78d32c683af3bf88f4aef595048edbd82372
commit r16-1462-g76bf78d32c683af3bf88f4aef595048edbd82372
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
Sam James changed:
What|Removed |Added
Target Milestone|--- |16.0
Summary|Optimization errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
--- Comment #2 from chenglulu ---
I compared the test.c.141t.dom2 and testf.c.208t.dom3
dom2：
```
range_of_expr (_5) [frange] float [1.0e+0 (0x0.8p+1), 6.5536e+4 (0x0.8p+17)]
range_of_expr (_6) [frange] float [7.62939453125e-6 (0x0.8p-16), 5.0e-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120639
Bug ID: 120639
Summary: vect: Strided memory access type, stores with gaps?
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120231
Sam James changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119650
--- Comment #5 from GCC Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:c291bde420556c69423961f59ef6765dc6c4c547
commit r16-1465-gc291bde420556c69423961f59ef6765dc6c4c547
Author: Gaius Mulley
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
chenglulu changed:
What|Removed |Added
CC||chenglulu at loongson dot cn
Ta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120638
Bug ID: 120638
Summary: Optimization errors caused by frange calculation
errors
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120489
--- Comment #2 from Wentao Zhang ---
> The "continue" at line 10 should have never been executed. The wrongly
> reported "1" contradicts with (1) "#" at its previous line (2) the
> relationship among if-then-else.
Sorry I was trying to say
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52641
--- Comment #33 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:07f229c2d7ee6b604e5a86092e675d5d36c1ba4e
commit r16-1435-g07f229c2d7ee6b604e5a86092e675d5d36c1ba4e
Author: Georg-Johann Lay
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120637
--- Comment #1 from Antony Lewis ---
Here's a code that reproduces a similar issue without explicit final.
module MiscUtils
implicit none
contains
logical function isFloat0(R)
class(*), intent(in) :: R
select type(R)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120604
--- Comment #13 from Uroš Bizjak ---
Created attachment 61627
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61627&action=edit
Additional patch to make sure we can represent the difference
Actually, we have to make sure we can represent t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117811
--- Comment #26 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:07f229c2d7ee6b604e5a86092e675d5d36c1ba4e
commit r16-1435-g07f229c2d7ee6b604e5a86092e675d5d36c1ba4e
Author: Georg-Johann Lay
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614
--- Comment #12 from kugan at gcc dot gnu.org ---
(In reply to kugan from comment #11)
> This specific ICE seems to be fixed with
> e416c8097fc87513e05c2d104c63488f733758c0
> Thanks for the fix.
>
> I am now seeing one in:
>
> x264_src/common/m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120614
--- Comment #11 from kugan at gcc dot gnu.org ---
This specific ICE seems to be fixed with
e416c8097fc87513e05c2d104c63488f733758c0
Thanks for the fix.
I am now seeing one in:
x264_src/common/mc.c: In function 'mc_weight_w16.part.0':
x264_src/c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120636
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
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
pietro ---
(In reply to Eric Gallager from comment #14)
> So, there's been some talk about how replacing GCC's local copies of stuff
> from gettext with an external gettext that might be relevant to this bug:
> https://gcc.gnu.org/pipermail/gcc/2022-June/238920.html
intl was
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
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/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120636
Bug ID: 120636
Summary: -O3 runtime problems with recent gcc
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
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
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
1 - 100 of 281129 matches
Mail list logo
