--- Comment #3 from vda dot linux at googlemail dot com 2010-02-04 14:33
---
I was bitten by this whet I was trying to get rid of
warning: dereferencing type-punned pointer will break strict-aliasing rules
on this fairly normal networking-related code:
if (cmsgptr-cmsg_level
1
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet
--- Comment #8 from vda dot linux at googlemail dot com 2009-06-21 16:11
---
(In reply to comment #7)
It seems to make sense to bump cost of idiv a bit, given the fact that there
are register pressure implications.
I would like to however understand what code sequences we produce
--- Comment #9 from vda dot linux at googlemail dot com 2009-06-21 16:12
---
Created an attachment (id=18040)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18040action=view)
Comparison of generated code with 4.4.svn.20090528 on x86_64
--
http://gcc.gnu.org/bugzilla
--- Comment #11 from vda dot linux at googlemail dot com 2009-06-21 16:47
---
In 32-bit code, there are indeed a few cases of code growth.
Here is a full list (id_XXX are signed divides, ud_XXX are unsigned ones):
- 000f T id_x_4
+ 0012 T id_x_4
-
--- Comment #12 from vda dot linux at googlemail dot com 2009-06-21 16:48
---
Created an attachment (id=18041)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18041action=view)
Comparison of generated code with 4.4.svn.20090528 on i86
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #13 from vda dot linux at googlemail dot com 2008-08-20 14:57
---
Created an attachment (id=16113)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16113action=view)
Updated doubleint-based patch. DOES NOT PASS TESTSUITE.
--
vda dot linux at googlemail dot com changed
--- Comment #14 from vda dot linux at googlemail dot com 2008-08-20 14:58
---
Created an attachment (id=16114)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16114action=view)
Tree based patch. Passes bootstrap.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28632
--- Comment #15 from vda dot linux at googlemail dot com 2008-08-20 15:07
---
(In reply to comment #13)
Created an attachment (id=16113)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16113action=view) [edit]
Updated doubleint-based patch. DOES NOT PASS TESTSUITE.
I meant does
--- Comment #12 from vda dot linux at googlemail dot com 2008-08-18 13:02
---
Bootstrap with -O2 on current svn fails. Bootstrap with -Os works.
Bootstrap with -O2 on 4.3.1 works.
Instrumented patch emits C code which can be used to test for incorrect VRP
predictions.
I ran
--- Comment #11 from vda dot linux at googlemail dot com 2008-08-11 12:46
---
Created an attachment (id=16050)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16050action=view)
Updated patch. Uses double_int calculations instead of trees.
On Mon, 2008-08-04 at 14:26 +0200, Richard
--- Comment #7 from vda dot linux at googlemail dot com 2008-08-04 11:25
---
Created an attachment (id=16009)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16009action=view)
Updated patch against current svn
This patch is bootstrapping successfully on current gcc svn.
--
vda
--- Comment #8 from vda dot linux at googlemail dot com 2008-08-04 11:28
---
Created an attachment (id=16010)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16010action=view)
Example program which is compiled differently with this patch.
The difference is here:
movl
--- Comment #9 from vda dot linux at googlemail dot com 2008-08-04 11:34
---
Created an attachment (id=16011)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16011action=view)
The instrumented version of the patch
Set $VDA_DEBUG to the name of a file and gcc will append debug
--- Comment #10 from vda dot linux at googlemail dot com 2008-08-04 11:55
---
Created an attachment (id=16012)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16012action=view)
Testcase to be added to testsuite
This program is artificially made to not compile if VRP fails
--- Comment #7 from vda dot linux at googlemail dot com 2008-07-04 20:33
---
4.3.1 have number of memory references down from 115 (4.2.1 had that) but still
can't regain the result of 3.4.3 (21 memory reference). Here is how I checked
this:
# i486-linux-uclibc-gcc -v
...
gcc version
--- Comment #8 from vda dot linux at googlemail dot com 2008-07-04 20:38
---
Created an attachment (id=15856)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15856action=view)
result of gcc-3.4.6 -fomit-frame-pointer serpent.c -O3 -S
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #9 from vda dot linux at googlemail dot com 2008-07-04 20:48
---
The above comment meant to say 4.3.1 have number of memory references down
from 115 _to 48_.
I also attached the best result so far - gcc-3.4.6 with -O3 genarates assembly
with smallest number of memory
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36282
--- Comment #1 from vda dot linux at googlemail dot com 2008-05-20 19:48
---
Simplified case:
#pragma weak __pthread_initialize
extern void *memcpy(void *dest, const void *src, int n);
extern typeof(memcpy) memcpy asm(__GI_memcpy);
void f(void) {}
--
http://gcc.gnu.org/bugzilla
--- Comment #7 from vda dot linux at googlemail dot com 2007-08-31 11:30
---
This is unfortunate, it skews busybox's make bloatcheck results.
In general, I suppose if generated asm sequences are different - one of them
is better (for some definition of better) - gcc generates better
--- Comment #5 from vda dot linux at googlemail dot com 2007-08-28 14:49
---
Created an attachment (id=14125)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14125action=view)
An example of code compiled differently by 4.2.1
It still exists in 4.2.1
testcase-421 contains
Component: regression
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
--- Comment #1 from vda dot linux at googlemail dot com 2007-08-21 12:23
---
Created an attachment (id=14086)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14086action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
--- Comment #2 from vda dot linux at googlemail dot com 2007-08-21 12:26
---
Created an attachment (id=14087)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14087action=view)
assembler output generated by 4.1.1
Sorry, don't have native gcc 4.1.1 at this machine, but have
i486
--- Comment #3 from vda dot linux at googlemail dot com 2007-08-21 12:26
---
Created an attachment (id=14088)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14088action=view)
assembler output generated by 4.2.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33136
--- Comment #2 from vda dot linux at googlemail dot com 2007-07-25 15:05
---
Created an attachment (id=13973)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13973action=view)
Fix: adjust div cost for -Os on i386
Patch was tested with 4.2.1, I guess it will apply to other versions
--- Comment #3 from vda dot linux at googlemail dot com 2007-07-25 15:09
---
Created an attachment (id=13974)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13974action=view)
Auto-generated test program with 15000 constant divs/mods
Test program, bzipped.
Build with
gcc -fomit
--- Comment #5 from vda dot linux at googlemail dot com 2007-07-25 15:22
---
Forgot to mention:
* generator tests signed and unsigned divisions and modulus, both const / x and
x / const, and also tests u = a / b; v = a % b; construct.
* you need to filter gen_test output to weed out
--- Comment #4 from vda dot linux at googlemail dot com 2007-07-25 15:17
---
Created an attachment (id=13975)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13975action=view)
Test program generator
Test program was generated using gen_test.c
--
http://gcc.gnu.org/bugzilla
--- Comment #7 from vda dot linux at googlemail dot com 2007-07-23 20:50
---
I want to apologise. Apparently this behavior (16-byte stack alignment) can be
turned off with an option = I can still have just word-aligned stack. As long
as that still works, I am a more-or-less happy
--- Comment #2 from vda dot linux at googlemail dot com 2007-07-22 10:16
---
Well, gcc 3.4.3 disagrees with you:
# gcc -Os -fomit-frame-pointer -S t.c
# cat t.s
.file t.c
.text
.globl t
.type t, @function
t:
callf
testl %eax, %eax
--- Comment #4 from vda dot linux at googlemail dot com 2007-07-22 21:32
---
I am confused...
How does reserving 12 bytes on stack can help to prevent a segfault?
I can imagine how aligning the stack can help, but here gcc 4.2.1 does
something diffrent.
Maybe just throw an URL to more
--- Comment #15 from vda dot linux at googlemail dot com 2007-07-23 00:03
---
Disadvantages of enforcing 16-bytes stack alignment, continued:
* Code to align the stack is generated when we call a function, even when this
function isn't going to use SSE. Which is ~90% of all functions
--- Comment #27 from vda dot linux at googlemail dot com 2007-07-23 00:06
---
May I point that alternative solution (to align stack _in the function which
needs it_) doesn't crash if called by code generated by old or new gcc, and
also gives smaller, faster and less stack consuming
--- Comment #6 from vda dot linux at googlemail dot com 2007-07-23 00:15
---
Oh *shit*. I see. Why, oh why you didn't go for aligning stack in fuctions
which decided they need to use instructions which require alignment? And ONLY
that functions? Why everyone needs to pay this tax now
--- Comment #16 from vda dot linux at googlemail dot com 2007-07-23 00:48
---
You have it reversed here:
8. Stack alignment is already implemented in Gcc and existing code relies on
it.
No, stack alignment is _not_ in current de-facto i386 Linux ABI and there are
tons of existing
/decrements in trivial code
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
--- Comment #1 from vda dot linux at googlemail dot com 2007-07-21 23:36
---
With 4.2.1 gcc regressed a bit:
gcc -Os -fomit-frame-pointer -S u.c
.file u.c
.text
.globl f
.type f, @function
f:
subl$12, %esp
cmpl$15, 20(%esp
--- Comment #4 from vda dot linux at googlemail dot com 2007-07-21 23:41
---
Tested gcc 4.2.1, generates identical code:
00aa T find_pair
00aa T find_pairB
00aa T find_pairC
00aa T find_pair
00aa T find_pairB
00aa T find_pairC
Also did a diff of .s files
--- Comment #4 from vda dot linux at googlemail dot com 2007-07-22 00:02
---
With t.c being a timing program from comment #3 and serpent.c from attachment,
I build testing program for 3.4.3, 3.4.6 and 4.2.1, -Os and -O3, like this:
ver=NNN
gcc -Os -o serpent-${ver}-Os serpent.c t.c
--- Comment #5 from vda dot linux at googlemail dot com 2007-07-22 00:10
---
Basically, the reason for the regression is that 4.2.1 doesn't figure out how
to use i386 registers efficiently. 3.4.3 was able to do it. Difference in
assembly:
# grep 'mov.*(' serpent-343-O3.s | wc -l
21
--- Comment #3 from vda dot linux at googlemail dot com 2007-03-23 12:00
---
You are right, in current svn it is fixed.
BTW I think I see a bug created by this change: with -Os x86_86 ABI will be
violated - arrays larger than 16 bytes will still be aligned only to 4 bytes
because if's
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31319
--- Comment #1 from vda dot linux at googlemail dot com 2007-03-22 20:07
---
Patch is available here:
http://busybox.net/~vda/mbigdata_align.diff
I cannot attach patch to this bugzilla entry because I get this:
Internal Error
GCC Bugzilla has suffered an internal error. Please save
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30622
--- Comment #3 from vda dot linux at googlemail dot com 2007-01-28 17:25
---
Sorry! Bug in the testcase, should be char *p.
I remember that string literals are special - they decay to const char * OR
to char* depending on context. In this context, it should decay to char*,
and it does
--- Comment #5 from vda dot linux at googlemail dot com 2007-01-28 17:40
---
http://david.tribble.com/text/cdiffs.htm#C99-string-const
In C, string literals have type char[n], but are not modifiable (i.e.,
attempting to modify the contents of a string literal is undefined behavior
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http://gcc.gnu.org/bugzilla
: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386-pc-linux-gnu
http
--- Comment #3 from vda dot linux at googlemail dot com 2006-11-27 23:03
---
Super! Thanks!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30004
*/
--
Summary: suboptimal code generation
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host
--- Comment #1 from vda dot linux at googlemail dot com 2006-11-22 22:57
---
Created an attachment (id=12669)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12669action=view)
Visual comparison of assembly
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950
--- Comment #2 from vda dot linux at googlemail dot com 2006-11-22 22:58
---
Created an attachment (id=12670)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12670action=view)
Complete testcase with .c, .o and .s files
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29950
--- Comment #6 from vda dot linux at googlemail dot com 2006-08-11 14:17
---
Created an attachment (id=12067)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12067action=view)
New version of the patch. 4.1.1 bootstraps with it.
--
vda dot linux at googlemail dot com changed
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host triplet: i386-pc-linux-gnu
GCC target triplet: i386
--- Comment #1 from vda dot linux at googlemail dot com 2006-08-07 11:13
---
Created an attachment (id=12035)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12035action=view)
The patch relative to 4.1.1
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28632
--- Comment #2 from vda dot linux at googlemail dot com 2006-08-07 11:14
---
Created an attachment (id=12036)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12036action=view)
Test program which demonstrates how VRP generates simpler code
--
http://gcc.gnu.org/bugzilla
--- Comment #3 from vda dot linux at googlemail dot com 2006-08-07 11:26
---
Differences in *.vrp (-fdump-tree-vrp output) and assembly generated
with stock 4.1.1 and with patched one out of test program test_vrp.c
--- test_vrp.c.t36-411org.vrp 2006-08-06 22:40:04.0 +0200
--- Comment #14 from vda dot linux at googlemail dot com 2006-08-04 18:14
---
But since these sort of transformations are of
a very mathematical nature, I trust the author of the
suggested changes has proven the algorithms?
I did not write a paper about it, but I think I have
--- Comment #12 from vda dot linux at googlemail dot com 2006-08-03 17:06
---
Created an attachment (id=12005)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12005action=view)
Alternative algorithm v. 3
Formatting fixes mostly
--
vda dot linux at googlemail dot com changed
--- Comment #9 from vda dot linux at googlemail dot com 2006-08-02 19:05
---
Thanks for the link to .pdf! Who's Tege? And his email address is ...?
Ok. This new version of the patch is working for signed divisions too, and is
giving the results which are always same or better than old
--- Comment #10 from vda dot linux at googlemail dot com 2006-08-02 19:05
---
Created an attachment (id=12000)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12000action=view)
Alternative algorithm v. 2
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417
--- Comment #4 from vda dot linux at googlemail dot com 2006-07-30 13:35
---
Created an attachment (id=11971)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11971action=view)
Use alternative algorithm if it gives better results
New algorithm lives in separate function
--- Comment #5 from vda dot linux at googlemail dot com 2006-07-30 13:37
---
Created an attachment (id=11972)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11972action=view)
Test program
Compile with -O2 -S to see the assembly.
Compile with -Os and run to check the correctness
--- Comment #6 from vda dot linux at googlemail dot com 2006-07-30 13:38
---
Patched versus stock gcc-4.1.1 on this code
unsigned v;
void f9188_mul365384439_shift27(unsigned A) { v = A/(unsigned)1577682821; }
is:
# diff -u suboptimal-411-O2.s suboptimal-411-O2-fixed.s
--- suboptimal
--- Comment #7 from vda dot linux at googlemail dot com 2006-07-30 13:43
---
Created an attachment (id=11973)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11973action=view)
Random tester
Randomly chooses a/b and compares gcc patch code results with code which was
previously
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
GCC build triplet: i386-pc-linux-gnu
GCC host
--- Comment #1 from vda dot linux at googlemail dot com 2006-07-25 14:45
---
Created an attachment (id=11934)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11934action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28481
--- Comment #3 from vda dot linux at googlemail dot com 2006-07-25 17:18
---
With this test program:
#include sys/time.h
#include stdio.h
typedef unsigned u32;
struct serpent_ctx { u32 expkey[132]; };
void serpent_encrypt(void *ctx, u32 *dst, const u32 *src);
u32 v[4],u[4];
struct
--- Comment #3 from vda dot linux at googlemail dot com 2006-07-19 16:24
---
I instrumented choose_multiplier(). When called like this:
choose_multiplier(d=1577682821,n=32,precision=32),
it returns *post_shift_ptr=31,multiplier=5846151023
whereas optimal one is *post_shift_ptr=27
ReportedBy: vda dot linux at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28417
--- Comment #1 from vda dot linux at googlemail dot com 2006-07-18 08:40
---
I didn't look too close at choose_multiplier(), yet.
If anybody will work upon it in order to make it better,
this is the routine which prints values 'K' and 'bits'
so that
(A*K)bits == A/B
is true
--- Comment #2 from vda dot linux at googlemail dot com 2006-07-18 12:06
---
Pseudo-code to help in reading above code:
void fastdiv_params(unsigned B, unsigned max_A)
{
L = (max_unsigned_long_long/max_unsigned - 1) * B;
L = largest_pow2_smaller_or_eq_to(L
gnu dot org
ReportedBy: vda dot linux at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28405
--- Comment #4 from vda dot linux at googlemail dot com 2006-07-17 09:09
---
Wow, this looks nice, good job! Thanks!
--
vda dot linux at googlemail dot com changed:
What|Removed |Added
--- Comment #11 from vda dot linux at googlemail dot com 2006-07-17 10:32
---
Andrew, I must be extremely dumb today. I looked in the source and for the life
of me, I can't see where that optimization is done. I even generated a
2.6.1-2.6.1 diff where it was added and still don't see
Version: 4.2.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vda dot linux at googlemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28395
--- Comment #1 from vda dot linux at googlemail dot com 2006-07-16 15:45
---
Created an attachment (id=11898)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11898action=view)
find_fast_div.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28395
--- Comment #2 from vda dot linux at googlemail dot com 2006-07-16 15:46
---
Created an attachment (id=11899)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11899action=view)
fast_div_bench.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28395
--- Comment #3 from vda dot linux at googlemail dot com 2006-07-16 15:46
---
Created an attachment (id=11900)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11900action=view)
find_fast_div_random.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28395
--- Comment #7 from vda dot linux at googlemail dot com 2006-07-16 16:22
---
Oh my.
It looks that use of -Os played a joke on me. gcc 3.4.3 -Os uses a division
instruction, even though it results in slower and _also bigger_ code.
Maybe it makes sense to enable this optimization
--- Comment #9 from vda dot linux at googlemail dot com 2006-07-16 18:47
---
The test program below shows that in this case doing division with div insn
takes more instructions than with mul+shift.
Also mul+shift path has absolutely useless movl %edx, %eax insn, shaving that
will make
--- Comment #10 from vda dot linux at googlemail dot com 2006-07-16 18:54
---
gcc-4.1.1 differs only by insterting one more useless insn:
movl$-858993459, %eax
mull8(%esp)
movl%edx, %eax
+ xorl%edx, %edx
shrl$3, %eax
85 matches
Mail list logo
