https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384
Bug ID: 91384
Summary: Compare with negation is not eliminated
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53796
--- Comment #23 from Janne Blomqvist ---
Author: jb
Date: Wed Aug 7 07:34:10 2019
New Revision: 274160
URL: https://gcc.gnu.org/viewcvs?rev=274160&root=gcc&view=rev
Log:
PR 53796 Make inquire(file=, recl=) conform to F2018
In my original patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91358
Richard Biener changed:
What|Removed |Added
Keywords|wrong-code |
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91374
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Version|tree-ssa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91375
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
--- Comment #1 from Richard Biener ---
Possibly related to the .gnu_lto emission changes?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91334
Martin Liška changed:
What|Removed |Added
Status|REOPENED|WAITING
--- Comment #8 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
--- Comment #2 from Martin Liška ---
(In reply to Richard Biener from comment #1)
> Possibly related to the .gnu_lto emission changes?
Well, my changes are not part of any binutils release yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91377
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91260
Jonathan Wakely changed:
What|Removed |Added
CC||ufospoke at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91378
Richard Biener changed:
What|Removed |Added
Priority|P3 |P2
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91383
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91383
--- Comment #4 from Jonathan Wakely ---
Specifically, note that Annex D says code MAY fail to compile. It is not
required to fail to compile.
Some users want the features to remain, and it hurts them if the features are
removed. It hurts nobody
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Target Milest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384
--- Comment #2 from Richard Biener ---
Hmpf. So the following was not optimized ever:
void foo (void);
void bar (void);
int
test (int a)
{
int r = -a;
if (a == 0)
foo ();
else
bar ();
return r;
}
Note this is also about cano
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91358
--- Comment #5 from Marc Glisse ---
(In reply to Richard Biener from comment #4)
> I guess valgrind could be improved to check
> only at uses of the uninit value?
It is used. In the easy case it would be used in "undef & 0", so the result
does n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91382
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91383
--- Comment #5 from Frédéric Bron ---
OK, thanks. I agree it dos not real harm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #2 from Martin Liška ---
> (In reply to Richard Biener from comment #1)
>> Possibly related to the .gnu_lto emission changes?
>
> Well, my changes are not part of any binut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91382
--- Comment #2 from Marc Glisse ---
(In reply to Jakub Jelinek from comment #1)
> Aren't unknown attributes supposed to be ignored?
Bug 86368 is related to that point.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91382
--- Comment #3 from Jonathan Wakely ---
Yes, this seems like a case that should be ignored. We have
-Wunknown-attributes that *doesn't* ignore them, but the main use of that is to
catch typos in the attribute name, or warn about unsupported attri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91384
--- Comment #3 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #1)
> Started with r223689. Though, generally that change looks like a useful
> GIMPLE canonicalization.
FYI, -fno-tree-forwprop generates expected code.
> Can't this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91377
--- Comment #2 from Jeffrey Kelling ---
Created attachment 46680
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46680&action=edit
gcc 7.3.0 preprocessed source
Not sure if it helps, but here is the code preprocessed by gcc 7.3.0.
This com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Martin Liška ---
[...]
> Sorry for not getting that. Well, then please try revision before
> cc5277b173701364c10204f316db28198f2c683b
That one is fine: the testcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91375
--- Comment #2 from Richard Biener ---
TYPE_BINFO (DECL_CONTEXT (vtable)) is NULL. DECL_CONTEXT is BDS_Mesh here,
from the -O0 compile where it is cleared here:
static void
free_lang_data_in_type (tree type, class free_lang_data_d *fld)
{
...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91374
--- Comment #2 from Hao Liu ---
(In reply to Richard Biener from comment #1)
> So you ask for main to be converted to
>
> if (idx == 0)
>foo_32_16 ();
> else /* idx == 1 */
>foo_16_8 ();
>
> correct? It shoulds like an interesting id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
Martin Liška changed:
What|Removed |Added
Status|WAITING |ASSIGNED
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91359
--- Comment #12 from Brian T. Carcich ---
Steve,
I ran GCC SVN repo rev 274151 against part of our SFTRAN3-generated codebase,
and they now pass the unit tests.
This work will be used to update the MIRAGE suite of software for
high-precision tr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|WAITING
--- Comment #7 from Martin Liška
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91375
--- Comment #3 from Martin Liška ---
>
> so I guess that flag_devirtualize is to blame since it may differ between
> CUs and type merging may chose the instance from a !flag_devirtualize one.
> A fix could be as simple as removing the !flag_dev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91359
--- Comment #13 from Brian T. Carcich ---
Whoops, I meant rev 274149.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91385
Bug ID: 91385
Summary: Zero-extended negation (*negsi2_1_zext) is not
generated
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91385
Uroš Bizjak changed:
What|Removed |Added
Target||x86_64
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
Bug ID: 91386
Summary: open-iscsi iscsiadm miscompiled by LTO on aarch64
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #1 from Andreas Schwab ---
Created attachment 46681
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46681&action=edit
Preprocessed sources with Makefile, part 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #2 from Andreas Schwab ---
Created attachment 46682
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46682&action=edit
Preprocessed sources with Makefile, part 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #3 from Andreas Schwab ---
Created attachment 46683
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46683&action=edit
Preprocessed sources with Makefile, part 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #4 from Richard Earnshaw ---
R8 is the register used for the address of the return value location when the
result cannot be stored in registers. Are you sure that this isn't a problem
in the caller?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #5 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #4)
> R8 is the register used for the address of the return value location when
> the result cannot be stored in registers. Are you sure that this isn't a
> prob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86675
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
Richard Earnshaw changed:
What|Removed |Added
Component|target |driver
--- Comment #33 from Richard E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #6 from Richard Biener ---
So I can't reproduce with a cross easily (w/o a libc I can only
do a partial link). Nevertheless I see some
58: 910e63e6add x6, sp, #0x398
...
90: a90008c2stp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #7 from Martin Liška ---
I'm reducing the LTO files that are needed to expose the problem..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #8 from Richard Biener ---
So if one can reproduce a way for a smaller testcase (likely only for trunk
then) is to -fdump-tree-optimized-gimple and make a GIMPLE FE testcase from
main()
(adding relevant typedefs from the preprocessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86675
--- Comment #3 from Jonathan Wakely ---
cat >86675.cc /dev/null | grep return
The first GDB session breaks at:
3 return 31415;
The second at:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #34 from Richard Biener ---
So like the following then.
Index: gcc/lto-wrapper.c
===
--- gcc/lto-wrapper.c (revision 274111)
+++ gcc/lto-wrapper.c (working copy)
@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91382
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #35 from Jakub Jelinek ---
Yeah, plus removing " according to LANG_MASK" from
get_options_from_collect_gcc_options function comment. But Martin claims it
doesn't work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #36 from Martin Liška ---
(In reply to Jakub Jelinek from comment #35)
> Yeah, plus removing " according to LANG_MASK" from
> get_options_from_collect_gcc_options function comment. But Martin claims it
> doesn't work.
Yes, I needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #37 from Jakub Jelinek ---
(In reply to Martin Liška from comment #36)
> (In reply to Jakub Jelinek from comment #35)
> > Yeah, plus removing " according to LANG_MASK" from
> > get_options_from_collect_gcc_options function comment. B
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #38 from Martin Liška ---
(In reply to Jakub Jelinek from comment #37)
> (In reply to Martin Liška from comment #36)
> > (In reply to Jakub Jelinek from comment #35)
> > > Yeah, plus removing " according to LANG_MASK" from
> > > get_o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #10 from Martin Liška ---
I'm attaching all tree and rtl dumps for the problematic LTRANS unit:
https://drive.google.com/file/d/1CW4cWvpm1VVXFIP80XCf1IzYXWwTsynZ/view?usp=sharing
I can confirm what Andreas sees:
(note 8303 8031 7890
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90796
--- Comment #11 from Michael Matz ---
(In reply to rguent...@suse.de from comment #10)
> >It's the only affine functions that don't progress with each iteration.
> > I
> >think, at least :)
>
> Hm. At least we analyze wrapping ones, but I guess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #11 from Martin Liška ---
And I can also verify that adding -fno-peephole -fno-peephole2 to CFLAGS helps
to resolve the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91387
Bug ID: 91387
Summary: Segfault using -flto
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91379
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91388
Bug ID: 91388
Summary: -Wreturn-type "no return statement" warning in
function that is already ill-formed
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Keywor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91387
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91375
Martin Liška changed:
What|Removed |Added
CC||gcc-bugzilla at tobias dot
goedder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91387
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #12 from Wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #13 from Martin Liška ---
>
> The key question is how does one dump rtl with -flto? It doesn't work at
> all, making debugging this difficult...
It does, look:
marxin@marxinbox:/tmp> gcc -c main.c -flto
marxin@marxinbox:/tmp> gcc m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #14 from Wilco ---
(In reply to Martin Liška from comment #13)
> >
> > The key question is how does one dump rtl with -flto? It doesn't work at
> > all, making debugging this difficult...
>
> It does, look:
>
> marxin@marxinbox:/tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #39 from Martin Liška ---
(In reply to Richard Biener from comment #34)
> So like the following then.
>
> Index: gcc/lto-wrapper.c
> ===
> --- gcc/lto-wrapper.c (revis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91109
--- Comment #9 from Bernd Edlinger ---
Author: edlinger
Date: Wed Aug 7 13:45:06 2019
New Revision: 274163
URL: https://gcc.gnu.org/viewcvs?rev=274163&root=gcc&view=rev
Log:
2019-08-07 Bernd Edlinger
PR tree-optimization/91109
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91389
Bug ID: 91389
Summary: [7/8/9/10 Regression] error: control reaches end of
non-void function with -fsanitize=thread since r219201
Product: gcc
Version: unknown
Status: UN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91390
Bug ID: 91390
Summary: treatment of extra parameter in a subroutine call
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91332
--- Comment #2 from Madarpok . ---
I can confirm that raising the stack limit with ulimit -s unlimited does not
prevent this crash.
Something inside gfortran is breaking/overflowing.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91389
--- Comment #1 from Jakub Jelinek ---
Don't do it then? The no fallthru early discovery isn't perfect and with the
sanitizer instrumentation it gets even harder.
Looks like a dup of PR86899 to me anyway.
If I do a small modification like:
class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79618
--- Comment #9 from Martin Sebor ---
It doesn't. -Wformat-diag runs after adjacent string literals have been
concatenated. Detecting these kinds of issues would mean enhancing the
preprocessor.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91346
--- Comment #1 from Marek Polacek ---
Author: mpolacek
Date: Wed Aug 7 14:20:40 2019
New Revision: 274169
URL: https://gcc.gnu.org/viewcvs?rev=274169&root=gcc&view=rev
Log:
PR c++/91346 - Implement P1668R1, allow unevaluated asm in cons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91346
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #17 from Martin Sebor ---
Just to be clear: my suggestion to fold the relational expressions is only for
incoming pointers with addresses of local variables that GCC already assumes
cannot be synthesized (I assume it does that on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #15 from Richard Earnshaw ---
From looking at the dumps it would appear that one of the STP generating
peepholes might have bailed out, but that some of the changes have not been
undone.
From the pass before, we have:
(insn/f:TI 802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91391
Bug ID: 91391
Summary: Bogus -Wcomma-subscript
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: un
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91391
Marek Polacek changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91379
--- Comment #2 from Clinton Bunch ---
As I stated, I've tried to compile 4.9.4, 5.3.0, 5.5.0, 6.1.0, 6.5.0 and 8.3.0
I get the same error on all of them. I reported on 9.1.0 as it is the current
version. I can't get a gcc more recent than 4.9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91388
Eric Gallager changed:
What|Removed |Added
CC||egallager at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91380
--- Comment #3 from Barry Revzin ---
In case it's at all helpful, here's the clang review that Tim found for this
diagnostic: https://reviews.llvm.org/D51333
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91334
--- Comment #9 from H.J. Lu ---
[hjl@gnu-mic-1 build_base_lto.]$
/export/gnu/import/git/gcc-test-spec-lto/usr/bin/g++ -S -DSPEC_CPU -DNDEBUG
-DAPP_NO_THREADS -DXALAN_INMEM_MSG_LOADER -I. -Ixercesc -Ixercesc/dom
-Ixercesc/dom/impl -Ixercesc/s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91391
--- Comment #2 from Marek Polacek ---
...except when it's:
void
fn (int *a, int b, int c)
{
a[b < c, b > c]; // should warn
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91285
--- Comment #4 from joseph at codesourcery dot com ---
Note that all the standard C pragmas are even more restricted than GCC's
statement-like pragmas - the standard pragmas (which aren't implemented in
GCC) are defined by the C standard to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
Richard Earnshaw changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91392
Bug ID: 91392
Summary: g++: internal compiler error: Aborted (program
cc1plus)
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #17 from Richard Earnshaw ---
Created attachment 46686
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46686&action=edit
candidate patch
Could you try this patch please? So far only very lightly tested.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88771
Eric Gallager changed:
What|Removed |Added
Target Milestone|9.2 |---
--- Comment #24 from Eric Gallager
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90121
Eric Gallager changed:
What|Removed |Added
Target Milestone|9.2 |---
--- Comment #3 from Eric Gallager -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91330
--- Comment #1 from Tom Tromey ---
This is pretty easy to fix in gcc/jit/docs/conf.py:
diff --git a/gcc/jit/docs/conf.py b/gcc/jit/docs/conf.py
index 3e630db47ef..1224bdcc07d 100644
--- a/gcc/jit/docs/conf.py
+++ b/gcc/jit/docs/conf.py
@@ -244,7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91154
Segher Boessenkool changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
--- Comment #40 from Richard Earnshaw ---
Author: rearnsha
Date: Wed Aug 7 16:15:35 2019
New Revision: 274176
URL: https://gcc.gnu.org/viewcvs?rev=274176&root=gcc&view=rev
Log:
PR driver/91130 Use CL_DRIVER when handling of COLLECT_GCC_OPTIONS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91130
Richard Earnshaw changed:
What|Removed |Added
Summary|[9/10 Regression] -MF |[9 Regression] -MF clashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91388
Jonathan Wakely changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91393
Bug ID: 91393
Summary: lto1: internal compiler error: decompressed stream:
Destination buffer is too small
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91394
Bug ID: 91394
Summary: C++ ABI incompatibility (stdexcept)
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88451
--- Comment #6 from joseph at codesourcery dot com ---
I don't think anyone has really been maintaining the fixed-point support
for a very long time.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91391
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82967
Eric Gallager changed:
What|Removed |Added
Target Milestone|9.2 |8.5
--- Comment #14 from Eric Gallager
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81419
--- Comment #4 from Eric Gallager ---
(In reply to Eric Gallager from comment #2)
> (In reply to Martin Sebor from comment #1)
> > Confirmed. There are few other similar bugs for these fix-it hints (e.g.,
> > pr80567 or pr80684). I haven't look
1 - 100 of 135 matches
Mail list logo
