https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
--- Comment #9 from Martin Liška ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #8)
> > --- Comment #7 from Martin Liška ---
> > (In reply to Martin Liška from comment #6)
> >> Good, then let me take a look.
> >
> > So I've just tes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91377
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48595
Eric Gallager changed:
What|Removed |Added
Keywords||build
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80078
--- Comment #3 from Christopher Head ---
I tried 9.1 at gcc.godbolt.org and it looks like this is fixed. Anyone else
care to take a look? If there are no further comments, I guess I’ll close this
ticket in a few days.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
--- Comment #10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90473
Marek Polacek changed:
What|Removed |Added
Keywords||patch
--- Comment #4 from Marek Polacek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80545
Martin Sebor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82813
Bug 82813 depends on bug 80545, which changed state.
Bug 80545 Summary: option -Wstringop-overflow not recognized by Fortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80545
What|Removed |Added
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89176
H.J. Lu changed:
What|Removed |Added
CC||crazylht at gmail dot com
--- Comment #2 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90473
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90473
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91394
--- Comment #4 from Jonathan Wakely ---
Some programs which happen to not use any new features might work with an older
version of libstdc++.so but that is not guaranteed, and definitely not
supported.
Removing one or two functions from a header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91406
Bug ID: 91406
Summary: gcc -Q -v lies about what flags are enabled
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: dri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47779
Jeffrey A. Law changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91394
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91379
--- Comment #4 from Clinton Bunch ---
Setting the CFLAGS and CXXFLAGS to -O0 -g as suggested didn't help. It still
blew up at the same point building libgcc.
Interestingly, I noticed that it doesn't blow up if the code is compiled in
-mlp64 mo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91405
--- Comment #1 from Michael de Lang ---
Correction, the reported line number for 7.4.0 is cp.parser.c:38874
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91405
Bug ID: 91405
Summary: [concepts] internal compiler error: in
synthesize_implicit_template_parm, at
cp/parser.c:41206
Product: gcc
Version: 9.1.0
Stat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #19 from Martin Sebor ---
That's a valid concern. Issuing a warning (either at the same time as or in
lieu of the folding) would be a way to detect and prevent these kinds of
problems. Exposing it to enough code (like in a whole dis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91229
Jim Wilson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91229
--- Comment #3 from Jim Wilson ---
Author: wilson
Date: Thu Aug 8 19:04:56 2019
New Revision: 274215
URL: https://gcc.gnu.org/viewcvs?rev=274215&root=gcc&view=rev
Log:
RISC-V: Fix C ABI for flattened struct with 0-length bitfield.
gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91403
Serge Belyshev changed:
What|Removed |Added
CC||belyshev at depni dot
sinp.msu.ru
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91403
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91334
H.J. Lu changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91404
Bug ID: 91404
Summary: [10 Regression] internal compiler error: Segmentation
fault
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91402
--- Comment #1 from Andrew Kaster ---
As a note, I was able to reproduce using godbolt, but they don't have very
recent versions of gcc for powerpc:
https://godbolt.org/z/20lNhf
Of the available compilers:
No warnings:
power64le clang (trunk)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91403
Bug ID: 91403
Summary: GCC fails with ICE.
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91178
--- Comment #17 from Vsevolod Livinskiy ---
(In reply to Serge Belyshev from comment #16)
> (In reply to Vsevolod Livinskiy from comment #15)
> > I don't know if it is the same error or not, but the reproducer looks
> > similar.
>
> This one is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #23 from Ian Lance Taylor ---
Look for _kern in runtime.inc. See what struct it is part of. The struct is
likely defined in the generated file runtime_sysinfo.go. You may need to
modify libgo/mkrsysinfo.sh to not add that struct to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79520
Marek Polacek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79520
--- Comment #3 from Marek Polacek ---
Author: mpolacek
Date: Thu Aug 8 17:54:58 2019
New Revision: 274214
URL: https://gcc.gnu.org/viewcvs?rev=274214&root=gcc&view=rev
Log:
PR c++/79520
* g++.dg/cpp1y/constexpr-79520.C: New test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91402
Bug ID: 91402
Summary: PowerPC unecessary -Wignored-attriubte warnings on
template specialization with -mlongcall
Product: gcc
Version: 7.4.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79520
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88330
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323
Bug 88323 depends on bug 88330, which changed state.
Bug 88330 Summary: Implement P0542R5, P1289R1, C++20 contract based programming.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88330
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88102
Marek Polacek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323
Bug 88323 depends on bug 88102, which changed state.
Bug 88102 Summary: Implement P0542R5, C++20 contracts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88102
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91398
--- Comment #1 from joseph at codesourcery dot com ---
ABI question: is a function that returns a value through such a hidden
pointer required not to write anything to the storage pointed to until it
knows that it will definitely be returning n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91395
--- Comment #5 from joseph at codesourcery dot com ---
It's *accessible objects* whose value on second return from setjmp is the
same as when longjmp is called (unless non-volatile, automatic storage
duration and changed between setjmp and long
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81930
Bug 81930 depends on bug 57854, which changed state.
Bug 57854 Summary: Would like to have a warning for virtual overrides without
C++11 "override" keyword
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57854
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57854
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80061
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91227
--- Comment #18 from joseph at codesourcery dot com ---
I don't expect people to do such comparisons with addresses of local
variables directly. It is plausible that they have a memmove-like
function, and once it gets inlined the compiler can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90313
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63391
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91396
Eric Gallager changed:
What|Removed |Added
Keywords||link-failure
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91334
--- Comment #11 from H.J. Lu ---
(In reply to Martin Liška from comment #10)
> (In reply to H.J. Lu from comment #9)
> > [hjl@gnu-mic-1 build_base_lto.]$
> > /export/gnu/import/git/gcc-test-spec-lto/usr/bin/g++ -S -DSPEC_CPU -DNDEBUG
> > -DA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91401
Jakub Jelinek changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONFI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91401
Bug ID: 91401
Summary: schedule + dist_schedule clauses rejected on
distribute parallel for
Product: gcc
Version: 9.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87519
--- Comment #12 from Marek Polacek ---
Fixed on trunk, will backport to 9.3 later.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87519
--- Comment #11 from Marek Polacek ---
Author: mpolacek
Date: Thu Aug 8 15:37:46 2019
New Revision: 274211
URL: https://gcc.gnu.org/viewcvs?rev=274211&root=gcc&view=rev
Log:
PR c++/87519 - bogus warning with -Wsign-conversion.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91400
Bug ID: 91400
Summary: __builtin_cpu_supports conjunction is optimized poorly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91399
Bug ID: 91399
Summary: parse_mtune_ctrl_str shouldn't use
ix86_tune_ctrl_string
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priori
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87519
Marek Polacek changed:
What|Removed |Added
Keywords||patch
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91376
--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Martin Liška ---
> (In reply to Martin Liška from comment #6)
>> Good, then let me take a look.
>
> So I've just tested current master of binutils and I can see:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91398
Bug ID: 91398
Summary: Possible missed optimization: Can a pointer be passed
as hidden pointer in x86-64 System V ABI
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #9 from Steinar H. Gunderson ---
Putting this at the start of mem_strdupl() suppresses the warning:
if (len + 1 == 0) __builtin_unreachable();
This seemingly also does:
if (static_cast(len) < 0) __builtin_unreachable();
So som
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #8 from Steinar H. Gunderson ---
But all of those conditions include last_slash > path.
I tried adding this just before the mem_strdupl() call:
if (last_slash < path) {
ib::fatal() << "Logic error.";
__builtin_unreachable(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91358
--- Comment #7 from Michael Matz ---
(In reply to Antony Polukhin from comment #6)
> (In reply to Michael Matz from comment #3)
> > I don't really see any, no good idea here :-/
>
> How about moving all the optimizations based on reading uniniti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #7 from Marc Glisse ---
(In reply to Steinar H. Gunderson from comment #6)
> So basically GCC is worried that I might be calling allocate() with -1
> bytes, and gives a warning?
Yes, although it might not always give the warning, dep
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91178
--- Comment #16 from Serge Belyshev ---
(In reply to Vsevolod Livinskiy from comment #15)
> I don't know if it is the same error or not, but the reproducer looks
> similar.
This one is different. It does not fail for me with -O3 -march=skylake-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91358
--- Comment #6 from Antony Polukhin ---
(In reply to Michael Matz from comment #3)
> I don't really see any, no good idea here :-/
How about moving all the optimizations based on reading uninitialized values
under a flag like -funinitialized-log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91396
niva at niisi dot msk.ru changed:
What|Removed |Added
Version|unknown |7.4.0
--- Comment #1 from niva
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #6 from Steinar H. Gunderson ---
So basically GCC is worried that I might be calling allocate() with -1 bytes,
and gives a warning?
last_slash presumably has to be >= path, given that it comes out of strrchr().
But maybe GCC won't kn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91052
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #5 from Marc Glisse ---
mem_strdupl calls allocate(len+1). If len+1 is 0, you proceed to write to
s[len] i.e. 0[-1]. I think gcc would be happier if you handled this special
case explicitly (you could error, trap, just assume it canno
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91306
--- Comment #4 from Jozef Lawrynowicz ---
Should I submit a patch which changes uses of sizeof in alignment attributes to
__alignof__? Or are you working on it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90313
Martin Liška changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #4 from Marc Glisse ---
I guess it happens in some dead path that gcc doesn't know is dead. At some
point, you look at last_slash-path+1. Here there is a branch on whether this
number is 0, and if it is 0, nonsense happens (writing 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #3 from Steinar H. Gunderson ---
Yes, the reduced one is awkward. Thus the unreduced one :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #2 from Marc Glisse ---
if (g == 0) return (char *)malloc(0);
for (;;)
;
so the only way this can return is if g is 0. This means that in j, k is -1,
and you are calling memcpy with a huge argu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90415
--- Comment #8 from Jonathan Wakely ---
(In reply to Lei YU from comment #6)
> @Jonathan Wakely Is there a quick fix for this? I would like to test it.
If I had a fix I would have committed it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
--- Comment #1 from Steinar H. Gunderson ---
Created attachment 46689
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46689&action=edit
Unreduced test case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91397
Bug ID: 91397
Summary: -Wstringop-overflow specified bound
18446744073709551615 exceeds maximum object size
9223372036854775807
Product: gcc
Version: 9.1.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91396
Bug ID: 91396
Summary: Link error when I use -fvtable-verify=std and -static
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91392
--- Comment #3 from Martin Liška ---
I would try any of these:
https://mingw-w64.org/doku.php/download
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #37 from rguenther at suse dot de ---
On August 8, 2019 3:35:26 AM GMT+02:00, "luoxhu at cn dot ibm.com"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>
>--- Comment #34 from Xiong Hu XS Luo ---
>(In reply to rguent...@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
--- Comment #36 from rguenther at suse dot de ---
On August 8, 2019 10:27:38 AM GMT+02:00, "rsandifo at gcc dot gnu.org"
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
>
>rsandifo at gcc dot gnu.org changed:
>
> What|R
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91392
--- Comment #2 from Harry Onslow ---
Hi Martin,
Thanks for the message. I will try a newer version - Could you please advise on
where I can download the latest release please?
Regards,
Harry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
Martin Liška changed:
What|Removed |Added
Known to fail||10.0, 9.1.0
--- Comment #19 from Martin L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91395
--- Comment #4 from Adam ---
(In reply to Andrew Pinski from comment #3)
> In theory other can cause a call to longjmp but gcc does not know it cannot.
Thanks for the quick reply.
I got the longjmp() part, it could be called anytime. The part I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91352
Martin Liška changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66087
--- Comment #4 from Mikael Pettersson ---
Still miscompiled by gcc-10.0, 9.1, and 8.3 at -O1 and above.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91389
--- Comment #7 from Jakub Jelinek ---
Forgot to say, if you are just looking for a workaround for the warning (note,
-O2 -Wreturn-type doesn't warn, in this case you need also no optimizations),
then I'd just move the return from the default: cla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91389
--- Comment #6 from Martin Liška ---
(In reply to Jakub Jelinek from comment #5)
> (In reply to Martin Liška from comment #4)
> > (In reply to Jakub Jelinek from comment #3)
> > > I see dead code everywhere in the function, they must have some we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91287
rsandifo at gcc dot gnu.org changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86899
--- Comment #6 from Jakub Jelinek ---
*** Bug 91389 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91389
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91395
--- Comment #3 from Andrew Pinski ---
In theory other can cause a call to longjmp but gcc does not know it cannot.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90415
--- Comment #7 from Lei YU ---
Additional information.
std::experimental::fundamentals_v1::any has no problem, so the below code
compiles fine.
```
#include
#include
#include
bool is_copy_constructible_tuple_any() {
return
std::is_copy_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91389
--- Comment #4 from Martin Liška ---
(In reply to Jakub Jelinek from comment #3)
> I see dead code everywhere in the function, they must have some weirdo macro
> for cases that wraps everything in case something { ... } break;
Is the 'break;' re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91389
--- Comment #3 from Jakub Jelinek ---
I see dead code everywhere in the function, they must have some weirdo macro
for cases that wraps everything in case something { ... } break;
Many of those break; statements are dead code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91352
--- Comment #4 from Martin Liška ---
Author: marxin
Date: Thu Aug 8 07:50:28 2019
New Revision: 274208
URL: https://gcc.gnu.org/viewcvs?rev=274208&root=gcc&view=rev
Log:
Fix file descriptor existence of MinGW.
2019-08-08 Martin Liska
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91395
--- Comment #2 from Adam ---
I got the point "The local variables that do not have the volatile type and
have been changed between the setjmp() invocation and longjmp() call are
indeterminate"
But save_exception_stack is not changed between the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #18 from Martin Liška ---
(In reply to Richard Earnshaw from comment #17)
> Created attachment 46686 [details]
> candidate patch
>
> Could you try this patch please? So far only very lightly tested.
Sure, I'll test the problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91379
--- Comment #3 from Martin Liška ---
(In reply to Clinton Bunch from comment #2)
> 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 v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91389
--- Comment #2 from Martin Liška ---
Created attachment 46688
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46688&action=edit
Original test-case
I'm fine with the approach to remove a dead code. However, I can't easily find
what to change
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91392
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91393
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91395
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Component|c
1 - 100 of 101 matches
Mail list logo
