--- Comment #10 from steven at gcc dot gnu dot org 2005-12-18 17:15 ---
rth assigned this to himself:
http://gcc.gnu.org/ml/gcc-bugs/2005-11/msg02843.html
A progress report would be nice ;-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16876
--- Comment #7 from steven at gcc dot gnu dot org 2005-12-18 17:17 ---
This will *NOT* be fixed for GCC 4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24408
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #13 from steven at gcc dot gnu dot org 2005-12-18 18:39 ---
Ugh, I guess that means going back to a checkout of the day of the report if we
want to reproduce this :-/
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2005-12-18 23:24 ---
Works in r108712.
Breaks in r108713.
That's the ENTRY/EXIT block renumbering patch. Somehow this seems to have
messed up df_analyze_subcfg.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25483
--- Comment #5 from steven at gcc dot gnu dot org 2005-12-18 23:44 ---
We get to iterative_dataflow from df_analyze_subcfg with this dataflow
argument:
(gdb) p *dataflow
$11 = {repr = SR_BITMAP, gen = 0xf43d90, kill = 0xf439d0, in = 0xf55ac0, out =
0xf57ca0,
dir = DF_FORWARD, conf_op
--- Comment #6 from steven at gcc dot gnu dot org 2005-12-18 23:52 ---
Kenny is working on a fix.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from steven at gcc dot gnu dot org 2005-12-19 06:30 ---
Could this be a dup of Bug 23585?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23954
--- Comment #37 from steven at gcc dot gnu dot org 2005-12-19 12:36 ---
That would be a different bug, and the fix would still be to not have a
no-conflict block to begin with.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from steven at gcc dot gnu dot org 2005-12-19 23:18 ---
Should be fixed on the trunk.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #20 from steven at gcc dot gnu dot org 2005-12-20 06:48 ---
HJ, see comment #18.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25305
--- Comment #5 from steven at gcc dot gnu dot org 2005-12-20 10:17 ---
Re. comment #4: but this new PR has a much simpler test case :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot
|dot org
--- Comment #12 from steven at gcc dot gnu dot org 2005-12-20 10:48 ---
Almost certainly a dup of PR25196
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23453
--- Comment #7 from steven at gcc dot gnu dot org 2005-12-20 14:59 ---
Does not fail with trunk or the head of the gcc 4.1 branch. But it does fail
with gcc 4.0.2. I'm going to try it with the head of the gcc 4.0 branch now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25196
--- Comment #8 from steven at gcc dot gnu dot org 2005-12-20 15:58 ---
Gross. According to a comment in postreload.c:move2add_note_store(), we can
have pushes without REG_INC notes:
/* Some targets do argument pushes without adding REG_INC notes. */
So we need to go look for those
--- Comment #14 from steven at gcc dot gnu dot org 2005-12-20 16:11 ---
The patch proposed in bug 25196 comment #8 indeed makes the test case from
comment #6 in this PR work (at least, it stops it from segfaulting).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23453
--- Comment #13 from steven at gcc dot gnu dot org 2005-12-21 15:28 ---
Subject: Bug 25130
Author: steven
Date: Wed Dec 21 15:28:16 2005
New Revision: 108906
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108906
Log:
patch for PR rtl-optimization/25
--- Comment #14 from steven at gcc dot gnu dot org 2005-12-21 15:32 ---
Subject: Bug 25130
Author: steven
Date: Wed Dec 21 15:32:09 2005
New Revision: 108907
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108907
Log:
patch for PR rtl-optimization/25130, gcc 4.1 editi
--- Comment #8 from steven at gcc dot gnu dot org 2005-12-21 15:34 ---
Patch posted by Jakub.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from steven at gcc dot gnu dot org 2005-12-21 15:45 ---
That's what you get for working on different GCSEs at the same time.
Those commits were for Bug 25196 :-(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25130
--- Comment #9 from steven at gcc dot gnu dot org 2005-12-21 15:46 ---
Fixed on the trunk and on the GCC 4.1 branch.
See http://gcc.gnu.org/ml/gcc-cvs/2005-12/msg01177.html and
http://gcc.gnu.org/ml/gcc-cvs/2005-12/msg01178.html (I used the wrong bug
number in the commit >:-/)
Will
--- Comment #16 from steven at gcc dot gnu dot org 2005-12-27 00:58 ---
Created an attachment (id=10557)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10557&action=view)
Make hash_rtx and exp_equiv_p take MEM_ATTRS into accoutn
The test cases don't fail with GCC 4.2
--- Comment #8 from steven at gcc dot gnu dot org 2005-12-27 11:08 ---
Nathan, tomorrow is more than a month ago. Ping!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24824
--- Comment #9 from steven at gcc dot gnu dot org 2005-12-27 11:11 ---
The patch that Janis identified in comment #5 fixed bug 19497, which is only an
"accepts-invalid". Bug 19497 was not fixed on the GCC 4.0 branch. Perhaps
that patch to fix it for GCC 4.1 should just be r
--- Comment #16 from steven at gcc dot gnu dot org 2005-12-27 11:16 ---
Re. comments #14 and #15 -- Dave you really should also say what compiler you
used, or people will just have to make a guess. They'd probably conclude you
are testing GCC 3.3 in this case ;-)
Anyway, i
--- Comment #1 from steven at gcc dot gnu dot org 2005-12-27 12:22 ---
That happens because data flow information is used to find uninitialized
variables. Some folks argue that this by itself is a bug, and that it should
be entirely up to the front end to diagnose uninitialized
--- Comment #8 from steven at gcc dot gnu dot org 2005-12-28 09:27 ---
Reopening...
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #9 from steven at gcc dot gnu dot org 2005-12-28 09:28 ---
...to close as INVALID.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2005-12-29 09:56 ---
The patch you identified as "breaking" this, is correct. Your bug is
elsewhere. But, there is no way to tell where without a test case.
Unless you're going to talk about public viewable sources, per
--- Comment #7 from steven at gcc dot gnu dot org 2005-12-29 21:52 ---
This bug report is for a really old compiler.
Would I hurt anyone's feelings if I just close this bug as WONTFIX? :-)
--
steven at gcc dot gnu dot org changed:
What|Re
--- Comment #2 from steven at gcc dot gnu dot org 2005-12-29 21:54 ---
Are you seeing the same problem with more recent compilers, like GCC 4.0 or a
GCC 4.1 snapshot?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24376
--- Comment #17 from steven at gcc dot gnu dot org 2006-01-01 17:37 ---
I posted a patch that addresses the gcse.c part of the problem.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from steven at gcc dot gnu dot org 2006-01-01 18:49 ---
Adding Nick to the CC list, because he is the listed v850 port maintainer.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from steven at gcc dot gnu dot org 2006-01-02 21:27 ---
Ehm, wouldn't "unsigned char *" alias everything? GCSE doesn't do load PRE for
me on the original test case, either. And, as long as "outbuf[outcnt] =
bi_buf;" has a V_MAY_DEF for o
--- Comment #7 from steven at gcc dot gnu dot org 2006-01-02 21:30 ---
With an even more modified test case, load PRE does happen:
unsigned long outcnt;
extern void flush_outbuf(void);
void
bi_windup(unsigned int *outbuf, unsigned int bi_buf, unsigned long *outcnt)
{
unsigned long
--- Comment #18 from steven at gcc dot gnu dot org 2006-01-03 06:20 ---
Subject: Bug 25130
Author: steven
Date: Tue Jan 3 06:20:21 2006
New Revision: 109264
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109264
Log:
* fold-const.c (operand_equal_p): Accep
--- Comment #19 from steven at gcc dot gnu dot org 2006-01-03 22:37 ---
Subject: Bug 25130
Author: steven
Date: Tue Jan 3 22:37:46 2006
New Revision: 109292
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=109292
Log:
2006-01-03 Steven Bosscher <[EMAI
--- Comment #20 from steven at gcc dot gnu dot org 2006-01-03 22:39 ---
One part of the problem is fixed, and the test cases now pass.
There is still the RTL alias analysis bug mentioned in the thread on gcc@
starting here: http://gcc.gnu.org/ml/gcc/2006-01/msg8.html. But that is
roduct: gcc
Version: 4.2.0
Status: UNCONFIRMED
Keywords: wrong-code, alias
Severity: major
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: steven at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
--- Comment #10 from steven at gcc dot gnu dot org 2006-01-04 22:35 ---
Re. comment #9, I don't understand how the way we hash would make load PRE
harder. Could you elaborate a bit on what is missing or done "wrong" for load
PRE of globals??
--
http://gcc.g
--- Comment #6 from steven at gcc dot gnu dot org 2006-01-05 17:04 ---
Assigning to Andrew Pinski because I wont be able to work on this for a while.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to
--- Comment #22 from steven at gcc dot gnu dot org 2006-01-05 22:54 ---
Mustafa's change (http://gcc.gnu.org/viewcvs?view=rev&rev=97481) has the
following ChangeLog entry:
(rtl_verify_flow_info_1): Fix.
@@ -2028,7 +2028,7 @@
err = 1;
}
if
--- Comment #11 from steven at gcc dot gnu dot org 2006-01-07 00:25 ---
The thread starting at http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00373.html
addresses my question in comment #10.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23455
--- Comment #4 from steven at gcc dot gnu dot org 2006-01-07 18:04 ---
On AMD64 with GNU C version 4.2.0 20060107, I get this .optimized dump:
;; Function foo (foo)
foo (r)
{
int r$b;
int r$a;
char r$d;
:
r$b = r.b;
r$a = r.a;
r$d = r.d;
.m = r.m;
.b = r$b;
.a = r$a
--- Comment #21 from steven at gcc dot gnu dot org 2006-01-07 18:23 ---
Using ``.ident "GCC: (GNU) 4.1.0 20060107 (prerelease)"'' on AMD64 with -m32,
I get the following assembly outputs:
options: -O2 -fno-tree-dominator-opts
.L2:
movl$videoram, %eax
--- Comment #22 from steven at gcc dot gnu dot org 2006-01-07 18:33 ---
I compiled the test case nodom.c with "xgcc (GCC) 4.1.0 20060107 (prerelease)"
and ran the resulting executables with "time ./a.out". And the numbers speak
for themsel
--- Comment #7 from steven at gcc dot gnu dot org 2006-01-07 18:41 ---
GCC 4.1-20060107 still produces the code reported in the original bug report:
:
0: 48 89 f8mov%rdi,%rax
3: 48 f7 d8neg%rax
6: 48 21 c7
--- Comment #1 from steven at gcc dot gnu dot org 2006-01-07 22:00 ---
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00416.html
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #12 from steven at gcc dot gnu dot org 2006-01-08 00:45 ---
I looked at what is going on here with "GNU C version 4.1.0 20060107
(prerelease) (x86_64-unknown-linux-gnu)"
We produce the invalid insn in replace_store_insn, where we have:
(gdb) p debug_rtx(del)
(ins
--- Comment #5 from steven at gcc dot gnu dot org 2006-01-08 15:05 ---
Created an attachment (id=10594)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10594&action=view)
Robustify
Ideally we would be able to reject (int)&a as non-constant and therefore
illegal because
--- Comment #6 from steven at gcc dot gnu dot org 2006-01-08 15:09 ---
Of course I mean "[finish_decl] _is_ called after the point where we fail now".
The error for (int)&a not being a constant is issued from finish_decl, but we
ICE before we call finish_decl for buf.
W
--- Comment #29 from steven at gcc dot gnu dot org 2006-01-08 16:02 ---
User times:
optimization| GCC version
level | 3.3-hammer 4.0 4.1
+
-O0 | 0m7.248s
--- Comment #30 from steven at gcc dot gnu dot org 2006-01-08 16:08 ---
Other than VRP taking so much time for GCC 4.1, there are no surprises in the
timings I just added in comment #29 for GCC 4.0 and GCC 4.1.
Computing dominance frontiers is just not a linear operation (especially
--- Comment #31 from steven at gcc dot gnu dot org 2006-01-08 16:14 ---
Re. the timings in comment #29, I should have said that my GCC 3.3 was
bootstrapped, but the GCC 4.0 and GCC 4.1 I used were built with "-O0 -g". I
added 3.3 numbers for "ballpark" refer
--- Comment #3 from steven at gcc dot gnu dot org 2006-01-08 17:35 ---
Re. #1, where you wrote: "What the using community needs are not arguments but
continued use of working programs. Rewrites are OK when there are clear
advantages in efficiency or less susceptibility to fraudulen
--- Comment #32 from steven at gcc dot gnu dot org 2006-01-08 18:16 ---
I have bootstrapped 4.0 and 4.1 and re-timed:
GCC 4.0 0m38.118s
GCC 4.1 0m51.059s
The distribution of the compile time is not significantly different from the
timings of the -O0 compilers.
--
http
--- Comment #33 from steven at gcc dot gnu dot org 2006-01-08 18:32 ---
So where are we wrt. GCC 3.3-hammer at -O2?
compiler absolute time relative to 3.3-hammer
GCC 3.3 0m30.390s 1.00
GCC 4.0 0m38.118s 1.25
GCC 4.1 0m51.059s 1.68
--- Comment #34 from steven at gcc dot gnu dot org 2006-01-08 18:40 ---
Another factor contributing to the huge compile time requirements of VRP for
this test case is the number of equivalences recorded:
Value ranges after VRP ("..." meaning I cut away a *cough* few b_i
--- Comment #5 from steven at gcc dot gnu dot org 2006-01-08 21:30 ---
Created an attachment (id=10595)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10595&action=view)
allow jumping into blocks in legacy mode
Something like this is probably all that's needed.
--- Comment #6 from steven at gcc dot gnu dot org 2006-01-08 21:32 ---
(From update of attachment 10595)
Index: resolve.c
===
--- resolve.c (revision 109449)
+++ resolve.c (working copy)
@@ -3579,9 +3579,12
--- Comment #7 from steven at gcc dot gnu dot org 2006-01-08 21:33 ---
(From update of attachment 10595)
See comment #6
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from steven at gcc dot gnu dot org 2006-01-08 21:45 ---
Actually we already know for sure that the label exists and that it is a valid
jump target. From resolve_branch:
/* Step one: is this a valid branching target? */
if (lp->defined == ST_LABEL_UNKN
--- Comment #10 from steven at gcc dot gnu dot org 2006-01-08 21:54 ---
Note that this code in resolve_branch is only slow for deeply nested programs
with many gotos. The code in resolve_branch is linear in the size of the
program, but if your program has many GOTO statements, say of
--- Comment #12 from steven at gcc dot gnu dot org 2006-01-08 22:23 ---
Yes please.
And what do you think of the other idea to speed things up?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18540
--- Comment #16 from steven at gcc dot gnu dot org 2006-01-09 18:35 ---
The idea of comment #14 and #15 looks better than mine, yes.
Which bug is the slowness bug btw? We should really be discussing solutions
for that bug in the audit trail of that bug instead of this one
--- Comment #13 from steven at gcc dot gnu dot org 2006-01-09 21:25 ---
Created an attachment (id=10601)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10601&action=view)
proposed fix
This is my throw-over-the-wall completely untested proposed fix
for PR24257. We end up
--- Comment #4 from steven at gcc dot gnu dot org 2006-01-09 21:57 ---
Your command line:
touch test.h; gcc -dM test.h
creates a precompiled header.
Also, my documentation for -dM says:
@item -dM
@itemx -fdump-rtl-mach
@opindex dM
@opindex fdump-rtl-mach
Dump after performing the
--- Comment #5 from steven at gcc dot gnu dot org 2006-01-09 22:00 ---
I get a lot of output with:
$ gcc -E -dD test.c
Perhaps that is what you're looking for. This looks more like a documentation
bug to me than a real preprocessor bug.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #4 from steven at gcc dot gnu dot org 2006-01-09 22:02 ---
IA-64 is a secondary platform, and Fortran is not a release critical language.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from steven at gcc dot gnu dot org 2006-01-09 22:23 ---
AMD64 timings for today's GCC 4.1 (20060109) branch:
flags used score
for compilation (avg. of 3, higher is better
--- Comment #35 from steven at gcc dot gnu dot org 2006-01-09 22:26 ---
...and so we go blame Diego for the 4.1/4.2 problem, because gcse.c CPROP is no
longer a problem here for GCC 4.0/4.1/4.2.
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #17 from steven at gcc dot gnu dot org 2006-01-09 22:43 ---
And the numbers for "gcc (GCC) 4.1.0 20060109" are
flags: .text size:
-Os 86 bytes
-Os -fno-ivopts 86 bytes
-m32 -Os58 bytes
-m32 -Os -
--- Comment #18 from steven at gcc dot gnu dot org 2006-01-09 22:44 ---
For reference, gcc 3.3-hammer-branch has the following .text sizes:
flags: .text size:
-Os 83
-m32 -Os44
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #19 from steven at gcc dot gnu dot org 2006-01-09 22:50 ---
Disassembly of section .text for x86 (compiled on AMD64 with -m32 -mtune=i686):
:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 8b 4d 10
--- Comment #9 from steven at gcc dot gnu dot org 2006-01-09 23:25 ---
Then let's close it. Thanks!
I'm closing it as WONTFIX because the problem may still exist in GCC 3.0 and
3.1 at least, and we're not going to fix that.
--
steven at gcc dot gnu dot org changed:
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25734
--- Comment #1 from steven at gcc dot gnu dot org 2006-01-10 17:25 ---
One of trivial.[cC] has to be renamed.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from steven at gcc dot gnu dot org 2006-01-10 17:50 ---
The new reassociation pass, or the removal of DOM's reassociation bits, fixed
this on the trunk. We get poorer initial RTL generation out of GCC 4.1 and we
never manage to fix it up:
The .final_cleanup from GC
--- Comment #4 from steven at gcc dot gnu dot org 2006-01-10 20:26 ---
Honza, are you going to do something useful with your patch from comment #3?
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- 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
--- 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 "
--- 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 te
--- 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
--- Comment #7 from steven at gcc dot gnu dot org 2006-01-10 22:00 ---
The patch does look reasonable to me at first sight. Steve, are you going to
look at the patch? It'd be nice to have this fixed in GCC 4.1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25486
--- Comment #6 from steven at gcc dot gnu dot org 2006-01-10 22:04 ---
No feedback for way more than 5 months, and not reconfirmed in the last 6
months. We may still look at the problem somewhen, hence suspending. Rainer,
if this problem still exists, can you investigate the problem a
--- Comment #5 from steven at gcc dot gnu dot org 2006-01-10 22:07 ---
Adding Jim Wilson to the CC: because he is the listed IA-64 maintainer.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from steven at gcc dot gnu dot org 2006-01-10 22:22 ---
Leaving "critical" bugs as UNCONFIRMED isn't going to help us keep the bug
database maintainable... So moving to WAITING pending further analysis by
Rainer or others.
However, it may well be a
--- Comment #24 from steven at gcc dot gnu dot org 2006-01-10 22:39 ---
Realistically, the prospects are that this problem won't be fixed until compile
time gets on the GCC developers' radar for real. The next release always
promises to be faster, but usually turns
--- 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
--- 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 -
--- 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
--- 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
--- 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
--- 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
--- 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 dif
--- 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|Re
--- Comment #13 from steven at gcc dot gnu dot org 2006-01-11 21:18 ---
Bernhard, thanks for fixing this, but you have put your ChangeLog entries in
the wrong ChangeLog. They should be in gcc/fortran/ChangeLog, and they are in
gcc/ChangeLog. Could you please fix that?
--
http
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25654
501 - 600 of 3051 matches
Mail list logo
