https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972
Andrew Pinski changed:
What|Removed |Added
Component|rtl-optimization|target
--- Comment #5 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77347
--- Comment #5 from Jakub Jelinek ---
Oops, please take #c4 back, it is a variable declarator, not function
declarator.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78973
Bug ID: 78973
Summary: [7 Regression] warning: ‘memcpy’: specified size
between 18446744071562067968 and 18446744073709551615
exceeds maximum object size 9223372036854775807
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78970
Martin Liška changed:
What|Removed |Added
Keywords||ice-on-valid-code
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78932
--- Comment #1 from xqr4n54r1 at hotmail dot com ---
Created attachment 40444
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40444&action=edit
filter_with_O2.c.201r.bbro : Indicates that the problem has occurred. -
filter_without_inline.c.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77284
Marek Polacek changed:
What|Removed |Added
Keywords|error-recovery |ice-on-valid-code
Priority|P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77545
Marek Polacek changed:
What|Removed |Added
Keywords|ice-on-invalid-code |ice-on-valid-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #17 from Dominik Vogt ---
Can you make sense of these results? The size of gamess has not changed, but
the runtime has but still looks noticeably worse. The astar performance looks
similar to yesterday's result without the change fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484
--- Comment #18 from Dominik Vogt ---
(The perlbench result looks like a bad measurement result; we sometimes have
this on devel machine for unknown reasons, possibly when someone compiles or
tests on a different partition.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71361
--- Comment #3 from amker at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #2)
> Any progress with this?
I had a patch which can resolve the reported regression, and generate even
better code than the original:
.L5:
movl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71361
--- Comment #4 from Jakub Jelinek ---
So shall we defer this PR to GCC 8 then (i.e. [8 Regression] and Target
Milestone: 8.0? Richard, are you ok with that?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71182
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78428
--- Comment #10 from Martin Liška ---
Author: marxin
Date: Tue Jan 3 10:54:40 2017
New Revision: 244016
URL: https://gcc.gnu.org/viewcvs?rev=244016&root=gcc&view=rev
Log:
Fill bitregion_{start,end} in store_constructor (PR tree-optimization/784
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #24
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77413
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589
Georg changed:
What|Removed |Added
CC||georggcc at googlemail dot com
--- Comment #8 fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77468
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77413
--- Comment #4 from Jonathan Wakely ---
Almost certainly r240656 which replaces the problematic use of std::abs with an
always-constexpr __abs function (which r240723 then renamed to __abs_integral).
So I think this is a dup of PR 77801
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
--- Comment #25 from Dominik Vogt ---
(In reply to Jakub Jelinek from comment #24)
> So is this fixed now?
As far as I know, it's fixed.
> Or is it being kept open because that change broke
> sparc*-* (but that is already tracked in a different
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77359
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78114
amker at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78966
--- Comment #2 from Eelis ---
The testcase was a minimized version of the (imho innocuous looking):
#include
#include
template
std::ostream & operator<<(std::ostream &, std::variant const &);
int main() { std::cout << std::endl; }
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77801
Jakub Jelinek changed:
What|Removed |Added
CC||ro at gcc dot gnu.org
--- Comment #8 fro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77413
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78428
--- Comment #11 from Martin Liška ---
Author: marxin
Date: Tue Jan 3 12:04:05 2017
New Revision: 244018
URL: https://gcc.gnu.org/viewcvs?rev=244018&root=gcc&view=rev
Log:
Fill bitregion_{start,end} in store_constructor (PR tree-optimization/784
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78428
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|6.4 |---
--- Comment #9 from Jonathan Wakel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78901
--- Comment #16 from h2+bugs at fsfe dot org ---
(In reply to Jakub Jelinek from comment #15)
> Fixed.
Thanks, confirmed it fixes our issues.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78886
--- Comment #10 from Martin Liška ---
Author: marxin
Date: Tue Jan 3 12:08:10 2017
New Revision: 244019
URL: https://gcc.gnu.org/viewcvs?rev=244019&root=gcc&view=rev
Log:
Fix tree-optimization/78886.
2017-01-03 Martin Liska
Backpor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78886
--- Comment #11 from Martin Liška ---
Author: marxin
Date: Tue Jan 3 12:09:05 2017
New Revision: 244020
URL: https://gcc.gnu.org/viewcvs?rev=244020&root=gcc&view=rev
Log:
Fix tree-optimization/78886.
2017-01-03 Martin Liska
Backpor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78886
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78863
--- Comment #6 from Martin Liška ---
Author: marxin
Date: Tue Jan 3 12:15:32 2017
New Revision: 244021
URL: https://gcc.gnu.org/viewcvs?rev=244021&root=gcc&view=rev
Log:
Do not suggest -fsanitize=all (PR driver/78863).
2017-01-03 Martin Liska
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78863
Martin Liška changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78631
--- Comment #13 from Ilya Enkovich ---
(In reply to Alexander Ivchenko from comment #12)
> Fixed with r243942
It should be backported to GCC6.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77569
--- Comment #4 from Jakub Jelinek ---
I still can't reproduce on x86_64-linux, but looking at the above mentioned
line (in input.c from that date), there is:
/* Detect and record errors emitted by libcpp/charset.c:init_iconv_desc
when
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77569
--- Comment #5 from Jakub Jelinek ---
Created attachment 40446
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40446&action=edit
gcc7-pr77569.patch
Untested fix that implements the verification - if that message has been
translated, the sel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77569
Jakub Jelinek changed:
What|Removed |Added
Attachment #40446|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968
--- Comment #2 from Jonathan Wakely ---
Created attachment 40448
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40448&action=edit
Check for __cxa_thread_atexit in libc
Does this fix it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968
--- Comment #3 from Jonathan Wakely ---
(In reply to h2+bugs from comment #0)
> This is a bug in gcc. The libsupc++ configuration assumes that there are
> exactly two possibilities: either libc is glibc and implements
> __cxa_thread_atexit() usi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78974
Bug ID: 78974
Summary: STM32L4 CPU read burst access equal to or more than 9
registers to FMC returns corrupted data starting from
the 9th read word
Product: gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968
--- Comment #4 from Jonathan Wakely ---
I wonder why FreeBSD chose to do it that way, instead of providing the _impl
function, which would also work with LLVM's libcxxabi.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78975
Bug ID: 78975
Summary: uniform_real_distribution should not check RealType
with is_floating_point
Product: gcc
Version: 6.3.1
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968
--- Comment #5 from Jonathan Wakely ---
It seems entirely wrong for libc to be providing any __cxa entry point called
by the compiler, such as __cxa_thread_atexit. It should come from the C++
runtime, such as libsupc++, or libcxxabi, or FreeBSD's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78975
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78956
--- Comment #1 from Jonathan Wakely ---
Author: redi
Date: Tue Jan 3 13:31:26 2017
New Revision: 244022
URL: https://gcc.gnu.org/viewcvs?rev=244022&root=gcc&view=rev
Log:
Add deleted std::thread(const thread&&) constructor
PR libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=76957
Rainer Orth changed:
What|Removed |Added
Target|arm-none-eabi |arm-none-eabi
|hppa-unkn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78976
Bug ID: 78976
Summary: [7 Regression] FAIL: gfortran.dg/dependency_49.f90 and
gfortran.dg/transfer_intrinsic_1.f90
Product: gcc
Version: 7.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977
Bug ID: 78977
Summary: g++7 snprintf() of double produces wrong code with -O3
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834
--- Comment #1 from Roel Standaert ---
I guess you can't really expect the compiler to correctly infer the value of
the if statement at compile time?
If std::enable_if is used instead of an if statement, GCC won't generate a
warning: https://god
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78976
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968
--- Comment #6 from h2+bugs at fsfe dot org ---
Thanks for your quick response!
To be honest, I only have a very basic understanding of the matter. The
original discussion of the implementation in FreeBSD can found here:
https://bugs.freebsd.org/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78978
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968
--- Comment #7 from Jonathan Wakely ---
Right. This can be worked around for any GCC releases except 5.5, 6.4 and 7.1,
but anything older can't be fixed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968
--- Comment #8 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #7)
> Right. This can be worked around for any GCC releases except 5.5, 6.4 and
> 7.1, but anything older can't be fixed.
Sorry, I edited that sentence half way th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78978
Bug ID: 78978
Summary: [7 regression] runtime/pprof FAILs on Solaris 2/x86
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78956
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78979
Bug ID: 78979
Summary: 27_io/headers/cstdio/functions_neg.cc FAILs on Solaris
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78979
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834
--- Comment #2 from Matt Godbolt ---
if constexpr is of course the right solution here, for certain.
I appreciate the compiler determining which if() branch to take in the
non-constexpr case is tricky.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77734
Rainer Orth changed:
What|Removed |Added
Target|hppa-unknown-linux-gnu |hppa-unknown-linux-gnu,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78116
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67321
--- Comment #5 from Christophe Lyon ---
I think this was fixed by Michael's commit r235402.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78978
--- Comment #1 from Ian Lance Taylor ---
If the libstdc++ approach works and is acceptable, it seems to me we should do
the same for libgo.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968
Kostik Belousov changed:
What|Removed |Added
CC||kostikbel at ukr dot net
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78980
Bug ID: 78980
Summary: runtime/internal/atomic FAILs on 32-bit SPARC
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78980
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |7.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |7.0
--- Comment #6 from Thomas Koenig -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968
--- Comment #10 from Jonathan Wakely ---
(In reply to Kostik Belousov from comment #9)
> Would older gcc releases fine if FreeBSD exports __cxa_thread_atexit_impl as
> an alias for __cxa_thread_atexit ?
I think there would still be a duplicate d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78979
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78979
--- Comment #2 from Jonathan Wakely ---
The Solaris header would be more correct if it did:
#if __STDC_VERSION__ < 201112L && __cplusplus < 201402L
extern char *gets(char *) __ATTR_DEPRECATED;
#endif
That would suppress the declaration for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78899
--- Comment #3 from Jakub Jelinek ---
The original ICE is with -flto, but modified testcase:
/* PR c++/71077 */
/* { dg-do compile { target { i?86-*-* x86_64-*-* } } } */
/* { dg-options "-O3 -march=core-avx2" } */
int *a;
static int b, c, d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78968
--- Comment #11 from Kostik Belousov ---
(In reply to Jonathan Wakely from comment #10)
> (In reply to Kostik Belousov from comment #9)
> > Would older gcc releases fine if FreeBSD exports __cxa_thread_atexit_impl as
> > an alias for __cxa_thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78899
--- Comment #4 from Jakub Jelinek ---
Somewhat more simplified:
/* PR c++/71077 */
/* { dg-do compile } */
/* { dg-options "-O3" } */
/* { dg-additional-options "-mavx2" { target { i?86-*-* x86_64-*-* } } } */
void
foo (int *a, int n)
{
int b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78973
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977
--- Comment #2 from Martin Sebor ---
It's possible that this bug will be fixed by my patch for bug 78696. The patch
was approved just before the holidays but I am yet to commit it. Let me retest
it and check it in today.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78973
Markus Trippelsdorf changed:
What|Removed |Added
Status|WAITING |NEW
Summary|[7 Regressi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78981
Bug ID: 78981
Summary: Sign extension bug when stdlib is not explicitly
included while using getenv on amd64.
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Se
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977
--- Comment #3 from h2+bugs at fsfe dot org ---
(In reply to Jakub Jelinek from comment #1)
> You haven't provided a self-contained test, so it is hard to know exactly,
> but I bet it is the -fprintf-return-value optimization. Try
> -fno-printf-r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78981
--- Comment #1 from Andrew Pinski ---
You should be getting an implicit function declared warning with -Wextra -Wall
.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78975
--- Comment #2 from Charles Karney ---
Gag... I see that the standard indeed restricts the implementation to
float, double, and long double. Was this really the intention? Everything
carries over beautifully for arbitrary types that "behave" a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78981
Andreas Schwab changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69517
--- Comment #14 from Marek Polacek ---
I don't see the segv anymore with current trunk.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78978
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78534
--- Comment #16 from Janne Blomqvist ---
Author: jb
Date: Tue Jan 3 18:01:30 2017
New Revision: 244027
URL: https://gcc.gnu.org/viewcvs?rev=244027&root=gcc&view=rev
Log:
PR 78534 Revert r244011
r244011 caused regressions on 32-bit hosts.
Remo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78789
--- Comment #1 from Uroš Bizjak ---
Proposed patch at [1].
[1] https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00117.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65618
--- Comment #11 from Jeffrey A. Law ---
Author: law
Date: Tue Jan 3 18:41:05 2017
New Revision: 244029
URL: https://gcc.gnu.org/viewcvs?rev=244029&root=gcc&view=rev
Log:
PR rtl-optimization/65618
* emit-rtl.c (try_split): Move i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65618
Jeffrey A. Law changed:
What|Removed |Added
CC||law at redhat dot com
Summar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78944
--- Comment #2 from Ivan Sorokin ---
Another very rare crash discovered by my fuzzer: _Z1fAqu4SmFG1n3_a.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78789
--- Comment #2 from ian at gcc dot gnu.org ---
Author: ian
Date: Tue Jan 3 20:41:54 2017
New Revision: 244031
URL: https://gcc.gnu.org/viewcvs?rev=244031&root=gcc&view=rev
Log:
PR go/78789
runtime: don't build aeshash.c if the assem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78977
--- Comment #4 from Jakub Jelinek ---
(In reply to Hannes Hauswedell from comment #3)
> > if it does, then we really need self-contained small test.
>
> Like I said, it doesn't happen on all the time and I have had difficulties
> extracting it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78789
Ian Lance Taylor changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78953
--- Comment #2 from Michael Meissner ---
Created attachment 40449
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40449&action=edit
Proposed patch to fix the problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39589
--- Comment #10 from Manuel López-Ibáñez ---
(In reply to Georg from comment #8)
> If it helps implementing this legitimate distinction between
> use cases, i.e. default initialisation vs. software maintenance,
> I'd be happy having to attach a t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70834
Manuel López-Ibáñez changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77721
--- Comment #4 from Martin Sebor ---
As it turns out, the patch for bug 78622 only masked the true root cause of the
problem which is bug 78969. An unrelated patch I'm testing makes the false
positives come back. There may be a way to work arou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78964
Manuel López-Ibáñez changed:
What|Removed |Added
CC||manu at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77421
Manuel López-Ibáñez changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78976
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |NEW
Target Milestone|---
1 - 100 of 130 matches
Mail list logo
