https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854
Uroš Bizjak changed:
What|Removed |Added
CC||Ganesh.Gopalasubramanian@am
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212
--- Comment #331 from John Paul Adrian Glaubitz ---
I found another failure when building webkit2gtk with the branch sh-lra-take3:
/usr/bin/g++-15 -DBUILDING_GTK__=1 -DBUILDING_WEBKIT=1 -DBUILDING_WITH_CMAKE=1
-DGETTEXT_PACKAGE=\"WebKitGTK-4.1\"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861
--- Comment #11 from Richard Biener ---
Yep note we now ggc_free gphi nodes when calling remove_phi_node (, true)
(and there are many incoming edges).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116860
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |15.0
Summary|New test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116856
--- Comment #5 from Richard Biener ---
Note some older GCC had issues with misaligned accesses but IIRC Bernd E. fixed
those.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111276
--- Comment #5 from Andrew Pinski ---
Created attachment 59211
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59211&action=edit
Patch but ...
It causes gcc.c-torture/execute/pr111422.c to fail.
See https://gcc.gnu.org/pipermail/gcc-patche
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116713
--- Comment #11 from pietro ---
(In reply to Oleg Endo from comment #9)
> (In reply to Andrew Pinski from comment #8)
> > See
> > https://gcc.gnu.org/legacy-ml/gcc-patches/2009-05/msg01233.html
> > and
> > https://gcc.gnu.org/legacy-ml/gcc-patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116713
--- Comment #10 from pietro ---
(In reply to Oleg Endo from comment #6)
> Thanks! Can you post that patch to the gcc-patches mailing list? It's more
> likely to receive attention and discussion -- which is needed, since this is
> outside of SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116713
Andrew Pinski changed:
What|Removed |Added
Component|target |rtl-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116713
--- Comment #9 from Oleg Endo ---
(In reply to Andrew Pinski from comment #8)
> See
> https://gcc.gnu.org/legacy-ml/gcc-patches/2009-05/msg01233.html
> and
> https://gcc.gnu.org/legacy-ml/gcc-patches/2009-09/msg00130.html
Nice find!
Yeah, same
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861
--- Comment #10 from Li Pan ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Li Pan from comment #8)
> > [0] psi ptr 0x7e2f8f00c000
> > [1] psi ptr 0x7e2f8f00c400
> > [2] psi ptr 0xa5a5a5a5a5a5a5a5 <=== Invalid.
> >
> > Looks som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854
--- Comment #7 from Anonymous ---
(In reply to Thiago Macieira from comment #5)
> This has nothing to do with -march=native. In fact, for the Gentoo people
> who are using -march=native, everything is fine because __RDRND__ is *not*
> defined (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854
--- Comment #8 from Anonymous ---
(In reply to Thiago Macieira from comment #5)
> This has nothing to do with -march=native. In fact, for the Gentoo people
> who are using -march=native, everything is fine because __RDRND__ is *not*
> defined (
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116713
--- Comment #7 from Andrew Pinski ---
There was a scheduler change I thought which prevented moving prefetches across
load/stores but I can't find it for some reason. Maybe it didn't make it in.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861
--- Comment #9 from Andrew Pinski ---
(In reply to Li Pan from comment #8)
> [0] psi ptr 0x7e2f8f00c000
> [1] psi ptr 0x7e2f8f00c400
> [2] psi ptr 0xa5a5a5a5a5a5a5a5 <=== Invalid.
>
> Looks some gsi info is polluted during matching.
[2] is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116713
--- Comment #6 from Oleg Endo ---
(In reply to pietro from comment #5)
> Created attachment 59210 [details]
> Add a blockage instruction before the prefetch
>
> I did a few tests on sh4-elf and adding a blockage before the prefetch keeps
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56592
--- Comment #5 from Oleg Endo ---
(In reply to Oleg Endo from comment #0)
> In order to
> minimize mode switches the function signature can be taken into account when
> deciding the default FPU precision for a particular function. E.g. when a
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861
--- Comment #8 from Li Pan ---
[0] psi ptr 0x7e2f8f00c000
[1] psi ptr 0x7e2f8f00c400
[2] psi ptr 0xa5a5a5a5a5a5a5a5 <=== Invalid.
Looks some gsi info is polluted during matching.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116713
--- Comment #5 from pietro ---
Created attachment 59210
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59210&action=edit
Add a blockage instruction before the prefetch
I did a few tests on sh4-elf and adding a blockage before the prefetch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861
--- Comment #7 from Li Pan ---
Thanks all for reducing, reproduced from myside and will take a look soon.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116713
--- Comment #4 from Oleg Endo ---
(In reply to pietro from comment #3)
> It looks like it's a more general GCC issue. The prefetch gets moved on both
> x86_64 and aarch64 on GCC, but not on clang: https://godbolt.org/z/Ycjr7Tq8b
>
> > It looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854
--- Comment #6 from Thiago Macieira ---
(In reply to Thiago Macieira from comment #5)
> The argument was that -march=bdver4 should not imply -mrdrnd, the same way
> that we had to fix -march=westmere to -march=haswell not to imply -maes: not
> a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854
--- Comment #5 from Thiago Macieira ---
(In reply to Andrew Pinski from comment #4)
> > Since the BIOS and/or OS can disable it,
>
> From the way I understand it, even things like avx can be turned on/off too.
> Does that mean gcc should disabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111276
--- Comment #4 from Andrew Pinski ---
(In reply to Richard Biener from comment #3)
> I think the API expects to be guarded to only be called on stmts that
> require rewriting.
That makes sense, so adding gimple_stmt_with_undefined_signed_overfl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115126
--- Comment #3 from GCC Commits ---
The master branch has been updated by Nathaniel Shead :
https://gcc.gnu.org/g:6a4d1c374eed177eceb12a50f3b25bd20f8b347a
commit r15-3906-g6a4d1c374eed177eceb12a50f3b25bd20f8b347a
Author: Nathaniel Shead
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112808
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861
--- Comment #6 from Sam James ---
Created attachment 59209
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59209&action=edit
reduced-again.ii
cvise gave me this when I asked it to try harder but it's still pretty
horrible.
Yours is a lot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116731
--- Comment #3 from GCC Commits ---
The trunk branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:6ac4e2f4b2ca9980670e7d3815a9140730df1005
commit r15-3905-g6ac4e2f4b2ca9980670e7d3815a9140730df1005
Author: Marek Polacek
Date: Tu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859
--- Comment #8 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:e23e5370d5855fc18b9f6f3fb680fcd2971e7a79
commit r15-3904-ge23e5370d5855fc18b9f6f3fb680fcd2971e7a79
Author: Jakub Jelinek
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-09-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861
--- Comment #4 from Andrew Pinski ---
Created attachment 59208
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59208&action=edit
Best I could get it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
--- Comment #15 from David Malcolm ---
Ouch, sorry about this. The -3 patch looks reasonable to me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
--- Comment #14 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #13)
> Created attachment 59202 [details]
> gcc15-pr116847-3.patch
>
> This seems to work on quick testing (just pch.exp so far).
>
> > I was thinking just history,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116743
--- Comment #10 from Rama Malladi ---
Created attachment 59207
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59207&action=edit
reproducer for funtion inlining issue - source
This is a reproducer to show GCC 12.3.0 inlining issue w AutoFD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116743
--- Comment #9 from Rama Malladi ---
Created attachment 59206
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59206&action=edit
reporducer for function inlining issue
This is a reproducer to show GCC 12.3.0 inlining issue w AutoFDO due to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113578
--- Comment #15 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:ee9f00606f184be37d6f9df74cc7e222157c7fee
commit r15-3903-gee9f00606f184be37d6f9df74cc7e222157c7fee
Author: Jonathan Wakely
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116743
--- Comment #8 from Rama Malladi ---
Here attached is a compilation unit extracted from `MySQL` repo
(https://github.com/mysql/mysql-server/blob/trunk/storage/innobase/handler/ha_innodb.cc)
which shows the impact of commit `3d9e6767939e` on func
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116858
--- Comment #6 from Sam James ---
Will do.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116858
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116862
Sam James changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50871
--- Comment #19 from Sam James ---
FTR:
* r15-3714-gd3a7302ec5985a
* r15-3859-g63a598deb0c9fc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859
--- Comment #7 from kargls at comcast dot net ---
(In reply to kargls from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > Created attachment 59203 [details]
> > gcc15-pr116859.patch
> >
> > Here it is in patch form. But I can't r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116858
Sam James changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
--- Comment #4 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116713
--- Comment #3 from pietro ---
It looks like it's a more general GCC issue. The prefetch gets moved on both
x86_64 and aarch64 on GCC, but not on clang: https://godbolt.org/z/Ycjr7Tq8b
> It looks like the problem can be "fixed" by inserting a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116862
Bug ID: 116862
Summary: [15 regression] gfortran.dg/initialization_25.f90
fails starting with r15-3890-g34bf6aa41ba539
Product: gcc
Version: 15.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861
--- Comment #3 from Sam James ---
Created attachment 59205
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59205&action=edit
reduced.i
cvise spat this out but it's pretty big still, not modified it yet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116851
--- Comment #2 from Andrew Pinski ---
Looks we warn about code which will be removed later on. I have not looked into
it further though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116736
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
CC||qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861
--- Comment #2 from Sam James ---
==236952== Invalid read of size 8
==236952==at 0x1EDB670: UnknownInlinedFun (tree-ssa-math-opts.cc:4174)
==236952==by 0x1EDB670: (anonymous
namespace)::math_opts_dom_walker::after_dom_children(basic_bloc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116860
Andrew Pinski changed:
What|Removed |Added
Keywords||testsuite-fail
Component|other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116736
--- Comment #2 from qinzhao at gcc dot gnu.org ---
currently, the "counted_by" info is used in __builtin_dynamic_object_size and
bounds sanitizer. and expected to catch out-of-bounds access during runtime.
So, this is the expected behavior.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861
Sam James changed:
What|Removed |Added
Target Milestone|--- |15.0
Version|13.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861
--- Comment #1 from Sam James ---
Note that this has Tamar's patch applied for PR116817.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116861
Bug ID: 116861
Summary: [15 regression] ICE when building netpbm-11.2.10
Product: gcc
Version: 13.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116860
Bug ID: 116860
Summary: New test case gcc.dg/tree-ssa/fold-xor-and-or.c from
r15-3866-ga88d6c6d777ad7 fails
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116851
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115860
--- Comment #4 from GCC Commits ---
The releases/gcc-14 branch has been updated by Stefan Schulze Frielinghaus
:
https://gcc.gnu.org/g:3eb3fbc89c638a72611efdc54110b8113f79ee8d
commit r14-10713-g3eb3fbc89c638a72611efdc54110b8113f79ee8d
Author:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859
--- Comment #6 from kargls at comcast dot net ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 59203 [details]
> gcc15-pr116859.patch
>
> Here it is in patch form. But I can't really test it on FreeBSD nor
> DragonFly.
I ju
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859
--- Comment #5 from Jakub Jelinek ---
Created attachment 59203
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59203&action=edit
gcc15-pr116859.patch
Here it is in patch form. But I can't really test it on FreeBSD nor DragonFly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859
--- Comment #2 from Sam James ---
(In reply to Andrew Pinski from comment #1)
> Maybe it was the recent `#pragma system_header` changes.
surely, yes..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
Jakub Jelinek changed:
What|Removed |Added
Attachment #59201|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-09-26
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859
Andrew Pinski changed:
What|Removed |Added
Summary|Bootstrap broken on FreeBSD |[15 Regression] Bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859
--- Comment #1 from Andrew Pinski ---
3d7c150e3f05 libstdc++-v3/config/os/bsd/freebsd/os_defines.h (Benjamin
Kosnik 2003-07-05 04:05:45 + 39) #define
_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC (_GLIBCXX_USE_C99_DYNAMIC || !defined
__LONG_LONG_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116859
Bug ID: 116859
Summary: Bootstrap broken on FreeBSD due to
_GLIBCXX_USE_C99_LONG_LONG_DYNAMIC
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
--- Comment #12 from Jason Merrill ---
(In reply to Jakub Jelinek from comment #10)
> Created attachment 59200 [details]
> gcc15-pr116847-1.patch
>
> Apparently diagnostic.h already uses auto_vec in one spot. So for now here
> is a cleanup pat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
--- Comment #11 from Jakub Jelinek ---
Created attachment 59201
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59201&action=edit
gcc15-pr116847-2.patch
Untested fix on top of the previous patch.
Unfortunately it regresses
FAIL: g++.dg/pch
On Thu, Sep 26, 2024 at 2:57 AM Jonathan Wakely via Gcc-bugs
wrote:
>
> On 26/09/24 04:44 +, Jason Mancini wrote:
> >Problem happens in 14.2.0, 13.2.0, 12.2.0
> >Doesn't seem to happen in 10.2.0 or 11.2.0
> >Only seems to happen for -std=c++17/14/11, but not for c++20/23/26.
> >Only seems to h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116856
--- Comment #4 from Andrew Pinski ---
```
#include
typedef uint32_t uuint32_t __attribute__ ((__aligned__(1))) ;
void f(uint8_t *array)
{
uuint32_t * ptr = (uuint32_t *) (array + 1);
*ptr ^= *(ptr+1);
}
```
Works for me with -mcpu=cortex
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116683
--- Comment #5 from Alex Coplan ---
Ah, so the problem seems to be that we're scanning for "Unrolled loop 3 times"
appearing exactly once in the dump, but on powerpc it appears twice; that is
because the loop in main gets unrolled too (presumabl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854
--- Comment #4 from Andrew Pinski ---
> Since the BIOS and/or OS can disable it,
>From the way I understand it, even things like avx can be turned on/off too.
Does that mean gcc should disable avx by default for most targets, NO.
Again the iss
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116683
Alex Coplan changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854
--- Comment #3 from Thiago Macieira ---
(In reply to Andrew Pinski from comment #2)
> So bdver4 does have RDRND support just buggy bios's cause linux to disable
> it:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
Sam James changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116078
--- Comment #6 from Filip Kastl ---
Or maybe one binary has some expensive instructions which the other one
doesn't. I didn't notice anything like that while looking through the perf
results but I'm still learning to use perf effectively.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116858
Sam James changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35779
--- Comment #14 from GCC Commits ---
The master branch has been updated by Sam James :
https://gcc.gnu.org/g:819098dc71f2079aedc15a904ab5f17f0788d991
commit r15-3899-g819098dc71f2079aedc15a904ab5f17f0788d991
Author: Sam James
Date: Thu Sep 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116858
--- Comment #2 from GCC Commits ---
The master branch has been updated by Sam James :
https://gcc.gnu.org/g:819098dc71f2079aedc15a904ab5f17f0788d991
commit r15-3899-g819098dc71f2079aedc15a904ab5f17f0788d991
Author: Sam James
Date: Thu Sep 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116858
Sam James changed:
What|Removed |Added
Last reconfirmed||2024-09-26
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116854
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116858
Sam James changed:
What|Removed |Added
Version|13.3.1 |15.0
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116858
Bug ID: 116858
Summary: gfortran.dg/initialization_25.f90 test failure
(exposed by r15-3890-g34bf6aa41ba539)
Product: gcc
Version: 13.3.1
Status: UNCONFIRMED
K
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116856
Richard Earnshaw changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116847
--- Comment #10 from Jakub Jelinek ---
Created attachment 59200
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59200&action=edit
gcc15-pr116847-1.patch
Apparently diagnostic.h already uses auto_vec in one spot. So for now here is
a clean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116857
--- Comment #6 from Sergei Trofimovich ---
The change fixed `x86_64-w64-mingw32` build for me. Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116852
--- Comment #3 from Jonathan Wakely ---
Yeah. they're implemented similarly with comdat approaches, but the C++
standard formally defines what "inline function" means, and it doesn't apply to
all function templates.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116683
--- Comment #3 from Alex Coplan ---
Sorry for the delay in looking into this.
So it looks like the unrolling works as expected without LTO, at least I see:
;; Unrolled loop 3 times, constant # of iterations 26 insns
in the dump with a powerpc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93158
Andre Vehreschild changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #2 from Andre Ve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116078
--- Comment #5 from Filip Kastl ---
I've double checked that the slowdown really happens on this commit. It realy
does. I've also double checked that the resulting binary is different. I've
seen this slowdown on 2 separate Zen 2 machines.
I'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116850
--- Comment #4 from Michael Matz ---
> Instead of using post-dominance from entry we could approximate that by
> dominance from exit which requires adding fake exit edges.
Hmm? post-dominance _is_ dominance from exit. (IOW: it's dominance on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116585
--- Comment #7 from Qing Zhao ---
>
> Yes, I'll pick it up after some soaking on trunk during my next backporting
> round. If you want to do the work of cherry-picking and regtesting feel free
> to do this earlier - it's been a week on trunk a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114855
--- Comment #56 from GCC Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:942bbb2357656019caa3f8ebd2d23b09222f039a
commit r15-3896-g942bbb2357656019caa3f8ebd2d23b09222f039a
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116725
--- Comment #3 from Antoni ---
Created attachment 59199
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59199&action=edit
Tentative fix for the issue
I have the following that seems to fix the issue.
I don't know if this is the correct way
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116725
Antoni changed:
What|Removed |Added
Attachment #59115|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116852
Nathaniel Shead changed:
What|Removed |Added
CC||nshead at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855
--- Comment #3 from Richard Biener ---
I would suggest to add a STMT_VINFO_ENSURE_NOTRAP or so and delay actual
verification to vectorizable_load when both vector type and VF are fixed.
We'd then likely need a LOOP_VINFO_MUST_USE_PARTIAL_VECTORS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116855
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
1 - 100 of 147 matches
Mail list logo
