https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820
--- Comment #15 from Hongtao.liu ---
(In reply to Richard Biener from comment #13)
> (In reply to Hongtao.liu from comment #12)
> > Fixed in GCC14, not sure if we want to backport the patch.
> > If so, the patch needs to be adjusted since GCC13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103861
--- Comment #15 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:7eed861e8ca3f533e56dea6348573caa09f16f5e
commit r14-4964-g7eed861e8ca3f533e56dea6348573caa09f16f5e
Author: liuhongt
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111833
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820
--- Comment #17 from Andrew Pinski ---
*** Bug 111833 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112104
--- Comment #1 from Andrew Pinski ---
This shows up in a really really bad benchmark:
https://github.com/kdlucas/byte-unixbench/blob/master/UnixBench/src/whets.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111318
--- Comment #1 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:e37bc2cf00671e3bc4d82f2627330c0f885a6f29
commit r14-4961-ge37bc2cf00671e3bc4d82f2627330c0f885a6f29
Author: Juzhe-Zhong
Date: Thu Oct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972
--- Comment #4 from Andrew Pinski ---
Is there a non-reduced testcase here? Or does the loop really just do j = j^1 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972
--- Comment #6 from Hongtao.liu ---
(In reply to Andrew Pinski from comment #5)
> Oh this is the original code:
> https://github.com/kdlucas/byte-unixbench/blob/master/UnixBench/src/whets.c
>
Yes, it's from unixbench.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
--- Comment #8 from JuzheZhong ---
(In reply to Maciej W. Rozycki from comment #7)
> Thank you for all your explanations. I think I'm still missing something
> here, so I'll write it differently (and let's ignore the tail-agnostic vs
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
--- Comment #9 from JuzheZhong ---
(In reply to Maciej W. Rozycki from comment #7)
> Thank you for all your explanations. I think I'm still missing something
> here, so I'll write it differently (and let's ignore the tail-agnostic vs
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51030
--- Comment #5 from Andrew Pinski ---
Created attachment 56317
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56317=edit
First set of patches
Note the last patch is still being worked on really.
Note the first patch is just a small speed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111318
Lehua Ding changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972
--- Comment #5 from Andrew Pinski ---
Oh this is the original code:
https://github.com/kdlucas/byte-unixbench/blob/master/UnixBench/src/whets.c
HEHEHEHEHEHEHEHEH. Basically after optimizing:
_9 = j_19 != 1;
_14 = (long int) _9;
Over to:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82366
Alibek Omarov changed:
What|Removed |Added
CC||a1ba.omarov at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103
Roger Sayle changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111833
--- Comment #5 from Hongtao.liu ---
It's the same issue as PR111820, thus should be fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112104
Bug ID: 112104
Summary: loop of ^1 should just be reduced to ^(n&1)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972
--- Comment #7 from Hongtao.liu ---
(In reply to Andrew Pinski from comment #3)
> First off does this even make sense to vectorize but rather do some kind of
> scalar reduction with respect to j = j^1 here . Filed PR 112104 for that.
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111888
--- Comment #1 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:e37bc2cf00671e3bc4d82f2627330c0f885a6f29
commit r14-4961-ge37bc2cf00671e3bc4d82f2627330c0f885a6f29
Author: Juzhe-Zhong
Date: Thu Oct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111888
JuzheZhong changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
--- Comment #7 from Maciej W. Rozycki ---
Thank you for all your explanations. I think I'm still missing something
here, so I'll write it differently (and let's ignore the tail-agnostic vs
tail-undisturbed choice for the purpose of this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111820
--- Comment #14 from CVS Commits ---
The releases/gcc-13 branch has been updated by hongtao Liu
:
https://gcc.gnu.org/g:82919cf4cb232166fed03d84a91fefd07feef6bb
commit r13-7988-g82919cf4cb232166fed03d84a91fefd07feef6bb
Author: liuhongt
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111833
--- Comment #4 from CVS Commits ---
The releases/gcc-13 branch has been updated by hongtao Liu
:
https://gcc.gnu.org/g:82919cf4cb232166fed03d84a91fefd07feef6bb
commit r13-7988-g82919cf4cb232166fed03d84a91fefd07feef6bb
Author: liuhongt
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51030
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
--- Comment #6 from JuzheZhong ---
> I have troubles chasing one down and the source code is so
> convoluted with macros I can't even find the implementation.
I am sorry for causing confusion to you here.
But because of the RVV fusion rules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111942
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104625
--- Comment #7 from Paul Thomas ---
(In reply to anlauf from comment #6)
> Steve Lionel of Intel confirmed that the code is valid, and that if X is
> polymorphic, so is (X):
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740
--- Comment #12 from CVS Commits ---
The releases/gcc-13 branch has been updated by Paul Thomas :
https://gcc.gnu.org/g:6fb12d3a0456a3503a670d95803aef10549f0134
commit r13-7986-g6fb12d3a0456a3503a670d95803aef10549f0134
Author: Paul Thomas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
Kito Cheng changed:
What|Removed |Added
CC||kito at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112092
--- Comment #5 from JuzheZhong ---
Yes. I am agree that some arch prefer agnostic than undisturbed even with more
vsetvls. That's why I have post PR for asking whether we can have a option like
-mprefer-agosnotic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111520
--- Comment #3 from CVS Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:33d38b431cced81e575b1d17d36cb9e43d64b02b
commit r14-4936-g33d38b431cced81e575b1d17d36cb9e43d64b02b
Author: Alexandre Oliva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111828
Kewen Lin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112097
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-10-26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112097
Bug ID: 112097
Summary: _PSTL_EARLYEXIT_PRESENT macro doesn't correctly
identify intel compilers.
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104625
--- Comment #8 from Paul Thomas ---
(In reply to anlauf from comment #6)
> Steve Lionel of Intel confirmed that the code is valid, and that if X is
> polymorphic, so is (X):
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91865
--- Comment #6 from CVS Commits ---
The master branch has been updated by Roger Sayle :
https://gcc.gnu.org/g:d1bb9569d7030490fe7bb35af432f934560d689d
commit r14-4941-gd1bb9569d7030490fe7bb35af432f934560d689d
Author: Roger Sayle
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112098
Bug ID: 112098
Summary: suboptimal optimization of inverted bit extraction
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112098
--- Comment #1 from Bruno Haible ---
The code that gets executed inside gcc is maybe the one mentioned in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109907#c2 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740
--- Comment #14 from Bálint Aradi ---
Thanks a lot for fixing it!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112099
Bug ID: 112099
Summary: GCC doesn't recognize matching friend operator!= to
resolve ambiguity in operator==
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111520
Alexandre Oliva changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111943
Alexandre Oliva changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112098
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101631
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112100
Bug ID: 112100
Summary: ubsan: misses UB when modifying std::string's trailing
\0
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112101
Bug ID: 112101
Summary: feature request: typeof_arg for extracting the type of
a function's (or function pointer's) arguments
Product: gcc
Version: unknown
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112101
--- Comment #1 from Abdulmalek Almkainzi ---
correction for the gurantee_type macro:
#define gurantee_type(exp, type) \
_Generic(exp, type: exp, default: (type){0})
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112102
Bug ID: 112102
Summary: Inefficient Integer multiplication on MIPS processors
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112099
Daniel Krügler changed:
What|Removed |Added
CC||daniel.kruegler@googlemail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112102
--- Comment #1 from Kaze Emanuar ---
Ignore the line about cycle counts. That was only applicable to my use case
before I realized GCC does this for all MIPS architectures. Sorry!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112103
Bug ID: 112103
Summary: [14 regression] gcc.target/powerpc/rlwinm-0.c fails
after r14-4941-gd1bb9569d70304
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #6 from Sam James ---
Try replying to the patch with 'ping'. I'm not a reviewer, but it both LGTM and
we're using it in Gentoo with no reported problems.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111971
--- Comment #6 from Vladimir Makarov ---
(In reply to Andrew Pinski from comment #4)
> But r1 is the argument register.
It is even worse, r1 is a stack pointer. Still the compilation should not
finish by LRA failure.
I've just started to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951
--- Comment #14 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:d8ff4b96b4be3bb4346c045bd0a7337079eabf90
commit r14-4949-gd8ff4b96b4be3bb4346c045bd0a7337079eabf90
Author: Thomas Schwinge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951
--- Comment #13 from CVS Commits ---
The master branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:967d4171b2eb0557e86ba28996423353f0f1b141
commit r14-4948-g967d4171b2eb0557e86ba28996423353f0f1b141
Author: Thomas Schwinge
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100470
Johel Ernesto Guerrero Peña changed:
What|Removed |Added
CC||johelegp at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111632
--- Comment #5 from Dimitry Andric ---
Is there any further action required to get this patch in? :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112102
--- Comment #2 from Andrew Pinski ---
-march=mips32r2 removes the nops. Iirc there was a hazard between the mflo and
mult instructions for older architectures.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112102
--- Comment #3 from Andrew Pinski ---
Which mips arch are you really trying to compile for?
Mips 1, 2, 4 or mips32 (r1-r5 or r6).
There are many different ones and mips32 (and above) does not have any delay
slots/hazards for the mult
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112102
--- Comment #5 from Andrew Pinski ---
/* True if mflo and mfhi can be immediately followed by instructions
which write to the HI and LO registers.
According to MIPS specifications, MIPS ISAs I, II, and III need
(at least) two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111969
--- Comment #6 from Patrick O'Neill ---
Mixed up my hashes when copy/pasting.
r14-4875-g9cf2e7441ee passes locally/CI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112102
--- Comment #7 from Andrew Pinski ---
Also is this function from real code or just an example to show the issue?
I suspect in real code you either have 2 extra nops or a scheduling bubble. the
nops might not make a huge difference ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111957
--- Comment #5 from CVS Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:662655e22dddf5392d9aa67fce45beee980e5454
commit r14-4955-g662655e22dddf5392d9aa67fce45beee980e5454
Author: Andrew Pinski
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111957
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112102
--- Comment #8 from Kaze Emanuar ---
This code is just an example, but I have seen this issue appear in many of my
collision functions. I agree it's not a huge issue in my use case, but it'd
still be cool to have this work well. I can work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112102
--- Comment #4 from Kaze Emanuar ---
I'm using the vr4300 (Nintendo 64). It does have the hazard between mult and
mflos. MULT can't be within 2 instructions of the MFLO. This shouldn't be an
issue here though since there were 3 instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112102
--- Comment #6 from Andrew Pinski ---
It just happened the scheduler didn't schedule it that way. Scheduling is NP
complete problem too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112100
Andrew Pinski changed:
What|Removed |Added
Component|sanitizer |libstdc++
--- Comment #1 from Andrew
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111530
Gaius Mulley changed:
What|Removed |Added
CC||gaius at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112098
--- Comment #3 from Andrew Pinski ---
Trying 6, 7, 8 -> 9:
6: {r105:SI=r108:SI 0>>0x9;clobber flags:CC;}
REG_DEAD r108:SI
REG_UNUSED flags:CC
7: {r106:SI=r105:SI&0x1;clobber flags:CC;}
REG_DEAD r105:SI
REG_UNUSED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112101
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112089
--- Comment #2 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:0c305f3dec9a992dd775a3b9607b7b1e8c051859
commit r14-4960-g0c305f3dec9a992dd775a3b9607b7b1e8c051859
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112096
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-10-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112100
--- Comment #2 from Jonathan Wakely ---
(In reply to Jan Engelhardt from comment #0)
> ==55843==ERROR: AddressSanitizer: heap-buffer-overflow on address 0xsomething
How would that even be possible? The terminating nul clearly has to be in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112100
--- Comment #4 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #2)
> It would need a completely new category of "memory location that you can
> read and write to but nothing else"
That was supposed to say "read and write
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112100
--- Comment #3 from Jonathan Wakely ---
(In reply to Andrew Pinski from comment #1)
> Maybe some how libstdc++ debug mode can catch this
> https://gcc.gnu.org/onlinedocs/gcc-13.2.0/libstdc++/manual/manual/
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112096
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> ```
> int t01(int x, int y)
> {
> bool t = x == 5 && y == 5;
> if (t) return 5; return y;
> } // y
> ```
> Is able to be detected in phiopt2. Just not the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112089
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.5
--- Comment #3 from Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104649
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
82 matches
Mail list logo
