https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78049
Andrew Pinski changed:
What|Removed |Added
Target Milestone|7.0 |5.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66313
--- Comment #17 from Dmitry Babokin ---
Any chances for the fix for this bug?
Looks like this one stands as a last obstacle to claim UBSAN in GCC fully
functional.
I still see quite a few errors, but looks like all of them are attributed to
thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80923
Bug ID: 80923
Summary: RTEMS SH ICE building gcc-7.1.0 on FreeBSD 11.0
Product: gcc
Version: 7.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78603
--- Comment #6 from jcmvbkbc at gcc dot gnu.org ---
Author: jcmvbkbc
Date: Wed May 31 00:05:38 2017
New Revision: 248714
URL: https://gcc.gnu.org/viewcvs?rev=248714&root=gcc&view=rev
Log:
xtensa: Fix PR target/78603
2017-05-30 Max Filippov
gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78118
--- Comment #6 from jcmvbkbc at gcc dot gnu.org ---
Author: jcmvbkbc
Date: Wed May 31 00:05:01 2017
New Revision: 248713
URL: https://gcc.gnu.org/viewcvs?rev=248713&root=gcc&view=rev
Log:
xtensa: Fix PR target/78118
It started failing after the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80916
--- Comment #1 from Davin McCall ---
(Does not actually require -Wno-invalid-offsetof to reproduce; that was just me
copying my command line literally. Problem first appears in GCC 6.1, not in
5.x, still present in 7.1).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78603
--- Comment #5 from jcmvbkbc at gcc dot gnu.org ---
Author: jcmvbkbc
Date: Tue May 30 23:41:58 2017
New Revision: 248708
URL: https://gcc.gnu.org/viewcvs?rev=248708&root=gcc&view=rev
Log:
xtensa: Fix PR target/78603
2017-05-30 Max Filippov
gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80840
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850
--- Comment #7 from Thomas Koenig ---
236968 OK
248467 Not OK
Trying 242717 ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80557
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80922
Bug ID: 80922
Summary: #pragma diagnostic ignored not honoured with -flto
Product: gcc
Version: 7.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80910
Tom de Vries changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80910
--- Comment #2 from Tom de Vries ---
Author: vries
Date: Tue May 30 22:00:57 2017
New Revision: 248701
URL: https://gcc.gnu.org/viewcvs?rev=248701&root=gcc&view=rev
Log:
Test if host compiler supports -std=c++11 in ms-sysv.exp
2017-05-30 Tom d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54202
--- Comment #6 from Thiago Macieira ---
ping.
If you can't fix GCC so that it can prove that the free is on a non-heap
object, then please change the warning to indicate that GCC may be wrong. For
example:
warning: free() may be called with non
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80187
--- Comment #5 from Tim Shen ---
(In reply to Ambroz Bizjak from comment #4)
> Oh wait sorry, that doesn't solve it (yet), the variant_storage_byte would
> still have a default copy constructor that copies the byte member.
Yeah, your solution se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80731
--- Comment #5 from Martin Sebor ---
Author: msebor
Date: Tue May 30 21:27:35 2017
New Revision: 248700
URL: https://gcc.gnu.org/viewcvs?rev=248700&root=gcc&view=rev
Log:
gcc/testsuite/ChangeLog:
PR c/80731
* g++.dg/ext/utf16-4.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80856
--- Comment #2 from Jason Merrill ---
Author: jason
Date: Tue May 30 21:13:27 2017
New Revision: 248699
URL: https://gcc.gnu.org/viewcvs?rev=248699&root=gcc&view=rev
Log:
PR c++/80856 - ICE with local extern in template
* semant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914
--- Comment #3 from Steven Noonan ---
This is from a different go.gcc binary, because I've rebuilt several times to
try and troubleshoot. But this one still exhibits the bad behavior. Just in
case, I've uploaded a copy of the binary, the entire '
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921
Eric Botcazou changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80187
--- Comment #4 from Ambroz Bizjak ---
Oh wait sorry, that doesn't solve it (yet), the variant_storage_byte would
still have a default copy constructor that copies the byte member.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80187
--- Comment #3 from Ambroz Bizjak ---
Hey,
Does this idea help: https://godbolt.org/g/3Iqp2c ?
The storage is an array of "special" byte classes which have empty
constructors/assign when those would be implemented by one of the mixins.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850
--- Comment #6 from Jerry DeLisle ---
(In reply to DIL from comment #4)
> Offset of zero is fine. I have never observed this SegFault before. I ran
> the test on multiple machines with GCC/5.3.0, GCC/5.4.0, and GCC/6.3.1.
> Also, as I mentioned b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80921
Bug ID: 80921
Summary: Cross compiling for mingw32 target fails to build Ada
shared libraries
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850
--- Comment #5 from Thomas Koenig ---
I'm trying for some bisection.
I hope this is not going to turn out as complex as PR 79430 ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80830
Nathan Sidwell changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80892
Martin Sebor changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from Martin Sebor -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80894
seurer at gcc dot gnu.org changed:
What|Removed |Added
CC||seurer at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80856
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80915
H.J. Lu changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80893
--- Comment #3 from Jonathan Wakely ---
This is actually a problem in vector though: it assumes allocate(0)
returns a non-null pointer, which is unspecified.
This should fix it:
--- a/libstdc++-v3/include/bits/stl_bvector.h
+++ b/libstdc++-v3/i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80915
--- Comment #4 from H.J. Lu ---
This may be fixed by r248687.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80833
--- Comment #13 from uros at gcc dot gnu.org ---
Author: uros
Date: Tue May 30 17:18:25 2017
New Revision: 248691
URL: https://gcc.gnu.org/viewcvs?rev=248691&root=gcc&view=rev
Log:
PR target/80833
* config/i386/constraints.md (Yd)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80893
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80893
--- Comment #1 from Jonathan Wakely ---
I can't reproduce this with the default configuration so I assume it's caused
by --enable-libstdcxx-allocator=pool (why are you using that?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79162
--- Comment #9 from Jonathan Wakely ---
I'm unable to reproduce this with the following, based on the llvm code. GCC
does the right thing here, so without a testcase there's nothing we can do.
#include
template
class storage {
public:
operat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80915
Nathan Sidwell changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80915
--- Comment #3 from Nathan Sidwell ---
Works for me:
/data/users/nathans/trunk/obj/x86_64-lto/./prev-gcc/xg++
-B/data/users/nathans/trunk/obj/x86_64-lto/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/data/users/nathans/trunk/obj
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79162
--- Comment #8 from Jonathan Wakely ---
Can you reduce the failing code down to something smaller than the entirety of
LLVM?
Richard also says the overload shouldn't exist and is a bug, but the overload
has to exist, because the C++17 draft is d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80920
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80850
--- Comment #4 from DIL ---
Offset of zero is fine. I have never observed this SegFault before. I ran the
test on multiple machines with GCC/5.3.0, GCC/5.4.0, and GCC/6.3.1. Also, as I
mentioned before, the test passed the VALGRIND check. Would y
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80913
Nathan Sidwell changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80913
--- Comment #10 from Nathan Sidwell ---
Author: nathan
Date: Tue May 30 14:43:45 2017
New Revision: 248687
URL: https://gcc.gnu.org/viewcvs?rev=248687&root=gcc&view=rev
Log:
PR c++/80913
* name-lookup.c (add_decl_to_level): Asser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80915
--- Comment #2 from H.J. Lu ---
(In reply to Nathan Sidwell from comment #1)
> I cannot reproduce this. an x86_64-linux host using
> --with-build-config=bootstrap-lto
>
>
> How exactly is gcc being configured and built? Alternatively, is is
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80917
--- Comment #2 from Marc Glisse ---
For this special case, we could simplify
a_6 = a_5(D) + 4;
_2 = a_6 & 2;
to
_2 = a_5(D) & 2;
I believe we already have a similar transform with | 4 instead of + 4.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80920
Bug ID: 80920
Summary: warnings get position wrong - very confusing
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80915
--- Comment #1 from Nathan Sidwell ---
I cannot reproduce this. an x86_64-linux host using
--with-build-config=bootstrap-lto
How exactly is gcc being configured and built? Alternatively, is is possible
for a self-contained testcase?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80914
--- Comment #2 from Ian Lance Taylor ---
The failure is in libbacktrace. The program crashes because once libbacktrace
fails the first time, the program is trying to use libbacktrace to show a stack
trace of the failure. This leads to an infini
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80910
--- Comment #1 from Tom de Vries ---
Created attachment 41440
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41440&action=edit
tentative patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80759
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #18 from Daniel Santos ---
> I intended to respond to your comments from 6 days ago sooner, but better late
> than never! Again, sorry for the delay
No worries at all: I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80913
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Nathan Sidwell ---
> It doesn't appear to be the stathack patch at fault here. I still get the
> infinite loop with my reduced testcase when I revert it. (Which i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80116
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80913
David Edelsohn changed:
What|Removed |Added
Target|i386-pc-solaris2.12,|i386-pc-solaris2.12,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80822
--- Comment #12 from Jakub Jelinek ---
Author: jakub
Date: Tue May 30 12:05:30 2017
New Revision: 248683
URL: https://gcc.gnu.org/viewcvs?rev=248683&root=gcc&view=rev
Log:
PR libgomp/80822
* config/linux/affinity.c (gomp_affinity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80901
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80919
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80919
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80919
Bug ID: 80919
Summary: [7 Regression] ICE: Segmentation fault with -Wall when
printing address of size 0 array
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80913
--- Comment #7 from Nathan Sidwell ---
It doesn't appear to be the stathack patch at fault here. I still get the
infinite loop with my reduced testcase when I revert it. (Which is good,
because I can't see how that patch could cause this behavi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80901
--- Comment #3 from Richard Biener ---
Author: rguenth
Date: Tue May 30 11:08:36 2017
New Revision: 248681
URL: https://gcc.gnu.org/viewcvs?rev=248681&root=gcc&view=rev
Log:
2017-05-30 Richard Biener
PR middle-end/80901
* cfg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78838
--- Comment #3 from Nick Clifton ---
Author: nickc
Date: Tue May 30 10:49:29 2017
New Revision: 248674
URL: https://gcc.gnu.org/viewcvs?rev=248674&root=gcc&view=rev
Log:
PR target/78838
gcc * config/msp430/msp430.c (gen_prefix): Retu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80918
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |6.4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13182
--- Comment #10 from Eric Botcazou ---
> To be clear: x86/Linux and x86-64/Linux (and for them there is no protection
> area during the probing).
I misremembered: there is exactly one page of protection area for them because
of the way the unwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80918
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80918
Bug ID: 80918
Summary: [6/7/8 Regression] Assumed size whole array rejected
in depend clause
Product: gcc
Version: 7.1.1
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13182
--- Comment #9 from Eric Botcazou ---
> Right, the Ada runtime uses an alternate signal stack for specific platforms.
To be clear: x86/Linux and x86-64/Linux (and for them there is no protection
area during the probing).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80911
--- Comment #17 from Tom de Vries ---
(In reply to Martin Liška from comment #2)
> Can't confirm that, running trunk@248556 works fine for me.
> Utilizing valgrind also does not help.
I also had problems reproducing the problem, so I decided to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13182
--- Comment #8 from Eric Botcazou ---
> I'm not sure if the the probing offset is large enough for this purpose
> because the kernel keeps pushing more and more data onto the stack during
> signal handling:
>
> https://sourceware.org/bugzilla/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51322
Jonathan Wakely changed:
What|Removed |Added
CC||plasmahh at gmx dot net
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59457
Jonathan Wakely changed:
What|Removed |Added
Keywords||ABI
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13182
--- Comment #7 from Florian Weimer ---
(In reply to Eric Botcazou from comment #6)
> That's as expected: the probing mechanism maintains a protection area so the
> program can recover from a stack overflow condition by raising an exception.
> Tha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80610
--- Comment #17 from Gustavo Hime ---
(In reply to Jerry DeLisle from comment #12)
Dear Jerry,
Thank you for the feedback.
For the record, I didn't say gfortran is crap, nor did I throw insults at it.
At least I didn't mean to. Sorry if you mis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=13182
Eric Botcazou changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80701
--- Comment #6 from Gustavo Hime ---
(In reply to Thomas Koenig from comment #5)
Dear Thomas,
Thank you for the feedback.
Please keep in mind this can easily arise in a shared codebase, sometimes
unintentionally. As Dominique pointed out, a si
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80701
Thomas Koenig changed:
What|Removed |Added
Status|WAITING |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80906
Richard Biener changed:
What|Removed |Added
Blocks||70390
--- Comment #3 from Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80394
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80385
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80363
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80286
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80176
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80168
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80141
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80112
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80129
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80097
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79944
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80025
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79896
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79932
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79901
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79807
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79641
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79729
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79570
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79568
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79559
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79512
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79494
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79197
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79396
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
1 - 100 of 226 matches
Mail list logo
