https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #14 from Uroš Bizjak ---
(In reply to Jan Kratochvil from comment #13)
> The question is whether gcc can rely on the undocumented Intel behavior as
> described in Comment 7. glibc already relies on it anyway.
I don't think this is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108939
--- Comment #1 from Andrew Pinski ---
Removing -std=c++11 still warns for me with GCC 10 and GCC 11.
The biggest difference I saw between GCC 11 and GCC 12 was:
GCC 12+ produces:
strncpy (, , 32);
While GCC 10/11 produces:
strncpy (, ,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108939
Bug ID: 108939
Summary: -Wstringop-truncation warning when -fsanitize=address,
-O2 and -std=c++11 are used
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108874
--- Comment #8 from Andrew Pinski ---
(In reply to Hongtao.liu from comment #7)
> Can we recognize it as bswap32 + roatate 16 in match.pd when backend
> supports boths, and then it should be easy for aarch64/arm to tranform bswap
> + ratate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108461
--- Comment #2 from Arseny Solokha ---
Created attachment 54540
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54540=edit
gkd diff #2
I believe this simpler testcase demonstrates the same issue.
long long int m, n;
void
foo (void)
{
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108874
Hongtao.liu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108937
--- Comment #3 from saitofuyuki at jamstec dot go.jp ---
Thanks a lot.
> Not sure it's a bug.
I see. I do agree it's not a bug and the answer of the particular case is
undefined.
But (for 32-bit integer case), since implemented ISHFT(I,32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
--- Comment #18 from CVS Commits ---
The releases/gcc-11 branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:cf3d95cce379f3260ad27264de0398e2ed1db2ea
commit r11-10549-gcf3d95cce379f3260ad27264de0398e2ed1db2ea
Author: Kewen Lin
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108938
Bug ID: 108938
Summary: Missing bswap detection
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96373
--- Comment #17 from CVS Commits ---
The releases/gcc-12 branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:cea4b90f8305df681d322315a9c30e3924e1e79d
commit r12-9206-gcea4b90f8305df681d322315a9c30e3924e1e79d
Author: Kewen Lin
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108937
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108937
--- Comment #1 from saitofuyuki at jamstec dot go.jp ---
Sorry, I missed to attach the test program.
program test_bits
implicit none
integer,parameter :: KT = 4
integer,parameter :: lbits = bit_size(0_KT)
integer(kind=KT) x, y0, y1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108937
Bug ID: 108937
Summary: Intrinsic IBITS(I,POS,LEN) fails when LEN equals to
BIT_SIZE(I).
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108779
--- Comment #8 from zach-gcc at cs dot stanford.edu ---
Alright sounds good, thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108779
--- Comment #7 from Andrew Pinski ---
(In reply to zach-gcc from comment #6)
> Is there any update on when this will be merged? Is this waiting on GCC 13
> to be released first?
Correct, it won't be merged until the trunk goes to stage 1 which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108779
--- Comment #6 from zach-gcc at cs dot stanford.edu ---
Is there any update on when this will be merged? Is this waiting on GCC 13 to
be released first?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #13 from Jan Kratochvil ---
(In reply to Uroš Bizjak from comment #12)
> (In reply to Jan Kratochvil from comment #8)
>
> > The revert makes it 13x faster. But the produced code still falls back to
> > calling glibc fmod() as shown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108936
Bug ID: 108936
Summary: internal compiler error: in
type_has_nontrivial_copy_init, at cp/tree.cc:4525
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108886
--- Comment #2 from Jonny Grant ---
(In reply to Jonathan Wakely from comment #1)
> Why are you suggesting adding a check in two places when the first one just
> calls the second one?
Feels clearer in the callstack if operator= throws when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108879
--- Comment #2 from Jonny Grant ---
(In reply to David Malcolm from comment #1)
> Yeah, I haven't implemented exceptions yet, so even the simplest cases are
> likely to fail :-/
>
> I plan to spent a chunk of my GCC *14* cycles working on C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #12 from Uroš Bizjak ---
(In reply to Jan Kratochvil from comment #8)
> The revert makes it 13x faster. But the produced code still falls back to
> calling glibc fmod() as shown in the disassembly in Comment 0.
> If I use the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #11 from Uroš Bizjak ---
(In reply to Jan Kratochvil from comment #8)
> It is true replacing fmod() with fmodl() makes it 5x faster (but only 5x).
> There is still some infinity check and I haven't found any real
> justification in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108935
Bug ID: 108935
Summary: Incorrect warning for infinite recursion
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108909
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108909
--- Comment #4 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:e6d39f68d03c46637ca6e1bede3d28eae6278df3
commit r13-6351-ge6d39f68d03c46637ca6e1bede3d28eae6278df3
Author: Peter Foley
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108909
Eric Botcazou changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #3 from Eric Botcazou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108909
Eric Botcazou changed:
What|Removed |Added
Last reconfirmed||2023-02-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103944
Iain Sandoe changed:
What|Removed |Added
Last reconfirmed||2023-02-26
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107884
--- Comment #10 from Michael N. Moran ---
(In reply to SASANO Takayoshi from comment #9)
> (In reply to Michael N. Moran from comment #8)
> > I created a corresponding cp-demangle.s file and attached it
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107884
--- Comment #9 from SASANO Takayoshi ---
(In reply to Michael N. Moran from comment #8)
> I created a corresponding cp-demangle.s file and attached it
> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54530
Please read this thread carefully,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #10 from Jan Kratochvil ---
(In reply to Alexander Monakov from comment #9)
> You just need to pass -fno-math-errno (the call is for setting errno,
> similar to how gcc emits the sqrt() sequence).
True, thanks.
So I think the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98470
--- Comment #4 from jcmvbkbc at gcc dot gnu.org ---
I've noticed that this forward-propagation of the literal load followed by not
calling the secondary reload function happens when the first literal load
instruction has the following in its
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108922
--- Comment #9 from Alexander Monakov ---
(In reply to Jan Kratochvil from comment #8)
> The revert makes it 13x faster. But the produced code still falls back to
> calling glibc fmod() as shown in the disassembly in Comment 0.
> If I use the
33 matches
Mail list logo
