[Bug tree-optimization/49712] internal compiler error: in gen_lsm_tmp_name, at tree-ssa-loop-im.c:2048
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49712
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.07.12 06:37:10
CC||jakub at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-12
06:37:10 UTC ---
Slightly reduced testcase:
int a[2], b, c, d, e;
void
foo (int x, int y)
{
}
int
bar (void)
{
int i;
for (; d = 0; d = 1)
for (i = 0; i 4; i++)
for (e = 0; e; e = 1)
;
return 0;
}
int
main ()
{
for (b = 0; b 2; b++)
while (c)
foo (a[b] = 0, bar ());
return 0;
}
[Bug tree-optimization/49712] internal compiler error: in gen_lsm_tmp_name, at tree-ssa-loop-im.c:2048
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49712 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-12 07:02:30 UTC --- Created attachment 24742 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24742 gcc47-pr49712.patch Untested fix. Wonder if TARGET_MEM_REF shouldn't be handled alongside MEM_REF in ref_always_accessed_p too.
[Bug rtl-optimization/49710] segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49710
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.07.12 07:32:35
CC||jakub at gcc dot gnu.org
Component|c |rtl-optimization
Ever Confirmed|0 |1
--- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-12
07:32:35 UTC ---
Slightly reduced testcase for -O3 -funroll-loops:
int a, b, c, d;
static void
foo (int *x)
{
c = 0;
while (1)
{
if (*x)
break;
while (b)
for (; c; c = 0);
for (d = 18; d != 18; d++)
if (c)
{
foo (x);
return;
}
}
}
static void
bar ()
{
foo (0);
foo (0);
for (;;)
;
}
baz ()
{
for (; a;)
bar ();
}
ICEs in fix_bb_placements during rtl loop peeling.
[Bug c++/35383] Lookup of template dependent function with overloads fails for namespace-qualified parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35383
ophir.setter+gcc at emc dot com changed:
What|Removed |Added
CC||ophir.setter+gcc at emc dot
||com
--- Comment #2 from ophir.setter+gcc at emc dot com 2011-07-12 08:21:25 UTC ---
Is the following the same bug as this bug?
If you remove the specified line it compiles, but without the line it doesn't.
According to my understanding of this analysis, the bug is that it compiles -
even without the line, the specified code should not compile. Am I right?
struct B {};
namespace N {
void foo(){} // If you comment this line, everything is well.
template class T
void bar(T t) {
foo(t);
}
void foo(::B) {
}
}
int main() {
B tmp;
N::bar(tmp);
return 0;
}
gcc -v -save-temps main.cpp -o main
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--with-multiarch-defaults=i386-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/i386-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/i386-linux-gnu
--enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default
--with-plugin-ld=ld.gold --enable-objc-gc --enable-targets=all --disable-werror
--with-arch-32=i686 --with-tune=generic --enable-checking=release
--build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'main' '-mtune=generic'
'-march=i686'
/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/cc1plus -E -quiet -v
-D_GNU_SOURCE main.cpp -D_FORTIFY_SOURCE=2 -mtune=generic -march=i686
-fpch-preprocess -fstack-protector -o main.ii
ignoring nonexistent directory /usr/local/include/i386-linux-gnu
ignoring nonexistent directory
/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/../../../../../i686-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.5
/usr/include/c++/4.5/i686-linux-gnu
/usr/include/c++/4.5/backward
/usr/local/include
/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/include
/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/include-fixed
/usr/include/i386-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'main' '-mtune=generic'
'-march=i686'
/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/cc1plus -fpreprocessed
main.ii -quiet -dumpbase main.cpp -mtune=generic -march=i686 -auxbase main
-version -fstack-protector -o main.s
GNU C++ (Ubuntu/Linaro 4.5.2-8ubuntu4) version 4.5.2 (i686-linux-gnu)
compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 3.0.0-p8,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu/Linaro 4.5.2-8ubuntu4) version 4.5.2 (i686-linux-gnu)
compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 3.0.0-p8,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 0c5cb630517b5952f4898dfa56d7e8e5
main.cpp: In function ‘void N::bar(T) [with T = B]’:
main.cpp:17:13: instantiated from here
main.cpp:8:5: error: too many arguments to function ‘void N::foo()’
main.cpp:4:8: note: declared here
[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519 --- Comment #29 from rguenther at suse dot de rguenther at suse dot de 2011-07-12 08:35:18 UTC --- On Tue, 12 Jul 2011, ian at airs dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com --- Comment #27 from Ian Lance Taylor ian at airs dot com 2011-07-12 04:37:01 UTC --- This patch seems too conservative and it appears that it will cause the compiler to miss all tailcalls with pointer arguments. It only matters if the register points to the incoming parameters, which can only happen in unusual cases. We should be able to determine that reliably. Janis, did you open a PR for the missing optimization? I didn't see one. The point is, of course, we have to determine it conservatively correct. The patch makes sure we do that. Richard.
[Bug fortran/49708] [4.5/4.6/4.7 Regression] ICE with allocate and no dimensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49708 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Priority|P3 |P5 CC||burnus at gcc dot gnu.org, ||janus at gcc dot gnu.org Known to work||4.1.2, 4.3.4, 4.4.0 Target Milestone|--- |4.6.2 Summary|internal compiler error |[4.5/4.6/4.7 Regression] |with allocate and no|ICE with allocate and no |dimensions |dimensions Known to fail||4.5.3, 4.6.1, 4.7.0 --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-07-12 08:35:20 UTC --- Side effect from allowing allocatable scalars in 4.5. With 4.1 to 4.4, one gets the error: Error: Array specification required in ALLOCATE statement at (1) In principle, the check is still in resolve.c - the question is: Why doesn't it trigger?
[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519
--- Comment #30 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-07-12
08:42:40 UTC ---
This patch seems too conservative and it appears that it will cause the
compiler to miss all tailcalls with pointer arguments. It only matters if the
register points to the incoming parameters, which can only happen in unusual
cases. We should be able to determine that reliably.
This is a bit of an overstatement though, as
extern int foo (int, int *);
int i;
int bar (int a, int b)
{
int *p = i;
return foo (a, p);
}
will be caught. Even this
extern int foo (int, int);
int i;
int bar (int a, int b)
{
int *p = i;
return foo (a, *p);
}
will be caught thanks to alias analysis at the Tree level.
As for the reliably, this time it's a little optimistic IMO. :-) But we can
probably be less conservative with more work.
[Bug target/49713] New: Conflicting types for 'arm_dbx_register_number'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49713 Summary: Conflicting types for 'arm_dbx_register_number' Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: revital.e...@linaro.org Host: arm-linux-gnueabi Target: arm-linux-gnueabi The following error occurs while bootstrap trunk -r176194 on arm-linux-gnueabi with the following config options: --enable-checking --enable-languages=c --enable-bootstrap gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber ../../gcc/gcc/dwarf2cfi.c -o dwarf2cfi.o In file included from ../../gcc/gcc/dwarf2cfi.c:31:0: ../../gcc/gcc/dwarf2out.h: In function 'dwarf_frame_regnum': ../../gcc/gcc/dwarf2out.h:271:3: warning: implicit declaration of function 'arm_dbx_register_number' In file included from ./tm_p.h:4:0, from ../../gcc/gcc/dwarf2cfi.c:34: ../../gcc/gcc/config/arm/arm-protos.h: At top level: ../../gcc/gcc/config/arm/arm-protos.h:41:21: error: conflicting types for 'arm_dbx_register_number' ../../gcc/gcc/dwarf2out.h:271:10: note: previous implicit declaration of 'arm_dbx_register_number' was here
[Bug middle-end/49711] [4.7 Regression] 186.crafty in SPEC CPU 2000 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49711 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-12 08:49:12 UTC --- . *** This bug has been marked as a duplicate of bug 49712 ***
[Bug rtl-optimization/49710] [4.7 Regression] segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49710 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.1 Target Milestone|--- |4.7.0 Summary|segfault|[4.7 Regression] segfault
[Bug tree-optimization/49712] internal compiler error: in gen_lsm_tmp_name, at tree-ssa-loop-im.c:2048
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49712 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-12 08:48:45 UTC --- (In reply to comment #3) Created attachment 24742 [details] gcc47-pr49712.patch Untested fix. Wonder if TARGET_MEM_REF shouldn't be handled alongside MEM_REF in ref_always_accessed_p too. Looks obvious.
[Bug c/49706] No warning for (!x 1) which is always false
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49706 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.12 08:51:27 Ever Confirmed|0 |1 Severity|normal |enhancement --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-12 08:51:27 UTC --- Confirmed.
[Bug tree-optimization/49712] internal compiler error: in gen_lsm_tmp_name, at tree-ssa-loop-im.c:2048
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49712 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-12 08:49:12 UTC --- *** Bug 49711 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/49710] [4.7 Regression] segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49710 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-12 08:54:29 UTC --- Caused by http://gcc.gnu.org/viewcvs?root=gccview=revrev=172430 but more probably this is just a dup of PR48813, which was for this testcase latent before. Honza, any chance you could look at that and PR48813? The ICE is in the exact same spot, base_loop is non-NULL, but base_loop-header is NULL, as the loop has been marked for removal in delete_basic_block called from remove_bbs/remove_path during the peeling. The same remove_path then calls fix_loop_placements which calls fix_bb_placements which ICEs. That delete_basic_block is apparently called on the loop-latch bb, which queues the loop for removal anyway, but loop-header hasn't been removed and its bb-loop_father still points to the loop that has now header and latch fields NULL.
[Bug middle-end/49705] -Wstrict-overflow should not diagnose unevaluated expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49705 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||diagnostic Last reconfirmed||2011.07.12 08:57:17 Component|c |middle-end CC||iant at google dot com Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-12 08:57:17 UTC --- Confirmed. And very difficult to fix.
[Bug tree-optimization/49712] internal compiler error: in gen_lsm_tmp_name, at tree-ssa-loop-im.c:2048
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49712 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-12 09:13:11 UTC --- Author: jakub Date: Tue Jul 12 09:13:06 2011 New Revision: 176195 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176195 Log: PR tree-optimization/49712 * tree-ssa-loop-im.c (gen_lsm_tmp_name): Handle TARGET_MEM_REF. * gcc.c-torture/execute/pr49712.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr49712.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-im.c
[Bug c/49706] No warning for (!x 1) which is always false
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49706
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-12
09:27:38 UTC ---
-Wtype-limits is apparently just in shorten_compare and vrp, while here it is
optimized by fold. For
_Bool x;
...
if (x 1)
or
struct { unsigned int i : 1; } x;
...
if (x.i 1)
we don't warn either.
[Bug lto/49700] LTO compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700 --- Comment #5 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-07-12 10:17:54 UTC --- (In reply to comment #3) Oh, so it's a sum ... Well, the I suppose you run into the usual array-prefetching compile-time hog. Try -fno-prefetch-loop-arrays. This seems to reduce the time by 5x. On a non-LTO run, this doesn't matter, but I assume LTO makes more info available that triggers some action by that pass.
[Bug target/49714] New: [4.7 Regression] Revision 176128 introduced many ICEs in insn_default_length, at config/i386/i386.md:600
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49714 Summary: [4.7 Regression] Revision 176128 introduced many ICEs in insn_default_length, at config/i386/i386.md:600 Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: r...@gcc.gnu.org, ia...@gcc.gnu.org Host: x86_64-apple-darwin10 Target: x86_64-apple-darwin10 Build: x86_64-apple-darwin10 On x86_64-apple-darwin10, revision 176128 introduced a lot of failures in the test suite of the kind: [macbook] f90/bug% /opt/gcc/gcc4.7p/bin/g++ /opt/gcc/work/gcc/testsuite/g++.old-deja/g++.other/dyncast1.C /opt/gcc/work/gcc/testsuite/g++.old-deja/g++.other/dyncast1.C: In member function 'void E::_ZThn8_N1ED1Ev()': /opt/gcc/work/gcc/testsuite/g++.old-deja/g++.other/dyncast1.C:123:1: error: unrecognizable insn: (jump_insn 3 2 4 (set (pc) (mem:QI (const:DI (unspec:DI [ (symbol_ref/i:DI (_ZN1ED1Ev) [flags 0x1] function_decl 0x1428b7400 __comp_dtor ) ] UNSPEC_GOTPCREL)) [0 S1 A8])) -1 (nil)) /opt/gcc/work/gcc/testsuite/g++.old-deja/g++.other/dyncast1.C:123:1: internal compiler error: in insn_default_length, at config/i386/i386.md:600
[Bug target/49714] [4.7 Regression] Revision 176128 introduced many ICEs in insn_default_length, at config/i386/i386.md:600
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49714 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.0
[Bug target/49715] New: Could do more efficient unsigned-to-float to conversions based on range information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49715
Summary: Could do more efficient unsigned-to-float to
conversions based on range information
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sgunder...@bigfoot.com
I have code that looks vaguely like this:
float func(unsigned x)
{
return (x 0xf) * 0.01f;
}
When I compile it, GCC gives a long and relatively slow sequence:
fugl:~ gcc-4.6 -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc-4.6
COLLECT_LTO_WRAPPER=/usr/lib/i386-linux-gnu/gcc/i486-linux-gnu/4.6.1/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-3'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-multiarch
--with-multiarch-defaults=i386-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/i386-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/i386-linux-gnu
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.6.1 (Debian 4.6.1-3)
fugl:~ gcc-4.6 -O2 -march=pentium3 -msse2 -mfpmath=sse -c test.c
fugl:~ objdump --disassemble test.o
test.o: file format elf32-i386
Disassembly of section .text:
func:
0:83 ec 04 sub$0x4,%esp
3:8b 54 24 08 mov0x8(%esp),%edx
7:89 d0mov%edx,%eax
9:81 e2 ff ff 00 00and$0x,%edx
f:25 ff ff 0f 00 and$0xf,%eax
14:c1 e8 10 shr$0x10,%eax
17:f3 0f 2a c0 cvtsi2ss %eax,%xmm0
1b:f3 0f 2a ca cvtsi2ss %edx,%xmm1
1f:f3 0f 59 05 00 00 00 mulss 0x0,%xmm0
26:00
27:f3 0f 58 c1 addss %xmm1,%xmm0
2b:f3 0f 59 05 04 00 00 mulss 0x4,%xmm0
32:00
33:f3 0f 11 04 24 movss %xmm0,(%esp)
38:d9 04 24 flds (%esp)
3b:58 pop%eax
3c:c3 ret
3d:8d 76 00 lea0x0(%esi),%esi
I assume this is because x is unsigned (I cannot easily change this, as I
depend on wraparound). However, if I insert a cast to int after the and
operation, I get the same results, and a much better sequence:
0040 func2:
40:83 ec 04 sub$0x4,%esp
43:8b 44 24 08 mov0x8(%esp),%eax
47:25 ff ff 0f 00 and$0xf,%eax
4c:f3 0f 2a c0 cvtsi2ss %eax,%xmm0
50:f3 0f 59 05 04 00 00 mulss 0x4,%xmm0
57:00
58:f3 0f 11 04 24 movss %xmm0,(%esp)
5d:d9 04 24 flds (%esp)
60:5a pop%edx
61:c3 ret
In other words, the modified code looks like this:
float func2(unsigned x)
{
return (int)(x 0xf) * 0.01f;
}
This should be possible for GCC to do when it has range information that says
the sign bit cannot be set.
[Bug rtl-optimization/49014] [4.7 Regression] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7132 with even more insane set of flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49014 --- Comment #7 from Andrey Belevantsev abel at gcc dot gnu.org 2011-07-12 12:12:40 UTC --- Author: abel Date: Tue Jul 12 12:12:36 2011 New Revision: 176197 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176197 Log: Backport from mainline 2011-05-25 Andrey Belevantsev a...@ispras.ru PR rtl-optimization/49014 * config/i386/athlon.md (athlon_ssecomi): Change type to ssecomi. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/i386/athlon.md
[Bug rtl-optimization/49014] [4.7 Regression] ICE: in reset_sched_cycles_in_current_ebb, at sel-sched.c:7132 with even more insane set of flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49014 Andrey Belevantsev abel at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #8 from Andrey Belevantsev abel at gcc dot gnu.org 2011-07-12 12:13:39 UTC --- Fixed.
[Bug c/49716] New: internal compiler error: in new_Cloog_Domain_from_ppl_Pointset_Powerset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49716 Summary: internal compiler error: in new_Cloog_Domain_from_ppl_Pointset_Powerset Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: step...@openelec.tv compiling busybox-1.18.5 with gcc-4.6.1 with enabled: -ftree-loop-distribution -floop-interchange -floop-strip-mine -floop-block -fgraphite-identity and using gold linker fails with: /home/stephan/projects/jetstream-master/build.Jetstream-MK_I.i386-devel/toolchain/bin/i686-openelec-linux-gnu-gcc -Wp,-MD,shell/.math.o.d -std=gnu99 -Iinclude -Ilibbb -include include/autoconf.h -D_GNU_SOURCE -DNDEBUG -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -DBB_VER=KBUILD_STR(1.18.5) -DBB_BT=AUTOCONF_TIMESTAMP -march=atom -m32 -fomit-frame-pointer -Wall -pipe -Os -fexcess-precision=fast -ftree-loop-distribution -floop-interchange -floop-strip-mine -floop-block -fgraphite-identity -mfpmath=sse -ftree-vectorize -mmovbe -Wall -Wshadow -Wwrite-strings -Wundef -Wstrict-prototypes -Wunused -Wunused-parameter -Wunused-function -Wunused-value -Wmissing-prototypes -Wmissing-declarations -Wdeclaration-after-statement -Wold-style-definition -fno-builtin-strlen -finline-limit=0 -fomit-frame-pointer -ffunction-sections -fdata-sections -fno-guess-branch-probability -funsigned-char -static-libgcc -falign-functions=1 -falign-jumps=1 -falign-labels=1 -falign-loops=1 -Os -march=i386 -mpreferred-stack-boundary=2-DKBUILD_STR(s)=#s -DKBUILD_BASENAME=KBUILD_STR(math) -DKBUILD_MODNAME=KBUILD_STR(math) -c -o shell/math.o shell/math.c shell/math.c:1:0: warning: SSE instruction set disabled, using 387 arithmetics [enabled by default] shell/math.c:1:0: warning: SSE instruction set disabled, using 387 arithmetics [enabled by default] shell/math.c: In function 'arith_apply': shell/math.c:300:1: internal compiler error: in new_Cloog_Domain_from_ppl_Pointset_Powerset, at graphite-cloog-util.c:302 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [shell/math.o] Error 1 make[1]: *** [shell] Error 2 make[1]: *** Waiting for unfinished jobs it was working with gcc-4.5.x thanks Stephan
[Bug tree-optimization/49715] Could do more efficient unsigned-to-float to conversions based on range information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49715
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Keywords||missed-optimization
Last reconfirmed||2011.07.12 12:18:02
Component|target |tree-optimization
CC||rguenth at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-12
12:18:02 UTC ---
Confirmed. VRP could do this transformation. I'm not sure it's always
worth or if there is a target that can do faster unsigned - float conversion
than signed - float conversion (though I doubt that). Probably similar
optimization can be applied for
float func (unsigned long long x)
{
return (x 0xf) * 0.01f;
}
that is, introduce a truncation so that the int-float expander can use
floatsi instead of floatdi which might not be available either.
It happens that i?86 defines floatunsssi, so depending on the availability
of a unsigned - float expander isn't a good profitability check.
The odd thing is of course that VRP would _insert_ a conversion ...
[Bug fortran/49708] [4.5/4.6/4.7 Regression] ICE with allocate and no dimensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49708 janus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.12 12:27:33 Ever Confirmed|0 |1 --- Comment #2 from janus at gcc dot gnu.org 2011-07-12 12:27:33 UTC --- (In reply to comment #1) In principle, the check is still in resolve.c - the question is: Why doesn't it trigger? Apparently because of the pointer attribute. Changing pointer to allocatable in the test case will trigger the error message. With the following patch one also gets the error message for the pointer case, but I haven't checked if this breaks anything else: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c(revision 175788) +++ gcc/fortran/resolve.c(working copy) @@ -6884,7 +6884,7 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code gfc_find_derived_vtab (ts.u.derived); } - if (pointer || (dimension == 0 codimension == 0)) + if (dimension == 0 codimension == 0) goto success; /* Make sure the last reference node is an array specifiction. */
[Bug libstdc++/49717] New: Debug version checking algorithmic preconditions may have different complexity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49717 Summary: Debug version checking algorithmic preconditions may have different complexity Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: bange...@gmail.com This is essentially just a request to state something more explicitly on the website: We've started using the libstdc++ debug mode for running our testsuite (and found a dozen or so bugs with it -- yay) but I've come to realize that a bunch of tests now time out: they've become orders of magnitude slower. The reason I found for this is that many of the algorithms in libstdc++ (rightfully) check preconditions. For example, std::lower_bound checks whether indeed the given element partitions the sequence. The problem here is that these checks violate the complexity guarantees of the algorithms: std::lower_bound is supposed to be O(log(N)) but with the check for partitioning, it is now O(N). In our case, we call this function for each element of a sequence, and so we get O(N**2) instead of O(N log(N)) and the result is the increase in compute time. There is little one can do about this -- the debug mode is meant to check these things and it can't be done in O(log(N)). But it would be good to state this prominently somewhere in the corresponding web sites. Thanks W.
[Bug fortran/49708] [4.5/4.6/4.7 Regression] ICE with allocate and no dimensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49708 --- Comment #3 from janus at gcc dot gnu.org 2011-07-12 12:38:55 UTC --- I'm afraid the regression was introduced by this commit of mine: http://gcc.gnu.org/viewcvs?view=revisionrevision=151240
[Bug c++/45697] __restrict__ inconsistent in presence of typedefs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45697 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-07-12 12:47:30 UTC --- Since clang handles this differently, I think I'll leave it as SUSPENDED for now.
[Bug tree-optimization/49715] Could do more efficient unsigned-to-float to conversions based on range information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49715 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #2 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-12 12:50:21 UTC --- Created attachment 24743 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24743 proof of concept Like this.
[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48851 --- Comment #20 from Jonathan Gray jsg at openbsd dot org 2011-07-12 13:00:32 UTC --- So can you commit your patch and unbreak the build? It is clearly broken, anyone wanting to do a less broken version of the fixincludes mangling can do so at a later point.
[Bug libstdc++/49717] Debug version checking algorithmic preconditions may have different complexity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49717 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-07-12 13:48:32 UTC --- http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt03ch17s02.html All functional and exception-handling guarantees made by the normal library also hold for the debug mode library, with one exception: performance guarantees made by the normal library may not hold in the debug mode library. For instance, erasing an element in a std::list is a constant-time operation in normal library, but in debug mode it is linear in the number of iterators that reference that particular list. So while your (correct) program won't change its results, it is likely to execute more slowly.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Hans-Werner Boschmann boschmann at tp1 dot physik.uni-siegen.de changed: What|Removed |Added CC||boschmann at tp1 dot ||physik.uni-siegen.de --- Comment #14 from Hans-Werner Boschmann boschmann at tp1 dot physik.uni-siegen.de 2011-07-12 13:51:08 UTC --- I've got one more item for the TODO list: character(:),allocatable::string integer::length length=5 allocate(character(len=length)::string) This is not yet accepted by gfortran. Is there any other way to allocate string without a primitive like string=repeat( ,10)?
[Bug libstdc++/49717] Debug version checking algorithmic preconditions may have different complexity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49717 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-07-12 13:54:51 UTC --- You should consider using 4.6 for the tests using debug mode - there are some huge performance improvements, where non-debug iterators are used when checking is known to have been done already e.g. instead of incrementing a debug iterator N times and checking on every increment, do the necessary checks once then increment the underlying unsafe iterator N times
[Bug c/49626] Explicit conversion skipped when followed by conversion to a wider type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49626
Jason Merrill jason at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.07.12 13:56:39
CC||jason at gcc dot gnu.org
Component|c++ |c
Ever Confirmed|0 |1
--- Comment #2 from Jason Merrill jason at gcc dot gnu.org 2011-07-12
13:56:39 UTC ---
This does seem like a bug, since the documentation says An explicit cast
silences the warning. This bug also affects the C front end, so I'm changing
the category to C.
unsigned long f()
{
short sh;
return (unsigned int)sh;
}
[Bug libstdc++/49717] Debug version checking algorithmic preconditions may have different complexity
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49717 Wolfgang Bangerth bangerth at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #3 from Wolfgang Bangerth bangerth at gmail dot com 2011-07-12 14:00:05 UTC --- Aw, thanks for the link -- I wonder how I missed that :-( I'm looking forward to trying 4.6 whenever our sysadmins decide to put it onto our machines -- the things you mention are one of many goodies worth trying. Thanks W.
[Bug middle-end/49699] Aligned load on unaligned address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49699 --- Comment #4 from H.J. Lu hjl.tools at gmail dot com 2011-07-12 14:05:08 UTC --- (In reply to comment #2) Very old issue. The aligned attribute cannot be reliably used to decrease alignment. Can we issue a warning for things like this?
[Bug middle-end/49699] Aligned load on unaligned address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49699 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-07-12 14:06:08 UTC --- (In reply to comment #3) I think you'd need to make it packed as well, but then it depends on gcc version which alignment the aggregate actually has. This issue came from http://sourceware.org/bugzilla/show_bug.cgi?id=12872
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #15 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-07-12 14:19:24 UTC --- On Tue, Jul 12, 2011 at 01:51:40PM +, boschmann at tp1 dot physik.uni-siegen.de wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Hans-Werner Boschmann boschmann at tp1 dot physik.uni-siegen.de changed: What|Removed |Added CC||boschmann at tp1 dot ||physik.uni-siegen.de --- Comment #14 from Hans-Werner Boschmann boschmann at tp1 dot physik.uni-siegen.de 2011-07-12 13:51:08 UTC --- I've got one more item for the TODO list: character(:),allocatable::string integer::length length=5 allocate(character(len=length)::string) This is not yet accepted by gfortran. Is there any other way to allocate string without a primitive like string=repeat( ,10)? laptop:kargl[212] gfc4x -o z g.f90 laptop:kargl[213] ./z yes!! laptop:kargl[214] cat g.f90 character(:),allocatable::string string='yes!!' print *, string end
[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48851 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added AssignedTo|rguenth at gcc dot gnu.org |mikestump at comcast dot ||net --- Comment #21 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-12 14:20:44 UTC --- Mike has taken this bug.
[Bug c++/49718] New: please allow no_instrument_function attribute in class member definition/declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49718
Summary: please allow no_instrument_function attribute in class
member definition/declaration
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jojel...@gmail.com
it says
instrument.cc:10:6: error: can’t set ‘no_instrument_function’ attribute after
definition
isn't it false-positive? because in class/struct it is normal one to define
such member function in it.
#include stdio.h
struct t
{
public:
t();
__attribute__((no_instrument_function)) void a(){
}
void __attribute__((no_instrument_function))b(){
}
void c() __attribute__((no_instrument_function)){
}
void d() __attribute__((no_instrument_function));
};
void t::d()
{}
int main()
{
t a;
a.a();
}
$ g++ instrument.cc -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-cygwin/4.7.0/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with: ./configure --config-cache --prefix=/usr
--disable-win32-registry --enable-threads=win32 --enable-languages=c,c++,lto
--with-win32-nlsapi=unicode --enable-tls --disable-bootstrap --enable-shared
--disable-sjlj-exceptions --enable-gomp
Thread model: win32
gcc version 4.7.0 20110708 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro'
/usr/libexec/gcc/i686-pc-cygwin/4.7.0/cc1plus.exe -quiet -v -D__CYGWIN32__
-D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter
/usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/lib/../include/w32api
-idirafter
/usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/lib/../../include/w32api
instrument.cc -quiet -dumpbase instrument.cc -mtune=generic -march=pentiumpro
-auxbase instrument -version -o /tmp/ccqnGK06.s
GNU C++ (GCC) version 4.7.0 20110708 (experimental) (i686-pc-cygwin)
compiled by GNU C version 4.7.0 20110622 (experimental), GMP version
5.0.0, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring duplicate directory /usr/include
ignoring duplicate directory
/usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/lib/../../include/w32api
#include ... search starts here:
#include ... search starts here:
/usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../include/c++/4.7.0
/usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../include/c++/4.7.0/i686-pc-cygwin
/usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../include/c++/4.7.0/backward
/usr/lib/gcc/i686-pc-cygwin/4.7.0/include
/usr/local/include
/usr/lib/gcc/i686-pc-cygwin/4.7.0/include-fixed
/usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/include
/usr/lib/gcc/i686-pc-cygwin/4.7.0/../../../../i686-pc-cygwin/lib/../include/w32api
End of search list.
GNU C++ (GCC) version 4.7.0 20110708 (experimental) (i686-pc-cygwin)
compiled by GNU C version 4.7.0 20110622 (experimental), GMP version
5.0.0, MPFR version 2.4.2, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 68ba7c3bade77b76b9651c346a28b1de
instrument.cc:6:46: error: can’t set ‘no_instrument_function’ attribute after
definition
instrument.cc:8:45: error: can’t set ‘no_instrument_function’ attribute after
definition
instrument.cc:10:6: error: can’t set ‘no_instrument_function’ attribute after
definition
[Bug middle-end/49705] -Wstrict-overflow should not diagnose unevaluated expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49705 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com --- Comment #2 from Ian Lance Taylor ian at airs dot com 2011-07-12 14:25:13 UTC --- Very difficult to fix in the general case but easy to fix in this particular case. When the warning is issued, c_inhibit_evaluation_warnings is 1. All we need to do is, when setting c_inhibit_evaluation_warnings non-zero, also call fold_defer_overflow_warnings.
[Bug middle-end/49705] -Wstrict-overflow should not diagnose unevaluated expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49705 --- Comment #3 from Ian Lance Taylor ian at airs dot com 2011-07-12 14:25:56 UTC --- Created attachment 24744 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24744 Possible patch Here is a possible patch to fix this test case.
[Bug tree-optimization/49651] [C++0x] nested lambdas and -O3 produced incorrect integer variable increments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49651 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||jason at gcc dot gnu.org Component|c++ |tree-optimization --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2011-07-12 14:38:53 UTC --- With current pre-4.6.2 I find that it fails with -O2 -fno-thread-jumps -fno-align-functions -fno-align-jumps -fno-align-loops -fno-align-labels -fno-caller-saves -fno-crossjumping -fno-cse-follow-jumps -fno-cse-skip-blocks -fno-delete-null-pointer-checks -fno-expensive-optimizations -fno-gcse -fno-gcse-lm -fno-inline-small-functions -fno-indirect-inlining -fno-ipa-sra -fno-optimize-sibling-calls -fno-peephole2 -fno-regmove -fno-reorder-blocks -fno-reorder-functions -fno-rerun-cse-after-loop -fno-sched-interblock -fno-sched-spec -fno-schedule-insns -fno-schedule-insns2 -fno-strict-aliasing -fno-strict-overflow -fno-tree-switch-conversion -fno-tree-pre -fno-tree-vrp -fno-devirtualize -fno-ipa-cp -fno-tree-builtin-call-dce -fno-auto-inc-dec -fno-cprop-registers -fno-dce -fno-defer-pop -fno-delayed-branch -fno-dse -fno-guess-branch-probability -fno-if-conversion -fno-if-conversion2 -fno-ipa-pure-const -fno-ipa-reference -fno-merge-constants -fno-split-wide-types -fno-tree-builtin-call-dce -fno-tree-ccp -fno-tree-ch -fno-tree-copyrename -fno-tree-dce -fno-tree-forwprop -fno-tree-phiprop -fno-tree-sra -fno-tree-ter But adding -O1, -fno-tree-pta or -fno-tree-fre makes it work. There only seem to be a few places that depend on optimize being 1 vs 2. Changing category to tree-optimization.
[Bug lto/49700] LTO compile time hog
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49700 --- Comment #6 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-07-12 14:40:29 UTC --- (In reply to comment #1) Joost, can you point us to a source tarball? Does the issue reproduce with simpler flags (plain -O2 or plain -O3? Esp. w/o -march=native?) CP2K sources are easy, but the to get a version that links, there are additional non-standard dependencies (blas, lapack, libint).
[Bug fortran/49708] [4.5/4.6/4.7 Regression] ICE with allocate and no dimensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49708 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org |gnu.org | --- Comment #4 from janus at gcc dot gnu.org 2011-07-12 14:44:30 UTC --- (In reply to comment #2) With the following patch one also gets the error message for the pointer case, but I haven't checked if this breaks anything else: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c(revision 175788) +++ gcc/fortran/resolve.c(working copy) @@ -6884,7 +6884,7 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code gfc_find_derived_vtab (ts.u.derived); } - if (pointer || (dimension == 0 codimension == 0)) + if (dimension == 0 codimension == 0) goto success; /* Make sure the last reference node is an array specifiction. */ I just verified that this patch is free of testsuite regressions.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #16 from Tobias Burnus burnus at gcc dot gnu.org 2011-07-12 14:44:11 UTC --- (In reply to comment #14) allocate(character(len=length)::string) This is not yet accepted by gfortran. Is there any other way to allocate string without a primitive like string=repeat( ,10)? Error: Variable 'length' cannot appear in the expression at (1) That comes from the specification expression check. The check is called via resolve_types - resolve_charlen - resolve_index_expr - gfc_specification_expr Thus, one needs to somehow distinguish length specifications in the ALLOCATE from those in a type-declaration statement; I think one needs to modify both resolve_index_expr (not calling gfc_specification_expr) and resolve_charlen (not setting specification_expr).
[Bug c/49716] internal compiler error: in new_Cloog_Domain_from_ppl_Pointset_Powerset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49716 --- Comment #1 from Sebastian Pop spop at gcc dot gnu.org 2011-07-12 14:55:07 UTC --- Please attach a preprocessed source (just add a -E option to the failing compile line and the preprocessed source should be in math.o). Thanks, Sebastian
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #17 from Hans-Werner Boschmann boschmann at tp1 dot physik.uni-siegen.de 2011-07-12 15:00:22 UTC --- This sounds like there is still a lot of work to do in this character issue. Has anyone ever managed to allocate such strings dynamically? In (In reply to comment #15) character(:),allocatable::string string='yes!!' print *, string end the length is constant so you could use character(5)::string. That's not what I mean, I would like to have something like this: PROGRAM helloworld character(:),allocatable::string real::rnd call random_number(rnd) call hello(ceiling(11*rnd),string) print *,string contains subroutine hello (n,string) character(:),allocatable,intent(out)::string integer,intent(in)::n character(10)::helloworld=hello world string=helloworld(:n) end subroutine hello end PROGRAM helloworld I guess that's not yet possible with gfortran.
[Bug middle-end/49719] New: test gcc.target/arm/sibcall-1.c fails for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49719 Summary: test gcc.target/arm/sibcall-1.c fails for ARM Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org Test gcc.target/arm/sibcall-1.c starts failing with r176042, a fix for PR middle-end/49519, for arm-none-linux-gnueabi configured with defaults for arch and cpu. The failure can be reproduced with a simple cross cc1. See discussion in 49519.
[Bug middle-end/49519] [4.7 Regression] Revision 175272 miscompiled 447.dealII in SPEC CPU 2006
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49519 --- Comment #31 from Janis Johnson janis at gcc dot gnu.org 2011-07-12 15:06:03 UTC --- I filed PR middle-end/49719 for the sibcall-1.c failure.
[Bug tree-optimization/49651] [C++0x] nested lambdas and -O3 produced incorrect integer variable increments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49651
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-12
15:19:48 UTC ---
Shorter testcase that also terminates when successful:
#include vector
#include algorithm
extern C void abort (void);
typedef unsigned int u32;
using namespace std;
vectoru32 g;
void f(u32 a, u32 b)
{
g.push_back(b);
for(int i=1; ig.size() ! g.empty(); ++i)
if ( g[i-1]+1 != g[i])
abort ();
}
int main(int argc, char *argv[])
{
int cnt = 256;
u32 a = 0;
vectorint vi;
vi.push_back(0);
vi.push_back(1);
vi.push_back(2);
vi.push_back(3);
vi.push_back(4);
vectorint vo;
vo.push_back(5);
vo.push_back(5);
vectorint ve;
ve.push_back(5);
vectorint v3;
vectorint v4;
vectorint v5;
vectorint v6;
vectorint v7;
f(32, a++);
f(32, a++);
auto run = [](int i) {
// inside this lambda a is not the same as the a in the first line
v3.push_back(i);
v4.push_back(i);
v5.push_back(i);
v6.push_back(i);
v7.push_back(i);
f(32, a++);
v3.push_back(i);
v4.push_back(i);
v5.push_back(i);
v6.push_back(i);
v7.push_back(i);
f(32, a++);
for_each(ve.begin(), ve.end(), [](int xi) {
v7.push_back(xi);
f(32, a++);
});
f(32, a++);
};
f(32, a++);
while(--cnt) {
for_each(vi.begin(), vi.end(), [](int xi) {
f(32, a++);
for_each(vo.begin(), vo.end(), run);
f(32, a++);
for_each(ve.begin(), ve.end(), run);
f(32, a++);
});
}
}
[Bug tree-optimization/49715] Could do more efficient unsigned-to-float to conversions based on range information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49715 --- Comment #3 from sgunderson at bigfoot dot com 2011-07-12 15:19:51 UTC --- Wow, answer in record time :-) I don't know anything about GCC internals, so I can't comment much on the patch; my only worry here is what would happen if you had a very narrow mask, e.g. (x 0xf) and you try to coerce it into the minimum possible type (a char); wouldn't you end up doing some sort of expansion with movzbl again?
[Bug tree-optimization/49715] Could do more efficient unsigned-to-float to conversions based on range information
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49715 --- Comment #4 from rguenther at suse dot de rguenther at suse dot de 2011-07-12 15:21:51 UTC --- On Tue, 12 Jul 2011, sgunderson at bigfoot dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49715 --- Comment #3 from sgunderson at bigfoot dot com 2011-07-12 15:19:51 UTC --- Wow, answer in record time :-) I don't know anything about GCC internals, so I can't comment much on the patch; my only worry here is what would happen if you had a very narrow mask, e.g. (x 0xf) and you try to coerce it into the minimum possible type (a char); wouldn't you end up doing some sort of expansion with movzbl again? That's why I limit it to SImode truncation (that should be equivalent to an int). Quite lame ;)
[Bug target/49714] [4.7 Regression] Revision 176128 introduced many ICEs in insn_default_length, at config/i386/i386.md:600
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49714
Uros Bizjak ubizjak at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.07.12 15:40:24
Ever Confirmed|0 |1
--- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2011-07-12 15:40:24
UTC ---
Can you please regtest this patch:
--cut here--
Index: i386.c
===
--- i386.c(revision 176207)
+++ i386.c(working copy)
@@ -29399,7 +29399,7 @@ x86_output_mi_thunk (FILE *file,
{
tmp = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, fnaddr), UNSPEC_GOTPCREL);
tmp = gen_rtx_CONST (Pmode, tmp);
- fnaddr = gen_rtx_MEM (QImode, tmp);
+ fnaddr = gen_rtx_MEM (Pmode, tmp);
}
}
else
--cut here--
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835
--- Comment #21 from Mikael Pettersson mikpe at it dot uu.se 2011-07-12
15:42:35 UTC ---
The problem is that LIBGNAT_TARGET_PAIRS is applied too late, and stage 1, 2,
and 3 gnat1 etc are built out of a fixed set of source files that your target
fragment in gcc/ada/gcc-interface/Makefile.in cannot influence (AFAIK).
You can observe this easily with a bootstrap on e.g. i686-linux. On that
platform system.ads should be replaced by system-linux-x86.ads, but the build
log clearly shows stage 1, 2, 3 compiling the default gcc/ada/system.ads from
the gcc source dir and linking that .o file into gnat1 etc. It's not until
some time after stage 3 that the build directory's gcc/ada/rts/ is populated
according to LIBGNAT_TARGET_PAIRS, allowing system-linux-x86.ads to get used.
But that's too late for m68k, since the type-incorrect s-memory.ad{b,s} have
already been compiled and linked into the intermediate gnat1 etc, which then
crash in stage 2.
So I'm now patching s-memory.ad{b,s} instead. Assuming the current bootstrap
succeeds (sometime late tomorrow) I'll post my full patch for 4.5.3.
[Bug target/49714] [4.7 Regression] Revision 176128 introduced many ICEs in insn_default_length, at config/i386/i386.md:600
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49714 --- Comment #2 from Richard Henderson rth at gcc dot gnu.org 2011-07-12 15:46:13 UTC --- Author: rth Date: Tue Jul 12 15:46:02 2011 New Revision: 176208 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176208 Log: PR target/49714 * config/i386/i386.c (x86_output_mi_thunk): Fix mode for destination address in memory on some paths. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/49714] [4.7 Regression] Revision 176128 introduced many ICEs in insn_default_length, at config/i386/i386.md:600
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49714 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Richard Henderson rth at gcc dot gnu.org 2011-07-12 15:47:53 UTC --- Fixed. Both the instance you noticed, Uros, but also another along the i386 mach-o path.
[Bug c/49716] internal compiler error: in new_Cloog_Domain_from_ppl_Pointset_Powerset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49716 --- Comment #2 from stephan at openelec dot tv 2011-07-12 16:20:12 UTC --- Created attachment 24745 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24745 preprocessed source math.o
[Bug other/32998] -frecord-gcc-switches issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32998 --- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-12 16:26:10 UTC --- Created attachment 24746 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24746 gcc47-pr32998.patch Untested patch to implement a new switch, -grecord-gcc-switches, which records passed options as a string appended to DW_AT_producer attribute in .debug_info. Apparently we aren't the first compiler to do that based on the dwarf2out.c comments... The main intent is to have the code generation options in there, as Roland said, -D* etc. options should be investigable through -g3 .debug_macinfo (especially if we manage to cut it down considerably), similarly -I/-i* etc. options related to preprocessing are either in .debug_macinfo and/or in .debug_line). If possible I'd like not to see filenames and paths in the string. I'm not entirely happy with it this way, as if passed command line options override each other, this approach will print all of them in the order specified (say -O2 -O3 -O0 inserts -O2 -O3 -O0 instead of just -O0) and due to the overriding the options can't be sorted, which would increase the likelyhood that the DW_AT_producer strings are mergeable between many object files. Joseph, is there a way to instead iterate over the explicitly passed options after override processing? I see global_options_set, but not sure what exactly to expect from it.
[Bug target/49714] [4.7 Regression] Revision 176128 introduced many ICEs in insn_default_length, at config/i386/i386.md:600
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49714 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-07-12 16:28:28 UTC --- Still fails with -m32: [macbook] f90/bug% g++47 -m32 /opt/gcc/work/gcc/testsuite/g++.old-deja/g++.other/dyncast1.C /opt/gcc/work/gcc/testsuite/g++.old-deja/g++.other/dyncast1.C: In member function 'void E::_ZThn4_N1ED1Ev()': /opt/gcc/work/gcc/testsuite/g++.old-deja/g++.other/dyncast1.C:123:1: error: unrecognizable insn: (jump_insn 3 2 4 (set (pc) (mem:SI (symbol_ref/i:SI (_ZN1ED1Ev) [flags 0x1] function_decl 0x142cb3600 __comp_dtor ) [0 S4 A8])) -1 (nil)) /opt/gcc/work/gcc/testsuite/g++.old-deja/g++.other/dyncast1.C:123:1: internal compiler error: in insn_default_length, at config/i386/i386.md:600
[Bug middle-end/49705] -Wstrict-overflow should not diagnose unevaluated expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49705 --- Comment #4 from eggert at gnu dot org 2011-07-12 16:30:44 UTC --- Created attachment 24747 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24747 longer, more-realistic test case Thanks for looking into the problem. If it helps, attached is a longer test case that more-closely corresponds to the original problem that I had with the Emacs source code.
[Bug regression/49500] [4.7 Regression]: gcc.dg/tls/alias-1.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49500 Ulrich Weigand uweigand at gcc dot gnu.org changed: What|Removed |Added CC||uweigand at gcc dot gnu.org --- Comment #10 from Ulrich Weigand uweigand at gcc dot gnu.org 2011-07-12 16:30:17 UTC --- This problem exists on spu-elf as well, and the patch fixes it there too.
[Bug middle-end/49705] -Wstrict-overflow should not diagnose unevaluated expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49705 --- Comment #5 from Ian Lance Taylor ian at airs dot com 2011-07-12 16:42:07 UTC --- My proposed patch also fixes the larger test case. Without the patch I see this: strict-overflow-bug.c: In function ‘check_image_width’: strict-overflow-bug.c:14:4: warning: assuming signed overflow does not occur when assuming that (X + c) = X is always true [-Wstrict-overflow] With the patch I see no warning. This is compiling with -O2 -Wstrict-overflow.
[Bug c/49716] internal compiler error: in new_Cloog_Domain_from_ppl_Pointset_Powerset
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49716 --- Comment #3 from Sebastian Pop spop at gcc dot gnu.org 2011-07-12 16:54:49 UTC --- trunk@176058 from Fri Jul 8 19:15:18 2011 does not ICE. I have not tried 4.6.
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835
Eric Botcazou ebotcazou at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.07.12 17:05:07
Ever Confirmed|0 |1
--- Comment #22 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-07-12
17:05:07 UTC ---
The problem is that LIBGNAT_TARGET_PAIRS is applied too late, and stage 1, 2,
and 3 gnat1 etc are built out of a fixed set of source files that your target
fragment in gcc/ada/gcc-interface/Makefile.in cannot influence (AFAIK).
Yes, the full run-time is built only after the compiler is built.
You can observe this easily with a bootstrap on e.g. i686-linux. On that
platform system.ads should be replaced by system-linux-x86.ads, but the build
log clearly shows stage 1, 2, 3 compiling the default gcc/ada/system.ads from
the gcc source dir and linking that .o file into gnat1 etc. It's not until
some time after stage 3 that the build directory's gcc/ada/rts/ is populated
according to LIBGNAT_TARGET_PAIRS, allowing system-linux-x86.ads to get used.
It is populated only at the beginning of the build of the full run-time. So,
in particular, system.ads is indeed used for the compiler proper in all stages.
But that's too late for m68k, since the type-incorrect s-memory.ad{b,s} have
already been compiled and linked into the intermediate gnat1 etc, which then
crash in stage 2.
OK, this is more involved than envisioned initially. I can propose a slight
variant of my earlier proposal: still the attribute, but gigi (interface
between front-end and middle-end) would be responsible for setting it on the
malloc-like functions used in Ada.
[Bug target/49713] Conflicting types for 'arm_dbx_register_number'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49713 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.12 17:14:43 CC||danglin at gcc dot gnu.org Ever Confirmed|0 |1
[Bug target/49714] [4.7 Regression] Revision 176128 introduced many ICEs in insn_default_length, at config/i386/i386.md:600
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49714 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|WAITING AssignedTo|unassigned at gcc dot |rth at gcc dot gnu.org |gnu.org | --- Comment #5 from Richard Henderson rth at gcc dot gnu.org 2011-07-12 17:18:56 UTC --- Created attachment 24748 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24748 i686-darwin cleanup This appears as if it might work. I can't seem to trigger the branch island path here. It looks like only darwin8 needs this, and even configuring for i686-apple-darwin8 doesn't trigger.
[Bug target/49713] Conflicting types for 'arm_dbx_register_number'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49713 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rth at gcc dot gnu.org |gnu.org | --- Comment #1 from Richard Henderson rth at gcc dot gnu.org 2011-07-12 17:21:03 UTC --- Mine.
[Bug c++/47606] [trans-mem] internal compiler error in expand_block_tm with O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47606 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|NEW AssignedTo|rth at gcc dot gnu.org |unassigned at gcc dot ||gnu.org --- Comment #10 from Richard Henderson rth at gcc dot gnu.org 2011-07-12 17:22:22 UTC --- Not working on it atm.
[Bug target/49714] [4.7 Regression] Revision 176128 introduced many ICEs in insn_default_length, at config/i386/i386.md:600
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49714 --- Comment #6 from Iain Sandoe iains at gcc dot gnu.org 2011-07-12 17:28:35 UTC --- (In reply to comment #5) Created attachment 24748 [details] i686-darwin cleanup This appears as if it might work. I can't seem to trigger the branch island path here. It looks like only darwin8 needs this, and even configuring for i686-apple-darwin8 doesn't trigger. hm. doing a cross to darwin-8 should produce the requirement for stubs and branch islands (the latter, I think are ppc only). You should also be able to trigger the branch island path by using -mmacosx-version-min=10.4 on Darwin 9 or 10 (when building for PPC). This should also also trigger generation of stubs for function calls on m32 x86 and ppc. (will try and look later - but tied up with other hassles right now)
[Bug middle-end/44382] Slow integer multiply
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44382
William J. Schmidt wschmidt at gcc dot gnu.org changed:
What|Removed |Added
CC||wschmidt at gcc dot gnu.org
--- Comment #7 from William J. Schmidt wschmidt at gcc dot gnu.org 2011-07-12
17:33:06 UTC ---
The test case from bug 45671 is as follows:
int myfunction (int a, int b, int c, int d, int e, int f, int g, int h) {
int ret;
ret = a + b + c + d + e + f + g + h;
return ret;
}
Compiling with -O3 results in a series of dependent add instructions to
accumulate the sum.
add 4,3,4
add 4,4,5
add 4,4,6
add 4,4,7
add 4,4,8
add 4,4,9
add 4,4,10
If we regrouped to (a+b)+(c+d)+... we can do multiple adds in parallel on
different execution units.
[Bug lto/48851] lto-plugin.c:224:7: error: missing sentinel in function call [-Werror=format]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48851
m...@gcc.gnu.org mrs at gcc dot gnu.org changed:
What|Removed |Added
CC||mrs at gcc dot gnu.org
--- Comment #22 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org 2011-07-12
18:03:23 UTC ---
Try:
Doing diffs in fixincludes:
--- fixincludes/inclhack.def.~1~2011-06-15 18:47:49.0 -0700
+++ fixincludes/inclhack.def2011-07-12 11:01:35.0 -0700
@@ -4417,6 +4417,7 @@ fix = {
files = sys/types.h;
/* avoid changing C++ friendly NULL */
bypass= __cplusplus;
+bypass= __null;
select= ^#[ \t]*define[ \t]+NULL[ \t]+\\(\\(void[ \t]*\\*\\)0\\);
c_fix = format;
c_fix_arg = #define NULL 0;
--
and let me know if it works. If so, I'd propose this.
[Bug c++/49720] New: Infinite recursion compiling gold binary_test.cc testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49720
Summary: Infinite recursion compiling gold binary_test.cc
testcase
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: r...@gcc.gnu.org
Host: i386-pc-solaris2.11
Target: i386-pc-solaris2.11
Build: i386-pc-solaris2.11
While compiling the gold testcast binary_test.cc, cc1plus SEGVed:
$ cc1plus -O2 sgr.ii
int main()
Analyzing compilation unit
Performing interprocedural optimizations
*free_lang_data visibility early_local_cleanups whole-program
profile_estimate cp inline pure-const static-varAssembling functions:
int main()Segmentation Fault
In gdb, I find that there's either a deep (depth 22000) or infinite recursion
in simplify_gen_relational:
#0 0x084c220d in swap_commutative_operands_p (x=0xfed6a1d0, y=0xfed6a200)
at /vol/gcc/src/hg/trunk/local/gcc/rtlanal.c:3111
#1 0x084ea80a in simplify_binary_operation (code=PLUS, mode=SImode,
op0=0xfed6a1d0, op1=0xfed6a200)
at /vol/gcc/src/hg/trunk/local/gcc/simplify-rtx.c:1899
#2 0x084f0d4f in simplify_plus_minus (code=Unhandled dwarf expression opcode
0xf3
)
at /vol/gcc/src/hg/trunk/local/gcc/simplify-rtx.c:4064
#3 0x084eb7f9 in simplify_binary_operation_1 (code=MINUS, mode=SImode,
op0=0xfd41966c, op1=0xfed6a1d0)
at /vol/gcc/src/hg/trunk/local/gcc/simplify-rtx.c:2308
#4 simplify_binary_operation (code=MINUS, mode=SImode, op0=0xfd41966c,
op1=0xfed6a1d0) at /vol/gcc/src/hg/trunk/local/gcc/simplify-rtx.c:1910
#5 0x084f5d88 in simplify_const_relational_operation (code=EQ, mode=SImode,
op0=0xfd41966c, op1=value optimized out)
at /vol/gcc/src/hg/trunk/local/gcc/simplify-rtx.c:4559
#6 0x084e9f5e in simplify_relational_operation (code=EQ, mode=CCZmode,
cmp_mode=SImode, op0=0xfed6a1d0, op1=0xfd41966c)
at /vol/gcc/src/hg/trunk/local/gcc/simplify-rtx.c:4184
#7 0x084ea736 in simplify_gen_relational (code=EQ, mode=CCZmode,
cmp_mode=SImode, op0=0xfed6a1d0, op1=0xfd41966c)
at /vol/gcc/src/hg/trunk/local/gcc/simplify-rtx.c:401
#8 0x084ea736 in simplify_gen_relational (code=EQ, mode=CCZmode,
cmp_mode=SImode, op0=0xfed6a1f0, op1=0xfd419660)
Here's the simplified testcase:
extern char t_start[], t_end[], t_size[];
int
main(void)
{
int size = reinterpret_castint(t_size);
return (size == t_end - t_start);
}
[Bug target/49714] [4.7 Regression] Revision 176128 introduced many ICEs in insn_default_length, at config/i386/i386.md:600
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49714 --- Comment #7 from Richard Henderson rth at gcc dot gnu.org 2011-07-12 18:20:33 UTC --- Author: rth Date: Tue Jul 12 18:20:29 2011 New Revision: 176211 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176211 Log: PR target/49714 * config/i386/i386.c (x86_output_mi_thunk): Use machopic_indirect_call_target instead of machopic_indirection_name directly. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug rtl-optimization/49474] [4.7 Regression] ppc ICEs with -O3 (bootstrapping with -O3 and --disable-checking)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49474 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org |
[Bug target/49714] [4.7 Regression] Revision 176128 introduced many ICEs in insn_default_length, at config/i386/i386.md:600
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49714 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #8 from Richard Henderson rth at gcc dot gnu.org 2011-07-12 18:37:29 UTC --- Fixed. Again.
[Bug target/49713] Conflicting types for 'arm_dbx_register_number'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49713 --- Comment #2 from Richard Henderson rth at gcc dot gnu.org 2011-07-12 18:41:48 UTC --- Author: rth Date: Tue Jul 12 18:41:44 2011 New Revision: 176212 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176212 Log: PR target/49713 * dwarf2out.h (dwarf_frame_regnum): Remove. * dwarf2out.c (based_loc_descr): Revert last change. Initialize regno earlier from DWARF_FRAME_REGNUM. Never use dbx_reg_number. * dwarf2cfi.c (dw_stack_pointer_regnum, dw_frame_pointer_regnum): New. (execute_dwarf2_frame): Initialize them. (DW_STACK_POINTER_REGNUM, DW_FRAME_POINTER_REGNUM): Remove; replace users of the macros with the variables. (expand_builtin_dwarf_sp_column): Revert last change. (expand_builtin_init_dwarf_reg_sizes): Likewise. Compute the result of DWARF_FRAME_REGNUM into a local variable. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2cfi.c trunk/gcc/dwarf2out.c trunk/gcc/dwarf2out.h
[Bug rtl-optimization/49474] [4.7 Regression] ppc ICEs with -O3 (bootstrapping with -O3 and --disable-checking)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49474 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2011-07-12 18:46:13 UTC --- Author: pinskia Date: Tue Jul 12 18:46:10 2011 New Revision: 176213 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176213 Log: 2011-07-12 Andrew Pinski pins...@gmail.com PR rtl-opt/49474 * cprop.c (find_implicit_sets): Correct the condition. 2011-07-12 Andrew Pinski pins...@gmail.com PR rtl-opt/49474 * gcc.c-torture/compile/pr49474.c: New testcase. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr49474.c Modified: trunk/gcc/ChangeLog trunk/gcc/cprop.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/49474] [4.7 Regression] ppc ICEs with -O3 (bootstrapping with -O3 and --disable-checking)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49474 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||patch Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2011-07/msg00949.htm ||l Resolution||FIXED --- Comment #6 from Andrew Pinski pinskia at gcc dot gnu.org 2011-07-12 18:46:54 UTC --- Fixed.
[Bug middle-end/49721] New: convert_memory_address_addr_space may generate invalid new insns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49721 Summary: convert_memory_address_addr_space may generate invalid new insns Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com When convert_memory_address_addr_space is called by simplify_unary_operation_1, it may generate new insns if Pmode != ptr_mode. But new insns aren't allowed from simplify_unary_operation_1.
[Bug target/49713] Conflicting types for 'arm_dbx_register_number'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49713 Richard Henderson rth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Richard Henderson rth at gcc dot gnu.org 2011-07-12 19:24:40 UTC --- Fixed.
[Bug c++/49722] New: G++ doens't allow compilation with extern C and C99 inside
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49722 Summary: G++ doens't allow compilation with extern C and C99 inside Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: anton.koch...@gmail.com Any gcc version. If you want use C99-standard conformant code inside extern C - it cant build. Option -std=c99 is ignored by g++.
[Bug c++/49722] G++ doens't allow compilation with extern C and C99 inside
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49722 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-07-12 19:41:15 UTC --- extern C does not mean compile this code as C but rather it means the linkage of the function/variable is C rather than the standard C++ linkage.
[Bug c++/49722] G++ doens't allow compilation with extern C and C99 inside
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49722 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution||INVALID --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-12 19:49:31 UTC --- Yeah, the source inside extern C block still needs to be valid C++.
[Bug middle-end/49719] [4.7 Regression] test gcc.target/arm/sibcall-1.c fails for ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49719 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Target|arm |arm-*-* Target Milestone|--- |4.7.0 Summary|test|[4.7 Regression] test |gcc.target/arm/sibcall-1.c |gcc.target/arm/sibcall-1.c |fails for ARM |fails for ARM
[Bug rtl-optimization/49720] Infinite recursion compiling gold binary_test.cc testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49720 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target|i386-pc-solaris2.11 |i386-pc-solaris2.11, ||i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2011.07.12 20:43:20 Component|c++ |rtl-optimization Ever Confirmed|0 |1 Known to fail||4.5.3, 4.6.1, 4.7.0 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-12 20:43:20 UTC --- I think I've also seen this ICE with 4.6 and on i?86-linux. Confirmed on x86_64-darwin with -O2 -m32 back to the 4.5 branch (no idea for earlier releases).
[Bug tree-optimization/49309] [4.6/4.7 Regression] ICE with -fmudflap: verify_stmts failed: type mismatch in pointer plus expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49309 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.07.12 21:06:29 AssignedTo|unassigned at gcc dot |pinskia at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2011-07-12 21:06:29 UTC --- Simple fix: Index: tree-mudflap.c === --- tree-mudflap.c(revision 62112) +++ tree-mudflap.c(working copy) @@ -869,7 +869,7 @@ mf_xform_derefs_1 (gimple_stmt_iterator break; case MEM_REF: - addr = build2 (POINTER_PLUS_EXPR, TREE_TYPE (TREE_OPERAND (t, 1)), + addr = fold_build2_loc (location, POINTER_PLUS_EXPR, TREE_TYPE (TREE_OPERAND (t, 1)), TREE_OPERAND (t, 0), fold_convert (sizetype, TREE_OPERAND (t, 1))); base = addr;
[Bug lto/47889] [4.6/4.7 Regression] Segmentation fault in useless_type_conversion_p, at tree-ssa.c:1228
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47889 --- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2011-07-12 21:17:31 UTC --- (In reply to comment #2) Confirmed. We should diagnose this. We do: t.c:1:13: warning: type of ‘s’ does not match original declaration [enabled by default] t1.c:1:14: note: previously declared here --- CUT --- But we don't error out.
[Bug tree-optimization/49309] [4.6/4.7 Regression] ICE with -fmudflap: verify_stmts failed: type mismatch in pointer plus expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49309 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-12 21:18:50 UTC --- Hm, I'd say rather - addr = build2 (POINTER_PLUS_EXPR, TREE_TYPE (TREE_OPERAND (t, 1)), + addr = fold_build2_loc (location, POINTER_PLUS_EXPR, TREE_TYPE (TREE_OPERAND (t, 0)),
[Bug lto/47889] [4.6/4.7 Regression] Segmentation fault in useless_type_conversion_p, at tree-ssa.c:1228
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47889 --- Comment #5 from Richard Guenther rguenth at gcc dot gnu.org 2011-07-12 21:20:57 UTC --- Yeah, well. There are legitimate cases (read: in SPEC2k6), so we can't error out in general (the cases are mixing float and int for example).
[Bug middle-end/49705] -Wstrict-overflow should not diagnose unevaluated expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49705 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ian at airs dot com |gnu.org | --- Comment #6 from Ian Lance Taylor ian at airs dot com 2011-07-12 22:47:33 UTC --- Patch tested and sent for approval. http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00971.html
[Bug middle-end/49723] New: gcc.c-torture/compile/pr46934.c: ICE in do_SUBST, at combine.c:707 at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49723 Summary: gcc.c-torture/compile/pr46934.c: ICE in do_SUBST, at combine.c:707 at -O1 and above Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa*-*-* Target: hppa*-*-* Build: hppa*-*-* Executing on host: /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ -O1 -w -c -o pr46934.o /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr 46934.c(timeout = 300) /test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr46934.c: In function 'caller':/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr46934.c:17:1: internal c ompiler error: in do_SUBST, at combine.c:707
[Bug middle-end/49723] gcc.c-torture/compile/pr46934.c: ICE in do_SUBST, at combine.c:707 at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49723 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Target|hppa*-*-hpux* |hppa64-*-* Host|hppa*-*-hpux* |hppa64-*-* Build|hppa*-*-hpux* |hppa64-*-* --- Comment #1 from John David Anglin danglin at gcc dot gnu.org 2011-07-13 00:19:10 UTC --- 0x44d67bac do_SUBST+172:b,l 0x44d9a290 .stub,rp 0x44d67bb0 do_SUBST+176:nop 0x44d67bb4 do_SUBST+180:copy r4,dp 0x44d67bb8 do_SUBST+184:cmpb,*=,n ret0,r6,0x44d67bf0 do_SUBST+240 (gdb) p/x $r6 $6 = 0x8000 (gdb) p/x $ret0 $7 = 0x8000 newval ($r6) doesn't appear valid.
[Bug middle-end/49723] gcc.c-torture/compile/pr46934.c: ICE in do_SUBST, at combine.c:707 at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49723
John David Anglin danglin at gcc dot gnu.org changed:
What|Removed |Added
CC||ebotcazou at gcc dot
||gnu.org
--- Comment #2 from John David Anglin danglin at gcc dot gnu.org 2011-07-13
01:09:39 UTC ---
(gdb) bt
#0 do_SUBST (into=0x417aa1e8, newval=0x4170cfb4) at
../../gcc/gcc/combine.c:706
#1 0x0029981a in subst (x=0x417aa1e0, from=0x417a52a0, to=0x4170cfb4,
in_dest=0, in_cond=0, unique_copy=0) at ../../gcc/gcc/combine.c:5227
#2 0x002996b7 in subst (x=0x41712ed0, from=0x417a52a0, to=0x4170cfb4,
in_dest=0, in_cond=0, unique_copy=0) at ../../gcc/gcc/combine.c:5189
#3 0x00292c99 in try_combine (i3=0x4176a84c, i2=0x4176a828, i1=0x0, i0=0x0,
new_direct_jump_p=0xb034, last_combined_insn=0x4176a84c) at
../../gcc/gcc/combine.c:3178
#4 0x0028cb6d in combine_instructions (f=0x417135c0, nregs=81) at
../../gcc/gcc/combine.c:1223
#5 0x002b1eb8 in rest_of_handle_combine () at ../../gcc/gcc/combine.c:13878
#6 0x0070bfda in execute_one_pass (pass=0xcf3360) at
../../gcc/gcc/passes.c:2063
#7 0x0070c477 in execute_pass_list (pass=0xcf3360) at
../../gcc/gcc/passes.c:2118
#8 0x0070c493 in execute_pass_list (pass=0xd44320) at
../../gcc/gcc/passes.c:2119
#9 0x0090a5ee in tree_rest_of_compilation (fndecl=0x41785300) at
../../gcc/gcc/tree-optimize.c:416
#10 0x00289022 in cgraph_expand_function (node=0x4178d000) at
../../gcc/gcc/cgraphunit.c:1804
#11 0x00289202 in cgraph_expand_all_functions () at
../../gcc/gcc/cgraphunit.c:1863
#12 0x00289a4a in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:2133
#13 0x002860d9 in cgraph_finalize_compilation_unit () at
../../gcc/gcc/cgraphunit.c:1304
#14 0x00038838 in c_write_global_declarations () at ../../gcc/gcc/c-decl.c:9844
#15 0x00830b46 in compile_file () at ../../gcc/gcc/toplev.c:564
#16 0x0083375f in do_compile () at ../../gcc/gcc/toplev.c:1886
#17 0x00833940 in toplev_main (argc=13, argv=0xb400) at
../../gcc/gcc/toplev.c:1958
#18 0x00149e0f in main (argc=13, argv=0xb400) at ../../gcc/gcc/main.c:36
(gdb) p debug_rtx (i3)
(insn 9 8 10 2 (set (reg:SI 73)
(minus:SI (reg:SI 26 %r26 [ reg_type ])
(reg:SI 74)))
/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr46934.c:3 168
{*pa.md:5239}
(expr_list:REG_DEAD (reg:SI 26 %r26 [ reg_type ])
(expr_list:REG_DEAD (reg:SI 74)
(nil
$4 = void
(gdb) p debug_rtx (i2)
(insn 8 7 9 2 (set (reg:SI 74)
(const_int 2147483648 [0x8000]))
/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/compile/pr46934.c:3 71
{*pa.md:2130}
(nil))
$5 = void
This is how insn 8 is generated:
(gdb) bt
#0 emit_move_sequence (operands=0xbfffe904, mode=SImode, scratch_reg=0x0) at
../../gcc/gcc/config/pa/pa.c:1541
#1 0x00171709 in gen_movsi (operand0=0x417a52a0, operand1=0x4170cfb4) at
pa.md:2048
#2 0x003a97e6 in emit_move_insn_1 (x=0x417a52a0, y=0x4170cfb4) at
../../gcc/gcc/expr.c:3280
#3 0x003a9c63 in emit_move_insn (x=0x417a52a0, y=0x4170cfb4) at
../../gcc/gcc/expr.c:3370
#4 0x00388537 in force_reg (mode=SImode, x=0x4170cfb4) at
../../gcc/gcc/explow.c:671
#5 0x00178945 in gen_casesi (operand0=0x41712e94, operand1=0x41712ea0,
operand2=0x4170c36c, operand3=0x4176a7e0, operand4=0x4176a72c) at pa.md:6918
#6 0x006fc425 in maybe_gen_insn (icode=CODE_FOR_casesi, nops=5,
ops=0xbfffebb0) at ../../gcc/gcc/optabs.c:7259
#7 0x006fc533 in maybe_expand_jump_insn (icode=CODE_FOR_casesi, nops=5,
ops=0xbfffebb0) at ../../gcc/gcc/optabs.c:7290
#8 0x006fc5cb in expand_jump_insn (icode=CODE_FOR_casesi, nops=5,
ops=0xbfffebb0) at ../../gcc/gcc/optabs.c:7316
#9 0x003dbe85 in try_casesi (index_type=0x417153c0, index_expr=0x411e8554,
minval=0x4172101c, range=0x4178ad3c, table_label=0x4176a7e0,
default_label=0x4176a72c, fallback_label=0x4176a750) at
../../gcc/gcc/expr.c:10152
#10 0x00814841 in expand_case (stmt=0x417a6000) at ../../gcc/gcc/stmt.c:2505
#11 0x0024c13d in expand_gimple_stmt_1 (stmt=0x417a6000) at
../../gcc/gcc/cfgexpand.c:1918
#12 0x0024ca1d in expand_gimple_stmt (stmt=0x417a6000) at
../../gcc/gcc/cfgexpand.c:2071
#13 0x00258312 in expand_gimple_basic_block (bb=0x417a7080) at
../../gcc/gcc/cfgexpand.c:3805
#14 0x0025b646 in gimple_expand_cfg () at ../../gcc/gcc/cfgexpand.c:4288
#15 0x0070bfda in execute_one_pass (pass=0xcf2f60) at
../../gcc/gcc/passes.c:2063
#16 0x0070c477 in execute_pass_list (pass=0xcf2f60) at
../../gcc/gcc/passes.c:2118
#17 0x0090a5ee in tree_rest_of_compilation (fndecl=0x41785300) at
../../gcc/gcc/tree-optimize.c:416
#18 0x00289022 in cgraph_expand_function (node=0x4178d000) at
../../gcc/gcc/cgraphunit.c:1804
#19 0x00289202 in cgraph_expand_all_functions () at
../../gcc/gcc/cgraphunit.c:1863
#20 0x00289a4a in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:2133
#21 0x002860d9 in cgraph_finalize_compilation_unit () at
[Bug ada/49724] New: [4.6/4.7 Regression] FAIL: gnat.dg/socket1.adb execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49724 Summary: [4.6/4.7 Regression] FAIL: gnat.dg/socket1.adb execution test Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Executing on host: /mnt/gnu/gcc/objdir-test/gcc/gnatmake --GCC=/mnt/gnu/gcc/objdir-test/gcc/xgcc --GNATBIND=/mnt/gnu/gcc/objdir-test/gcc/gnatbind --GNATLINK=/mnt/gnu/gcc/objdir-test/gcc/gnatlink -cargs -B/mnt/gnu/gcc/objdir-test/gcc -largs --GCC=/mnt/gnu/gcc/objdir-test/gcc/xgcc\ -B/mnt/gnu/gcc/objdir-test/gcc\ -margs --RTS=/mnt/gnu/gcc/objdir-test/hppa2.0w-hp-hpux11.11/./libada -q -f /mnt/gnu/gc c/gcc/gcc/testsuite/gnat.dg/socket1.adb -lm -o ./socket1.exe(timeout = 300) Executing on host: /mnt/gnu/gcc/objdir-test/gcc/gnatclean -c -q -n ./socket1 ( timeout = 300) ./socket1.ali ./socket1.oPASS: gnat.dg/socket1.adb (test for excess errors)Setting LD_LIBRARY_PATH to :/mnt/gnu/gcc/objdir/gcc::/mnt/gnu/gcc/objdir/gccraised GNAT.SOCKETS.HOST_ERROR : [0] Unknown errorFAIL: gnat.dg/socket1.adb execution test Revision 176070 was ok.
[Bug ada/49725] New: [4.6 Regression] FAIL: c34005a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49725 Summary: [4.6 Regression] FAIL: c34005a Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa2.0w-hp-hpux11.11 Target: hppa2.0w-hp-hpux11.11 Build: hppa2.0w-hp-hpux11.11 BUILD c34005a.adb gnatmake --GCC=/mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc/ -gnatws -O2 -I/mnt/gnu/gcc/objdir/gcc/testsuite/ada/acats/support c34005a.adb -largs -- GCC=/mnt/gnu/gcc/objdir/gcc/xgcc -B/mnt/gnu/gcc/objdir/gcc//mnt/gnu/gcc/objdir/gcc/xgcc -c -B/mnt/gnu/gcc/objdir/gcc/ -gnatws -O2 -I/mnt/gnu/gcc/objdir/gcc/testsuite/ada/acats/support c34005a.adb +===GNAT BUG DETECTED==+| 4.6.2 20110711 (prerelease) [gcc-4_6-branch revision 176188] (hppa2.0w-hp-hpux 11.11) GCC error:| | in gimplify_expr, at gimplify.c:7315 || Error detected around c34005a.adb:37:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. Consider also -gnatd.n switch (see debug.adb). /mnt/gnu/gcc/objdir/gcc/ada/rts/system.ads c34005a.adb /mnt/gnu/gcc/objdir/gcc/testsuite/ada/acats/support/report.ads /mnt/gnu/gcc/objdir/gcc/ada/rts/s-secsta.ads /mnt/gnu/gcc/objdir/gcc/ada/rts/s-stoele.ads /mnt/gnu/gcc/objdir/gcc/ada/rts/s-stoele.adb /mnt/gnu/gcc/objdir/gcc/ada/rts/ada.ads /mnt/gnu/gcc/objdir/gcc/ada/rts/a-unccon.ads /mnt/gnu/gcc/objdir/gcc/ada/rts/s-soflin.ads /mnt/gnu/gcc/objdir/gcc/ada/rts/a-except.ads /mnt/gnu/gcc/objdir/gcc/ada/rts/s-parame.ads /mnt/gnu/gcc/objdir/gcc/ada/rts/s-stalib.ads /mnt/gnu/gcc/objdir/gcc/ada/rts/s-traent.ads /mnt/gnu/gcc/objdir/gcc/ada/rts/s-stache.ads raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:423 gnatmake: c34005a.adb compilation error FAIL: c34005a Revision 176070 was ok.
[Bug driver/49726] New: -g0 file.S -g does not produce debug info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49726 Summary: -g0 file.S -g does not produce debug info Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassig...@gcc.gnu.org ReportedBy: jan.kratoch...@redhat.com Target: x86_64-fedora15-linux-gnu Build: x86_64-fedora15-linux-gnu FAIL: gcc (GCC) 4.4.7 20110712 (prerelease) FAIL: gcc (GCC) 4.5.4 20110712 (prerelease) FAIL: gcc (GCC) 4.6.2 20110713 (prerelease) FAIL: gcc (GCC) 4.7.0 20110713 (experimental) gcc -c -o 1.o 1.c -g: debug info produced gcc -c -o 1.o 1.S -g: debug info produced gcc -c -o 1.o -g0 1.c -g: debug info produced gcc -c -o 1.o -g0 1.S -g: debug info not produced - IMO a bug Why .c and .S behave differently wrt -g application rules? Sure for .S there is just the .debug_line relevant.
