https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109296
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109310
--- Comment #1 from Jakub Jelinek ---
So perhaps for GCC13 emit some kind of deprecation message for it and suggest
using --enable-link-serialization instead and delete later?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109311
Kewen Lin changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109308
--- Comment #3 from Andrew Pinski ---
This code is very much undefined.
THe original code did:
opc = XNEWVEC (struct m68hc11_opcode_def, num_opcodes);
m68hc11_opcode_defs = opc--;
Which is definitely undefined. You cannot take the address b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109311
Bug ID: 109311
Summary: [13 Regression] bb_is_just_return miss to realize some
bb from r13-6873-g776a5bb5894315
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109308
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109308
--- Comment #1 from Andrew Pinski ---
Doing:
--opc;
On an address which starts an array is undefined. Even for an a memory
allocated by malloc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108129
--- Comment #4 from Hongtao.liu ---
We may merge ATOMIC_XXX_N with SYNC_XXX_N if the "?" can be extent to optional
operand.
The only difference between them is ATOMIC_XXX_N has one more parameter, and
it's not used by the pattern match.
Curren
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109310
Bug ID: 109310
Summary: --enable-link-mutex is quite duplicate to
--enable-link-serialization
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109309
Bug ID: 109309
Summary: Untranslated text in diagnostic
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109308
Martin Liška changed:
What|Removed |Added
See Also||https://sourceware.org/bugz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109308
Bug ID: 109308
Summary: False positive store to address 0x6260016c with
insufficient space for an object of type 'int' since
r12-6030-g422f9eb7011b76c1
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109256
James Hilliard changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109274
Andrew Macleod changed:
What|Removed |Added
Attachment #54743|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
--- Comment #59 from Martin Liška ---
(In reply to Andrew Carlotti from comment #58)
> Since November 2021, there's been a significant regression in the compile
> time for gimple-match.cc during a bootstrap build (+100% in Stage 2, +73% in
> Stag
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92340
lixiaoyi13691419520 at gmail dot com changed:
What|Removed |Added
Resolution|--- |FIXED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109300
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266
--- Comment #4 from David Malcolm ---
(In reply to David Malcolm from comment #3)
> (In reply to Jonny Grant from comment #2)
[...]
> >
> > I wondered if you know how to turn on that "cc1plus: note: source object is
> > likely at address zero?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109266
--- Comment #3 from David Malcolm ---
(In reply to Jonny Grant from comment #2)
> Thank you for your reply David. Your analyzer is very good already.
>
> I played around a bit, a base of nullptr doesn't give a warning. But
> changing to 0x10 do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109247
Jakub Jelinek changed:
What|Removed |Added
CC||slyfox at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109307
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |DUPLICATE
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109307
Bug ID: 109307
Summary: [13 Regression] constructors fails typecheck on
initializer list assignment
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109299
Benjamin Buch changed:
What|Removed |Added
Version|12.0|12.1.0
--- Comment #3 from Benjamin Buc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109305
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109299
--- Comment #2 from Jonathan Wakely ---
Are you really using GCC 12.0? If not, please fix the Version field.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109300
Marek Polacek changed:
What|Removed |Added
Priority|P3 |P2
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107822
--- Comment #5 from Andrew Macleod ---
(In reply to Richard Biener from comment #4)
> I don't see us realistically fixing this for GCC 13, so postponing to GCC 14
> and downgrading from P1 to P2.
>
I am currently developing a phi analyzer for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109300
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109304
--- Comment #4 from Martin Liška ---
A bit clean-up test-case:
int PyUnicode_FindChar_i;
int PyUnicode_FindChar() {
while (PyUnicode_FindChar_i)
if (PyUnicode_FindChar())
break;
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109304
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276
--- Comment #17 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #16)
> (In reply to Uroš Bizjak from comment #15)
> > (In reply to Jakub Jelinek from comment #13)
> > > asks for a DImode stack slot, ix86_local_alignment newly doesn'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303
Martin Liška changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106282
Andreas Schwab changed:
What|Removed |Added
Known to work||13.0
--- Comment #4 from Andreas Schwa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109306
--- Comment #6 from Jakub Jelinek ---
Or we could take strstr from gnulib, which is much larger (and faster).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109306
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109306
--- Comment #4 from pmorf at apple dot com ---
Ha got it. thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109306
--- Comment #3 from Andrew Pinski ---
(In reply to pmorf from comment #2)
> Oh. Is there a different implementation I'll link against when telling gcc
> to use the c++11 standard ?
I am saying that implementation is only used if the host's libc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109306
--- Comment #2 from pmorf at apple dot com ---
Oh. Is there a different implementation I'll link against when telling gcc to
use the c++11 standard ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109291
--- Comment #3 from Andrew Pinski ---
(In reply to ncm from comment #2)
> CWG 1430 is still marked Open, and is anyway only superficially
> analogous. Here, there is no need for an alias to be encoded
> into a type signature.
Right and yes PR 5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109306
Andrew Pinski changed:
What|Removed |Added
Summary|The strstr function might |The strstr implementation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109291
--- Comment #2 from ncm at cantrip dot org ---
CWG 1430 is still marked Open, and is anyway only superficially
analogous. Here, there is no need for an alias to be encoded
into a type signature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109306
Bug ID: 109306
Summary: The strstr function might do undefined behavior (out
of bounds mem access)
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: nor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109301
--- Comment #3 from Jakub Jelinek ---
Tried -Ofast -mavx512f
#include
void
foo (double *a, double *b)
{
for (int i = 0; i < 1024; i++)
a[i] = pow (a[i], b[i]);
}
void
bar (double *a)
{
for (int i = 0; i < 1024; i++)
a[i] = cbrt (s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276
--- Comment #16 from Jakub Jelinek ---
(In reply to Uroš Bizjak from comment #15)
> (In reply to Jakub Jelinek from comment #13)
> > asks for a DImode stack slot, ix86_local_alignment newly doesn't lower the
> > alignment
> > which isn't good fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276
--- Comment #15 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #13)
> asks for a DImode stack slot, ix86_local_alignment newly doesn't lower the
> alignment
> which isn't good for -mpreferred-stack-boundary=2.
IIRC, DImode FILD/FI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109301
--- Comment #2 from Jakub Jelinek ---
Created attachment 54774
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54774&action=edit
gcc13-pr109301.patch
Actually, I think just that single case might be enough, all the others involve
cbrt or p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109305
--- Comment #2 from Andrew Pinski ---
https://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#2579
This copy only happens with _S_propagate_on_copy_assign which is true even.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109305
--- Comment #1 from Andrew Pinski ---
LWG2579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109305
Bug ID: 109305
Summary: Allocator copy in basic_string::operator=
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109301
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109304
--- Comment #2 from Sam James ---
Good: 13.0.1 20230319
Bad: 13.0.1 20230326
I'll bisect now but someone is free to beat me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109301
--- Comment #1 from Jakub Jelinek ---
Started with r13-1763-g78d5e125c008d87cb2e1.
(for sqrts (SQRT)
cbrts (CBRT)
pows (POW)
/* sqrt(sqrt(x)) -> pow(x,1/4). */
(simplify
(sqrts (sqrts @0))
(pows @0 { build_real (type, dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109304
Andrew Pinski changed:
What|Removed |Added
Keywords||ice-on-valid-code
Target Milestone|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109300
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-03-27
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109304
--- Comment #1 from Sam James ---
Created attachment 54772
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54772&action=edit
reduced.i
```
$ x86_64-pc-linux-gnu-gcc -c /tmp/reduced.i -fprofile-generate -O3
-fno-semantic-interposition -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109304
Bug ID: 109304
Summary: ICE when building Python 3.12.0_alpha6 (internal
compiler error: in get_vrange, at
value-range-storage.cc:87)
Product: gcc
Version: 13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-bisection
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109301
Andrew Pinski changed:
What|Removed |Added
Component|c |tree-optimization
Target Milestone|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106856
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106856
--- Comment #16 from CVS Commits ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:4f41c4ff250709219a7c3eba27a62f8a4689412b
commit r12-9322-g4f41c4ff250709219a7c3eba27a62f8a4689412b
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108025
--- Comment #4 from CVS Commits ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:
https://gcc.gnu.org/g:4b56945b1ae497580b542abb6d7ca41b6444c219
commit r12-9321-g4b56945b1ae497580b542abb6d7ca41b6444c219
Author: Harald Anlauf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109303
Bug ID: 109303
Summary: [13 Regression] ICE in push_agg_values_from_plats, at
ipa-cp.cc:1458
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109302
Bug ID: 109302
Summary: [12/13 Regression] ICE in emit_move_insn, at
expr.cc:4225
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109301
Bug ID: 109301
Summary: [13 Regression] ICE in format_helper, at real.h:233
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109300
Bug ID: 109300
Summary: [13 Regression] ICE in cp_finish_decl, at
cp/decl.cc:8279
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183
--- Comment #4 from Yann Droneaud ---
(In reply to Alexandre Oliva from comment #3)
> dump files now consistently take the base name from the output name, when
> not overridden
>
> since in this case gcc is called for (compiling and) linking, a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109154
--- Comment #21 from Jakub Jelinek ---
Created attachment 54770
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54770&action=edit
gcc13-pr109154.patch
So what about this then?
It matches the x86 FTZ behavior, because FTZ is a masked reacti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109293
--- Comment #6 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #5)
> Something like this:
> diff --git a/fixincludes/configure.ac b/fixincludes/configure.ac
> index 14813b910f1..00aeb1ce1d9 100644
> --- a/fixincludes/configure.ac
> ++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109293
--- Comment #5 from Andrew Pinski ---
Something like this:
diff --git a/fixincludes/configure.ac b/fixincludes/configure.ac
index 14813b910f1..00aeb1ce1d9 100644
--- a/fixincludes/configure.ac
+++ b/fixincludes/configure.ac
@@ -89,6 +89,7 @@ def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276
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=109293
--- Comment #4 from Xi Ruoyao ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Xi Ruoyao from comment #2)
> > I'll make a patch to check if memmem is declared in configure.ac. memmem is
> > not a POSIX function, so it may be undec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109293
--- Comment #3 from Andrew Pinski ---
(In reply to Xi Ruoyao from comment #2)
> I'll make a patch to check if memmem is declared in configure.ac. memmem is
> not a POSIX function, so it may be undeclared on systems other than MinGW as
> well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109293
--- Comment #2 from Xi Ruoyao ---
I'll make a patch to check if memmem is declared in configure.ac. memmem is
not a POSIX function, so it may be undeclared on systems other than MinGW as
well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109293
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
Statu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109293
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.3
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109299
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #1 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276
--- Comment #13 from Jakub Jelinek ---
Neither the new ix86_lower_local_decl_alignment function is called, nor
SET_DECL_ALIGN in pass_adjust_alignment::execute.
What happens is that
#0 ix86_local_alignment (exp=,
mode=E_DImode, align=64, may_lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109098
--- Comment #9 from David Malcolm ---
(In reply to Hans-Peter Nilsson from comment #8)
> (In reply to David Malcolm from comment #7)
> > The invalid UTF-8 in the patch seems to have broken the server-side script:
>
> Maybe the not-really-utf8 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59498
Andrew Pinski changed:
What|Removed |Added
CC||ncm at cantrip dot org
--- Comment #21 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109291
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109294
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276
--- Comment #12 from Jakub Jelinek ---
The above testcase only started ICEing with r11-2259-g0a9d711df36b42b6494b73 ,
so I think the IPA pass is innocent here.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276
--- Comment #11 from Jakub Jelinek ---
Reduced testcase:
/* PR target/109276 */
/* { dg-do compile } */
/* { dg-options "-march=x86-64" } */
/* { dg-additional-options "-mpreferred-stack-boundary=2" } */
long long a;
long double b;
void
foo (v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109299
Bug ID: 109299
Summary: wrong warning on std::wstring with -O2 -std=c++20
-D_FORTIFY_SOURCE=2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106190
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
Andrew Carlotti changed:
What|Removed |Added
CC||andrew.carlotti at arm dot com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106124
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Assignee|unassigned at gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106190
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106543
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109274
--- Comment #11 from Andrew Macleod ---
I will provide a fix today, once I look deeper and settle it. Sorry, I was
busy and incommunicado all weekend.
The real root of the problem seems to be that previously if symbolically op1 ==
op2, we were
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106608
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109159
Marek Polacek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106879
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106955
Richard Biener changed:
What|Removed |Added
Status|WAITING |NEW
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087
--- Comment #4 from Jonathan Wakely ---
Comment 0 comes from 22_locale/money_put/cons/3.cc
make check RUNTESTFLAGS="conformance.exp=22_locale/money_put/cons/3.cc
--target_board=unix/-m32"
(but I don't see it failing now).
Comment 1 comes from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106998
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107041
Richard Biener changed:
What|Removed |Added
Keywords||diagnostic
--- Comment #2 from Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109294
--- Comment #2 from Jonathan Wakely ---
(In reply to Dávid Péter Jánosa from comment #0)
> Based on the calls, the same binary will provide different results for use
> case 1 vs 3 which is a bug.
> Also, the result will be different for use case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107087
--- Comment #3 from Richard Biener ---
Created attachment 54767
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54767&action=edit
patch I am testing
I can't verify the preprocessed sources with patched trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109294
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #1 fr
1 - 100 of 170 matches
Mail list logo
