On Wed, 6 Aug 2025, ywgrit wrote:
> I have the following question:
>
> // Way.h
> struct waymapt
> {
> int fillnum;
> int num;
> };
> typedef waymapt* waymappt;
>
> class wayobj
> {
> public:
> int bound;
> int *maparp;
> waymappt waymap;
> int makebound2(int fillnum, int ite
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121422
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-08-06
Version|14.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113520
Richard Biener changed:
What|Removed |Added
Last reconfirmed|2024-01-22 00:00:00 |2025-8-6
--- Comment #10 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121422
Bug ID: 121422
Summary: [16 Regression] wrong code for proping zero
incorrectly
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118885
sadineniharish8446 at gmail dot com changed:
What|Removed |Added
CC||sadineniharish8446
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121405
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2025-08-06
Assignee|unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121370
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Version|unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121389
--- Comment #11 from Carlos Galvez ---
> Again I'll mention my rant that using heavily musttail attributes #ifndef
> __OPTIMIZE__ doesn't make much sense unless it is really required for the
> program not running out of stack. In the protobuf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85608
--- Comment #8 from Sam James ---
(In reply to Sam James from comment #7)
> *** Bug 121326 has been marked as a duplicate of this bug. ***
This shows up with qtwebengine. It's one of two issues (the other being
PR121321) from the large run I did
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85608
--- Comment #9 from Sam James ---
+left
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
Sam James changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #29 from Sam James ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102397
--- Comment #5 from Sam James ---
(In reply to sandra from comment #4)
> PR108796 seems to be more of a "GCC is broken because it doesn't do what I
> want" issue, than specifically a documentation issue.
I was thinking of documenting what you s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121421
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121421
Bug ID: 121421
Summary: [ICE] internal compiler error: Segmentation fault
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116375
--- Comment #6 from Andrew Pinski ---
Created attachment 62064
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62064&action=edit
Current patch which does not work
I have some new ideas on how to fix this. more related to
https://gcc.gnu.or
I have the following question:
// Way.h
struct waymapt
{
int fillnum;
int num;
};
typedef waymapt* waymappt;
class wayobj
{
public:
int bound;
int *maparp;
waymappt waymap;
int makebound2(int fillnum, int iters);
void create(int size);
};
// WayInit.cpp
#include
#includ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116375
--- Comment #5 from Andrew Pinski ---
So even with hacking the verifiers (for now) and getting this in the
.optimized:
```
void g ()
{
[local count: 1073741824]:
f ({}); [tail call]
return;
}
```
We still get a memset and a memcpy. So t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121306
--- Comment #13 from H.J. Lu ---
(In reply to Sam James from comment #12)
> Is this one fixed now, or does it still need Richard S's simplify-rtx patch
> (https://inbox.sourceware.org/gcc-patches/mpt34a7f5mk@arm.com/)?
Need this and
https:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121234
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jerry DeLisle :
https://gcc.gnu.org/g:3d496ed9a5821ae9188e5242c1e26eea80c4039f
commit r16-3024-g3d496ed9a5821ae9188e5242c1e26eea80c4039f
Author: Jerry DeLisle
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121420
--- Comment #8 from Andrew Pinski ---
(In reply to Sam James from comment #7)
> ->
> https://lore.kernel.org/linux-perf-users/
> fea380fb0934d039d19821bba88130e632bbfe8d.1754438581.git@gentoo.org/T/#u
>
> MOVED then?
Let's wait for the rep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121420
--- Comment #7 from Sam James ---
->
https://lore.kernel.org/linux-perf-users/fea380fb0934d039d19821bba88130e632bbfe8d.1754438581.git@gentoo.org/T/#u
MOVED then?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121420
--- Comment #6 from Andrew Pinski ---
s/FIELD_EXISTENCE/BPF_FIELD_EXISTS/
But you get the idea.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121420
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> I think this patch fixes the issue:
diff --git a/tools/perf/util/bpf_skel/sample_filter.bpf.c
b/tools/perf/util/bpf_skel/sample_filter.bpf.c
index b195e6efeb8b.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121420
--- Comment #4 from Andrew Pinski ---
I think this patch fixes the issue:
```
diff --git a/tools/perf/util/bpf_skel/sample_filter.bpf.c
b/tools/perf/util/bpf_skel/sample_filter.bpf.c
index b195e6efeb8b..f1ffef44f603 100644
--- a/tools/perf/util/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121420
--- Comment #3 from Andrew Pinski ---
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=3a8b8fc3174891c4c12f5766d82184a82d4b2e3e
introduced the brokenness after the Cupertino Miranda's patch.
commit 3a8b8fc3174891c4c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121420
--- Comment #2 from Andrew Pinski ---
This looks like it is doing the old way.
because GCC documentation says it should be just done as:
__builtin_preserve_field_info (arg->y, FIELD_BYTE_OFFSET);
https://gcc.gnu.org/onlinedocs/gcc/BPF-Built-i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121420
--- Comment #1 from Sam James ---
The header does:
#ifdef __clang__
#define ___bpf_field_ref1(field)(field)
#define ___bpf_field_ref2(type, field) (___bpf_typeof(type)->field)
#else
#define ___bpf_field_ref1(field)(&(field))
#d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121420
Bug ID: 121420
Summary: Failed to build BPF program accepted by Clang (error:
cannot take address of bit-field 'mem_hops')
Product: gcc
Version: 16.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93507
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121306
--- Comment #12 from Sam James ---
Is this one fixed now, or does it still need Richard S's simplify-rtx patch
(https://inbox.sourceware.org/gcc-patches/mpt34a7f5mk@arm.com/)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121370
Sam James changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rguenther at suse dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120145
--- Comment #9 from Kirill A. Korinsky ---
Meanwhile, I had a confirmation that GCC-15.1.0 fails the same way.
echo timestamp > stmp-int-hdrs
LC_ALL=C GCC_COLORS= /usr/ports/pobj/gcc-15.1.0/buil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121068
--- Comment #18 from GCC Commits ---
The trunk branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:bc42128330c0ea70a015b74b655cb8c48b6a8c06
commit r16-3022-gbc42128330c0ea70a015b74b655cb8c48b6a8c06
Author: Jason Merrill
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121419
--- Comment #5 from Andrew Pinski ---
LLVM's compiler-rt even depends on it always being expanded;
https://github.com/llvm/llvm-project/issues/12035 .
:)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121419
--- Comment #4 from Andrew Pinski ---
https://gitlab.freedesktop.org/libevdev/udev-hid-bpf/-/blob/main/src/bpf/testing/0010-WALTOP__Batteryless-Tablet.bpf.c?ref_type=heads
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121419
--- Comment #3 from Andrew Pinski ---
There might be a better way of implementing scaled_log2 rather than using
__builtin_clzg here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121419
Andrew Pinski changed:
What|Removed |Added
Target||bpf
--- Comment #2 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121419
--- Comment #1 from Sam James ---
I am not sure how these libcalls are handled for bpf. Are patterns supposed to
avoid it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121419
Bug ID: 121419
Summary: __clzdi2 emitted when building udev-hid-bpf
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121411
--- Comment #3 from Nick Alcock ---
Agreed. BTF is no better here, alas, since the kernel will never need anything
so huge... but this is an area where CTFv4 could encode a big array
differently, I suppose. Not designed yet. I wonder if we could
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121410
H.J. Lu changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121410
--- Comment #2 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:40da83e4a770f0a05ef6ace4cdd75397609e5bde
commit r16-3015-g40da83e4a770f0a05ef6ace4cdd75397609e5bde
Author: H.J. Lu
Date: Tue Aug 5 06:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121408
Andrew Pinski changed:
What|Removed |Added
Keywords||error-recovery,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121335
--- Comment #5 from Patrick Palka ---
i.e. place #includes first:
#define GLFW_INCLUDE_VULKAN
#include
import std;
import vulkan_hpp;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121404
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121413
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110921
--- Comment #12 from 罗勇刚(Yonggang Luo) ---
Clang already fixed this
https://github.com/llvm/llvm-project/issues/64477
https://github.com/llvm/llvm-project/pull/123623/files
Can gcc also fixed this?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121418
Bug ID: 121418
Summary: Missed copy prop for aggregate after a memcpy
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancemen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121398
Paul Thomas changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121413
--- Comment #1 from Jakub Jelinek ---
Ah, the problem is in the PHI INTEGER_CST argument expansion code on targets
with GET_MODE_BITSIZE (info.abi_limb_mode) > GET_MODE_BITSIZE (info.limb_mode)
like aarch64 (or in the near future loongarch and a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121416
Bug ID: 121416
Summary: [gcn][MI300][CDNA3]
libgomp.oacc-c-c++-common/reduction-cplx-dbl.c
produces wrong gang-reduction result
Product: gcc
Version: 16.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121415
Andrew Pinski changed:
What|Removed |Added
See Also||https://github.com/llvm/llv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121415
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121408
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-08-05
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
--- Comment #40 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #39)
> (In reply to Richard Earnshaw from comment #34)
> > To be honest, I'm more concerned that we aren't eliminating a lot of these
> > copies during the gimple opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121418
Andrew Pinski changed:
What|Removed |Added
Blocks||121364
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121417
Bug ID: 121417
Summary: Missed copy prop for aggregate with memcpy
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121416
Tobias Burnus changed:
What|Removed |Added
CC||tschwinge at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121411
David Faust changed:
What|Removed |Added
CC||nick.alcock at oracle dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121335
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121411
--- Comment #2 from David Faust ---
Created attachment 62061
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62061&action=edit
proposed patch
Use unsigned HOST_WIDE_INT (which should always be 64 bits) when calculating
the array bounds so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121417
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2025-08-05
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121280
--- Comment #3 from Ryan Stocks ---
(In reply to Andrew Pinski from comment #1)
> Note this code is undefined if vect.empty() is true due to front being
> undefined in that case.
> Adding that check makes the warning go away too; either for
> `v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121392
--- Comment #2 from Andrew Stubbs ---
This is actually a bug in Newlib libm that is exposed because the testcase is
now vectorizing, where previously the i386 setting of
param_vect_partial_vector_usage was blocking it.
>From newlib/libm/machine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121404
--- Comment #1 from Cassio Neri ---
Actually, printf has the same issue. For instance, when x1 and x2 are defined
as below.
using u128 = unsigned __int128;
long double const p61 = 1.0l / (u128(1) << 61);
long double const x1 = 1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120018
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Arthur Cohen :
https://gcc.gnu.org/g:7e38e0ca35d2c6d5850a6f1c1e2e7875106fe405
commit r16-2808-g7e38e0ca35d2c6d5850a6f1c1e2e7875106fe405
Author: Marc Poulhiès
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121359
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121343
Bug 121343 depends on bug 121359, which changed state.
Bug 121359 Summary: [avr] Remove last remains of reload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121359
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121389
--- Comment #10 from Jakub Jelinek ---
And the same without -fdisable-tree-switchlower_O0 has there not just
equality/non-equality comparisons but also finally_tmp.NNN_MMM > 33 and the
like.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121389
--- Comment #9 from Jakub Jelinek ---
And yet another version which with -fsanitize=address
-fdisable-tree-switchlower_O0 has there a GIMPLE_SWITCH to process rather than
comparison:
int foo (void);
int bar (void);
int baz (unsigned *);
int
ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121415
Bug ID: 121415
Summary: aarch64: Failure to handle PSTATE.SM & ZA for tlsdesc
calls
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keywords: aarch64-sme, wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121389
--- Comment #8 from Jakub Jelinek ---
Modified testcase which uses finally_tmp.N from 0 to 5.
int foo (void);
int bar (void);
int baz (unsigned *);
int
bar (void)
{
for (int a = 0; a < 420; ++a)
{
for (int b = 0; b < 420; ++b)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121414
Richard Sandiford changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121414
Bug ID: 121414
Summary: aarch64: streaming & streaming-compatible functions
should be marked as variant PCS
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Keyw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121389
--- Comment #7 from Jakub Jelinek ---
Again I'll mention my rant that using heavily musttail attributes #ifndef
__OPTIMIZE__ doesn't make much sense unless it is really required for the
program not running out of stack. In the protobuf case wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121389
--- Comment #6 from Jakub Jelinek ---
In the r16-1886-gb610132ddbe4cb870b9c2752053616dcf12979fe commit I've been
expecting finally_tmp.N will be only 0/1, but on this testcase it uses 0/1/2
values and even the assumption that the SSA_NAMEs (e.g.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121389
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85919
Richard Biener changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121306
--- Comment #11 from GCC Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:5305f84c3be3de9397907dfaf151477579d91c77
commit r16-2789-g5305f84c3be3de9397907dfaf151477579d91c77
Author: Richard Sandiford
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121410
--- Comment #1 from H.J. Lu ---
A patch is posted at
https://gcc.gnu.org/pipermail/gcc-patches/2025-August/691707.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121410
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120935
--- Comment #8 from Hans-Peter Nilsson ---
(In reply to Hans-Peter Nilsson from comment #7)
> Now three
> patches, with this one committed, and the other two in progress for the
> master branch.
The default for MAX_FIXED_MODE_SIZE is now change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121359
--- Comment #1 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:7e8d89ee82cc504e760c1613f4225be61ddc5d5d
commit r16-2787-g7e8d89ee82cc504e760c1613f4225be61ddc5d5d
Author: Georg-Johann Lay
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121306
--- Comment #10 from GCC Commits ---
The master branch has been updated by H.J. Lu :
https://gcc.gnu.org/g:a58d770fa1d17ead3c38417b299cce3f19f392db
commit r16-2786-ga58d770fa1d17ead3c38417b299cce3f19f392db
Author: H.J. Lu
Date: Fri Aug 1 08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121321
--- Comment #5 from Sam James ---
This shows up in bsd-games now too (after the other issue was fixed). It's the
only one left from the run I did.
ted LTO compression algorithms: zlib zstd
gcc version 16.0.0 20250805 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121395
--- Comment #1 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:32b1be7eb434addefe203249746dc6bbdc185403
commit r16-2785-g32b1be7eb434addefe203249746dc6bbdc185403
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121406
--- Comment #4 from Joseph S. Myers ---
See C99 issue 0316.
https://www.open-std.org/jtc1/sc22/wg14/issues/c99/issue0316.html
Hi gcc-bugs@gcc.gnu.org,
Quick note from WELLSUCCEED - we help brands like yours with:
• Small-batch socks (MOQ 200 pairs)
• Stress-free customization (you send logo → we handle the rest)
• Speedy sampling (Free 1st sample + USD 30 shipping = 2 weeks)
Fun fact: Last month we created so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121382
--- Comment #10 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:5d55cd95e2bbb1114a59ca743671188634e757cc
commit r16-2782-g5d55cd95e2bbb1114a59ca743671188634e757cc
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121370
--- Comment #5 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:afafae097232e700bb7a74a453a048b83ebefccd
commit r16-2781-gafafae097232e700bb7a74a453a048b83ebefccd
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121412
--- Comment #7 from rguenther at suse dot de ---
On Tue, 5 Aug 2025, ktkachov at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121412
>
> ktkachov at gcc dot gnu.org changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121412
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Known to work|15.1.1 |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119702
--- Comment #16 from Surya Kumari Jangala ---
(In reply to Segher Boessenkool from comment #13)
> (In reply to Surya Kumari Jangala from comment #12)
> > Ok. We also need to tackle the original issue, which is that a shift left
> > can be optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121412
--- Comment #5 from ktkachov at gcc dot gnu.org ---
Comment on attachment 62057
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62057
Second sleeffoo.i reproducer
>#pragma GCC aarch64 "arm_sve.h"
>typedef svfloat32_t a;
>typedef svfloat32x2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119702
--- Comment #15 from Segher Boessenkool ---
(In reply to Avinash Jayakar from comment #14)
> (In reply to Surya Kumari Jangala from comment #12)
> > Ok. We also need to tackle the original issue, which is that a shift left
> > can be optimized b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121127
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121412
--- Comment #4 from Richard Biener ---
(In reply to Richard Biener from comment #3)
> -msve-vector-bits is not specially handled in lto-wrapper and thus it will
> go the "default" and ferry that over to the link command.
>
> The flag should get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121412
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |16.0
Version|15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119702
--- Comment #14 from Avinash Jayakar ---
(In reply to Surya Kumari Jangala from comment #12)
> Ok. We also need to tackle the original issue, which is that a shift left
> can be optimized by generating a vector add. Perhaps tackle this issue fir
1 - 100 of 117 matches
Mail list logo
