https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99334
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99326
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99325
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99324
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2021-03-02
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99323
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99318
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |10.3
Keywords|
cpp with preprocessed source to trigger bug.
version: gcc version 11.0.1 20210301 (experimental)
target: x86_64-pc-linux-gnu
build options: -disable-multilib --enable-languages=c,c++,fortran,lto,objc
--no-create --no-recursion
g++ produces an internal compiler error when combining an unordered_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99317
--- Comment #3 from Andrew Pinski ---
Right.
basically what I am saying is:
x ? void* : char*
implies an implict conversion of the second operand to void*.
Without the cast, there is no implict conversion in standard C, that is what
the warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99038
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99317
--- Comment #2 from Piotr ---
@(In reply to Andrew Pinski from comment #1)
> I dont think this is exactly a bug. The warning is a pedantic warning and
> with void*, things are implicitly converted by standard c rules.
With not `void *` it is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99095
Eric Botcazou changed:
What|Removed |Added
Target Milestone|--- |10.3
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020
Eric Botcazou changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020
--- Comment #3 from CVS Commits ---
The master branch has been updated by Eric Botcazou :
https://gcc.gnu.org/g:3104dbdcf4a2b7766b5570a0fa2d30157082f04e
commit r11-7444-g3104dbdcf4a2b7766b5570a0fa2d30157082f04e
Author: Eric Botcazou
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020
Eric Botcazou changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99334
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
--- Comment #28 from anlauf at gcc dot gnu.org ---
Patch for accepts-invalid / ice-on-invalid-code (parameter + data) part:
https://gcc.gnu.org/pipermail/fortran/2021-March/055768.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99335
Bug ID: 99335
Summary: Comma Operator Evaluation Order - C++ 11 and newer
Product: gcc
Version: 6.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98860
--- Comment #38 from Mikael Pettersson ---
After updating binutils to ba6eb62ff0ea9843a018cfd7cd06777bd66ae0a0, including
the fix for BZ 27268, I was able to do a full bootstrap of current gcc head on
Cygwin64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99334
Bug ID: 99334
Summary: Generated DWARF unwind table issue while on
instructions where rbp is pointing to callers stack
frame
Product: gcc
Version: 6.2.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99333
Bug ID: 99333
Summary: std::filesystem::path().is_absolute() thinks UNC paths
aren't absolute
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98432
--- Comment #6 from Iain Sandoe ---
(In reply to Tomáš Hering from comment #5)
> Created attachment 50278 [details]
> unprocessed original source
>
> Oops, seems I uploaded a slightly different code. I apologize. It's strange
> you can't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99276
Martin Sebor changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99276
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99332
Bug ID: 99332
Summary: ICE:inreset_sched_cycles_in_current_ebb, at
sel-sched.c:7147 with -fprofile-generate -O3
-fselective-scheduling -fselective-scheduling2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097
--- Comment #18 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:491d5b3cf8216f9285a67aa213b9a66b0035137b
commit r11-7443-g491d5b3cf8216f9285a67aa213b9a66b0035137b
Author: Iain Sandoe
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44107
--- Comment #34 from CVS Commits ---
The master branch has been updated by Iain D Sandoe :
https://gcc.gnu.org/g:491d5b3cf8216f9285a67aa213b9a66b0035137b
commit r11-7443-g491d5b3cf8216f9285a67aa213b9a66b0035137b
Author: Iain Sandoe
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99322
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |11.0
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321
--- Comment #2 from Jakub Jelinek ---
I'm afraid we have multiple problems with -mavx512vl -mno-avx512bw (are there
any CPUs with that combination of ISA sets though?).
In r7-618-g9bdf001b7a2232753e4a92582218bb4f24c8d809 I've fixed the 16-byte
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331
--- Comment #3 from Nikita Kniazev ---
This one most likely has the same root problem:
template struct X {};
template
struct foo { using t = X; };
:3:26: error: conversion from 'long unsigned int' to 'int' may change
value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
--- Comment #9 from Segher Boessenkool ---
The i386 port has
===
(define_insn "trap"
[(trap_if (const_int 1) (const_int 6))]
""
{
#ifdef HAVE_AS_IX86_UD2
return "ud2";
#else
return ASM_SHORT "0x0b0f";
#endif
}
[(set_attr "length"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
Ever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99331
Bug ID: 99331
Summary: -Wconversion false-positive in immidiate context
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95757
--- Comment #9 from Jakub Jelinek ---
Created attachment 50279
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50279=edit
gcc11-pr95757.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127
--- Comment #9 from Vladimir Fuka ---
I see now, it was fixed on the 8 branch, but not on the trunk! It ought to be
applied at least to the 12.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
--- Comment #8 from Franz Sirl ---
(In reply to Segher Boessenkool from comment #7)
> (In reply to Franz Sirl from comment #5)
> > For the naming I suggest __builtin_debugtrap() to align with clang. Maybe
> > with an aliased __debugbreak() on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99295
Martin Sebor changed:
What|Removed |Added
Known to fail||10.2.1, 9.3.0
Summary|[11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99271
Richard Earnshaw changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98432
Tomáš Hering changed:
What|Removed |Added
Attachment #50276|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99271
--- Comment #3 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Earnshaw
:
https://gcc.gnu.org/g:1b3bb23a576e6a864f540e3bea5097f47fea507c
commit r10-9398-g1b3bb23a576e6a864f540e3bea5097f47fea507c
Author: Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327
Jonathan Wakely changed:
What|Removed |Added
Keywords||build
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99330
Bug ID: 99330
Summary: module ICE with -std=c++2b
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99329
Bug ID: 99329
Summary: [OpenMP] device_type(nohost) & host code diagnostic
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: accepts-invalid, openmp
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99317
--- Comment #1 from Andrew Pinski ---
I dont think this is exactly a bug. The warning is a pedantic warning and with
void*, things are implicitly converted by standard c rules.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99328
Bug ID: 99328
Summary: ICE: in verify_target_availability, at
sel-sched.c:1557 with -fselective-scheduling2 on
aarch64
Product: gcc
Version: 11.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327
--- Comment #1 from cqwrteur ---
Created attachment 50277
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50277=edit
DJGPP's original errno
This is djgpp crt's original errno.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99327
Bug ID: 99327
Summary: ENOTSUP macro does not exist on djgpp crt
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99326
Bug ID: 99326
Summary: [9/10/11 Regression] ICE in
gfc_build_dummy_array_decl, at
fortran/trans-decl.c:1299
Product: gcc
Version: 11.0
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99325
Bug ID: 99325
Summary: [11 Regression] ICE in maybe_print_line_1, at
c-family/c-ppoutput.c:454
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127
Vladimir Fuka changed:
What|Removed |Added
CC||vladimir.fuka at gmail dot com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99143
Richard Earnshaw changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99324
Bug ID: 99324
Summary: ICE in mark_addressable, at gimple-expr.c:918
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99321
Martin Liška changed:
What|Removed |Added
Target Milestone|--- |11.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99323
Bug ID: 99323
Summary: [9/10/11 Regression] ICE in add_hint, at
diagnostic-show-locus.c:2234
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99322
Bug ID: 99322
Summary: [11 Regression] ICE in change_scope, at final.c:1480
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98432
--- Comment #4 from Iain Sandoe ---
(In reply to Tomáš Hering from comment #3)
> Created attachment 50276 [details]
> unprocessed source
thanks!
but ... (on x86_64-linux-gnu and x86_64-darwin16):
$ gcc-10-2/bin/g++ -std=c++20 -fcoroutines
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
--- Comment #7 from Segher Boessenkool ---
(In reply to Franz Sirl from comment #5)
> For the naming I suggest __builtin_debugtrap() to align with clang. Maybe
> with an aliased __debugbreak() on Windows platforms.
Those are terrible names.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99299
--- Comment #6 from Segher Boessenkool ---
(In reply to Richard Biener from comment #4)
> I'm not sure what your proposed not noreturn trap() would do in terms of
> IL semantics compared to a not specially annotated general call?
Nothing I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99306
--- Comment #3 from Jonathan Wakely ---
It's intended to be the cacheline size, so would use
std::hardware_destructive_interference_size, but that's not implemented yet for
the reasons given in PR 88466. And also because it's just a very verbose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98432
Tomáš Hering changed:
What|Removed |Added
Attachment #49839|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99320
--- Comment #3 from Jakub Jelinek ---
constexpr doesn't imply anything like that.
constexpr variables can still be odr-used, their address taken, compared etc.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99320
--- Comment #2 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
You are right, it seems to be the same issue except that my function is
constexpr, and I can't use `static constexpr ...` within the function, but
Barry mentioned that use case
ux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r11-7439-20210301075850-g074226d5aa8-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.1 20210301 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99320
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2021-03-01
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99320
Bug ID: 99320
Summary: constexpr defined arrays within constexpr functions
would benefit from lookup-tables
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319
--- Comment #2 from Tom de Vries ---
(In reply to Tom de Vries from comment #0)
> The second operand is now also a .uleb128. AFAIU, this goes against the
> spec.
Also, gdb doesn't get it:
...
$ gdb -q -batch -readnow a.out
DW_FORM_strp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319
--- Comment #1 from Tom de Vries ---
Related readelf PR: https://sourceware.org/bugzilla/show_bug.cgi?id=27387
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99319
Bug ID: 99319
Summary: DW_MACRO_define_strp uses uleb128 for second operand
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99318
Bug ID: 99318
Summary: [10/11 Regression] -Wdeprecated-declarations where
non-should be?
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95757
Jakub Jelinek changed:
What|Removed |Added
CC||aldyh at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99314
--- Comment #1 from Kito Cheng ---
I didn't see this testcase failed before, and I can't reproduce that on my work
environment, do you mind share your build environment, e.g. the version of gcc
or the distribution version?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313
Martin Liška changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313
--- Comment #5 from CVS Commits ---
The master branch has been updated by Martin Liska :
https://gcc.gnu.org/g:4ed0a92f6cfc647e2ad8ceaa1e5709545c915465
commit r11-7442-g4ed0a92f6cfc647e2ad8ceaa1e5709545c915465
Author: Martin Liska
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99020
Eric Botcazou changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99317
Bug ID: 99317
Summary: Missed warning
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313
--- Comment #4 from Martin Liška ---
(In reply to Richard Biener from comment #3)
> But this results in unexpected behavior when there's functions with arch=z13
> vs. arch=z9 and depending on "luck" we then inherit the wrong params where
> we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313
--- Comment #3 from Richard Biener ---
But this results in unexpected behavior when there's functions with arch=z13
vs. arch=z9 and depending on "luck" we then inherit the wrong params where
we should not?
That said, when unifying
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99294
Nathan Sidwell changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99294
--- Comment #1 from CVS Commits ---
The master branch has been updated by Nathan Sidwell :
https://gcc.gnu.org/g:2e0bb9eec2d455840bc4773391b3313a320b3c23
commit r11-7441-g2e0bb9eec2d455840bc4773391b3313a320b3c23
Author: Nathan Sidwell
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338
Jan Hubicka changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338
--- Comment #24 from CVS Commits ---
The master branch has been updated by Jan Hubicka :
https://gcc.gnu.org/g:150bde36c119eff4b8a74667c9d728d6a8a5e8a1
commit r11-7440-g150bde36c119eff4b8a74667c9d728d6a8a5e8a1
Author: Jan Hubicka
Date: Mon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
--- Comment #8 from Sebastian Huber ---
(In reply to Eric Botcazou from comment #7)
> > I still think that the profiling counter increment in the
> > __builtin_unreachable() path is a bug.
>
> How so? I only see a missed optimization, but with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
--- Comment #7 from Eric Botcazou ---
> This nop behaviour could be a bit inconsistent across architectures. For
> example, arm and powerpc don't generate a nop here.
Well, it's low-level trickery so architecture-dependent by definition.
> I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99230
--- Comment #4 from Jakub Jelinek ---
I can actually reproduce e.g. on x86_64-linux with:
extern void fn2(void);
extern void fn3(int);
int a, b;
void fn1() {
int c;
short d;
switch (a) {
case 22000:
fn2();
case 22300:
b = 0;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
--- Comment #6 from Sebastian Huber ---
(In reply to Eric Botcazou from comment #5)
> static void
> sparc_asm_function_epilogue (FILE *file)
> {
> /* If the last two instructions of a function are "call foo; dslot;"
> the return address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98338
--- Comment #23 from Jakub Jelinek ---
The make check results also looked ok on all 3 arches.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99291
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99230
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99234
--- Comment #23 from Vadim Zeitlin ---
(In reply to Eric Botcazou from comment #22)
> Thanks for reporting the problem.
Thanks a lot for fixing it so quickly!
And I've also appreciated the explanation in the commit message, it's nice to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99308
Tobias Burnus changed:
What|Removed |Added
Keywords||missed-optimization
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99151
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99307
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96357
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
CC||andrew.goodbody at linaro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99316
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99316
--- Comment #1 from andrew.goodbody at linaro dot org ---
Command line used was this
/usr/local/bin/gcc-U_FORTIFY_SOURCE -Wall
-Wunused-but-set-parameter -Wno-free-nonheap-object
-fno-omit-frame-pointer -g0 -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99316
Bug ID: 99316
Summary: ICE: in final_scan_insn_1, at final.c:3073 (error:
could not split insn)
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313
Martin Liška changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot
gnu.org
1 - 100 of 121 matches
Mail list logo
