https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115508
Andrew Pinski changed:
What|Removed |Added
Attachment #58443|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114515
Jeffrey A. Law changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115508
Andrew Pinski changed:
What|Removed |Added
Attachment #58442|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115508
--- Comment #9 from Andrew Pinski ---
_19 = BIT_FIELD_REF ;
_12 = BIT_FIELD_REF ;
_15 = _12 | _19;
vs
_13 = BIT_FIELD_REF ;
_14 = BIT_FIELD_REF ;
_15 = _13 | _14;
So basically it is just by accident the order happens that way which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115508
--- Comment #8 from Andrew Pinski ---
Created attachment 58442
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58442&action=edit
Semi-cleaned up testcase with some extra hooks
So note if you change any of the `#if 0` to `#if 1` or `#if 1`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115508
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115508
--- Comment #6 from Sam James ---
Created attachment 58441
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58441&action=edit
reduced_more.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115508
--- Comment #5 from Sam James ---
On trunk with reduced.i, I get:
```
==3698089== Invalid read of size 8
==3698089==at 0x2430014: UnknownInlinedFun (tree-vect-slp.cc:9672)
==3698089==by 0x2430014: vect_schedule_slp_node(vec_info*, _slp_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115508
Andrew Pinski changed:
What|Removed |Added
CC||pinskia at gcc dot gnu.org
Target Mil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115508
--- Comment #4 from Sam James ---
Created attachment 58440
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58440&action=edit
reduced.i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115508
--- Comment #3 from Sam James ---
> I can't reproduce it with -march=znver2, just -march=znver1. Not compared
> the diff yet.
-march=znver2 -mprefer-vector-width=128 fails too
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115508
--- Comment #2 from Sam James ---
I'm reducing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115508
--- Comment #1 from Sam James ---
==3050649== Invalid read of size 8
==3050649==at 0x192EB36: vect_schedule_slp_node(vec_info*, _slp_tree*,
_slp_instance*) [clone .part.0] (tree-vect-slp.cc:9279)
==3050649==by 0x1948643: vect_schedule_s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115508
Bug ID: 115508
Summary: ICE when building flac with -O2 -march=znver1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114528
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
l_Enum_8.Impl.Value_Enumeration at s-valuen.adb:149
0x404a4d Sample at sample.adb:12
0x4046b7 Main at b~sample.adb:258
[/lib/x86_64-linux-gnu/libc.so.6]
0x7fc03814f248
0x7fc03814f303
[./sample]
0x4040ef _start at ???
0xfffe
```
'Wide_Value will also failed with the same error.
I've tested in Debian 12 x86_64 with GNAT 15.0.0 20240615 (git 079506).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115475
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108316
Andrew Pinski changed:
What|Removed |Added
Target Milestone|13.4|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115087
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113859
--- Comment #4 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Patch was posted:
> https://gcc.gnu.org/pipermail/gcc-patches/2024-May/650311.html
Latest patch:
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/653405.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100211
Andrew Pinski changed:
What|Removed |Added
Keywords||aarch64-sve
Assignee|unassign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106329
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97405
Andrew Pinski changed:
What|Removed |Added
Known to work||15.0
--- Comment #6 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111733
Andrew Pinski changed:
What|Removed |Added
Keywords||aarch64-sve
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114906
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115391
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115505
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112422
--- Comment #4 from Eric Gallager ---
(In reply to Sam James from comment #3)
> There's some stuff we could cache for sure but it wouldn't be the majority
> of the checks - stuff like finding tools like awk, sed should work
> regardless of which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115312
--- Comment #6 from Brecht Sanders
---
You're right. Sorry I missed that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115486
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115503
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115504
--- Comment #1 from Andrew Pinski ---
I suspect the fix for PR 96917 broke references (or rather changed all to be
non references).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
--- Comment #12 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #11)
> Although that class template has been there for years, so if any library
> like abseil was using the built-in, they're already have the problem that
> libstd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
--- Comment #11 from Jonathan Wakely ---
Although that class template has been there for years, so if any library like
abseil was using the built-in, they're already have the problem that libstdc++
now has.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
--- Comment #10 from Jonathan Wakely ---
The only foolproof fix would be to rename the __is_pointer class template.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
--- Comment #9 from Jonathan Wakely ---
Changing libstdc++ order of includes won't help abseil. If their use of
__is_pointer still comes after any standard header has included
cpp_type_traits.h, the identifier will be "poisoned" by the class tem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115312
--- Comment #5 from Lewis Hyatt ---
(In reply to Brecht Sanders from comment #4)
> No, that patch wasn't added for my build, see my build recipe here:
> https://github.com/brechtsanders/winlibs_recipes/blob/main/recipes/gcc.winlib
Thanks, this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115505
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115506
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Component|rtl-opti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115506
Bug ID: 115506
Summary: Possible but missed "cmp" instruction merging (x86 &
ARM, optimization)
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115231
Nathaniel Shead changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115505
Bug ID: 115505
Summary: missing optimization: thumb1 use ldmia/stmia for load
store DI/DF data when possible
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Sev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #13 from John Paul Adrian Glaubitz ---
(In reply to Andrew Pinski from comment #7)
> `-fno-lifetime-dse` is already used but I get the feeling there might be
> strict aliasing issues in the code though. What happens if you add
> -fn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #12 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111639
--- Comment #9 from Georg-Johann Lay ---
(In reply to Jonathan Wakely from comment #1)
> since float, double and long double all seem to be the same size on avr
Not necessarily. Since GCC v10, the default for long double is 64 bit (IEEE
double)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115312
--- Comment #4 from Brecht Sanders
---
No, that patch wasn't added for my build, see my build recipe here:
https://github.com/brechtsanders/winlibs_recipes/blob/main/recipes/gcc.winlib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
Arthur O'Dwyer changed:
What|Removed |Added
CC||arthur.j.odwyer at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115504
Bug ID: 115504
Summary: Wrong decltype result for a captured reference inside
limbda
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #11 from John Paul Adrian Glaubitz ---
(In reply to John Paul Adrian Glaubitz from comment #10)
> (In reply to Kewen Lin from comment #9)
> > Since it's a breakage during stage2, it's concluded that some built stage1
> > stuffs behav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115482
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115497
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108467
--- Comment #4 from Vincent Lefèvre ---
(In reply to Sam James from comment #3)
> For 14/15, it seems gone with -O2, but I see it with -Og.
The warning still occurs with -O1 too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #16 from Siarhei Volkau ---
Might it be that LoongArch have register reuse dependency?
I observed similar behavior on XBurst with load/store/reuse pattern:
e.g. this code
LW $v0, 0($t1)# Xburst load latency is 4 but it has bypa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #15 from Siarhei Volkau ---
Created attachment 58437
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58437&action=edit
application to test performance of shift
Here is the test application (MIPS32 specific) I wrote.
It allows
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115481
--- Comment #4 from Georg-Johann Lay ---
(In reply to dv from comment #0)
> New versions of avrlibc provide long double math functions,
In the case it matters:
1) avr-libc has long double prototypes in math.h since v2.2.
2a) When long double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374
--- Comment #21 from GCC Commits ---
The trunk branch has been updated by Gerald Pfeifer :
https://gcc.gnu.org/g:57af69d56e72af049444c42bc7216d2737683f08
commit r15-1349-g57af69d56e72af049444c42bc7216d2737683f08
Author: Gerald Pfeifer
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111376
--- Comment #14 from YunQiang Su ---
And it seems that the performance of SLL is related with the operand.
Just iterate from 0 to 1e9:
```
0b00 :
b00: 000223c0sll a0,v0,0xf <-- the code is something
wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115503
Bug ID: 115503
Summary: Explicit deduction guide - Capture parameter pack in
lambda - Compiler segfaults
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severit
58 matches
Mail list logo
