https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #25 from Andrew Pinski ---
*** Bug 112568 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112568
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112568
--- Comment #18 from Kostadin Shishmanov ---
(In reply to Andrew Pinski from comment #17)
> Can you try the patch in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572#c18 ?
The patch does fix it.
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231118 (experimental) (GCC)
[511] %
[511] % gcctk -O1 small.c; ./a.out
[512] %
[512] % gcctk -O3 small.c
[513] % ./a.out
Segmentation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103487
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-11-19
CC|rth at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96253
Andrew Pinski changed:
What|Removed |Added
Target|aarch64, arm|arm
--- Comment #3 from Andrew Pinski -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112561
--- Comment #2 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:af7fa3135b6b046fe3ba869993221042a65301eb
commit r14-5592-gaf7fa3135b6b046fe3ba869993221042a65301eb
Author: Juzhe-Zhong
Date: Sun Nov 19
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112615
--- Comment #4 from Andrew Pinski ---
.
Or their sources for Oracle DB ...
I suspect they have an assembly file that contains that variable and didn't
realize the alignment rules.
Note GCC 4.1.2 even sets the alignment to 16 for a simple:
cha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112615
gandalf at winds dot org changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112615
gandalf at winds dot org changed:
What|Removed |Added
Resolution|INVALID |FIXED
--- Comment #3 from gan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112615
--- Comment #2 from Andrew Pinski ---
>Assuming a minimum alignment of 16 for __tzname only makes sense when you're
>either compiling the whole program or when __tzname is static
Not if you follow the ABI which has had this in the ABI for yea
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112615
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107573
--- Comment #2 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:f65f63c4d86a48be042a3ad242fffe5fe8347ff0
commit r14-5591-gf65f63c4d86a48be042a3ad242fffe5fe8347ff0
Author: David Malcolm
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112615
Bug ID: 112615
Summary: gcc incorrectly assumes char *x[2]={"str1", "str2"}
has 16-byte minimum alignment and generates SSE
instructions (e.g. movaps) when accessing this data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89316
Uroš Bizjak changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112614
Bug ID: 112614
Summary: Compile-time float-to-_Decimal64 fails for -NAN
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112612
--- Comment #2 from Eyal Rozenberg ---
(In reply to Andrew Pinski from comment #1)
> IV-OPTs selects these IVs and is very much target specific due to cost model.
In this example, it seems that the missed optimization should be useful under
mos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #24 from Andrew Pinski ---
(In reply to Richard Sandiford from comment #23)
> (In reply to Andrew Pinski from comment #18)
> > compare-elim.cc depends on up to date REG_UNUSED and between before
> > vzeroupper and cmpelim the note ge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #23 from Richard Sandiford ---
(In reply to Andrew Pinski from comment #18)
> compare-elim.cc depends on up to date REG_UNUSED and between before
> vzeroupper and cmpelim the note gets out of date.
Thanks for tracking it down.
I can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112613
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #22 from Andrew Pinski ---
*** Bug 112613 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #21 from Andrew Pinski ---
So originally we had in vzeroupper:
```
(insn # # # 2 (set (reg/f:DI 43 r15 [orig:126 _84 ] [126])
(reg/f:DI 2 cx [orig:126 _84 ] [126]))
"/home/sam/git/llvm-project/llvm/include/llvm/ADT/SmallVecto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112609
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2023-11-18
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112613
--- Comment #3 from Sergei Trofimovich ---
> since the bad instruction is a compare, it does seem like it might be solved
> via https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572#c18 too. compare
> elimination is going wrong.
Yeah, that fixe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112094
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-11-18
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #20 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #18)
> compare-elim.cc depends on up to date REG_UNUSED and between before
> vzeroupper and cmpelim the note gets out of date.
Note it depends on it indirectly via s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112607
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |13.3
--- Comment #5 from Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110801
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112607
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:279e407a06cc676d8e6e0bb5755b0a804e05377c
commit r14-5588-g279e407a06cc676d8e6e0bb5755b0a804e05377c
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110801
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:41a5ea4cab2c59f9911325281f7df1d3ae846d48
commit r14-5587-g41a5ea4cab2c59f9911325281f7df1d3ae846d48
Author: Jonathan Wakely
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112612
Andrew Pinski changed:
What|Removed |Added
Component|middle-end |tree-optimization
Summary|[M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112613
--- Comment #2 from Andrew Pinski ---
since the bad instruction is a compare, it does seem like it might be solved
via https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572#c18 too. compare
elimination is going wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #19 from Sergei Trofimovich ---
I spent some time poking at the bug and was not able to reproduce it on my
toolchain.
I was able to get it to fail on gentoo's toolchain and arrived at problems in
lib/Target/X86/X86InterleavedAccess.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112613
--- Comment #1 from Sergei Trofimovich ---
Created attachment 56635
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56635&action=edit
bug.cpp.xz
--disable-libvtv CFLAGS='-O1 -g0' CXXFLAGS='-O1 -g0'
LDFLAGS='-O1 -g0'
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231118 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112568
--- Comment #17 from Andrew Pinski ---
Can you try the patch in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572#c18 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #17 from Andrew Pinski ---
It looks like another pass after vzeroupper depends on REG_DEAD/REG_UNUSED to
be correct but a different pass before that pass messes it up ...
I am still trying to figure out which pass is making the bad c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112612
Bug ID: 112612
Summary: [Missed Optimization] Holding on the loop variable
rather than a derived value which can replace it
Product: gcc
Version: 14.0
Status: UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112568
--- Comment #16 from Andrew Pinski ---
(In reply to Kostadin Shishmanov from comment #13)
> Created attachment 56617 [details]
> dump of the first different pass with the commit reverted
Note using -fdump-unnumbered might help to avoid dumping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #16 from Andrew Pinski ---
Note using -fdump-unnumbered might help to avoid dumping memory addresses that
were from memory addresses inside gcc itself.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112611
Bug ID: 112611
Summary: LoongArch: Test cases lsx-vshuf.c and lasx-xvshuf_b.c
fails on LA664
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112610
Bug ID: 112610
Summary: [12/13/14 Regression] ICE: SIGSEGV with
-flive-range-shrinkage -fdump-rtl-all-all
-fira-verbose=9
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89316
Andrew Pinski changed:
What|Removed |Added
CC||iamanonymous.cs at gmail dot
com
--- Co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112605
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112605
Andrew Pinski changed:
What|Removed |Added
Known to fail||8.1.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112606
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.0
Component|rtl-optimizatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112607
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112609
Bug ID: 112609
Summary: [F2023] Restrictions on integer arguments to
SYSTEM_CLOCK
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112607
--- Comment #3 from Jonathan Wakely ---
The standard tries quite hard to avoid this kind of specialization:
https://eel.is/c++draft/format.formatter.spec#note-1
But I suppose you can contrive this kind of custom formatter, or the inverse,
i.e.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=22196
Andrew Pinski changed:
What|Removed |Added
CC||goon.pri.low at gmail dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112608
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112607
--- Comment #2 from Jonathan Wakely ---
basic_string would be a valid program-defined specialization
though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112607
--- Comment #1 from Jonathan Wakely ---
That is not a valid specialization since it doesn't depend on a program-defined
type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112608
Bug ID: 112608
Summary: Missed-optimization: Multiple Division Constants
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96388
Maxim Kuvyrkov changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #15 from Maxim Kuv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112607
Bug ID: 112607
Summary: : _Normalize does not consider char_type for
the basic_string_view case
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112604
--- Comment #3 from Jakub Jermar ---
Created attachment 56633
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56633&action=edit
Updated requested good object file for vfs_file.c
Seems like -O3 -fno-unswitch-loops makes the bug go away. See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112606
Tamar Christina changed:
What|Removed |Added
CC||tnfchris at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112606
Bug ID: 112606
Summary: [14 Regression] powerpc64le-linux-gnu: 'FAIL:
gcc.target/powerpc/p8vector-fp.c scan-assembler
xsnabsdp'
Product: gcc
Version: 14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112604
--- Comment #2 from Jakub Jermar ---
Created attachment 56632
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56632&action=edit
Requested object and preprocessed source files
Here are the bad and good object and preprocessed sources fies f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112605
Bug ID: 112605
Summary: ICE: in gen_reg_rtx, at emit-rtl.cc:1176
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112604
Sam James changed:
What|Removed |Added
See Also||http://www.helenos.org/tick
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112604
Bug ID: 112604
Summary: [ia64] Output register not preserved after a branch is
not taken
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112547
--- Comment #8 from Filip Kastl ---
I've just ran the test on another zen4 machine. Between the originally
mentioned commits g:53010f6ff6dfbf7b and g:1a55724f7870719d there was only 1%
slowdown on this other machine. I guess this means that the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #15 from Sam James ---
Looks like it's extractInstructionFeatures
(https://github.com/llvm/llvm-project/blob/llvmorg-17.0.5/llvm/lib/CodeGen/MLRegallocEvictAdvisor.cpp#L943).
Adding __attribute__((optimize("O0"))) to it makes the te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #14 from Jakub Jelinek ---
Try to use optimize (0) attribute or corresponding pragma on some functions in
that file (just those where bad vs. good results in different code generation)
to find out which one is problematic?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #13 from Sam James ---
Created attachment 56631
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56631&action=edit
MLRegallocEvictAdvisor.cpp.cpp.262r.expand-good.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #12 from Sam James ---
Created attachment 56630
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56630&action=edit
MLRegallocEvictAdvisor.cpp.cpp.262r.expand-bad.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #11 from Sam James ---
The first pass to differ is expand.
Some selected diffs:
```
void llvm::cl::opt >::~opt (struct opt * const
this)
{
bool [-(*)-]{+(*)+} (union _Any_data & {ref-all}, const union
_Any_data & {ref-all}, _Manag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #10 from Sam James ---
Created attachment 56629
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56629&action=edit
MLRegallocEvictAdvisor.cpp.ii.xz
Attaching preprocesed sources from:
```
/tmp/build/bin/g++ -D_DEBUG -D_GLIBCXX_A
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #9 from Sam James ---
*
https://dev.gentoo.org/~sam/bugs/gcc/gcc-llvm-x86/MLRegallocEvictAdvisor.cpp.o-bad.xz
*
https://dev.gentoo.org/~sam/bugs/gcc/gcc-llvm-x86/MLRegallocEvictAdvisor.cpp.o-good.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112572
--- Comment #8 from Sam James ---
Bringing MLRegallocEvictAdvisor.cpp.o into a good build then relinking
lib/libLLVMCodeGen.so.17 is enough to break it.
Some selected diffs:
```
│ llvm::NextPowerOf2(unsigned long):
│ /home/sam/git/llvm-projec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112603
Sam James changed:
What|Removed |Added
CC||sjames at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112603
--- Comment #2 from Jonathan Wakely ---
Patches should be sent to the mailing list, not here. Please see
https://gcc.gnu.org/contribute.html
75 matches
Mail list logo
