--- Comment #1 from carrot at google dot com 2009-07-01 06:56 ---
Created an attachment (id=18105)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18105&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40603
Compile the following function with options -Os -mthumb -march=armv5te
int ldrb(unsigned char* p)
{
if (p[8] <= 0x7F)
return 2;
else
return 5;
}
Gcc generates following codes:
push{lr}
mov r3, #8
ldrsb r3, [r0, r3]
mov
--- Comment #3 from ccg dot ijsj at gmail dot com 2009-07-01 06:41 ---
(In reply to comment #2)
> Can you check this with a later compiler. 4.2.x is closed. Works for me with
> current trunk.
>
Just encountered similar problem while cross compiling gcc 4.4.0 with glibc
2.9.
(Using cross
I'm trying to compile gcc-4.4.0 configured as:
../gcc-4.4.0/configure --prefix=/static --build=$x86_64-cross-linux-gnu
--host=x86_64-cross-linux-gnu --target=x86_64-pc-linux-gnu --enable-languages=c
--disable-multilib --disable-decimal-float --disable-threads
I get the following error message aft
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2009-07-01 05:46
---
Investigating.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Assigne
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2009-07-01 05:45
---
Yep.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Severity|normal
--- Comment #12 from steven at gcc dot gnu dot org 2009-07-01 05:41 ---
Yes, at -Os.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
--- Comment #4 from pinskia at gcc dot gnu dot org 2009-07-01 04:26 ---
None of the print_operand changes are in the changelog either ...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40558
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-07-01 04:24 ---
This change:
if (GET_CODE (tmp) == REG)
- fprintf (file, "0,%s", reg_names[REGNO (tmp)]);
+ fprintf (file, "%s,%s", reg_names[0], reg_names[REGNO (tmp)]);
--
http://gcc.gnu.org/bugzilla/s
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-07-01 04:22 ---
Confirmed, simple testcase:
void f(int *a, float b)
{
*a = b;
}
--- CUT ---
This produces:
_f:
fctiwz f1,f1
stfiwx f1,r0,r3
blr
But it should produce:
_f:
fctiwz f1,f1
stfiw
--- Comment #21 from bergner at gcc dot gnu dot org 2009-07-01 03:29
---
Created an attachment (id=18104)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18104&action=view)
Tetscase for use without comment #11 patch
/home/bergner/gcc/PR40597/build/gcc-mainline-base-32/./prev-gcc/cc
--- Comment #20 from bergner at gcc dot gnu dot org 2009-07-01 03:26
---
Here's a backtrace for a 32-bit default build without Comment #11 patch:
#0 fancy_abort (file=0x1096c5e4
"/home/bergner/gcc/PR40597/gcc-mainline-base/gcc/simplify-rtx.c", line=4966,
function=0x1096d0a0 "sim
--- Comment #11 from hubicka at ucw dot cz 2009-06-30 23:36 ---
Subject: Re: [4.5 regression] 0.5% code size regression caused by r147852
> I see no effect whatsoever of the patch for for CSiBE on arm-elf-unknown.
At -Os?
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40436
--- Comment #11 from jakub at gcc dot gnu dot org 2009-06-30 22:40 ---
Fixed on the trunk.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from jakub at gcc dot gnu dot org 2009-06-30 22:40 ---
Fixed for 4.4/4.5 so far.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Known to
--- Comment #2 from jakub at gcc dot gnu dot org 2009-06-30 22:38 ---
Subject: Bug 40566
Author: jakub
Date: Tue Jun 30 22:38:04 2009
New Revision: 149123
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149123
Log:
PR c++/40566
* convert.c (convert_to_integer) : D
On Linux/ia32, revision 149114 gave:
ERROR: couldn't execute
"/export/gnu/import/svn/gcc-test/bld/gcc/libgcc.a/xgcc": not a directory
ERROR: couldn't execute
"/export/gnu/import/svn/gcc-test/bld/gcc/libgcc.a/xgcc": not a directory
ERROR: tcl error sourcing
/export/gnu/import/svn/gcc-test/src-trunk
--- 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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
--
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 #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-
--- 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 #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 #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 #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
--
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 #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
--- 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 #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 #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 #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 #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 #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 #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 #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
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Component|ada |debug
Keywords||ice-on-valid-co
--- 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
--- 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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 #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
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 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
--- 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 #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 #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 #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 #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 #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
--
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 #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
$ 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 #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
---
--- 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 #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
1 - 100 of 117 matches
Mail list logo