https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #10 from Richard Biener ---
(In reply to Roger Sayle from comment #7)
> Created attachment 54843 [details]
> proposed patch
>
> Proposed patch. Does this look reasonable?
Yes, but doesn't this work for all GET_CODE (op) != ASHIFTR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109369
--- Comment #10 from Pali Rohár ---
> I would suggest to move the bug to the Binutils Bugzilla.
Done: https://sourceware.org/bugzilla/show_bug.cgi?id=30343
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109449
--- Comment #5 from Richard Biener ---
As expected that causes
FAIL: c-c++-common/Wstringop-truncation.c -std=gnu++98 bug 77293 (test for
warn
ings, line 271)
FAIL: g++.dg/warn/Wplacement-new-size-7.C -std=gnu++98 (test for warnings,
lin
e 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109493
--- Comment #6 from Mikhail Mitskevich ---
(In reply to Sam James from comment #3)
> It's unclear to me from the reports if this started with GCC 13 or if it
> always failed on s390x. Could you clarify? Thanks.
I have run this test on GCC 12 on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494
Bug ID: 109494
Summary: inline const variables interfere with source_location
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109048
--- Comment #11 from Richard Biener ---
The recent patch improved this to avoid some of the compares. We still have
the three-argument PHI and thus three VEC_CONDs.
.L10:
vmovups (%rdi,%rdx), %ymm0
vcmpltps%ymm6, %ymm0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108722
Richard Biener changed:
What|Removed |Added
Keywords||testsuite-fail
Assignee|unas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #9 from Jonathan Wakely ---
No:
This elision of copy/move operations, called copy elision, is permitted in the
following circumstances (which may be combined to eliminate multiple copies):
— in a return statement in a function with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109434
--- Comment #6 from Tomáš Pecka ---
I can confirm that the bug now does not appear in our application code that I
simplified into attached code. Tested on commit df7f55cb2ae.
Thank you!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109369
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #10 from Jakub Jelinek ---
Making the reference types to return or parameter non-POD types passed by value
restrict could be
--- gcc/cp/call.cc.jj 2023-03-30 09:34:05.609725768 +0200
+++ gcc/cp/call.cc 2023-04-13 09:56:53.2269
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485
--- Comment #6 from Dani Borg ---
(In reply to Andrew Pinski from comment #1)
> Is this even valid with NFS?
My knowledge of different file systems is limited, but I think checking the
presence of a directory should be as valid on NFS as most o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109048
Hongtao.liu changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109490
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
Sum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485
--- Comment #7 from Dani Borg ---
(In reply to Andrew Pinski from comment #2)
> Also does it work with Windows style pathes?
> I am suspecting clang does not do the right thing there ...
I don't know much about Windows path handling, so I can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109493
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #7 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485
--- Comment #8 from Dani Borg ---
(In reply to Andrew Pinski from comment #3)
> Also I really doubt the improvement here is less than 1% improvement really
> for the common case where people don't put pathes in the include line.
Yes, it really
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #11 from Jakub Jelinek ---
And I don't see any code generation changes on the #c0 testcase with added
#include with the patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109485
--- Comment #9 from Dani Borg ---
(In reply to Andrew Pinski from comment #5)
> Note I think clang's "optimization" might get the case where a subdirectory
> is not "executable" but is readable wrong.
>
> So this is definitely something which w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109460
--- Comment #36 from Costas Argyris ---
Regarding usage of the -r flag:
Building windows(mingw)-hosted gcc with clang at this point seems highly
experimental at best, and impossible with msvc.
With clang (lld linker), -r is supported with ELF,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108809
Jiu Fu Guo changed:
What|Removed |Added
CC||guojiufu at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109412
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107682
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91355
Richard Biener changed:
What|Removed |Added
CC||matz at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109495
Bug ID: 109495
Summary: Stack is used (unexpectedly) for copying on-heap
objects (while clang doesn't)
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109495
--- Comment #1 from gcc-bug-reports at xhtml dot guru ---
Created attachment 54849
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54849&action=edit
test.cpp: test code that triggers Wframe-larger-than in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93271
Richard Biener changed:
What|Removed |Added
Target||i?86-*-*
Last reconfirmed|2022-01-29
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109490
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |11.4
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #6 from Richard Biener ---
Doesn't happen with a cross from x86_64 to powerpc64-suse-linux. I've just
used
./configure --target=powerpc64-suse-linux --enable-languages=c,c++,lto
and
./cc1plus -quiet -I include t.ii -mcpu=power8 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2023-04-13
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109492
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109409
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=109493
Richard Biener changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109488
Gaius Mulley changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109495
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Known to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109496
Bug ID: 109496
Summary: Cannot pass a constant char to an array of char formal
parameter
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #8 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109496
Gaius Mulley changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109497
Bug ID: 109497
Summary: Adding two constant chars should result in a string of
two chars
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109497
Gaius Mulley changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109484
--- Comment #9 from Jakub Jelinek ---
The documentation already says that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #10 from chenglulu ---
(In reply to Xi Ruoyao from comment #5)
> The test fails on loongarch64-linux-gnu. foo is kept in 114t.threadfull1,
> but removed in 135t.forwprop3.
>
> Does this mean something is wrong for LoongArch, or we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109466
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Resolu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #11 from Xi Ruoyao ---
(In reply to chenglulu from comment #10)
> (In reply to Xi Ruoyao from comment #5)
> > The test fails on loongarch64-linux-gnu. foo is kept in 114t.threadfull1,
> > but removed in 135t.forwprop3.
> >
> > Does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #8 from Richard Biener ---
So we have a NULL op, in this case
(gdb) p *vro1
$4 = {opcode = TARGET_MEM_REF, clique = 0, base = 0, reverse = 0, align = 0,
off = {coeffs = {-1}}, type = ,
op0 = , op1 = , op2 = }
(gdb) p *vro2
$5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109269
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #12 from chenglulu ---
(In reply to Xi Ruoyao from comment #11)
> (In reply to chenglulu from comment #10)
> > (In reply to Xi Ruoyao from comment #5)
> > > The test fails on loongarch64-linux-gnu. foo is kept in 114t.threadfull1,
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109495
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #9 from Richard Biener ---
Note it's IPA consuming the most time for me, but it might be just another case
of always_inline abuse (having always_inline across a deep call stack can
exponentially increase compile-time)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109498
Bug ID: 109498
Summary: SVE support for ctz
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #12 from Richard Biener ---
(In reply to Jakub Jelinek from comment #11)
> And I don't see any code generation changes on the #c0 testcase with added
> #include with the patch.
Yes, that's because we cannot disambiguate the call ag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499
Bug ID: 109499
Summary: Unnecessary zeroing in SVE loops
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #13 from Jakub Jelinek ---
(In reply to Richard Biener from comment #12)
> Note maybe the restrict qualification isn't the best representation since
> it doesn't capture the value will die upon function return (does it? I
> gues the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108809
--- Comment #3 from Jiu Fu Guo ---
A similar different view between BE and LE on the vector for vec_xst_len_r.
For:
store_data_uc = (vector unsigned char){ 1, 2, 3, 4, 5, 6, 7, 8,
9, 10, 11, 12, 13,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109495
--- Comment #4 from Richard Biener ---
In store_field we run into
/* If the structure is in a register or if the component
is a bit field, we cannot use addressing to access it.
Use bit-field techniques or SUBREG to store in it. */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109476
--- Comment #11 from Wilhelm M ---
After testing some more code, I got this ICE:
/home/lmeier/Projekte/wmucpp/boards/rcfoc/gimbal_sbus_01.cc: In static member
function 'static void GlobalFsm::ratePeriodic() [with BusDevs
=BusDevs > >]':
/home/l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109495
--- Comment #5 from Richard Biener ---
That said, the comment says
padding that shouldn't be clobbered. In the future we could
replace the TREE_ADDRESSABLE check with a check that
get_base_address needs t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
--- Comment #10 from CVS Commits ---
The master branch has been updated by Richard Biener :
https://gcc.gnu.org/g:a37783de23c067d6a26374ff29c014e49604035c
commit r13-7166-ga37783de23c067d6a26374ff29c014e49604035c
Author: Richard Biener
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109495
Jakub Jelinek changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109491
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #13 from rguenther at suse dot de ---
On Thu, 13 Apr 2023, chenglulu at loongson dot cn wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
>
> --- Comment #10 from chenglulu ---
> (In reply to Xi Ruoyao from comment #5)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499
--- Comment #1 from Richard Biener ---
Is there not enough info to catch this on the RTL level with a peephole?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #14 from Xi Ruoyao ---
(In reply to rguent...@suse.de from comment #13)
> On Thu, 13 Apr 2023, chenglulu at loongson dot cn wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
> >
> > --- Comment #10 from chenglulu --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #14 from rguenther at suse dot de ---
On Thu, 13 Apr 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
>
> --- Comment #13 from Jakub Jelinek ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
--- Comment #15 from rguenther at suse dot de ---
On Thu, 13 Apr 2023, xry111 at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108357
>
> --- Comment #14 from Xi Ruoyao ---
> (In reply to rguent...@suse.de from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499
--- Comment #2 from rsandifo at gcc dot gnu.org
---
(In reply to Richard Biener from comment #1)
> Is there not enough info to catch this on the RTL level with a peephole?
That works for simple cases like the first loop. But in general, I thin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
Jakub Jelinek changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499
--- Comment #3 from rguenther at suse dot de ---
On Thu, 13 Apr 2023, rsandifo at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499
>
> --- Comment #2 from rsandifo at gcc dot gnu.org
> ---
> (In reply to Richard B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
Bug ID: 109500
Summary: SIGABRT when calling a function that returns an
unallocated value
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
--- Comment #16 from rguenther at suse dot de ---
On Thu, 13 Apr 2023, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109443
>
> Jakub Jelinek changed:
>
>What|Removed |Adde
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
Bug ID: 109501
Summary: vec_test_data_class defines missing
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
Chip Kerchner changed:
What|Removed |Added
CC||chip.kerchner at ibm dot com
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
--- Comment #2 from Chip Kerchner ---
'__VEC_CLASS_FP_NAN' was not declared in this scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
Andrew Pinski changed:
What|Removed |Added
Component|c++ |target
--- Comment #3 from Andrew Pinsk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
--- Comment #4 from Chip Kerchner ---
PowerPC LE - P9.
Yes, other PVIPR APIs are available and compile in more source code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
--- Comment #5 from Chip Kerchner ---
Here's a testcase
```
#include
#include
int main()
{
__vector float p4f = { float(0), float(1), float(2), float(3) };
__vector __bool int nan_selector = vec_test_data_class(p4f,
__VEC_CLASS_FP_NAN);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109499
--- Comment #4 from rsandifo at gcc dot gnu.org
---
(In reply to rguent...@suse.de from comment #3)
> AVX512 masking allows merge and zero modes, zero being cheaper
> (obviously). I think "zero" is what all targets support so we could
> defin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
--- Comment #7 from Segher Boessenkool ---
"For clarity of code, the following named constants are suggested. Preferably,
compilers will provide these constants in a header file, but this is not
required
for compliance."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-04-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
--- Comment #8 from Chip Kerchner ---
Well, then I'm asking GCC to add these to make it easier to use
`vec_test_data_class`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56528
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109500
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=109476
--- Comment #12 from Segher Boessenkool ---
With the modified compiler? Does it ICE with an unmodified compiler as well?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494
--- Comment #2 from Oliver Rosten ---
Created attachment 54851
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54851&action=edit
Preprocessed file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109494
--- Comment #3 from Oliver Rosten ---
Created attachment 54852
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54852&action=edit
Preprocessed file for Test.cpp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109277
Jason Merrill changed:
What|Removed |Added
Last reconfirmed|2023-03-24 00:00:00 |2023-04-13
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100836
Jan-Benedict Glaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100268
Jan-Benedict Glaw changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
--- Comment #14 from CVS Commits ---
The trunk branch has been updated by Richard Sandiford :
https://gcc.gnu.org/g:66946624b96b762985de56444d726a0ebd4e0df5
commit r13-7167-g66946624b96b762985de56444d726a0ebd4e0df5
Author: Richard Sandiford
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108910
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Summary|[12/13 Regression] Further |[12 Regression] Further IC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109496
--- Comment #1 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:a1afdc6e2aa77d0a990e1a82aceeffc837b7e50c
commit r13-7168-ga1afdc6e2aa77d0a990e1a82aceeffc837b7e50c
Author: Gaius Mulley
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109497
--- Comment #1 from CVS Commits ---
The master branch has been updated by Gaius Mulley :
https://gcc.gnu.org/g:a1afdc6e2aa77d0a990e1a82aceeffc837b7e50c
commit r13-7168-ga1afdc6e2aa77d0a990e1a82aceeffc837b7e50c
Author: Gaius Mulley
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109496
Gaius Mulley changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109497
Gaius Mulley changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
y-trunk-r13-7165-20230413001648-g66c7257b675-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.1 20230413 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109501
Segher Boessenkool changed:
What|Removed |Added
Last reconfirmed||2023-04-13
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183
Allan W. Macdonald changed:
What|Removed |Added
CC||allan.w.macdonald at gmail dot
com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183
--- Comment #6 from Allan W. Macdonald ---
(In reply to Allan W. Macdonald from comment #5)
> Here is a workaround:
or just
gcc -E -MMD test.c > /dev/null
if gcc-11 is default gcc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183
--- Comment #7 from Andrew Pinski ---
Does using -c instead help?
1 - 100 of 163 matches
Mail list logo
