--- Comment #3 from xenofears at gmail dot com 2009-06-30 07:38 ---
I have now, in an attempt at a testcase, have found this bug to have further
implications. Trying to turn off mpc, ppl, and/or cloog has the same behavior,
i.e. --without-mpc causes:
gmpinc: '-I/no/include'
gmplibs: '-L
--- Comment #6 from carrot at google dot com 2009-06-30 07:42 ---
http://gcc.gnu.org/ml/gcc-cvs/2009-06/msg01067.html
--
carrot at google dot com changed:
What|Removed |Added
-
The fix for PR40551 made me realise that there are some assignment
optimizations that are missed:
integer :: array (3, 3), source (3, 3)
array = 0
array(:, 1) = 0 ! could use __builtin_memcpy
array(1,:) = 0
source = array ! uses __builtin_memcpy
source(:,1) = a
--- Comment #6 from bonzini at gnu dot org 2009-06-30 07:59 ---
Subject: Bug 40597
Author: bonzini
Date: Tue Jun 30 07:59:01 2009
New Revision: 149083
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149083
Log:
2009-06-30 Paolo Bonzini
PR boostrap/40597
* expm
--- Comment #7 from bonzini at gnu dot org 2009-06-30 07:59 ---
The bootstrap was successful on x86_64-linux, I'll look at the failures
tonight.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
--- Comment #4 from thomas dot orgis at awi dot de 2009-06-30 08:18 ---
Hm, the gfortran program _is_ installed with that script. I have the evidence
on my disk;-) It was created the same day the other current gcc/fortran files
have been installed.
Could it be a side-effect of building
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40416
--- Comment #7 from steven at gcc dot gnu dot org 2009-06-30 08:21 ---
Please adjust the test case:
/* { dg-options "-O2 -Os -fdump-tree-sink-stats" } */
This makes no sense, -Os implies -O2. So it should be:
/* { dg-options "-Os -fdump-tree-sink-stats" } */
--
http://gcc.gnu.or
--- Comment #4 from tg at mirbsd dot org 2009-06-30 08:44 ---
@Richard Guenther: the problem is that "-fwhole-program --combine"
works most of the time, but if it fails, there is no simple way to
detect it from a build script (by compiling a small test programme
with these options I can
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-06-30
09:18 ---
Created an attachment (id=18098)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18098&action=view)
Another testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40535
--- Comment #4 from jamborm at gcc dot gnu dot org 2009-06-30 09:34 ---
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg02214.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40554
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-06-30 09:35 ---
http://gcc.gnu.org/ml/gcc-patches/2009-06/msg02215.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40582
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-06-30 09:39 ---
I guess for zeroing you want memset, not memcpy. Note that in most of the
cases you should be able to use direct assignments from {} (to zero) or
the source. For selecting continuous ranges of an array you can use
--- Comment #2 from burnus at gcc dot gnu dot org 2009-06-30 09:46 ---
array(:,1) = 0
would then become
ARRAY_RANGE_REF = { }
and
array(:,1) = [1,2,3]
would then become
ARRAY_RANGE_REF = { 1,2,3 }
If I recall correctly, using memcopy/memset causes alias analysis problems as
--- Comment #1 from jwakely dot gcc at gmail dot com 2009-06-30 09:53
---
(In reply to comment #0)
> I'm trying to use SFINAE to disable overloads when a function call expression
> is invalid, which is needed to implement std::bind for C++0x
N.B. the use of an invalid expression in a s
--- Comment #3 from pault at gcc dot gnu dot org 2009-06-30 09:54 ---
(In reply to comment #1)
> I guess for zeroing you want memset, not memcpy. Note that in most of the
***blush*** - yes, you are right, of course!
> cases you should be able to use direct assignments from {} (to zero
--- Comment #4 from aph at gcc dot gnu dot org 2009-06-30 09:59 ---
Fixed by commit.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFI
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-06-30 10:03 ---
Subject: Bug 40554
Author: jamborm
Date: Tue Jun 30 10:03:26 2009
New Revision: 149087
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149087
Log:
2009-06-30 Martin Jambor
PR middle-end/40554
--- Comment #7 from jamborm at gcc dot gnu dot org 2009-06-30 10:10 ---
Subject: Bug 40582
Author: jamborm
Date: Tue Jun 30 10:10:29 2009
New Revision: 149088
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149088
Log:
2009-06-30 Martin Jambor
PR tree-optimization/405
--- Comment #2 from paolo dot carlini at oracle dot com 2009-06-30 10:11
---
Jon, are there any hopes for a temporary workaround for std::bind?
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
---
$ gcc -c -g -O -v pkg0017.adb
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.5-20090625/configure --prefix=/opt/gnat/fsf
--enable-languages=c,c++,ada --enable-debug
Thread model: posix
gcc version 4.5.0 20090625 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-c' '-g' '
--- Comment #12 from paolo dot carlini at oracle dot com 2009-06-30 10:32
---
Hi again. I just studied the glibc2.2.x documentation and I think a workaround
for those old glibcs is pretty simple, indeed use 1 << LC_CTYPE.
For the record, LC_CTYPE_MASK & co appeared in 2.3.0.
--
pa
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle
|dot org
--- Comment #1 from oliver dot kellogg at eads dot com 2009-06-30 10:34
---
Created an attachment (id=18099)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18099&action=view)
source files for reproducing the bug
Tried this with i686-linux-gnu and x86_64-linux-gnu and with various
--- Comment #13 from paolo at gcc dot gnu dot org 2009-06-30 10:46 ---
Subject: Bug 40511
Author: paolo
Date: Tue Jun 30 10:45:54 2009
New Revision: 149089
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149089
Log:
2009-06-30 Paolo Carlini
PR libstdc++/40511
--- Comment #14 from paolo dot carlini at oracle dot com 2009-06-30 10:47
---
Fixed.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
Stat
--- Comment #2 from oliver dot kellogg at eads dot com 2009-06-30 10:49
---
Does not happen with 4.5.0 trunk 20090406 and earlier versions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40599
--- Comment #3 from jwakely dot gcc at gmail dot com 2009-06-30 10:52
---
The basic problem is I've made std::result_of too good ;-)
My new result_of uses decltype to determine the exact result type of an
arbitrary function call, including resolving overloads based on whether the
calla
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-06-30 10:57 ---
My bet would be var-tracking. Can you try if -fno-var-tracking fixes this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40599
--- Comment #4 from oliver dot kellogg at eads dot com 2009-06-30 11:06
---
> My bet would be var-tracking. Can you try if -fno-var-tracking fixes this?
On the mark. Doesn't happen with -fno-var-tracking
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40599
25_algorithms/minmax/2.cc fails with -fno-inline because
std::pair z = std::minmax({1, 2, 3});
converts an rvalue to an lvalue:
std::initializer_list::initializer_list (&D.15746, &._65[0], 3);
D.15878 = minmax (D.15746);
std::pair::pair (&z, &D.15878);
std::pair<_T1, _T2>::pair(std::pai
--- Comment #4 from irar at gcc dot gnu dot org 2009-06-30 11:33 ---
Subject: Bug 40542
Author: irar
Date: Tue Jun 30 11:33:27 2009
New Revision: 149090
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149090
Log:
PR tree-optimization/40542
* tree-vect-stmts.c (ve
--- Comment #3 from steven at gcc dot gnu dot org 2009-06-30 11:35 ---
For this test case:
unsigned int code_in_ram[100];
void testme(void)
{
unsigned int *p_rom, *p_ram, *p_end, len;
extern unsigned int _ram_erase_sector_start;
extern unsigned int _ram_erase_sector_end;
p_ra
--- Comment #8 from jamborm at gcc dot gnu dot org 2009-06-30 11:39 ---
As you may have noticed, I changed the testcase a little bit so that
it ICEs as my i386 desktop too. A freshly checked out trunk no longer
does. So I believe this is indeed fixed.
--
jamborm at gcc dot gnu dot
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-06-30 11:44 ---
When compiled with a freshly checked-out trunk the testcase no longer
segfaults and gives exactly the same output as if compiled with trunk
revision 147978 (i.e. just before my new SRA got in). So I consider
thi
--- Comment #1 from paolo dot carlini at oracle dot com 2009-06-30 11:45
---
Yes, but N2914 is already fixed here. I'll implement it.
--
paolo dot carlini at oracle dot com changed:
What|Removed |Added
-
--- Comment #2 from paolo dot carlini at oracle dot com 2009-06-30 11:48
---
Actually, only the testcase is wrong, has not been updated to the
implementation, which now correctly returns a pair.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40600
--- Comment #5 from irar at gcc dot gnu dot org 2009-06-30 11:49 ---
Subject: Bug 40542
Author: irar
Date: Tue Jun 30 11:48:51 2009
New Revision: 149091
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149091
Log:
PR tree-optimization/40542
* tree-vect-analyze.c (
--- Comment #3 from rguenther at suse dot de 2009-06-30 11:49 ---
Subject: Re: pair& operator=(pair&& __p) doesn't work
without inlining
On Tue, 30 Jun 2009, paolo dot carlini at oracle dot com wrote:
> --- Comment #2 from paolo dot carlini at oracle dot com 2009-06-30 11:48
>
--- Comment #4 from paolo dot carlini at oracle dot com 2009-06-30 11:56
---
Maybe, but std::pair is heavily in flux for C++0x, let's deal with it
separately, after having reviewed the current WP and figured out what we can
conservatively implement in C++0x mode without concepts.
--
--- Comment #6 from irar at gcc dot gnu dot org 2009-06-30 11:56 ---
Subject: Bug 40542
Author: irar
Date: Tue Jun 30 11:56:21 2009
New Revision: 149092
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149092
Log:
PR tree-optimization/40542
* tree-vect-analyze.c (
--- Comment #5 from paolo dot carlini at oracle dot com 2009-06-30 11:58
---
To be clear, what I meant is already fixed in the WP is the return type of
std::minmax taking an initializer list (actually, I took care of the issue in
the Sophia C++ Meeting with help from Jason)
--
http
--- Comment #7 from irar at il dot ibm dot com 2009-06-30 12:02 ---
Fixed.
--
irar at il dot ibm dot com changed:
What|Removed |Added
Status|NEW
--- Comment #6 from jwakely dot gcc at gmail dot com 2009-06-30 12:05
---
Is Richard's original issue related to bug 34022?
Bug 40600 is caused by the differences between std::pair in gcc and the current
WP
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40600
--- Comment #7 from paolo at gcc dot gnu dot org 2009-06-30 12:10 ---
Subject: Bug 40600
Author: paolo
Date: Tue Jun 30 12:09:57 2009
New Revision: 149094
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149094
Log:
2009-06-30 Paolo Carlini
PR libstdc++/40600
*
--- Comment #8 from paolo at gcc dot gnu dot org 2009-06-30 12:10 ---
Subject: Bug 40600
Author: paolo
Date: Tue Jun 30 12:10:14 2009
New Revision: 149095
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149095
Log:
2009-06-30 Paolo Carlini
PR libstdc++/40600
*
--- Comment #10 from jwakely dot gcc at gmail dot com 2009-06-30 12:10
---
Dragan, http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#1054 tracks
the issue
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40486
--- Comment #9 from paolo dot carlini at oracle dot com 2009-06-30 12:13
---
The issue with the return type std::minmax is fixed, in case please open
separate PRs about pair. In any case, I recommend we are very careful with
pair, without concept support.
--
paolo dot carlini at ora
--- Comment #6 from hubicka at gcc dot gnu dot org 2009-06-30 12:44 ---
Created an attachment (id=18100)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18100&action=view)
Proposed patch
The problem is that early inliner allows to increase code size estimate by
inlining single funct
--- Comment #7 from hubicka at ucw dot cz 2009-06-30 12:46 ---
Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852
> The problem is that early inliner allows to increase code size estimate by
> inlining single function by up to 12 instructions. This is higher tha
--- Comment #4 from pault at gcc dot gnu dot org 2009-06-30 12:57 ---
Modifying trans-expr (gfc_trans_zero_assign) to:
tmp = build4 (ARRAY_RANGE_REF, TREE_TYPE (dest), dest,
build_int_cst (gfc_array_index_type, 3),
NULL_TREE, NULL_TREE);
/* If
--- Comment #8 from steven at gcc dot gnu dot org 2009-06-30 13:14 ---
Honza, I can take care of the CSiBE run if you want.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
--- Comment #4 from steven at gcc dot gnu dot org 2009-06-30 13:21 ---
The auto-inc-dec pass fails because the store and the reg increment are not in
the same basic block. The dump of the pass before auto-inc-dec (reginfo) looks
like this:
;; Function testme (testme)
74 NOTE_INSN_B
--- Comment #5 from steven at gcc dot gnu dot org 2009-06-30 13:27 ---
Compiling with "./cc1 -Os t.c -fno-ivopts" I get the following code:
.global testme
.type testme, %function
testme:
@ Function supports interworking.
@ args = 0, pretend = 0, frame =
--- Comment #13 from hubicka at gcc dot gnu dot org 2009-06-30 13:36
---
Hmm,
looking at the cases it seems that main reason for the win is the fact that
idiv needs integer load instruction that has long immediate and we don't
optimize these for -Os well.
I suppose for -Os following is
--- Comment #9 from hubicka at gcc dot gnu dot org 2009-06-30 13:41 ---
I can schedule it for nightly testing today, but if you have easier setup for
CSiBE, it would help :)
Thanks!
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
--- Comment #9 from hjl at gcc dot gnu dot org 2009-06-30 13:56 ---
Subject: Bug 40582
Author: hjl
Date: Tue Jun 30 13:55:43 2009
New Revision: 149097
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149097
Log:
2009-06-30 H.J. Lu
Backport from mainline:
2009-0
--- Comment #16 from hjl at gcc dot gnu dot org 2009-06-30 13:56 ---
Subject: Bug 40493
Author: hjl
Date: Tue Jun 30 13:55:43 2009
New Revision: 149097
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149097
Log:
2009-06-30 H.J. Lu
Backport from mainline:
2009-
--- Comment #8 from hjl at gcc dot gnu dot org 2009-06-30 13:56 ---
Subject: Bug 40274
Author: hjl
Date: Tue Jun 30 13:55:43 2009
New Revision: 149097
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149097
Log:
2009-06-30 H.J. Lu
Backport from mainline:
2009-0
--- Comment #2 from jakub at gcc dot gnu dot org 2009-06-30 13:59 ---
Is this really a regression? GCC 3.4.x, 4.0.x, 4.1.x, 4.2.x, 4.3.x emit the
same thing?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40573
--- Comment #3 from hubicka at ucw dot cz 2009-06-30 14:07 ---
Subject: Re: [4.4/4.5 Regression] DWARF for inlined subroutines refers to the
outlined copy
Hmm, I tought GCC was doing the same thing for years. So we need
abstract function for each inline?
Honza
--
http://gcc.gnu.
--- Comment #4 from drow at gcc dot gnu dot org 2009-06-30 14:19 ---
It looks like you're right. Jan K. recently added support to GDB to attach the
unreferenced children of abstract DIEs to each concrete instance, and that
caused my existing test case to fail in a new way.
--
drow a
--- Comment #5 from drow at gcc dot gnu dot org 2009-06-30 14:21 ---
(In reply to comment #3)
> Hmm, I tought GCC was doing the same thing for years. So we need
> abstract function for each inline?
Why? I think we each inlined copy (and the outlined copy) to refer to the one
abstract
--- Comment #2 from janus at gcc dot gnu dot org 2009-06-30 14:28 ---
Here is a reduced and modified test case. I have marked four lines with a (*),
whose removal results in the correct output (F F), although they seem
completely unrelated. This is pretty strange stuff.
MODULE atom_typ
--- Comment #8 from dje at gcc dot gnu dot org 2009-06-30 14:50 ---
Now I see failures when building libgcc:
../../.././gcc/dp-bit.c: In function '__pack_d':
../../.././gcc/dp-bit.c:268:39: internal compiler error: in simplify_subreg, at
simplify-rtx.c:4966
--
http://gcc.gnu.org/b
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|ada |debug
Keywords||ice-on-valid-co
--- Comment #3 from janus at gcc dot gnu dot org 2009-06-30 15:06 ---
This patch seems to cure it:
Index: gcc/fortran/trans-types.c
===
--- gcc/fortran/trans-types.c (revision 149095)
+++ gcc/fortran/trans-types.c (work
--- Comment #9 from dje at gcc dot gnu dot org 2009-06-30 15:07 ---
The traceback leads to the store flag change.
(gdb) print op
$3 = (rtx) 0x30153558
(gdb) pr
(reg:SI 234)
(gdb) print innermode
$4 = DImode
(gdb) print outermode
$5 = SImode
#0 fancy_abort (file=0x10e8a5b8 "/farm/dje/s
--- Comment #4 from janus at gcc dot gnu dot org 2009-06-30 15:21 ---
PR 39230 is connected to item (c) in comment #3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29616
--- Comment #6 from jakub at gcc dot gnu dot org 2009-06-30 16:29 ---
Created an attachment (id=18101)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18101&action=view)
gcc45-pr40573.patch
Does this patch do what you wanted to see?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?i
--- Comment #10 from janis at gcc dot gnu dot org 2009-06-30 16:46 ---
Bootstrap of trunk revision 149105 fails on powerpc64-linux with the same ICE
that David reported in comment #8, but building stage2:
/libcpp/expr.c: In function _cpp_parse_expr:
/home/janis/gcc_trunk_anonsvn/gcc/l
--- Comment #11 from bonzini at gnu dot org 2009-06-30 16:53 ---
Subject: Re: Powerpc bootstrap is broken due to changes
in expmed.c
What happens with this patch?
Index: expmed.c
===
--- expmed.c(revision 149
--- Comment #4 from dfranke at gcc dot gnu dot org 2009-06-30 16:54 ---
Janus, the patch also fixes the original application.
Thanks for looking into it so quickly!
Please submit for review :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40594
--- Comment #12 from dje at gcc dot gnu dot org 2009-06-30 17:01 ---
I tried bootstrapping with that patch and it did not solve the bootstrap
failure in simplify_subreg.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
--- Comment #5 from janus at gcc dot gnu dot org 2009-06-30 17:06 ---
Subject: Bug 40594
Author: janus
Date: Tue Jun 30 17:06:27 2009
New Revision: 149108
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149108
Log:
2009-06-30 Janus Weil
PR fortran/40594
* tran
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
--- Comment #6 from janus at gcc dot gnu dot org 2009-06-30 17:09 ---
Fixed with r149108. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from tkoenig at gcc dot gnu dot org 2009-06-30 17:10
---
Subject: Bug 40576
Author: tkoenig
Date: Tue Jun 30 17:10:06 2009
New Revision: 149109
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149109
Log:
2009-06-30 Thomas Koenig
PR fortran/40576
--- Comment #11 from hjl at gcc dot gnu dot org 2009-06-30 17:13 ---
Subject: Bug 40576
Author: hjl
Date: Tue Jun 30 17:13:38 2009
New Revision: 149110
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149110
Log:
2009-06-30 H.J. Lu
Backport from mainline:
2009-
--- Comment #7 from hjl at gcc dot gnu dot org 2009-06-30 17:13 ---
Subject: Bug 40594
Author: hjl
Date: Tue Jun 30 17:13:38 2009
New Revision: 149110
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149110
Log:
2009-06-30 H.J. Lu
Backport from mainline:
2009-0
--- Comment #7 from drow at gcc dot gnu dot org 2009-06-30 17:52 ---
Subject: Re: DWARF for inlined subroutines refers to the
outlined copy
On Tue, Jun 30, 2009 at 04:29:25PM -, jakub at gcc dot gnu dot org wrote:
>
>
> --- Comment #6 from jakub at gcc dot gnu dot org 2009-
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org
|dot org
--- Comment #8 from jakub at gcc dot gnu dot org 2009-06-30 18:13 ---
Created an attachment (id=18102)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18102&action=view)
diff
Weird, the difference I get with the patch on the testcase at -O2 -g is
attached.
--
http://gcc.gnu.org
--- Comment #13 from dje at gcc dot gnu dot org 2009-06-30 18:16 ---
The failure appears to need a compiler built in 32 bit mode.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
--- Comment #14 from bergner at gcc dot gnu dot org 2009-06-30 18:40
---
Confirmed, a --with-cpu=default32 build dies with:
/home/bergner/gcc/PR40597/gcc-mainline-base/gcc/builtins.c: In function
get_memory_rtx:
/home/bergner/gcc/PR40597/gcc-mainline-base/gcc/builtins.c:1210:10: inte
--- Comment #9 from drow at gcc dot gnu dot org 2009-06-30 18:59 ---
Subject: Re: DWARF for inlined subroutines refers to the
outlined copy
On Tue, Jun 30, 2009 at 06:13:16PM -, jakub at gcc dot gnu dot org wrote:
> Weird, the difference I get with the patch on the testcase at -O2
--- Comment #4 from jason at gcc dot gnu dot org 2009-06-30 19:36 ---
Subject: Bug 40595
Author: jason
Date: Tue Jun 30 19:36:36 2009
New Revision: 149117
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149117
Log:
PR c++/40595
* pt.c (tsubst_pack_expansion): Hand
--- Comment #15 from bonzini at gnu dot org 2009-06-30 19:40 ---
Guys, when something breaks can you attach preprocessed testcases?...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
--- Comment #5 from jason at gcc dot gnu dot org 2009-06-30 19:45 ---
Subject: Bug 40595
Author: jason
Date: Tue Jun 30 19:45:21 2009
New Revision: 149118
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149118
Log:
PR c++/40595
* pt.c (tsubst_pack_expansion): Hand
--- Comment #6 from jason at gcc dot gnu dot org 2009-06-30 19:49 ---
Fixed for 4.4.1.
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNC
--- Comment #10 from steven at gcc dot gnu dot org 2009-06-30 19:55 ---
I see no effect whatsoever of the patch for for CSiBE on arm-elf-unknown.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
--- Comment #1 from tromey at gcc dot gnu dot org 2009-06-30 20:05 ---
Fixed on trunk:
2009-06-11 Richard Henderson
* common.opt (gdwarf-): Accept a version number.
* doc/invoke.texi (gdwarf-): Update docs.
* opth-gen.awk: Special case -gdwarf+ to OPT_gdwarfp
--- Comment #16 from bergner at gcc dot gnu dot org 2009-06-30 21:02
---
Created an attachment (id=18103)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18103&action=view)
Preprocessed testcase
Preprocessed source file compiled with:
/home/bergner/gcc/PR40597/build/gcc-mainline-b
--- Comment #12 from mckelvey at maskull dot com 2009-06-30 21:09 ---
I see this too, as of today's SVN.
$ alias CONFIGURECVS
alias CONFIGURECVS='/cygdrive/e/Home/cvsroot/gcc/configure --verbose
--enable-threads --disable-nls --enable-checking=release
--enable-concept-checks
--- Comment #17 from bonzini at gnu dot org 2009-06-30 21:31 ---
Regarding powerpc64, I see no difference at -O2 in assembly output between
2009-06-26 version and the version after the patch attached to this bug.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40597
--- Comment #8 from vmakarov at redhat dot com 2009-06-30 21:49 ---
I've checked gcc4.3. It has the same problem. So the reason is not only in
the chosen register class. The both RAs make the pseudo in question
conflicting with all call clobbered hard-regs because it leaves on abnorma
--- Comment #18 from bergner at gcc dot gnu dot org 2009-06-30 21:57
---
This is my backtrace:
#0 fancy_abort (file=0x1091d148
"/home/bergner/gcc/PR40597/gcc-mainline-base/gcc/simplify-rtx.c", line=4966,
function=0x1091dc04 "simplify_subreg") at
/home/bergner/gcc/PR40597/gcc-main
--- Comment #10 from jakub at gcc dot gnu dot org 2009-06-30 22:03 ---
Subject: Bug 40573
Author: jakub
Date: Tue Jun 30 22:03:27 2009
New Revision: 149120
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149120
Log:
PR debug/40573
* dwarf2out.c (gen_formal_paramet
--- Comment #1 from jakub at gcc dot gnu dot org 2009-06-30 22:04 ---
Subject: Bug 40566
Author: jakub
Date: Tue Jun 30 22:04:36 2009
New Revision: 149121
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149121
Log:
PR c++/40566
* convert.c (convert_to_integer) : D
--- Comment #19 from bonzini at gnu dot org 2009-06-30 22:13 ---
I have a patch that seems to fix the problem, but I am afraid it's just
papering over it. Since the attached file does not fail without the patch from
comment #11, would you please attach a testcase that fails without the
1 - 100 of 117 matches
Mail list logo
