https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160
Andre Heider changed:
What|Removed |Added
CC||a.heider at gmail dot com
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108596
--- Comment #7 from David Binderman ---
(In reply to Jakub Jelinek from comment #6)
> Fixed on the trunk so far.
linux-6.2-rc6 builds fine, when built with -O3.
Thanks for the quick fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45115
--- Comment #4 from Jonathan Wakely ---
This affects C++20 three-way comparisons, which return trivial structs wrapping
an integer.
>From PR 108635:
#include
struct S
{
std::weak_ordering operator<=>(const S&) const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #15 from Richard Biener ---
To not look at "nothing" (after successful SRA it should indeed become almost
nothing) I've added a store to a volatile 'x' global variable to the end
of main:
...
s2 = f(s1,s2);
x = s2;
return 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104883
--- Comment #5 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:aa18735f7aa99b40c56b3e3aacb1b28cb805bb90
commit r12-9099-gaa18735f7aa99b40c56b3e3aacb1b28cb805bb90
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107300
--- Comment #8 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:d2423144eb36a68fd0da9224857ce807714874a7
commit r13-5645-gd2423144eb36a68fd0da9224857ce807714874a7
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108630
--- Comment #3 from Andre Heider ---
While this is a libstdc++ related LTO issue, there's at least another libgcc
one, see the linked bug #60160.
With the workaround here and the patch there the LTOed target libraries look
alot more sane, but
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108086
--- Comment #16 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #13)
> (In reply to Richard Biener from comment #12)
> > A regression from GCC 10 which compiles this in 90s at -O1.
> >
> > Richard? Can you
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108635
Bug ID: 108635
Summary: Redundant calls to C++ spaceship operator<=> with
attribute pure or const
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106157
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108601
--- Comment #15 from CVS Commits ---
The master branch has been updated by hongtao Liu :
https://gcc.gnu.org/g:209f02b0a9e9adc0bf0247cb5eef04e0f175d64e
commit r13-5644-g209f02b0a9e9adc0bf0247cb5eef04e0f175d64e
Author: liuhongt
Date: Wed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108635
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
Richard Biener changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #21 from Tamar Christina ---
>
> OK, so that's an ADD_HIGHPART_EXPR then? Though the highpart of an
> add is only a single bit, isn't it? For scalar you'd use the
> carry bit here and instructions like adc to consume it. Is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108635
--- Comment #1 from Andrew Pinski ---
I suspect you need noexcept too. Otherwise you could in theory have an
exception.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #9 from rguenther at suse dot de ---
On Wed, 1 Feb 2023, meissner at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
>
> Michael Meissner changed:
>
>What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108435
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:0f349928e16fdc7dba52561e8d40347909f9f0ff
commit r13-5643-g0f349928e16fdc7dba52561e8d40347909f9f0ff
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108635
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45115
Andrew Pinski changed:
What|Removed |Added
CC||jzwinck at gmail dot com
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108625
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108443
--- Comment #1 from CVS Commits ---
The master branch has been updated by Andre Simoes Dias Vieira
:
https://gcc.gnu.org/g:e0bc13d396002f88b8c27e3a23c7eaee54d379d5
commit r13-5648-ge0bc13d396002f88b8c27e3a23c7eaee54d379d5
Author: Andre Vieira
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107674
--- Comment #2 from CVS Commits ---
The master branch has been updated by Andre Simoes Dias Vieira
:
https://gcc.gnu.org/g:d45ec8a732f449647afa89e46b80a4e0614ec28d
commit r13-5647-gd45ec8a732f449647afa89e46b80a4e0614ec28d
Author: Andre Vieira
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107674
--- Comment #1 from CVS Commits ---
The master branch has been updated by Andre Simoes Dias Vieira
:
https://gcc.gnu.org/g:75b58e77706e8b5057770f040005950940a9a0f5
commit r13-5646-g75b58e77706e8b5057770f040005950940a9a0f5
Author: Andre Vieira
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #22 from rguenther at suse dot de ---
On Thu, 2 Feb 2023, tnfchris at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
>
> --- Comment #21 from Tamar Christina ---
> >
> > OK, so that's an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
--- Comment #23 from Tamar Christina ---
(In reply to rguent...@suse.de from comment #22)
> On Thu, 2 Feb 2023, tnfchris at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108583
> >
> > --- Comment #21 from Tamar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108623
--- Comment #10 from rsandifo at gcc dot gnu.org
---
(In reply to rguent...@suse.de from comment #9)
> Please you do it, as far as I understand Richard S. no further adjustment
> is necessary but we could simplify some code after the change(?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108635
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2023-02-02
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108626
--- Comment #5 from Marat Radchenko ---
So, does "String literals, and compound literals with const-qualified types,
need not designate distinct objects." apply here or not? If not, how does the
case where it applies look like?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255
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=108651
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108651
kargl at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108650
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=108639
--- Comment #11 from Richard Biener ---
Yes, they should compare equal. Integer constant ranges do not need a type.
Not even FP constant ranges. Symbolic ranges need a type, but then the
endpoints in their symbolic form have one (and those
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108625
--- Comment #3 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:605d1297b91c2c7c23ccfe669e66dda5791d1f55
commit r13-5651-g605d1297b91c2c7c23ccfe669e66dda5791d1f55
Author: Richard Biener
Date:
/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
--with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.1 20230202 (experimental) [master r13-5642-g66d700af5bb] (GCC)
[539] %
[539] % gcctk -O1 small.c
small.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108508
--- Comment #4 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:f4e1b46618ef3bd7933992ab79f663ab9112bb80
commit r13-5657-gf4e1b46618ef3bd7933992ab79f663ab9112bb80
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108086
--- Comment #17 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:cd41085a37b8288dbdfe0f81027ce04b978578f1
commit r13-5658-gcd41085a37b8288dbdfe0f81027ce04b978578f1
Author: Richard Sandiford
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108626
--- Comment #6 from Jiang An ---
(In reply to Marat Radchenko from comment #5)
> So, does "String literals, and compound literals with const-qualified types,
> need not designate distinct objects." apply here or not? If not, how does
> the case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108637
Bug ID: 108637
Summary: ASAN at -O2 misses a stack-use-after-scope
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107300
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108484
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108633
--- Comment #1 from CVS Commits ---
The master branch has been updated by David Malcolm :
https://gcc.gnu.org/g:d84dc419e692d42c3b1e0c82e972c8a6f4c71389
commit r13-5655-gd84dc419e692d42c3b1e0c82e972c8a6f4c71389
Author: David Malcolm
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636
Bug ID: 108636
Summary: C++20 to undefined reference to
`std::filesystem::__cxx11::path::_List::type(std::file
system::__cxx11::path::_Type)' with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108625
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Summary|[11/12/13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108638
Bug ID: 108638
Summary: Another ice in decompose, at wide-int.h:984
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108626
--- Comment #7 from Marat Radchenko ---
While playing with it more, I found that clang behaves in a very strange way.
While they do combine `const char* const` + `const char[]`, the DO NOT combine
two `const char[]` together. I don't have any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108638
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.0
Component|c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107944
--- Comment #5 from CVS Commits ---
The releases/gcc-11 branch has been updated by Martin Jambor
:
https://gcc.gnu.org/g:e36385be53d51539e1c295a80085115b24fede32
commit r11-10496-ge36385be53d51539e1c295a80085115b24fede32
Author: Martin Jambor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107944
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108638
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #16 from Richard Biener ---
(In reply to Richard Biener from comment #14)
> Martin, can you look at the SRA issue? Do you want me to create a separate
> bugreport for this? The IL into SRA looks like
>
>:
> s2D.2755 = {};
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108626
--- Comment #8 from Marat Radchenko ---
Also, quote from C17 standard:
Like string literals, const-qualified compound literals can be placed into
read-only memory and *can even be shared*. (6.5.2.5 p 13).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
Jakub Jelinek changed:
What|Removed |Added
Version|unknown |13.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108484
--- Comment #7 from Sam James ---
Could you add 108463 to See Also? Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
Bug ID: 108640
Summary: ICE compiling busybox for m68k in change_address_1, at
emit-rtl.cc:2283
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106746
--- Comment #27 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:465a9c51e7d5bafa7a81195b5af20f2a54f22210
commit r13-5652-g465a9c51e7d5bafa7a81195b5af20f2a54f22210
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108484
--- Comment #5 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:465a9c51e7d5bafa7a81195b5af20f2a54f22210
commit r13-5652-g465a9c51e7d5bafa7a81195b5af20f2a54f22210
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108463
--- Comment #16 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:465a9c51e7d5bafa7a81195b5af20f2a54f22210
commit r13-5652-g465a9c51e7d5bafa7a81195b5af20f2a54f22210
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60160
--- Comment #9 from Andre Heider ---
See also https://github.com/rui314/mold/issues/977
mold v1.10.1 can't handle crt files which are built with LTO enabled.
But it sounds more like LTO on crt as-is produces the wrong thing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636
--- Comment #1 from Jonathan Wakely ---
Trunk has some additional errors:
/usr/bin/ld: /tmp/ccXeUWH9.o: in function
`std::filesystem::__cxx11::directory_iterator::operator==(std::default_sentinel_t)
const':
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108633
David Malcolm changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #18 from Richard Biener ---
OK, thanks for the info. These kind of testcases are quite useful in that they
are not done for the purpose of breaking the compiler and they show algorithmic
deficiencies in GCC. GCC aims to be able to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
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=108642
--- Comment #4 from David Spickett ---
Of course, I was just looking at at assembly output in compiler explorer and
then locally I didn't link the object. That's why it seemed to work.
Compiling and linking I get:
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104647
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104647
Andrew Pinski changed:
What|Removed |Added
Target Milestone|10.5|13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107897
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106170
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108643
Bug ID: 108643
Summary: Initializing parameter by ref in coroutine function
causes memory corruption
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108642
--- Comment #3 from Andrew Pinski ---
GCC has a builtin already for getting fpsr already too:
__builtin_aarch64_get_fpsr
Which of course is not documented ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636
Jonathan Wakely changed:
What|Removed |Added
Summary|C++20 undefined reference |[10/11/12 Regression] C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108500
--- Comment #17 from dhekir at gmail dot com ---
To be honest, the "real" test case is very similar to the last one I sent: it's
a semi-generated code, with some initialization of the data in the beginning,
and then a lot of statements which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108641
Bug ID: 108641
Summary: Hooking MS-MPI system into the NONMEM installation
failed
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108384
--- Comment #13 from Martin Jambor ---
I have proposed a fix on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611194.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108636
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:db8d6fc572ec316ccfcf70b1dffe3be0b1b37212
commit r13-5662-gdb8d6fc572ec316ccfcf70b1dffe3be0b1b37212
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108642
Bug ID: 108642
Summary: ACLE function __arm_wsr missing when compiling in C++
mode for AArch64
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108642
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-02-02
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
Aldy Hernandez changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107574
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
Jakub Jelinek changed:
What|Removed |Added
CC||amacleod at redhat dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #6 from Aldy Hernandez ---
Created attachment 54393
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54393=edit
untested patch for irange::operator==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108638
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
Jakub Jelinek changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60512
Jason Merrill changed:
What|Removed |Added
Resolution|WORKSFORME |---
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108642
--- Comment #2 from Andrew Pinski ---
Note the ACLE does not require "fpsr" to be supported either only
"o0:op1:CRn:CRm:op2" format is listed there ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108642
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #3)
> Which of course is not documented ...
They are documented but not in a decent way:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #7 from Aldy Hernandez ---
Jakub, take a look and see if you agree. I've fired off some tests.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108641
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107561
Hans-Peter Nilsson changed:
What|Removed |Added
CC||hp at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108639
--- Comment #9 from Andrew Macleod ---
(In reply to Jakub Jelinek from comment #8)
> (In reply to Aldy Hernandez from comment #5)
> > (In reply to Jakub Jelinek from comment #3)
> > > Created attachment 54391 [details]
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108085
--- Comment #4 from Andrew Pinski ---
Hmm, using the C++ front-end, the use-after-scope still happens at -O3 but not
with the C front-end.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644
--- Comment #1 from Andrew Pinski ---
The lto-plugin warnings are not a GCC issue really.
../../../gcc/lto-plugin/lto-plugin.c:501:19: warning: 'I' flag used with '%x'
gnu_printf format [-Wformat=]
Those are done correctly and using the right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108640
--- Comment #2 from Mikael Pettersson ---
Happens with 11.3.0, 10.4.0, and 9.5.0 too, so shouldn't be related to the CC0
conversion.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108645
--- Comment #1 from Evan Teran ---
To further experiment, i factored out `std::accumulate`:
```
#include
#include
#include
#include
void print_v(const char *rem, const std::vector ) {
std::cout << rem;
for (const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108644
--- Comment #2 from Andrew Pinski ---
h8300.cc should be using HOST_WIDE_INT_PRINT_DEC instead.
Can you file that issue seperately?
1 - 100 of 143 matches
Mail list logo