Bug#347508: libstdc++6-4.0-dev: 4.0.3/libstdc++.a BFD: sh_link in section XXX is incorrect

2006-01-10 Thread Grant Grundler
Package: libstdc++6-4.0-dev Version: 4.0.2-5 Severity: important $ ar t /usr/lib/gcc/ia64-linux-gnu/4.0.3/libstdc++.a BFD: /usr/lib/gcc/ia64-linux-gnu/4.0.3/libstdc++.a(bitmap_allocator.o): sh_link [281] in section `.IA_64.unwind.text._ZN9__gnu_cxx9free_list6_M_getEm' is incorrect BFD: /usr/lib/g

Suggested strengthening of -Wconversion

2006-01-10 Thread Matteo Frigo
>Submitter-Id: net >Originator:Matteo Frigo >Organization: >Confidential: no >Synopsis: gcc -Wconversion should warn on implicit 64-bit => 32-bit >integral conversions >Severity: non-critical >Priority: low >Category: c >Class: change-request >Release: 4

Bug#347484: gcc-4.0: Give option not to depend on system -base package for cross compiler

2006-01-10 Thread Ian Wienand
Package: gcc-4.0 Version: 4.0.2-6 Severity: wishlist Tags: patch Hi, Thanks for making it quite easy to build a cross compiler on Debian. The only problem I have had is that the packages by default depend on the -base package used by the system gcc. This means whenever I upgrade my system gcc I

[Bug target/23451] Redundant reloading from stack frame on i386

2006-01-10 Thread herbert at gondor dot apana dot org dot au
--- Comment #18 from herbert at gondor dot apana dot org dot au 2006-01-10 23:45 --- Subject: Re: Redundant reloading from stack frame on i386 On Tue, Jan 10, 2006 at 11:44:21PM -, steven at gcc dot gnu dot org wrote: > > > --- Comment #17 from steven at gcc dot gnu dot org

[Bug target/23451] Redundant reloading from stack frame on i386

2006-01-10 Thread steven at gcc dot gnu dot org
-- steven at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2006-01-10 20:36:18 |2006-01-10 23:44:58 date||

[Bug target/23451] Redundant reloading from stack frame on i386

2006-01-10 Thread steven at gcc dot gnu dot org
--- Comment #17 from steven at gcc dot gnu dot org 2006-01-10 23:44 --- Fair enough. I think it's highly unlikely that anyone would care enough about i386 to worry about fixing this, but you never know. -- steven at gcc dot gnu dot org changed: What|Removed

[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame

2006-01-10 Thread herbert at gondor dot apana dot org dot au
--- Comment #16 from herbert at gondor dot apana dot org dot au 2006-01-10 23:41 --- Subject: Re: [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame On Tue, Jan 10, 2006 at 11:36:51PM -, steven at gcc dot gnu dot org wrote: > > So, closing as INVALID, i.e. not-a-bu

[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame

2006-01-10 Thread steven at gcc dot gnu dot org
--- Comment #15 from steven at gcc dot gnu dot org 2006-01-10 23:36 --- Then I am quite sure that the difference comes from using "repnz; scasb" in GCC 3.2 vs. calling strlen in GCC 3.3 on i486. For GCC 3.2, the code for i386 and i486 are pretty much equivalent (the only difference is t

[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame

2006-01-10 Thread herbert at gondor dot apana dot org dot au
--- Comment #14 from herbert at gondor dot apana dot org dot au 2006-01-10 23:25 --- Subject: Re: [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame On Tue, Jan 10, 2006 at 10:58:03PM -, steven at gcc dot gnu dot org wrote: > > > --- Comment #8 from steven at

[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame

2006-01-10 Thread steven at gcc dot gnu dot org
--- Comment #13 from steven at gcc dot gnu dot org 2006-01-10 23:04 --- Created an attachment (id=10615) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10615&action=view) gcc 3.2 vs. gcc 4.0 .s output, march=i686 For the sake of completeness, also a diff between GCC 3.2 and GCC 4.0

[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame

2006-01-10 Thread steven at gcc dot gnu dot org
--- Comment #12 from steven at gcc dot gnu dot org 2006-01-10 23:02 --- For the record, it is a known problem that x86 32 bits hosts and x86_64 hosts sometimes produce different code, even with the same -march options. We may be seeing one such case here, eventhough that is quite unlike

[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame

2006-01-10 Thread steven at gcc dot gnu dot org
--- Comment #11 from steven at gcc dot gnu dot org 2006-01-10 23:01 --- Created an attachment (id=10614) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10614&action=view) gcc 3.2 vs. gcc 3.3 .s output, march=i686 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23451 --- You

[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame

2006-01-10 Thread steven at gcc dot gnu dot org
--- Comment #10 from steven at gcc dot gnu dot org 2006-01-10 23:00 --- Created an attachment (id=10613) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10613&action=view) gcc 3.2 vs. gcc 3.3 .s output, march=i586 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23451 --- You

[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame

2006-01-10 Thread steven at gcc dot gnu dot org
--- Comment #9 from steven at gcc dot gnu dot org 2006-01-10 23:00 --- Created an attachment (id=10612) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10612&action=view) gcc 3.2 vs. gcc 3.3 .s output, march=i486 All .s files created on AMD64, compiler options -m32 -S -O2 -march=i[4

[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame

2006-01-10 Thread steven at gcc dot gnu dot org
--- Comment #8 from steven at gcc dot gnu dot org 2006-01-10 22:58 --- Unfortunately you're not showing your full command line, so I can only guess what platform your host is and for what target you are compiling. I will attach diffs between GCC 3.2 and GCC 3.3-hammer for i[456]86. To

[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame

2006-01-10 Thread herbert at gondor dot apana dot org dot au
--- Comment #7 from herbert at gondor dot apana dot org dot au 2006-01-10 22:44 --- Subject: Re: [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame On Tue, Jan 10, 2006 at 09:32:58PM -, steven at gcc dot gnu dot org wrote: > > --- Comment #6 from steven at gcc

[Bug c++/25744] typename causes segmentation fault

2006-01-10 Thread bangerth at dealii dot org
--- Comment #3 from bangerth at dealii dot org 2006-01-10 22:40 --- Confirmed, but this is already fixed as of 3.4.6 20060102 (prerelease) W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25744 --- You are receiving this mail because: --- You are on the CC list for the bug

[Bug c++/23797] [3.4 Regression] ICE on typename outside template

2006-01-10 Thread pinskia at gcc dot gnu dot org
--- Comment #18 from pinskia at gcc dot gnu dot org 2006-01-10 22:40 --- *** Bug 25744 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added -

[Bug c++/25744] typename causes segmentation fault

2006-01-10 Thread pinskia at gcc dot gnu dot org
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-01-10 22:40 --- *** This bug has been marked as a duplicate of 23797 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added --

Bug#301746: [Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame

2006-01-10 Thread Herbert Xu
On Tue, Jan 10, 2006 at 09:32:58PM -, steven at gcc dot gnu dot org wrote: > > --- Comment #6 from steven at gcc dot gnu dot org 2006-01-10 21:32 > --- > Since GCC 3.2 also has this problem, contrary to what the reporter claims, I > am > not sure if we should keep this marked as a r

[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame

2006-01-10 Thread steven at gcc dot gnu dot org
--- Comment #6 from steven at gcc dot gnu dot org 2006-01-10 21:32 --- Since GCC 3.2 also has this problem, contrary to what the reporter claims, I am not sure if we should keep this marked as a regression. Obviously it is a missed optimization, so the bug report is valid in that sense,

[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame

2006-01-10 Thread steven at gcc dot gnu dot org
--- Comment #5 from steven at gcc dot gnu dot org 2006-01-10 21:27 --- FWIW, the peephole that we trigger is this one, which has been around since forever (since rth's ia32 backend rewrite from the previous century...): ;; Don't compare memory with zero, load and use a test instead. (de

[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame

2006-01-10 Thread steven at gcc dot gnu dot org
-- steven at gcc dot gnu dot org changed: What|Removed |Added Keywords|ra | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23451 --- You are r

[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame

2006-01-10 Thread steven at gcc dot gnu dot org
--- Comment #4 from steven at gcc dot gnu dot org 2006-01-10 20:57 --- On the trunk, we have the following situation in the .csa RTL dump (on AMD64 -m32 -march=i686): ;; Start of basic block 5, registers live: 4 [si] 5 [di] 6 [bp] 7 [sp] 20 [frame] (code_label:HI 38 37 39 5 2 "" [1 use

[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame

2006-01-10 Thread steven at gcc dot gnu dot org
--- Comment #3 from steven at gcc dot gnu dot org 2006-01-10 20:36 --- GCC 4.2 (trunk) produces this kind of redundant loads: ... movl-20(%ebp), %eax testl %eax, %eax je .L10 movl-20(%ebp), %eax movl%eax, (%esp) c