--- Comment #26 from hjl dot tools at gmail dot com 2008-06-21 16:00
---
I am closing it as an dup for PR 36584. Please reoopen it if it isn't
fixed after
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01361.html
is checked in.
*** This bug has been marked as a duplicate of 36584 ***
--- Comment #25 from ubizjak at gmail dot com 2008-06-21 15:49 ---
The testcase at http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01361.html will
fail for -mfpmath=sse on x86_32.
Related PR is PR 36584.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
--- Comment #24 from jh at suse dot cz 2008-02-26 09:43 ---
Subject: Re: Stack not aligned at mod 16 byte boundary in x86_64 code
> I guess we need
> 1) Get the patch to check overwritability of body to mainline and branch,
> since
> it is quite wrong to optimize based on knowledge of
--- Comment #23 from hubicka at gcc dot gnu dot org 2008-02-26 09:31
---
I guess we need
1) Get the patch to check overwritability of body to mainline and branch, since
it is quite wrong to optimize based on knowledge of body that might be replaced
2) Figure out how to get Apple's linke
--- Comment #22 from pinskia at gcc dot gnu dot org 2008-02-25 19:16
---
This is true even for -fPIC case. So in this case, the linker and the compiler
are saying two different things even though I do know for PPC darwin this is
always the case.
So maybe in the end this is a bug in th
--- Comment #21 from pinskia at gcc dot gnu dot org 2008-02-25 19:15
---
The real issue is that darwin's back-end says functions that are defined in the
TU are always binds local so they can be called directly.
So I guess a patch to darwin.c is needed.
--
pinskia at gcc dot gnu dot
--- Comment #20 from jh at suse dot cz 2008-02-24 20:49 ---
Subject: Re: Stack not aligned at mod 16 byte boundary in x86_64 code
Hi,
what about this patch. There seems to be availablity check missing
earlier in code. This way GCC will always align calls to functions that
might be ov
--- 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 a
--- Comment #18 from matz at gcc dot gnu dot org 2008-02-24 19:52 ---
Umm sorry. I meant the __gmp_mt_recalc_buffer function is global in my last
comment.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35271
--- Comment #17 from matz at gcc dot gnu dot org 2008-02-24 19:50 ---
Honza: No recursion is involved here. I guess (Tege: correct me if I'm wrong)
that already the first call to __gmp_mt_recalc_buffer() from
__gmp_randget_mt() will segfault, as the first call obviously will end up
in t
--- 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=35271
--- Comment #15 from hubicka at gcc dot gnu dot org 2008-02-23 18:10
---
Still, can I ask how does the PLT entry of Darwin look like? It seems a bit
weird that recursive call that should not trigger lazy binding will get into
code relying on the alignment.
Or are some kind of aliases i
--- Comment #14 from hubicka at gcc dot gnu dot org 2008-02-23 18:05
---
I see. It is quite pity that Darwin's dynamic linker insist on the alignment.
I guess it would be worthwhile to try to tell GCC to optimize those calls as
local: calling overhead of recursive functions is quite ex
--- 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=15214&action=view)
This is a minimized version of the original faling code.
I understand the reasoning about local calls. The problem
--- Comment #12 from matz at gcc dot gnu dot org 2008-02-23 16:15 ---
In fact I'm now convinced of the opposite, the testcases here don't show any
problem. The non-alignment of RSP at function entry in these cases is not a
bug. See the discussions at
http://gcc.gnu.org/ml/gcc-patches
--- Comment #11 from matz at gcc dot gnu dot org 2008-02-23 14:08 ---
FWIW, Torbjorn: I agree with Honza that it would be very good to see the
original testcase that segfaults on darwin. The testcases here are all of
the type where it's questionable if the behaviour is really wrong.
Th
--- Comment #10 from hubicka at gcc dot gnu dot org 2008-02-23 12:57
---
Hi,
as I added to the gcc-patches thread, I think GCC is valid to optimize stack
alignment on the reduced testcase and it is precisely what is supposed to be
done by the code Michael disabled. ABI is not strict abo
--- Comment #9 from matz at gcc dot gnu dot org 2008-02-23 00:40 ---
Mine, have patch.
--
matz at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unas
--- Comment #8 from matz at gcc dot gnu dot org 2008-02-22 23:40 ---
I can confirm this, the code in foo is definitely wrong. When I compile
the (standard compliant, unlike the example from comment #4) with 4.2 or
4.3 on x86-64, with -O or -O2 it breaks:
% cat foo.c
long align;
int fo
19 matches
Mail list logo
