[Bug middle-end/23599] [4.0 Regression] Flag -fstrict-aliasing corrupts iterators
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-08-28 08:11 --- Works on powerpc-unknown-linux-gnu and i686-pc-linux-gnu with g++-4.0 (GCC) 4.0.2 20050821 (prerelease) (Debian 4.0.1-6). Can you try reproducing with a recent snapshot from the 4.0 branch? This may still be x86_64 specific, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23599
[Bug libstdc++/23081] Finish the implementation of tr1::array
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-28 10:09 --- Subject: Bug 23081 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-28 10:09:09 Modified files: libstdc++-v3 : ChangeLog libstdc++-v3/include/tr1: array Added files: libstdc++-v3/testsuite/tr1/6_containers/array/element_access: back.cc data.cc front.cc libstdc++-v3/testsuite/tr1/6_containers/array/tuple_interface: get.cc tuple_element.cc tuple_size.cc Log message: 2005-08-28 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/23081 * include/tr1/array: Implement members back(), front(), data(), and the tuple interface; tidy. * testsuite/tr1/6_containers/array/element_access/back.cc: New. * testsuite/tr1/6_containers/array/element_access/data.cc: Likewise. * testsuite/tr1/6_containers/array/element_access/front.cc: Likewise. * testsuite/tr1/6_containers/array/tuple_interface/get.cc: Likewise. * testsuite/tr1/6_containers/array/tuple_interface/tuple_element.cc: Likewise. * testsuite/tr1/6_containers/array/tuple_interface/tuple_size.cc: Likewise. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.2917.2.74r2=1.2917.2.75 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/include/tr1/array.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.5r2=1.5.14.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/array/element_access/back.cc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/array/element_access/data.cc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/array/element_access/front.cc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/array/tuple_interface/get.cc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/array/tuple_interface/tuple_element.cc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/testsuite/tr1/6_containers/array/tuple_interface/tuple_size.cc.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=NONEr2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23081
[Bug libstdc++/23081] Finish the implementation of tr1::array
--- Additional Comments From pcarlini at suse dot de 2005-08-28 10:10 --- Fixed for 4.0.2. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23081
[Bug rtl-optimization/23601] New: reload may drop non-call exception information
Seen as an ia64 bootstrap failure as of 20050828 in libjava/java/lang/reflect/natMethod.cc, though the problem could affect any target. The observed problem is that reload chooses a reg/reg alternative for reloading a memory (for unknown reasons). This causes the insn stream to be changed from (set (reg 1) (mem)) // REG_EH_REGION 1 to (set (reg 2) (addr)) (set (reg 1) (mem)) (set (reg 1) (reg 1)) // REG_EH_REGION 1 so that the insn that actually traps no longer contains the REG_EH_REGION note. I figure the note ought to get distributed during emit_reload_insns. -- Summary: reload may drop non-call exception information Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code, ice-on-valid-code Severity: normal Priority: P2 Component: rtl-optimization AssignedTo: rth at gcc dot gnu dot org ReportedBy: rth at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23601
[Bug ada/23593] [4.0/4.1 Regression] 5 ACATS compiler SEGV c371002 c371003 c52008b cc51004 cc51b03
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-28 11:01 --- Subject: Bug 23593 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-28 11:01:32 Modified files: gcc: ChangeLog builtins.c Log message: PR ada/23593 * builtins.c (get_memory_rtx): Don't strip nops in between COMPONENT_REFs. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9841r2=2.9842 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/builtins.c.diff?cvsroot=gccr1=1.473r2=1.474 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23593
[Bug libfortran/23598] iostat handling after library error return
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org URL||http://gcc.gnu.org/ml/fortra ||n/2005-08/msg00467.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Keywords||patch Last reconfirmed|-00-00 00:00:00 |2005-08-28 11:05:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23598
[Bug ada/23593] [4.0/4.1 Regression] 5 ACATS compiler SEGV c371002 c371003 c52008b cc51004 cc51b03
--- Additional Comments From laurent at guerby dot net 2005-08-28 11:05 --- Thanks for fixing this. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23593
[Bug ada/23593] [4.0/4.1 Regression] 5 ACATS compiler SEGV c371002 c371003 c52008b cc51004 cc51b03
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-28 11:09 --- Subject: Bug 23593 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-28 11:08:57 Modified files: gcc: ChangeLog builtins.c Log message: PR ada/23593 * builtins.c (get_memory_rtx): Don't strip nops in between COMPONENT_REFs. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.397r2=2.7592.2.398 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/builtins.c.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.426.2.4r2=1.426.2.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23593
[Bug rtl-optimization/23601] reload may drop non-call exception information
-- What|Removed |Added Keywords||EH http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23601
[Bug ada/23593] [4.0/4.1 Regression] 5 ACATS compiler SEGV c371002 c371003 c52008b cc51004 cc51b03
-- What|Removed |Added Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23593
[Bug tree-optimization/23350] [4.1 Regression] ICE in vect_update_ivs_after_vectorizer, at tree-vect-transform.c:2418
--- Additional Comments From dorit at il dot ibm dot com 2005-08-28 13:47
---
The patch below fixes the problem.
We fail on this assert:
gcc_assert (evolution_part != NULL_TREE);
in 'vect_update_ivs_after_vectorizer'.
This happens because we assume that 'vect_update_ivs_after_vectorizer' is
called only if 'vect_can_advance_ivs_p' passes
successfully. 'vect_can_advance_ivs_p' is supposed to be called during the
analysis phase if we suspect that loop peeling will be required. Currently we
only call it when we discover that peeling-for-loop-bound will be required, but
we should also call it if peeling-for-alignment is required (cause usually it
also involves peeling-for-loop-bound). The patch below adds the missing check.
This bit is actually included in Keith's versioning-for-alignment patch
(http://gcc.gnu.org/ml/gcc-patches/2005-08/msg01372.html), which hopefully is
going to be approved soon (I'd rather wait for that, than create a conflict for
Keith's patch).
Even when this ICE is solved, this is not the end of the story, because this
loop should get vectorized, and we are going to fail because of an invariant
phi (phi with evolution NULL, that we don't know how to handle). This goes back
to http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00905.html. Hopefully
Ira/Sebastian have a solution to resolve this.
Below is the loop from the testcase;
This:
D.2219_59 = PHI D.2248_8(3), D.2248_8(1)
is the invariant phi:
# BLOCK 2 freq:1
# PRED: 3 [100.0%] (fallthru,exec) 1 [100.0%] (fallthru,exec)
# ivtmp.36D.2301_17 = PHI ivtmp.36D.2301_18(3), 32(1);
# TMT.9D.2268_2 = PHI TMT.9D.2268_27(3), TMT.9D.2268_45(1);
# D.2219_59 = PHI D.2248_8(3), D.2248_8(1);
# __iD.2254_58 = PHI __iD.2254_24(3), 0(1);
L3:;
# TMT.9D.2268_27 = V_MAY_DEF TMT.9D.2268_2;
thisD.2217_6-master_handle_set_D.2206.mask_D.2146.fds_bitsD.2134
[__iD.2254_58] = 0;
__iD.2254_24 = __iD.2254_58 + 1;
ivtmp.36D.2301_18 = ivtmp.36D.2301_17 - 1;
if (ivtmp.36D.2301_18 != 0) goto L11; else goto L12;
# SUCC: 3 [96.9%] (dfs_back,true,exec) 4 [3.1%]
(dfs_back,loop_exit,false,exec)
# BLOCK 3 freq:9687
# PRED: 2 [96.9%] (dfs_back,true,exec)
L11:;
goto bb 2 (L3);
# SUCC: 2 [100.0%] (fallthru,exec)
Patch:
Index: tree-vect-analyze.c
===
RCS file: /cvs/gcc/gcc/gcc/tree-vect-analyze.c,v
retrieving revision 2.35
diff -c -3 -p -r2.35 tree-vect-analyze.c
*** tree-vect-analyze.c 13 Aug 2005 17:28:41 - 2.35
--- tree-vect-analyze.c 28 Aug 2005 13:26:31 -
*** vect_enhance_data_refs_alignment (loop_v
*** 955,960
--- 955,965
TODO: - consider accesses that are known to have the same
alignment, even if that alignment is unknown. */
+ /* Often peeling for alignment will require peeling for loop-bound, which in
+ turn requires that we know how to adjust the loop ivs after the loop. */
+ if (!vect_can_advance_ivs_p (loop_vinfo))
+LOOP_PEELING_FOR_ALIGNMENT (loop_vinfo) = 0;
+
if (LOOP_PEELING_FOR_ALIGNMENT (loop_vinfo))
{
int mis;
--
What|Removed |Added
CC||sebastian dot pop at cri dot
||ensmp dot fr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23350
[Bug libgcj/23508] FAIL: PR218
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-28 15:14 --- Subject: Bug 23508 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-08-28 15:14:14 Modified files: gcc: ChangeLog gcc/config/pa : linux-unwind.h Log message: PR libgcj/23508 * pa/linux-unwind.h (pa32_fallback_frame_state): Use r0 slot in frame state for return address column of signal frames. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=2.7592.2.398r2=2.7592.2.399 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/pa/linux-unwind.h.diff?cvsroot=gcconly_with_tag=gcc-4_0-branchr1=1.3r2=1.3.8.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23508
[Bug libgcj/23508] FAIL: PR218
--- Additional Comments From danglin at gcc dot gnu dot org 2005-08-28 15:21 --- Fixed in 4.0 and mainline. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23508
[Bug target/23508] FAIL: PR218
-- What|Removed |Added Component|libgcj |target Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23508
[Bug target/23602] New: [4.1 regression] 1081 test failures in libjava, when configured for i486-linux
configuring HEAD 20050828 for i486-linux (instead of the default i686-linux), libjava fails with 1081 test failures (instead of two with i686-linux). apparently all the execution tests fail. I don't see any additional information from the test log (attached). Compiling the a testcase by hand, and running it, succeeds. Environment is current Debian unstable, binutils 2.16.1, glibc-2.3.5. Matthias Running /home/packages/gcc/snap/tst/gcc-20050828/libjava/testsuite/libjava.lang/lang.exp ... FAIL: ArrayStore execution - source compiled test FAIL: ArrayStore execution - gij test FAIL: ArrayStore execution - bytecode-native test FAIL: ArrayStore -O3 execution - source compiled test FAIL: ArrayStore execution - gij test FAIL: ArrayStore -O3 execution - bytecode-native test FAIL: ArrayStore2 execution - source compiled test FAIL: ArrayStore2 execution - gij test FAIL: ArrayStore2 execution - bytecode-native test FAIL: ArrayStore2 -O3 execution - source compiled test FAIL: ArrayStore2 execution - gij test FAIL: ArrayStore2 -O3 execution - bytecode-native test [...] FAIL: utilTest execution - source compiled test FAIL: utilTest execution - gij test FAIL: utilTest execution - bytecode-native test FAIL: utilTest -O3 execution - source compiled test FAIL: utilTest execution - gij test FAIL: utilTest -O3 execution - bytecode-native test FAIL: verify execution - source compiled test FAIL: verify execution - gij test FAIL: verify execution - bytecode-native test FAIL: verify -O3 execution - source compiled test FAIL: verify execution - gij test FAIL: verify -O3 execution - bytecode-native test Running /home/packages/gcc/snap/tst/gcc-20050828/libjava/testsuite/libjava.loader/loader.exp ... FAIL: /home/packages/gcc/snap/tst/build486/i486-linux-gnu/libjava/testsuite/TestEarlyGC.exe execution - /home/packages/gcc/snap/tst/build486/i486-linux-gnu/libjava/testsuite/TestEarlyGC.exe FAIL: /home/packages/gcc/snap/tst/build486/i486-linux-gnu/libjava/testsuite/TestLeak.exe execution - /home/packages/gcc/snap/tst/build486/i486-linux-gnu/libjava/testsuite/TestLeak.exe FAIL: /home/packages/gcc/snap/tst/build486/i486-linux-gnu/libjava/testsuite/TestMultiple.exe execution - /home/packages/gcc/snap/tst/build486/i486-linux-gnu/libjava/testsuite/TestMultiple.exe FAIL: /home/packages/gcc/snap/tst/build486/i486-linux-gnu/libjava/testsuite/TestParent.exe execution - /home/packages/gcc/snap/tst/build486/i486-linux-gnu/libjava/testsuite/TestParent.exe Running /home/packages/gcc/snap/tst/gcc-20050828/libjava/testsuite/libjava.mauve/mauve.exp ... Running /home/packages/gcc/snap/tst/gcc-20050828/libjava/testsuite/libjava.special/special.exp ... FAIL: pr21115 run Running /home/packages/gcc/snap/tst/gcc-20050828/libjava/testsuite/libjava.verify/verify.exp ... === libjava Summary === # of expected passes1783 # of unexpected failures1081 # of expected failures 4 # of untested testcases 1089 make[2]: *** [check-DEJAGNU] Error 1 make[2]: Leaving directory `/home/packages/gcc/snap/tst/build486/i486-linux-gnu/libjava/testsuite' make[1]: *** [check-am] Error 2 -- Summary: [4.1 regression] 1081 test failures in libjava, when configured for i486-linux Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: critical Priority: P2 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: debian-gcc at lists dot debian dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: i486-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23602
[Bug target/23602] [4.1 regression] 1081 test failures in libjava, when configured for i486-linux
--- Additional Comments From debian-gcc at lists dot debian dot org 2005-08-28 16:41 --- Created an attachment (id=9602) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9602action=view) test log -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23602
[Bug tree-optimization/23603] New: VRP does not say range for a in a = b == c; is [0,1]
Example:
int f(int i)
{
int t = i == 1;
int g = t == 2;
int h = g == 3;
return h;
}
We should convert this to return 0 on the tree level but currently we get:
return i == 1 == 2 == 3;
in final_cleanup
--
Summary: VRP does not say range for a in a = b == c; is [0,1]
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23603
[Bug tree-optimization/23603] VRP does not say range for a in a = b == c; is [0,1]
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28 17:22 --- The fix would be instead of setting the range to varrying in extract_range_from_comparison, set it to [0,1]. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23603
[Bug tree-optimization/23603] VRP does not say range for a in a = b == c; is [0,1]
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28 17:25 --- I have a fix. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-28 17:25:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23603
[Bug c++/23099] [4.0/4.1 regression] ICE in build_simple_base_path, at cp/class.c:460
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23099
[Bug c++/23099] [4.0/4.1 regression] ICE in build_simple_base_path, at cp/class.c:460
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-08-28 18:11 --- The fundamental problem here is that G++ is not honoring [temp.inst], which requires that: in particular, the initialization (and any associated side-effects) of a static data member does not occur unless the static data member is itself used in a way that requires the definition of the static data member to exist. It is instead performing the initialization immediately when instantiating ADerived*. I am looking into the issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23099
[Bug tree-optimization/23603] VRP does not say range for a in a = b == c; is [0,1]
-- What|Removed |Added BugsThisDependsOn||23604 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23603
[Bug tree-optimization/23604] New: [4.1 Regression] wrong code due to VRP
The following should not abort but does at -O2.
int g(int i, int j)
{
if (i-1)
if (i2)
{
if (i != j)
{
if (j != 0)
return 0;
}
}
return 1;
}
int main(void)
{
if (!g(1, 0))
abort ();
return 0;
}
---
I found this while working on PR 23603.
--
Summary: [4.1 Regression] wrong code due to VRP
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P2
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
OtherBugsDependingO 23603
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23604
[Bug tree-optimization/23604] [4.1 Regression] wrong code due to VRP
-- What|Removed |Added CC||phython at gcc dot gnu dot ||org, dnovillo at gcc dot gnu ||dot org Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23604
[Bug tree-optimization/16157] gcc fails to optimize redundant expression (reassocation)
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-28 19:59 --- I have a patch for this -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-03-23 02:58:54 |2005-08-28 19:59:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16157
[Bug tree-optimization/15878] a b ~a ~b not optimized at the tree level
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-28 20:00 --- I have a patch for this -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dberlin at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-05-01 16:29:30 |2005-08-28 20:00:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15878
[Bug c/23605] New: memset() Optimization on x86-32 bit
I have a bit of a disagreement with the optimization toward memset() calls. In one of my libraries, libteklti, I have a function named ucharempty(), which frees a uchar_t (unique character structure) from memory. If the user elects to have the memory erased prior to calling free(), memset() is supposed to reset the memory about to be freed. In gcc 4.0.1, I have noticed that the optimization for memset() calls has a few extra instructions in the generated assembly that do not need to be inserted. Per Ian Lance Taylor's request, I am going to attatch to this bug only the source code and .i files as a tarball. If you look closely, you can see that %edi can be automatically loaded directly without problems, and that (%eax) can be directly loaded into (%esp). The following disassembly output is an example for the line: 0x08049172 ucharempty+53: mov0x8(%ebp),%eax 0x08049175 ucharempty+56: mov0x4(%eax),%edx 0x08049178 ucharempty+59: mov0x8(%ebp),%eax 0x0804917b ucharempty+62: mov(%eax),%ebx 0x0804917d ucharempty+64: mov%ebx,%edi 0x0804917f ucharempty+66: cld 0x08049180 ucharempty+67: mov%edx,%ecx 0x08049182 ucharempty+69: mov$0x0,%al 0x08049184 ucharempty+71: repz stos %al,%es:(%edi) 0x08049186 ucharempty+73: mov%ebx,%eax 0x08049188 ucharempty+75: mov%eax,(%esp) 0x0804918b ucharempty+78: call 0x8048c08 free associated C code: #ifdefTEKLTI_ENFORCE_PRIVACY free( memset( uchrtofree-uchar_t_ascii, '\0', sizeof(char) * uchrtofree-uchar_t_asciilen ) ); #else/* not USE_386_ASM_ENFORCE_PRIVACY */ For reference: Dump of assembler code for function ucharempty, for comparison: From uchar.c: 0x0804913d ucharempty+0: push %ebp 0x0804913e ucharempty+1: mov%esp,%ebp 0x08049140 ucharempty+3: push %edi 0x08049141 ucharempty+4: push %ebx 0x08049142 ucharempty+5: sub$0x10,%esp 0x08049145 ucharempty+8: cmpl $0x0,0x8(%ebp) 0x08049149 ucharempty+12: jne0x8049172 ucharempty+53 0x0804914b ucharempty+14: mov0x804c1cc,%eax 0x08049150 ucharempty+19: mov%eax,0xc(%esp) 0x08049154 ucharempty+23: movl $0x35,0x8(%esp) 0x0804915c ucharempty+31: movl $0x1,0x4(%esp) 0x08049164 ucharempty+39: movl $0x804b120,(%esp) 0x0804916b ucharempty+46: call 0x8048c58 free+80 0x08049170 ucharempty+51: jmp0x804919b ucharempty+94 0x08049172 ucharempty+53: mov0x8(%ebp),%eax 0x08049175 ucharempty+56: mov0x4(%eax),%edx 0x08049178 ucharempty+59: mov0x8(%ebp),%eax 0x0804917b ucharempty+62: mov(%eax),%ebx 0x0804917d ucharempty+64: mov%ebx,%edi 0x0804917f ucharempty+66: cld 0x08049180 ucharempty+67: mov%edx,%ecx 0x08049182 ucharempty+69: mov$0x0,%al 0x08049184 ucharempty+71: repz stos %al,%es:(%edi) 0x08049186 ucharempty+73: mov%ebx,%eax 0x08049188 ucharempty+75: mov%eax,(%esp) 0x0804918b ucharempty+78: call 0x8048c08 free 0x08049190 ucharempty+83: mov0x8(%ebp),%eax 0x08049193 ucharempty+86: mov%eax,(%esp) 0x08049196 ucharempty+89: call 0x8048c08 free 0x0804919b ucharempty+94: add$0x10,%esp 0x0804919e ucharempty+97: pop%ebx 0x0804919f ucharempty+98: pop%edi 0x080491a0 ucharempty+99: pop%ebp 0x080491a1 ucharempty+100: ret End of assembler dump. From uchar.386.c: Dump of assembler code for function ucharempty: 0x08048fde ucharempty+0: push %ebp 0x08048fdf ucharempty+1: mov%esp,%ebp 0x08048fe1 ucharempty_passpushpop+0: mov0x8(%ebp),%ecx 0x08048fe4 ucharempty_passpushpop+3: push %edi 0x08048fe5 ucharempty_passpushpop+4: mov(%ecx),%edi 0x08048fe7 ucharempty_passpushpop+6: push %edi 0x08048fe8 ucharempty_passpushpop+7: mov0x4(%ecx),%ecx 0x08048feb ucharempty_passpushpop+10: mov$0x0,%al 0x08048fed ucharempty_passpushpop+12: repz stos %al,%es:(%edi) 0x08048fef ucharempty_passpushpop+14: call 0x8048be0 free 0x08048ff4 ucharempty_passpushpop+19: pop%edi 0x08048ff5 ucharempty_passpushpop+20: pop%edi 0x08048ff6 ucharempty_passpushpop+21: mov%ebp,%esp 0x08048ff8 ucharempty_passpushpop+23: pop%ebp 0x08048ff9 ucharempty_passpushpop+24: jmp0x8048be0 free End of assembler dump. -- Summary: memset() Optimization on x86-32 bit Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: minor Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: kevin at planetsaphire dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: -g -O0 GCC host triplet: Kernel 2.6.12 GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
[Bug target/23605] memset() Optimization on x86-32 bit
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28 20:08 --- Are you compiling your source at -O0 or GCC at -O0? If the former, then this is most likely not a bug. -- What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
[Bug tree-optimization/23604] [4.1 Regression] wrong code due to VRP
--- Additional Comments From phython at gcc dot gnu dot org 2005-08-28 20:16 --- Created an attachment (id=9603) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9603action=view) initial patch (untested) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23604
[Bug tree-optimization/23604] [4.1 Regression] wrong code due to VRP
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-28 20:16:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23604
[Bug target/23605] memset() Optimization on x86-32 bit
--- Additional Comments From kevin at planetsaphire dot com 2005-08-28 20:18 --- Created an attachment (id=9604) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9604action=view) Testcases and .i Files of uchar.* This attatchment contains only the source files of my project, as well as the .i files of uchar.* -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
[Bug target/23605] memset() Optimization on x86-32 bit
--- Additional Comments From kevin at planetsaphire dot com 2005-08-28 20:26 --- (In reply to comment #1) Are you compiling your source at -O0 or GCC at -O0? If the former, then this is most likely not a bug. -O2 does not do any optimization at all, and -O0 optimizes the code to a certain extent. The testcase I submitted was compiled with the -O0 flag. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
[Bug target/23605] memset() Optimization on x86-32 bit
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28 20:28 --- You are compiling at -O0 so this is not a bug and we don't care that much about code generation at -O0. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
[Bug target/23605] memset() Optimization on x86-32 bit
--- Additional Comments From kevin at planetsaphire dot com 2005-08-28 20:34 --- (In reply to comment #4) You are compiling at -O0 so this is not a bug and we don't care that much about code generation at -O0. So you're invalidating this bug because -O0 optimizes this and -O2 does not? I think this is clearly a bug, and so does Ian Lance Taylor per his e-mail earlier. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
[Bug target/23605] memset() Optimization on x86-32 bit
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28 20:37 --- inlining memset is not an optimization as most OS's memsets are better than the inlined version, using sse registers,etc. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
[Bug target/23602] [4.1 regression] 1081 test failures in libjava, when configured for i486-linux
-- What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23602
[Bug target/23605] memset() Optimization on x86-32 bit
--- Additional Comments From kevin at planetsaphire dot com 2005-08-28 21:58 --- (In reply to comment #6) inlining memset is not an optimization as most OS's memsets are better than the inlined version, using sse registers,etc. I have finished reviewing over the glibc memset.* source files for the 32-bit Intel platforms, simply because every one using Linux is using glibc as the libc. I find that SSE (nor even MMX) is used in the 32-bit implementations of memset. I think it is best to change this bug into an enhancement for the next available GCC branch. The reason for this change is because of a few reasons: 1. Fedora Core 3 (the distro installed on my computer) does not install the i686 binaries of glibc during install; rather, it installs the i386 version. 2. You are right about systems having better memset()s, though considering the widespread use of glibc, most implementations do not utilize SSE, MMX, etc. Maybe the memset() optimization can be turned on by the use of a new flag? After all, the i386 build of glibc does not include the use of instructions that can possibly be used on i686. In addition, there may be a few circumstances where the user may not want to use the i686 build, such as debugging, apps that require the i386 build (perhaps to get around a few glibc bugs), and hardware processor issues with other functions in glibc. I hope the GCC staff and the steering committee reviews over this possible enhancement seriously. The optimization would allow the user to get around slower code in certain situations when it comes to using memset(). -- What|Removed |Added Severity|minor |enhancement Status|RESOLVED|UNCONFIRMED Priority|P2 |P1 Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
[Bug fastjar/13020] zip-style comments
--- Additional Comments From wmahan at gmail dot com 2005-08-28 22:18 --- Hi, I submitted a different patch to the upstream FastJar sources at http://sourceforge.net/tracker/index.php?func=detailaid=1275036group_id=426atid=300426 before I noticed this bug. (It doesn't apply to the gcc tree, but it would be simple to make a patch if desired.) When a zip-style comment is present, the patch by Stephen White searches backwards from the end for the central-header-end section to read the offset of the central header, while my patch parses through the file from the beginning to find the central header. Either approach should fix the problem. My fix might be a little less efficient, but I think Stephen's patch would fail if the comment happens to contain the magic string 0x06054b50. I'm not sure if that ever happens in practice. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13020
[Bug target/23605] memset() Optimization on x86-32 bit
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28 22:21 --- First it is not our bug your distro installs i686 versions, go bug them instead. Second glibc not using SSE is its bug and not ours, report it to them instead. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
[Bug target/23605] memset() Optimization on x86-32 bit
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28 23:00 --- Oh, I forgot to mention if you want to inline all string functions, use -minline-all-stringops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
[Bug middle-end/23606] New: fold does not fold (type)(a == b) into a == b (with type as the type)
I don't have a testcase for this one as convert already does it though with my
tree combiner (or when
TER folds), you can reproduce it with:
int f(int i, int j)
{
_Bool a = i == j;
int t = a;
return t;
}
--
Summary: fold does not fold (type)(a == b) into a == b (with type
as the type)
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P2
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pinskia at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23606
[Bug middle-end/23606] fold does not fold (type)(a == b) into a == b (with type as the type)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28 23:04 --- I have a patch which I will be submitting after I do a bootstrap/test. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pinskia at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-28 23:04:22 date|| Summary|fold does not fold (type)(a |fold does not fold (type)(a |== b) into a == b (with type|== b) into a == b (with type |as the type)|as the type) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23606
[Bug target/23605] memset() Optimization on x86-32 bit
--- Additional Comments From ian at airs dot com 2005-08-28 23:15 --- I didn't realize that this was at -O0. Extra register moves at -O0 are not a bug. -O0 means no optimization. I think it is odd that we open code memset at -O0 but not at -O1. I don't know the rationale behind that. The comment in the code explaining why we don't open code this case by default is: /* In case we don't know anything about the alignment, default to library version, since it is usually equally fast and result in shorter code. But that does not explain why we open code at -O0. I think the open coding at -O0 is most likely a bug, as -O0 code should emphasize debuggability, and open coding prevents the user from setting a breakpoint. As pinskia says, the -minline-all-stringops option forces the call to be opencoded. And I agree with him that the bug report about extra register moves at -O0 is invalid. If you want optimal code, compile with optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
[Bug libgcj/23495] java.lang.String.equals is suboptimal
--- Additional Comments From greenrd at greenrd dot org 2005-08-28 23:25 --- memcmp (which is compiled for i686 in fedora because it is part of glibc) is actually less efficient than the current code on my athlon! I was so surprised, I ran the memcmp benchmark again, and the results differed by no more than +/-2%. Here are the wallclock times in ms, followed by the advantage of block compare over the current code. n is the length of the strings tested. n | Current | block compare | memcmp | Advantage of block compare --- 10 | 10717 | 9236 | 11957 | 16% 30 | 16427 | 14618 | 19884 | 12% 50 | 22181 | 17539 | 27550 | 26% 70 | 28052 | 20978 | 35243 | 34% 90 | 32966 | 24695 | 42815 | 33% 110 | 42975 | 28453 | 55036 | 51% All these tests were done on x86 with the same -O, -g and -f flags as make bootstrap uses by default, using LD_PRELOAD to hot-replace the code, and without the assertion enabled in the benchmark. The advantage of block compare rises to 54% for n=10 and 81% for n=110 if -march=athlon-xp is used (to compile both the original code and my block compare code). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23495
Re: [Bug libgcj/23495] java.lang.String.equals is suboptimal
On Aug 28, 2005, at 7:25 PM, greenrd at greenrd dot org wrote: --- Additional Comments From greenrd at greenrd dot org 2005-08-28 23:25 --- memcmp (which is compiled for i686 in fedora because it is part of glibc) is actually less efficient than the current code on my athlon! I was so surprised, I ran the memcmp benchmark again, and the results differed by no more than +/-2%. Here are the wallclock times in ms, followed by the advantage of block compare over the current code. n is the length of the strings tested. n | Current | block compare | memcmp | Advantage of block compare --- 10 | 10717 | 9236 | 11957 | 16% 30 | 16427 | 14618 | 19884 | 12% 50 | 22181 | 17539 | 27550 | 26% 70 | 28052 | 20978 | 35243 | 34% 90 | 32966 | 24695 | 42815 | 33% 110 | 42975 | 28453 | 55036 | 51% All these tests were done on x86 with the same -O, -g and -f flags as make bootstrap uses by default, using LD_PRELOAD to hot-replace the code, and without the assertion enabled in the benchmark. This seems like something glibc's memcmp should be doing also, could you report a bug to glibc about this comparison? Also glibc's memcmp could be improved by doing 128 byte (SSE2 and altivec) comparison at a time so we get a nice speed up there too. -- Pinski
[Bug libgcj/23495] java.lang.String.equals is suboptimal
--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-28 23:32 --- Subject: Re: java.lang.String.equals is suboptimal On Aug 28, 2005, at 7:25 PM, greenrd at greenrd dot org wrote: --- Additional Comments From greenrd at greenrd dot org 2005-08-28 23:25 --- memcmp (which is compiled for i686 in fedora because it is part of glibc) is actually less efficient than the current code on my athlon! I was so surprised, I ran the memcmp benchmark again, and the results differed by no more than +/-2%. Here are the wallclock times in ms, followed by the advantage of block compare over the current code. n is the length of the strings tested. n | Current | block compare | memcmp | Advantage of block compare --- 10 | 10717 | 9236 | 11957 | 16% 30 | 16427 | 14618 | 19884 | 12% 50 | 22181 | 17539 | 27550 | 26% 70 | 28052 | 20978 | 35243 | 34% 90 | 32966 | 24695 | 42815 | 33% 110 | 42975 | 28453 | 55036 | 51% All these tests were done on x86 with the same -O, -g and -f flags as make bootstrap uses by default, using LD_PRELOAD to hot-replace the code, and without the assertion enabled in the benchmark. This seems like something glibc's memcmp should be doing also, could you report a bug to glibc about this comparison? Also glibc's memcmp could be improved by doing 128 byte (SSE2 and altivec) comparison at a time so we get a nice speed up there too. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23495
[Bug target/23605] memset() Optimization on x86-32 bit
--- Additional Comments From ian at airs dot com 2005-08-28 23:36 --- The generated code for your second test case doesn't look too bad to me. The bulk of the code is checking the alignment of the buffer in order to get an efficient rep; stosl. What would you recommend as faster code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
[Bug middle-end/23606] fold does not fold (type)(a == b) into a == b (with type as the type)
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-28 23:42 --- Note, type and TREE_CODE (op0) are swapped in the patch (as I did not even build the orginal patch). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23606
[Bug middle-end/21180] [4.1 Regression] checking on fold no longer happens in some cases
-- Bug 21180 depends on bug 22455, which changed state. Bug 22455 Summary: [4.1 regression] ICE tree check: expected function_decl, have type_decl in fold_checksum_tree, at fold-const.c:10282 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22455 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21180
[Bug middle-end/20623] ICE: fold check: original tree changed by fold with --enable-checking=fold
-- Bug 20623 depends on bug 22455, which changed state. Bug 22455 Summary: [4.1 regression] ICE tree check: expected function_decl, have type_decl in fold_checksum_tree, at fold-const.c:10282 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22455 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20623
[Bug middle-end/22455] [4.1 regression] ICE tree check: expected function_decl, have type_decl in fold_checksum_tree, at fold-const.c:10282
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-08-29 00:12 --- Fixed -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22455
[Bug middle-end/22455] [4.1 regression] ICE tree check: expected function_decl, have type_decl in fold_checksum_tree, at fold-const.c:10282
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-29 00:12 --- Subject: Bug 22455 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-29 00:12:21 Modified files: gcc: ChangeLog fold-const.c Log message: 2005-08-28 Daniel Berlin [EMAIL PROTECTED] Fix PR middle-end/22455 * fold-const.c (fold_checksum_tree): Adjust for now-largest tree size. Checksum only the parts of the tree that exist for the tree code. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gccr1=2.9845r2=2.9846 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fold-const.c.diff?cvsroot=gccr1=1.623r2=1.624 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22455
[Bug target/23605] memset() Optimization on x86-32 bit
--- Additional Comments From kevin at planetsaphire dot com 2005-08-29 00:16 --- err... I meant get rid of the pushpop instructions for ebx because ebx wouldn't be used (probably taken care of automatically anyway) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
[Bug target/23605] memset() Optimization on x86-32 bit
--- Additional Comments From kevin at planetsaphire dot com 2005-08-29 00:36 --- Also, is setting %eax to $0 once per memset good enough? I don't think the stos instruction would reset %eax... the resulting assembly code in tektester.386.s is the same in -O3 and -O2... -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23605
[Bug tree-optimization/23603] VRP does not say range for a in a = b == c; is [0,1]
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 00:49 --- This really does depend on PR 23604 as it exposes that latent bug while bootstrapping. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23603
[Bug testsuite/23607] New: gcc.target/i386/pr23575.c fails on x86_64
gcc.target/i386/pr23575.c fails with the following message: /home/pinskia/src/onetest/gcc/gcc/testsuite/gcc.target/i386/pr23575.c:1: error: CPU you selected does not support x86-64 instruction set /home/pinskia/src/onetest/gcc/gcc/testsuite/gcc.target/i386/pr23575.c:1: error: CPU you selected does not support x86-64 instruction set -- Summary: gcc.target/i386/pr23575.c fails on x86_64 Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org,rguenth at gcc dot gnu dot org GCC target triplet: x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23607
[Bug c++/23608] New: -Wsign-compare and const propagation
Compiling
#define FIVE 5
int main()
{
int i = 5;
int const ic = 5;
i 5u;
ic 5u;
FIVE 5u; // line 10
}
with -Wsign-compare produces the output
pp.cpp:8: warning: comparison between signed and unsigned integer expressions
pp.cpp:9: warning: comparison between signed and unsigned integer expressions
MSVC only warns on line 8. G++'s current behaviour is unfortunate because it
favors #defines over consts.
Regards,
Bruno MartÃnez
--
Summary: -Wsign-compare and const propagation
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: br1 at internet dot com dot uy
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23608
[Bug c++/23608] -Wsign-compare and const propagation
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 02:34 --- ic by the C++ standard does not need to propagate its value into ic 5u so I think the warning is warranted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23608
[Bug other/23572] No warning for assigning a value to a 'float' variable that overflows with option -Wextra
--- Additional Comments From qiyaoltc at cn dot ibm dot com 2005-08-29
02:57 ---
OK.
GCC version: 3.4.3 20050227 (Red Hat 3.4.3-22.1)
GNU C Library: stable release version 2.3.4
OS : Red Hat Enterprise Linux AS release 4 (Nahant Update 1)
I write a small example named overflow-test.c, here is the source code:
1 #includestdio.h
2 int main()
3 {
4 /* overflow. */
5 float f1 = 3.5E+38;
6 /* underflow. */
7 float f2 = 3.3E-46;
8 /* overflow. */
9 double d1 = 1.9E+308;
10 /* underflow. */
11 double d2 = 1.4E-325;
12 /* overflow, 2**32. */
13 int i = 4294967296;
14
15 printf(%e,%e,%e,%e\n,f1,f2,d1,d2);
16 printf(%d\n,i);
17 return 0;
18 }
And I compile it like this:
[EMAIL PROTECTED] gcc -o overflow-test -Wextra -Wall -g overflow-test.c
overflow-test.c: In function `main':
overflow-test.c:13: warning: integer constant is too large for long type
overflow-test.c:13: warning: overflow in implicit constant conversion
I run it,
[EMAIL PROTECTED] ./overflow-test
inf,0.00e+00,inf,0.00e+00
0
I hope this example would be helpful. Any comments are highly aprreciated!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23572
[Bug other/23572] No warning for assigning a value to a 'float' variable that overflows with option -Wextra
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 03:10 --- I think there are some real interesting issues here. First with -pedantic we get a warning for line 9 but nothing more. If we add f to the end of the constant on line 5, we then get a warning. And yes your example was useful. The interesting thing is that we don't get a warning for the following code: double d1 = 1.9E+308 + 1.; which should warn. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||diagnostic Known to work||2.95.3 3.2.3 3.4.0 4.0.0 ||4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-08-29 03:10:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23572
[Bug testsuite/23609] New: all obj-c++ execute tests fails with the GNU runtime
All obj-c++ execute tests fails with the GNU runtime: Setting LD_LIBRARY_PATH to .:/home/pinskia/src/onetest/gcc/objdir/x86_64-unknown-linux-gnu/./ libstdc++-v3/src/.libs:/home/pinskia/src/onetest/gcc/objdir/gcc:/home/pinskia/src/onetest/gcc/ objdir/gcc:.:/home/pinskia/src/onetest/gcc/objdir/x86_64-unknown-linux-gnu/./libstdc++-v3/src/ .libs:/home/pinskia/src/onetest/gcc/objdir/gcc:/home/pinskia/src/onetest/gcc/objdir/gcc:.:/home/ pinskia/src/onetest/gcc/objdir/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/pinskia/ src/onetest/gcc/objdir/gcc ./basic.exe: error while loading shared libraries: libobjc.so.1: cannot open shared object file: No such file or directory looks for some reason LD_LIBRARY_PATH does not include libobjc for some reason -- Summary: all obj-c++ execute tests fails with the GNU runtime Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23609
[Bug testsuite/23610] New: obj-c++.dg/bitfield-1.mm fails with the GNU runtime
obj-c++.dg/bitfield-1.mm fails by giving these extra warnings: In file included from built-in:0: built-in:0: warning: padding struct to align 'anonymous struct::anonymous' built-in:0: warning: padding struct to align 'anonymous struct::anonymous'/home/pinskia/ src/onetest/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:40: warning: padding struct size to alignment boundary/home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:43: warning: padding struct size to alignment boundary/home/pinskia/src/onetest/gcc/gcc/testsuite/obj- c++.dg/bitfield-1.mm:57: warning: padding struct size to alignment boundary /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:60: warning: padding struct size to alignment boundary /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:75: warning: padding struct size to alignment boundary /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/bitfield-1.mm:76: warning: padding struct size to alignment boundary -- Summary: obj-c++.dg/bitfield-1.mm fails with the GNU runtime Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23610
[Bug testsuite/23610] obj-c++.dg/bitfield-[14].mm fails with the GNU runtime
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 03:37 --- Likewise for obj-c++.dg/bitfield-4.mm: In file included from built-in:0: built-in:0: warning: padding struct to align 'anonymous struct::anonymous' built-in:0: warning: padding struct to align 'anonymous struct::anonymous' /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/bitfield-4.mm:29: warning: padding struct size to alignment boundary /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/bitfield-4.mm:35: warning: padding struct size to alignment boundary -- What|Removed |Added Summary|obj-c++.dg/bitfield-1.mm|obj-c++.dg/bitfield-[14].mm |fails with the GNU runtime |fails with the GNU runtime http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23610
[Bug testsuite/23611] New: obj-c++.dg/encode-4.mm fails with the GNU runtime on linux
obj-c++.dg/encode-4.mm fails with the following error message: /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/encode-4.mm:35: error: declaration of 'int sscanf(const char*, const char*, ...)' throws different exceptions/usr/include/stdio.h:402: error: than previous declaration 'int sscanf(const char*, const char*, ...) throw ()' We should be just including stdio.h instead of declaring sscanf. -- Summary: obj-c++.dg/encode-4.mm fails with the GNU runtime on linux Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23611
[Bug testsuite/23611] obj-c++.dg/encode-[45].mm fails with the GNU runtime on linux
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 03:40 --- Likewise for encode-5.mm: /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/encode-5.mm:17: error: declaration of 'int sscanf(const char*, const char*, ...)' throws different exceptions /usr/include/stdio.h:402: error: than previous declaration 'int sscanf(const char*, const char*, ...) throw ()' -- What|Removed |Added Summary|obj-c++.dg/encode-4.mm fails|obj-c++.dg/encode-[45].mm |with the GNU runtime on |fails with the GNU runtime |linux |on linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23611
[Bug testsuite/23612] New: obj-c++.dg/encode-6.mm fail with the GNU runtime
obj-c++.dg/encode-6.mm fails with: /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/encode-6.mm:57: error: invalid use of undefined type 'struct objc_ivar'/home/pinskia/src/onetest/gcc/gcc/testsuite/../../libobjc/objc/objc- api.h:216: error: forward declaration of 'struct objc_ivar' /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/encode-6.mm:58: error: invalid use of undefined type 'struct objc_ivar' /home/pinskia/src/onetest/gcc/gcc/testsuite/../../libobjc/objc/objc-api.h:216: error: forward declaration of 'struct objc_ivar' /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/encode-6.mm:59: error: cannot increment a pointer to incomplete type 'objc_ivar' /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/encode-6.mm:63: error: cannot convert 'objc_ivar_list::objc_ivar [1]' to 'objc_ivar*' in assignment /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/encode-6.mm:70: error: cannot convert 'objc_ivar_list::objc_ivar [1]' to 'objc_ivar*' in assignment -- Summary: obj-c++.dg/encode-6.mm fail with the GNU runtime Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23612
[Bug testsuite/23613] New: obj-c++.dg/isa-field-1.mm fails with the GNU runtime
obj-c++.dg/isa-field-1.mm fails with: /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/isa-field-1.mm:17: error: 'struct objc_object' has no member named 'isa' /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/isa-field-1.mm:21: error: 'struct objc_object' has no member named 'isa' /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/isa-field-1.mm:30: error: 'struct objc_object' has no member named 'isa' /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/isa-field-1.mm:34: error: 'struct objc_object' has no member named 'isa' /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/isa-field-1.mm:41: error: 'struct objc_object' has no member named 'isa' -- Summary: obj-c++.dg/isa-field-1.mm fails with the GNU runtime Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23613
[Bug testsuite/23610] obj-c++.dg/bitfield-[14].mm, obj-c++.dg/layout-1.mm fails with the GNU runtime
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 03:42 --- obj-c++.dg/layout-1.mm fails the same way: In file included from built-in:0: built-in:0: warning: padding struct to align 'anonymous struct::anonymous' built-in:0: warning: padding struct to align 'anonymous struct::anonymous' -- What|Removed |Added Summary|obj-c++.dg/bitfield-[14].mm |obj-c++.dg/bitfield-[14].mm, |fails with the GNU runtime |obj-c++.dg/layout-1.mm fails ||with the GNU runtime http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23610
[Bug objc++/23614] New: obj-c++.dg/lookup-2.mm fails with the GNU runtime
obj-c++.dg/lookup-2.mm fails with: /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/lookup-2.mm:40: error: cannot convert 'objc_object*' to 'MyWidget*' in initialization -- Summary: obj-c++.dg/lookup-2.mm fails with the GNU runtime Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P2 Component: objc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23614
[Bug testsuite/23615] New: obj-c++.dg/method-19.mm fails with the GNU runtime on linux
obj-c++.dg/method-19.mm fails with: /home/pinskia/src/onetest/gcc/gcc/testsuite/obj-c++.dg/method-19.mm:19: error: declaration of 'int strcmp(const char*, const char*)' throws different exceptions /usr/include/string.h:97: error: than previous declaration 'int strcmp(const char*, const char*) throw ()' We should just include string.h instead of declaring strcmp. -- Summary: obj-c++.dg/method-19.mm fails with the GNU runtime on linux Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org GCC target triplet: x86_64-*-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23615
[Bug objc++/23616] New: obj-c++.dg/try-catch-2.mm (objc exceptions are broken) fails with the GNU Runtime
obj-c++.dg/try-catch-2.mm fails with: /tmp/ccYlrE11.o(.gcc_except_table+0x18): undefined reference to `typeinfo for Frob*' Which means we are trying to use the C++ style exceptions instead of objc exceptions. Though this is harder to fix correctly (I have to look into how the C++ front-end implements java exceptions). -- Summary: obj-c++.dg/try-catch-2.mm (objc exceptions are broken) fails with the GNU Runtime Product: gcc Version: 4.1.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P2 Component: objc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23616
[Bug objc++/23616] obj-c++.dg/try-catch-[29].mm (objc exceptions are broken) fails with the GNU Runtime
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 03:48 --- try-catch-9.mm fails the same way: /tmp/ccgh94EZ.o(.gcc_except_table+0x14): undefined reference to `typeinfo for Object*' -- What|Removed |Added Summary|obj-c++.dg/try-catch-2.mm |obj-c++.dg/try-catch-[29].mm |(objc exceptions are broken)|(objc exceptions are broken) |fails with the GNU Runtime |fails with the GNU Runtime http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23616
[Bug java/23617] New: Out of memory when classpath contains jar file with zip-style comment
When trying to compile a file with Debian's gcj 4.0.1-2, I got an error like this: HelloWorld.java:0: error: malformed .zip archive in CLASSPATH: /usr/lib/j2re1.5-sun/lib/ext/localedata.jar/ jc1: out of memory allocating 1342179073 bytes after a total of 389120 bytes It turns out the .jar file the error mentions has a zipfile comment. (JAR is based on the zip format, which allows an variable-length comment at the end of the file.) The compilation was successful when I removed the jar file from the classpath. Here's a simple test case to summarize: with gcj 4.0.1, the Info-ZIP utility, and any class, say HelloWorld.java: $ jar -cf test.jar; gcj -classpath test.jar HelloWorld.java # works fine $ jar -cf test.jar; echo some comment | zip -z test.jar; gcj -classpath test.jar HelloWorld.java enter new zip file comment (end with .): jc1: out of memory allocating 1663067502 bytes after a total of 135168 bytes This problem is similar to bug 13020 for FastJar. I came up with a similar solution: modifying zextract.c to check for a zipfile comment, and if necessary scan backwards for the end-central-header signature. Unfortunately I haven't had a chance to test the change compiled into gcc, although it appears to work in a small test program. -- Summary: Out of memory when classpath contains jar file with zip- style comment Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wmahan at gmail dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23617
[Bug java/23617] Out of memory when classpath contains jar file with zip-style comment
--- Additional Comments From wmahan at gmail dot com 2005-08-29 04:53 --- Created an attachment (id=9611) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9611action=view) Possible fix for gcc/java/zextract.c against latest CVS -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23617
[Bug fastjar/13020] zip-style comments
-- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-29 04:54:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13020
[Bug testsuite/23607] gcc.target/i386/pr23575.c fails on x86_64
--- Additional Comments From aj at gcc dot gnu dot org 2005-08-29 04:55 --- Taking it. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aj at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-08-29 04:55:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23607
[Bug java/23617] Out of memory when classpath contains jar file with zip-style comment
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 04:56 --- Confirmed, I thought there was already a bug about this (not the fast jar one you pointed out) but looks like there is not. Could you sent your patch to java-patches@ and gcc-patches@ with a changelog and a comment and what this patch does? -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-08-29 04:56:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23617
[Bug other/23572] No warning for assigning a value to a 'float' variable that overflows with option -Wextra
--- Additional Comments From qiyaoltc at cn dot ibm dot com 2005-08-29 05:00 --- I add suffix f to the end of float constants at line 5 and line 7, and add option -pedantic, the output from gcc is like this: overflow-test.c:5: warning: floating constant exceeds range of float overflow-test.c:9: warning: floating constant exceeds range of double overflow-test.c:13: warning: integer constant is too large for long type overflow-test.c:13: warning: overflow in implicit constant conversion It seems that gcc has checked initialization which caused overflow, but do not check underflow, that is to say: 1 GCC does not check underflow event, at least options -pedantic does not enable underflow check. 2 If there is some mechanism in GCC internal to check underflow and overflow, there is a bug in gcc info about the description of -Wextra option. Could you tell me what I could do to this problem? Maybe, it is impossible for me to fix it, but I just want to do something more. Please give me some suggestions and I will try to do it. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23572
[Bug tree-optimization/21636] Missed ccp optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 05:18 --- I am wrong, in saying that if fold does it, we will automatic get the optimization but after fold doing the simplification, I think this turns into the same issue as PR 23588. -- What|Removed |Added BugsThisDependsOn||23588 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21636
Re: [Bug tree-optimization/21636] Missed ccp optimization
On Aug 29, 2005, at 1:18 AM, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 05:18 --- I am wrong, in saying that if fold does it, we will automatic get the optimization but after fold doing the simplification, I think this turns into the same issue as PR 23588. Oh, I have a patch for fold doing this transformation which I am testing. -- Pinski
[Bug tree-optimization/21636] Missed ccp optimization
--- Additional Comments From pinskia at physics dot uc dot edu 2005-08-29 05:19 --- Subject: Re: Missed ccp optimization On Aug 29, 2005, at 1:18 AM, pinskia at gcc dot gnu dot org wrote: --- Additional Comments From pinskia at gcc dot gnu dot org 2005-08-29 05:18 --- I am wrong, in saying that if fold does it, we will automatic get the optimization but after fold doing the simplification, I think this turns into the same issue as PR 23588. Oh, I have a patch for fold doing this transformation which I am testing. -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21636
[Bug testsuite/23607] gcc.target/i386/pr23575.c fails on x86_64
--- Additional Comments From aj at gcc dot gnu dot org 2005-08-29 05:31 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23607
[Bug testsuite/23607] gcc.target/i386/pr23575.c fails on x86_64
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-08-29 05:31 --- Subject: Bug 23607 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-08-29 05:31:49 Modified files: gcc/testsuite : ChangeLog Log message: Add marker for PR testsuite/23607. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gccr1=1.5973r2=1.5974 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23607
