--- 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
--- 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
--
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
--- 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
--- 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,
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
--- 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
--
--- 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
-
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
--
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||
--- 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
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
>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
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
25 matches
Mail list logo
