https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
St
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44574
--- Comment #13 from Heiko Eißfeldt ---
(In reply to Andrew Pinski from comment #9)
> I am going to add a:
> #pragma GCC posion atoi
>
> And fix all of the cases.
Andrew, since I am currently working on this, could you supply a patch
regarding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117990
--- Comment #6 from Li Pan ---
Add (mem:BLK (scratch)) to strided load define_insn can help to fix this issue,
as (mem:BLK (scratch)) is considered to alias all other memories.
In theory, we can do even more accurate alias analysis here, like v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118010
Bug ID: 118010
Summary: -Wlto-type-mismatch warning/error during m2 bootstrap
on arm (gm2-libs-boot/Glibc.h:206:16: warning: type of
‘libc_lseek’ does not match original declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118010
--- Comment #1 from Sam James ---
It may well work to just enforce _FILE_OFFSET_BITS=64 as we do in other parts
of the build. Not checked.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117999
--- Comment #5 from Christophe Lyon ---
Note that the test passed before commit r15-5997-g75e7d1600f4785 , which was
bisected by the CI.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117899
--- Comment #2 from Christophe Piault ---
According to Intel support team they don't have any plans currently regarding
an OpenMP backend on their side.
Looking for volunteers, AdaptiveCpp author is "very open to collaborating with
the GCC proj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118008
Sam James changed:
What|Removed |Added
Known to work||11.5.0, 12.4.1, 13.3.1
Target Milestone|-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118008
--- Comment #5 from Sam James ---
Created attachment 59840
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59840&action=edit
l.go.xz
So far, more needs to be done:
```
/var/tmp/portage/sys-devel/gcc-14.2.1_p20241207/work/build/./gcc/gccgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118004
Manuel López-Ibáñez changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #1 from Georg-Johann Lay ---
(In reply to Georg-Johann Lay from comment #0)
> For comparison, here is the code when the test is for bit 1 instead of bit 0:
>
> if (b & 1)
^^
This should be "if (b & 2)"
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117899
--- Comment #3 from Jonathan Wakely ---
Instead of looking for volunteers you might need to consider funding somebody
to do the work. A new PSTL backend is a large and complex piece of work. A
SPIR-V backend would be even larger.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94531
--- Comment #2 from GCC Commits ---
The master branch has been updated by Torbjorn Svensson :
https://gcc.gnu.org/g:bdf75257aad299cbad5a62dd10a45139ac3aa369
commit r15-6164-gbdf75257aad299cbad5a62dd10a45139ac3aa369
Author: Torbjörn SVENSSON
Da
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #4 from Georg-Johann Lay ---
It's even crazier when the device doesn't have MUL instruction. In that case,
a libgcc function is used. With -Os the call consumes less code than the
bit-extract + extend + neg + and, so a library call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118003
--- Comment #2 from Martin Storsjö ---
> I also don't want to have to use Windows APIs here.
How does that work within libstdc++ in general, with std::filesystem using
wchar_t as std::filesystem::path::value_type? Are all paths converted to nar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116669
Andre Vehreschild changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #2 from Andre V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #6 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #5)
> /* Expand X*Y as X&-Y when Y must be zero or one. */
> ...
> if (bit0_p || bit1_p)
> {
> bool speed = optimize_insn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #7 from Andrew Pinski ---
(In reply to Georg-Johann Lay from comment #6)
> (In reply to Andrew Pinski from comment #5)
> > /* Expand X*Y as X&-Y when Y must be zero or one. */
> > ...
> > if (bit0_p || bit1_p)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118016
Bug ID: 118016
Summary: GCC adds excess precision to floating point literals,
and therefore rounds incorrectly (x87 FPU,
-fexcess-precision=standard)
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118016
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92875
Andrew Pinski changed:
What|Removed |Added
CC||geza.herman at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117946
Uroš Bizjak changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117978
--- Comment #3 from Richard Sandiford ---
I think this would be better done in expand rather than gimple. The gimple
representation would be a vector load in a 128-bit type, followed by a zeroing
extension to the original SVE type. I'm not sur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117990
--- Comment #7 from Robin Dapp ---
Does it work when we use the old gather-load code path instead of the strided
load or does this have the same problem?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118011
Bug ID: 118011
Summary: -fshort-enums reported as enabled by default
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117990
--- Comment #8 from Li Pan ---
The gather load has involved this (mem:BLK (scratch)) already, thus it doesn't
have this problem.
BTW, does alias analysis support the complicated scenario like strided/index
load (I bet we may need more info to f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
Bug ID: 118012
Summary: [avr] Expensive code (bit extract + extend + neg +
and) instead of bit test
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117996
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
Target M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
--- Comment #9 from GCC Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:d46c7f313b5a30ee04080f249e31e12987d50aa2
commit r15-6170-gd46c7f313b5a30ee04080f249e31e12987d50aa2
Author: Martin Uecker
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118001
--- Comment #1 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:f8a602ce5394ef7e0c56b48e3bd89f97f0411c45
commit r15-6171-gf8a602ce5394ef7e0c56b48e3bd89f97f0411c45
Author: Georg-Johann Lay
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118003
--- Comment #7 from Martin Storsjö ---
(In reply to Jonathan Wakely from comment #6)
> I have zero interest in learning any native APIs and my employer isn't
> interested in Windows support, so if I can't easily get it working with code
> simila
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |middle-end
--- Comment #5 from Andrew P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118014
Bug ID: 118014
Summary: address computation for coroutine frame differs
between BasePromise and MostDerivedPromise
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118014
--- Comment #1 from Giel ---
While different from PR104177 I believe that Arsen's patch for that would also
solve this bug: [PATCH 2/2] c++/coroutines: handle (new-)extended alignment
[PR104177]
(https://gcc.gnu.org/pipermail/gcc-patches/2024-Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114713
--- Comment #3 from GCC Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:d46c7f313b5a30ee04080f249e31e12987d50aa2
commit r15-6170-gd46c7f313b5a30ee04080f249e31e12987d50aa2
Author: Martin Uecker
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117724
--- Comment #12 from GCC Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:d46c7f313b5a30ee04080f249e31e12987d50aa2
commit r15-6170-gd46c7f313b5a30ee04080f249e31e12987d50aa2
Author: Martin Uecker
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118004
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #3 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117987
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118013
Bug ID: 118013
Summary: bogus "infinite loop" warning
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117091
--- Comment #23 from Filip Kastl ---
(In reply to Sam James from comment #22)
> Are we keeping this one open for the improvement mentioned in
> https://inbox.sourceware.org/gcc-patches/z1gdhpphod-5m...@fkdesktop.suse.cz/?
I wanted to close this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118015
Bug ID: 118015
Summary: bogus "check for NULL after already dereferencing it"
warning
Product: gcc
Version: 14.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118003
--- Comment #3 from Jonathan Wakely ---
Changing directory does work:
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -1327,8 +1327,22 @@ fs::remove(const path& p, error_code& ec) noexcept
std::uintmax_t
fs::r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118003
--- Comment #4 from Jonathan Wakely ---
(In reply to Martin Storsjö from comment #2)
> > I also don't want to have to use Windows APIs here.
>
> How does that work within libstdc++ in general, with std::filesystem using
> wchar_t as std::filesy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118003
--- Comment #5 from Martin Storsjö ---
(In reply to Jonathan Wakely from comment #4)
> (In reply to Martin Storsjö from comment #2)
> > > I also don't want to have to use Windows APIs here.
> >
> > How does that work within libstdc++ in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94531
Torbjorn SVENSSON changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
Georg-Johann Lay changed:
What|Removed |Added
CC||michael.collison at linaro dot
org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117978
Jennifer Schmitz changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jschmitz at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118001
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #8 from Georg-Johann Lay ---
Isn't there a way to make match.md patterns conditional?
A -fno-tree-phiopt gives mixed results...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115532
sandra at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #9 from Andrew Pinski ---
(In reply to Georg-Johann Lay from comment #8)
> Isn't there a way to make match.md patterns conditional?
match patterns should almost never be conditional unless it is producing direct
internal functions.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116979
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117997
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117990
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118003
--- Comment #8 from Jonathan Wakely ---
I think you'll get similar problems when trying to recurse into them with
recursive_directory_iterator, because that's what remove_all was doing when it
failed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005
--- Comment #16 from Alejandro Colomar ---
(In reply to Andrew Pinski from comment #13)
> We have been warning about noinline and inline since the noinline attribute
> was added back in r0-37987-g9162542e3d0cd2 .
>
> When noipa was added (r8-22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118005
--- Comment #17 from Alejandro Colomar ---
(In reply to Jakub Jelinek from comment #15)
> I think the current behavior is correct, noipa implies the function boundary
> is an optimization barrier for the compiler, while inline is the exact
> opp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118000
--- Comment #1 from GCC Commits ---
The master branch has been updated by Georg-Johann Lay :
https://gcc.gnu.org/g:c94ac10ffc422d4c9a28266b1340382d69518464
commit r15-6175-gc94ac10ffc422d4c9a28266b1340382d69518464
Author: Georg-Johann Lay
Dat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118000
Georg-Johann Lay changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116447
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118003
--- Comment #6 from Jonathan Wakely ---
I have zero interest in learning any native APIs and my employer isn't
interested in Windows support, so if I can't easily get it working with code
similar to POSIX, I'm not going to work on it.
If you or
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117899
--- Comment #4 from Christophe Piault ---
We have a RFE opened for this issue and will try to see with Intel contacts if
they can update their plans.
If you know another way to fund this work, feel free to share.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117996
--- Comment #3 from GCC Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:b563a3a00db064d4d47fd171379e1d34d0698faa
commit r15-6176-gb563a3a00db064d4d47fd171379e1d34d0698faa
Author: Eric Botcazou
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106631
--- Comment #1 from Barry Revzin ---
I tried to open this bug report again today (although this time I ran into it
due to a missing #include for the primary definition, rather than typoing the
name).
Still took me a while to parse the error me
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117996
--- Comment #4 from GCC Commits ---
The releases/gcc-14 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:d470d64b398684f510637fe8ada570fff92af841
commit r14-11083-gd470d64b398684f510637fe8ada570fff92af841
Author: Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117996
--- Comment #5 from GCC Commits ---
The releases/gcc-13 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:0f74991d88948238530ed1216d334ac123483c5d
commit r13-9249-g0f74991d88948238530ed1216d334ac123483c5d
Author: Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117996
--- Comment #6 from GCC Commits ---
The releases/gcc-12 branch has been updated by Eric Botcazou
:
https://gcc.gnu.org/g:62c1d98b870f84bd511deba7b93e8c49e38f4335
commit r12-10856-g62c1d98b870f84bd511deba7b93e8c49e38f4335
Author: Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117996
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117258
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117996
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117095
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118003
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2024-12-12
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
Georg-Johann Lay changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Component|middle-end
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117095
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116447
--- Comment #4 from Torbjorn SVENSSON ---
(In reply to Jakub Jelinek from comment #3)
> libsupc++.a (fundamental_type_info.o) (also included in libstdc++.a and
> libstdc++.so.6)
> should provide those symbols since r13-4722 if the target support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118004
--- Comment #4 from Manuel López-Ibáñez ---
(In reply to Xi Ruoyao from comment #3)
> Making the entire ... access (read_only) would be incorrect, considering the
> argument corresponding to %n should be access (write_only) instead.
>
> So we s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118011
--- Comment #1 from Andreas Schwab ---
-fshort-enums has a special "uninitialized" state which is only finalized after
target options have been processed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116447
--- Comment #2 from Torbjorn SVENSSON ---
(In reply to Richard Earnshaw from comment #1)
> How was the compiler configured and what's the full command line used when
> building the test?
The toolchain was built using the scripts here:
https://g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114014
--- Comment #5 from GCC Commits ---
The master branch has been updated by Martin Uecker :
https://gcc.gnu.org/g:d46c7f313b5a30ee04080f249e31e12987d50aa2
commit r15-6170-gd46c7f313b5a30ee04080f249e31e12987d50aa2
Author: Martin Uecker
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116447
--- Comment #5 from Jakub Jelinek ---
I certainly get the _ZTIDF16_ symbol when (admittedly cross-)compiling
fundamental_type_info.C with -mthumb -mcpu=cortex-m55 -mfloat-abi=hard
-mfpu=auto
Anyway, if this doesn't work with the --with-multilib-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117724
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114713
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #4 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113688
uecker at gcc dot gnu.org changed:
What|Removed |Added
Summary|[14/15 Regression] |[14] verify_type fails for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116447
Richard Earnshaw changed:
What|Removed |Added
CC||clyon at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117797
--- Comment #2 from GCC Commits ---
The master branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:d4330ff9bc9a2995e79d88b09a2ee76673167661
commit r15-6177-gd4330ff9bc9a2995e79d88b09a2ee76673167661
Author: Paul Thomas
Date: Thu D
dcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-20241212162925-r15-6176-gb563a3a00db064-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.0 20241212 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #11 from Andrew Pinski ---
(In reply to Georg-Johann Lay from comment #10)
> > Expanding it for scalar modes and using it for isel can happen.
> How would the backend chime in? Only per costs, or is there more control
> qua new stan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116979
Jakub Jelinek changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118016
--- Comment #3 from Joseph S. Myers ---
For C, see https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1361.htm and the
minutes https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1380.pdf where it was
accepted (thus reverting an abortive attempt to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44574
--- Comment #15 from Heiko Eißfeldt ---
Thanks a lot, I will add atoq too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116979
--- Comment #14 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #12)
> With the following patch instead it isn't vectorized anymore and uses scalar
> code:
AFAICS, this is the correct patch to implement partial vector V2SFmode patte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116979
--- Comment #13 from Jakub Jelinek ---
Without the #c12 patch, slp2 shows with -O2 -mfma:
Vector cost: 172
Scalar cost: 184
with it
Vector cost: 156
Scalar cost: 152
No idea how the scalar cost decreased so much.
.VEC_FMADDSUB (_8, _10,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #10 from Georg-Johann Lay ---
(In reply to Andrew Pinski from comment #9)
> Basically gimple should be almost all target indepdendent except in the late
> stages.
The problem is that some canonicalizations are very expensive on some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115127
--- Comment #9 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f7d1b9cdc0dd811722798530efffd736bfc2bc1d
commit r15-6179-gf7d1b9cdc0dd811722798530efffd736bfc2bc1d
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115127
Jakub Jelinek changed:
What|Removed |Added
Summary|[12/13/14/15 Regression]|[12/13/14 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118016
--- Comment #2 from geza.herman at gmail dot com ---
I disagree how the standard is interpreted.
If I write "1.1", it is a double literal. Its value should be the closest
double to "1.1". It is fine, if later, the compiler treats this value as l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118014
--- Comment #2 from Andrew Pinski ---
[/opt/compiler-explorer/gcc-trunk-20241212/include/c++/15.0.0/coroutine:207:7]
# DEBUG INLINE_ENTRY from_promise
[/opt/compiler-explorer/gcc-trunk-20241212/include/c++/15.0.0/coroutine:209:19]
# DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118016
--- Comment #4 from geza.herman at gmail dot com ---
Thanks!
After reading the links, I still think that the current behavior is bad (the
arguments in the docs weren't convincing, tbh), but it seems that it is
supposed to be like this, so arguin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117970
--- Comment #6 from Lewis Hyatt ---
I can reproduce that failure using your configuration to make cross compilers
on an x86-64 host. The tests pass when a single arch is configured, there are
just problems with multilib configuration. They also
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117797
Paul Thomas changed:
What|Removed |Added
Summary|[13/14/15 Regression] ICE |[13/14 Regression] ICE in
1 - 100 of 146 matches
Mail list logo
