https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82366
--- Comment #10 from Jonathan Wakely ---
My best guess for what's happening in the original report is that the shared
library is being loaded into a running process which uses an older version of
libstdc++, and so the locale facets needed by the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82366
--- Comment #9 from Jonathan Wakely ---
If this only happens when the shared library is loaded from a closed source
application, you really need to talk to Oracle.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82366
--- Comment #8 from Jonathan Wakely ---
We still don't have a complete description of the problem though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972
--- Comment #9 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #8)
> These should work:
>
> (simplify
> (convert (eq one_zero_valued_p@1 one_zero_valued_p@2))
> (if (types_match (type, TREE_TYPE (@1)))
> (bit_xor @1 (bit_xor!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111972
--- Comment #8 from Andrew Pinski ---
These should work:
(simplify
(convert (eq one_zero_valued_p@1 one_zero_valued_p@2))
(if (types_match (type, TREE_TYPE (@1)))
(bit_xor @1 (bit_xor! @2 { build_one_cst (type); }
(simplify
(convert (
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&action=edit
First set of patches
Note the last patch is still being worked on really.
Note the first patch is just a small
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51030
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
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.
>
> Basi
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=82366
Alibek Omarov changed:
What|Removed |Added
CC||a1ba.omarov at gmail dot com
--- Comment
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=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=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
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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=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=111833
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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 Oct
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=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=111820
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
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=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=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
> tail-und
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
> tail-und
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 conside
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=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 26
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 26
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=104649
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112089
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |11.5
--- Comment #3 from Jonathan Wak
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=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 zero
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/
> debug_mode_using.html#debug_mode.usin
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
alloc
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=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
Date:
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=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=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=112100
Andrew Pinski changed:
What|Removed |Added
Component|sanitizer |libstdc++
--- Comment #1 from Andrew Pi
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 aroun
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=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: Tu
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=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 #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=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 instructi
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 avai
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 instruction
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=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 work
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=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=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
Sever
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=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
Date
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
Date
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=101631
Patrick Palka changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
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
Compo
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=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: UNCON
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
P
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
Seve
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=67740
--- Comment #14 from Bálint Aradi ---
Thanks a lot for fixing it!
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
--- 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=112098
Bug ID: 112098
Summary: suboptimal optimization of inverted bit extraction
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112097
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-10-26
Status|UNCONFI
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=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
Date
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 Oc
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):
>
> community.intel.com/t5/Intel-Fortran-Compiler/SELECT-TYPE-statemen
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):
>
> community.intel.com/t5/Intel-Fortran-Compiler/SELECT-TYPE-statemen
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: norm
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=111942
Alexandre Oliva changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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 a
84 matches
Mail list logo
