http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57384
Bug ID: 57384
Summary: can't expand a parameter pack into a list of function
types or function pointer types
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Seve
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370
--- Comment #4 from Joost VandeVondele
---
I killed the compilation after 15h...
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56915
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56930
Jason Merrill changed:
What|Removed |Added
Summary|[4.8/4.9 regression]|[4.8 regression] pointless
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57383
Bug ID: 57383
Summary: Illegal program not detected, RM 7.3(10.1)
Product: gcc
Version: 4.5.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57362
--- Comment #3 from Sriraman Tallam ---
Patch proposed to fix this problem,
This happens when a subset of versions are invalid because of unrecognized
target string name or if a dispatcher for that is not available. When
constructing the version
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57382
Bug ID: 57382
Summary: Illegal type conversion to access-interface-class
inside generic not detected
Product: gcc
Version: 4.5.4
Status: UNCONFIRMED
Severity: no
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742
Richard Henderson changed:
What|Removed |Added
Attachment #30168|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30807
--- Comment #12 from Kazumoto Kojima ---
(In reply to Oleg Endo from comment #11)
> Would it be OK to add this test case to gcc.target/sh/torture and close this
> PR?
Please go ahead.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57352
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57379
Uroš Bizjak changed:
What|Removed |Added
Component|rtl-optimization|target
--- Comment #1 from Uroš Bizjak ---
gcc version 4.9.0 20130522 (experimental) [trunk revision 199191] (GCC)
$ time gcc-trunk -O0 -c small.c
real0m0.023s
user0m0.008s
sys0m0.008s
$ time gcc-4.7 -O1 -c small.c
real0m0.028s
user0m0.004s
sys0m0.016s
$ time timeout 10 gcc-trunk -O1 -c small.c
real0m10.002s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57380
--- Comment #1 from Jeremiah Willcock ---
I tested version "(Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3" and that fails as well
(with "note: not vectorized: data ref analysis failed D.2097_9 = *D.2115_16;"
in the vectorization report).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57380
Bug ID: 57380
Summary: GCC 4.9.0 will not vectorize std::max and similar
functions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Pri
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742
--- Comment #9 from Richard Henderson ---
Created attachment 30168
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30168&action=edit
proposed patch
Kudos to Kai for finally figuring out what was going wrong inside the
system unwinder, and why
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742
Richard Henderson changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56742
Richard Henderson changed:
What|Removed |Added
CC||rth at gcc dot gnu.org
Target Miles
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30807
Oleg Endo changed:
What|Removed |Added
CC||olegendo at gcc dot gnu.org
--- Comment #11 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37140
fabien at gcc dot gnu.org changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |fabien at gcc dot
gnu.o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57379
Bug ID: 57379
Summary: [4.9 Regression]: Segfault in
invalidate_any_buried_refs (x=0x0) at
../../gcc-svn/trunk/gcc/gcse.c:3850
Product: gcc
Version: 4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57378
Bug ID: 57378
Summary: gnu multiversioning gives assembler error:
foo.resolver is already defined
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: nor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57341
--- Comment #8 from rguenther at suse dot de ---
"jakub at gcc dot gnu.org" wrote:
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57341
>
>--- Comment #7 from Jakub Jelinek ---
>(In reply to Michael Matz from comment #5)
>> Nope. Our memory mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57352
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287
--- Comment #3 from Pedro Alves ---
hmb,
could you do that?
See instructions here: http://gcc.gnu.org/bugs/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57377
Bug ID: 57377
Summary: compiler cannot be built with RTL checking
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57376
Bug ID: 57376
Summary: Bogus error due to failure of unqualified namespace
lookup
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Pr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57375
--- Comment #1 from mib.bugzilla at gmail dot com ---
Created attachment 30166
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30166&action=edit
Test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57375
Bug ID: 57375
Summary: gnu multiversioning selects different version
depending on link order
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57368
--- Comment #1 from Nick Maclaren ---
Disabling --enable-checking=all causes it to build.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57371
--- Comment #2 from Marc Glisse ---
Thank you for this very detailed analysis :-)
(In reply to jos...@codesourcery.com from comment #1)
> * If not all values of the integer type can be represented in the
> floating-point type exactly, then the c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57347
Martin Jambor changed:
What|Removed |Added
URL||http://gcc.gnu.org/ml/gcc-p
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57356
Uroš Bizjak changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57340
Ramana Radhakrishnan changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57374
--- Comment #5 from Akim Demaille ---
Apologies :( I really thought my 4.9 was young enough.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57374
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57371
--- Comment #1 from joseph at codesourcery dot com ---
On Wed, 22 May 2013, glisse at gcc dot gnu.org wrote:
> int f(int i){
> return (double)i != 0;
> }
>
> compiled with -Ofast (I don't think -ffast-math matters) keeps the conversion
> to do
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57374
--- Comment #3 from Akim Demaille ---
Also, FWIW, libstdc++ headers use __attribute__((noreturn)), so there's no way
to get some inspiration from there :)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57374
--- Comment #2 from Akim Demaille ---
Hi Paolo,
I have tried to put it in about every possible place, and the one I used in the
attached example is the one from
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2761.pdf which is
cited in h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57374
--- Comment #1 from Paolo Carlini ---
It seems to me that you have it in the wrong place, see cpp0x/gen-attrs-4.C
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57374
Bug ID: 57374
Summary: c+11 attribute noreturn does not blend well
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57340
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57373
Bug ID: 57373
Summary: ICE on invalid: insert_bbt(): Duplicate key found!
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57372
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57340
Ramana Radhakrishnan changed:
What|Removed |Added
CC||zhroma at ispras dot ru
--- Commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57372
Bug ID: 57372
Summary: [4.9 Regression] Miscompiled tailcall on ARM
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-o
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366
--- Comment #6 from Rainer Orth ---
Created attachment 30163
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30163&action=edit
assembler output from testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #4 from Jan Hubicka ---
> Thank you. It seems that the weakref is simply not output into the file, so we
> end up with undefined call.
Which may or may not be the same prob
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57341
--- Comment #7 from Jakub Jelinek ---
(In reply to Michael Matz from comment #5)
> Nope. Our memory model allows this, the write will dynamically change
> the type of the written memory cell.
But why is that? Just to handle placement new? I'd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
Jan Hubicka changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57341
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56930
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57341
--- Comment #5 from Michael Matz ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Richard Biener from comment #3)
> > It seems the code really wants to use anti_dependence, not true_dependence.
> > We have
> >
> > ... = equiv_me
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57371
Bug ID: 57371
Summary: Simplify (double)i != 0
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57341
Jakub Jelinek changed:
What|Removed |Added
CC||vmakarov at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370
--- Comment #3 from Joost VandeVondele
---
I actually suspect the compilation is in an infinite loop. Still running after
15min.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57341
--- Comment #3 from Richard Biener ---
(In reply to Jakub Jelinek from comment #2)
> Seems validate_equiv_mem_from_store during update_equiv_regs calls
> true_dependence to find out if it is safe to use it as equiv, and
> true_dependence is called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57328
Marc Glisse changed:
What|Removed |Added
CC||glisse at gcc dot gnu.org
--- Comment #10 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370
Joost VandeVondele changed:
What|Removed |Added
CC||eraman at google dot com
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370
Joost VandeVondele changed:
What|Removed |Added
CC||Joost.VandeVondele at mat dot
ethz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57370
Bug ID: 57370
Summary: [4.9 Regression] compile time hog in reassoc
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56930
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57369
Bug ID: 57369
Summary: type-less DW_TAG_const_type
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366
--- Comment #4 from Jan Hubicka ---
Thank you. It seems that the weakref is simply not output into the file, so we
end up with undefined call.
What happens when you compile the following manually concatenated testcase w/o
LTO? If it links, can you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57368
Bug ID: 57368
Summary: Trying to build CilkPlus fails with an ICE
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57367
--- Comment #7 from Richard Biener ---
(In reply to Paolo Carlini from comment #6)
> Disappointing, Richard, that in 4.8/4.9 (vs 4.7) we don't seem to warn at
> all for the testcase in Comment#4 too. I'm wondering if the tree-vrp.c check
> couldn'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57367
Paolo Carlini changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56033
Rainer Orth changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57364
--- Comment #4 from Tobias Burnus ---
Author: burnus
Date: Wed May 22 12:43:55 2013
New Revision: 199196
URL: http://gcc.gnu.org/viewcvs?rev=199196&root=gcc&view=rev
Log:
2013-05-22 Tobias Burnus
PR fortran/57364
* resolve.c (
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57367
--- Comment #5 from Paolo Carlini ---
Remember that -O2 is required for this kind of middle-end check. A front-end
check would not.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366
--- Comment #3 from Rainer Orth ---
Created attachment 30160
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30160&action=edit
-O0 -flto -flto-partition=none -fuse-linker-plugin testcase with Sun as/gld
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366
--- Comment #2 from Rainer Orth ---
(In reply to Jan Hubicka from comment #1)
> I solved the infinite loop problem on plugin enabled setups with
> http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00847.html
> Are you still seeing the infinite loop?
M
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57367
--- Comment #4 from Guido Del Sarto ---
I do not receive warnings with the following (no dead code).
#
#include
void warning( int pippo[100] )
{
pippo[1000] += pippo[0];
printf( "%d\n", pippo[1000] ) ;
}
int main(int argc, char**ar
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57367
--- Comment #3 from Paolo Carlini ---
Yeah, shared between the front-ends, this isn't a C++-only issue, of course.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57367
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57038
--- Comment #24 from Jan Hubicka ---
S=/home/marxin/libreoffice && O=$S/solver/unxlngx6.pro &&
W=$S/workdir/unxlngx6.pro && mkdir -p $W/LinkTarget/Executable/ && g++ -flto
-fno-fat-lto-objects -fuse-linker-plugin -O2 -Wl,-z,origin
'-Wl,-rpath,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57349
Richard Biener changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56982
Bug 56982 depends on bug 57349, which changed state.
Bug 57349 Summary: [4.9 Regression] ICE on 253.perlbmk with pgo after r198096
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57349
What|Removed |Added
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57338
--- Comment #4 from Tobias Burnus ---
FIXED on the trunk (4.9).
Thanks for the report!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57338
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57364
--- Comment #3 from mikael.morin at sfr dot fr ---
Le 22/05/2013 11:22, burnus at gcc dot gnu.org a écrit :
> --- a/gcc/fortran/resolve.c
> +++ b/gcc/fortran/resolve.c
> @@ -9299,4 +9299,5 @@ get_temp_from_expr (gfc_expr *e, gfc_namespace *ns)
>
Le 22/05/2013 11:22, burnus at gcc dot gnu.org a écrit :
> --- a/gcc/fortran/resolve.c
> +++ b/gcc/fortran/resolve.c
> @@ -9299,4 +9299,5 @@ get_temp_from_expr (gfc_expr *e, gfc_namespace *ns)
> tmp->n.sym->attr.dimension = 0;
>
> + gfc_commit_symbol (tmp->n.sym);
>gfc_set_sym_referenced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57367
--- Comment #1 from Marc Glisse ---
This is all dead code, gcc discards it before it looks at possible issues.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57367
Bug ID: 57367
Summary: Missing warning: array subscript is above array bounds
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56754
Duncan Sands changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56754
--- Comment #7 from Duncan Sands ---
2013-05-21 Magnus Granberg
PR plugins/56754
* Makefile.in (PLUGIN_HEADERS): Add TARGET_H
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366
Rainer Orth changed:
What|Removed |Added
Target Milestone|--- |4.9.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57366
Bug ID: 57366
Summary: gcc.dg/lto/attr-weakref-1 FAILs
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57349
Richard Biener changed:
What|Removed |Added
Blocks||56982
--- Comment #3 from Richard Biener
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57211
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57364
--- Comment #2 from Tobias Burnus ---
Draft patch:
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -9299,4 +9299,5 @@ get_temp_from_expr (gfc_expr *e, gfc_namespace *ns)
tmp->n.sym->attr.dimension = 0;
+ gfc_commit_symbol (tmp->
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46897
--- Comment #12 from Tobias Burnus ---
(In reply to Tobias Burnus from comment #11)
> Draft patch:
That patch should have gone to PR57364. However, it is related as it fixes a
regression caused by a commit for this PR, namely be the one in commen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46897
--- Comment #11 from Tobias Burnus ---
Draft patch:
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -9299,4 +9299,5 @@ get_temp_from_expr (gfc_expr *e, gfc_namespace *ns)
tmp->n.sym->attr.dimension = 0;
+ gfc_commit_symbol (tmp-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48858
--- Comment #18 from Tobias Burnus ---
Actually, a future gfortran patch might again disable the support for the code
in comment 0 (original bug report) by doing interface checks.
That's not only in line with my interpretation of the standard but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57361
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57364
Tobias Burnus changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
--- Comment #1 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31397
Michal Malecki changed:
What|Removed |Added
CC||ethouris at gmail dot com
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57362
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57364
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
1 - 100 of 104 matches
Mail list logo
