This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PING: PATCH: PR middle-end/45234: [4.4/4.5/4.6 Regression] ICE in expand_call, at calls.c:2845 when passing aligned function argument from unaligned stack after alloca
On Wed, Sep 22, 2010 at 11:56 PM, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Sep 22, 2010 at 03:01:49PM -0700, H.J. Lu wrote:
>> 2010-09-22 ?H.J. Lu ?<hongjiu.lu@intel.com>
>>
>> ? ? ? PR middle-end/45234
>> ? ? ? * calls.c (expand_call): Don't call check all variable sized
>> ? ? ? adjustments are multiple of preferred stack boundary after
>> ? ? ? stack alignment when calling builtin functions.
>
>> --- a/gcc/calls.c
>> +++ b/gcc/calls.c
>> @@ -2369,7 +2369,7 @@ expand_call (tree exp, rtx target, int ignore)
>>
>> ? ?preferred_unit_stack_boundary = preferred_stack_boundary / BITS_PER_UNIT;
>>
>> - ?if (SUPPORTS_STACK_ALIGNMENT)
>> + ?if (SUPPORTS_STACK_ALIGNMENT && fndecl && !DECL_IS_BUILTIN (fndecl))
>> ? ? ?{
>> ? ? ? ?/* All variable sized adjustments must be multiple of preferred
>> ? ? ? ?stack boundary. ?Stack alignment may change preferred stack
>
> I'd like to hear explanation on why you think this is the right approach.
> What is so special about builtins in this case? ?If they are to be expanded
> as calls instead of expanded inline, I'd say they behave like any other
> call.
>
> Isn't the problem instead with nested expand_calls (which is happening
> in the testcase that is now failing)? ?Not sure if we still ever TER const/pure
> calls into other call arguments or not[*], so if that is possible for arbitrary
> calls, or the problem is just memcpy emitted through
> emit_block_move_hints with method BLOCK_OP_CALL_PARM.
> I admit I haven't debugged the original PR45234 testcase, so I don't know
> why exactly is your patch needed and thus why it isn't needed when expanding
> the call param move calls.
>
> [*] In
> long long foo (int, int) __attribute__((const));
> int bar (int, int, long long, int, int);
> int baz (int x)
> {
> ?return bar (2, 3, foo (4, 5), 6, 7) + 1;
> }
> foo is now evaluated before starting the pushes with -m32 -O2 -march=i586.
> I vaguely remember const/pure calls used to be TERed at some point, but
> perhaps I'm just using a wrong testcase.
>
I didn't find exactly why. From what I can see, builtin functions are
treated differently from the normal ones.
--
H.J.