[Bug middle-end/27116] [4.2 Regression] Incorrect integer division (wrong sign).
--- Comment #17 from vincent at vinc17 dot org 2006-06-08 07:18 --- The patch looks strange to me too: is there any reason why the optimization would be correct under wrapping? i.e. I don't understand why -fwrapv can "fix" the problem (as said in comment #1). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27116
[Bug c/27948] New: MS -bitfield struct layout test fails
Since this revision:
2006-06-04 Eric Christopher <[EMAIL PROTECTED]>
* stor-layout.c (start_record_layout): Initialize
remaining_in_alignment.
(debug_rli): Output value for remaining_in_alignment.
(update_alignment_for_field): Unconditionalize
ms_bitfield_layout_p code. Handle non-bitfield fields. Remove
extra alignment code.
(place_field): Don't realign if ms_bitfield_layout_p. Unconditionalize
ms_bitfield_layout_p code. Rewrite handling of structure fields.
* tree.h (record_layout_info_s): Remove prev_packed.
* doc/extend.texi (ms_struct): Add documentation of format.
The ms-bitfield test gcc.dg/bf-ms-layout.c fails.
In particular, the 0-size bitfield in
struct six {
char a :8;
int :0; /* not ignored; prior field IS a bitfield, causes
struct alignment as well. */
char b;
char c;
} ;
is being ignored
I have reconfirmed that that the test does indeed pass with MS VC6 compiler.
Danny
--
Summary: MS -bitfield struct layout test fails
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dannysmith at users dot sourceforge dot net
GCC build triplet: i686-pc-mingw32
GCC host triplet: i686-pc-mingw32
GCC target triplet: i686-pc-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27948
[Bug ada/27944] s-taprop.adb:66:06: warning: redundant with clause in body
--- Comment #2 from charlet at adacore dot com 2006-06-08 07:57 --- Subject: Re: s-taprop.adb:66:06: warning: redundant with clause in body > Probably introduced by the following change: And/or by a new GNAT warning. Anyway, the fix should be trivial: simply follow GNAT's advice and remove the with clause. Change preapproved. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27944
[Bug ada/27936] [4.2 Regression] gnatbind fails to link on Tru64 UNIX
--- Comment #3 from charlet at adacore dot com 2006-06-08 08:03 --- Subject: Re: New: gnatbind fails to link on Tru64 UNIX > Add ada/s-purexc.o to ada/Make-lang.in (GNATBIND_OBJS). > > If this is considered the correct fix, I'll submit a proper patch. This shouldn't be needed at first sight, so this is likely not the right fix. Arno -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27936
[Bug rtl-optimization/26449] [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invariant motion
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-06-08 08:17 --- Subject: Bug 26449 Author: rakdver Date: Thu Jun 8 08:17:05 2006 New Revision: 114481 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114481 Log: PR rtl-optimization/26449 * loop-invariant.c (move_invariant_reg): Fail if force_operand fails. * gcc.dg/pr26449.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr26449.c Modified: trunk/gcc/ChangeLog trunk/gcc/loop-invariant.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug rtl-optimization/27872] Internal compiler error in verify_loop_structure
--- Comment #4 from rakdver at gcc dot gnu dot org 2006-06-08 08:20 --- Subject: Bug 27872 Author: rakdver Date: Thu Jun 8 08:19:50 2006 New Revision: 114482 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114482 Log: PR tree-optimization/27872 * tree-ssa-loop-manip.c (tree_unroll_loop): Set EDGE_IRREDUCIBLE_LOOP flag on the new exit edge of the unrolled loop. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-loop-manip.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27872
[Bug tree-optimization/27830] [4.1/4.2 regression] ICE: verify_stmts failed (invalid operand to unary operator)
--- Comment #8 from patchapp at dberlin dot org 2006-06-08 08:26 --- Subject: Bug number PR27830 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00385.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27830
[Bug middle-end/27116] [4.2 Regression] Incorrect integer division (wrong sign).
--- Comment #18 from rguenth at gcc dot gnu dot org 2006-06-08 08:31 --- The transformation -~a to a + 1 is valid with -fwrapv, but with -fwrapv, the further transformation of the division will not happen, because that in turn is not safe for -fwrapv. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27116
[Bug target/15184] [4.0/4.1/4.2 Regression] Direct access to byte inside word not working with -march=pentiumpro
--- Comment #11 from bonzini at gnu dot org 2006-06-08 08:36 --- I would note, however, that Pentium Pro also means Pentium 2/3/M, Core, etc. In practice every Intel chip after the Pentium Pro, except the P4 and Nocona, is based on that pipeline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15184
[Bug middle-end/27116] [4.2 Regression] Incorrect integer division (wrong sign).
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-06-08 08:42 --- Well, ok, with the testcase in comment #1 we hit another problem in negate_expr(_p) which I pointed out before. I'll prepare a followup patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27116
[Bug middle-end/27116] [4.2 Regression] Incorrect integer division (wrong sign).
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-06-08 08:49 --- Subject: Bug 27116 Author: rguenth Date: Thu Jun 8 08:49:19 2006 New Revision: 114483 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114483 Log: 2006-06-08 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/27116 * fold-const.c (negate_expr_p): We can negate BIT_NOT_EXPR only, if overflow is defined and not trapping. (negate_expr): Likewise. * gcc.dg/torture/pr27116.c: New testcase. * gcc.dg/pr15785-1.c: Remove test for invalid transformation. Added: trunk/gcc/testsuite/gcc.dg/torture/pr27116.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pr15785-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27116
[Bug target/27863] [4.2 Regression] ICE in check_cfg, at haifa-sched.c:4615
--- Comment #4 from mkuvyrkov at gcc dot gnu dot org 2006-06-08 08:51 --- Subject: Bug 27863 Author: mkuvyrkov Date: Thu Jun 8 08:51:13 2006 New Revision: 114484 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114484 Log: 2006-06-08 Maxim Kuvyrkov <[EMAIL PROTECTED]> PR target/27863 * haifa-sched.c (unlink_other_notes, unlink_line_notes): Update basic block boundaries. Modified: trunk/gcc/ChangeLog trunk/gcc/haifa-sched.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27863
[Bug target/27863] [4.2 Regression] ICE in check_cfg, at haifa-sched.c:4615
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2006-06-08 08:56 --- Fixed. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27863
[Bug fortran/27588] -fbounds-check should catch substring out of range accesses
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-06-08 09:01 --- I'm writing a patch to add substring bounds checking. I hope to post it in the next few days. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org AssignedTo|unassigned at gcc dot gnu |fxcoudert at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-06-05 21:01:03 |2006-06-08 09:01:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27588
[Bug rtl-optimization/26727] [4.2 Regression] gcc.target/powerpc/doloop-1.c fails
--- Comment #5 from mkuvyrkov at gcc dot gnu dot org 2006-06-08 09:11 --- (In reply to comment #3) > Only the testcase is failing and only due to the scheduler changes (which was > said not to effect other targets besides ia64 which looks like it was wrong). As extended regions by default are disabled now, can, please, someone reconfirm this bug. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added CC||mkuvyrkov at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26727
[Bug bootstrap/26998] bootstrap failure building libdecnumber, ICE in compare_values, tree-vrp.c:432
--- Comment #9 from rguenth at gcc dot gnu dot org 2006-06-08 09:13 --- This now blocks a fix for the wrong-code PR27116, comment #1. The fix for that part of that PR is to not allow negate_expr negate INT_MIN if -fwrapv is not in effect. Now this "simple" fix breaks bootstrap in the here mentioned way. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at redhat dot com OtherBugsDependingO||27116 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-08 09:13:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug bootstrap/26998] bootstrap failure building libdecnumber, ICE in compare_values, tree-vrp.c:432
--- Comment #10 from rguenth at gcc dot gnu dot org 2006-06-08 09:39
---
Testcase:
int decCompareOp (int result)
{
if (result != (int)0x8000)
{
result = -result;
return (result > 0);
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug c/27950] New: [4.2 regression] undefined reference when compiling valgrind 3.2.0
if /usr/local/4.2/bin/gcc4.2.0 -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -m32 -mpreferred-stack-boundary=2 -O -g -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -O2 -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -save-temps -v -MT memcheck_x86_linux-mc_main.o -MD -MP -MF ".deps/memcheck_x86_linux-mc_main.Tpo" -c -o memcheck_x86_linux-mc_main.o `test -f 'mc_main.c' || echo './'`mc_main.c; \ then mv -f ".deps/memcheck_x86_linux-mc_main.Tpo" ".deps/memcheck_x86_linux-mc_main.Po"; else rm -f ".deps/memcheck_x86_linux-mc_main.Tpo"; exit 1; fi Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2-svn/configure --enable-languages=c,c++ --prefix=/usr/local/4.2 --program-suffix=4.2.0 Thread model: posix gcc version 4.2.0 20060603 (experimental) /usr/local/4.2/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1 -E -quiet -v -I. -I. -I.. -I../include -I../VEX/pub -MD memcheck_x86_linux-mc_main.d -MF .deps/memcheck_x86_linux-mc_main.Tpo -MP -MT memcheck_x86_linux-mc_main.o -MQ memcheck_x86_linux-mc_main.o -DHAVE_CONFIG_H -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 mc_main.c -m32 -mpreferred-stack-boundary=2 -mtune=generic -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -fworking-directory -O -O2 -fpch-preprocess -o mc_main.i ignoring nonexistent directory "/usr/local/4.2/lib/gcc/i686-pc-linux-gnu/4.2.0/../../../../i686-pc-linux-gnu/include" ignoring duplicate directory "." #include "..." search starts here: #include <...> search starts here: . .. ../include ../VEX/pub /usr/local/include /usr/local/4.2/include /usr/local/4.2/lib/gcc/i686-pc-linux-gnu/4.2.0/include /usr/include End of search list. /usr/local/4.2/libexec/gcc/i686-pc-linux-gnu/4.2.0/cc1 -fpreprocessed mc_main.i -quiet -dumpbase mc_main.c -m32 -mpreferred-stack-boundary=2 -mtune=generic -auxbase-strip memcheck_x86_linux-mc_main.o -g -O -O2 -Wmissing-prototypes -Winline -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -version -o mc_main.s GNU C version 4.2.0 20060603 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.2.0 20060603 (experimental). GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: a42b76558fd6d6863486421b7e5252eb as -V -Qy -o memcheck_x86_linux-mc_main.o mc_main.s GNU assembler version 2.16.91.0.2 (i586-suse-linux) using BFD version 2.16.91.0.2 20050720 (SuSE Linux) /usr/local/4.2/bin/gcc4.2.0 -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -save-temps -v -o memcheck-x86-linux -static -Wl,-defsym,valt_load_address=0x3800 -nodefaultlibs -nostartfiles -u _start -m32 -Wl,-T,../valt_load_address_x86_linux.lds memcheck_x86_linux-mc_leakcheck.o memcheck_x86_linux-mc_malloc_wrappers.o memcheck_x86_linux-mc_main.o memcheck_x86_linux-mc_translate.o ../coregrind/libcoregrind_x86_linux.a ../VEX/libvex_x86_linux.a -lgcc Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.2-svn/configure --enable-languages=c,c++ --prefix=/usr/local/4.2 --program-suffix=4.2.0 Thread model: posix gcc version 4.2.0 20060603 (experimental) /usr/local/4.2/libexec/gcc/i686-pc-linux-gnu/4.2.0/collect2 -m elf_i386 -static -o memcheck-x86-linux -u _start -L/usr/local/4.2/lib/gcc/i686-pc-linux-gnu/4.2.0 -L/usr/local/4.2/lib/gcc/i686-pc-linux-gnu/4.2.0/../../.. -defsym valt_load_address=0x3800 -T ../valt_load_address_x86_linux.lds memcheck_x86_linux-mc_leakcheck.o memcheck_x86_linux-mc_malloc_wrappers.o memcheck_x86_linux-mc_main.o memcheck_x86_linux-mc_translate.o ../coregrind/libcoregrind_x86_linux.a ../VEX/libvex_x86_linux.a -lgcc memcheck_x86_linux-mc_main.o:(.debug_info+0x9d50): undefined reference to `hacky_auxmaps' collect2: ld returned 1 exit status -- Summary: [4.2 regression] undefined reference when compiling valgrind 3.2.0 Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at pdoerfler dot com GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27950
[Bug bootstrap/26998] bootstrap failure building libdecnumber, ICE in compare_values, tree-vrp.c:432
--- Comment #11 from rguenth at gcc dot gnu dot org 2006-06-08 09:47
---
This one:
/* Apply the operation to each end of the range and see what we end
up with. */
if (code == NEGATE_EXPR
&& !TYPE_UNSIGNED (TREE_TYPE (expr)))
{
/* NEGATE_EXPR flips the range around. */
min = (vr0.max == TYPE_MAX_VALUE (TREE_TYPE (expr)) && !flag_wrapv)
? TYPE_MIN_VALUE (TREE_TYPE (expr))
: fold_unary_to_constant (code, TREE_TYPE (expr), vr0.max);
max = (vr0.min == TYPE_MIN_VALUE (TREE_TYPE (expr)) && !flag_wrapv)
? TYPE_MAX_VALUE (TREE_TYPE (expr))
: fold_unary_to_constant (code, TREE_TYPE (expr), vr0.min);
}
is wrong for
(gdb) print vr0
$3 = {type = VR_ANTI_RANGE, min = 0xb7d2b3a8, max = 0xb7d2b3a8,
equiv = 0x896c298}
(gdb) call debug_generic_expr (vr0.min)
-2147483648
(gdb) call debug_generic_expr (vr0.max)
-2147483648
It needs to read:
min = (vr0.max == TYPE_MIN_VALUE (TREE_TYPE (expr)) && !flag_wrapv)
? TYPE_MAX_VALUE (TREE_TYPE (expr))
: fold_unary_to_constant (code, TREE_TYPE (expr), vr0.max);
values other than TYPE_MIN_VALUE are not special with inversion.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2006-06-08 09:13:37 |2006-06-08 09:47:25
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #6 from martin at mpa-garching dot mpg dot de 2006-06-08 09:51 --- I have now reproduced the problem on two different x86_64 systems. Could you please reopen the PR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug target/27421] [4.0/4.1 regression] ICE with invalid array in struct
--- Comment #12 from patchapp at dberlin dot org 2006-06-08 10:10 --- Subject: Bug number PR target/27421 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00387.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27421
[Bug c++/27951] New: [4.0/4.1/4.2 regression] ICE with invalid anonymous union
The following invalid code snippet triggers an ICE in the C++ frontend since
GCC 4.0.0:
==
void foo()
{
int i;
union { int i; };
}
==
bug.cc: In function 'void foo()':
bug.cc:4: error: redeclaration of 'int i'
bug.cc:3: error: 'int i' previously declared here
bug.cc:4: internal compiler error: tree check: expected tree that contains
'decl minimal' structure, have 'error_mark' in finish_anon_union, at
cp/decl2.c:1121
Please submit a full bug report, [etc.]
Will post a patch soon.
--
Summary: [4.0/4.1/4.2 regression] ICE with invalid anonymous
union
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27951
[Bug c++/27951] [4.0/4.1/4.2 regression] ICE with invalid anonymous union
--- Comment #1 from patchapp at dberlin dot org 2006-06-08 10:20 --- Subject: Bug number PR c++/27951 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00388.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27951
[Bug c++/27951] [4.0/4.1/4.2 regression] ICE with invalid anonymous union
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27951
[Bug target/27421] [4.0/4.1 regression] ICE with invalid array in struct
--- Comment #13 from reichelt at gcc dot gnu dot org 2006-06-08 10:23 --- We do have the same problem with unions. See patch in comment #12. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27421
[Bug target/27421] [4.0/4.1 regression] ICE with invalid array in struct
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|ASSIGNED Last reconfirmed|2006-05-07 03:13:58 |2006-06-08 10:23:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27421
[Bug target/27789] [4.2 Regression] attribute handling fallout from DECL_INITIAL changes
--- Comment #3 from dannysmith at users dot sourceforge dot net 2006-06-08 10:29 --- Patch here: http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00389.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27789
[Bug c++/27952] New: [4.0/4.1/4.2 Regression] ICE with invalid virtual inheritance
The following testcase with invalid virtual inheritance ICEs since GCC 4.0.0:
==
struct A
{
virtual ~A() {}
};
struct B : A, virtual A {};
struct C : A, B {};
C c;
==
bug.cc:6: error: duplicate base type 'A' invalid
bug.cc:8: warning: direct base 'A' inaccessible in 'C' due to ambiguity
bug.cc: In destructor 'virtual C::~C()':
bug.cc:8: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
A more reduced version crashes since GCC 4.1.0:
==
struct A {};
struct B : A, virtual A {};
struct C : B {};
==
bug.cc:7: error: duplicate base type 'A' invalid
bug.cc:9: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.0/4.1/4.2 Regression] ICE with invalid virtual
inheritance
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27952
[Bug c/27953] New: ICE with invalid function definitions
The following invalid code snippet triggers an ICE in the C frontend since
at least GCC 2.95.3:
=
void foo(struct A a) {}
void foo() {}
=
bug.c:1: warning: 'struct A' declared inside parameter list
bug.c:1: warning: its scope is only this definition or declaration, which is
probably not what you want
bug.c:1: error: parameter 1 ('a') has incomplete type
bug.c:2: error: redefinition of 'foo'
bug.c:1: error: previous definition of 'foo' was here
bug.c: In function 'foo':
bug.c:2: internal compiler error: tree check: expected class 'type', have
'exceptional' (error_mark) in store_parm_decls_oldstyle, at c-decl.c:6375
Please submit a full bug report, [etc.]
--
Summary: ICE with invalid function definitions
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27953
[Bug fortran/27954] New: ICE on garbage in DATA statement
The following invalid code snippet causes an ICE since GCC 4.0.0: == subroutine FOO character*20 X 0 data X /'A'/0 end subroutine FOO == In file bug.f:4 data X /'A'/0 1 Error: Syntax error in DATA statement at (1) In file bug.f:6 end subroutine FOO 1 Internal Error at (1): gfc_get_default_type(): Bad symbol -- Summary: ICE on garbage in DATA statement Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, error-recovery, monitored Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27954
[Bug c/27950] [4.2 regression] undefined reference when compiling valgrind 3.2.0
--- Comment #1 from gcc at pdoerfler dot com 2006-06-08 11:00 --- Created an attachment (id=11633) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11633&action=view) preprocessed source Preprocessed source of the file that contains declaration of hacky_auxmaps. Probably, this is not enough to reproduce the failure. valgrind-3.2.0 is available from valgrind.org ./configure make to reproduce at least on x86 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27950
[Bug c++/27955] New: friend members produce different results
I've encoutered a problem with a friend function embedded into a class
declaration AND with the optimisation flag -O2. I have discovered that two
successive identical call to cout<
class A{
friend void load (A* a, float& t){
reinterpret_cast(t) = 1077936128; //binary float
value of 3
}
};
class B{
friend void load (B* b, float& t);
};
void load (B* b, float& t) {
reinterpret_cast(t) = 1077936128; //binary float value
of 3
}
int main(){
float testValue = -1;
//OK
load(new A(), testValue);
std::cout
[Bug middle-end/26807] [4.2 Regression] FAIL: gcc.dg/torture/pr24626-1.c -O2 (test for excess errors)
--- Comment #15 from mkuvyrkov at gcc dot gnu dot org 2006-06-08 11:49 --- haifa_sched.c: check_cfg () ICEs because a block with the conditional jump at the end has only 1 successor (the jump is to the next instruction). I thought that this is invalid, but now I see that verify_flow_info () considers this correct. I will post the patch soon. -- mkuvyrkov at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mkuvyrkov at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-05-08 07:50:12 |2006-06-08 11:49:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26807
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- Comment #10 from bonzini at gnu dot org 2006-06-08 12:08 ---
Reduced testcase:
long foo(long zz)
{
return zz * 15238614669586151335;
}
takes "ridiculously long" with -O2 -mdisable-fpregs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- Comment #11 from bonzini at gnu dot org 2006-06-08 12:24 --- OUCH! The number is stored as a unsigned int in the cache, which means that numbers > 2^32 never hit the cache! Besides that, it's wise to enlarge the cache for 64-bit hosts, because there every EXACT_DIV_EXPR will call synth_mult with a very large multiplier. Time for a -O0 compiler on the reduced testcase is down to 0.3s for 2069 cache entries, and 0.8s for 1031 cache entries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- Comment #12 from bonzini at gnu dot org 2006-06-08 12:26 --- Created an attachment (id=11634) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11634&action=view) proposed patch -- bonzini at gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bonzini at gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug c++/27935] gcc fails to compile code with operator delete(void*,size_t)
--- Comment #7 from charles at kde dot org 2006-06-08 13:04 --- Created an attachment (id=11635) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11635&action=view) compiles on 4.0 just #include -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27935
[Bug fortran/27958] New: assignments to and from zero-sized string selections not handled
The following code is legal, but segfaults at runtime when compiled with gfortran: $ cat a.f90 character(len=10) :: s s = "abcdefghij" s(6:5) = s(7:5) print *, s end $ ifort a.f90 -check all && ./a.out abcdefghij $ gfortran a.f90 && ./a.out zsh: segmentation fault ./a.out -- Summary: assignments to and from zero-sized string selections not handled Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: fxcoudert at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27958
[Bug fortran/27958] assignments to and from zero-sized string selections not handled
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-08 13:28:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27958
[Bug target/27959] New: s390x miscompilation due to clobbering literal pool base reg
The testcase I'll attach is miscompiled on s390x with -m64 -O2 -mtune=z990 or -m64 -O2 -mtune=z9-109. The test function needs a base reg (so %r13 is loaded early and during flow2 the %r13 references actually make it into the assembler). But, during reload a TImode pseudo is reloaded into TI %r12 (and therefore clobbers %r13 too) and the testcase segfaults. -- Summary: s390x miscompilation due to clobbering literal pool base reg Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jakub at gcc dot gnu dot org GCC target triplet: s390x-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27959
[Bug target/27959] s390x miscompilation due to clobbering literal pool base reg
--- Comment #1 from jakub at gcc dot gnu dot org 2006-06-08 13:33 --- Created an attachment (id=11638) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11638&action=view) pr27959.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27959
[Bug tree-optimization/27882] [4.2 regression] segfault in ipa-inline.c, if (e->callee->local.disregard_inline_limits
--- Comment #17 from tbm at cyrius dot com 2006-06-08 13:54 --- This segfault also shows up when compiling the Linux kernel (compiling file net/tipc/net.c). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27882
[Bug middle-end/27948] [4.2 Regression] MS -bitfield struct layout test fails
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end Keywords||ABI, wrong-code Summary|MS -bitfield struct layout |[4.2 Regression] MS - |test fails |bitfield struct layout test ||fails Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27948
[Bug middle-end/27793] [4.1 Regression] num_ssa_names inconsistent or immediate use iterator wrong
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-06-08 14:17 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27793
[Bug c++/27952] [4.0/4.1/4.2 Regression] ICE with invalid virtual inheritance
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |minor Target Milestone|--- |4.0.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27952
[Bug c++/27955] friend members produce different results
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-06-08 14:23 --- reinterpret_cast(t) = 1077936128; //binary float reinterpret_cast(t) = 1077936128; //binary float value You are violating C/C++ aliasing rules as you are accessing a float as int. *** This bug has been marked as a duplicate of 21920 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27955
[Bug c/21920] alias violating
--- Comment #99 from pinskia at gcc dot gnu dot org 2006-06-08 14:23 --- *** Bug 27955 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||julien dot durand dot 1981 ||at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug c++/27935] gcc fails to compile code with operator delete(void*,size_t)
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-06-08 14:32 --- Works in 4.2.0 20060507 and 4.1.0 20060208 and 4.1.2 20060529. And works as of today in 4.1.2 20060608 so this is still invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27935
[Bug c++/27894] [4.1/4.2 Regression] "internal compiler error: Segmentation fault" with -O
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-06-08 14:36 --- Don't know how I got assigned, anyways this is fixed by the patch for PR 27793. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27894
[Bug middle-end/27950] [4.2 regression] undefined reference when compiling valgrind 3.2.0
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-08 14:42 --- Related to PR 27657, though this is not an unused variable as far as I can tell. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||27657 Component|c |middle-end Keywords||link-failure Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27950
[Bug fortran/27916] Problem with allocatable arrays inside OpenMP do loop
-- 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 | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-08 14:46:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27916
[Bug c/8268] no compile time array index checking
--- Comment #39 from falk at debian dot org 2006-06-08 15:02 --- I'm not actually working on this at the moment -- falk at debian dot org changed: What|Removed |Added AssignedTo|falk at debian dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- Comment #13 from sje at cup dot hp dot com 2006-06-08 15:11 --- The proposed patch does fix the compilation time problem on hppa64-hp-hpux11.11 but I am confused about how the cache works. Without the patch, the compile takes 15 to 20 minutes but I do wind up generating a sequence of instructions instead of a call to __divdi3. With the patch, I get a very fast compilation, but I also get a call to __divdi3 instead of the code sequence. Why does caching results change the behaviour? Caches (in general) should speed things up by saving previous/intermediate results, but shouldn't change the ultimate answer. This seems to be doing something different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug rtl-optimization/26727] [4.2 Regression] gcc.target/powerpc/doloop-1.c fails
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-06-08 15:24 --- (In reply to comment #5) > As extended regions by default are disabled now, can, please, someone > reconfirm > this bug. Yes this is fixed now. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26727
[Bug c++/27961] New: [4.1/4.2 regression] ICE on invalid template declaration
The following testcase causes an ICE on the 4.1 branch and mainline:
struct A
{
template void foo(X);
};
bug.cc:7: error: 'X' was not declared in this scope
bug.cc:7: error: variable or field 'foo' declared void
bug.cc:7: internal compiler error: tree check: expected var_decl, have
field_decl in cp_finish_decl, at cp/decl.c:4933
Please submit a full bug report, [etc.]
This is a very recent regression, since GCC 4.1.1 is not affected.
Mark, your patch for PR 27819 seems to have caused this:
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg00198.html
--
Summary: [4.1/4.2 regression] ICE on invalid template declaration
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27961
[Bug c++/27961] [4.1/4.2 regression] ICE on invalid template declaration
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|normal |minor Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27961
[Bug rtl-optimization/27872] Internal compiler error in verify_loop_structure
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-06-08 15:31 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27872
[Bug rtl-optimization/26449] [4.2 Regression] ICE with -march=pentium4 -ftree-vectorize in matmul_i4.c in loop invariant motion
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-06-08 15:32 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26449
[Bug c++/27962] New: [4.0/4.1 regression] ICE with invalid template parameter in specialization
The following testcase causes an ICE on the 4.1 branch and mainline:
template struct A
{
template void foo();
};
template<> template void A<0>::foo() {}
bug.cc:6: error: 'struct T' is not a valid type for a template constant
parameter
bug.cc:6: internal compiler error: in check_classfn, at cp/decl2.c:575
Please submit a full bug report, [etc.]
This is a very recent regression, since GCC 4.1.1 is not affected.
Mark, your patch for PR 20173 seems to have caused this:
http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01204.html
--
Summary: [4.0/4.1 regression] ICE with invalid template parameter
in specialization
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27962
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- Comment #14 from bonzini at gnu dot org 2006-06-08 15:37 --- Well, it shouldn't. My guess could be that we are hitting the case where the logic is flawed. The we fill the cache with the algorithm for say 0x10085 (but then we only write 0x84 in the cache), and then use it for 0x85. The synth_mult logic then could be resilient enough to not generate wrong code but just code with wrong cost measures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug c++/27962] [4.0/4.1 regression] ICE with invalid template parameter in specialization
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |minor Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27962
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- Comment #15 from bonzini at gnu dot org 2006-06-08 15:40 --- Subject: Bug 27733 Author: bonzini Date: Thu Jun 8 15:40:48 2006 New Revision: 114488 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114488 Log: 2006-06-08 Paolo Bonzini <[EMAIL PROTECTED]> PR middle-end/27733 * expmed.c (struct alg_hash_entry): Fix type of field T to match synth_mult argument. (NUM_ALG_HASH_ENTRIES): Make it bigger for 64-bit HOST_WIDE_INT. Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug c/8268] no compile time array index checking
--- Comment #40 from mueller at gcc dot gnu dot org 2006-06-08 15:50 --- I've a patch, which is currently blocked by -fivopts bug -- mueller at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mueller at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8268
[Bug middle-end/27733] [4.1/4.2 Regression] Large compile time regression
--- Comment #16 from sje at cup dot hp dot com 2006-06-08 15:50 --- Bizarre, I could swear that when I first tried your fix I got a call to __muldi3, but I just updated expmed.c, reran the test case and I got the same inlined sequence that I got before the patch. I think in the first case I had reduced the cost of MULT on hppa64 and that is why I got the __divdi3 call. I put the MULT cost back to where it was and now I get the inline sequence. In short, the compilation now takes 30 seconds instead of 15 minutes and I get the same code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27733
[Bug bootstrap/26998] bootstrap failure building libdecnumber, ICE in compare_values, tree-vrp.c:432
--- Comment #12 from law at redhat dot com 2006-06-08 16:38 ---
Subject: Re: bootstrap failure building libdecnumber,
ICE in compare_values, tree-vrp.c:432
On Thu, 2006-06-08 at 09:47 +, rguenth at gcc dot gnu dot org wrote:
>
> --- Comment #11 from rguenth at gcc dot gnu dot org 2006-06-08 09:47
> ---
> This one:
>
> /* Apply the operation to each end of the range and see what we end
> up with. */
> if (code == NEGATE_EXPR
> && !TYPE_UNSIGNED (TREE_TYPE (expr)))
> {
> /* NEGATE_EXPR flips the range around. */
> min = (vr0.max == TYPE_MAX_VALUE (TREE_TYPE (expr)) && !flag_wrapv)
> ? TYPE_MIN_VALUE (TREE_TYPE (expr))
> : fold_unary_to_constant (code, TREE_TYPE (expr), vr0.max);
>
> max = (vr0.min == TYPE_MIN_VALUE (TREE_TYPE (expr)) && !flag_wrapv)
> ? TYPE_MAX_VALUE (TREE_TYPE (expr))
> : fold_unary_to_constant (code, TREE_TYPE (expr), vr0.min);
>
> }
>
> is wrong for
>
> (gdb) print vr0
> $3 = {type = VR_ANTI_RANGE, min = 0xb7d2b3a8, max = 0xb7d2b3a8,
> equiv = 0x896c298}
> (gdb) call debug_generic_expr (vr0.min)
> -2147483648
> (gdb) call debug_generic_expr (vr0.max)
> -2147483648
>
> It needs to read:
>
> min = (vr0.max == TYPE_MIN_VALUE (TREE_TYPE (expr)) && !flag_wrapv)
> ? TYPE_MAX_VALUE (TREE_TYPE (expr))
> : fold_unary_to_constant (code, TREE_TYPE (expr), vr0.max);
>
> values other than TYPE_MIN_VALUE are not special with inversion.
I'm not terribly familiar with the code in question or this PR. But it
seems to me that negating a signed type's minimum value should give you
the same value with an overflow.
ie, for a 32bit signed type
- (-2147483648) => -2147483648
If I read your proposed change, you'd instead return the type's max
value, in this case 2147483647. Which seems rather wrong.
Diego is far more familiar with code than I am.
jeff
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26998
[Bug ada/27936] [4.2 Regression] gnatbind fails to link on Tru64 UNIX
--- Comment #4 from ro at techfak dot uni-bielefeld dot de 2006-06-08 17:24 --- Subject: Re: [4.2 Regression] gnatbind fails to link on Tru64 UNIX charlet at adacore dot com writes: > Subject: Re: New: gnatbind fails to link on Tru64 UNIX > > > Add ada/s-purexc.o to ada/Make-lang.in (GNATBIND_OBJS). > > > > If this is considered the correct fix, I'll submit a proper patch. > > This shouldn't be needed at first sight, so this is likely not the right > fix. So how should I go on to investigate this? The question seems to be why gnatbind -C generates those references in b_gnat[1b].c in the first place. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27936
[Bug c++/27826] [4.0/4.1 Regression] ICE in copy_to_mode_reg
--- Comment #11 from bangerth at dealii dot org 2006-06-08 17:26 --- (In reply to comment #8) > Bangerth, why did you change the Priority? That is the job of the Release > manager. Actually, as a remark, I believe this isn't true. Bugmasters have always adjusted initial priorities of PRs to alert the RM to new bugs that warrant his attention. Looking at the activity trail of this bug, I didn't see any priority activity before my change. I certainly wouldn't have upgraded the PR if anyone had downgraded it before. That said, I don't care either way. I don't have much time for GCC work these days so am happy to defer policy decisions to others. W. -- bangerth at dealii dot org changed: What|Removed |Added CC||mmitchel at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27826
[Bug c++/26957] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:871
--- Comment #6 from sje at cup dot hp dot com 2006-06-08 17:47 --- Created an attachment (id=11639) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11639&action=view) Cut-down test case Here is a cutdown test case that fails on hppa1.1-hp-hpux11.11. It does not fail on hppa64-hp-hpux11.11 or ia64-hp-hpux11.23. If you shrink the size of LDD then the problem goes away so it seems related to how we are passing large (>64 bits) structures. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
[Bug middle-end/27948] [4.2 Regression] MS -bitfield struct layout test fails
--- Comment #1 from echristo at apple dot com 2006-06-08 18:11 --- Can you get me the size of that structure according to MS VC? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27948
[Bug middle-end/27942] [4.2 Regression] packed union doesn't make the unaligned magic on sh64-*
--- Comment #4 from echristo at apple dot com 2006-06-08 18:14 --- Well, I suppose the question is whether or not I'm doing something wrong here. The alignment should be added unilaterally (as far as I can tell from the documents that I included in the documentation). Part of the question is what happens with the packed attribute? I've not seen any part of an abi document that includes that. I'm perfectly willing to include your patch in - it shouldn't affect anything else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27942
[Bug boehm-gc/27963] New: [4.2 Regression] libjava fails to build if it isn't built by default
Trying to bootstrap mainline on IRIX 6.5 with java included failed since
boehm-gc (which is required for libjava) isn't built:
In file included from /vol/gcc/src/gcc-dist/libjava/include/jvm.h:25,
from /vol/gcc/src/gcc-dist/libjava/include/java-interp.h:14,
from /vol/gcc/src/gcc-dist/libjava/defineclass.cc:23:
./include/java-gc.h:30:53: error: gc_ext_config.h: No such file or directory
This happens due to this change:
2006-06-06 David Ayers <[EMAIL PROTECTED]>
PR libobjc/13946
* Makefile.def: Add dependencies for libobjc which boehm-gc.
* Makefile.in: Regenerate.
* configure.in: Add --enable-objc-gc at toplevel and have it
enable boehm-gc for Objective-C.
Remove target-boehm-gc from libgcj.
Add target-boehm-gc to target_libraries.
Add target-boehm-gc to noconfigdirs where ${libgcj}
is specified.
On platforms (like IRIX 6), where libjava just isn't built *by default*,
unconditionally adding boehm-gc to noconfigdirs inhibits building boehm-gc
completely, though it could build and is required for libjava.
This is a regression from the 4.1 branch.
Environment:
System: IRIX64 columba 6.5 07010238 IP27
host: mips-sgi-irix6.5
build: mips-sgi-irix6.5
target: mips-sgi-irix6.5
configured with: /vol/gcc/src/gcc-dist/configure --prefix=/vol/gcc
--with-local-prefix=/vol/gcc --disable-nls --with-gnu-as
--with-as=/vol/gcc/lib/gas-2.16.1 --enable-libgcj
--with-gmp-dir=/vol/gnu/obj/gmp-4.1.3
--with-mpfr-dir=/vol/gnu/obj/gmp-4.1.3/mpfr
--enable-languages=c,c++,fortran,java,objc,ada --disable-libmudflap
How-To-Repeat:
Bootstrap mainline as described.
--
Summary: [4.2 Regression] libjava fails to build if it isn't
built by default
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: boehm-gc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ro at techfak dot uni-bielefeld dot de
GCC build triplet: mips-sgi-irix6.5
GCC host triplet: mips-sgi-irix6.5
GCC target triplet: mips-sgi-irix6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27963
[Bug boehm-gc/27963] [4.2 Regression] libjava fails to build if it isn't built by default
--- Comment #1 from ro at gcc dot gnu dot org 2006-06-08 18:59 --- David, your patch caused this regression, so please have a look. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||d dot ayers at inode dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27963
[Bug fortran/27964] New: Wrong line ends on windows (XP)
Output lines on Windows are incorrectly terminated. Example: program le integer i do i = 1,6 print *, 'Line ', i end do end The output looks ok on the windows console. However, if you redirect output to a file, and examine with a hexadecimal viewer, you will see that each line is terminated by CR/CR/LF, instead of CR/LF which would be correct for Windows. This causes big problems for other programs that are going to read such files! -- Summary: Wrong line ends on windows (XP) Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gay at sfu dot ca http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
[Bug bootstrap/27963] [4.2 Regression] libjava fails to build if it isn't built by default
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-06-08 19:11 --- Maybe it is better to not to disable libjava completely for IRIX. It seems like --disable-libjava is out of date and wrong in general now (maybe even has been for a long time). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|boehm-gc|bootstrap Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27963
[Bug fortran/27964] Wrong line ends on windows (XP)
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-06-08 19:14 --- FX, if you want this one, let me know, otherwise I will look into it. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-08 19:14:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
[Bug bootstrap/27963] [4.2 Regression] libjava fails to build if it isn't built by default
--- Comment #3 from ro at techfak dot uni-bielefeld dot de 2006-06-08 19:15 --- Subject: Re: [4.2 Regression] libjava fails to build if it isn't built by default pinskia at gcc dot gnu dot org writes: > Maybe it is better to not to disable libjava completely for IRIX. It seems But it isn't disabled completely (and I've been able to build it at some point in the past), it's just disabled by default since it requires (or at least used to require) a larger-than-default limit for the command line length. > like --disable-libjava is out of date and wrong in general now (maybe even has > been for a long time). Do you have any evidence for this? (Btw., it's --enable/disable-libgcj.) Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27963
[Bug fortran/27965] New: gfortran gives "Array bound mismatch" for valid program
The following valid Fortran 95 program gives Fortran runtime error: Array bound mismatch for GNU Fortran 95 (GCC) 4.1.0 (SUSE Linux) and Fortran runtime error: Array bound mismatch, upper bound of dimension 1 of array 'rho' exceeded (in file 'main.f90', at line 12) for GNU Fortran 95 (GCC) 4.2.0 20060608 (experimental). - program test implicit none real(8) :: rftp(4) rftp = 42.0_8 call xcifc(n=4,rho=rftp) contains subroutine xcifc(n,rho) implicit none integer, optional, intent(in) :: n real(8), optional, intent(in) :: rho(*) if(present(n).and.present(rho)) then print *,rho(1:n) end if end subroutine xcifc end program test -- Compiled as: gfortran -Wall -g -O0 -fbounds-check -Wconversion main.f90 If compiled without -fbounds-check, the output is ok. Other compilers: ~> f95 -C=all -C=undefined -kind=byte main.f90 ; ./a.out 42. 42. 42. 42. ~> ifort -C -check all -warn all,nodec,interfaces -gen_interfaces -traceback -fpe0 -fpstkchk -g -O0 main.f90; ./a.out 42.042.042.0 42.0 -- Summary: gfortran gives "Array bound mismatch" for valid program Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27965
[Bug fortran/27965] gfortran gives "Array bound mismatch" for valid program
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-06-08 19:53 --- This could be the same as gfortran.fortran-torture/execute/assumed_size.f90, I'm not completely sure, though. -- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27965
[Bug bootstrap/27963] [4.2 Regression] libjava fails to build if it isn't built by default
--- Comment #4 from ayers at gcc dot gnu dot org 2006-06-08 20:18 --- Hello, I followed the advice given here: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00886.html I believe "noconfigdir" is supposed to mean "not supported" so in this case the correct "patch" would be to remove tartget-boehm-gc if in fact it is supported by the platform, as we will later remove it again if it wasn't requested by libobjc and not needed by java. If I get a get a list of targets for which I should re-enable target-boehm-gc (and possibly pre approval) I can certainly come up with a patch (it's just a matter of removing target-boehm-gc from the appropriate noconfigdir entry). Cheers, David -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27963
[Bug bootstrap/27963] [4.2 Regression] libjava fails to build if it isn't built by default
--- Comment #5 from ro at techfak dot uni-bielefeld dot de 2006-06-08 20:23 --- Subject: Re: [4.2 Regression] libjava fails to build if it isn't built by default ayers at gcc dot gnu dot org writes: > I followed the advice given here: > > http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00886.html As this PR demonstrates, this advice was wrong wrt. to adding boehm-gc to noconfigdirs, as this will break any configuration where libjava just isn't built by default. > I believe "noconfigdir" is supposed to mean "not supported" so in this case > the > correct "patch" would be to remove tartget-boehm-gc if in fact it is supported > by the platform, as we will later remove it again if it wasn't requested by > libobjc and not needed by java. > > If I get a get a list of targets for which I should re-enable target-boehm-gc > (and possibly pre approval) I can certainly come up with a patch (it's just a > matter of removing target-boehm-gc from the appropriate noconfigdir entry). I fear this is the wrong way round: it shouldn't be necessary to unbreak the affected targets one by one, but boehm-gc should only be included in noconfigdirs if it is known not to work (which is what noconfigdirs is for). Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27963
[Bug c++/26957] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:871
--- Comment #7 from sje at cup dot hp dot com 2006-06-08 20:34 --- Created an attachment (id=11642) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11642&action=view) Proposed patch I am going to test the attached patch and will submit it to gcc-patches if there are no regressions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
[Bug target/27421] [4.0/4.1 regression] ICE with invalid array in struct
--- Comment #14 from reichelt at gcc dot gnu dot org 2006-06-08 20:50 --- Subject: Bug 27421 Author: reichelt Date: Thu Jun 8 20:50:24 2006 New Revision: 114494 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114494 Log: PR target/27421 * config/i386/i386.c (classify_argument): Skip fields with invalid types in unions. * gcc.dg/union-3.c: New test. Added: trunk/gcc/testsuite/gcc.dg/union-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27421
[Bug target/27421] [4.0/4.1 regression] ICE with invalid array in struct
--- Comment #15 from reichelt at gcc dot gnu dot org 2006-06-08 20:53 --- The problem with unions is now also fixed on mainline. Will commit to 4.1 and 4.0 branch in a couple of days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27421
[Bug fortran/27786] Bad interaction between Cray pointer, assumed-size array and bounds checking
--- Comment #3 from langton at gcc dot gnu dot org 2006-06-08 21:01 --- Subject: Bug 27786 Author: langton Date: Thu Jun 8 21:00:26 2006 New Revision: 114495 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114495 Log: * cray_pointers_2.f90: Add -fbounds-check compile flag. PR fortran/27786 * trans-array.c (gfc_conv_array_ref): Eliminate bounds checking for assumed-size Cray pointees. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/cray_pointers_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27786
[Bug fortran/27786] Bad interaction between Cray pointer, assumed-size array and bounds checking
--- Comment #4 from langton at gcc dot gnu dot org 2006-06-08 21:03 --- I've committed a patch that should fix this bug. -- langton at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27786
[Bug preprocessor/8270] [4.0/4.1/4.2 Regression] back-slash white space newline with comments, no warning
--- Comment #35 from echristo at apple dot com 2006-06-08 21:06 --- I'm unlikely to work on this... -- echristo at apple dot com changed: What|Removed |Added AssignedTo|echristo at apple dot com |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8270
[Bug c++/26957] [4.0/4.1/4.2 regression] ICE in make_decl_rtl, at varasm.c:871
--- Comment #8 from sje at cup dot hp dot com 2006-06-08 21:12 --- I do not think my patch is correct. The variable causing the problem is created in gimplify_parameters by a call to create_tmp_var. This local variable is only created on systems that pass structures by pointers and which are callee copied. I think this variable should be a local stack variable but I think that is what we have now. Then we run into the gcc_assert in make_decl_rtl, if I just comment out that assert I run into one in expand_expr_real_1. It may be that the function context is not set when creating this temporary, that would explain the expand_expr_real_1 assert. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26957
Re: bug report
Hayashi Eisuke wrote: > 100: 400 (-1077752048) > 2092728: Segmentatioin error (core dumped) The process is dying because you are exceeding unix process stack space limits. You probably have an 8MB per process limit, and the number you are using is a tad less than 2MB. If you are using bash, see the documentation for the "ulimit" command. If csh, I think it is "limits". -- Jim Wilson, GNU Tools Support, http://www.specifix.com
[Bug libfortran/27964] Wrong line ends on windows (XP)
--- Comment #2 from fxcoudert at gcc dot gnu dot org 2006-06-08 21:26 --- No, go ahead if you have time (I'm buried deep into bounds-checking). I confirm this bug on MinGW, I think the problem might not appear on cygwin. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27964
[Bug target/27542] [4.2 Regression] the ms_struct pragma is not documented
--- Comment #2 from echristo at apple dot com 2006-06-08 21:40 --- Submitted patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27542
[Bug fortran/27958] assignments to and from zero-sized string selections not handled
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2006-06-08 21:48 --- Subject: Bug 27958 Author: fxcoudert Date: Thu Jun 8 21:48:05 2006 New Revision: 114496 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114496 Log: PR fortran/27958 * trans-expr.c (gfc_conv_substring): If the substring start is greater than its end, the length of the substring is zero, and not negative. (gfc_trans_string_copy): Don't generate a call to _gfortran_copy_string when destination length is zero. * gcc/testsuite/gfortran.dg/substr_2.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/substr_2.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27958
[Bug middle-end/27942] [4.2 Regression] packed union doesn't make the unaligned magic on sh64-*
--- Comment #5 from kkojima at gcc dot gnu dot org 2006-06-08 22:17 --- I also couldn't find any document refering to it. My patch is just a guess from the behavior for nonzero-size bitfield with the packed attribute appeared in the last 3 lines of my patch. I'd like to send my patch to gcc-patch to get comments for our abi question. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27942
[Bug target/26427] [4.2 Regression] with -fsection-anchors with zero sized structs
--- Comment #16 from mrs at gcc dot gnu dot org 2006-06-08 22:23 --- Subject: Bug 26427 Author: mrs Date: Thu Jun 8 22:23:17 2006 New Revision: 114498 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114498 Log: PR target/26427 * config/darwin.c (darwin_asm_output_anchor): Disable -fsection-anchors on darwin for now. * config/darwin.h (TARGET_ASM_OUTPUT_ANCHOR): Likewise. * rs6000/rs6000.c (optimization_options): Likewise. testsuite: * gcc.dg/pr26427.c: Test to ensure that -fsection-anchors doesn't produce bad code on darwin. Added: trunk/gcc/testsuite/gcc.dg/pr26427.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/darwin.c trunk/gcc/config/darwin.h trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26427
[Bug middle-end/27942] [4.2 Regression] packed union doesn't make the unaligned magic on sh64-*
--- Comment #6 from echristo at apple dot com 2006-06-08 22:23 --- Sure. Sounds good. As I said, the ABI stuff I've seen (and helped write) don't take packed into account anywhere :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27942
[Bug target/27880] [4.2 regression] undefined reference to `_Unwind_GetIPInfo'
--- Comment #5 from sje at cup dot hp dot com 2006-06-08 22:25 --- I think using configure to detect whether or not _Unwind_GetIPInfo exists may be difficult. The libstdc++ configure script seems to go out of its way to not link programs or to use and/or look at libgcc in anyway. Anyone have an idea on how to implement this? I am thinking the checking/flag setting on whether or not _Unwind_GetIPInfo exists might have to be done in the gcc directory. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27880
[Bug target/26427] [4.2 Regression] with -fsection-anchors with zero sized structs
--- Comment #17 from mrs at apple dot com 2006-06-08 22:26 --- This should be fixed now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26427
[Bug middle-end/27948] [4.2 Regression] MS -bitfield struct layout test fails
--- Comment #2 from dannysmith at users dot sourceforge dot net 2006-06-08 22:32 --- (In reply to comment #1) > Can you get me the size of that structure according to MS VC? With version 12.00.8804 of MS cl.exe, sizeof (struct six) == 8, as tested in the testcase. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27948
[Bug middle-end/27948] [4.2 Regression] MS -bitfield struct layout test fails
--- Comment #3 from echristo at apple dot com 2006-06-08 22:39 --- Verified. Investigating. The alignment should be 8 from what I can see: a -> 1st byte int :0 -> align to 4th byte b -> 5th byte c -> 6th byte align structure to 8th byte because of int :0. -- echristo at apple dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at apple dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-08 22:39:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27948
[Bug target/26427] [4.2 Regression] with -fsection-anchors with zero sized structs
--- Comment #18 from mrs at apple dot com 2006-06-08 22:40 --- The regression was introduced by: 2006-04-30 David Edelsohn <[EMAIL PROTECTED]> * config/rs6000/rs6000.c (rs6000_override_options): Enable TARGET_NO_FP_IN_TOC for section anchors. (optimization_options): Enable section anchors for all non-"Objective" languages. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26427
[Bug target/26427] [4.2 Regression] with -fsection-anchors with zero sized structs
--- Comment #19 from pinskia at gcc dot gnu dot org 2006-06-08 22:45 --- (In reply to comment #18) > The regression was introduced by: Exposed by and not introduced. If you look at my patch which you approved, I had mentioned this failure when I fixed most of -fsection-anchors for Darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26427
