https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115798
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115822
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #2 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115795
--- Comment #2 from Jordi Sala ---
Thanks, is it possible to force a bigger LMUL currently? It's mainly for
performance reasons.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115802
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115805
--- Comment #1 from Richard Biener ---
Note that -D_FORTIFY_SOURCE=3 (and also =2 to some extent) impose stricter
constraints on the program than the C or C++ standard do. That means valid
C/C++ programs can become invalid so -D_FORTIFY_SOURCE=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115812
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |12.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115816
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic,
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115795
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #3 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115822
--- Comment #3 from Bruno Pitrus ---
(In reply to Xi Ruoyao from comment #2)
> And you can always use something like -ftabstop=1 to "disallow mixing
> tabs with spaces."
`-ftabstop=1` does not catch the example i provided above.
(In r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115824
Bug ID: 115824
Summary: Strange -Warray-bounds warning when assigning an
initializer list to a vector of pointers
Product: gcc
Version: 12.4.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115822
--- Comment #4 from Xi Ruoyao ---
(In reply to Bruno Pitrus from comment #3)
> (In reply to Xi Ruoyao from comment #2)
> > And you can always use something like -ftabstop=1 to "disallow mixing
> > tabs with spaces."
>
> `-ftabstop=1` do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115822
--- Comment #5 from Andrew Pinski ---
(In reply to Bruno Pitrus from comment #3)
> I came up with this enhancement _specifically_ because the libstdc++ headers
> are hard to read due to inconsistent use of tabs vs spaces. If your editor
> is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110040
--- Comment #2 from GCC Commits ---
The master branch has been updated by jeevitha :
https://gcc.gnu.org/g:5be97039aa6c27fdf5d5bd43ef393b307c5ecedd
commit r15-1895-g5be97039aa6c27fdf5d5bd43ef393b307c5ecedd
Author: Jeevitha
Date: Mon Jul 8 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115646
--- Comment #4 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:078cdccc849831b8f1ff74b9ad16ce3f5aa172be
commit r14-10391-g078cdccc849831b8f1ff74b9ad16ce3f5aa172be
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115694
--- Comment #14 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:cde411950e91e0174a0134360d2eb138ca6821c6
commit r14-10393-gcde411950e91e0174a0134360d2eb138ca6821c6
Author: Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115669
--- Comment #10 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:03844a2a15a85015506c0f187d0e9d526900cc2c
commit r14-10392-g03844a2a15a85015506c0f187d0e9d526900cc2c
Author: Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115723
--- Comment #18 from GCC Commits ---
The releases/gcc-14 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:64a6c0d594c05f275de91df35047cffb3ccecf2f
commit r14-10394-g64a6c0d594c05f275de91df35047cffb3ccecf2f
Author: Richard Bien
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115723
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 115723, which changed state.
Bug 115723 Summary: [14 Regression] SPEC CPU2017 521/621 build error with
-Ofast and AVX512 enabled(-ftree-vectorize?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115723
What|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112732
--- Comment #7 from GCC Commits ---
The releases/gcc-11 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:e7879391bb2b86606d0ce35ed97eccc108970e36
commit r11-11561-ge7879391bb2b86606d0ce35ed97eccc108970e36
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97990
--- Comment #16 from GCC Commits ---
The releases/gcc-11 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:c2c216d0f85f861cc10529a455edfaf645aa393f
commit r11-11562-gc2c216d0f85f861cc10529a455edfaf645aa393f
Author: Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97990
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115795
--- Comment #4 from Jordi Sala ---
problem is this is not related to the vectorizer as far as I'm aware, so
setting -mrvv-max-lmul=m8 does not change the fact that vsetvl pass is going to
change the loads and stores from m8 to m2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114663
Nina Ranns changed:
What|Removed |Added
CC||dinka.ranns at gmail dot com
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115810
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|2024-07-06 00:00
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115795
--- Comment #5 from JuzheZhong ---
(In reply to Jordi Sala from comment #4)
> problem is this is not related to the vectorizer as far as I'm aware, so
> setting -mrvv-max-lmul=m8 does not change the fact that vsetvl pass is going
> to change the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817
Georg-Johann Lay changed:
What|Removed |Added
Priority|P3 |P4
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115810
--- Comment #13 from Jonathan Wakely ---
NOT reproduced with gcc 14 in a Fedora 40 container though. So this could be an
Ubuntu-specific patch to GCC, or something fixed between the Ubuntu g++-14:
gcc version 14.0.1 20240412 (experimental) [mast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
Bug ID: 115825
Summary: Loop unrolling increases code size with -Os
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115810
--- Comment #14 from Jonathan Wakely ---
Like Andrew showed in comment 6, the confusing lines in the ubuntu output
should be showing the context:
550 | return [&](
|
~~~
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115826
Bug ID: 115826
Summary: vect-tsvc-s1281.c fails with with -ffast-math on
arm-none-eabi
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115810
--- Comment #15 from Jonathan Wakely ---
(In reply to linuxnyasha from comment #7)
> It doesn't work like that for me when I compile using preprocessed sources.
> The bug only appears when I simply compile. (ubuntu-24.04 Github Actions)
Are you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115795
--- Comment #6 from Jordi Sala ---
Perfect, that's what I was looking for. I'm thinking of adding a way to tell
GCC to minimize, maximize or preserve SEW on vsetvl expand. Like
-mrvv-vsetvl-sew={maximize,minimize,preserve}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114663
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817
--- Comment #2 from Dmytro Bagrii ---
Yes, in "regular" function single STS for storing zero is better than LDI/STS
for storing non-zero, assuming r1 is already zeroed.
If it were guaranteed that ISR cannot be invoked before libc's .init2 secti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114663
Ville Voutilainen changed:
What|Removed |Added
CC||ville.voutilainen at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115810
--- Comment #16 from Jonathan Wakely ---
Created attachment 58607
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58607&action=edit
Preprocessed source
This all_meta.cpp.ii.gz file repros the problem with Ubuntu's g++-14 14.0.1
compiler, u
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115827
Bug ID: 115827
Summary: uninit-17.c no longer emits expected warning on
arm-none-eabi
Product: gcc
Version: 13.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115827
--- Comment #1 from Andrew Pinski ---
>arm-gnu-toolchain-13.3.rel1-x86_64-arm-none-eabi
Works with GCC 13.3.0 with:
COLLECT_GCC=/opt/compiler-explorer/arm/gcc-13.3.0/arm-unknown-linux-gnueabihf/bin/arm-unknown-linux-gnueabihf-g++
Target: arm-un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115827
Andrew Pinski changed:
What|Removed |Added
Target||arm-none-eabi
--- Comment #2 from Andre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115827
--- Comment #3 from Andrew Pinski ---
-msoft-float is the difference ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115827
Andrew Pinski changed:
What|Removed |Added
Summary|uninit-17.c no longer emits |[13/14/15 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115810
Sam James changed:
What|Removed |Added
CC||doko at gcc dot gnu.org
--- Comment #17 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #1 from Andrew Pinski ---
For avr, we get:
size: 5-4, last_iteration: 5-4
Loop size: 5
Estimated size after unrolling: 5
So something is under-estimating the size after unrolling.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
Andrew Pinski changed:
What|Removed |Added
Known to fail||7.1.0
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115824
Andrew Pinski changed:
What|Removed |Added
Known to work||12.3.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115824
Andrew Pinski changed:
What|Removed |Added
Known to work|12.3.0 |13.1.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #3 from Georg-Johann Lay ---
How is the tree-ssa passes quering the costs? Does it bake RTX patterns, or is
it again some implicit assumptions without looking at actual (estimated) real
costs?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115828
Bug ID: 115828
Summary: Inefficient loop termination (should use compare
against 0)
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817
--- Comment #3 from Georg-Johann Lay ---
Setting R1 to 0 in an ISR prologue is not redundant, because R1 may be non-zero
due to a variety of reasons, for example when the interrupted code uses MUL
just to mention one.
Moreover, on Reduced Tiny
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114531
--- Comment #20 from Richard Sandiford ---
(In reply to Jan Hubicka from comment #18)
> I am trying to understand how useful this is. I am basically worried
> about two things
> 1) we have other optimization passes that behave differently at -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115807
--- Comment #1 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:40d234dd6439e8c8cfbf3f375a61906aed35c80d
commit r15-1898-g40d234dd6439e8c8cfbf3f375a61906aed35c80d
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115799
--- Comment #9 from Jonathan Wakely ---
Yes, that's worth fixing. Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/656644.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115049
Jason Merrill changed:
What|Removed |Added
Component|c++ |tree-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115825
--- Comment #4 from Andrew Pinski ---
(In reply to Georg-Johann Lay from comment #3)
> How is the tree-ssa passes quering the costs? Does it bake RTX patterns, or
> is it again some implicit assumptions without looking at actual (estimated)
> r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115828
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115829
Bug ID: 115829
Summary: ((x & 1345) ^ 2048) - 2048 is not optimized to just (x
& 1345)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimiza
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115829
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115808
--- Comment #9 from Jonathan Wakely ---
Without the library dependency:
struct _ignore {
template constexpr const _ignore& operator=(const T&) const { return
*this; }
};
constexpr _ignore ignore{};
namespace utempl::loopholes {
template
s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115808
--- Comment #10 from Jonathan Wakely ---
EDG rejects it too:
"loop.cc", line 11: warning: "auto Magic(utempl::loopholes::Getter)"
declares a non-template function -- add <> to refer to a template
instance
friend constexp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115830
Bug ID: 115830
Summary: [avr] Make better use of SREG in conditional jumps
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115830
Georg-Johann Lay changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115828
--- Comment #2 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #1)
> Turning off ivopts `-fno-ivopts`. avr gives:
> .L2:
> sts v+1,r19
> sts v,r18
> subi r18,2
> sbc r19,__zero_reg__
> sb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115815
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.4
Summary|ICE: in purge_a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115815
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-07-08
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115815
--- Comment #2 from Andrew Pinski ---
I suspect r13-8594-g40ddc0b05a47f9 as the cause.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115795
--- Comment #7 from JuzheZhong ---
(In reply to Jordi Sala from comment #6)
> Perfect, that's what I was looking for. I'm thinking of adding a way to tell
> GCC to minimize, maximize or preserve SEW on vsetvl expand. Like
> -mrvv-vsetvl-sew={max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817
--- Comment #4 from Dmytro Bagrii ---
Of course, there are various cores, i'm just speculating regarding necessity of
preserving R1.
For now the issue is worked around with inline assembler. It was surprise for
me to see the .text size increase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115831
Bug ID: 115831
Summary: if the function for check-function-bodies is not
found, it does not say it was not found
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115796
--- Comment #3 from GCC Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:23ab7f632f4f5bae67fb53cf7b18fea7ba7242c4
commit r15-1905-g23ab7f632f4f5bae67fb53cf7b18fea7ba7242c4
Author: liuhongt
Date: Mon Jul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115796
Hongtao Liu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115049
--- Comment #2 from Sam James ---
Some things which would help, especially given it's not reproducible on Linux
yet:
* A bisect
* Figuring out which options between -O1 and -O2 cause it (you can't cleanly
split between -O1 and -O2 but you can fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115832
Bug ID: 115832
Summary: Very slow compilation with certain flags and std::sort
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115832
--- Comment #1 from Mohammed Faisal ---
Created attachment 58612
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58612&action=edit
Preprocessed file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115833
Bug ID: 115833
Summary: SLP of signed short multiply goes wrong
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115832
--- Comment #2 from Mohammed Faisal ---
I have also tested this with gcc 13.2.1 on a different machine and found a
similar slowdown.
Testing this with clang 14.0.6 gives only about a 2x slowdown as opposed to the
13.5x slowdown with gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115832
Andrew Pinski changed:
What|Removed |Added
Component|c++ |middle-end
--- Comment #3 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115832
--- Comment #4 from Andrew Pinski ---
(In reply to Mohammed Faisal from comment #2)
> I have also tested this with gcc 13.2.1 on a different machine and found a
> similar slowdown.
> Testing this with clang 14.0.6 gives only about a 2x slowdown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115832
--- Comment #5 from Andrew Pinski ---
Also is your clang still using libstdc++ or is it using libc++?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115832
--- Comment #6 from Mohammed Faisal ---
(In reply to Andrew Pinski from comment #4)
> (In reply to Mohammed Faisal from comment #2)
> > I have also tested this with gcc 13.2.1 on a different machine and found a
> > similar slowdown.
> > Testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115763
--- Comment #10 from GCC Commits ---
The releases/gcc-14 branch has been updated by Pan Li :
https://gcc.gnu.org/g:505382ceee0b5e72dc5defa05aec77a97658feca
commit r14-10396-g505382ceee0b5e72dc5defa05aec77a97658feca
Author: Pan Li
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115049
--- Comment #3 from Jörn Heusipp ---
Created attachment 58613
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58613&action=edit
updated testcase-v2
Updated testcase that got rid of std::mt19937. It's still somewhat huge because
it still dr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115834
Bug ID: 115834
Summary: two loads from same address for min/max
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115834
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
84 matches
Mail list logo
