http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51632
Tobias Burnus changed:
What|Removed |Added
Known to fail||4.6.3, 4.7.0
--- Comment #1 from Tobias B
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51633
Bug #: 51633
Summary: [c++0x] [4.6/4.7 Regression] ICE with invalid
constexpr constructor
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51633
Volker Reichelt changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Target Milestone|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51634
Bug #: 51634
Summary: [OOP] ICE with polymorphic operators
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Se
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51630
--- Comment #2 from Jonathan Wakely 2011-12-20
08:57:19 UTC ---
the code fails for me using any of GCC 4.4, 4.5, 4.6 of 4.7
are you sure that's the actual code you're compiling?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51630
--- Comment #3 from Jonathan Wakely 2011-12-20
08:59:11 UTC ---
Ah, it's because you're using -fsyntax-only, so it doesn't instantiate
templates. Don't do that.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51365
--- Comment #14 from Jonathan Wakely 2011-12-20
09:09:56 UTC ---
Author: redi
Date: Tue Dec 20 09:09:50 2011
New Revision: 182523
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182523
Log:
PR libstdc++/51365
* include/std/tuple (_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437
--- Comment #17 from Mikael Pettersson 2011-12-20
09:14:03 UTC ---
Created attachment 26150
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26150
reduced second test case
Reduced test case, very sensitive to control flow and other details.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46796
--- Comment #10 from Richard Guenther 2011-12-20
09:49:22 UTC ---
Author: rguenth
Date: Tue Dec 20 09:49:17 2011
New Revision: 182524
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182524
Log:
2011-12-20 Richard Guenther
PR lto/46
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46796
Richard Guenther changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
Richard Guenther changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51624
Richard Guenther changed:
What|Removed |Added
Target Milestone|--- |4.6.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51630
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51633
--- Comment #1 from Paolo Carlini 2011-12-20
10:30:39 UTC ---
By the way, calling these issues "Regression" doesn't seem appropriate:
granted, 4.5 may have parsed some constrexpr usages, but didn't have any
semantics implemented, could very hardl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51612
--- Comment #2 from paolo at gcc dot gnu.org
2011-12-20 10:38:48 UTC ---
Author: paolo
Date: Tue Dec 20 10:38:44 2011
New Revision: 182526
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182526
Log:
/cp
2011-12-20 Paolo Carlini
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51612
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #5 from Eric Botcazou 2011-12-20
10:52:19 UTC ---
> The point is that even if you use sth like
>
> typedef int myint __attribute__((aligned(1)));
>
> to capture the misaligned pointer to the packed structure element:
>
> myint *p =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50518
--- Comment #1 from Paolo Carlini 2011-12-20
10:54:06 UTC ---
Any news on this?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50592
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41159
Richard Guenther changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41159
--- Comment #20 from Richard Guenther 2011-12-20
11:01:37 UTC ---
Created attachment 26151
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26151
patch
I'm testing this patch on x86_64-linux, but it won't make any difference there.
So can you
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #6 from rguenther at suse dot de
2011-12-20 11:04:37 UTC ---
On Tue, 20 Dec 2011, ebotcazou at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
>
> --- Comment #5 from Eric Botcazou 2011-12-20
> 10:52:19
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #7 from Eric Botcazou 2011-12-20
11:18:24 UTC ---
> Huh, it's not. It's the same as a packed struct or enum type.
No, it isn't, the mode is integral instead of BLKmode. In Ada we do support
misaligned integers, but we simply wrap t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51621
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51583
Martin Jambor changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #8 from rguenther at suse dot de
2011-12-20 11:23:48 UTC ---
On Tue, 20 Dec 2011, ebotcazou at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
>
> --- Comment #7 from Eric Botcazou 2011-12-20
> 11:18:24
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #9 from Eric Botcazou 2011-12-20
11:34:00 UTC ---
> You mean that handling the TYPE_ALIGN != MODE_ALIGN case when
> expanding a MEM_REF (thus, INDIRECT_REF on old branches) won't work?
But you cannot have TYPE_ALIGN < MODE_ALIGN (TYP
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #10 from rguenther at suse dot de
2011-12-20 11:56:22 UTC ---
On Tue, 20 Dec 2011, ebotcazou at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
>
> --- Comment #9 from Eric Botcazou 2011-12-20
> 11:34:00
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
Bug #: 51635
Summary: [4.7 regression] ICE in in dwarf2out_finish, at
dwarf2out.c:22494 when building Firefox's libxul
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
Richard Guenther changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #2 from Richard Guenther 2011-12-20
12:13:27 UTC ---
(gdb) call debug_tree (context)
type_common.name)
>
(gdb) call lookup_type_die (context)
$1 = (struct die_struct *) 0x758fdd70
(gdb) call debug_tree (node->created_for)
so
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #11 from Eric Botcazou 2011-12-20
12:25:13 UTC ---
> You can. Just check what you get with that aligned(1) int typedef.
Well, we're going in circles as this example precisely doesn't work.
> Is it documented anywhere that you can't
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41159
--- Comment #21 from Ryan Mansfield 2011-12-20
12:27:29 UTC ---
(In reply to comment #20)
> I'm testing this patch on x86_64-linux, but it won't make any difference
> there.
> So can you guys test on arm/alpha please and report back? Thx.
For
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51636
Bug #: 51636
Summary: Thread-safeness of new and delete operators
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priori
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51636
Ingo K. changed:
What|Removed |Added
Severity|normal |minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48189
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #13 from rguenther at suse dot de
2011-12-20 13:21:02 UTC ---
On Tue, 20 Dec 2011, ebotcazou at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
>
> --- Comment #11 from Eric Botcazou 2011-12-20
> 12:25:1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50518
--- Comment #2 from fabien at gcc dot gnu.org 2011-12-20 13:29:26 UTC ---
(In reply to comment #1)
> Any news on this?
No, sorry, I'll try to work on it before the end of stage 3.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951
--- Comment #11 from Dodji Seketeli 2011-12-20
13:36:08 UTC ---
Author: dodji
Date: Tue Dec 20 13:36:04 2011
New Revision: 182532
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182532
Log:
PR debug/49951 - jumpy stepping at end of scope i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951
Dodji Seketeli changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51637
Bug #: 51637
Summary: Add compile-time error if array is too large
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: diagnostic
S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951
--- Comment #13 from Jonathan Wakely 2011-12-20
13:49:28 UTC ---
Thanks! It would be very helpful to get this into 4.6.3 too if it's safe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #3 from Richard Guenther 2011-12-20
14:16:35 UTC ---
It's actually easy to do. We just have to make sure that the TYPE_DECLs we
refer to are those of their type. Thus,
Index: gcc/lto/lto.c
==
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388
Andreas Tobler changed:
What|Removed |Added
CC||andreast at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #4 from Richard Guenther 2011-12-20
14:47:25 UTC ---
Doesn't work. Instead testing a similar
Index: gcc/lto/lto.c
===
--- gcc/lto/lto.c (revision 182525)
+++ gcc/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437
--- Comment #18 from Mikael Pettersson 2011-12-20
15:14:41 UTC ---
The second test case started failing with r170199:
http://gcc.gnu.org/ml/gcc-cvs/2011-02/msg00744.html
This is the reversal of the same change that was later reapplied as r17
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51638
Bug #: 51638
Summary: gfortran optimization breaks a single variable used as
both input and output for subroutine call
Classification: Unclassified
Product: gcc
Version: fortran-
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #5 from Markus Trippelsdorf
2011-12-20 15:31:47 UTC ---
(In reply to comment #4)
> Doesn't work. Instead testing a similar
>
> Index: gcc/lto/lto.c
> ===
> --- gcc/lto/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #6 from rguenther at suse dot de
2011-12-20 15:38:16 UTC ---
On Tue, 20 Dec 2011, markus at trippelsdorf dot de wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
>
> --- Comment #5 from Markus Trippelsdorf
> 2011-12-20 15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #7 from rguenther at suse dot de
2011-12-20 15:40:01 UTC ---
On Tue, 20 Dec 2011, Richard Guenther wrote:
> On Tue, 20 Dec 2011, markus at trippelsdorf dot de wrote:
>
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
> >
> > -
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388
--- Comment #11 from Andreas Schwab 2011-12-20 15:48:28
UTC ---
Does this work?
diff --git a/config/warnings.m4 b/config/warnings.m4
index 292e5a4..b64b594 100644
--- a/config/warnings.m4
+++ b/config/warnings.m4
@@ -32,7 +32,7 @@ for real_optio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51388
--- Comment #12 from Andreas Tobler 2011-12-20
15:57:36 UTC ---
Seems to work. At least in stage one, compiling gcc.
Thank you!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51639
Bug #: 51639
Summary: Nested type pointer null initialisation fails
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Prio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51639
--- Comment #1 from Dominique d'Humieres 2011-12-20
16:27:46 UTC ---
This seems to have been fixed on trunk between revisions 181881 (valgrind
error) and 182076 (OK).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51640
Bug #: 51640
Summary: Misleading error if the type in the catch() is
ambiguous
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51640
--- Comment #1 from petschy at gmail dot com 2011-12-20 16:49:02 UTC ---
Created attachment 26155
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26155
a slightly more verbose test case
Extended test case with ambiguous type name in variable d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51639
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
Target Milest
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51640
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Status|UNCONFIRM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51472
Aldy Hernandez changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot |aldyh at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51641
Bug #: 51641
Summary: Lookup finds enclosing class member instead of
template parameter
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51037
Marc Glisse changed:
What|Removed |Added
CC||marc.glisse at normalesup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51639
--- Comment #2 from Dominique d'Humieres 2011-12-20
17:13:31 UTC ---
Tobias,
Do you have a 4.6.3 build after r182062 (p51435)? If yes, could you check its
behavior for this pr? TIA.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51638
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51622
--- Comment #9 from Domingo Alvarez 2011-12-20
17:30:55 UTC ---
Some mistakes corrected and it was compiled with mingw 4.6.1 and wotk as
expected.
The results:
lua 5.1.4 with _Decimal64 from 2.4MB to 681KB
sqlite3 with _Decimal64 from 3MB to 1.2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51642
Bug #: 51642
Summary: Weak variable reference triggers ICE with -flto option
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51639
Tobias Burnus changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51628
--- Comment #14 from Eric Botcazou 2011-12-20
17:43:07 UTC ---
> What Ada does looks just like a workaround for what should be done properly in
> the expander. So no, IMHO we shouldn't be changing all other FEs and the
> middle-end (when it want
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51638
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Co
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51435
Tobias Burnus changed:
What|Removed |Added
CC||jonathan.hogg at stfc dot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51635
--- Comment #8 from Markus Trippelsdorf
2011-12-20 18:06:34 UTC ---
(In reply to comment #7)
> On Tue, 20 Dec 2011, Richard Guenther wrote:
> > > This one is extremely slow. lto1 has already used 12min of CPU time when
> > > linking libxul and is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19185
Jason Merrill changed:
What|Removed |Added
Status|NEW |WAITING
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19185
John David Anglin changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51636
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51630
Robert Ramey changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #5 from Robert Ramey 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
Bug #: 51643
Summary: Incorrect code produced for tail-call of weak function
with -O2/-O3 option
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
Andrew Pinski changed:
What|Removed |Added
Target|arm-eabi|
Component|rtl-optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
--- Comment #2 from Andrew Pinski 2011-12-20
21:27:15 UTC ---
Also the linker seems funny to replace a branch to null with a nop.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49865
--- Comment #7 from Vladimir Makarov 2011-12-20
21:29:40 UTC ---
Author: vmakarov
Date: Tue Dec 20 21:29:36 2011
New Revision: 182553
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182553
Log:
2011-12-20 Vladimir Makarov
PR target
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.kratoch...@redhat.com
PASS: gcc (GCC) 4.6.3 20111220 (prerelease)
FAIL: gcc (GCC) 4.7.0 20111220 (experimental)
#include
extern
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42839
rsand...@gcc.gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
--- Comment #3 from Alexander Osipenko 2011-12-20
21:39:11 UTC ---
This behavior is explicitly defined in ARM RealView compiler, and GCC seems try
to follow this convention.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39586
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
--- Comment #4 from Alexander Osipenko 2011-12-20
21:58:39 UTC ---
>From ARM EABI specification (doc: ARM IHI 0044A)
"On platforms that do not support dynamic pre-emption of symbols an unresolved
weak reference to a symbol relocated by R_ARM_CAL
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51645
Bug #: 51645
Summary: FAIL: g++.dg/cpp0x/alias-decl-debug-0.C (test for
excess errors)
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
--- Comment #5 from joseph at codesourcery dot com 2011-12-20 22:34:43 UTC ---
On Tue, 20 Dec 2011, sipych at gmail dot com wrote:
> "On platforms that do not support dynamic pre-emption of symbols an unresolved
> weak reference to a symbol reloc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43437
Mikael Pettersson changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
--- Comment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
--- Comment #6 from Alexander Osipenko 2011-12-20
23:33:06 UTC ---
It seems reasonable to expect minimal consistency, either generating invalid
(zero for example) reference for any direct weak function call, better marking
it with "warning" or ev
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51621
--- Comment #2 from paolo at gcc dot gnu.org
2011-12-20 23:51:13 UTC ---
Author: paolo
Date: Tue Dec 20 23:51:09 2011
New Revision: 182556
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182556
Log:
/cp
2011-12-20 Paolo Carlini
PR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51621
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51305
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51200
Bernd Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951
--- Comment #14 from asmwarrior 2011-12-21
03:21:07 UTC ---
Thanks for fix this bug, I hope some devs will backport this patch to 4.5/4.6
branches.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43491
--- Comment #4 from amker.cheng 2011-12-21
03:44:03 UTC ---
This bug is even worse on mips.
The cause is ssa-pre eliminates global register variable when it is the RHS of
single assign statment, while following passes do not handle the const/reg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51200
Joey Ye changed:
What|Removed |Added
Status|RESOLVED|VERIFIED
--- Comment #4 from Joey Ye 2011-12-2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51552
--- Comment #2 from Jie Zhang 2011-12-21 04:35:19 UTC
---
(gdb) p insn
$23 = (rtx) 0x7701b180
(gdb) pr
(parallel [
(unspec [
(const_int -4 [0xfffc])
] 5)
(set/f (mem:SI (plus:SI (reg/f:S
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51630
--- Comment #6 from Jonathan Wakely 2011-12-21
05:08:32 UTC ---
The syntax of your example was OK, so -fsyntax-only doesn't give errors. If
-fsyntax-errors only isn't what you're looking for, don't use it. It's not
clear what you're asking for,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51630
Robert Ramey changed:
What|Removed |Added
Resolution|INVALID |WONTFIX
--- Comment #7 from Robert Ramey
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41159
--- Comment #22 from Uros Bizjak 2011-12-21 07:21:38
UTC ---
Hardly to believe, but alpha finished --with-build-config=bootstrap-lto build,
with lto crippled by the following patch:
Index: lto-wrapper.c
==
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43491
Uros Bizjak changed:
What|Removed |Added
Component|rtl-optimization|tree-optimization
Known to fail|
100 matches
Mail list logo
