https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117317
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117275
--- Comment #5 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:7f41203f08b9948c1c636dc9d66571121c6c7793
commit r15-4739-g7f41203f08b9948c1c636dc9d66571121c6c7793
Author: David Malcolm
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112716
--- Comment #15 from Richard Biener ---
(In reply to uecker from comment #14)
> (In reply to Richard Biener from comment #13)
> > (In reply to uecker from comment #11)
> > > I asked the C FE and it wants to get this fixed.
> >
> > That was a fu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117333
--- Comment #4 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:0e99b22aa666f107c4035d32bfb5ab11534a9d2f
commit r15-4737-g0e99b22aa666f107c4035d32bfb5ab11534a9d2f
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112641
--- Comment #3 from Patrick Palka ---
> which will have 𝒪(n) complexity in the case of random-access-sized but
> non-common range.
As mentioned in the commit message I think the ranges::next implementation is
O(n) only if the range is sized wit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
--- Comment #5 from ak at gcc dot gnu.org ---
Peter, can you construct a test case that demonstrates the problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112716
--- Comment #14 from uecker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #13)
> (In reply to uecker from comment #11)
> > I asked the C FE and it wants to get this fixed.
>
> That was a funny comment?
Yes sorry.
>
> But yes,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117333
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2024-10-29
Assignee|unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117343
Bug ID: 117343
Summary: valgrind error in
vect_optimize_slp_pass::decide_masked_load_lanes
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117334
--- Comment #1 from Richard Biener ---
I think it's a GCC extension that we accept
const struct s gs = { 3, -4, "abcdef" };
C17 6.7.2.1/21 shows an example where such initialization is invalid as
'struct s' should be treated as if the 'ac' mem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117336
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117335
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117344
Bug ID: 117344
Summary: Suboptimal use of movprfx in SVE intrinsics code
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: aarch64-sve, missed-optimization
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117343
--- Comment #3 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:cc79e9866ba33dea0256078f4557d92d80d9
commit r15-4738-gcc79e9866ba33dea0256078f4557d92d80d9
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112601
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61379
--- Comment #5 from Jakub Jelinek ---
Yes.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61379
--- Comment #4 from k4lizen at proton dot me ---
re: jakub
Does what you're saying also apply to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117337 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112601
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117343
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61379
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117317
--- Comment #5 from Jakub Jelinek ---
Slightly cleaned up:
struct C {
constexpr bool operator== (const C &b) const { return foo (); }
constexpr virtual bool foo () const = 0;
};
class A : public C {};
class B : public C {};
template
struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112349
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112641
--- Comment #2 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:7f622ee83fbbcf4a4ca70e020db8a0ce4b556b61
commit r15-4740-g7f622ee83fbbcf4a4ca70e020db8a0ce4b556b61
Author: Patrick Palka
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112641
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117030
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:972f653cad2aedcfa901614566506c1c2e668766
commit r15-4729-g972f653cad2aedcfa901614566506c1c2e668766
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #3 from David Binderman ---
No mention of base64 in the config.log:
working.2 $ grep base64 config.log
working.2 $
What's a combined build ?
My usual configure line is:
CC="clang" CXX="clang++" \
../trunk/configure --prefix=$HO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #5 from Jakub Jelinek ---
Combined build is when you build gcc together with binutils (and often other
modules like gmp, mpfr, libmpc, etc.) by unpacking those into the same tree.
The toplevel configure indeed doesn't check for .base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117317
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
--- Comment #13 from GCC Commits ---
The releases/gcc-12 branch has been updated by Peter Bergner
:
https://gcc.gnu.org/g:eeb72f26ea7e70baadf2e3b9e89e8f7055fec0a9
commit r12-10790-geeb72f26ea7e70baadf2e3b9e89e8f7055fec0a9
Author: Peter Bergner
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116415
Peter Bergner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112716
--- Comment #16 from uecker at gcc dot gnu.org ---
(In reply to Richard Biener from comment #15)
> (In reply to uecker from comment #14)
> > (In reply to Richard Biener from comment #13)
> > > (In reply to uecker from comment #11)
> > >
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61379
--- Comment #6 from k4lizen at proton dot me ---
I understand what you're saying but I'm hoping that there would be *some*
solution for annotating such functions as noreturn. It's highly
counterintuitive that even after marking all definitions and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117349
Bug ID: 117349
Summary: aarch64_gen_ccmp_next, aarch64_gen_ccmp_first contains
extra casts which can be removed
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117349
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-10-29
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106073
--- Comment #12 from Sam James ---
Ah, thanks.
Let's add the testcase too, if no objection? The topic is a prickly one and
PR90348 was somewhat worked around.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117342
--- Comment #11 from David Binderman ---
(In reply to Andreas Schwab from comment #10)
> Can you provide an example of the evidence?
Sure. For this C++ source code:
void s61() { static char extra_special_characters[] = "\n\t\b\r\f\\\'"; }
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117349
--- Comment #2 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:9dd9a88b75334bc079b8ab5fb2dbb5d56765bd60
commit r15-4754-g9dd9a88b75334bc079b8ab5fb2dbb5d56765bd60
Author: Andrew Pinski
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114785
--- Comment #4 from Andrew Pinski ---
(In reply to Richard Biener from comment #3)
> Note there's still code in tree-vect-patterns.cc creating those and code in
> tree-vect-stmts.cc might use gimple_extract on them.
Now we assert this won't hap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117007
--- Comment #10 from Steven Munroe ---
(In reply to Segher Boessenkool from comment #7)
> It is always more and slower code. Yes.
More examples:
vui64_t
test_sld_52_v1 (vui64_t vra)
{
vui32_t shft = vec_splat_u32(52-64);
return vec_vsld (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117344
--- Comment #2 from Andrew Pinski ---
The way cond_addvnx4si_2 is written currently is:
;; Predicated integer operations, merging with the first input.
(define_insn "*cond__2"
[(set (match_operand:SVE_I 0 "register_operand")
(unspec:SV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116949
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117327
--- Comment #11 from Brad Moody ---
Thank you for the quick turnaround!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
--- Comment #15 from H. Peter Anvin ---
Odd. When I added a read flag intrinsic to my test case, it prevented the red
zone from being used. If it clobbers the redzone, then that's obviously a very
serious problem.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
Sam James changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
ak at gcc dot gnu.org changed:
What|Removed |Added
Resolution|FIXED |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117311
--- Comment #4 from H. Peter Anvin ---
Again, any recommendations for a construct (current or future) that *can* be
relied upon?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117349
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117351
Bug ID: 117351
Summary: ICE while reporting invalid template error
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117350
--- Comment #3 from ak at gcc dot gnu.org ---
Reduced test case for an Intel platform:
gu.cc:
template class tuple;
template struct tuple<_T1, _T2> {
tuple(_T1, _T2);
};
struct __uniq_ptr_impl {
__uniq_ptr_impl(int __p, int) : _M_t(__p, in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117352
--- Comment #2 from Andrew Pinski ---
But note not all targets support all comparisons with ccmp (though I think for
integer both x86_64 and aarch64 supports all, it is float comparisons where
TARGET_GEN_CCMP_FIRST/TARGET_GEN_CCMP_NEXT can fail)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
--- Comment #18 from GCC Commits ---
The trunk branch has been updated by Andi Kleen :
https://gcc.gnu.org/g:3d06e9c3e07e13eab715e19dafbcfc1a0b7e43d6
commit r15-4758-g3d06e9c3e07e13eab715e19dafbcfc1a0b7e43d6
Author: Andi Kleen
Date: Fri Oct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117329
--- Comment #5 from Andrew Pinski ---
(In reply to Oskars Putans from comment #4)
> (In reply to Andrew Pinski from comment #1)
> > I can't reproduce the warning for Wnull-dereference but I do get a warning
> > for -O2 -Warray-bounds that has t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117329
--- Comment #4 from Oskars Putans ---
(In reply to Andrew Pinski from comment #1)
> I can't reproduce the warning for Wnull-dereference but I do get a warning
> for -O2 -Warray-bounds that has the same line as what you reported.
Oh no.. It see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117355
--- Comment #8 from Andrew Pinski ---
Created attachment 59495
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59495&action=edit
C/C++ code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117355
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> (In reply to Andrew Pinski from comment #6)
> > Most likely r15-4414-g51b85dfeb19652
>
> Or r15-4396-g72ae35bbc90fea .
100% this one. Tested the revision befor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116607
Iain Sandoe changed:
What|Removed |Added
CC||iains at gcc dot gnu.org
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117344
Andrew Pinski changed:
What|Removed |Added
Keywords||ra
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117347
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
Last reconfi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117346
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
--- Comment #2 from Vineet Gupta ---
For other benign instances of the pattern lshrv8qi3, typically it goes through
a splitter in autovec.md which converts it into the canonical RVV form with all
the VL info.
(define_insn_and_split "3"
[(set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
Bug ID: 117353
Summary: RISC-V: ICE when building libcrypt
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85605
Bug 85605 depends on bug 117346, which changed state.
Bug 117346 Summary: ccmp does not go through canonicalize_comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117346
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117353
Vineet Gupta changed:
What|Removed |Added
CC||ewlu at rivosinc dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117329
--- Comment #6 from Oskars Putans ---
(In reply to Andrew Pinski from comment #5)
> That is ok because the underlying issue is the same though. Only the line
> info for the `var = a;` assignment is there.
Could I get confirmation of Wnull-deref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
--- Comment #12 from Uroš Bizjak ---
(In reply to Uroš Bizjak from comment #11)
> (In reply to H. Peter Anvin from comment #9)
> > So this sounds like it would solve additional problems, which may very well
> > make it worthwhile.
>
> How about
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117354
Bug ID: 117354
Summary: [14] ICE: in extract_bit_field_1, at expmed.cc:1838
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117354
--- Comment #2 from Sam James ---
Oh, nevermind.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117354
--- Comment #4 from Sam James ---
_BitInt(512) x;
void
baz (void *p)
{
__builtin_memcpy (p, &x, sizeof x);
}
_BitInt(512)
qux (void *p)
{
_BitInt(512) y = x + 1;
__builtin_memcpy (p, &y, sizeof y);
return x;
}
int main() {
void *ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117355
--- Comment #6 from Andrew Pinski ---
Most likely r15-4414-g51b85dfeb19652
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117355
--- Comment #7 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #6)
> Most likely r15-4414-g51b85dfeb19652
Or r15-4396-g72ae35bbc90fea .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117355
--- Comment #5 from Andrew Pinski ---
It worked in July (20240727).
.
gcc/
PR rtl-optimization/117327
* reorg.cc (find_end_label): Do not return a dangling label at the
end of the function and adjust commentary.
gcc/testsuite/
* gcc.c-torture/execute/20241029-1.c: New test.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
Uroš Bizjak changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117327
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
ak at gcc dot gnu.org changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
--- Comment #11 from Uroš Bizjak ---
(In reply to H. Peter Anvin from comment #9)
> So this sounds like it would solve additional problems, which may very well
> make it worthwhile.
How about a guarantee that the first word of the redzone won't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117352
Bug ID: 117352
Summary: switch bit test conversion makes comparison code worse
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117352
Andrew Pinski changed:
What|Removed |Added
Summary|switch bit test conversion |[15 Regression] switch bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117352
Andrew Pinski changed:
What|Removed |Added
Target||aarch64 x86_64
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
--- Comment #17 from GCC Commits ---
The trunk branch has been updated by Andi Kleen :
https://gcc.gnu.org/g:a4e2b13888267f2581ac03f076aa0d32cd045adb
commit r15-4757-ga4e2b13888267f2581ac03f076aa0d32cd045adb
Author: Andi Kleen
Date: Wed Oct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85605
--- Comment #8 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:3d8cd34a450e9ffe2b2ac8a0c8eb33fd5d613483
commit r15-4759-g3d8cd34a450e9ffe2b2ac8a0c8eb33fd5d613483
Author: Andrew Pinski
Date: Tue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117346
--- Comment #5 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:3d8cd34a450e9ffe2b2ac8a0c8eb33fd5d613483
commit r15-4759-g3d8cd34a450e9ffe2b2ac8a0c8eb33fd5d613483
Author: Andrew Pinski
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117355
--- Comment #2 from Sam James ---
It's fine in C...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117355
--- Comment #4 from Sam James ---
Created attachment 59494
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59494&action=edit
larger.cxx
Attached the larger original function without branches pruned. I'll bisect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117355
--- Comment #3 from Sam James ---
--- a/foo.cxx.034t.early_objsz
+++ b/foo.cxx.034t.early_objsz
@@ -19,14 +19,14 @@ char * strncpy (char * restrict __dest, const char *
restrict __src, size_t __le
-;; Function gen_blr (_ZL7gen_blrPKc, funcdef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117355
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
--- Comment #13 from H. Peter Anvin ---
Yes, you have to be able to "reserve" (clobber) the entire redzone (128 bytes).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117354
--- Comment #5 from Sam James ---
asan isn't needed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117354
--- Comment #6 from Andrew Pinski ---
Created attachment 59492
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59492&action=edit
Reduced testcase
` -O2 -mavx512f -fsanitize=address` is enough to reproduce the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117354
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117312
--- Comment #14 from H. Peter Anvin ---
I am assuming the cases Uroš are talking about are constrained by a separate
software convention.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117354
--- Comment #8 from Andrew Pinski ---
Created attachment 59493
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59493&action=edit
fails with ` -O2 -mavx2 -fsanitize=address`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117354
--- Comment #3 from Sam James ---
Reproduced on trunk and tip of releases/gcc-14 with:
```
$ gcc /tmp/a.c -O2 -march=znver4 -fwhole-program -fsanitize=address
during RTL pass: expand
example.c:29:3: internal compiler error: in extract_bit_field_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117354
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116613
--- Comment #35 from GCC Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:0b73e9382ab51c00a79b2a6f8abbcd31d87f6814
commit r15-4760-g0b73e9382ab51c00a79b2a6f8abbcd31d87f6814
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117350
--- Comment #5 from ak at gcc dot gnu.org ---
Also the ICE had a truncated backtrace. Checking it in gdb gives the full one.
The bad mangling happens while autofdo is reading the string table of the afdo
file, and trying to generate the asm name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117350
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|2024-10-29 00:00:0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117350
--- Comment #7 from Andrew Pinski ---
Also when was the last time was this known to work?
1 - 100 of 180 matches
Mail list logo
