[Bug tree-optimization/35428] [4.3 regression] ICE with -ftrapv
--- Comment #10 from reichelt at gcc dot gnu dot org 2008-08-12 06:45 --- The bug is still present on the 4.3 branch as of 2008-08-11 (with both the C and C++ frontend). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35428
[Bug c/35746] [4.3 regression] ICE with undefined variables
--- Comment #8 from reichelt at gcc dot gnu dot org 2008-08-12 06:48 --- As Andrew Pinski pointed out, we suppress ICEs after regular errors. You have to configure the compiler with --enable-checking to see the real ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35746
[Bug c++/36688] [4.3/4.4 Regression] Incorrect struct assignments with nested const initializers
--- Comment #3 from jakub at gcc dot gnu dot org 2008-08-12 08:09 --- Subject: Bug 36688 Author: jakub Date: Tue Aug 12 08:07:57 2008 New Revision: 139004 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139004 Log: PR c++/36688 * gimplify.c (gimplify_modify_expr_rhs): Test TREE_READONLY on the VAR_DECL instead of TYPE_READONLY on its type. * g++.dg/init/const6.C: New test. Added: trunk/gcc/testsuite/g++.dg/init/const6.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36688
[Bug c++/36688] [4.3/4.4 Regression] Incorrect struct assignments with nested const initializers
--- Comment #4 from jakub at gcc dot gnu dot org 2008-08-12 08:32 --- Subject: Bug 36688 Author: jakub Date: Tue Aug 12 08:31:15 2008 New Revision: 139006 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139006 Log: PR c++/36688 * gimplify.c (gimplify_modify_expr_rhs): Test TREE_READONLY on the VAR_DECL instead of TYPE_READONLY on its type. * g++.dg/init/const6.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/init/const6.C Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/gimplify.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36688
[Bug tree-optimization/37084] [4.4 regression] ICE in gimple_assign_rhs1
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-12 08:39 ---
Confirmed.
#3 0x006c360a in copy_bb (id=0x7fffd920, bb=0x7759c300,
frequency_scale=0, count_scale=1)
at /space/rguenther/src/svn/trunk/gcc/tree-inline.c:1269
1269 new_rhs = force_gimple_operand_gsi (copy_gsi,
(gdb) l
1264 gimple_assign_rhs_code (stmt) == NOP_EXPR
1265 !is_gimple_val (gimple_assign_rhs1 (stmt)))
1266 || id-regimplify)
1267{
1268 tree new_rhs;
1269 new_rhs = force_gimple_operand_gsi (copy_gsi,
1270 gimple_assign_rhs1
(stmt),
1271 true, NULL, true,
GSI_SAME_STMT);
1272 gimple_assign_set_rhs1 (stmt, new_rhs);
1273}
we have id-regimplify set but do not expect to need to deal with a call here.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||rguenth at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Priority|P3 |P1
Last reconfirmed|-00-00 00:00:00 |2008-08-12 08:39:51
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37084
[Bug bootstrap/37086] Cross-compilers built with GCC 3.4 do not work
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-08-12 08:41 --- As this is a bug in GCC 3.4 let's close this as invalid (can't we do a C only host bootstrap for building cross-compilers to work around issues with host compilers?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37086
[Bug c++/36688] [4.3/4.4 Regression] Incorrect struct assignments with nested const initializers
--- Comment #5 from jakub at gcc dot gnu dot org 2008-08-12 08:42 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36688
[Bug bootstrap/37091] Rev 138207 causes ICE using bootstrap for crt for win64
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-08-12 08:42 --- *** This bug has been marked as a duplicate of 37086 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37091
[Bug bootstrap/37086] Cross-compilers built with GCC 3.4 do not work
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-12 08:42 --- *** Bug 37091 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||nightstrike at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37086
[Bug tree-optimization/37084] [4.4 regression] ICE in gimple_assign_rhs1
--- Comment #3 from jakub at gcc dot gnu dot org 2008-08-12 08:46 ---
/* With return slot optimization we can end up with
non-gimple (foo *)this-m, fix that here. */
if ((is_gimple_assign (stmt)
gimple_assign_rhs_code (stmt) == NOP_EXPR
!is_gimple_val (gimple_assign_rhs1 (stmt)))
|| id-regimplify)
{
tree new_rhs;
new_rhs = force_gimple_operand_gsi (copy_gsi,
gimple_assign_rhs1 (stmt),
true, NULL, true, GSI_SAME_STMT);
gimple_assign_set_rhs1 (stmt, new_rhs);
}
else if (id-regimplify)
gimple_regimplify_operands (stmt, copy_gsi);
IMNSHO we just need to kill the || id-regimplify from the first if condition,
the then body isn't able to deal with it and the correct
gimple_regimplify_operands call never triggers.
--
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|NEW |ASSIGNED
Last reconfirmed|2008-08-12 08:39:51 |2008-08-12 08:46:30
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37084
[Bug middle-end/37090] optimization breaks code in manually unrolled loop
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-08-12 08:48 --- I can confirm this with 4.3.1 but it works for me on the current 4.3 branch, so this seems to be fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Keywords||wrong-code Known to fail||4.3.1 Known to work||4.3.2 Resolution||FIXED Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37090
[Bug debug/37058] [4.4 Regression] profiling testcases fail with .cfi_endproc without corresponding .cfi_startproc
--- Comment #2 from jakub at gcc dot gnu dot org 2008-08-12 09:46 --- -freorder-blocks-and-partition never really worked with EH, whether you get assembler errors as with the .cfi_* directives or whether it just silently generates bogus unwind info is unimportant. GCC isn't able to track the unwind info for two separate sections ATM. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37058
[Bug c/36849] IMA rejects to merge (function)decls with va_args
--- Comment #2 from aldot at gcc dot gnu dot org 2008-08-12 09:54 --- (In reply to comment #1) The error message is correct as the function types are not compatible. If in fact this is invalid C even though we don't currently diagnostic it without -combine. Closing as invalid as -combine is doing the correct job of rejecting this. Ideally the __VA_ARGS__ would be dealt with as any or none param decl, so the function(s) above would be considered equal. No, that is not what the C/C++ standard says about compatible function types. Yes we could enable this and have -pedantic-error reject it but I don't see why we should allow this as it is obvious invalid C code. Do you have a suggestion on how libc could legally provide an mremap implementation as per the example in #0 that can be compiled with -combine? -- aldot at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36849
[Bug middle-end/37014] [4.2/4.3/4.4 Regression] internal compiler error: in expand_expr_real_1, at expr.c:8760
-- 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|NEW |ASSIGNED Last reconfirmed|2008-08-05 18:03:10 |2008-08-12 10:01:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37014
[Bug bootstrap/37035] gcc-4.2.2 build failed on solaris-8
--- Comment #2 from halder dot malay at gmail dot com 2008-08-12 10:54 --- (In reply to comment #1) Did you set CONFIG_SHELL? no i haven't set CONFIG_SHELL -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37035
[Bug bootstrap/37092] New: gcc-4.2.2 build failed on solaris-8
i am building gcc 4.2.2 on a solaris machine using gcc-3.4.4 my build machine SunOS 5.8 Generic_108528-20 sun4u sparc SUNW,Sun-Blade-100 my gcc-3.4.4 Reading specs from /tools/openbin/gcc/3.4.4/sparc-sun-solaris8/lib/gcc/sparc-sun-solaris2.8/3.4.4/specs Configured with: ../gcc-3.4.4/configure --prefix=/tools/openbin/gcc/3.4.4/sparc-sun-solaris8 --disable-nls --enable-languages=c,c++,java --enable-shared --enable-threads=posix --with-gnu-as --with-as=/tools/openbin/binutils/2.16.1/sparc-sun-solaris8/bin/as --with-gnu-ld --with-ld=/tools/openbin/binutils/2.16.1/sparc-sun-solaris8/bin/ld Thread model: posix my configure options CC=$(HOST_CC) CXX=$(HOST_CXX) MAKE=$(GMAKE) \ $(SRC_DIR)/configure \ --prefix=$(DEST_DIR) \ --disable-nls \ --enable-shared \ --enable-threads=posix \ --without-gnu-ld \ --with-ld=/usr/ccs/bin/ld \ --with-as=/tools/openbin/binutils/2.16.1/sparc-sun-solaris8/bin/as \ --with-gnu-as \ --enable-languages=c,c++ \ --with-mpfr=/tools/openbin/mpfr/2.3.1/sparc-sun-solaris10 \ --with-mpfr-include=/tools/openbin/mpfr/2.3.1/sparc-sun-solaris10/include \ --with-mpfr-lib=/tools/openbin/mpfr/2.3.1/sparc-sun-solaris10/lib \ --with-gmp=/tools/openbin/gmp/4.2.2/sparc-sun-solaris10 \ --with-gmp-include=/tools/openbin/gmp/4.2.2/sparc-sun-solaris10/include \ --with-gmp-lib=/tools/openbin/gmp/4.2.2/sparc-sun-solaris10/lib I am getting this error in build stage /users/toolsrd/ws/si_ctoolrd/gcc/production/objects/gcc-4.2.2/./gcc/xgcc -B/users/toolsrd/ws/si_ctoolrd/gcc/production/objects/gcc-4.2.2/./gcc/ -B/tools/openbin/gcc/4.2.2/sparc-sun-solaris8/sparc-sun-solaris2.8/bin/ -B/tools/openbin/gcc/4.2.2/sparc-sun-solaris8/sparc-sun-solaris2.8/lib/ -isystem /tools/openbin/gcc/4.2.2/sparc-sun-solaris8/sparc-sun-solaris2.8/include -isystem /tools/openbin/gcc/4.2.2/sparc-sun-solaris8/sparc-sun-solaris2.8/sys-include -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -shared -nodefaultlibs -Wl,-h,libgcc_s.so.1 -Wl,-z,text -Wl,-z,defs -Wl,-M,libgcc/./libgcc.map -o ./libgcc_s.so.1.tmp libgcc/./_muldi3_s.o libgcc/./_negdi2_s.o libgcc/./_lshrdi3_s.o libgcc/./_ashldi3_s.o libgcc/./_ashrdi3_s.o libgcc/./_cmpdi2_s.o libgcc/./_ucmpdi2_s.o libgcc/./_clear_cache_s.o libgcc/./_enable_execute_stack_s.o libgcc/./_trampoline_s.o libgcc/./__main_s.o libgcc/./_absvsi2_s.o libgcc/./_absvdi2_s.o libgcc/./_addvsi3_s.o libgcc/./_addvdi3_s.o libgcc/./_subvsi3_s.o libgcc/./_subvdi3_s.o libgcc/./_mulvsi3_s.o libgcc/./_mulvdi3_s.o libgcc/./_negvsi2_s.o libgcc/./_negvdi2_s.o libgcc/./_ctors_s.o libgcc/./_ffssi2_s.o libgcc/./_ffsdi2_s.o libgcc/./_clz_s.o libgcc/./_clzsi2_s.o libgcc/./_clzdi2_s.o libgcc/./_ctzsi2_s.o libgcc/./_ctzdi2_s.o libgcc/./_popcount_tab_s.o libgcc/./_popcountsi2_s.o libgcc/./_popcountdi2_s.o libgcc/./_paritysi2_s.o libgcc/./_paritydi2_s.o libgcc/./_powisf2_s.o libgcc/./_powidf2_s.o libgcc/./_powixf2_s.o libgcc/./_powitf2_s.o libgcc/./_mulsc3_s.o libgcc/./_muldc3_s.o libgcc/./_mulxc3_s.o libgcc/./_multc3_s.o libgcc/./_divsc3_s.o libgcc/./_divdc3_s.o libgcc/./_divxc3_s.o libgcc/./_divtc3_s.o libgcc/./_fixunssfsi_s.o libgcc/./_fixunsdfsi_s.o libgcc/./_fixunsxfsi_s.o libgcc/./_fixsfdi_s.o libgcc/./_fixunssfdi_s.o libgcc/./_floatdisf_s.o libgcc/./_floatundisf_s.o libgcc/./_fixdfdi_s.o libgcc/./_fixunsdfdi_s.o libgcc/./_floatdidf_s.o libgcc/./_floatundidf_s.o libgcc/./_fixxfdi_s.o libgcc/./_fixunsxfdi_s.o libgcc/./_floatdixf_s.o libgcc/./_floatundixf_s.o libgcc/./_fixtfdi_s.o libgcc/./_fixunstfdi_s.o libgcc/./_floatditf_s.o libgcc/./_floatunditf_s.o libgcc/./_divdi3_s.o libgcc/./_moddi3_s.o libgcc/./_udivdi3_s.o libgcc/./_umoddi3_s.o libgcc/./_udiv_w_sdiv_s.o libgcc/./_udivmoddi4_s.o libgcc/./unwind-dw2_s.o libgcc/./unwind-dw2-fde_s.o libgcc/./unwind-sjlj_s.o libgcc/./gthr-gnat_s.o libgcc/./unwind-c_s.o -lc rm -f ./libgcc_s.so if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 ln -s libgcc_s.so.1 ./libgcc_s.so ld: fatal: relocation error: R_SPARC_32: file libgcc/./_muldi3_s.o: symbol unknown: offset 0xfe98dad1 is non-aligned ld: fatal: relocation error: R_SPARC_32: file libgcc/./_lshrdi3_s.o: symbol unknown: offset 0xfe98dbe3 is non-aligned ld: fatal: relocation error: R_SPARC_32: file libgcc/./_ashrdi3_s.o: symbol unknown: offset 0xfe98dd0d is non-aligned ld: fatal:
[Bug c++/37093] New: [4.2/4.3/4.4 Regression] ICE with pointer to member template parameters
template class C, void (C::*M) ()
static void foo (void *obj)
{
C *p = static_castC* (obj);
(p-*M) ();
}
template class C
static void bar (C *c, void (C::*m) ())
{
fooC, m ((void *) c);
}
struct S
{
void baz () {}
};
int
main ()
{
S a;
bar (a, S::baz);
}
ICEs since 4.0 (in 3.4 and before before it gave
rh458297.C: In function `void bar(C*, void (C::*)()) [with C = S]':
rh458297.C:23: instantiated from here
rh458297.C:11: error: `m' is not a valid template argument
rh458297.C:11: error: it must be a pointer-to-member of the form `X::Y'
rh458297.C:11: error: no matching function for call to `foo(void*)'
).
--
Summary: [4.2/4.3/4.4 Regression] ICE with pointer to member
template parameters
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37093
[Bug c++/37093] [4.2/4.3/4.4 Regression] ICE with pointer to member template parameters
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37093
[Bug bootstrap/37086] Cross-compilers built with GCC 3.4 do not work
--- Comment #4 from drow at gcc dot gnu dot org 2008-08-12 11:55 --- In the past, we've worked around bugs like this in widely used compilers - they make life difficult. Obviously it depends how nasty a workaround is found! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37086
[Bug c/36531] -Wno-packed appears to be disconnected/ignored
--- Comment #3 from manu at gcc dot gnu dot org 2008-08-12 12:36 --- @John, I know where the bug is but we still need a small testcase, please. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36531
[Bug middle-end/37090] optimization breaks code in manually unrolled loop
--- Comment #4 from michael+gcc at stapelberg dot de 2008-08-12 12:43 --- Thanks for confirming it. Is there a way to work around this (except for -O0), as many distributions ship 4.3.1 as standard compiler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37090
[Bug ada/37094] New: GNAT Bug Box During Build [regression]
This is with revision
Compiler built for revision 138553 (20080802) with ACATS reported
(http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00380.html)
/home/joel/work-gnat/svn/b-gcc2-i386/./gcc/xgcc
-B/home/joel/work-gnat/svn/b-gcc2-i386/./gcc/ -nostdinc
-B/home/joel/work-gnat/svn/b-gcc2-i386/i386-rtems4.9/newlib/ -isystem
/home/joel/work-gnat/svn/b-gcc2-i386/i386-rtems4.9/newlib/targ-include -isystem
/home/joel/work-gnat/svn/gcc/newlib/libc/include
-B/home/joel/work-gnat/svn//install/i386-rtems4.9/bin/
-B/home/joel/work-gnat/svn//install/i386-rtems4.9/lib/ -isystem
/home/joel/work-gnat/svn//install/i386-rtems4.9/include -isystem
/home/joel/work-gnat/svn//install/i386-rtems4.9/sys-include -c -g -O2 -W -Wall
-gnatpg a-nllcef.ads -o a-nllcef.o
a-ngcefu.adb: In function
'Ada.Numerics.Long_Long_Complex_Elementary_Functions.Log':
a-ngcefu.adb:538: error: insn does not satisfy its constraints:
(insn 465 314 468 41 a-ngcefu.adb:533 (set (reg:XF 8 st [141])
(const_double:XF -921707870 [0xc90fdaa2]
3.14159265358979323851280895940618620443274267018e+0
[0x0.c90fdaa22168c235p+2])) 76 {*movxf_integer} (nil))
+===GNAT BUG DETECTED==+
| 4.4.0 20080811 (experimental) [trunk revision 138957] (i386-pc-rtems4.9) GCC
error:|
| in copyprop_hardreg_forward_1, at regrename.c:1589 |
| Error detected around a-ngcefu.adb:538 |
| 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.
raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:424
--
Summary: GNAT Bug Box During Build [regression]
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: ada
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: joel at gcc dot gnu dot org
GCC target triplet: i386-rtems4.9
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37094
[Bug ada/37040] GNAT Socket Code Broken on RTEMS
--- Comment #4 from joel at gcc dot gnu dot org 2008-08-12 12:52 --- Patch committed to SVN trunk. -- joel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37040
[Bug tree-optimization/37095] New: [4.4 regression] Trouble with covariant return
The following valid code snippet fails to compile on mainline when compiled
with -O:
===
struct A
{
virtual A* foo();
};
struct B : virtual A
{
virtual B* foo() { return 0; }
};
B b;
===
bug.cc:11: error: 'B* *.LTHUNK1()' aliased to undefined symbol
'_ZTch0_v0_n32_N1B3fooEv'
--
Summary: [4.4 regression] Trouble with covariant return
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: tree-optimization
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=37095
[Bug tree-optimization/37095] [4.4 regression] Trouble with covariant return
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37095
[Bug c++/37096] New: conditional evaluation incorrect with -O3
// system: core duo, 2.4 GHz, 64bit debian sid, vanilla kernel 2.6.26.2
// I stumbled over this using gcc 4.3.1 (Debian 4.3.1-8)
// compiler switches: -O3 -mssse3
// there were no compiler warnings / errors.
const int32_t nCC_[16] =
{
3, 2, 2, 1, 1, 1, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0
};
int32_t Residual4x4( int16_t *pAR, int32_t nCost )
{
int32_t nRun = 0;
for( int i=0 ; i16 ; ++i )
if ( const int v = pAR[i] ) {
nCost += ( abs(v) 1 ) ? 16 : nCC_[nRun];
nRun = 0;
} else
++nRun;
}
// the above code calculates nCost uncorrectly (leading to a segfault later on)
// when I use the compiler switch -O2 or replace the conditional assignment by
an if / else
// construct, everything works fine.
// gcc 4.2 works fine too. (-with -O3 -msse2)
--
Summary: conditional evaluation incorrect with -O3
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: erik dot moller at cycos dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37096
[Bug c++/36741] [4.3/4.4 regression] Bogus large integer implicitly truncated passing size_t constant to new
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-07-10 14:24:55 |2008-08-12 13:25:52 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741
[Bug target/37094] Ada build broken
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-08-12 14:00 --- See http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00776.html -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Severity|normal |blocker Status|UNCONFIRMED |NEW Component|ada |target Ever Confirmed|0 |1 GCC target triplet|i386-rtems4.9 |i[345]86-*-* Last reconfirmed|-00-00 00:00:00 |2008-08-12 14:00:44 date|| Summary|GNAT Bug Box During Build |Ada build broken |[regression]| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37094
[Bug bootstrap/37086] Cross-compilers built with GCC 3.4 do not work
--- Comment #5 from joseph at codesourcery dot com 2008-08-12 14:00 --- Subject: Re: Cross-compilers built with GCC 3.4 do not work On Tue, 12 Aug 2008, rguenth at gcc dot gnu dot org wrote: As this is a bug in GCC 3.4 let's close this as invalid (can't we do a C only host bootstrap for building cross-compilers to work around issues with host compilers?) Existing documented practice is to support building cross compilers using 2.95 or later. Again, this (and keeping the requirement to 3.4 as previously discussed if C++ use is introduced, and ensuring bootstrap from a compiler with a different C++ ABI and runtime works) is not about what builds are possible but about what builds are not made more complicated than necessary. By now we can probably remove the workaround This paragraph is here to try to keep Sun CC from dying. The number of chars here seems crucial */ in gcc.c though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37086
[Bug c/35746] [4.3 regression] ICE with undefined variables
--- Comment #9 from aldyh at gcc dot gnu dot org 2008-08-12 14:05 --- Subject: Bug 35746 Author: aldyh Date: Tue Aug 12 14:04:18 2008 New Revision: 139018 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139018 Log: PR c/35746 * gimplify.c (gimplify_expr): Do not convert MODIFY_EXPR to GIMPLE_MODIFY_STMT upon GS_ERROR. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/pr35746.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/gimplify.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35746
[Bug c/35746] [4.3 regression] ICE with undefined variables
--- Comment #10 from aldyh at gcc dot gnu dot org 2008-08-12 14:06 --- http://gcc.gnu.org/ml/gcc-patches/2008-08/msg00778.html -- aldyh at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35746
[Bug tree-optimization/35428] [4.3 regression] ICE with -ftrapv
--- Comment #11 from aldyh at gcc dot gnu dot org 2008-08-12 14:21 ---
Still can't reproduce. What target are you compiling for?
Verify my steps below, and see if there's any discrepancy in what you are
doing.
anquetil:/build/43/gcc$ ./cc1 --version
GNU C (GCC) version 4.3.2 20080812 (prerelease) [gcc-4_3-branch revision
139018] (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.1.2 20070925 (Red Hat 4.1.2-33), GMP
version 4.2.2, MPFR version 2.3.0-p2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
anquetil:/build/43/gcc$ ./cc1 a.c -O3 -ftrapv -quiet
anquetil:/build/43/gcc$ ./cc1plus a.c -O3 -ftrapv -quiet
anquetil:/build/43/gcc$ ./cc1 a.c -ftrapv -O -ftree-vectorize -quiet
anquetil:/build/43/gcc$ ./cc1plus a.c -ftrapv -O -ftree-vectorize -quiet
anquetil:/build/43/gcc$ uname -a
Linux anquetil.quesejoda.com 2.6.24.7-92.fc8 #1 SMP Wed May 7 16:26:02 EDT 2008
x86_64 x86_64 x86_64 GNU/Linux
anquetil:/build/43/gcc$ cat a.c
void foo(int x[])
{
int i, j;
for (i = 0; i 2; i++)
for (j = 0; j 2; j++)
{
x[i] = x[i*j];
x[i] = x[i*j];
}
}
--
aldyh at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED|WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35428
[Bug bootstrap/37097] New: [4.4 Regression]: Revision 139014 failed to bootstrap
On Linux/x86, I got cc1: warnings being treated as errors ../../src/gcc/builtins.c: In function 'do_mpfr_bessel_n': ../../src/gcc/builtins.c:13085: error: unused variable 'result_c' ../../src/gcc/builtins.c:13085: error: unused variable 'result_s' make[5]: *** [builtins.o] Error 1 -- Summary: [4.4 Regression]: Revision 139014 failed to bootstrap Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37097
[Bug bootstrap/37097] [4.4 Regression]: Revision 139014 failed to bootstrap
--- Comment #1 from uweigand at gcc dot gnu dot org 2008-08-12 14:37 --- Subject: Bug 37097 Author: uweigand Date: Tue Aug 12 14:35:54 2008 New Revision: 139019 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139019 Log: PR bootstrap/37097 * builtins.c (do_mpfr_bessel_n): Fix copy-and-paste bug introduced by last change. -This line, and those below, will be ignored-- Mgcc/builtins.c Mgcc/ChangeLog Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37097
[Bug tree-optimization/35428] [4.3 regression] ICE with -ftrapv
--- Comment #12 from reichelt at gcc dot gnu dot org 2008-08-12 14:37 --- I'm using i686-pc-linux-gnu. On x86_64-unknown-linux-gnu you probably need to add -m32 to the flags. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35428
[Bug c++/36741] [4.3/4.4 regression] Bogus large integer implicitly truncated passing size_t constant to new
--- Comment #3 from dodji at gcc dot gnu dot org 2008-08-12 14:42 --- Created an attachment (id=16058) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16058action=view) primary candidate fix This minimal patch fixes the problem for me and regtests on x86_64. I have some questions though and would like to have you guys comments, if possible. My understanding is that the parameter of the new operator being size_t, its type should represented in GENERIC using an integer that is not signed. The issue here is that the type of the parameter of the new operator has the same time as 'sizetype', which has its flag TYPE_IS_SIZETYPE set. When TYPE_IS_SIZETYPE is set on an integer, some type checking machinery consider that integer to be signed. So the the representation of that integer is sign extended. So a quick fix was to make sure the type of the parameter of the new operator has the same time as 'size_type_node', instead of 'sizetype'. Maybe there is a better way of solving this. Also, maybe I should modify the other uses of 'sizetype' in the build_new_1() function and replace them with size_type_node' instead. But that's maybe out of the strict scope of this bug. I am not sure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741
[Bug libstdc++/23888] should debug mode throw instead of assert?
--- Comment #5 from sylvain dot pion at sophia dot inria dot fr 2008-08-12 14:42 --- What about providing both modes, with for example a global run-time flag to select the mode which is the most appropriate ? And maybe defaulting to assert, since it looks like users might prefer this (?). Also, a side note : throwing an uncaught exception does not seem to destroy the stack, when you are under the debugger. I just made a test, and it seems to work. Here is the typical backtrace that you get: (gdb) bt #0 0x94ed0b9e in __kill () #1 0x94ed0b91 in kill$UNIX2003 () #2 0x94f47ec2 in raise () #3 0x94f5747f in abort () #4 0x91261005 in __gnu_cxx::__verbose_terminate_handler () #5 0x9125f10c in __gxx_personality_v0 () #6 0x9125f14b in std::terminate () #7 0x9125f261 in __cxa_throw () #8 0x1f79 in f (i=1) at test_throw_debug.cpp:3 #9 0x1f8c in main () at test_throw_debug.cpp:9 I agree it is still a problem for programs that catch the exception, thinking no other exception should occur. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23888
[Bug bootstrap/37097] [4.4 Regression]: Revision 139014 failed to bootstrap
--- Comment #2 from uweigand at gcc dot gnu dot org 2008-08-12 14:45 --- Should be fixed now ... -- uweigand at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37097
[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*
--- Comment #25 from jakub at gcc dot gnu dot org 2008-08-12 14:48 --- Created an attachment (id=16059) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16059action=view) dbr.patch Patch that should cure this testcase. We weren't handling the dbrs correctly. For the compute_barrier_args_size* calls when setting destination args_size depth for annulled branches we should only consider the insns from target and for normal sequence only insns from !target. And in normal args_size computation we need to ignore the target insns. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
[Bug tree-optimization/35428] [4.3 regression] ICE with -ftrapv
--- Comment #13 from aldyh at gcc dot gnu dot org 2008-08-12 15:02 --- Nope, still can't reproduce with i686-pc-linux-gnu, or with x86-64-linux using -m32. FWIW, Jakub can't reproduce it either. Can anyone beside Volker reproduce this? If nobody else can't, I'm inclined to say it's a problem on Volker's setup, and close the PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35428
[Bug c/36849] IMA rejects to merge (function)decls with va_args
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-08-12 15:04 --- (In reply to comment #2) Do you have a suggestion on how libc could legally provide an mremap implementation as per the example in #0 that can be compiled with -combine? You don't. You can try some tricks with __asm__ but I would not recommend it though. As far as I can tell mremap only takes 4 arguments anyways. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36849
[Bug tree-optimization/35428] [4.3 regression] ICE with -ftrapv
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-08-12 15:16 --- Fails for me on a x86_64 - i586-linux cross ./cc1 -quiet -O3 -ftrapv /tmp/t.c /tmp/t.c: In function 'foo': /tmp/t.c:2: internal compiler error: tree check: expected integer_cst, have polynomial_chrec in int_cst_value, at tree.c:8078 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. you probably need to configure with --enable-checking. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2008-03-04 13:30:42 |2008-08-12 15:16:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35428
[Bug tree-optimization/35428] [4.3 regression] ICE with -ftrapv
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2008-08-12 15:16:37 |2008-08-12 15:16:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35428
[Bug c/35443] [4.2/4.3/4.4 regression] Completely broken diagnostic with bind_expr
-- aldyh at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35443
[Bug c/36849] IMA rejects to merge (function)decls with va_args
--- Comment #4 from aldot at gcc dot gnu dot org 2008-08-12 15:48 --- (In reply to comment #3) You don't. You can try some tricks with __asm__ but I would not recommend it though. Yes, i dont' want that. As far as I can tell mremap only takes 4 arguments anyways. unfortunately it has a very ugly interface and takes a 5th argument, depending on the flags: void * mremap(void *old_address, size_t old_size , size_t new_size, int flags); [] The flags bit-mask argument may be 0, or include the following flag: [] MREMAP_FIXED (since Linux 2.3.31) This flag serves a similar purpose to the MAP_FIXED flag of mmap(2). If this flag is specified, then mremap() accepts a fifth argument, void *new_address, which specifies a page- aligned address to which the mapping must be moved. Any previ- ous mapping at the address range specified by new_address and new_size is unmapped. If MREMAP_FIXED is specified, then MREMAP_MAYMOVE must also be specified. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36849
[Bug c++/37096] conditional evaluation incorrect with -O3
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-08-12 15:49 --- Can you please provide a testcase that can be complied and run stating the expected and the errorneous output you see? Thanks. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37096
[Bug c++/36741] [4.3/4.4 regression] Bogus large integer implicitly truncated passing size_t constant to new
--- Comment #4 from dodji at gcc dot gnu dot org 2008-08-12 16:10 --- Created an attachment (id=16060) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16060action=view) second fix candidate This patch should be better than the previous one because it one must use size_binop() with a sizetype integer, not with a size_type_node one. regtested on x86_64. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Attachment #16058|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36741
[Bug c/35746] [4.3 regression] ICE with undefined variables
--- Comment #11 from andreasmeier80 at gmx dot de 2008-08-12 17:14 --- Should the testcase go also in mainline? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35746
[Bug tree-optimization/37084] [4.4 regression] ICE in gimple_assign_rhs1
--- Comment #4 from jakub at gcc dot gnu dot org 2008-08-12 17:59 --- Subject: Bug 37084 Author: jakub Date: Tue Aug 12 17:57:49 2008 New Revision: 139028 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139028 Log: PR tree-optimization/37084 * tree-inline.c (copy_bb): Call gimple_regimplify_operands if id-regimplify, don't assume stmt is a cast assignment. * g++.dg/tree-ssa/pr37084.C: New test. Added: trunk/gcc/testsuite/g++.dg/tree-ssa/pr37084.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37084
[Bug target/35575] ICE: in function_arg_slotno, at config/sparc/sparc.c:4696
--- Comment #1 from joel at gcc dot gnu dot org 2008-08-12 17:59 --- This is 5 months old and the target now builds. Must have been fixed along the way. Closing. -- joel at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35575
[Bug ada/21327] gnat_ugn.texi invalid @direntry
--- Comment #3 from joel at gcc dot gnu dot org 2008-08-12 18:05 --- This looks to still be needed as of gcc (GCC) 4.4.0 20080811 (experimental) [trunk revision 138957] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21327
[Bug middle-end/37014] [4.2/4.3/4.4 Regression] internal compiler error: in expand_expr_real_1, at expr.c:8760
--- Comment #8 from jakub at gcc dot gnu dot org 2008-08-12 18:07 --- Subject: Bug 37014 Author: jakub Date: Tue Aug 12 18:05:43 2008 New Revision: 139029 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139029 Log: PR middle-end/37014 * expr.c (expand_expr_real_1): Handle TRUTH_ANDIF_EXPR and TRUTH_ORIF_EXPR. * dojump.c (do_jump): Likewise. * gcc.c-torture/compile/20080812-1.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/20080812-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/dojump.c trunk/gcc/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37014
[Bug target/23695] [ColdFire] Illegal move of byte intoo address register causes compiler to ICE
--- Comment #6 from joel at gcc dot gnu dot org 2008-08-12 18:10 --- This works with 4.3.1. I am closing this one. -- joel at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Known to fail|4.1.0 |4.1.0 4.2.4 Known to work|4.3.0 |4.3.0 4.3.1 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23695
[Bug libgomp/26165] Cannot find libgomp.spec after 'make install' on x86_64 and ppc64
--- Comment #16 from froydnj at gcc dot gnu dot org 2008-08-12 18:20 --- Subject: Bug 26165 Author: froydnj Date: Tue Aug 12 18:19:08 2008 New Revision: 139031 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139031 Log: PR libgomp/26165 * gcc.c (include_spec_function): Tweak call to find_a_file. Modified: trunk/gcc/ChangeLog trunk/gcc/gcc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26165
[Bug fortran/34805] defined assignment not allowed to vector subscripted array
--- Comment #6 from dick dot hendrickson at gmail dot com 2008-08-12 18:27 --- Subject: Re: defined assignment not allowed to vector subscripted array On Fri, Aug 8, 2008 at 3:39 PM, jv244 at cam dot ac dot uk [EMAIL PROTECTED] wrote: --- Comment #5 from jv244 at cam dot ac dot uk 2008-08-08 20:39 --- has J3 judged the testcase ? Almost. It's interpretation request 111. The status in June was passed J3, it next needs to be accepted by WG5, although that is likely to be a mere formality. The J3 vote was unanimous and taken at a joint WG5/J3 meeting. It's unlikely to change. Unfortunately, they got it wrong and are rejecting my claim that the test is standard conforming. So, you can mark this bug report as closed with no action or user error or whatever you use to (politely) tell someone to go away. Dick Hendrickson -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34805 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34805
[Bug middle-end/37014] [4.2/4.3/4.4 Regression] internal compiler error: in expand_expr_real_1, at expr.c:8760
--- Comment #9 from jakub at gcc dot gnu dot org 2008-08-12 18:37 --- Subject: Bug 37014 Author: jakub Date: Tue Aug 12 18:36:28 2008 New Revision: 139032 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139032 Log: PR middle-end/37014 * expr.c (expand_expr_real_1): Handle TRUTH_ANDIF_EXPR and TRUTH_ORIF_EXPR. * dojump.c (do_jump): Likewise. * gcc.c-torture/compile/20080812-1.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.c-torture/compile/20080812-1.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/dojump.c branches/gcc-4_3-branch/gcc/expr.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37014
[Bug c/35742] [4.2/4.3/4.4 regression] Broken diagnostic: 'goto_expr' not supported by pp_c_expression
-- aldyh at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35742
[Bug c/35442] [4.2/4.3/4.4 Regression] Completely broken diagnostic with view_convert_expr
-- aldyh at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35442
[Bug c/35441] [4.2/4.3/4.4 regression] Completely broken diagnostics
-- aldyh at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aldyh at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35441
[Bug debug/37098] New: [vta] ICE in expand_debug_expr, at cfgexpand.c:2519
the following testcase http://www.pci.unizh.ch/vandevondele/tmp/all_cp2k_gfortran.f90.gz generates an ICE when compiling gfortran -v -c -g -O3 -ffast-math -funroll-loops -ftree-vectorize -march=native all_cp2k_gfortran.f90 Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_vta/gcc/configure --prefix=/data03/vondele/gcc_vta/build --with-gmp=/data03/vondele/ --with-mpfr=/data03/vondele/ --enable-languages=c,fortran Thread model: posix gcc version 4.4.0 20080729 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-g' '-O3' '-ffast-math' '-funroll-loops' '-ftree-vectorize' /data03/vondele/gcc_vta/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951 all_cp2k_gfortran.f90 -march=k8-sse3 -mcx16 -msahf --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=1024 -mtune=k8 -quiet -dumpbase all_cp2k_gfortran.f90 -auxbase all_cp2k_gfortran -g -O3 -version -ffast-math -funroll-loops -ftree-vectorize -fintrinsic-modules-path /data03/vondele/gcc_vta/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude -o /tmp/ccukjSCb.s GNU Fortran (GCC) version 4.4.0 20080729 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20080729 (experimental), GMP version 4.2.1, MPFR version 2.2.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 paren_expr 0x2acbad1ad180 type real_type 0x2acb8bd15600 real(kind=8) asm_written DF size integer_cst 0x2acb8bcfdb40 constant 64 unit size integer_cst 0x2acb8bcfdb70 constant 8 align 64 symtab -1940364928 alias set 3 canonical type 0x2acb8bd15600 precision 64 pointer_to_this pointer_type 0x2acb8bd15840 reference_to_this reference_type 0x2acb8c04ec00 arg 0 minus_expr 0x2acbad1ad140 type real_type 0x2acb8bd15600 real(kind=8) arg 0 mult_expr 0x2acbad1ad0c0 type real_type 0x2acb8bd15600 real(kind=8) arg 0 var_decl 0x2acb8f3f3b40 D.88376 arg 1 var_decl 0x2acb8ee46640 D.88368 arg 1 mult_expr 0x2acbad1ad100 type real_type 0x2acb8bd15600 real(kind=8) arg 0 var_decl 0x2acb8f2e0a00 D.88374 arg 1 var_decl 0x2acb8f03f780 D.88364 all_cp2k_gfortran.f90: In function det_3x3_2: all_cp2k_gfortran.f90:43446: internal compiler error: in expand_debug_expr, at cfgexpand.c:2519 -- Summary: [vta] ICE in expand_debug_expr, at cfgexpand.c:2519 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37098
[Bug debug/37098] [vta] ICE in expand_debug_expr, at cfgexpand.c:2519
--- Comment #1 from jv244 at cam dot ac dot uk 2008-08-12 19:04 --- some vta testing on CP2K as requested in http://gcc.gnu.org/ml/gcc/2008-08/msg00160.html -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37098
[Bug debug/37098] [vta] ICE in expand_debug_expr, at cfgexpand.c:2519
--- Comment #2 from jv244 at cam dot ac dot uk 2008-08-12 19:25 --- already happens at -O1: gfortran -c -g -O1 all_cp2k_gfortran.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37098
[Bug fortran/37099] New: Wrong results when comparing a character array to a character expression
When compiled with gfortran 4.3.1/4.4.0, the following code:
module xparams
integer,parameter :: exprbeg=100,exprend=154
character(*),dimension(exprbeg:exprend),parameter ::
exprs=(/'nint() ','log10() ','sqrt() ','acos() ','asin() ',
'atan() ','cosh() ','sinh() ','tanh() ','int() ',
'cos() ','sin() ','tan() ','exp() ','log() ','abs() ',
'delta() ','step() ','rect() ','max(,) ','min(,) ','bj0() ',
'bj1() ','bjn(,) ','by0() ','by1() ','byn(,) ','logb(,) ',
'erf() ','erfc() ','lgamma()','gamma() ','csch() ','sech() ',
'coth() ','lif(,,) ','gaus() ','sinc() ','atan2(,)','mod(,) ',
'nthrt(,)','ramp() ','fbi() ','fbiq() ','uran(,) ','aif(,,,)',
'sgn() ','cbrt() ','fact() ','somb() ','bk0() ','bk1() ',
'bkn(,) ','bbi(,,) ','bbiq(,,)'/)
logical :: tmp(55,26)
character(26) :: al = 'abcdefghijklmnopqrstuvwxyz'
end
program pack_bug
use xparams
do i = 1, 1
tmp(:,i) = (exprs(:)(1:1)==al(i:i))
print '(55L)', exprs(:)(1:1)=='a'
print '(55L)', tmp(:,i)
end do
end
gives
FFFTTTFTFFTFFTF
FFF
The first line is the expected result, the second one is wrong.
See http://gcc.gnu.org/ml/fortran/2008-08/msg00057.html for the original post.
the dump original gives:
pack_bug ()
{
extern character(kind=1) al[1:26];
integer(kind=4) i;
extern logical(kind=4) tmp[1430];
static integer(kind=4) options.0[7] = {68, 127, 0, 0, 0, 1, 0};
_gfortran_set_options (7, (void *) options.0);
i = 1;
if (i = 1)
{
while (1)
{
{
logical(kind=4) D.1013;
{
integer(kind=4) D.992;
static character(kind=1)[1:8] * A.1[55] = {n[1]{lb: 1 sz: 1},
l[1]{lb: 1 sz: 1}, s[1]{lb: 1 sz: 1}, a[1]{lb: 1 sz: 1}, a[1]{lb: 1
sz: 1}, a[1]{lb: 1 sz: 1}, c[1]{lb: 1 sz: 1}, s[1]{lb: 1 sz: 1},
t[1]{lb: 1 sz: 1}, i[1]{lb: 1 sz: 1}, c[1]{lb: 1 sz: 1}, s[1]{lb: 1
sz: 1}, t[1]{lb: 1 sz: 1}, e[1]{lb: 1 sz: 1}, l[1]{lb: 1 sz: 1},
a[1]{lb: 1 sz: 1}, d[1]{lb: 1 sz: 1}, s[1]{lb: 1 sz: 1}, r[1]{lb: 1
sz: 1}, m[1]{lb: 1 sz: 1}, m[1]{lb: 1 sz: 1}, b[1]{lb: 1 sz: 1},
b[1]{lb: 1 sz: 1}, b[1]{lb: 1 sz: 1}, b[1]{lb: 1 sz: 1}, b[1]{lb: 1
sz: 1}, b[1]{lb: 1 sz: 1}, l[1]{lb: 1 sz: 1}, e[1]{lb: 1 sz: 1},
e[1]{lb: 1 sz: 1}, l[1]{lb: 1 sz: 1}, g[1]{lb: 1 sz: 1}, c[1]{lb: 1
sz: 1}, s[1]{lb: 1 sz: 1}, c[1]{lb: 1 sz: 1}, l[1]{lb: 1 sz: 1},
g[1]{lb: 1 sz: 1}, s[1]{lb: 1 sz: 1}, a[1]{lb: 1 sz: 1}, m[1]{lb: 1
sz: 1}, n[1]{lb: 1 sz: 1}, r[1]{lb: 1 sz: 1}, f[1]{lb: 1 sz: 1},
f[1]{lb: 1 sz: 1}, u[1]{lb: 1 sz: 1}, a[1]{lb: 1 sz: 1}, s[1]{lb: 1
sz: 1}, c[1]{lb: 1 sz: 1}, f[1]{lb: 1 sz: 1}, s[1]{lb: 1 sz: 1},
b[1]{lb: 1 sz: 1}, b[1]{lb: 1 sz: 1}, b[1]{lb: 1 sz: 1}, b[1]{lb: 1
sz: 1}, b[1]{lb: 1 sz: 1}};
D.992 = i;
{
integer(kind=4) D.994;
integer(kind=4) S.2;
D.994 = D.992 * 55 + -56;
S.2 = 1;
while (1)
{
if (S.2 55) goto L.3;
tmp[S.2 + D.994] = _gfortran_compare_string (8, A.1[S.2 +
-1], 1, (character(kind=1)[1:26] *) al[i]{lb: 1 sz: 1}) == 0;
S.2 = S.2 + 1;
}
L.3:;
}
}
{
struct __st_parameter_dt dt_parm.3;
dt_parm.3.common.filename = pack_bug_red.f90[1]{lb: 1 sz: 1};
dt_parm.3.common.line = 22;
dt_parm.3.format = (55L)[1]{lb: 1 sz: 1};
dt_parm.3.format_len = 5;
dt_parm.3.common.flags = 4096;
dt_parm.3.common.unit = 6;
_gfortran_st_write (dt_parm.3);
{
static logical(kind=4) A.4[55] = {0, 0, 0, 1, 1, 1, 0, 0, 0, 0,
0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 1, 0, 0, 0, 0, 0, 0, 1, 0, 0, 0, 0, 0, 0, 0, 0, 0};
{
integer(kind=4) S.5;
S.5 = 0;
while (1)
{
if (S.5 54) goto L.4;
{
logical(kind=4) D.999;
D.999 = A.4[S.5];
_gfortran_transfer_logical (dt_parm.3, D.999, 4);
}
S.5 = S.5 + 1;
}
L.4:;
}
}
_gfortran_st_write_done (dt_parm.3);
}
{
struct __st_parameter_dt dt_parm.6;
dt_parm.6.common.filename = pack_bug_red.f90[1]{lb: 1 sz: 1};
dt_parm.6.common.line = 23;
dt_parm.6.format = (55L)[1]{lb: 1 sz: 1};
dt_parm.6.format_len = 5;
dt_parm.6.common.flags = 4096;
[Bug c++/37087] Segfault on compiling template defined in wrong namespace.
--- Comment #2 from paolo at gcc dot gnu dot org 2008-08-12 19:39 --- Subject: Bug 37087 Author: paolo Date: Tue Aug 12 19:38:02 2008 New Revision: 139034 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139034 Log: /cp 2008-08-12 Paolo Carlini [EMAIL PROTECTED] PR c++/37087 * parser.c (cp_parser_class_head): Early return error_mark_node in case of global qualification of class name or qualified name that does not name a class. /testsuite 2008-08-12 Paolo Carlini [EMAIL PROTECTED] PR c++/37087 * g++.dg/template/crash80.C: New. * g++.old-deja/g++.other/decl5.C: Adjust. Added: trunk/gcc/testsuite/g++.dg/template/crash80.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.old-deja/g++.other/decl5.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37087
[Bug fortran/37099] Wrong results when comparing a character array to a character expression
-- jv244 at cam dot ac dot uk changed: What|Removed |Added OtherBugsDependingO||32834 nThis|| Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Known to fail||4.3.1 4.4.0 Last reconfirmed|-00-00 00:00:00 |2008-08-12 19:41:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37099
[Bug c++/37087] Segfault on compiling template defined in wrong namespace.
--- Comment #3 from paolo dot carlini at oracle dot com 2008-08-12 19:45 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|paolo dot carlini at oracle |unassigned at gcc dot gnu |dot com |dot org Status|ASSIGNED|NEW Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37087
[Bug target/34439] ICE in reload_cse_simplify_operands for Coldfire
--- Comment #4 from joel at gcc dot gnu dot org 2008-08-12 19:47 --- Works with 4.3.1. Should this be closed if someone can confirm it is fixed on the trunk? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34439
[Bug testsuite/36087] [4.4 Regression] test failures between revs. 134696 and 134717
--- Comment #9 from janis at gcc dot gnu dot org 2008-08-12 21:20 --- Subject: Bug 36087 Author: janis Date: Tue Aug 12 21:18:54 2008 New Revision: 139037 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139037 Log: PR testsuite/36087 * gcc.dg/var-expand3.c: Fix name of dump file. Modified: trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/var-expand3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36087
[Bug c++/37100] New: /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/bits/stl_pair.h:99: error 404
At /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/bits/stl_pair.h:99: /// http://gcc.gnu.org/onlinedocs/libstdc++/20_util/howto.html#pairlt the referenced doc doesn't exist. -- Summary: /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++- v4/bits/stl_pair.h:99: error 404 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pentek dot imre at gmail dot com GCC build triplet: x86_64-pc-linux-gnu GCC host triplet: x86_64-pc-linux-gnu GCC target triplet: x86_64-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37100
[Bug libstdc++/37100] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/bits/stl_pair.h:99: error 404
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-08-12 22:43 --- That is because it moved: http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt04ch10.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37100
[Bug libstdc++/37100] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/bits/stl_pair.h:99: error 404
--- Comment #2 from paolo dot carlini at oracle dot com 2008-08-12 23:10 --- For now, let's just change the url to point to the utilities subsection, which doesn't change when the documentation is regenerated (... I know, we should really deal with the latter issue, but it's known already) -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-08-12 23:10:43 date|| Target Milestone|--- |4.3.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37100
[Bug tree-optimization/37101] New: [4.2/4.3 Regression] wrong code: tree vectorizer omits bogus movq/movlps construct
(see http://bugs.gentoo.org/show_bug.cgi?id=227311 )
Seeing this on my (amd64) gcc 4.3.1 in xorg-server code dix/resource.c with
-O2 -march=nocona -ftree-vectorize.
( gcc -O2 -march=nocona -ftree-vectorize -o resource.o -c resource.i )
Unfortunately I was not able to reproduce this using a simpler testcase,
because gcc would omit a punpcklqdq instead of the offending movq/movlps,
so I attached the whole thing with a description of the problem and an analysis
of the wrong assembler code emitted.
When going through the attached file, look for the RebuildTable function,
which is inlined into AddResource.
It contains the following construct:
for (rptr = resources, tptr = tails; --j = 0; rptr++, tptr++)
{
*rptr = NullResource;
*tptr = rptr;
}
which initialises two arrays of pointers, one filled with null pointers and the
other with a pointer to the just filled NULL in the other array.
The symptom (leeding to a segfault just after) shows up that the second tails
array is incorrectly initialized. Every second entry does not contain the
correct pointer (i.e. filled with the correct value of rptr), but contains a
ladder starting at 0 (0x8, 018, 0x28, ...), i.e. does not add the value of
resources as start offset. (the whole array goes like 0xc000, 0x0008,
0xc010, 0x0018, 0xc020, 0x0028, ... instead of 0xc000, 0xc008, 0xc010, 0xc018,
0xc020, 0xc028, ...)
Digging through the code it seems that the tree vectorizer is emitting an
optimized implementation of the loop for large amount of entries (j starts at a
value of 128 when the failure was observed) after the body of the function.
It fills a bunch of xmm registers with values, so that both arrays can be
filled 16 bytes at a time (instead of 8 bytes at a time).
Now, due to the bug, the register that pair-wise fills the tails array should
be doing sth like this (pseudo-code)
xmm1 = ((resources + 0x0008) 64) + resources
xmm2 = (0x0010 64) + 0x0010
and then fill in xmm1 and add xmm2 to it after each iteration, or something
like that.
What I now seem to see be seeing, is that in my terminology here xmm1 is not
filled correctly, the upper 64 bit seem to be zero, which would explain how the
array is incorrectly filled.
The assembler code of this part looks like:
(the start of the for loop in the default code path)
f0d: 44 89 eemov%r13d,%esi
f10: 83 ee 01sub$0x1,%esi
f13: 78 32 js f47 AddResource+0x1a2
f15: 41 83 fd 09 cmp$0x9,%r13d
f19: 0f 87 22 01 00 00 ja 1041 AddResource+0x29c
So here seems to be some logic for the first --j and as to whether the
optimized out-of-line code should be jumped (and a non-sse implementation
of the loop body below, which looks ok).
Starting at 1041 there is some more funny logic which I don't fully get, but
some instructions below is where I think the cause of the problem is:
Here, the code that initializes xmm1 (also the xmm1 in my pseudo-code above):
107e: 48 8b 44 24 38 mov0x38(%rsp),%rax
1083: 48 83 c0 08 add$0x8,%rax
1087: 66 48 0f 6e c8 movq %rax,%xmm1
108c: 0f 12 4c 24 38 movlps 0x38(%rsp),%xmm1
I'm no sse2 expert, but it seems as if movlps was supposed to move the lower
part of xmm1 (which contains resources + 0x8) to the upper part before
overwriting the lower part with resources? Or something, like that, which it
doesn't (using google and http://www.ews.uiuc.edu/~cjiang/reference/vc191.htm
as a reference... :-))
Anyway, here is the rest of the method:
1091: 66 0f 6f c1 movdqa %xmm1,%xmm0
1095: 31 d2 xor%edx,%edx
1097: 31 c0 xor%eax,%eax
1099: 66 0f 6f 15 00 00 00movdqa 0x0(%rip),%xmm2# 10a1
AddResource+0x2fc
10a0: 00
109d: R_X86_64_PC32 .LC3+0xfffc
(presumably loads 0x00100010 into xmm2)
10a1: 66 0f ef c9 pxor %xmm1,%xmm1
(xmm1 now contains zeroes to fill the resources array)
10a5: 48 8b 5c 24 38 mov0x38(%rsp),%rbx
10aa: 66 0f 7f 0c 03 movdqa %xmm1,(%rbx,%rax,1) - fill 2
resources entries
10af: 66 41 0f 7f 04 04 movdqa %xmm0,(%r12,%rax,1) - fill 2
tails entries
10b5: 83 c2 01add$0x1,%edx
10b8: 48 83 c0 10 add$0x10,%rax
10bc: 66 0f d4 c2 paddq %xmm2,%xmm0
10c0: 39 ca cmp%ecx,%edx
10c2: 72 e1 jb 10a5 AddResource+0x300
Trying to reproduce the test case, gcc omitted a punpcklqdq to initialized
the base instead, which works, so this must me some different code triggered by
some other register constraints or something (?).
As from the report, I guess this
[Bug libstdc++/37100] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/bits/stl_pair.h:99: error 404
--- Comment #3 from paolo at gcc dot gnu dot org 2008-08-12 23:15 --- Subject: Bug 37100 Author: paolo Date: Tue Aug 12 23:14:10 2008 New Revision: 139040 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139040 Log: 2008-08-12 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/37100 * include/bits/stl_pair.h: Fix documentation URL in comment. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_pair.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37100
[Bug libstdc++/37100] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/bits/stl_pair.h:99: error 404
--- Comment #4 from paolo at gcc dot gnu dot org 2008-08-12 23:16 --- Subject: Bug 37100 Author: paolo Date: Tue Aug 12 23:15:23 2008 New Revision: 139041 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139041 Log: 2008-08-12 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/37100 * include/bits/stl_pair.h: Fix documentation URL in comment. Modified: branches/gcc-4_3-branch/libstdc++-v3/ChangeLog branches/gcc-4_3-branch/libstdc++-v3/include/bits/stl_pair.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37100
[Bug libstdc++/37100] /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/bits/stl_pair.h:99: error 404
--- Comment #5 from paolo dot carlini at oracle dot com 2008-08-12 23:17 --- Fixed for 4.3.2. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37100
[Bug tree-optimization/37101] [4.2/4.3 Regression] wrong code: tree vectorizer omits bogus movq/movlps construct
--- Comment #1 from christophe at saout dot de 2008-08-12 23:17 --- Created an attachment (id=16061) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16061action=view) preprocessed source file to be compiled to see the wrong generated code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37101
[Bug c++/32305] ICE in initialize_flags_in_bb with -O -fipa-pta
--- Comment #8 from janis at gcc dot gnu dot org 2008-08-12 23:57 --- With r139042 the GCC Manual says that -fipa-pta is an experimental option that does not affect code generation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32305
[Bug debug/37098] [vta] ICE in expand_debug_expr, at cfgexpand.c:2519
--- Comment #3 from aoliva at gcc dot gnu dot org 2008-08-13 00:51 --- Created an attachment (id=16062) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16062action=view) Patch that may fix the bug Thanks for the report. Wow, I was a bit surprised this didn't show up building libgfortran. This patch ought to fix this one. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37098
[Bug rtl-optimization/36998] [4.3/4.4 regression] Ada bootstrap broken on i586-*-*
--- Comment #26 from kkojima at gcc dot gnu dot org 2008-08-13 03:30 --- (In reply to comment #25) Created an attachment (id=16059) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16059action=view) [edit] dbr.patch This fixes the ICE. Trunk revision 138972 + pop.patch + dbr.patch with reverting disable-asserts.patch was built successfully on sh4-unknown-linux-gnu for all languages except ada. It has passed regtesting on that target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36998
[Bug c/37102] New: possible integer codegen bug
This is for svn 139046 on Ubuntu Hardy.
[EMAIL PROTECTED]:~/volatile/tmp0$ current-gcc -O -Wall -fwrapv small.c -o small
[EMAIL PROTECTED]:~/volatile/tmp0$ ./small
5
[EMAIL PROTECTED]:~/volatile/tmp0$ current-gcc -O3 -Wall -fwrapv small.c -o
small
[EMAIL PROTECTED]:~/volatile/tmp0$ ./small
0
[EMAIL PROTECTED]:~/volatile/tmp0$ current-gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --program-prefix=current-
--enable-languages=c,c++ --prefix=/home/regehr
Thread model: posix
gcc version 4.4.0 20080813 (experimental) (GCC)
[EMAIL PROTECTED]:~/volatile/tmp0$ cat small.c
#include stdio.h
unsigned int g_24;
unsigned int g_37 = 1;
unsigned char g_225;
int main (void)
{
int l_289;
for (l_289 = 1; l_289 5; l_289 += 1) {
if (g_225) {
g_24 = g_37;
}
}
g_24 = g_37;
unsigned short context = g_24 1;
do {
if (context)
context = (context 1) ^ 1;
} while (0);
printf (%d\n, (int)context);
return 0;
}
--
Summary: possible integer codegen bug
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37102
[Bug c/37103] New: possible integer codegen bug
This is an interesting one...
Compiling the code below at all common optimization levels, gcc r139046
generates code that prints hello, as does 4.3.1. Pre-4.3 versions of gcc emit
code that prints nothing. I'm pretty sure that the older versions are correct.
#include stdio.h
int func_72 (void);
int func_72 (void)
{
printf (hello\n);
return 0;
}
void func_58 (unsigned short p_65);
void func_58 (unsigned short p_65)
{
char g_99 = -1;
(p_65 != g_99) || (func_72 ());
}
int main (void)
{
func_58 (-1);
return 0;
}
--
Summary: possible integer codegen bug
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37103
Re: [Bug c/37103] New: possible integer codegen bug
Note for most targets not printing is correct as char is signed by
default but for most powerpc targets the opposite is true. You should
have explicted included signed for g_99.
Sent from my iPhone
On Aug 12, 2008, at 22:10, regehr at cs dot utah dot edu [EMAIL PROTECTED]
wrote:
This is an interesting one...
Compiling the code below at all common optimization levels, gcc
r139046
generates code that prints hello, as does 4.3.1. Pre-4.3 versions
of gcc emit
code that prints nothing. I'm pretty sure that the older versions
are correct.
#include stdio.h
int func_72 (void);
int func_72 (void)
{
printf (hello\n);
return 0;
}
void func_58 (unsigned short p_65);
void func_58 (unsigned short p_65)
{
char g_99 = -1;
(p_65 != g_99) || (func_72 ());
}
int main (void)
{
func_58 (-1);
return 0;
}
--
Summary: possible integer codegen bug
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37103
[Bug c/37103] possible integer codegen bug
--- Comment #1 from pinskia at gmail dot com 2008-08-13 05:44 ---
Subject: Re: New: possible integer codegen bug
Note for most targets not printing is correct as char is signed by
default but for most powerpc targets the opposite is true. You should
have explicted included signed for g_99.
Sent from my iPhone
On Aug 12, 2008, at 22:10, regehr at cs dot utah dot edu
[EMAIL PROTECTED]
wrote:
This is an interesting one...
Compiling the code below at all common optimization levels, gcc
r139046
generates code that prints hello, as does 4.3.1. Pre-4.3 versions
of gcc emit
code that prints nothing. I'm pretty sure that the older versions
are correct.
#include stdio.h
int func_72 (void);
int func_72 (void)
{
printf (hello\n);
return 0;
}
void func_58 (unsigned short p_65);
void func_58 (unsigned short p_65)
{
char g_99 = -1;
(p_65 != g_99) || (func_72 ());
}
int main (void)
{
func_58 (-1);
return 0;
}
--
Summary: possible integer codegen bug
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: regehr at cs dot utah dot edu
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37103
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37103
