[Bug c/23106] -Wstrict-aliasing=2 doesn't warn for all aliasing problems
--- Additional Comments From fn_x at hotmail dot com 2005-07-28 05:26 --- Consider this reopened as a documentation bug, then, as it is currently clearly documented that the second case will get a warning with -Wstrict-aliasing=2. -- What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23106
[Bug rtl-optimization/23047] Combine ignores flag_wrapv
--- Additional Comments From phython at gcc dot gnu dot org 2005-07-28 04:52 --- Fixed in the commit above. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23047
[Bug libgcj/22084] [4.1 Regression] Divide_1 test case hangs
--- Additional Comments From phython at gcc dot gnu dot org 2005-07-28 04:51 --- Fixing pr 22493 fixed all the Divide_1 problems on ia64. -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22084
[Bug libgcj/22084] [4.1 Regression] Divide_1 test case hangs
-- Bug 22084 depends on bug 22493, which changed state. Bug 22493 Summary: [4.1 Regression] with -fwrapv -INT_MIN is still not positive http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22493 What|Old Value |New Value Status|UNCONFIRMED |NEW Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22084
[Bug tree-optimization/22493] [4.1 Regression] with -fwrapv -INT_MIN is still not positive
--- Additional Comments From phython at gcc dot gnu dot org 2005-07-28 04:45 --- Fixed in the commit above. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22493
[Bug rtl-optimization/23047] Combine ignores flag_wrapv
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-28 04:40 --- Subject: Bug 23047 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-28 04:40:06 Modified files: gcc: ChangeLog simplify-rtx.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: pr23047.c pr23047.x Log message: 2005-07-27 James A. Morrison <[EMAIL PROTECTED]> PR rtl-optimization/23047 * simplify-rtx.c (simplify_const_relational_operation): Respect flag_wrapv for comparisons with ABS. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9576&r2=2.9577 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/simplify-rtx.c.diff?cvsroot=gcc&r1=1.241&r2=1.242 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5833&r2=1.5834 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr23047.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr23047.x.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23047
[Bug tree-optimization/22493] [4.1 Regression] with -fwrapv -INT_MIN is still not positive
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-28 04:35 --- Subject: Bug 22493 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-28 04:35:02 Modified files: gcc: ChangeLog tree-vrp.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.c-torture/execute: pr22493-1.c pr22493-1.x vrp-1.c vrp-2.c vrp-3.c Log message: 2005-07-27 James A. Morrison <[EMAIL PROTECTED]> PR tree-optimization/22493 * tree-vrp.c (extract_range_from_unary_expr): Deal with -fwrapv and VR_ANTI_RANGEs properly for NEGATE_EXPRs and ABS_EXPRs. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9575&r2=2.9576 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-vrp.c.diff?cvsroot=gcc&r1=2.43&r2=2.44 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5832&r2=1.5833 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr22493-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/pr22493-1.x.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/vrp-1.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/vrp-2.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.c-torture/execute/vrp-3.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22493
[Bug c++/22604] [4.0/4.1 Regression] ICE after invalid covariant return
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-28 03:27 --- (In reply to comment #6) > Here's another segfault, originally PalmSource bug 105158, but after Delta > reduction it looked similar: That is a different issue, please file as a seperate bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22604
[Bug c++/22604] [4.0/4.1 Regression] ICE after invalid covariant return
--- Additional Comments From flash at pobox dot com 2005-07-28 03:15
---
Here's another segfault, originally PalmSource bug 105158, but after Delta
reduction it looked similar:
class nameOne : public nameTwo, public nameThree, public nameFour, public
nameFive, public nameSix
{
void nameSeven(const nameEight &name, const nameNine & icon);
virtual void nameSeven(const nameEight& name, const nameTen &icon);
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22604
[Bug driver/20425] -print-search-dirs doesn't honor mutil-os/multilib settings
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-28 02:00 --- *** Bug 23107 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||mike dot patnode at centrify ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20425
[Bug driver/23107] gcc -m64 -print-search-dirs ignores the -m64
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-28 02:00 --- *** This bug has been marked as a duplicate of 20425 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23107
[Bug driver/23107] gcc -m64 -print-search-dirs ignores the -m64
-- What|Removed |Added Component|c |driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23107
[Bug c/23107] New: gcc -m64 -print-search-dirs ignores the -m64
-bash-3.00$ gcc -print-multi-lib .; sparcv9;@m64 -bash-3.00$ gcc -print-libgcc-file-name /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/libgcc.a -bash-3.00$ gcc -m64 -print-libgcc-file-name /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/sparcv9/libgcc.a GOOD! -bash-3.00$ gcc -m64 -print-search-dirs install: /usr/local/lib/gcc-lib/sparc-sun-solaris2.8/3.3.2/ programs: =/usr/local/lib/gcc-lib/sparc-sun- solaris2.8/3.3.2/:/usr/local/lib/gcc-lib/sparc-sun- solaris2.8/3.3.2/:/usr/local/lib/gcc-lib/sparc-sun- solaris2.8/:/usr/lib/gcc/sparc-sun-solaris2.8/3.3.2/:/usr/lib/gcc/sparc-sun- solaris2.8/:/usr/local/lib/gcc-lib/sparc-sun- solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/sparc-sun- solaris2.8/3.3.2/:/usr/local/lib/gcc-lib/sparc-sun- solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/bin/:/usr/ccs/bin/sparc-sun- solaris2.8/3.3.2/:/usr/ccs/bin/ libraries: =/usr/local/lib/gcc-lib/sparc-sun- solaris2.8/3.3.2/:/usr/lib/gcc/sparc-sun-solaris2.8/3.3.2/:/usr/local/lib/gcc- lib/sparc-sun-solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/lib/sparc-sun- solaris2.8/3.3.2/:/usr/local/lib/gcc-lib/sparc-sun- solaris2.8/3.3.2/../../../../sparc-sun-solaris2.8/lib/:/usr/ccs/bin/sparc-sun- solaris2.8/3.3.2/:/usr/ccs/bin/:/usr/ccs/lib/sparc-sun- solaris2.8/3.3.2/:/usr/ccs/lib/:/usr/local/lib/gcc-lib/sparc-sun- solaris2.8/3.3.2/../../../sparc-sun-solaris2.8/3.3.2/:/usr/local/lib/gcc- lib/sparc-sun-solaris2.8/3.3.2/../../../:/lib/sparc-sun- solaris2.8/3.3.2/:/lib/:/usr/lib/sparc-sun-solaris2.8/3.3.2/:/usr/lib/ BAD! This cascades down to problems with libtool as well. Broken on RedHat gcc 3.4.3 as well -- Summary: gcc -m64 -print-search-dirs ignores the -m64 Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P2 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mike dot patnode at centrify dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23107
[Bug debug/20161] [4.0/4.1 Regression] ICE with dwarf for incomplete element type argument
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-28 01:29 --- Subject: Bug 20161 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-07-28 01:28:59 Modified files: gcc: passes.c ChangeLog Log message: PR debug/20161 * passes.c (rest_of_decl_compilation): If decl is a type and we have encountered errors, don't emit debug information. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/passes.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.72.2.2&r2=2.72.2.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.334&r2=2.7592.2.335 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20161
[Bug debug/20161] [4.0/4.1 Regression] ICE with dwarf for incomplete element type argument
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-28 01:25 --- be fixeth, buglette! -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20161
[Bug debug/20161] [4.0/4.1 Regression] ICE with dwarf for incomplete element type argument
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-28 01:24 --- Subject: Bug 20161 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-28 01:24:20 Modified files: gcc: ChangeLog passes.c Log message: PR debug/20161 * passes.c (rest_of_decl_compilation): If decl is a type and we have encountered errors, don't emit debug information. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9572&r2=2.9573 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/passes.c.diff?cvsroot=gcc&r1=2.105&r2=2.106 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20161
[Bug c/23106] -Wstrict-aliasing=2 doesn't warn for all aliasing problems
--- Additional Comments From fn_x at hotmail dot com 2005-07-28 00:00 --- The bug this is marked a duplicate of is about -Wall, which includes only -Wstrict-aliasing. This bug is about -Wstrict-aliasing=2. It is documented as warning for "all code which might break the strict aliasing rules that the compiler is using for optimization". I certainly agree that it is reasonable not to warn when only -Wstrict-aliasing is given, but if you don't want to warn here either, would it be fair to ask to at least update the documentation? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23106
[Bug c/23106] -Wstrict-aliasing=2 doesn't warn for all aliasing problems
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 23:38 --- there are two different issues here, the second example cannot be warned about, because no warning does no flow control at all and that was a different bug, PR 20689 Since this is a bug about the second issue, this is a dup of bug 20689 which was closed as will not fix. *** This bug has been marked as a duplicate of 20689 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23106
[Bug c/20689] strict aliasing with temporary variable never gives warnings
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 23:39 --- *** Bug 23106 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||fn_x at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20689
[Bug target/17993] Error in dwarf2 debug output of bitfield members
-- Bug 17993 depends on bug 19885, which changed state. Bug 19885 Summary: [4.0/4.1 Regression] avr dwarf-2 support is broken for head 4.0/4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885 What|Old Value |New Value Status|NEW |WAITING Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17993
[Bug target/19087] Overflowed address in dwarf debug line information
-- Bug 19087 depends on bug 19885, which changed state. Bug 19885 Summary: [4.0/4.1 Regression] avr dwarf-2 support is broken for head 4.0/4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885 What|Old Value |New Value Status|NEW |WAITING Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19087
[Bug target/17994] avr-gcc does not output a dwarf2 .debug_frame section
-- Bug 17994 depends on bug 19885, which changed state. Bug 19885 Summary: [4.0/4.1 Regression] avr dwarf-2 support is broken for head 4.0/4.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885 What|Old Value |New Value Status|NEW |WAITING Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17994
[Bug target/19885] [4.0/4.1 Regression] avr dwarf-2 support is broken for head 4.0/4.1
--- Additional Comments From giovannibajo at libero dot it 2005-07-27 23:37 --- Fixed for GCC 4.0.2 and GCC 4.1.0. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Target Milestone|4.1.0 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885
[Bug target/19885] [4.0/4.1 Regression] avr dwarf-2 support is broken for head 4.0/4.1
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-27 23:37 --- Subject: Bug 19885 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-07-27 23:37:13 Modified files: gcc: ChangeLog gcc/config/avr : avr.c Log message: PR target/19885 * config/avr/avr.c (TARGET_ASM_ALIGNED_SI_OP): Add. (TARGET_ASM_UNALIGNED_HI_OP): Add. (TARGET_ASM_UNALIGNED_SI_OP): Add. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.333&r2=2.7592.2.334 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/avr/avr.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.129.6.3&r2=1.129.6.4 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885
[Bug c/23106] New: -Wstrict-aliasing=2 doesn't warn for all aliasing problems
Hi,
This program:
int main() {
int a = 1;
* (short *) (char *) &a = 2;
char *p = (char *) &a;
* (short *) p = 3;
return a;
}
returns 1 when compiled with gcc 4.0.1 (nothing more is necessary than gcc -O2
test.c). However, adding -Wstrict-aliasing=2 does not make any warning for this
show up. This happens with void * as well.
I first asked about the first case on gcc-help, and Ian Lance Taylor followed up
with a patch to show a warning:
http://gcc.gnu.org/ml/gcc-help/2005-07/msg00292.html
For the second case, he asked to open a bug here.
--
Summary: -Wstrict-aliasing=2 doesn't warn for all aliasing
problems
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: fn_x at hotmail dot com
CC: gcc-bugs at gcc dot gnu dot org
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=23106
[Bug c/23104] [4.1 Regression] C does not reject the same function in two different TUs with -combine
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |echristo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23104
[Bug rtl-optimization/23047] Combine ignores flag_wrapv
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 23:09 --- *** Bug 23105 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||danglin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23047
[Bug rtl-optimization/23105] FAIL: gcc.dg/fold-abs-2.c execution test
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 23:09 --- Yes this is a combine issue, see PR 23047 which is the same bug. This is a dup of bug 23047. *** This bug has been marked as a duplicate of 23047 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23105
[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name
--- Additional Comments From ian at airs dot com 2005-07-27 22:55 --- In comment #7 Giovanni was saying that the compiler was generating the wrong string. The correct string is the one in the quote from the C++ ABI. The compiler has now been fixed the generate the correct string. The demangler only handles the correct string. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16240
[Bug c++/16240] [3.4/3.5 ABI Regression] g++ generates incorrect mangled name
--- Additional Comments From uttamp at us dot ibm dot com 2005-07-27 22:48 --- (In reply to comment #7) > Agreed. This is quoted by the C++ ABI: > > void foo(char); // mangled as _Z3fooc > template struct CB; > // CB is mangled as "2CBIL_Z3foocEE" > > Given this: > > void foo(CB*); > > we generate: > > T _Z3fooP2CBILZ3foocEE but c++filt _Z3fooP2CBILZ3foocEE, just returns the same string. But if I add '_' as _Z3fooP2CBIL_Z3foocEE and then do c++filt on that string, returns foo(CB*) as expected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16240
[Bug rtl-optimization/23105] New: FAIL: gcc.dg/fold-abs-2.c execution test
Executing on host: /home/dave/gnu/gcc-4.0/objdir/gcc/xgcc -B/home/dave/gnu/gcc-4
.0/objdir/gcc/ /home/dave/gnu/gcc-4.0/gcc/gcc/testsuite/gcc.dg/fold-abs-2.c -O
1 -fwrapv -fno-show-column -lm -o ./fold-abs-2.exe(timeout = 300)
PASS: gcc.dg/fold-abs-2.c (test for excess errors)
Setting LD_LIBRARY_PATH to :/home/dave/gnu/gcc-4.0/objdir/gcc::/home/dave/gnu/gc
c-4.0/objdir/gcc:/usr/lib/debug
FAIL: gcc.dg/fold-abs-2.c execution test
.globl f
.type f, @function
f:
.PROC
.CALLINFO FRAME=0,NO_CALLS
.ENTRY
bv %r0(%r2)
ldi 1,%r28
.EXIT
.PROCEND
.size f, .-f
So, f always returns 1.
This appears to be a combine bug. We have the following in life:
;; Start of basic block 0, registers live: 3 [%r3] 26 [%r26] 30 [%r30]
(note 9 2 6 0 [bb 0] NOTE_INSN_BASIC_BLOCK)
(insn 6 9 7 0 (set (reg/v:SI 95 [ a ])
(reg:SI 26 %r26 [ a ])) 37 {*pa.md:2291} (nil)
(expr_list:REG_DEAD (reg:SI 26 %r26 [ a ])
(expr_list:REG_EQUIV (mem/i:SI (plus:SI (reg/f:SI 3 %r3)
(const_int -36 [0xffdc])) [0 a+0 S4 A32])
(nil
(note 7 6 11 0 NOTE_INSN_FUNCTION_BEG)
(insn 11 7 12 0 (set (reg:SI 97)
(abs:SI (reg/v:SI 95 [ a ]))) 22 {abssi2} (insn_list:REG_DEP_TRUE 6 (nil
))
(expr_list:REG_DEAD (reg/v:SI 95 [ a ])
(nil)))
(insn 12 11 13 0 (set (reg:SI 99)
(not:SI (reg:SI 97))) 131 {one_cmplsi2} (insn_list:REG_DEP_TRUE 11 (nil)
)
(expr_list:REG_DEAD (reg:SI 97)
(nil)))
(insn 13 12 17 0 (set (reg:SI 98)
(lshiftrt:SI (reg:SI 99)
(const_int 31 [0x1f]))) 178 {lshrsi3} (insn_list:REG_DEP_TRUE 12 (ni
l))
(expr_list:REG_DEAD (reg:SI 99)
(nil)))
(note 17 13 20 0 NOTE_INSN_FUNCTION_END)
(insn 20 17 26 0 (set (reg/i:SI 28 %r28 [ ])
(reg:SI 98)) 37 {*pa.md:2291} (insn_list:REG_DEP_TRUE 13 (nil))
(expr_list:REG_DEAD (reg:SI 98)
(nil)))
(insn 26 20 0 0 (use (reg/i:SI 28 %r28 [ ])) -1 (insn_list:REG_DEP_TRUE
20 (nil))
(nil))
;; End of basic block 0, registers live:
3 [%r3] 28 [%r28] 30 [%r30]
After combine, we have:
;; Start of basic block 0, registers live: 3 [%r3] 30 [%r30]
(note 9 2 6 0 [bb 0] NOTE_INSN_BASIC_BLOCK)
(note 6 9 7 0 NOTE_INSN_DELETED)
(note 7 6 11 0 NOTE_INSN_FUNCTION_BEG)
(note 11 7 12 0 NOTE_INSN_DELETED)
(note 12 11 13 0 NOTE_INSN_DELETED)
(note 13 12 17 0 NOTE_INSN_DELETED)
(note 17 13 20 0 NOTE_INSN_FUNCTION_END)
(insn 20 17 26 0 (set (reg/i:SI 28 %r28 [ ])
(const_int 1 [0x1])) 37 {*pa.md:2291} (nil)
(nil))
(insn 26 20 0 0 (use (reg/i:SI 28 %r28 [ ])) -1 (insn_list:REG_DEP_TRUE
20 (nil))
(nil))
;; End of basic block 0, registers live:
3 [%r3] 28 [%r28] 30 [%r30]
--
Summary: FAIL: gcc.dg/fold-abs-2.c execution test
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: danglin at gcc dot gnu dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: hppa*-*-*
GCC host triplet: hppa*-*-*
GCC target triplet: hppa*-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23105
[Bug middle-end/23090] [4.0/4.1 Regression] gcc.c-torture/execute/20050713-1.c -Os fails
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-27 22:37 --- Optimizing with -O2 does not create a sibcall, but optimizing with -Os (enabling string instructions) does. The patch to detect overlap with the argument area is not recognizing the insn stream with the string instruction as similarly dangerous. One can perform tailcall optimization on this type of function, but one needs to insert a barrier that the argument area is clobbered. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23090
[Bug rtl-optimization/23100] poor code generation for i686
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-07-27 22:33 --- (In reply to comment #3) > Actually am I missing something, I get: > .L8: > popl%ebp > movl$5, %eax > .p2align 4,,4 > ret Is that with -O2 -fno-inline -march=i686 ? I am using: "GCC: (GNU) 4.1.0 20050727 (experimental)" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23100
[Bug target/19885] [4.0/4.1 Regression] avr dwarf-2 support is broken for head 4.0/4.1
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-27 22:29 --- Subject: Bug 19885 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-27 22:29:47 Modified files: gcc: ChangeLog gcc/config/avr : avr.c Log message: PR target/19885 * config/avr/avr.c (TARGET_ASM_ALIGNED_SI_OP): Add. (TARGET_ASM_UNALIGNED_HI_OP): Add. (TARGET_ASM_UNALIGNED_SI_OP): Add. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9570&r2=2.9571 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/avr/avr.c.diff?cvsroot=gcc&r1=1.140&r2=1.141 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885
[Bug target/21981] [4.0 only] __m64 return value should be returned in %mm0
-- What|Removed |Added Summary|__m64 return value should |[4.0 only] __m64 return |be returned in %mm0 |value should be returned in ||%mm0 Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21981
[Bug middle-end/23090] [4.0/4.1 Regression] gcc.c-torture/execute/20050713-1.c -Os fails
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-27 22:22 --- This looks wrong in the initial argument passing RTL. (virtual-incoming-args is r1+24): (insn 13 11 14 1 (set (reg:SI 122) (mem/s:SI (plus:SI (reg/f:SI 114 virtual-incoming-args) (const_int 8 [0x8])) [3 x+8 S4 A32])) -1 (nil) (nil)) (insn 14 13 15 1 (set (mem:SI (plus:SI (reg/f:SI 114 virtual-incoming-args) (const_int 32 [0x20])) [0 S4 A32]) (reg:SI 122)) -1 (nil) (nil)) corresponds to lwz r0,32(r1) stw r0,56(r1) (insn 19 18 20 1 (set (reg:SI 124) (plus:SI (reg/f:SI 114 virtual-incoming-args) (const_int 24 [0x18]))) -1 (nil) (nil)) (insn 20 19 21 1 (parallel [ (set (reg:SI 6 r6) (mem/s:SI (reg:SI 124) [3 z+0 S4 A32])) (set (reg:SI 7 r7) (mem/s:SI (plus:SI (reg:SI 124) (const_int 4 [0x4])) [3 z+4 S4 A32])) (set (reg:SI 8 r8) (mem/s:SI (plus:SI (reg:SI 124) (const_int 8 [0x8])) [3 z+8 S4 A32])) ]) -1 (nil) (nil)) corresponds to addi r2,r1,48 lswi r6,r2,12 Whoops! We just generated RTL that writes a new value to virtual-incoming-args+32 before reading the old value from it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23090
[Bug rtl-optimization/23100] poor code generation for i686
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 22:22 --- Actually am I missing something, I get: .L8: popl%ebp movl$5, %eax .p2align 4,,4 ret -- What|Removed |Added GCC host triplet|i686-pc-linux-gnu | GCC target triplet||i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23100
[Bug target/23102] extra XORs generated on i686
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 22:18 --- Confirmed, this is a i686 only problem as the complex movl are slower and we expand the movl after reload. -- What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|rtl-optimization|target Ever Confirmed||1 GCC host triplet|i686-pc-linux-gnu | GCC target triplet||i686-pc-linux-gnu Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2005-07-27 22:18:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23102
[Bug rtl-optimization/22472] [4.1 regression] testsuite failure gcc.c-torture/compile/930621-1.c -O3 -funroll-loops
--- Additional Comments From danglin at gcc dot gnu dot org 2005-07-27 22:17 --- Fixed on head. Probably, Steve's fix should be backported as the bug is latent in earlier versions. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22472
[Bug rtl-optimization/15023] -frename-registers is buggy and slow
-- Bug 15023 depends on bug 22472, which changed state. Bug 22472 Summary: [4.1 regression] testsuite failure gcc.c-torture/compile/930621-1.c -O3 -funroll-loops http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22472 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15023
[Bug c/23104] [4.1 Regression] C does not reject the same function in two different TUs with -combine
--- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-07-27 22:14 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-27 22:14:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23104
[Bug c/23103] gcc_diag does not work with -combine
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 22:12 --- Note this looks like we are comparing types by == instead of by comptypes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23103
[Bug c/23104] [4.1 Regression] C does not reject the same function in two different TUs with -combine
-- What|Removed |Added OtherBugsDependingO||21975, 22052 nThis|| Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23104
[Bug c/23104] New: [4.1 Regression] C does not reject the same function in two different TUs with -combine
Compile the following sources with -combine:
file1.c
int f(void) {}
end
file2.c
int f(void) {}
end
We used to reject this in 4.0.0.
This was caused by:
2005-06-28 Eric Christopher <[EMAIL PROTECTED]>
PR c/22052
PR c/21975
* c-decl.c (diagnose_mismatched_decls): Define DECL_EXTERN_INLINE.
Use. Fix detection of invalid extern inline redefinition.
--
Summary: [4.1 Regression] C does not reject the same function in
two different TUs with -combine
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: c
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=23104
[Bug middle-end/23090] [4.0/4.1 Regression] gcc.c-torture/execute/20050713-1.c -Os fails
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-27 22:03
---
The testcase passes three structs with three members each for a total of nine
words. AIX, Darwin, and PPC64 Linux pass structs by value in GPRs r3-r10
allowing a maximum of 8 words. The ninth argument is passed on the stack. This
bug appears to be a problem with either argument passing or scheduling.
struct S a = { 3, 4, 5 }, b = { 6, 7, 8 }, c = { 9, 10, 11 };
main() calls baz3 (c, a, b) and the arguments are correct
9, 10, 11, 3, 4, 5, 6, 7 in GPRs and 8 on stack at 56(r1)
baz3 (struct S x, struct S y, struct S z)
{
return foo3 (y, z, x);
}
is compiled as:
addi r2,r1,24
addi r11,r1,36
stswi r3,r2,12 <== store baz3 argument x to r1+24,28,32
addi r2,r1,48 <== address of foo3 second argument
stswi r6,r11,12
lwz r0,32(r1) <== load x.c
stw r9,48(r1)
mr r9,r3
stw r10,52(r1)
stw r0,56(r1) <== store x.c to third argument last member on stack
lwz r10,28(r1)
lswi r3,r11,12
lswi r6,r2,12 <== load foo3 second argument from r2+48,52,56
b _foo3
GCC stores the argument passed on the stack for foo3 before loading the second
argument from the same location.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23090
[Bug c/23103] New: gcc_diag does not work with -combine
Try compiling the following two source with -combine -Wformat and you will end
of with an error
which is wrong:
--- file1.c ---
typedef long long __gcc_host_wide_int__;
typedef struct location_s
{
const char *file;
int line;
} location_t;
union tree_node;
typedef union tree_node *tree;
extern int diag (const char *, ...) __attribute__ ((__format__ (__gcc_diag__,
1, 2))) __attribute__
((__nonnull__));;
void
foo (location_t *loc)
{
diag ("%H", loc);
}
end
file2.c
typedef long long __gcc_host_wide_int__;
typedef struct location_s
{
const char *file;
int line;
} location_t;
union tree_node;
typedef union tree_node *tree;
extern int diag (const char *, ...) __attribute__ ((__format__ (__gcc_diag__,
1, 2))) __attribute__
((__nonnull__));;
void
foo1 (location_t *loc)
{
diag ("%H", loc);
}
end
--
Summary: gcc_diag does not work with -combine
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: diagnostic, build
Severity: normal
Priority: P2
Component: c
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=23103
[Bug rtl-optimization/23102] New: extra XORs generated on i686
Compiling the code below (extracted from xterm-202) with
-fno-inline -O2 -march=i686
typedef unsigned int Cardinal;
typedef unsigned long Pixel;
typedef char *String;
typedef struct {
String resource;
Pixel value;
int mode;
} ColorRes;
typedef struct {
ColorRes Acolors[(256 +4)];
int startHRow, startHCol,
endHRow, endHCol,
startHCoord, endHCoord;
Cardinal selection_count;
} TScreen;
static void
ResetSelectionState(TScreen * screen)
{
screen->selection_count = 0;
screen->startHRow = screen->startHCol = 0;
screen->endHRow = screen->endHCol = 0;
}
void foo (TScreen *scr)
{
ResetSelectionState (scr);
}
generates:
ResetSelectionState:
pushl %ebp
xorl%edx, %edx
movl%esp, %ebp
xorl%ecx, %ecx
popl%ebp
movl%edx, 3144(%eax)
xorl%edx, %edx
movl%ecx, 3124(%eax)
xorl%ecx, %ecx ;; this is not needed, ecx is already 0
movl%edx, 3120(%eax)
xorl%edx, %edx;; so is edx
movl%ecx, 3132(%eax)
movl%edx, 3128(%eax)
ret
when using -march=i386 the code looks better:
ResetSelectionState:
pushl %ebp
movl%esp, %ebp
movl$0, 3144(%eax)
movl$0, 3124(%eax)
movl$0, 3120(%eax)
movl$0, 3132(%eax)
movl$0, 3128(%eax)
leave
ret
--
Summary: extra XORs generated on i686
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23102
[Bug bootstrap/23101] Make Bootstrap fails on AIX 5.2 ML6
--- Additional Comments From elizabeth dot brosch at thomson dot com 2005-07-27 21:51 --- Subject: RE: Make Bootstrap fails on AIX 5.2 ML6 I exported the BOOT_CFLAGS you suggested but it fails on the exact error. Elizabeth Brosch Sr. Systems Engineer Thomson Scientific & Healthcare - System Services Philadelphia, PA 19104 office: (215) 386-0100 x1144 cell: (267) 784-9166 -Original Message- From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 27, 2005 5:44 PM To: Brosch, Liz (TS USA) Subject: [Bug bootstrap/23101] Make Bootstrap fails on AIX 5.2 ML6 --- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 21:43 --- Try the following add BOOT_CFLAGS="-O2 -maix64 -g" and it should work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23101
[Bug bootstrap/23101] Make Bootstrap fails on AIX 5.2 ML6
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 21:43 --- Try the following add BOOT_CFLAGS="-O2 -maix64 -g" and it should work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23101
[Bug c++/21123] [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Additional Comments From danglin at gcc dot gnu dot org 2005-07-27 21:41 --- This bug seems related to PR c++/18793. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug bootstrap/23101] Make Bootstrap fails on AIX 5.2 ML6
--- Additional Comments From elizabeth dot brosch at thomson dot com 2005-07-27 21:32 --- Subject: RE: Make Bootstrap fails on AIX 5.2 ML6 It gets past it. As stated before, I have successfully compiled gcc v 3.3.2 on AIX 5.2 ML3 using the OBJECT_MODE variable. So I can't understand why I can't get this compiled this time! Elizabeth Brosch Sr. Systems Engineer Thomson Scientific & Healthcare - System Services Philadelphia, PA 19104 office: (215) 386-0100 x1144 cell: (267) 784-9166 -Original Message- From: pinskia at gcc dot gnu dot org [mailto:[EMAIL PROTECTED] Sent: Wednesday, July 27, 2005 5:30 PM To: Brosch, Liz (TS USA) Subject: [Bug bootstrap/23101] Make Bootstrap fails on AIX 5.2 ML6 --- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 21:29 --- What happens if you don't set OBJECT_MODE to 64? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23101
[Bug bootstrap/23101] Make Bootstrap fails on AIX 5.2 ML6
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 21:29 --- What happens if you don't set OBJECT_MODE to 64? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23101
[Bug bootstrap/23101] New: Make Bootstrap fails on AIX 5.2 ML6
I am attempting to compile GCC version 3.3.2 on my AIX system. Here is the host config: AIX 5.2 ML 6 powerpc-ibm-aix5.2.0.0 GNU make v 3.80 Native ar and ld (/usr/bin/ar /usr/bin/ld) Using Native C compiler: cc_r - C for AIX Compiler, Version 6 environment variables: OBJECT_MODE=64 CC=cc_r APAR IY53606 installed configure statement: /usr/local/builds/gcc-3.3.2/objdir] ../configure --prefix=/usr/local/gcc- 3.3.2 --enable-threads=aix --disable-nls When running "make bootstrap" it fails with the following: mkdir libgcc/pthread/ppc64 if [ -f stmp-dirs ]; then true; else touch stmp-dirs; fi ./xgcc -B./ -B/usr/local/gcc-3.3.2/powerpc-ibm-aix5.2.0.0/bin/ - isystem /usr/local/gcc-3.3.2/powerpc-ibm-aix5.2.0.0/include - isystem /usr/local/gcc-3.3.2/powerpc-ibm-aix5.2.0.0/sys-include -O2 - DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes - isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 - D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/config - I../../gcc/../include -DL_muldi3 -c ../../gcc/libgcc2.c -o libgcc/./_muldi3.o Assembler: /tmp//ccLHMdWu.s: line 68: 1252-191 Only .llong should be used for relocatable expressions. /tmp//ccLHMdWu.s: line 285: 1252-191 Only .llong should be used for relocatable expressions. /tmp//ccLHMdWu.s: line 446: 1252-191 Only .llong should be used for relocatable expressions. make[3]: *** [libgcc/./_muldi3.o] Error 1 make[3]: Leaving directory `/usr/local/builds/gcc-3.3.2/objdir/gcc' make[2]: *** [stmp-multilib] Error 2 make[2]: Leaving directory `/usr/local/builds/gcc-3.3.2/objdir/gcc' make[1]: *** [stage1_build] Error 2 make[1]: Leaving directory `/usr/local/builds/gcc-3.3.2/objdir/gcc' make: *** [bootstrap] Error 2 I have read a build document (http://gcc.gnu.org/ml/gcc/2003-11/msg01493.html) and searched Google but no luck. I have successfully compiled this exact version on another development server - AIX 5.2 ML3 and I used native C compiler to build it. But I am getting no where with this and need some help. -- Summary: Make Bootstrap fails on AIX 5.2 ML6 Product: gcc Version: 3.3.2 Status: UNCONFIRMED Severity: normal Priority: P2 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: elizabeth dot brosch at thomson dot com CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23101
[Bug rtl-optimization/23100] poor code generation for i686
--- Additional Comments From dann at godzilla dot ics dot uci dot edu 2005-07-27 21:06 --- The problem does not happen for i386: (ie using -fno-inline -O2 -march=i386) CutBuffer: pushl %ebp movl%esp, %ebp subl$9, %eax cmpl$7, %eax ja .L2 jmp *.L11(,%eax,4) .section.rodata .align 4 .align 4 .L11: .long .L3 .long .L4 .long .L5 .long .L6 .long .L7 .long .L8 .long .L9 .long .L10 .text .p2align 2,,3 .L2: movl$-1, %eax leave ret .L3: xorl%eax, %eax leave ret .L10: movl$7, %eax leave ret .L9: movl$6, %eax leave ret .L8: movl$5, %eax leave ret .L7: movl$4, %eax leave ret .L6: movl$3, %eax leave ret [snip] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23100
[Bug c++/22003] [4.1 Regression] -freorder-blocks-and-partition and thunks
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-27 21:05 --- This should now be fixed. Could the reporter check if things work for you now? There may still be the sections issue with -ffunction-sections mentioned in http://gcc.gnu.org/ml/gcc-patches/2005-07/msg01829.html. I'm not sure if I should just close this bug and open a new one (not having a test case, etc.) or just ignore the issue, or leave this bug open until it is clear what the issue really is and what we can do about it... -- What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22003
[Bug c++/22003] [4.1 Regression] -freorder-blocks-and-partition and thunks
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-07-27 21:03 --- Subject: Bug 22003 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-07-27 21:03:01 Modified files: gcc: ChangeLog varasm.c Log message: PR c++/22003 * varasm.c (assemble_start_function): Don't do anything that may require a CFG if the current function is a thunk. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9569&r2=2.9570 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/varasm.c.diff?cvsroot=gcc&r1=1.522&r2=1.523 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22003
[Bug tree-optimization/23086] aliasing information in gcc.dg/tree-ssa/20030807-7.c should be fixed properly
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 20:39 --- I must be missing something ovbious since that did not fix it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23086
[Bug tree-optimization/23086] aliasing information in gcc.dg/tree-ssa/20030807-7.c should be fixed properly
--- Additional Comments From dnovillo at redhat dot com 2005-07-27 20:38 --- Subject: Re: aliasing information in gcc.dg/tree-ssa/20030807-7.c should be fixed properly On Wed, Jul 27, 2005 at 08:34:10PM -, pinskia at gcc dot gnu dot org wrote: > Isn't this a simple fix to may_alias_p saying that PARM_DECLs > cannot alias local variables? > It isn't. Only a default_def of a PARM_DECL is guaranteed not to point into any local. may_alias_p is flow-insensitive, so it can only return answers that apply to *all* the SSA names for a DECL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23086
[Bug tree-optimization/23086] aliasing information in gcc.dg/tree-ssa/20030807-7.c should be fixed properly
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 20:34 --- Isn't this a simple fix to may_alias_p saying that PARM_DECLs cannot alias local variables? unless I am missing something obvious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23086
[Bug target/18911] mmix-knuth-mmixware testsuite failure: g++.dg/init/array16.C execution
--- Additional Comments From hp at gcc dot gnu dot org 2005-07-27 20:24 --- Test passed "Tue Jul 26 21:00:09 UTC 2005" Failed again "Wed Jul 27 09:56:50 UTC 2005". This time the host is a x86_64-unknown-linux-gnu; amd64 2GHz, PC3200 DDR. (no use opening a separate PR; same basic problem). Smells like a performance regression. Or some cron jobs got in the way. For the record, "libstdc++.sum 25_algorithms/search_n/iterator.cc" started timing out too. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC host triplet|i686-pc-linux-gnu | Last reconfirmed|-00-00 00:00:00 |2005-07-27 20:24:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18911
[Bug c++/21123] [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-07-27 20:17 ---
Subject: Re: [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
> Thus, it looks as if the ICE is caused by a
> tree check failure in the assert at cp/cp-objcp-common.c:101, rather
> than the assert itself.
Actually, it's the enabling of assert checking that catches this
problem.
The problem can be duplicated with an x86 cross to hppa-unknown-linux-gnu.
Here is some debug output:
Breakpoint 1, fancy_abort (
file=0x84d9e38 "../../gcc/gcc/cp/cp-objcp-common.c", line=101,
function=0x84d9de5 "cp_expr_size") at ../../gcc/gcc/diagnostic.c:590
590 internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) bt
#0 fancy_abort (file=0x84d9e38 "../../gcc/gcc/cp/cp-objcp-common.c",
line=101, function=0x84d9de5 "cp_expr_size")
at ../../gcc/gcc/diagnostic.c:590
During symbol reading, Incomplete CFI data; unspecified registers at 0x0826776d.
During symbol reading, Incomplete CFI data; unspecified registers at 0x0826776d.
During symbol reading, Incomplete CFI data; unspecified registers at 0x0826776d.
During symbol reading, Incomplete CFI data; unspecified registers at 0x0826776d.
During symbol reading, Incomplete CFI data; unspecified registers at 0x0826776d.
During symbol reading, Incomplete CFI data; unspecified registers at 0x0826776d.
During symbol reading, Incomplete CFI data; unspecified registers at 0x0826776d.
#1 0x0812c516 in cp_expr_size (exp=0x4021f820)
at ../../gcc/gcc/cp/cp-objcp-common.c:85
During symbol reading, Incomplete CFI data; unspecified registers at 0x0812c584.
During symbol reading, Incomplete CFI data; unspecified registers at 0x0812c584.
During symbol reading, Incomplete CFI data; unspecified registers at 0x0812c584.
During symbol reading, Incomplete CFI data; unspecified registers at 0x0812c584.
During symbol reading, Incomplete CFI data; unspecified registers at 0x0812c584.
During symbol reading, Incomplete CFI data; unspecified registers at 0x0812c584.
#2 0x082907f2 in expr_size (exp=0x4021f820) at ../../gcc/gcc/explow.c:246
During symbol reading, Incomplete CFI data; unspecified registers at 0x08290840.
During symbol reading, Incomplete CFI data; unspecified registers at 0x08290840.
During symbol reading, Incomplete CFI data; unspecified registers at 0x08290840.
During symbol reading, Incomplete CFI data; unspecified registers at 0x08290840.
During symbol reading, Incomplete CFI data; unspecified registers at 0x08290840.
During symbol reading, Incomplete CFI data; unspecified registers at 0x08290840.
#3 0x082a4c7a in store_expr (exp=0x4021f820, target=0x40223fc0,
call_param_p=0) at ../../gcc/gcc/expr.c:4267
During symbol reading, Incomplete CFI data; unspecified registers at 0x082a4d74.
#4 0x082a44e9 in expand_assignment (to=0x4022b9c0, from=0x4021f820)
at ../../gcc/gcc/expr.c:4099
#5 0x082b4017 in expand_expr_real_1 (exp=0x4022d240, target=0x0,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../gcc/gcc/expr.c:8279
#6 0x082aa838 in expand_expr_real (exp=0x4022d240, target=0x4014f210,
tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0)
at ../../gcc/gcc/expr.c:6456
#7 0x0838a099 in expand_expr_stmt (exp=0x4022d240) at expr.h:492
#8 0x083c97ac in expand_gimple_basic_block (bb=0x40226e10, dump_file=0x0)
at ../../gcc/gcc/cfgexpand.c:1326
#9 0x083c9ef4 in tree_expand_cfg () at ../../gcc/gcc/cfgexpand.c:1521
#10 0x083c6206 in execute_one_pass (pass=0x8559fe0)
at ../../gcc/gcc/passes.c:790
#11 0x083c62af in execute_pass_list (pass=0x8559fe0)
---Type to continue, or q to quit---
at ../../gcc/gcc/passes.c:822
#12 0x0818ea05 in tree_rest_of_compilation (fndecl=0x401f0d80)
at ../../gcc/gcc/tree-optimize.c:419
#13 0x0811469d in expand_body (fn=0x401f0d80)
at ../../gcc/gcc/cp/semantics.c:3008
#14 0x081060ab in use_thunk (thunk_fndecl=0x401f0d80, emit_p=1 '\001')
at ../../gcc/gcc/cp/method.c:520
#15 0x081144ec in emit_associated_thunks (fn=0x4021f820)
at ../../gcc/gcc/cp/semantics.c:2961
#16 0x08114671 in expand_body (fn=0x401d0280)
at ../../gcc/gcc/cp/semantics.c:3001
#17 0x083f7579 in cgraph_expand_function (node=0x402032d8)
at ../../gcc/gcc/cgraphunit.c:1033
#18 0x083f7707 in cgraph_expand_all_functions ()
at ../../gcc/gcc/cgraphunit.c:1099
#19 0x083f7c0e in cgraph_optimize () at ../../gcc/gcc/cgraphunit.c:1256
#20 0x080c2ced in cp_finish_file () at ../../gcc/gcc/cp/decl2.c:3094
#21 0x08049afa in finish_file () at ../../gcc/gcc/cp/cp-lang.c:149
#22 0x08166cb8 in c_common_parse_file (set_yydebug=1075792704)
at ../../gcc/gcc/c-opts.c:1117
#23 0x08396cfe in compile_file () at ../../gcc/gcc/toplev.c:971
#24 0x0839813f in do_compile () at ../../gcc/gcc/toplev.c:1937
#25 0x08398197 in toplev_main (argc=10, argv=0xb484)
at ../../gcc/gcc/toplev.c:1969
#26 0x0816fec3 in main (argc=10, argv=0xb484) at ../../gcc/gcc/main.c:35
(gdb) frame 1
#1 0x
[Bug c/23087] Misleading warning, "... differ in signedness"
--- Additional Comments From kst at mib dot org 2005-07-27 19:34 --- I misused the term "compatible" above (and I think the standard itself is sometimes a bit loose about the term). All references are to the C99 standard. I think the C90 rules are the same or very similar. 6.7.8p11: The initializer for a scalar shall be a single expression, optionally enclosed in braces. The initial value of the object is that of the expression (after conversion); the same type constraints and conversions as for simple assignment apply, taking the type of the scalar to be the unqualified version of its declared type. 6.5.16.1p1 (Simple assignment): One of the following shall hold: [...] -- both operands are pointers to qualified or unqualified versions of compatible types, and the type pointed to by the left has all the qualifiers of the type pointed to by the right; 6.7.5.1p2: For two pointer types to be compatible, both shall be identically qualified and both shall be pointers to compatible types. 6.2.5p14: The type char, the signed and unsigned integer types, and the floating types are collectively called the basic types. Even if the implementation defines two or more basic types to have the same representation, they are nevertheless different types. (34) 6.2.5p15: The three types char, signed char, and unsigned char are collectively called the _character types_. The implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char. (35) Footnote 35: CHAR_MIN, defined in , will have one of the values 0 or SCHAR_MIN, and this can be used to distinguish the two options. Irrespective of the choice made, char is a separate type from the other two and is not compatible with either. For an initialization of a char object, there's an implicit conversion, even though types char and signed char are not compatible. signed char sc = 'x'; char c = sc; /* implicit conversion */ There is no implicit conversion for pointer types other than void*: signed char *psc = ≻ char *pc = psc; /* illegal, incompatible types */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23087
[Bug target/23095] [4.1 Regression] ICE in regstack compensate_edge
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-27 19:32 --- Actually the problem existed before that patch. And so, the search continues... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23095
[Bug rtl-optimization/23098] [3.4/4.0/4.1 Regression] store of 0.0 to float
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
19:30 ---
(In reply to comment #4)
> Another testcase for x86 for -fPIC vs -fno-PIC:
double f(float);
double g(void)
{
return f(1.0);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23098
[Bug rtl-optimization/23098] [3.4/4.0/4.1 Regression] store of 0.0 to float
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
19:29 ---
Another testcase for x86 for -fPIC vs -fno-PIC:
double f(float);
double g(void)
{
return f(0.0);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23098
[Bug target/23095] [4.1 Regression] ICE in regstack compensate_edge
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-27
19:21 ---
I'm not sure why reg-stack wants to insert compensation code at all. The
reg-stack dump shows that st(0) is live-at-end in the source block of the
edge, but not live-at-start for the target block:
Analyzing compilation unitPerforming intraprocedural optimizations
Assembling functions:
foo
Breakpoint 1, fancy_abort (file=0xb92af8 "../../mainline/gcc/reg-stack.c",
line=2686,
function=0xb93230 "compensate_edge") at diagnostic.c:590
590 internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) up
#1 0x0081098f in compensate_edge (e=0x2a95a6ef80, file=0xe3f6e0) at
reg-stack.c:2686
2686 gcc_assert (! (e->flags & EDGE_ABNORMAL));
(gdb) p debug_bb (e->src)
;; basic block 12, loop depth 1, count 0
;; prev block 11, next block 13
;; pred: 11 [100.0%] (fallthru,dfs_back,can_fallthru) 7 [19.0%]
(dfs_back,can_fallthru,irreducible) 6 [19.0%]
(dfs_back,can_fallthru,irreducible) 3 [35.4%] (can_fallthru)
;; succ: 6 [25.0%] (ab,irreducible) 14 [25.0%] (ab,irreducible) 13
[25.0%] (ab,irreducible) 5 [25.0%] (ab,irreducible)
;; Registers live at start: 1 [dx] 3 [bx] 4 [si] 5 [di] 6 [bp] 7 [sp] 20
[frame]
(code_label:HI 29 126 30 12 9 "" [3 uses])
(note:HI 30 29 125 12 [bb 12] NOTE_INSN_BASIC_BLOCK)
(insn:TI 125 30 139 12 (set (reg:DF 8 st)
(mem/i:DF (plus:SI (reg/f:SI 6 bp)
(const_int -32 [0xffe0])) [4 absx+0 S8 A32])) 93
{*movdf_nointeger} (nil)
(nil))
(insn:TI 139 125 31 12 (set (mem:DF (plus:SI (reg/f:SI 6 bp)
(const_int -40 [0xffd8])) [11 S8 A8])
(reg:DF 8 st)) 93 {*movdf_nointeger} (insn_list:REG_DEP_TRUE 125
(nil))
(nil))
(jump_insn:TI 31 139 32 12 (set (pc)
(reg/f:SI 1 dx [orig:59 gotovar.36 ] [59])) 525 {*indirect_jump}
(insn_list:REG_DEP_ANTI 125 (insn_list:REG_DEP_TRUE 139 (nil)))
(expr_list:REG_DEAD (reg/f:SI 1 dx [orig:59 gotovar.36 ] [59])
(nil)))
;; Registers live at end: 3 [bx] 4 [si] 5 [di] 6 [bp] 7 [sp] 8 [st] 20
[frame]
$10 = void
(gdb) p debug_bb (e->dest)
;; basic block 6, loop depth 1, count 0
;; prev block 5, next block 7
;; pred: 12 [25.0%] (ab,irreducible) 5 [100.0%]
(fallthru,can_fallthru) 13 [50.0%] (can_fallthru,irreducible) 14 [50.0%]
(can_fallthru,irreducible) 15 [100.0%] (can_fallthru,irreducible)
;; succ: 12 [19.0%] (dfs_back,can_fallthru,irreducible) 7 [81.0%]
(fallthru,can_fallthru,irreducible)
;; Registers live at start: 3 [bx] 4 [si] 5 [di] 6 [bp] 7 [sp] 20 [frame]
(code_label/s:HI 71 51 72 6 13 ("__label_40") [6 uses])
(note:HI 72 71 118 6 [bb 6] NOTE_INSN_BASIC_BLOCK)
(insn:TI 118 72 75 6 (set (reg/f:SI 1 dx [orig:59 gotovar.36 ] [59])
(label_ref:SI 49)) 40 {*movsi_1} (nil)
(insn_list:REG_LABEL 49 (expr_list:REG_EQUAL (label_ref:SI 49)
(nil
(insn:TI 75 118 76 6 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/f:SI 3 bx [orig:62 next.1 ] [62])
(reg:SI 1 dx))) 5 {*cmpsi_1_insn} (insn_list:REG_DEP_TRUE 118
(nil))
(nil))
(jump_insn:TI 76 75 78 6 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0x0]))
(label_ref 29)
(pc))) 509 {*jcc_1} (insn_list:REG_DEP_ANTI 118
(insn_list:REG_DEP_TRUE 75 (nil)))
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(expr_list:REG_BR_PROB (const_int 1900 [0x76c])
(nil
;; Registers live at end: 1 [dx] 3 [bx] 4 [si] 5 [di] 6 [bp] 7 [sp] 20
[frame]
$11 = void
(gdb)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23095
[Bug rtl-optimization/23100] poor code generation for i686
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 19:20 --- This is the same issue as PR 16796 really, see comment #3. -- What|Removed |Added Keywords||missed-optimization, ra http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23100
[Bug target/23095] [4.1 Regression] ICE in regstack compensate_edge
--- Additional Comments From steven at gcc dot gnu dot org 2005-07-27 19:15 --- Roger, this appears to be caused by your patch: * reg-stack.c (struct block_info_def): Correct grammar typo. (compensate_edge): Clean-up. Perform as little work as possible when src and dest stacks match. Avoid modifying block_info. Reorder and simplify assertion checks. Avoid unnecessary copying of regstack structure. (convert_regs_1): Set the done flag here... (convert_regs_2): ... instead of here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23095
[Bug rtl-optimization/23098] [3.4/4.0/4.1 Regression] store of 0.0 to float
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
19:13 ---
Another testcase which is a regression (on x86) caused by the same problem:
int g (float* g1,float t)
{
*g1 = 0.0 + t;
}
Without -fPIC,
fldz
movl4(%esp), %eax
fadds 8(%esp)
fstps (%eax)
ret
With -fPIC:
g:
call__i686.get_pc_thunk.cx
addl$_GLOBAL_OFFSET_TABLE_, %ecx
movl4(%esp), %eax
flds[EMAIL PROTECTED](%ecx)
fadds 8(%esp)
fstps (%eax)
ret
in 2.95.3, we get:
g:
fldz
fadds 8(%esp)
movl 4(%esp),%eax
fstps (%eax)
ret
But from 3.0.4 and above we get the same issue as the mainline with -fPIC.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23098
[Bug rtl-optimization/23100] New: poor code generation for i686
Compiling the code below (extracted from xterm-202) with
-fno-inline -O2 -march=i686
typedef unsigned long Atom;
static int
CutBuffer(unsigned code)
{
int cutbuffer;
switch (code) {
case ((Atom) 9):
cutbuffer = 0;
break;
case ((Atom) 10):
cutbuffer = 1;
break;
case ((Atom) 11):
cutbuffer = 2;
break;
case ((Atom) 12):
cutbuffer = 3;
break;
case ((Atom) 13):
cutbuffer = 4;
break;
case ((Atom) 14):
cutbuffer = 5;
break;
case ((Atom) 15):
cutbuffer = 6;
break;
case ((Atom) 16):
cutbuffer = 7;
break;
default:
cutbuffer = -1;
break;
}
return cutbuffer;
}
int foo (unsigned code)
{
return CutBuffer (code);
}
generates:
CutBuffer:
subl$9, %eax
movl$-1, %edx
pushl %ebp
cmpl$7, %eax
movl%esp, %ebp
ja .L12
jmp *.L11(,%eax,4)
.section.rodata
.align 4
.align 4
.L11:
.long .L3
.long .L4
.long .L5
.long .L6
.long .L7
.long .L8
.long .L9
.long .L10
.text
.L9:
movl$6, %edx
.p2align 4,,15
.L12:
popl%ebp
movl%edx, %eax
ret
.L3:
popl%ebp
xorl%edx, %edx
movl%edx, %eax
.p2align 4,,2
ret
.L10:
popl%ebp
movl$7, %edx
movl%edx, %eax
ret
.L8:
popl%ebp
movl$5, %edx
movl%edx, %eax
ret
.L7:
popl%ebp
movl$4, %edx
movl%edx, %eax
ret
.L6:
popl%ebp
movl$3, %edx
movl%edx, %eax
ret
[snip]
Note the sequences: movl NUMBER, %edx
movl %edx, %eax
instead of using only one instruction for the same thing: movl NUMBER, %eax
--
Summary: poor code generation for i686
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23100
[Bug rtl-optimization/23098] [3.4/4.0/4.1 Regression] store of 0.0 to float
--- Additional Comments From dje at gcc dot gnu dot org 2005-07-27 19:11 --- On PowerPC this is because we now are forcing all FP constants to memory. The only constant for which this is interesting is zero, and only if one is storing to memory. XLC produces the same code as GCC mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23098
[Bug c++/23099] [4.0/4.1 regression] ICE in build_simple_base_path, at cp/class.c:460
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 19:03 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2005-07-27 19:03:08 date|| Summary|[4.0 regression] ICE in |[4.0/4.1 regression] ICE in |build_simple_base_path, at |build_simple_base_path, at |cp/class.c:460 |cp/class.c:460 Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23099
[Bug c++/23099] New: [4.0 regression] ICE in build_simple_base_path, at cp/class.c:460
The following test case:
struct Base {
int x;
};
template
struct A {
static const int N = sizeof(static_cast(T()));
};
struct Derived : Base {
A a;
};
gcc 2.95.3: compiles
gcc 3.4.4: compiles
gcc 4.0.1: ICE
b1.cc: In instantiation of 'A':
b1.cc:11: instantiated from here
b1.cc:7: internal compiler error: in build_simple_base_path, at cp/class.c:459
gcc-4.1-20050716: ICE
bug.cc: In instantiation of 'A':
bug.cc:11: instantiated from here
bug.cc:7: internal compiler error: in build_simple_base_path, at cp/class.c:460
gcc CVS 2005-07-25: ICE
b1.cc: In instantiation of 'A':
b1.cc:11: instantiated from here
b1.cc:7: internal compiler error: in build_simple_base_path, at cp/class.c:461
Thanks to mec for uncovering this, and bgibbons for minimizing the
test case.
--
Summary: [4.0 regression] ICE in build_simple_base_path, at
cp/class.c:460
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dank at kegel dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23099
[Bug rtl-optimization/23098] [3.4/4.0/4.1 Regression] store of 0.0 to float
-- What|Removed |Added GCC target triplet|powerpc-darwin |powerpc-darwin, i?86-*-* Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23098
[Bug rtl-optimization/23098] [3.4/4.0/4.1 Regression] store of 0.0 to float
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 18:49 --- Actually I take back x86 is not a regression. It is a regression from 3.2.3 -- What|Removed |Added Known to fail||3.3.3 3.4.0 4.0.0 4.1.0 Known to work||2.95.3 3.2.3 Summary|[4.1 Regression] store of |[3.4/4.0/4.1 Regression] |0.0 to float|store of 0.0 to float http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23098
[Bug rtl-optimization/23098] New: [4.1 Regression] store of 0.0 to float
Take the following program:
int g (float* g1)
{
*g1 = 0;
}
Running it on ppc-darwin on the mainline (with -static), we get:
LC0:
.long 0
.text
.align 2
.globl _g
_g:
lis r2,ha16(LC0)
lfs f0,lo16(LC0)(r2)
stfs f0,0(r3)
blr
On 4.0.0, we get:
_g:
li r0,0
stw r0,0(r3)
blr
x86 have the same problem but only with -fPIC but that is not a regression:
.LC0:
.long 0
.text
.p2align 4,,15
.globl g
.type g, @function
g:
call__i686.get_pc_thunk.cx
addl$_GLOBAL_OFFSET_TABLE_, %ecx
movl4(%esp), %eax
movl[EMAIL PROTECTED](%ecx), %edx
movl%edx, (%eax)
ret
--
Summary: [4.1 Regression] store of 0.0 to float
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: minor
Priority: P2
Component: rtl-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
GCC target triplet: powerpc-darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23098
[Bug target/19885] [4.0/4.1 Regression] avr dwarf-2 support is broken for head 4.0/4.1
--- Additional Comments From bjoern dot m dot haase at web dot de 2005-07-27 18:30 --- >Bjorn, do you have a copyright assignment filed with the FSF? Yes. It took quite a while but since a couple of weeks the paperwork is finished. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19885
[Bug classpath/21869] We should to use StringBuilder instead of StringBuffer where appropriate.
--- Additional Comments From tromey at gcc dot gnu dot org 2005-07-27 17:39 --- This is a request for Classpath. -- What|Removed |Added Component|libgcj |classpath Product|gcc |classpath Version|4.1.0 |0.17 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21869
[Bug libfortran/23097] [4.0/4.1 Regression] non-printable output from write with certain formats
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 17:31 --- This works with 4.1.0 20050727. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23097
[Bug c/22589] [3.4 regression] ICE casting to long long
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-07-27 17:31 --- This seems to be caused by: 2004-02-15 Roger Sayle <[EMAIL PROTECTED]> Backport from mainline: 2004-02-07 Roger Sayle <[EMAIL PROTECTED]> PR middle-end/13696 * fold-const.c (fold_convert): New function to provide type conversion to the middle-end without using convert. (negate_expr, associate_trees, size_diffop, omit_one_operand, operand_equal_for_comparison_p, pedantic_omit_one_operand, invert_truthvalue, optimize_bit_field_compare, range_binop, decode_field_reference, make_range, build_range_check, unextend, fold_truthop, extract_muldiv_1, fold_mathfn_compare, fold_binary_op_with_conditional_arg, fold_inf_compare, fold_single_bit_test, fold, multiple_of_p): Replace all calls to convert with calls to fold_convert. convert() uses CONVERT_EXPR rather than NOP_EXPR for pointer-to-integer conversions, but after the patch above, the original will be "folded" to . On 3.4, get_narrower() returns "foo", which has a pointer type, and causes the segfault in shorten_compare(). This was fixed (worked around?) on mainline by: 2004-07-08 Alexandre Oliva <[EMAIL PROTECTED]> Introduce H8SX support. 2004-06-16 Alexandre Oliva <[EMAIL PROTECTED]> * tree.c (get_narrower): Don't narrow integral types into non-integral types. and backporting that patch seems to fix the testcase. I'm not a tree expert, and I can't find any discussion of Alex's patch: http://gcc.gnu.org/ml/gcc-patches/2004-06/msg01644.html so I'm not sure if CONVERT_EXPR really is required here. But given that this bug is specific to a release branch, and that the branch is deep into "maintenance only" mode, I think that backporting Alex's patch is the best fix here. I'm regression testing it now. Richard -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-07-21 16:36:13 |2005-07-27 17:31:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22589
[Bug libfortran/23097] [4.0/4.1 Regression] non-printable output from write with certain formats
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 17:30 --- Fixed already. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|fortran |libfortran Resolution||FIXED Summary|non-printable output from |[4.0/4.1 Regression] non- |write with certain formats |printable output from write ||with certain formats Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23097
[Bug c++/21123] [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-07-27 17:20 --- Subject: Re: [4.0 regression] ICE in cp_expr_size, at cp/cp-objcp-common.c:101 > Dave, you mentioned that it "needs debugging on a system that can reproduce > it". I was just able to reproduce it using a cvs head build done yesterday. It had checking enabled. The release builds that I had tried previously had checking disabled. Thus, it looks as if the ICE is caused by a tree check failure in the assert at cp/cp-objcp-common.c:101, rather than the assert itself. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21123
[Bug fortran/23097] New: non-printable output from write with certain formats
[EMAIL PROTECTED] test_blas]$ ~/GREG/bin_gcc/bin/gfortran -v Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc4/configure --prefix=/home/casper/GREG/bin_gcc -- mandir=/home/casper/GREG/objdir/share/man --enable- languages=c,c++,f95,java,objc --enable-shared --enable-threads=posix --with- mpfr=/home/casper/GREG/f90_prereq --with-gmp=/home/casper/GREG/f90_prereq : (reconfigured) ../gcc4/configure --prefix=/home/casper/GREG/bin_gcc --enable- threads --with-gmp=/home/casper/GREG/f90_prereq --with- mpfr=/home/casper/GREG/f90_prereq Thread model: posix gcc version 4.1.0 20050719 (experimental) [EMAIL PROTECTED] test_blas]$ uname -a Linux ARROW 2.4.20-8bigmem #1 SMP Thu Mar 13 17:32:29 EST 2003 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] test_blas]$ cat test_io.f90 PROGRAM TEST_IO INTEGER :: A = 12, B = 109 ! actual data not important WRITE(*,100)A,B WRITE(*,101)A,B 100 FORMAT(/,2X,I5,/2X,I5) 101 FORMAT(2(/,3X,I5)) END PROGRAM TEST_IO [EMAIL PROTECTED] test_blas]$ ~/GREG/bin_gcc/bin/gfortran test_io.f90 -static [EMAIL PROTECTED] test_blas]$ ./a.out 12 109 12 109 - As you can see this is the expected normal behavior, but if you redirect the output by either piping to something like less, or to a file then editing with say: [EMAIL PROTECTED] test_blas]$ ./a.out > junk; vi junk the file becomes: 12 [EMAIL PROTECTED]@ 109 12 [EMAIL PROTECTED]@^@ 109 -- the ^@ characters are supposed to be the blanks that the #X outputs. As you can see it prints some odd character instead. This only happens after you make a newline with /, otherwise it works as normal. If you have a single format statement with multiple /2X statements like format 101 above, the first one works correctly, all others after this exibit the bug. -- Summary: non-printable output from write with certain formats Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: grrogers at umd dot edu CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23097
[Bug tree-optimization/21559] [4.1 Regression] missed jump threading
--- Additional Comments From law at redhat dot com 2005-07-27 17:13 --- It's highly unlikely threading is going to be able to completely eliminate the test for bytes == 0. The fundamental problem is the threader has no way of knowing that the loop exit test (toread != 0) can never be true if bytes == 0. Now there is a missed threading opportunity in this code, when bytes <= 0, but ! (bytes < 0) we exit the loop via a break statement. Clearly when we exit the loop via that break statement, we need not test bytes == 0 again outside the loop. It's also the case that the test bytes < 0 can and should be simplified into bytes != 0. In fact, if VRP is enhanced to perform that simplification, then we do thread the loop exit via the break statement. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21559
[Bug tree-optimization/17064] -falias-noargument-global doesn't eliminate dead stores/loads
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27
17:06 ---
Another testcase for extra load at the tree level:
int g (int* g1, int* g2)
{
int i;
g2[0] = 2;
g1[0] = 3;
return g2[0];
}
Note the test in comment #1 has been fixed already.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17064
[Bug tree-optimization/22630] [4.1 Regression] vrp produces wrong code
--- Additional Comments From law at redhat dot com 2005-07-27 16:55 --- Subject: Re: [4.1 Regression] vrp produces wrong code On Wed, 2005-07-27 at 16:34 +, ja2morri at csclub dot uwaterloo dot ca wrote: > --- Additional Comments From ja2morri at csclub dot uwaterloo dot ca > 2005-07-27 16:34 --- > Subject: Re: [4.1 Regression] vrp produces > wrong code > > > Jeffrey A Law <[EMAIL PROTECTED]> writes: > > > The underlying problem here is the code to meet a VR_ANTI_RANGE and > > a VR_RANGE does not intersect the equivalence sets. This in turn > > causes the VRP code to incorrectly evaluate a conditional. It's > > all downhill after that. > > > > While investigating this problem I also noticed that the vrp_meet > > code does not properly handle intersecting the equivalence sets > > when vr0 has a set, but vr1 does not (their intersection is the > > null set of course). This patch fixes that oversight as well. > > > > Bootstrapped and regression tested on i686-pc-linux-gnu. > > > > jeff > > You added 3 bitmap_clear calls here, do you have any testcases that > exercise this code? No, but the code is clearly wrong by inspection. jeff -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22630
[Bug libstdc++/23081] Finish the implementation of tr1::array
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 16:51 --- Confirmed. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-27 16:51:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23081
[Bug tree-optimization/20773] [4.0 Regression] ICE: SEGV building jar file
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 16:45 --- Fixed on the mainline, I think the 4.0 branch's bug is slightly different also. -- What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2005- | |07/msg01132.html| Keywords|patch | Summary|[4.0/4.1 Regression] ICE: |[4.0 Regression] ICE: SEGV |SEGV building jar file |building jar file Target Milestone|4.1.0 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20773
[Bug tree-optimization/22348] [4.0 Regression] Execution continues past end of for loop end condition with optimisation enabled
-- What|Removed |Added Status|REOPENED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22348
[Bug tree-optimization/22348] [4.0 Regression] Execution continues past end of for loop end condition with optimisation enabled
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 16:40 --- Actually this was only fixed on the mainline, it also fails in 4.0.0 branch too. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | Summary|[4.0/4.1 Regression]|[4.0 Regression] Execution |Execution continues past end|continues past end of for |of for loop end condition |loop end condition with |with optimisation enabled |optimisation enabled http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22348
[Bug middle-end/23096] Wrong folding for FLOOR_MOD_EXPR
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 16:38 --- >From comment #7 of PR 22348: extract_muldiv(51 - 7, 3, FLOOR_MOD_EXPR) returns incorrectly 0. The reason is that 51 - 7 is replaced with 51 + ~6, and both 51 and ~6 are divisible by 3, so the result obviously is 0 :-) Someone forgot about overflows. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23096
[Bug middle-end/23096] Wrong folding for FLOOR_MOD_EXPR
-- What|Removed |Added CC||rakdver at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-07-27 16:38:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23096
[Bug middle-end/23096] Wrong folding for FLOOR_MOD_EXPR
-- What|Removed |Added OtherBugsDependingO||22348 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23096
[Bug tree-optimization/22348] [4.0/4.1 Regression] Execution continues past end of for loop end condition with optimisation enabled
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 16:37 --- The work around is in but the new problem should have been filed as a new bug which I did as PR 23096. The testcase is now fixed. -- What|Removed |Added OtherBugsDependingO|23096 | nThis|| Status|NEW |RESOLVED Resolution||FIXED Summary|[4.0/4.1 Regression] Wrong |[4.0/4.1 Regression] |folding for FLOOR_MOD_EXPR |Execution continues past end ||of for loop end condition ||with optimisation enabled http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22348
[Bug middle-end/23096] Wrong folding for FLOOR_MOD_EXPR
-- What|Removed |Added BugsThisDependsOn|22348 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23096
[Bug tree-optimization/22348] [4.0/4.1 Regression] Wrong folding for FLOOR_MOD_EXPR
-- What|Removed |Added OtherBugsDependingO||23096 nThis|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22348
[Bug middle-end/23096] New: Wrong folding for FLOOR_MOD_EXPR
See PR 22348 for the full analysis of this bug. -- Summary: Wrong folding for FLOOR_MOD_EXPR Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal 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 BugsThisDependsOn: 22348 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23096
[Bug tree-optimization/22630] [4.1 Regression] vrp produces wrong code
--- Additional Comments From ja2morri at csclub dot uwaterloo dot ca 2005-07-27 16:34 --- Subject: Re: [4.1 Regression] vrp produces wrong code Jeffrey A Law <[EMAIL PROTECTED]> writes: > The underlying problem here is the code to meet a VR_ANTI_RANGE and > a VR_RANGE does not intersect the equivalence sets. This in turn > causes the VRP code to incorrectly evaluate a conditional. It's > all downhill after that. > > While investigating this problem I also noticed that the vrp_meet > code does not properly handle intersecting the equivalence sets > when vr0 has a set, but vr1 does not (their intersection is the > null set of course). This patch fixes that oversight as well. > > Bootstrapped and regression tested on i686-pc-linux-gnu. > > jeff You added 3 bitmap_clear calls here, do you have any testcases that exercise this code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22630
[Bug target/23093] base class template specialization in library
-- What|Removed |Added CC||gerrit at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23093
[Bug tree-optimization/23073] [4.1 regression] testsuite failure, gcc.dg/tree-ssa/ifc-20040816-2.c
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-07-27 16:31 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23073
