--- Comment #19 from tege-gcc at swox dot com 2008-02-24 20:39 ---
I believe the local call optimization is triggered when compiling
__gmp_randget_mt() because its only call is to a function the compiler
determines to be local. (One can easily untrigger the optimization by
inserting
--- Comment #13 from tege-gcc at swox dot com 2008-02-23 17:09 ---
Created an attachment (id=15214)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15214action=view)
This is a minimized version of the original faling code.
I understand the reasoning about local calls. The problem
--- Comment #16 from tege-gcc at swox dot com 2008-02-23 18:27 ---
I don't know how a PLT entry looks like. They use the object format
macho, of which I know nothing.
Note that the new testcase does not have any recursive calls.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #2 from tege-gcc at swox dot com 2008-02-21 13:49 ---
Created an attachment (id=15196)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15196action=view)
Alignment test
This is not a strictly correct test case, it may fail even if
the compiler aligns the stack properly
--- Comment #4 from tege-gcc at swox dot com 2008-02-21 13:57 ---
(From update of attachment 15196)
#include stdlib.h
long align;
foo (int flag)
{
int variable;
if (flag == 0)
return (((long)variable ^ align) 0xf);
align = (long)variable;
foo (flag - 1);
}
main
--- Comment #5 from tege-gcc at swox dot com 2008-02-21 14:01 ---
The attachment is not the right file.
I tried to edit it but I cannot find out how to do it.
The proper test case is in the comment before this one.
Sorry, I am bugzilla challenged.
--
http://gcc.gnu.org/bugzilla
--- Comment #3 from tege-gcc at swox dot com 2008-02-21 13:53 ---
Testcase? Because we do align it for both x86_64-* and i386-darwin.
Well, not as mandated in the 64-bit ABI.
Now the SVSV i386 ABI says it should be aligned at 4 (word)
bytes boundary.
This is hardly
--- Comment #7 from tege-gcc at swox dot com 2008-02-21 22:01 ---
Sorry, but you ought to read and understand what I write before
you comment, otherwise it becomes rather pointless.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
: 4.2.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tege-gcc at swox dot com
GCC build triplet: i386-apple-darwin8.11.1
GCC host triplet: i386-apple-darwin8.11.1
GCC
Version: 4.2.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tege-gcc at swox dot com
GCC target triplet: i386-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #2 from tege-gcc at swox dot com 2007-12-13 10:52 ---
It does make sense to bluff somewhat about the costs of the few 3
operand instructions that we have:
lea
mul const, regx, regy
Exactly what cost to assign is not obvious. I think the nominal
cost - epsilon
.
--
Summary: Typo in gcc/config/i386.c (ix86_rtx_costs)
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tege-gcc at swox dot
--- Comment #1 from tege-gcc at swox dot com 2007-12-13 07:21 ---
This bug is present also in the svn head.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34451
: critical
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tege-gcc at swox dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: ia64-redhat-linux, powerpc-apple-darwin8
GCC host triplet: ia64-redhat
14 matches
Mail list logo
