http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8081
Eric Botcazou changed:
What|Removed |Added
CC||ebotcazou at gcc dot
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51844
Bug #: 51844
Summary: [4.7 regression] configuring with
--with-gxx-include-dir= adds a relative
(non-existing) C++ include dir
Classification: Unclassified
Product: gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48308
--- Comment #19 from Ramana Radhakrishnan
2012-01-13 09:07:48 UTC ---
(In reply to comment #14)
> Note, can't be reproduced on the trunk, the strcmp isn't DCEd there, but guess
> the problem is just latent there.
Latent still in trunk with the t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8081
--- Comment #26 from rguenther at suse dot de
2012-01-13 09:08:30 UTC ---
On Fri, 13 Jan 2012, ebotcazou at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8081
>
> Eric Botcazou changed:
>
>What|Removed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51845
Bug #: 51845
Summary: [4.6 regression]
23_containers/unordered_multimap/erase/24061-multimap.
cc segfault
Classification: Unclassified
Product: gcc
Version: 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
--- Comment #31 from Richard Guenther 2012-01-13
09:26:45 UTC ---
Ok, so the following patch makes
extern __inline __attribute__ ((__always_inline__))
void open ()
{
}
void bar ()
{
open ();
}
void open ()
{
open ();
}
"work" as in the exte
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842
Tobias Burnus changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842
--- Comment #4 from Tobias Burnus 2012-01-13
09:28:51 UTC ---
Sorry for the double commit - but I somehow midair collision didn't work as
expected.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842
--- Comment #2 from Tobias Burnus 2012-01-13
09:27:16 UTC ---
(In reply to comment #0)
> /* The type used of array indices, amongst other things. */
> typedef ssize_t index_type;
I just saw that GCC 4.7 uses now:
typedef ptrdiff_t index_typ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51845
Richard Guenther changed:
What|Removed |Added
Target Milestone|--- |4.7.0
Summary|[4.6 regressi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51840
Richard Guenther changed:
What|Removed |Added
Component|tree-optimization |c
Summary|asm goto incorrec
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51843
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51844
Richard Guenther changed:
What|Removed |Added
Version|4.6.2 |4.7.0
Target Milestone|---
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8081
--- Comment #27 from Richard Guenther 2012-01-13
10:11:43 UTC ---
(In reply to comment #26)
> On Fri, 13 Jan 2012, ebotcazou at gcc dot gnu.org wrote:
>
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8081
> >
> > Eric Botcazou changed:
> >
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842
--- Comment #5 from Janne Blomqvist 2012-01-13 10:19:02
UTC ---
(In reply to comment #3)
> (In reply to comment #0)
> > /* The type used of array indices, amongst other things. */
> > typedef ssize_t index_type;
>
> I just saw that GCC 4.7 uses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-01-13 10:25:34 UTC ---
I've done some more digging and found that the EINVAL error is generated
inside libpthread.so, by a function called __thdIsAddrInStack. And in
fact, if I make M m
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842
--- Comment #6 from Tobias Burnus 2012-01-13
10:34:01 UTC ---
(In reply to comment #5)
> Yes, and no. It is perhaps a better match for the current frontend logic of
> choosing a type equal to the pointer size, but semantically ptrdiff_t is the
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51296
--- Comment #25 from Jonathan Wakely 2012-01-13
10:37:52 UTC ---
Nice digging. POSIX does say the INIT macro is for use when the mutex is
statically-allocated:
"In cases where default mutex attributes are appropriate, the macro
PTHREAD_MUTEX_IN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51845
Paolo Carlini changed:
What|Removed |Added
Priority|P3 |P1
--- Comment #2 from Paolo Carlini 201
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36758
Richard Guenther changed:
What|Removed |Added
Known to work||4.7.0
Summary|[4.4/4.5/4.6/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8081
--- Comment #28 from Eric Botcazou 2012-01-13
11:21:34 UTC ---
> OTOH as GIMPLE cannot deal with VLAs on the LHS of a CALL when not applying
> RSO
> the above is correct anyway.
Right, gimplify_return_expr already has a similar provision:
els
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51845
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842
--- Comment #7 from Janne Blomqvist 2012-01-13 11:44:05
UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> > Yes, and no. It is perhaps a better match for the current frontend logic of
> > choosing a type equal to the pointer size, but
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8081
Richard Guenther changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51813
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50313
Ramana Radhakrishnan changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51829
--- Comment #3 from Paolo Carlini 2012-01-13
12:04:02 UTC ---
Please do your best to distill a testcase of manageable size, a few KBs at
most: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51846
Bug #: 51846
Summary: Compiled programs suffer from infinite recursion when
using -finstrument-functions with optimizations
Classification: Unclassified
Product: gcc
Version: 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8081
--- Comment #30 from Richard Guenther 2012-01-13
12:05:32 UTC ---
Author: rguenth
Date: Fri Jan 13 12:05:27 2012
New Revision: 183153
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183153
Log:
2012-01-13 Richard Guenther
PR middle-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8081
Richard Guenther changed:
What|Removed |Added
Keywords|accepts-invalid,|
|ice-on-invalid-code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50313
--- Comment #4 from Ramana Radhakrishnan 2012-01-13
12:06:33 UTC ---
Created attachment 26314
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26314
smaller testcase
Better reduced testcase. Fails on trunk with -Os -fPIC -mcpu=arm9tdmi or -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51846
--- Comment #1 from Daniel Willmann
2012-01-13 12:20:25 UTC ---
Here's my gcc version, I noticed that Debian's GCC (tested gcc-4.53-10 as well
as gcc-4.6.2-11) works as expected.
alphaone@adrastea ~ $ gcc --version -v
Using built-in specs.
COLLE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51845
--- Comment #4 from Andreas Krebbel 2012-01-13
12:41:55 UTC ---
For s390 the first failing release was r181677.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51845
--- Comment #5 from Andreas Krebbel 2012-01-13
12:42:42 UTC ---
Yes Valgrind has S/390 support since release 3.7.0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38813
Salvatore Filippone changed:
What|Removed |Added
CC||sfilippone at uniroma2 dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38813
--- Comment #7 from Salvatore Filippone
2012-01-13 12:48:13 UTC ---
(In reply to comment #6)
And the example that still fails:
--
module foo_mod
type foo_type
integer, allocatable :: idx(:)
end type foo_type
end module foo_mod
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51845
--- Comment #6 from Paolo Carlini 2012-01-13
12:56:03 UTC ---
Andreas, can you run the test under valgrind? Thanks in advance.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51847
Bug #: 51847
Summary: incorrect primitive array initialization in generic
methods
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51845
--- Comment #7 from Andreas Krebbel 2012-01-13
13:07:52 UTC ---
(In reply to comment #6)
> Andreas, can you run the test under valgrind? Thanks in advance.
I should better have mentioned that Valgrind on S/390 doesn't support 32 bit
code yet :(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51848
Bug #: 51848
Summary: GCC is not able to vectorize when a constant value is
also added to the sum of array expression inside a
loop.
Classification: Unclassified
Product
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51709
Ramana Radhakrishnan changed:
What|Removed |Added
Keywords||missed-optimization
St
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842
--- Comment #8 from Tobias Burnus 2012-01-13
15:41:19 UTC ---
Author: burnus
Date: Fri Jan 13 15:41:13 2012
New Revision: 183154
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183154
Log:
2012-01-13 Tobias Burnus
PR fortran/51
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51620
--- Comment #2 from Jason Merrill 2012-01-13
15:49:35 UTC ---
Author: jason
Date: Fri Jan 13 15:49:29 2012
New Revision: 183155
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183155
Log:
PR c++/51620
* class.c (build_vtbl_initiali
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51620
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51813
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51374
--- Comment #7 from Georg-Johann Lay 2012-01-13
15:58:10 UTC ---
Created attachment 26316
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26316
pr51374.diff (tentative patch against 4.7)
* combine.c (record_dead_and_set_regs_1): Update
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51848
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51374
Georg-Johann Lay changed:
What|Removed |Added
Keywords||patch
--- Comment #8 from Georg-Johann
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51225
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51813
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|NEW
Component|c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51813
--- Comment #4 from Paolo Carlini 2012-01-13
16:24:07 UTC ---
Eh, thanks for the analysis. Is there some sort of conservative option here? I
don't think we want to take risks at this stage only for the sake of hiding a
few more symbols ws 4.6. Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39055
--- Comment #17 from Jason Merrill 2012-01-13
16:41:08 UTC ---
Pinged again about creating a core issue for this.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51813
--- Comment #5 from Jonathan Wakely 2012-01-13
16:43:12 UTC ---
(In reply to comment #3)
> What do we want to do about C library visibility?
We can't redeclare all the types with default visibility, because we don't know
if e.g. mbstate_t is jus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51813
--- Comment #6 from Paolo Carlini 2012-01-13
16:46:56 UTC ---
Thanks for your help Jon. Note the issue isn't just about std::use_facet, is
about std::codecvt too, any type we instantiate with mbstate_t.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51813
--- Comment #7 from Jason Merrill 2012-01-13
16:52:41 UTC ---
The right answer would seem to be wrapping includes of C headers in #pragma GCC
visibility push/pop, like many of the libsupc++ headers do. But I'm not sure
why the compiler wants to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51813
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Component|libstdc++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51845
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #8 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842
--- Comment #9 from mrs at gcc dot gnu.org 2012-01-13
17:23:37 UTC ---
The last fix looks perfect, thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51849
Bug #: 51849
Summary: -Wc99-compat would be considered useful
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Prior
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51850
Bug #: 51850
Summary: debug mode for std::array and tr1::array
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: enhancement
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51813
--- Comment #9 from Jason Merrill 2012-01-13
17:51:04 UTC ---
Author: jason
Date: Fri Jan 13 17:50:58 2012
New Revision: 183156
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183156
Log:
PR c++/51813
* decl2.c (constrain_visibilit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51813
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51616
Steven Bosscher changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51709
--- Comment #5 from John A. Van Boxtel 2012-01-13
18:39:43 UTC ---
Sorry about not understanding CS vs GNU release numbering and time
relationship. I now understand that CS versions may precede introduction into
the GNC source. I will also try
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51832
--- Comment #6 from Jason Merrill 2012-01-13
18:55:24 UTC ---
I still can't reproduce this on x86_64-pc-linux-gnu. I notice that you have a
lot of configure flags in your gcc -v output; mine is just
/home/jason/src/trunk/configure -v --with-mpf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39055
Jason Merrill changed:
What|Removed |Added
Keywords|ice-on-invalid-code |
Target Milestone|4.4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51851
Bug #: 51851
Summary: Overriding a function with a parameter of dependent
type fails to override.
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20681
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51851
--- Comment #1 from Ville Voutilainen
2012-01-13 19:13:13 UTC ---
Johannes Schaub says "in both situations the question is whether the parameter
type adjustments happen immediately or after instantiation (when T is replaced
by the actual type)",
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51842
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20681
--- Comment #34 from Jason Merrill 2012-01-13
20:06:25 UTC ---
Author: jason
Date: Fri Jan 13 20:06:16 2012
New Revision: 183161
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183161
Log:
PR c++/20681
* semantics.c (finish_break_s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20681
Jason Merrill changed:
What|Removed |Added
Known to work||4.7.0
Summary|[4.4/4.5/4.6/4.7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51844
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=12245
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Known to fa
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852
Bug #: 51852
Summary: [regression] [c++11] tree check: expected tree_list,
have HßèMÕþÿøtxøtsø
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40778
Steven Bosscher changed:
What|Removed |Added
Status|NEW |WAITING
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51852
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51845
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Target|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179
Jason Merrill changed:
What|Removed |Added
Status|ASSIGNED|NEW
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #30 from Jakub Jelinek 2012-01-13
20:36:16 UTC ---
PR51471 patch has been committed by now, can you recheck if it didn't fix also
this PR?
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183038
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48351
--- Comment #4 from Paul Thomas 2012-01-13 20:42:07
UTC ---
Author: pault
Date: Fri Jan 13 20:42:01 2012
New Revision: 183162
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183162
Log:
2012-01-13 Paul Thomas
PR fortran/48351
*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51851
Jason Merrill changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51853
Bug #: 51853
Summary: MPFR assertion failure with Python: p >= 2 && p <=
((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
Classification: Unclassified
Product: gcc
Version: 4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51808
Janne Blomqvist changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
URL|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48351
--- Comment #5 from Tobias Burnus 2012-01-13
21:14:42 UTC ---
FIXED on the trunk (4.7).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51733
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48351
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51832
--- Comment #7 from Markus Trippelsdorf
2012-01-13 21:25:48 UTC ---
(In reply to comment #6)
> I still can't reproduce this on x86_64-pc-linux-gnu. I notice that you have a
> lot of configure flags in your gcc -v output; mine is just
>
> /home/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179
Jason Merrill changed:
What|Removed |Added
Attachment #5763|0 |1
is obsolete|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14179
--- Comment #62 from Jason Merrill 2012-01-13
22:08:38 UTC ---
(In reply to comment #61)
> 4.7 14s 1704M (r183161, optimized, --enable-checking=release)
Making the change to convert_to_integer mentioned in 12245 reduces VM size to
1509M; there
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36545
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41356
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51634
--- Comment #2 from Tobias Burnus 2012-01-13
22:17:53 UTC ---
(In reply to comment #1)
> Fixed on trunk as long as explicit allocations are inserted, as below.
> I will raise a separate PR for the lack of automatic allocate on assign for
> class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26219
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22210
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|NEW
AssignedTo|pinskia at gcc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51854
Bug #: 51854
Summary: ICE in mangle.c with literal of complex floating type
Classification: Unclassified
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26894
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51854
Andrew Pinski changed:
What|Removed |Added
Target|powerpc64-unknown-linux-gnu |
Status|UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18589
William J. Schmidt changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassign
1 - 100 of 136 matches
Mail list logo
