[PATCH/AARCH64] Fix gcc.c-torture/compile/pr37433.c for AARCH64:ILP32.

[PATCH/AARCH64] Fix gcc.c-torture/compile/pr37433.c for AARCH64:ILP32.

[Andrew Pinski]

[-- Attachment #1: Type: text/plain, Size: 510 bytes --]

The problem here is that we get a symbol_ref which is SImode but for
the sibcall patterns we only match symbol_refs which use DImode.  I
added a new testcase that tests the non-value sibcall pattern too.

OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.

Thanks,
Andrew Pinski

ChangeLog:

    * config/aarch64/aarch64.md (sibcall): Force call
    address to be DImode for ILP32.
    (sibcall_value): Likewise.

testsuite/ChangeLog:
    * gcc.c-torture/compile/pr37433-1.c: New testcase.

[-- Attachment #2: fixpr37433-aarch64-ilp32.diff.txt --]
[-- Type: text/plain, Size: 2122 bytes --]

commit e72320f54d1c6ed6f2324a3faaad02175c83887b
Author: Andrew Pinski <apinski@cavium.com>
Date:   Sun Feb 8 23:05:01 2015 +0000

    Fix gcc.c-torture/compile/pr37433.c for AARCH64:ILP32.
    
    The problem here is that we get a symbol_ref which is SImode
    but for the sibcall patterns we only match symbol_refs which
    use DImode.
    
    OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.
    
    Thanks,
    Andrew Pinski
    
    * config/aarch64/aarch64.md (sibcall): Force operands[0]'s
    address to be DImode for ILP32.
    (sibcall_value): Likewise.
    
    * gcc.c-torture/compile/pr37433-1.c: New testcase.

diff --git a/gcc/config/aarch64/aarch64.md b/gcc/config/aarch64/aarch64.md
index 1f4169e..05240ba 100644
--- a/gcc/config/aarch64/aarch64.md
+++ b/gcc/config/aarch64/aarch64.md
@@ -687,6 +687,11 @@
        && (GET_CODE (XEXP (operands[0], 0)) != SYMBOL_REF))
      XEXP (operands[0], 0) = force_reg (Pmode, XEXP (operands[0], 0));
 
+    if (TARGET_ILP32
+	&& GET_CODE (XEXP (operands[0], 0)) == SYMBOL_REF
+	&& GET_MODE (XEXP (operands[0], 0)) == SImode)
+      XEXP (operands[0], 0) = convert_memory_address (DImode,
+						      XEXP (operands[0], 0));
     if (operands[2] == NULL_RTX)
       operands[2] = const0_rtx;
 
@@ -717,6 +722,12 @@
        && (GET_CODE (XEXP (operands[1], 0)) != SYMBOL_REF))
      XEXP (operands[1], 0) = force_reg (Pmode, XEXP (operands[1], 0));
 
+    if (TARGET_ILP32
+	&& GET_CODE (XEXP (operands[1], 0)) == SYMBOL_REF
+	&& GET_MODE (XEXP (operands[1], 0)) == SImode)
+      XEXP (operands[1], 0) = convert_memory_address (DImode,
+						      XEXP (operands[1], 0));
+
     if (operands[3] == NULL_RTX)
       operands[3] = const0_rtx;
 
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr37433-1.c b/gcc/testsuite/gcc.c-torture/compile/pr37433-1.c
new file mode 100644
index 0000000..322c167
--- /dev/null
+++ b/gcc/testsuite/gcc.c-torture/compile/pr37433-1.c
@@ -0,0 +1,11 @@
+void regex_subst(void)
+{
+  const void *subst = "";
+  (*(void (*)(int))subst) (0);
+}
+
+void foobar (void)
+{
+  int x;
+  (*(void (*)(void))&x) ();
+}

Re: [PATCH/AARCH64] Fix gcc.c-torture/compile/pr37433.c for AARCH64:ILP32.

[Marcus Shawcroft]

On 9 February 2015 at 05:41, Andrew Pinski <pinskia@gmail.com> wrote:
> The problem here is that we get a symbol_ref which is SImode but for
> the sibcall patterns we only match symbol_refs which use DImode.  I
> added a new testcase that tests the non-value sibcall pattern too.
>
> OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.


Why are we being given an SI mode expression here, I would have
thought we should get FUNCTION_MODE or Pmode ?

Cheers
/Marcus

> Thanks,
> Andrew Pinski
>
> ChangeLog:
>
>     * config/aarch64/aarch64.md (sibcall): Force call
>     address to be DImode for ILP32.
>     (sibcall_value): Likewise.
>
> testsuite/ChangeLog:
>     * gcc.c-torture/compile/pr37433-1.c: New testcase.

Re: [PATCH/AARCH64] Fix gcc.c-torture/compile/pr37433.c for AARCH64:ILP32.

[Jeff Law]

On 02/17/15 08:31, Marcus Shawcroft wrote:
> On 9 February 2015 at 05:41, Andrew Pinski <pinskia@gmail.com> wrote:
>> The problem here is that we get a symbol_ref which is SImode but for
>> the sibcall patterns we only match symbol_refs which use DImode.  I
>> added a new testcase that tests the non-value sibcall pattern too.
>>
>> OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.
>
>
> Why are we being given an SI mode expression here, I would have
> thought we should get FUNCTION_MODE or Pmode ?
Agreed.  I guess something might be doing something weird and generating 
the SImode from POINTER_SIZE.

I was going to look for that since it seemed so weird, but I've been 
unable to reproduce this failure with the tip of the trunk or a variety 
of trees from around the date this bug was reported.

Andrew, is it possible you had some local changes in your tree that were 
responsible for getting the bogus mode?  What were the flags you used to 
trigger the failure?

I tried it with -mabi=ilp32 using the standard c-torture options.

jeff

Re: [PATCH/AARCH64] Fix gcc.c-torture/compile/pr37433.c for AARCH64:ILP32.

[Andrew Pinski]

On Tue, Feb 24, 2015 at 9:18 PM, Jeff Law <law@redhat.com> wrote:
> On 02/17/15 08:31, Marcus Shawcroft wrote:
>>
>> On 9 February 2015 at 05:41, Andrew Pinski <pinskia@gmail.com> wrote:
>>>
>>> The problem here is that we get a symbol_ref which is SImode but for
>>> the sibcall patterns we only match symbol_refs which use DImode.  I
>>> added a new testcase that tests the non-value sibcall pattern too.
>>>
>>> OK?  Bootstrapped and tested on aarch64-linux-gnu with no regressions.
>>
>>
>>
>> Why are we being given an SI mode expression here, I would have
>> thought we should get FUNCTION_MODE or Pmode ?
>
> Agreed.  I guess something might be doing something weird and generating the
> SImode from POINTER_SIZE.
>
> I was going to look for that since it seemed so weird, but I've been unable
> to reproduce this failure with the tip of the trunk or a variety of trees
> from around the date this bug was reported.

Weird as I did not have any changes in my tree at the time I reported
it.  I was bootstrapping a clean trunk.

>
> Andrew, is it possible you had some local changes in your tree that were
> responsible for getting the bogus mode?  What were the flags you used to
> trigger the failure?


I will try again, I might have messed up something but I knew I saw
this at one time and even when I was patching the sources myself.

Thanks,
Andrew Pinski

>
> I tried it with -mabi=ilp32 using the standard c-torture options.
>
> jeff
>
>