http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50350
--- Comment #4 from Matthias Klose 2011-10-13
06:21:36 UTC ---
still seen on the 4.6 branch with 20111012
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50705
--- Comment #3 from SK 2011-10-13 05:41:20
UTC ---
Created attachment 25481
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25481
system map, objdump, source code
As the earlier file was 14MB with large objdump.I have copied the code around
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50697
trevor at corevx dot com changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50697
--- Comment #2 from trevor at corevx dot com 2011-10-13 05:38:40 UTC ---
(In reply to comment #1)
> Why not just use --with-gmp=/swadm/local ?
right .. thank you, that worked nicely.
sorry for the noise.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50712
Bug #: 50712
Summary: [4.7 regression] invalid argument to gimple call
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50711
--- Comment #3 from Jarryd Beck 2011-10-13
03:32:05 UTC ---
The following code works:
struct Tuple
{
int a, b, c;
};
struct array_get
{
template
const T&
operator()(const T& t)
{
return t;
}
template
auto
operator()(con
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38174
--- Comment #4 from Jason Merrill 2011-10-13
02:49:30 UTC ---
(In reply to comment #3)
> So, for operator== for example, we reach the end of add_builtin_candidate, the
> conditional is true, and we proceed with two calls to build_builtin_candidat
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50711
--- Comment #2 from Paolo Carlini 2011-10-13
02:19:27 UTC ---
Eg, if you simply open the header you will find plenty of
decltype( std::declval... for sfinae, which cannot be replaced by a concise
std::result_of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50711
Paolo Carlini changed:
What|Removed |Added
CC||daniel.kruegler at
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50711
Bug #: 50711
Summary: [C++0x] substitution failure reports error with
result_of
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17212
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|gcc-bugs at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50710
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50710
Bug #: 50710
Summary: ambiguity problem between bool() and string()
operators, when used on a string that's a class member
Classification: Unclassified
Product: gcc
Version: 4.6.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #28 from Eric Botcazou 2011-10-12
22:54:57 UTC ---
> OK. well libgcc_s or libSystem contains the unwinder, depending on whether
> it's darwin9 or darwin10 (and assuming that there's no insertion caused by a
> DYLD_LIBRARY_PATH). I'l
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #27 from Iain Sandoe 2011-10-12 22:48:18
UTC ---
(In reply to comment #26)
> > reproducible (using gdb 7.1) on darwin9 @ m64 (m32 is OK on D9 and D10) -
> > - so where are we looking for a problem- in the m64 libgcc_s unwinder - or
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50709
Bug #: 50709
Summary: stage3 bootstrap comparison fail on x86_64 with
--disable-checking config option
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38174
--- Comment #3 from Paolo Carlini 2011-10-12
22:14:03 UTC ---
So, for operator== for example, we reach the end of add_builtin_candidate, the
conditional is true, and we proceed with two calls to build_builtin_candidate
for pairs of const int* and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50684
--- Comment #8 from janus at gcc dot gnu.org 2011-10-12 22:07:01 UTC ---
(In reply to comment #7)
> > The following (equivalent) variant is at least rejected by gfortran 4.5 on
> > upwards:
> >
> > TYPE MY_TYPE
> > INTEGER, ALLOCATABLE :: VA
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50684
--- Comment #7 from Tobias Burnus 2011-10-12
21:53:28 UTC ---
(In reply to comment #5)
> I can't give any hard evidence right now, but naively I would say it should
> indeed be rejected. Shouldn't the allocation status of the components be
> prot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50684
--- Comment #6 from Tobias Burnus 2011-10-12
21:42:02 UTC ---
(In reply to comment #4)
> But should it be rejected? move_alloc does not modify the association
> status of "dt" - just of "dt%VALUE". Thus, I believe this test case is
> valid and, h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38174
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50153
Steve Ellcey changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29148
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|gcc-bugs at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38174
Paolo Carlini changed:
What|Removed |Added
CC||andrew.stubbs at st dot com
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50684
--- Comment #5 from janus at gcc dot gnu.org 2011-10-12 21:17:58 UTC ---
(In reply to comment #4)
> > This was rejected before, and still is with my patch.
>
> But should it be rejected? move_alloc does not modify the association status
> of
> "d
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #26 from Eric Botcazou 2011-10-12
20:55:31 UTC ---
> reproducible (using gdb 7.1) on darwin9 @ m64 (m32 is OK on D9 and D10) -
> - so where are we looking for a problem- in the m64 libgcc_s unwinder - or in
> the ada handers? .. or i
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50684
Tobias Burnus changed:
What|Removed |Added
Target Milestone|--- |4.6.2
--- Comment #4 from Tobias Burnus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50684
--- Comment #3 from janus at gcc dot gnu.org 2011-10-12 20:44:27 UTC ---
(In reply to comment #1)
>
> That won't work for:
>
> type(t), intent(in) :: dt
> call move_alloc(dt%allocatable, ...)
>
> That's invalid as dt%allocatable is intent(in);
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50684
janus at gcc dot gnu.org changed:
What|Removed |Added
Summary|Incorrect error for |[4.6/4.7 Regression]
ec in do_compile () at
/home/ryan/gnu/gcc/trunk/arm-oabi/../gcc/toplev.c:1925
#218 0x086eb069 in toplev_main (argc=125, argv=0xbfdbc134) at
/home/ryan/gnu/gcc/trunk/arm-oabi/../gcc/toplev.c:2001
#219 0x081d9e9a in main (argc=Cannot access memory at address 0x8000
This happens in:
gcc version 4.7.0 201
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #25 from Iain Sandoe 2011-10-12 20:07:28
UTC ---
passes at -O0 on darwin9 and 10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50707
Bug #: 50707
Summary: [C++0x] Non-static const data member initializer
breaks default constructor
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49740
--- Comment #5 from Douglas Mencken 2011-10-12
20:03:14 UTC ---
(In reply to comment #4)
Yep, it's still broken (gcc-4.7-20111008).
Configure line:
./gcc-v4.7-20111008.sourcedir/configure --prefix=/usr --sysconfdir=/etc
--mandir=/usr/share/man
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #24 from Iain Sandoe 2011-10-12 19:57:15
UTC ---
reproducible (using gdb 7.1) on darwin9 @ m64 (m32 is OK on D9 and D10) -
- so where are we looking for a problem- in the m64 libgcc_s unwinder - or in
the ada handers? .. or in libSys
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50684
--- Comment #1 from janus at gcc dot gnu.org 2011-10-12 19:52:57 UTC ---
Some carryover form PR50570, where I proposed a draft patch:
Index: gcc/fortran/check.c
===
--- gcc/fortran/ch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27100
Paolo Carlini changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|FIXED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27100
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|gcc-bugs at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26654
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|gcc-bugs at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50350
--- Comment #3 from Matthias Klose 2011-10-12
19:16:01 UTC ---
I'll check, however I don't see the fix for 50326 applied to the 4.6 branch.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50659
--- Comment #13 from janus at gcc dot gnu.org 2011-10-12 18:53:59 UTC ---
Author: janus
Date: Wed Oct 12 18:53:55 2011
New Revision: 179864
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179864
Log:
2011-10-12 Janus Weil
PR fortran/
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50594
--- Comment #23 from paolo at gcc dot gnu.org
2011-10-12 18:41:03 UTC ---
Author: paolo
Date: Wed Oct 12 18:40:58 2011
New Revision: 179863
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179863
Log:
2011-10-12 Paolo Carlini
PR c++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50350
Steve Ellcey changed:
What|Removed |Added
CC||sje at cup dot hp.com
--- Comment #2 from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49967
Steve Ellcey changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49967
--- Comment #3 from Steve Ellcey 2011-10-12 18:07:29
UTC ---
Author: sje
Date: Wed Oct 12 18:07:25 2011
New Revision: 179862
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179862
Log:
2011-10-12 Steve Ellcey
PR target/49967
Ba
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #23 from Eric Botcazou 2011-10-12
18:04:00 UTC ---
It turns out that Tom's patch is innocent, you can reproduce the problem at the
preceding revision if you compiled at -O1 instead of -O2.
This appears to be a problem in the signal u
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50704
--- Comment #8 from H.J. Lu 2011-10-12 17:58:19
UTC ---
(In reply to comment #7)
>
> I need to make sure that UNITS_PER_WORD is 8 on the architecture I am running
> the test. Is it the case for x32?
>
Yes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50704
--- Comment #7 from Artem Shinkarov 2011-10-12
17:45:14 UTC ---
(In reply to comment #6)
> (In reply to comment #5)
> >
> > So if I want to run the test only on 64-bit architectures, then lp64 is the
> > correct choice in dg-require-effective-ta
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50695
--- Comment #11 from rickyrockrat 2011-10-12
17:40:25 UTC ---
Richard,
The original issue involved strtof, with -Wall enabled in the Makefile, and
stdlib.h included. That is the case that brought all this up, and that is the
case where it prints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50704
--- Comment #6 from H.J. Lu 2011-10-12 17:36:05
UTC ---
(In reply to comment #5)
>
> So if I want to run the test only on 64-bit architectures, then lp64 is the
> correct choice in dg-require-effective-target?
>
> Artem.
x32 also has 64bit reg
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35606
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36812
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|gcc-bugs at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50705
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Component|c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50699
--- Comment #2 from Iain Sandoe 2011-10-12 17:21:37
UTC ---
(In reply to comment #1)
> Looks like a minor oversight in r179820.
>
> I am testing the following on *-darwin9.
allows bootstrap to complete on *-darwin9 and x86_64-dariwn10.
reg-test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835
Mikael Pettersson changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comme
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50706
--- Comment #2 from Dmitry Gorbachev
2011-10-12 17:10:51 UTC ---
Created attachment 25477
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25477
Backtrace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50706
--- Comment #1 from Dmitry Gorbachev
2011-10-12 17:10:15 UTC ---
Created attachment 25476
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25476
Small testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50706
Bug #: 50706
Summary: Fold check failed (expected tree that contains 'typed'
structure, have 'block' in fold_checksum_tree, at
fold-const.c:13921)
Classification: Unclassified
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40695
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
CC|gcc-bugs at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50704
--- Comment #5 from Artem Shinkarov 2011-10-12
17:03:46 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > Ah! It happens because the underlying architecture is 32-bit. We should
> > > run
> > > these
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50704
--- Comment #3 from H.J. Lu 2011-10-12 17:00:54
UTC ---
(In reply to comment #2)
> Ah! It happens because the underlying architecture is 32-bit. We should run
> these tests only on 64-bit architectures to get the correct warnings. So I'll
> add
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40825
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|gcc-bugs at g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50704
--- Comment #4 from H.J. Lu 2011-10-12 17:01:27
UTC ---
(In reply to comment #3)
> (In reply to comment #2)
> > Ah! It happens because the underlying architecture is 32-bit. We should run
> > these tests only on 64-bit architectures to get the c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50698
--- Comment #3 from vincenzo Innocente
2011-10-12 17:00:40 UTC ---
the patch work for me.
Does not seem to break anything else.
thanks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50704
Artem Shinkarov changed:
What|Removed |Added
CC||tema at gcc dot gnu.org
--- Comment #2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-10-12 16:53:32 UTC ---
> --- Comment #4 from Bernd Schmidt 2011-10-12
> 16:46:23 UTC ---
> This doesn't seem to happen with a cross compiler :(
Drats. I've run the reghunt natively.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #4 from Bernd Schmidt 2011-10-12
16:46:23 UTC ---
This doesn't seem to happen with a cross compiler :(
When you say "in stage 2", do you mean the stage 1 compiler is crashing, or the
stage 2 compiler is crashing?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50705
SK changed:
What|Removed |Added
URL||https://rapidshare.com/file
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49629
--- Comment #8 from Georg-Johann Lay 2011-10-12
16:27:34 UTC ---
For me it works, too. There are no ICEs any more for avr-unknown-none and the
test cases mentioned in comment #0.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48075
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48372
Paolo Carlini changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15339
Paolo Carlini changed:
What|Removed |Added
CC||jyasskin at gcc dot gnu.org
--- Comment #
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50364
Paolo Carlini changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50705
Bug #: 50705
Summary: Wrong assembly generated in ppc 476
Classification: Unclassified
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: blocker
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50239
Paolo Carlini changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50704
Dominique d'Humieres changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50703
Paolo Carlini changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50704
Bug #: 50704
Summary: FAIL: gcc.target/i386/warn-vect-op-1.c
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50686
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE 2011-10-12 15:37:46 UTC ---
> --- Comment #1 from Rainer Orth 2011-10-12 13:08:48
> UTC ---
> The reghunt is not yet complete, but the bad patch is between r179536 (good)
> and r179566 (bad)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50703
--- Comment #1 from hoenle2...@kayser-threde.com 2011-10-12 15:36:50 UTC ---
Created attachment 25475
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25475
debugger screenshot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50703
Bug #: 50703
Summary: std::stringstream not thread-safe
Classification: Unclassified
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49279
Michael Matz changed:
What|Removed |Added
CC||matz at gcc dot gnu.org
--- Comment #18 fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49629
--- Comment #7 from Pat Haugen 2011-10-12
15:19:54 UTC ---
No, I no longer see the failure on PowerPC, for the reduced testcase or the
full benchmark.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50693
--- Comment #22 from Richard Guenther 2011-10-12
15:19:54 UTC ---
Yeah, maybe we can just throw them away with -O3. Or decay them (on BB
merging) to
# DEBUG user_label:
that exposes the label to more code motion issues, so its location would b
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
--- Comment #16 from Richard Guenther 2011-10-12
15:16:17 UTC ---
Author: rguenth
Date: Wed Oct 12 15:16:14 2011
New Revision: 179857
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179857
Log:
2011-10-12 Paul Koning
PR tree-optimi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
Richard Guenther changed:
What|Removed |Added
Known to work||4.6.2
Summary|[4.5/4.6 Regr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
--- Comment #15 from Richard Guenther 2011-10-12
15:13:04 UTC ---
Author: rguenth
Date: Wed Oct 12 15:12:58 2011
New Revision: 179856
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=179856
Log:
2011-10-12 Paul Koning
PR tree-optimi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50419
--- Comment #2 from Michael Matz 2011-10-12 15:09:53
UTC ---
Meeh, since the fix for PR49279 we don't retain the casts to restrict anymore,
making the testcase not work even with the fix.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #22 from Iain Sandoe 2011-10-12 14:54:01
UTC ---
(In reply to comment #13)
> Would you please try and reproduce the failure with a Linux target? [Setting
> up Darwin GCC development environment (especially with GNAT in it) is a very
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50698
--- Comment #2 from Richard Guenther 2011-10-12
14:40:55 UTC ---
Patch:
Index: gcc/tree-data-ref.c
===
--- gcc/tree-data-ref.c (revision 179849)
+++ gcc/tree-data-ref.c (working cop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50702
Richard Guenther changed:
What|Removed |Added
CC||tom at codesourcery dot com
Target M
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50700
Richard Guenther changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
--- Comment #14 from rguenther at suse dot de
2011-10-12 14:21:48 UTC ---
On Wed, 12 Oct 2011, rguenther at suse dot de wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
>
> --- Comment #13 from rguenther at suse dot de
> 2011-10-12
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
--- Comment #13 from rguenther at suse dot de
2011-10-12 14:15:56 UTC ---
On Wed, 12 Oct 2011, pkoning at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
>
> --- Comment #12 from Paul Koning 2011-10-12
> 14:04:30 UT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50629
Ramana Radhakrishnan changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #21 from Iain Sandoe 2011-10-12 14:07:45
UTC ---
Created attachment 25474
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25474
optimized tree dump for c52104y
shows the builtin_alloca_with_align
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50702
--- Comment #1 from John David Anglin 2011-10-12
14:05:04 UTC ---
Also,
FAIL: gcc.c-torture/compile/nested-1.c -O1 (internal compiler error)
FAIL: gcc.c-torture/compile/nested-1.c -O1 (test for excess errors)
fail in same way.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50189
--- Comment #12 from Paul Koning 2011-10-12
14:04:30 UTC ---
You said "GCC treats types compatible when they have the same precision".
That's where the problem lies, because enums with -fstrict-enums have their
precision set to just enough bits
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50702
Bug #: 50702
Summary: [4.7 Regression] 20020210-1.c:2:22: ICE: gimple_op, at
gimple.h:1704. at -O1 and above
Classification: Unclassified
Product: gcc
Version: 4.7.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
--- Comment #20 from Iain Sandoe 2011-10-12 13:47:32
UTC ---
rax0x1010 268435472
rbx0x7fff5fbff380 140734799803264
rcx0x7fff5bc00380 140734732698496
rdx0x1000 268435456
rsi
1 - 100 of 132 matches
Mail list logo
