Re: [PATCH 1/1] sparc: support for -mmisalign in the SPARC M8

[David Miller]

From: Qing Zhao 
Date: Thu, 3 Aug 2017 10:37:15 -0500

> all the special handling on STRICT_ALIGNMENT or
> SLOW_UNALIGNMENT_ACCESS in these codes have the following common
> logic:
> 
> if the memory access is known to be not-aligned well during
> compilation time, if the targeted platform does NOT support faster
> unaligned memory access, the compiler will try to make the memory
> access aligned well. Otherwise, if the targeted platform supports
> faster unaligned memory access, it will leave the compiler-time
> known not-aligned memory access as it, later the hardware support
> will kicked in for these unaligned memory access.
> 
> this behavior is consistent with the high level definition of 
> STRICT_ALIGNMENT. 

That's exactly the problem.

What you want with this M8 feature is simply to let the compiler know
that if it is completely impossible to make some memory object
aligned, then the cpu can handle this with special instructions.

You still want the compiler to make the effort to align data when it
can because the accesses will be faster than if it used the unaligned
loads and stores.

This is incredibly important for on-stack objects.

Re: [PATCH 1/1] sparc: support for -mmisalign in the SPARC M8

[David Miller]

From: Qing Zhao 
Date: Wed, 2 Aug 2017 14:41:51 -0500

> so, could you please specify what kind of side effects will have
> when set STRICT_ALIGNMENT to true on TARGET_MISALIGN?

Why don't you read the code rather than just relying upon what
high level description is given by the documentation instead?

Thanks.

Re: [PATCH 1/1] sparc: support for -mmisalign in the SPARC M8

[David Miller]

From: qinzhao 
Date: Wed,  2 Aug 2017 10:27:51 -0500

> This patch adds support to GCC for the misaligned load/store
> instructions introduced in the Oracle SPARC Architecture 2017 and
> implemented by the SPARC M8 processor.
> 
> A new command line option -mmisaligned is added, that activates the
> usage of the new instructions.
> 
> The SPARC backend is modified to use the misaligned load/store
> instructions when loading/storing data from/to addresses that are
> known to be misaligned at compile time (such as in packed structs).
> 
> New tests are added to check that the proper instructions are used
> when loading and storing from/to packed structs.
> 
> The GCC manual is expanded to cover the new command-line option.

STRICT_ALIGNMENT has a lot of implications.

I think just because we happen to have misaligned loads and stores
available doesn't mean we want all of the side effects associated
with STRICT_ALIGNMENT being true.

Re: A potential bug in lra-constraints.c for special_memory_constraint?

[David Miller]

From: Qing Zhao 
Date: Wed, 12 Jul 2017 08:49:52 -0500

> and it also clearly mentioned that “specially aligned memory might
> use this constraint”.

It guarantees the achieve the opposite of what you are trying to do.

That is, it can be used to guarantee that something is aligned to a
multiple of X or greater.

What you want is to know that something is guaranteed to be
aligned less strongly that X.  And that invariant is not
provided for.

Re: A potential bug in lra-constraints.c for special_memory_constraint?

[David Miller]

From: Eric Botcazou 
Date: Wed, 12 Jul 2017 01:19:03 +0200

>> we add this new constraint as:
>> 
>> ;; We need a special memory constraint for the misaligned memory access
>> ;; This is only for TARGET_MISALIGN target
>> (define_special_memory_constraint "B"
>>  "Memory reference whose address is misaligned"
>>  (and (match_code "mem")
>>   (match_test "TARGET_MISALIGN")
>>   (match_test "memory_is_misaligned (op, mode)”)))
>> 
>> the routine “memory_is_misaligned” is a compile-time check to see whether
>> the address is known to be misaligned or not. only for compile-time KNOWN
>> misaligned memory access, we will use misaligned load/store insns provided
>> by the new processor for the memory access.
>> 
>> and then put this new constraints to sparc.md as:
>> 
>> (define_insn "*movdi_insn_sp64"
>>   [(set (match_operand:DI 0 "nonimmediate_operand" "=r,r,r,r, B, m,
>> r,*e,?*e,?*e,?W,b,b") (match_operand:DI 1 "input_operand"   
>> "rI,N,B,m,rJ,rJ,*e, r, *e,  W,*e,J,P"))]
>> 
>> 
>> NOTE, the 4th constraints for this insn is “B, rJ”,  if the operands match
>> this constraint, then.  misaligned store insns will be generated for the
>> misaligned memory access instead of regular store.
> 
> OK, but what happens in the end?  What's the failure mode?  Internal compiler 
> error, impossible reloading, wrong code, suboptimal code, etc?

Yeah I'm still hopelessly confused what the problem is too.

As far as I understand it, the unaligned loads and stores present in
the M8 can be used just fine on aligned data.  It's just not efficient
(11 cycle latency instead of 3).

Perhaps they are just trying to only match the constraints for the
the unaligned loads and stores when absolutely necessary.

If so, I really really wish they had said this from the beginning. :)

Re: [PATCH V2 0/7] Support for the SPARC M8 cpu

[David Miller]

From: jose.march...@oracle.com (Jose E. Marchesi)
Date: Fri, 07 Jul 2017 12:53:37 +0200

> I will be committing to svn in both trunk and the gcc 7 branch.

Thank you for doing this work.

Re: [PATCH-v3] [SPARC] Add a workaround for the LEON3FT store-store errata

[David Miller]

From: Daniel Cederman 
Date: Thu, 29 Jun 2017 17:15:43 +0200

>> I'm not thrilled with this, it's undocumented, the other workaround
>> don't have
>> it and I don't think that we really need it.
> 
> The B2BST errata workaround requires more changes to assembler
> routines commonly used by operating systems, such as for example
> register window handling, than what the UT699 workaround needed. It
> would be nice to have a way to only enable these modification when the
> -mfix- flag is used. The alternative would be to provide a define
> directly on the compiler command line in conjunction with -mfix
> flag. But if more changes are required later on it would be good to
> have the define more closely tied to the flag to minimize the number
> of changes to Makefiles and etc.

Personally, I have never seen compiler based CPP defines as ever being
useful for tailoring OS assembler code.  Ever.

In most cases you will want to support several families of CPUs and
therefore sort out the individual cpu support assembler routines
internally in the kernel sources.

Re: [libcilkrts] Fix 64-bit SPARC/Linux port

[David Miller]

From: Eric Botcazou 
Date: Fri, 23 Jun 2017 19:34:54 +0200

> Since libcilkrts was ported to the SPARC architecture by Rainer, running the 
> testsuite on SPARC/Linux in 64-bit mode with sufficiently high parallelim has 
> resulted in an almost guaranteed kernel panic.
> 
> Fixed thusly, tested on SPARC64/Linux and SPARC/Solaris., applied to mainline 
> and 7 branch.  Rainer kindly agreed to submit a copy of the fix to the master 
> repository when he gets a chance.

Ok, but the kernel shouldn't crash because of a bad stack pointer.

The fact that an unaligned stack access causes the problem is a good
clue.  Thanks, I'll try to look into this.

Re: [PATCH] [SPARC] Add a workaround for the LEON3FT store-store errata

[David Miller]

From: Daniel Cederman 
Date: Wed, 21 Jun 2017 15:27:51 +0200

> I have modified the patch so that the workaround is enabled by using
> either mfix-ut699, -mfix-ut700, or -mfix-gr712rc.

Eric, does Daniel's patch meet your requirements now?

Re: [PATCH] [SPARC] Add a workaround for the LEON3FT store-store errata

[David Miller]

From: Eric Botcazou 
Date: Tue, 20 Jun 2017 21:19:37 +0200

>> I'm fine with this change.
> 
> I disagree, the existing policy is to avoid switches like -mfix-b2bst and use 
> -mfix- where  is a CPU (here  could be ut699e or ut700).

Ok, I was not aware of that policy.  But this should be easy for the
submitter to fix.

Re: [PATCH] [SPARC] Add a workaround for the LEON3FT store-store errata

[David Miller]

From: Sebastian Huber 
Date: Tue, 20 Jun 2017 07:55:33 +0200

> would someone mind reviewing this patch please. It was already sent
> for review on January this year and got no attention. Now we are in a
> different development stage.
> 
> https://gcc.gnu.org/ml/gcc-patches/2017-01/msg01354.html

I'm fine with this change.

Re: Fix gcc.c-torture/execute/20101011-1.c on 64-bit Niagara

[David Miller]

From: Eric Botcazou 
Date: Wed, 14 Jun 2017 12:40:57 +0200

> This fixes
> 
> FAIL: gcc.c-torture/execute/20101011-1.c   -O2  execution test
> FAIL: gcc.c-torture/execute/20101011-1.c   -O2 -flto -fno-use-linker-plugin -
> flto-partition=none  execution test
> FAIL: gcc.c-torture/execute/20101011-1.c   -O2 -flto -fuse-linker-plugin -fno-
> fat-lto-objects  execution test
> FAIL: gcc.c-torture/execute/20101011-1.c   -O3 -g  execution test
> FAIL: gcc.c-torture/execute/20101011-1.c   -Os  execution test
> 
> on 64-bit SPARC with -mcpu=niagara.  There is exactly the same guard a few 
> lines below for the DIV case.
> 
> Tested on SPARC64/Linux and x86-64/Linux, applied on the mainline.

Thanks for fixing this.

Re: [PATCH][SPARC] PR target/80968 Prevent stack loads in return delay slot.

[David Miller]

From: Eric Botcazou 
Date: Mon, 12 Jun 2017 11:27:10 +0200

>> I do not see a direct gen_return happening in function.c in the gcc-7
>> branch.
>> 
>> Is it somewhere else?
> 
> There is a call from force_nonfallthru_and_redirect in cfgrtl.c AFAICS.
> 
> So the code generated for your testcase is less optimized with GCC 7 and 
> later 
> than with GCC 6 and earlier?

Ok, I see.

That invocation from cfgrtl.c is not triggered for my testcase in gcc-7 and
later.

I'll update the return pattern in the gcc-7 branch and mainline in order to
cover all possible cases.

Re: [PATCH][SPARC] PR target/80968 Prevent stack loads in return delay slot.

[David Miller]

From: Eric Botcazou 
Date: Fri, 09 Jun 2017 22:13:20 +0200

>> Eric, after some more testing it turns out that we need something
>> more for gcc-5 and gcc-6 to cover all cases.
> 
> Hmm, yes, I should have thought of that...
> 
>> The problem is that before gcc-7, the compiler can emit return
>> instructions directly without going through the epilogue expander.
> 
> That should also be true with GCC 7 and later, no?

I do not see a direct gen_return happening in function.c in the gcc-7
branch.

Is it somewhere else?

Re: [PATCH][SPARC] PR target/80968 Prevent stack loads in return delay slot.

[David Miller]

From: David Miller <da...@davemloft.net>
Date: Tue, 06 Jun 2017 15:02:55 -0400 (EDT)

> From: David Miller <da...@davemloft.net>
> Date: Mon, 05 Jun 2017 20:54:46 -0400 (EDT)
> 
>> From: Eric Botcazou <ebotca...@adacore.com>
>> Date: Tue, 06 Jun 2017 00:02:06 +0200
>> 
>>>> That seems to work as well, following is going through a testsuite
>>>> run right now:
>>>> 
>>>> 
>>>> [PATCH] sparc: Fix stack references in return delay slot.
>>>> 
>>>> gcc/
>>>> 
>>>>PR target/80968
>>>>* config/sparc/sparc.c (sparc_expand_prologue): Emit frame
>>>>blockage if function uses alloca.
>>> 
>>> Probably worth applying on all active branches I'd think.
>> 
>> I agree, this is a really nasty bug.
>> 
>> I'll do that after some more testing.
> 
> This is now done, thanks again.

Eric, after some more testing it turns out that we need something
more for gcc-5 and gcc-6 to cover all cases.

The problem is that before gcc-7, the compiler can emit return
instructions directly without going through the epilogue expander.

So I have to add the frame barrier emission to our return expander as
well, which I will work on right now.

Just FYI...

Re: [PATCH][SPARC] PR target/80968 Prevent stack loads in return delay slot.

[David Miller]

From: David Miller <da...@davemloft.net>
Date: Mon, 05 Jun 2017 20:54:46 -0400 (EDT)

> From: Eric Botcazou <ebotca...@adacore.com>
> Date: Tue, 06 Jun 2017 00:02:06 +0200
> 
>>> That seems to work as well, following is going through a testsuite
>>> run right now:
>>> 
>>> 
>>> [PATCH] sparc: Fix stack references in return delay slot.
>>> 
>>> gcc/
>>> 
>>> PR target/80968
>>> * config/sparc/sparc.c (sparc_expand_prologue): Emit frame
>>> blockage if function uses alloca.
>> 
>> Probably worth applying on all active branches I'd think.
> 
> I agree, this is a really nasty bug.
> 
> I'll do that after some more testing.

This is now done, thanks again.

Re: [PATCH][SPARC] PR target/80968 Prevent stack loads in return delay slot.

[David Miller]

From: Eric Botcazou 
Date: Tue, 06 Jun 2017 00:02:06 +0200

>> That seems to work as well, following is going through a testsuite
>> run right now:
>> 
>> 
>> [PATCH] sparc: Fix stack references in return delay slot.
>> 
>> gcc/
>> 
>>  PR target/80968
>>  * config/sparc/sparc.c (sparc_expand_prologue): Emit frame
>>  blockage if function uses alloca.
> 
> Probably worth applying on all active branches I'd think.

I agree, this is a really nasty bug.

I'll do that after some more testing.

Eric, thanks for reviewing and your advice to use frame blockage!

Re: [PATCH][SPARC] PR target/80968 Prevent stack loads in return delay slot.

[David Miller]

From: Eric Botcazou 
Date: Sun, 04 Jun 2017 10:32:47 +0200

>> This is an attempt to fix PR target/80968.  This bug has existed
>> basically forever.
>> 
>> The stack_tie sequence seems to be how other targets deal with this
>> issue.  I only emit this when alloca is used.  If there are other
>> conditions that potentially would necessitate such a barrier, just let
>> me know.
> 
> See my comment in the audit trail about the stack tie approach, let's just 
> emit a frame_blockage instead.

That seems to work as well, following is going through a testsuite
run right now:


[PATCH] sparc: Fix stack references in return delay slot.

gcc/

PR target/80968
* config/sparc/sparc.c (sparc_expand_prologue): Emit frame
blockage if function uses alloca.

gcc/testsuite/

* gcc.target/sparc/sparc-ret-3.c: New test.
---
 gcc/config/sparc/sparc.c |  3 ++
 gcc/testsuite/gcc.target/sparc/sparc-ret-3.c | 53 
 2 files changed, 56 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/sparc/sparc-ret-3.c

diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index 6dfb269..95a64a4 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -5792,6 +5792,9 @@ sparc_expand_epilogue (bool for_eh)
 {
   HOST_WIDE_INT size = sparc_frame_size;
 
+  if (cfun->calls_alloca)
+emit_insn (gen_frame_blockage ());
+
   if (sparc_n_global_fp_regs > 0)
 emit_save_or_restore_global_fp_regs (sparc_frame_base_reg,
 sparc_frame_base_offset
diff --git a/gcc/testsuite/gcc.target/sparc/sparc-ret-3.c 
b/gcc/testsuite/gcc.target/sparc/sparc-ret-3.c
new file mode 100644
index 000..7a151f8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/sparc/sparc-ret-3.c
@@ -0,0 +1,53 @@
+/* PR target/80968 */
+/* { dg-do compile } */
+/* { dg-skip-if "no register windows" { *-*-* } { "-mflat" } { "" } } */
+/* { dg-require-effective-target ilp32 } */
+/* { dg-options "-mcpu=ultrasparc -O" } */
+
+/* Make sure references to the stack frame do not slip into the delay slot
+   of a return instruction.  */
+
+struct crypto_shash {
+   unsigned int descsize;
+};
+struct crypto_shash *tfm;
+
+struct shash_desc {
+   struct crypto_shash *tfm;
+   unsigned int flags;
+
+   void *__ctx[] __attribute__((aligned(8)));
+};
+
+static inline unsigned int crypto_shash_descsize(struct crypto_shash *tfm)
+{
+   return tfm->descsize;
+}
+
+static inline void *shash_desc_ctx(struct shash_desc *desc)
+{
+   return desc->__ctx;
+}
+
+#define SHASH_DESC_ON_STACK(shash, ctx)  \
+   char __##shash##_desc[sizeof(struct shash_desc) + \
+ crypto_shash_descsize(ctx)] 
__attribute__((aligned(8))); \
+   struct shash_desc *shash = (struct shash_desc *)__##shash##_desc
+
+extern int crypto_shash_update(struct shash_desc *, const void *, unsigned 
int);
+
+unsigned int bug(unsigned int crc, const void *address, unsigned int length)
+{
+   SHASH_DESC_ON_STACK(shash, tfm);
+   unsigned int *ctx = (unsigned int *)shash_desc_ctx(shash);
+   int err;
+
+   shash->tfm = tfm;
+   shash->flags = 0;
+   *ctx = crc;
+
+   err = crypto_shash_update(shash, address, length);
+
+   return *ctx;
+}
+/* { dg-final { scan-assembler "ld\[ \t\]*\\\[%i5\\+8\\\], 
%i0\n\[^\n\]*return\[ \t\]*%i7\\+8" } } */
-- 
2.1.2.532.g19b5d50

[PATCH][SPARC] PR target/80968 Prevent stack loads in return delay slot.

[David Miller]

This is an attempt to fix PR target/80968.  This bug has existed
basically forever.

The stack_tie sequence seems to be how other targets deal with this
issue.  I only emit this when alloca is used.  If there are other
conditions that potentially would necessitate such a barrier, just let
me know.


sparc: Fix stack references in return delay slot.

gcc/

* config/sparc/sparc.md (UNSPEC_TIE): New unspec.
(stack_tie): New pattern.
* config/sparc/sparc.c (sparc_emit_stack_tie): New function.
(sparc_expand_prologue): Call it if function uses alloca.

gcc/testsuite/

* gcc.target/sparc/sparc-ret-3.c: New test.
---
 gcc/config/sparc/sparc.c | 15 
 gcc/config/sparc/sparc.md| 11 ++
 gcc/testsuite/gcc.target/sparc/sparc-ret-3.c | 53 
 3 files changed, 79 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/sparc/sparc-ret-3.c

diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index 6dfb269..345bc7f 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -5784,6 +5784,18 @@ sparc_asm_function_prologue (FILE *file, HOST_WIDE_INT 
size ATTRIBUTE_UNUSED)
   sparc_output_scratch_registers (file);
 }
 
+/* This ties together stack memory (MEM with an alias set of frame_alias_set)
+   and the change to the stack pointer.  */
+
+static void
+sparc_emit_stack_tie (void)
+{
+  rtx mem = gen_frame_mem (BLKmode,
+  gen_rtx_REG (Pmode, STACK_POINTER_REGNUM));
+
+  emit_insn (gen_stack_tie (mem));
+}
+
 /* Expand the function epilogue, either normal or part of a sibcall.
We emit all the instructions except the return or the call.  */
 
@@ -5792,6 +5804,9 @@ sparc_expand_epilogue (bool for_eh)
 {
   HOST_WIDE_INT size = sparc_frame_size;
 
+  if (cfun->calls_alloca)
+sparc_emit_stack_tie ();
+
   if (sparc_n_global_fp_regs > 0)
 emit_save_or_restore_global_fp_regs (sparc_frame_base_reg,
 sparc_frame_base_offset
diff --git a/gcc/config/sparc/sparc.md b/gcc/config/sparc/sparc.md
index 737bdb3..ef00fc5 100644
--- a/gcc/config/sparc/sparc.md
+++ b/gcc/config/sparc/sparc.md
@@ -94,6 +94,8 @@
   UNSPEC_ADDV
   UNSPEC_SUBV
   UNSPEC_NEGV
+
+  UNSPEC_TIE
 ])
 
 (define_c_enum "unspecv" [
@@ -8473,6 +8475,15 @@
   [(set_attr "type" "multi")
(set_attr "length" "4")])
 
+;; This is used in sparc_expand_epilogue in order to prevent insns
+;; referencing the stack from being placed after the deallocation of
+;; the stack frame.
+(define_insn "stack_tie"
+  [(set (match_operand:BLK 0 "memory_operand" "+m")
+(unspec:BLK [(match_dup 0)] UNSPEC_TIE))]
+  ""
+  ""
+  [(set_attr "length" "0")])
 
 ;; Vector instructions.
 
diff --git a/gcc/testsuite/gcc.target/sparc/sparc-ret-3.c 
b/gcc/testsuite/gcc.target/sparc/sparc-ret-3.c
new file mode 100644
index 000..7a151f8
--- /dev/null
+++ b/gcc/testsuite/gcc.target/sparc/sparc-ret-3.c
@@ -0,0 +1,53 @@
+/* PR target/80968 */
+/* { dg-do compile } */
+/* { dg-skip-if "no register windows" { *-*-* } { "-mflat" } { "" } } */
+/* { dg-require-effective-target ilp32 } */
+/* { dg-options "-mcpu=ultrasparc -O" } */
+
+/* Make sure references to the stack frame do not slip into the delay slot
+   of a return instruction.  */
+
+struct crypto_shash {
+   unsigned int descsize;
+};
+struct crypto_shash *tfm;
+
+struct shash_desc {
+   struct crypto_shash *tfm;
+   unsigned int flags;
+
+   void *__ctx[] __attribute__((aligned(8)));
+};
+
+static inline unsigned int crypto_shash_descsize(struct crypto_shash *tfm)
+{
+   return tfm->descsize;
+}
+
+static inline void *shash_desc_ctx(struct shash_desc *desc)
+{
+   return desc->__ctx;
+}
+
+#define SHASH_DESC_ON_STACK(shash, ctx)  \
+   char __##shash##_desc[sizeof(struct shash_desc) + \
+ crypto_shash_descsize(ctx)] 
__attribute__((aligned(8))); \
+   struct shash_desc *shash = (struct shash_desc *)__##shash##_desc
+
+extern int crypto_shash_update(struct shash_desc *, const void *, unsigned 
int);
+
+unsigned int bug(unsigned int crc, const void *address, unsigned int length)
+{
+   SHASH_DESC_ON_STACK(shash, tfm);
+   unsigned int *ctx = (unsigned int *)shash_desc_ctx(shash);
+   int err;
+
+   shash->tfm = tfm;
+   shash->flags = 0;
+   *ctx = crc;
+
+   err = crypto_shash_update(shash, address, length);
+
+   return *ctx;
+}
+/* { dg-final { scan-assembler "ld\[ \t\]*\\\[%i5\\+8\\\], 
%i0\n\[^\n\]*return\[ \t\]*%i7\\+8" } } */
-- 
2.1.2.532.g19b5d50

Re: install.texi and sparc-*-linux*

[David Miller]

From: Gerald Pfeifer 
Date: Sun, 12 Mar 2017 12:39:56 +0100 (CET)

> On Sun, 12 Mar 2017, Gerald Pfeifer wrote:
>> References to dependencies on really, really old versions of
>> binutils (talking 10+ years here) which I think we can remove.
>> Let me follow-up with some of you with concrete suggestions 
>> around that.
> 
> The section on sparc-*-linux* currently has this:
> 
>   GCC versions 3.0 and higher require binutils 2.11.2 and glibc 2.2.4
>   or newer on this platform.  All earlier binutils and glibc
>   releases mishandled unaligned relocations on @code{sparc-*-*} targets.
> 
> Okay to yank it?

No objections from me.

Re: [PATCH] Convert SPARC to LRA

[David Miller]

From: Sebastian Huber 
Date: Tue, 8 Dec 2015 11:17:53 +0100

> since the LRA patch is still reverted on the trunk, I guess the
> switch to LRA will not happen in GCC 6?

Indeed, it is unlikely I will have time to work on this for at
least a month.

Re: [PATCH] Convert SPARC to LRA

[David Miller]

From: Oleg Endo 
Date: Mon, 28 Sep 2015 21:26:14 +0900

> LRA on SH seems to work without GCC test suite failures.  However, I'd
> expect that there still hidden bugs not covered by the test suite.  SH's
> R0 spill failures are greatly reduced with LRA, although some hacks had
> to be added to the SH backend to make it work at all.  Despite that, we
> see quite some significant code size increases compared to reload.  If
> the difference wasn't that big, we'd probably turn LRA on by default for
> SH in GCC 6...

One weakness I noticed while working on the sparc conversion is that
the bootstrap of the compiler tests reload/LRA better than the
testsuite does.

Which is unfortunate, because bootstrap failures are significantly harder
to analyze and debug than individual testsuite cases.

Re: [PATCH] Convert SPARC to LRA

[David Miller]

From: David Miller <da...@davemloft.net>
Date: Mon, 14 Sep 2015 11:30:29 -0700 (PDT)

> There are some other issues I'm having troubles resolving for 64-bit
> native bootstraps as well, and I am probably going to revert the LRA
> sparc changes unless I can resolve them by the end of today.

So I was actually able to resolve these problems, and committed the
following patch.

The big take-aways are:

1) Since we can only access SFmode/SImode/etc. in FP_REGS but not
   necessarily in EXTRA_FP_REGS, we have to tell LRA that secondary
   memory is needed when moving such a mode between those two classes.

2) HARD_REGNO_CALLER_SAVE_MODE's default should really be reconsidered.
   If the caller has an explicit mode in mind we should just use it
   instead just going to choose_hard_reg_mode().  That causes stupid
   things like using a DFmode register to spill an SFmode value and
   all the subregging that results from that.

3) It's amazing how much we get away with in RELOAD, particular wrt.
   to addressing.  Here all of the "(set x (HIGH (SYMBOLIC...)))"
   were always available even when flag_pic and this was never
   noticed before.


[PATCH] Fix LRA regressions on 64-bit SPARC.

gcc/
* config/sparc/sparc-protos.h (sparc_secondary_memory_needed):
Declare.
* config/sparc/sparc.c (sparc_secondary_memory_needed): New
function.
* config/sparc/sparc.h (SECONDARY_MEMORY_NEEDED): Use it.
(HARD_REGNO_CALLER_SAVE_MODE): Define.
* config/sparc/sparc.md (sethi_di_medlow, losum_di_medlow, seth44)
(setm44, setl44, sethh, setlm, sethm, setlo, embmedany_sethi)
(embmedany_losum, embmedany_brsum, embmedany_textuhi)
(embmedany_texthi, embmedany_textulo, embmedany_textlo): Do not
provide when flag_pic.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@227847 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog   | 14 ++
 gcc/config/sparc/sparc-protos.h |  2 ++
 gcc/config/sparc/sparc.c| 20 
 gcc/config/sparc/sparc.h| 14 +-
 gcc/config/sparc/sparc.md   | 32 
 5 files changed, 61 insertions(+), 21 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 76566ca..42faf2e 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,17 @@
+2015-09-17  David S. Miller  <da...@davemloft.net>
+
+   * config/sparc/sparc-protos.h (sparc_secondary_memory_needed):
+   Declare.
+   * config/sparc/sparc.c (sparc_secondary_memory_needed): New
+   function.
+   * config/sparc/sparc.h (SECONDARY_MEMORY_NEEDED): Use it.
+   (HARD_REGNO_CALLER_SAVE_MODE): Define.
+   * config/sparc/sparc.md (sethi_di_medlow, losum_di_medlow, seth44)
+   (setm44, setl44, sethh, setlm, sethm, setlo, embmedany_sethi)
+   (embmedany_losum, embmedany_brsum, embmedany_textuhi)
+   (embmedany_texthi, embmedany_textulo, embmedany_textlo): Do not
+   provide when flag_pic.
+
 2015-09-17  Kaz Kojima  <kkoj...@gcc.gnu.org>
 
* config/sh/sh.c (label_ref_list_d_pool): Adjust to
diff --git a/gcc/config/sparc/sparc-protos.h b/gcc/config/sparc/sparc-protos.h
index 1431437..18192fd 100644
--- a/gcc/config/sparc/sparc-protos.h
+++ b/gcc/config/sparc/sparc-protos.h
@@ -62,6 +62,8 @@ extern bool constant_address_p (rtx);
 extern bool legitimate_pic_operand_p (rtx);
 extern rtx sparc_legitimize_reload_address (rtx, machine_mode, int, int,
int, int *win);
+extern bool sparc_secondary_memory_needed (enum reg_class, enum reg_class,
+  machine_mode);
 extern void load_got_register (void);
 extern void sparc_emit_call_insn (rtx, rtx);
 extern void sparc_defer_case_vector (rtx, rtx, int);
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index b41800c..f4ad68d 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -12283,6 +12283,26 @@ sparc_expand_vector_init (rtx target, rtx vals)
   emit_move_insn (target, mem);
 }
 
+bool sparc_secondary_memory_needed (enum reg_class class1, enum reg_class 
class2,
+   machine_mode mode)
+{
+  if (FP_REG_CLASS_P (class1) != FP_REG_CLASS_P (class2))
+{
+  if (! TARGET_VIS3
+ || GET_MODE_SIZE (mode) > 8
+ || GET_MODE_SIZE (mode) < 4)
+   return true;
+  return false;
+}
+
+  if (GET_MODE_SIZE (mode) == 4
+  && ((class1 == FP_REGS && class2 == EXTRA_FP_REGS)
+ || (class1 == EXTRA_FP_REGS && class2 == FP_REGS)))
+return true;
+
+  return false;
+}
+
 /* Implement TARGET_SECONDARY_RELOAD.  */
 
 static reg_class_t
diff --git a/gcc/config/sparc/sparc.h b/gcc/config/sparc/sparc.h
index 8343671..1f26232 100644
--- a/gcc/config/sparc/sparc.h
+++ b/gcc/config/sparc/sparc.h
@@ -747,6 +747,12 @@ extern int sparc_mode_cla

Re: [PATCH] Convert SPARC to LRA

[David Miller]

From: Eric Botcazou 
Date: Sat, 12 Sep 2015 16:04:09 +0200

> You need to update https://gcc.gnu.org/backends.html

Done.

Re: [PATCH] Convert SPARC to LRA

[David Miller]

From: Eric Botcazou 
Date: Thu, 17 Sep 2015 23:13:21 +0200

> Did you keep the 64-bit promotion in PROMOTE_MODE or...?

Yes I had to, the compiler aborts() if I make it use SImode on 64-bit.

I'll take a closer look soon.

[PATCH] Fix endianness assumption in LRA

[David Miller]

This was the most glaring case, and would result in LRA crashing
if this code snippet was actually hit on big-endian, since
simplify_gen_subreg() will return NULL in such a case and then
we try to blindly emit a move to 'subreg'.

There is code in match_reload which seems to have a similar problem,
specifically these sequences:

  if (SCALAR_INT_MODE_P (inmode))
new_out_reg = gen_lowpart_SUBREG (outmode, reg);
  else
new_out_reg = gen_rtx_SUBREG (outmode, reg, 0);
 ...
  if (SCALAR_INT_MODE_P (outmode))
new_in_reg = gen_lowpart_SUBREG (inmode, reg);
  else
new_in_reg = gen_rtx_SUBREG (inmode, reg, 0);

But I have not tried to address those cases in this patch.

Vlad, is this OK to commit?

2015-09-14  David S. Miller  

* lra-constraints.c (simplify_operand_subreg): Do not assume that
lowpart of a SUBREG has offset zero.

diff --git a/gcc/lra-constraints.c b/gcc/lra-constraints.c
index cdb2695..fc8e43d 100644
--- a/gcc/lra-constraints.c
+++ b/gcc/lra-constraints.c
@@ -1545,7 +1545,7 @@ simplify_operand_subreg (int nop, machine_mode reg_mode)
  bool insert_before, insert_after;
 
  PUT_MODE (new_reg, mode);
-  subreg = simplify_gen_subreg (innermode, new_reg, mode, 0);
+  subreg = gen_lowpart_SUBREG (innermode, new_reg);
  bitmap_set_bit (_subreg_reload_pseudos, REGNO (new_reg));
 
  insert_before = (type != OP_OUT);

Re: [PATCH] Convert SPARC to LRA

[David Miller]

From: Richard Henderson 
Date: Mon, 14 Sep 2015 10:20:00 -0700

> There's a possibility of benefit though -- br and movr only work with DImode.
> You may want to examine the generated code to decide one way or another.
> 
> It's possible that the extra comparison instructions don't really matter
> compared with the larger spill slot, but you never know...

And another issue is that I get expr.c:expand_expr_real_1() assertion
failures when I try to use SImode for 64-bit, specifically the one in
this code sequence:

  /* Get the signedness to be used for this variable.  Ensure we get
 the same mode we got when the variable was declared.  */
  if (code != SSA_NAME)
pmode = promote_decl_mode (exp, );
  else if ((g = SSA_NAME_DEF_STMT (ssa_name))
   && gimple_code (g) == GIMPLE_CALL
   && !gimple_call_internal_p (g))
pmode = promote_function_mode (type, mode, ,
   gimple_call_fntype (g),
   2);
  else
pmode = promote_ssa_mode (ssa_name, );
  gcc_assert (GET_MODE (decl_rtl) == pmode);

There are some other issues I'm having troubles resolving for 64-bit
native bootstraps as well, and I am probably going to revert the LRA
sparc changes unless I can resolve them by the end of today.

Re: [PATCH] Convert SPARC to LRA

[David Miller]

From: Eric Botcazou 
Date: Sat, 12 Sep 2015 16:04:09 +0200

>> Richard, Eric, any objections?
> 
> Do we really need to promote to 64-bit if TARGET_ARCH64?  Most 32-bit 
> instructions are still available.  Otherwise this looks good to me.

No, we don't, we can just promote to 32-bit.  I'll make that adjustment
and update the backends page as well.

Thanks.

Re: [PATCH] Convert SPARC to LRA

[David Miller]

From: David Miller <da...@davemloft.net>
Date: Tue, 08 Sep 2015 21:41:15 -0700 (PDT)

> I'm therefore reasonably confident in these changes, but I will
> not apply them just yet to give the other sparc maintainers some
> time to review and give feedback.

Richard, Eric, any objections?

[PATCH] Convert SPARC to LRA

[David Miller]

The following patch converts the sparc backend over to LRA.

The three major obstacles to overcome were:

1) The funky "U" constraint.  It was a register constraint, but
   did not evaluate to a register class, and was used to help
   handling unaligned integer register pairs.

   It turns out to be unnecessary, since GENERAL_REGS plus
   HARD_REGNO_MODE_OK() do the job just fine now.

2) Sparc generates unreasonable amounts of subregging because
   it did not define PROMOTE_MODE().  All of the subreg LRA
   problems I was running into went away once I simply added
   the define.

3) The sethi/or patterns accepting direct symbol references and
   similar should not be available when flag_pic.

The testsuite runs really well, there are no regressions and in
fact the LRA conversion fixes some failures.

I'm therefore reasonably confident in these changes, but I will
not apply them just yet to give the other sparc maintainers some
time to review and give feedback.

2015-09-08  David S. Miller  

* config/sparc/constraints.md: Make "U" constraint a real register
constraint.
* config/sparc/sparc.c (TARGET_LRA_P): Define.
(D_MODES, DF_MODES): Add missing cast.
(TF_MODES, TF_MODES_NO_S): Include T_MODE.
(OF_MODES, OF_MODES_NO_S): Include O_MODE.
(sparc_register_move_cost): Decrease Niagara/UltrsSPARC memory
cost to 8.
* config/sparc/sparc.h (PROMOTE_MODE): Define.
* config/sparc/sparc.md (*movsi_lo_sum, *movsi_high): Do not
provide these insn when flag_pic.

diff --git a/gcc/config/sparc/constraints.md b/gcc/config/sparc/constraints.md
index e12efa1..7a18879 100644
--- a/gcc/config/sparc/constraints.md
+++ b/gcc/config/sparc/constraints.md
@@ -44,6 +44,8 @@
 (define_register_constraint "h" "(TARGET_V9 && TARGET_V8PLUS ? I64_REGS : 
NO_REGS)"
  "64-bit global or out register in V8+ mode")
 
+(define_register_constraint "U" "(TARGET_ARCH32 ? GENERAL_REGS : NO_REGS)")
+
 ;; Floating-point constant constraints
 
 (define_constraint "G"
@@ -135,51 +137,6 @@
   (match_code "mem")
   (match_test "memory_ok_for_ldd (op)")))
 
-;; This awkward register constraint is necessary because it is not
-;; possible to express the "must be even numbered register" condition
-;; using register classes.  The problem is that membership in a
-;; register class requires that all registers of a multi-regno
-;; register be included in the set.  It is add_to_hard_reg_set
-;; and in_hard_reg_set_p which populate and test regsets with these
-;; semantics.
-;;
-;; So this means that we would have to put both the even and odd
-;; register into the register class, which would not restrict things
-;; at all.
-;;
-;; Using a combination of GENERAL_REGS and HARD_REGNO_MODE_OK is not a
-;; full solution either.  In fact, even though IRA uses the macro
-;; HARD_REGNO_MODE_OK to calculate which registers are prohibited from
-;; use in certain modes, it still can allocate an odd hard register
-;; for DImode values.  This is due to how IRA populates the table
-;; ira_useful_class_mode_regs[][].  It suffers from the same problem
-;; as using a register class to describe this restriction.  Namely, it
-;; sets both the odd and even part of an even register pair in the
-;; regset.  Therefore IRA can and will allocate odd registers for
-;; DImode values on 32-bit.
-;;
-;; There are legitimate cases where DImode values can end up in odd
-;; hard registers, the most notable example is argument passing.
-;;
-;; What saves us is reload and the DImode splitters.  Both are
-;; necessary.  The odd register splitters cannot match if, for
-;; example, we have a non-offsetable MEM.  Reload will notice this
-;; case and reload the address into a single hard register.
-;;
-;; The real downfall of this awkward register constraint is that it does
-;; not evaluate to a true register class like a bonafide use of
-;; define_register_constraint would.  This currently means that we cannot
-;; use LRA on Sparc, since the constraint processing of LRA really depends
-;; upon whether an extra constraint is for registers or not.  It uses
-;; reg_class_for_constraint, and checks it against NO_REGS.
-(define_constraint "U"
- "Pseudo-register or hard even-numbered integer register"
- (and (match_test "TARGET_ARCH32")
-  (match_code "reg")
-  (ior (match_test "REGNO (op) < FIRST_PSEUDO_REGISTER")
-  (not (match_test "reload_in_progress && reg_renumber [REGNO (op)] < 
0")))
-  (match_test "register_ok_for_ldd (op)")))
-
 ;; Equivalent to 'T' but available in 64-bit mode
 (define_memory_constraint "W"
  "Memory reference for 'e' constraint floating-point register"
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index ed8a166..b41800c 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -808,6 +808,9 @@ char sparc_hard_reg_printed[8];
 #undef TARGET_CAN_ELIMINATE
 #define TARGET_CAN_ELIMINATE sparc_can_eliminate
 

Re: [RFC 1/2] Turn RETURN_ADDR_IN_PREVIOUS_FRAME into C expression

[David Miller]

From: Max Filippov jcmvb...@gmail.com
Date: Sun, 1 Mar 2015 09:34:38 +0300

 Richard, David, Eric,
 
 could you please take a look and possibly approve the below changes for
 sparc?

I don't have any objection to the sparc changes.

Re: [PATCH][SPARC] default with_cpu to ultrasparc in sparc64-*-linux* targets

[David Miller]

From: Eric Botcazou ebotca...@adacore.com
Date: Mon, 15 Dec 2014 22:27:38 +0100

 I think it would be reasonable to have gcc targetting ultrasparc
 extensions by default in sparc64-*-linux*.  WDYT?
 
 No strong opinion.  FreeBSD and OpenBSD already do it so why not?
 
 DaveM, any opinion?

Keep in mind that some early Niagara chips lacked some portion of the
VIS instructions and they are thus emulated in software.

The other problem is that the instruction scheduling for ultrasparc
is either completely unnecessary or wrong for all of the Niagara
variants.

In fact, 'ultrasparc' is the most complicated and resource intensive
of all of the instruction schedulers we have yet it applies to a very
small percentage of the actual chips still in use.

The ultrasparc3 scheduler is much smaller and much more efficient,
and provides a schedule that works well across all chip variants.

Re: [SPARC] Remove superfluous memory barrier for atomics with TSO

[David Miller]

From: Richard Henderson r...@redhat.com
Date: Tue, 30 Jul 2013 12:33:30 -1000

 On 07/30/2013 03:31 AM, Eric Botcazou wrote:
 2013-07-30  Eric Botcazou  ebotca...@adacore.com
 
  * config/sparc/sparc.c (sparc_emit_membar_for_model) SMM_TSO: Add
  the implied StoreLoad barrier for atomic operations if before.
 
 Looks good.

This looks fine to me too.

Re: [SPARC] Work around data cache nullify issues on LEON3

[David Miller]

From: Eric Botcazou ebotca...@adacore.com
Date: Mon, 22 Jul 2013 23:34:29 +0200

 This enhances -mfix-ut699 to work around the data cache nullify issues 
 recently 
 uncovered on the LEON3 processor, as documented in the relevant errata sheet.
 
 Tested on SPARC/Solaris, applied on the mainline.

Looks good, nice work Eric.

Re: [SPARC] Minor tweak to uses of bmasksi_vis

[David Miller]

From: Eric Botcazou ebotca...@adacore.com
Date: Tue, 28 May 2013 11:56:40 +0200

 This changes the 3 occurrences of bmasksi_vis to use %g0 as the destination 
 register instead of an otherwise unused pseudo-register.
 
 Tested on SPARC/Solaris, applied on the mainline.

Thanks for improving this.

Re: [SPARC] Fix PR target/56890

[David Miller]

From: Eric Botcazou ebotca...@adacore.com
Date: Mon, 15 Apr 2013 18:07:05 +0200

 We can actually support this by adding patterns for the partial store
 instructions, which can store 8-bit and 16-bit quantities from FP
 registers.
 
 Ah, indeed, with -mvis.  Not clear whether that would really be worthwhile.

Well, %99 of sparc cpus used with gcc these days are -mvis capable,
and popping the value to the integer register file via the stack
in these situations is needless overhead.

Re: [SPARC] Fix PR target/56890

[David Miller]

From: Eric Botcazou ebotca...@adacore.com
Date: Sun, 14 Apr 2013 10:39:59 +0200

 To my great surprise, this PR shows that the SPARC back-end allows QImode and 
 HImode values to live in FP registers, but can neither load nor move them.
 This can result in an unrecognizable move insn between FP registers or an 
 illegal fdtox instruction in 64-bit mode as shown by the submitted testcases.
 
 The attached patch changes that and yields no regressions both in 32-bit and 
 64-bit modes.  Any objections to applying it to all active branches?

No objections.

We can actually support this by adding patterns for the partial store
instructions, which can store 8-bit and 16-bit quantities from FP
registers.

[PATCH] Fix assembler options for -mcpu={supersparc,hypersparc}

[David Miller]

This is yet another bug just like PR target/52610, we need to pass
-Av8 to the assembler for every cpu type that will use MASK_V8 in
sparc.c:sparc_option_override().

I found this while testing GMP builds.

I'd like to check this into the various gcc-4_X-branch branches as
well, unless there are major objections.

gcc/

* config/sparc/sparc.h (ASM_CPU_SPEC): Pass -Av8 if -mcpu=supersparc
or -mcpu=hypersparc.

diff --git a/gcc/config/sparc/sparc.h b/gcc/config/sparc/sparc.h
index 6b02b45..c6122c1 100644
--- a/gcc/config/sparc/sparc.h
+++ b/gcc/config/sparc/sparc.h
@@ -327,6 +327,8 @@ extern enum cmodel sparc_cmodel;
 %{mcpu=sparclite86x:-Asparclite} \
 %{mcpu=f930:-Asparclite} %{mcpu=f934:-Asparclite} \
 %{mcpu=v8:-Av8} \
+%{mcpu=supersparc:-Av8} \
+%{mcpu=hypersparc:-Av8} \
 %{mcpu=leon:-Av8} \
 %{mv8plus:-Av8plus} \
 %{mcpu=v9:-Av9} \

Re: [PATCH] Improve cstore code generation on 64-bit sparc.

[David Miller]

From: David Miller da...@davemloft.net
Date: Mon, 08 Apr 2013 21:56:04 -0400 (EDT)

 
 One major suboptimal area of the sparc back end is cstore generation
 on 64-bit.
 
 Due to the way arguments and return values of functions must be
 promoted, the ideal mode for cstore's result would be DImode.
 
 But this hasn't been done because of a fundamental limitation
 of the cstore patterns.  They require a fixed mode be used for
 the boolean result value.
 
 I've decided to work around this by building a target hook which
 specifies the type to use for conditional store results, and then I
 use a special predicate for operans 0 in the cstore expanders so
 that they still match even when we use DImode.
 
 The default version of the target hook just does what it does now,
 so no other target should be impacted by this at all.
 
 Regstrapped on 32-bit sparc-linux-gnu and I've run the testsuite
 with -m64 to validate the 64-bit side.
 
 Any major objections?

Since no objections were expressed, I've committed this to trunk.

[PATCH] Improve cstore code generation on 64-bit sparc.

[David Miller]

One major suboptimal area of the sparc back end is cstore generation
on 64-bit.

Due to the way arguments and return values of functions must be
promoted, the ideal mode for cstore's result would be DImode.

But this hasn't been done because of a fundamental limitation
of the cstore patterns.  They require a fixed mode be used for
the boolean result value.

I've decided to work around this by building a target hook which
specifies the type to use for conditional store results, and then I
use a special predicate for operans 0 in the cstore expanders so
that they still match even when we use DImode.

The default version of the target hook just does what it does now,
so no other target should be impacted by this at all.

Regstrapped on 32-bit sparc-linux-gnu and I've run the testsuite
with -m64 to validate the 64-bit side.

Any major objections?

gcc/

* target.def (cstore_mode): New hook.
* target.h: Include insn-codes.h
* targhooks.c: Likewise.
(default_cstore_mode): New function.
* targhooks.h: Declare it.
* doc/tm.texi.in: New hook slot for TARGET_CSTORE_MODE.
* doc/tm.texi: Rebuild.
* expmed.c (emit_cstore): Obtain cstore boolean result mode using
target hook, rather than inspecting the insn_data.
* config/sparc/sparc.c (sparc_cstore_mode): New function.
(TARGET_CSTORE_MODE): Redefine.
(emit_scc_insn): When TARGET_ARCH64, emit new 64-bit boolean
result patterns.
* config/sparc/predicates.md (cstore_result_operand): New special
predicate.
* config/sparc/sparc.md (cstoresi4, cstoredi4, cstoreF:mode4):
Use it for operand 0.
(*seqsi_special): Rewrite using 'P' mode iterator on operand 0.
(*snesi_special): Likewise.
(*snesi_zero): Likewise.
(*seqsi_zero): Likewise.
(*sltu_insn): Likewise.
(*sgeu_insn): Likewise.
(*seqdi_special): Make operand 0 and comparison operation be of
DImode.
(*snedi_special): Likewise.
(*snedi_special_vis3): Likewise.
(*neg_snesi_zero): Rename to *neg_snesisi_zero.
(*neg_snesi_sign_extend): Rename to *neg_snesidi_zero.
(*snesi_zero_extend): Delete, covered by 'P' mode iterator.
(*neg_seqsi_zero): Rename to *neg_seqsisi_zero.
(*neg_seqsi_sign_extend): Rename to *neg_seqsidi_zero.
(*seqsi_zero_extend): Delete, covered by 'P' mode iterator.
(*sltu_extend_sp64): Likewise.
(*neg_sltu_insn): Rename to *neg_sltusi_insn.
(*neg_sltu_extend_sp64): Rename to *neg_sltudi_insn.
(*sgeu_extend_sp64): Delete, covered by 'P' mode iterator.
(*neg_sgeu_insn): Rename to *neg_sgeusi_insn.
(*neg_sgeu_extend_sp64): Rename to *neg_sgeudi_insn.

gcc/testsuite/

* gcc.target/sparc/setcc-4.c: New test.
* gcc.target/sparc/setcc-5.c: New test.
---
 gcc/config/sparc/predicates.md   |   5 ++
 gcc/config/sparc/sparc.c |  23 +-
 gcc/config/sparc/sparc.md| 137 ++-
 gcc/doc/tm.texi  |   4 +
 gcc/doc/tm.texi.in   |   2 +
 gcc/expmed.c |   2 +-
 gcc/target.def   |  10 +++
 gcc/target.h |   1 +
 gcc/targhooks.c  |   9 ++
 gcc/targhooks.h  |   1 +
 gcc/testsuite/gcc.target/sparc/setcc-4.c |  44 ++
 gcc/testsuite/gcc.target/sparc/setcc-5.c |  42 ++
 12 files changed, 183 insertions(+), 97 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/sparc/setcc-4.c
 create mode 100644 gcc/testsuite/gcc.target/sparc/setcc-5.c

diff --git a/gcc/config/sparc/predicates.md b/gcc/config/sparc/predicates.md
index b8524e5..073bce2 100644
--- a/gcc/config/sparc/predicates.md
+++ b/gcc/config/sparc/predicates.md
@@ -265,6 +265,11 @@
   (ior (match_test register_operand (op, SImode))
(match_test TARGET_ARCH64  register_operand (op, DImode
 
+;; Return true if OP is an integer register of the appropriate mode
+;; for a cstore result.
+(define_special_predicate cstore_result_operand
+  (match_test register_operand (op, TARGET_ARCH64 ? DImode : SImode)))
+
 ;; Return true if OP is a floating point condition code register.
 (define_predicate fcc_register_operand
   (match_code reg)
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index 3e98325..4a73c73 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -597,6 +597,7 @@ static void sparc_print_operand_address (FILE *, rtx);
 static reg_class_t sparc_secondary_reload (bool, rtx, reg_class_t,
   enum machine_mode,
   secondary_reload_info *);
+static enum machine_mode sparc_cstore_mode (enum insn_code icode);
 
 #ifdef SUBTARGET_ATTRIBUTE_TABLE
 /* Table of valid machine attributes.  */

[PATCH RFC] Finer grained reg classes.

[David Miller]

This is very much a work in progress, but I think it has potential
to solve the problem at hand.

A major blocker for using LRA on sparc is a fundamental limitation of
register classes as currently implemented.

If you have an instruction that requires an evenly aligned hard
register pair, you cannot describe this alone using register classes.

That's because register classes must contain all registers of a
multiple register set, which effectively would allow both even
and odd registers, thus not constraining the hard registers which
are valid at all.

Targets work around this by using HARD_REGNO_MODE_OK(), which causes
pre-LRA reload to fix up all the hard register allocation mistakes
made by IRA, the latter of which relies largely upon register classes.

LRA relies upon register classes completely, so targets really have to
express an instruction's exact needs using register classes rather
than ad-hoc constraints like the U constraint sparc is using:

(define_constraint U
 Pseudo-register or hard even-numbered integer register
 (and (match_test TARGET_ARCH32)
  (match_code reg)
  (ior (match_test REGNO (op)  FIRST_PSEUDO_REGISTER)
   (not (match_test reload_in_progress  reg_renumber [REGNO (op)]  
0)))
  (match_test register_ok_for_ldd (op

So this patch tries to rework the semantics of hard register classes,
such that if a hard register is present in the set it is implied that
the rest of the registers in a multi-register group are present as
well.  So we can add a register class called EVEN_REGS and only have
to set the even register bits.

The patch below is enough to get zero regressions for the c/c++
testsuite on 32-bit sparc, but I do know that there are some problems
that need to be resolved still.

For example, I think we need some way to validate a regclass based
upon the mode, something slightly different from HARD_REGNO_MODE_OK.

This would be used for things like the a constraint on x86 so that
on 32-bit a user couldn't try to use the a constraint in an inline
asm for a 64-bit value.

In the compiler itself, this really isn't an issue, because the
machine description would only use register classes for the proper
mode.

I intend to also use this new regclass scheme to represent FPU double
register pairs on sparc as well.

Anyways, any comments would be appreciated, thanks.

diff --git a/gcc/config/sparc/constraints.md b/gcc/config/sparc/constraints.md
index 5dec3dd..cd082ad 100644
--- a/gcc/config/sparc/constraints.md
+++ b/gcc/config/sparc/constraints.md
@@ -44,6 +44,9 @@
 (define_register_constraint h (TARGET_V9  TARGET_V8PLUS ? I64_REGS : 
NO_REGS)
  64-bit global or out register in V8+ mode)
 
+(define_register_constraint U (TARGET_ARCH32 ? EVEN_REGS : NO_REGS)
+ Even-numbered integer register)
+
 ;; Floating-point constant constraints
 
 (define_constraint G
@@ -135,51 +138,6 @@
   (match_code mem)
   (match_test memory_ok_for_ldd (op
 
-;; This awkward register constraint is necessary because it is not
-;; possible to express the must be even numbered register condition
-;; using register classes.  The problem is that membership in a
-;; register class requires that all registers of a multi-regno
-;; register be included in the set.  It is add_to_hard_reg_set
-;; and in_hard_reg_set_p which populate and test regsets with these
-;; semantics.
-;;
-;; So this means that we would have to put both the even and odd
-;; register into the register class, which would not restrict things
-;; at all.
-;;
-;; Using a combination of GENERAL_REGS and HARD_REGNO_MODE_OK is not a
-;; full solution either.  In fact, even though IRA uses the macro
-;; HARD_REGNO_MODE_OK to calculate which registers are prohibited from
-;; use in certain modes, it still can allocate an odd hard register
-;; for DImode values.  This is due to how IRA populates the table
-;; ira_useful_class_mode_regs[][].  It suffers from the same problem
-;; as using a register class to describe this restriction.  Namely, it
-;; sets both the odd and even part of an even register pair in the
-;; regset.  Therefore IRA can and will allocate odd registers for
-;; DImode values on 32-bit.
-;;
-;; There are legitimate cases where DImode values can end up in odd
-;; hard registers, the most notable example is argument passing.
-;;
-;; What saves us is reload and the DImode splitters.  Both are
-;; necessary.  The odd register splitters cannot match if, for
-;; example, we have a non-offsetable MEM.  Reload will notice this
-;; case and reload the address into a single hard register.
-;;
-;; The real downfall of this awkward register constraint is that it does
-;; not evaluate to a true register class like a bonafide use of
-;; define_register_constraint would.  This currently means that we cannot
-;; use LRA on Sparc, since the constraint processing of LRA really depends
-;; upon whether an extra constraint is for registers or not.  It uses
-;; REG_CLASS_FROM_CONSTRAINT, and checks it against NO_REGS.

Re: expansion of vector shifts...

[David Miller]

From: Richard Biener richard.guent...@gmail.com
Date: Wed, 13 Feb 2013 12:15:13 +0100

 On Tue, Feb 12, 2013 at 11:31 PM, David Miller da...@davemloft.net wrote:
 Maybe what we really mean to do here is check both op1 and SUBREG_REG
 (op1) against SCALAR_INT_MODE_P instead of INTEGRAL_MODE_P?
 
 Yes.

Ok, I'll commit this after doing some regstraps, thanks.

 Something like this:

 gcc/

 2013-02-12  David S. Miller  da...@davemloft.net

 * expmed.c (expand_shift_1): Only strip scalar integer subregs.

 diff --git a/gcc/expmed.c b/gcc/expmed.c
 index 4a6ddb0..954a360 100644
 --- a/gcc/expmed.c
 +++ b/gcc/expmed.c
 @@ -2116,8 +2116,8 @@ expand_shift_1 (enum tree_code code, enum machine_mode 
 mode, rtx shifted,
% GET_MODE_BITSIZE (mode));
else if (GET_CODE (op1) == SUBREG
 subreg_lowpart_p (op1)
 -   INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1)))
 -   INTEGRAL_MODE_P (GET_MODE (op1)))
 +   SCALAR_INT_MODE_P (GET_MODE (SUBREG_REG (op1)))
 +   SCALAR_INT_MODE_P (GET_MODE (op1)))
 op1 = SUBREG_REG (op1);
  }



 

Re: expansion of vector shifts...

[David Miller]

From: David Miller da...@redhat.com
Date: Fri, 16 Nov 2012 00:33:05 -0500 (EST)

 From: Richard Sandiford rdsandif...@googlemail.com
 Date: Mon, 29 Oct 2012 10:14:53 +
 
 ...given that the code is like you say written:
 
   if (SHIFT_COUNT_TRUNCATED)
 {
   if (CONST_INT_P (op1)
 ...
   else if (GET_CODE (op1) == SUBREG
  subreg_lowpart_p (op1)
  INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1
  op1 = SUBREG_REG (op1);
 }
 
 INTEGRAL_MODE_P (GET_MODE (op1)) might be better than an explicit
 VECTOR_MODE_P check.  The code really doesn't make sense for anything
 other than integers.
 
 (It amounts to the same thing in practice, of course...)
 
 Agreed, I've just committed the following.  Thanks!
 
 
 Fix gcc.c-torture/compile/pr53410-2.c on sparc.
 
   * expmed.c (expand_shift_1): Don't strip non-integral SUBREGs.

This is broken on sparc again, although I'm confused about how this
has happened.

The suggestion was to use INTEGRAL_MODE_P as the test, so what's there
in expand_shift_1() is:

  else if (GET_CODE (op1) == SUBREG
subreg_lowpart_p (op1)
INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1)))
INTEGRAL_MODE_P (GET_MODE (op1)))
op1 = SUBREG_REG (op1);

but INTEGRAL_MODE_P accepts vectors.  This is really confusing because
I was absolutely sure I re-ran the test case with the fix I committed
and it didn't crash any more.

Maybe what we really mean to do here is check both op1 and SUBREG_REG
(op1) against SCALAR_INT_MODE_P instead of INTEGRAL_MODE_P?

Something like this:

gcc/

2013-02-12  David S. Miller  da...@davemloft.net

* expmed.c (expand_shift_1): Only strip scalar integer subregs.

diff --git a/gcc/expmed.c b/gcc/expmed.c
index 4a6ddb0..954a360 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -2116,8 +2116,8 @@ expand_shift_1 (enum tree_code code, enum machine_mode 
mode, rtx shifted,
   % GET_MODE_BITSIZE (mode));
   else if (GET_CODE (op1) == SUBREG
subreg_lowpart_p (op1)
-   INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1)))
-   INTEGRAL_MODE_P (GET_MODE (op1)))
+   SCALAR_INT_MODE_P (GET_MODE (SUBREG_REG (op1)))
+   SCALAR_INT_MODE_P (GET_MODE (op1)))
op1 = SUBREG_REG (op1);
 }
 

Re: var-tracking wrt. leaf regs on sparc

[David Miller]

From: Jakub Jelinek ja...@redhat.com
Date: Thu, 7 Feb 2013 18:22:32 +0100

 Then supposedly somewhere in dwarf2out we do some adjustment,
 but still end up with d/e loclist of:
 .LLST2:
 .uaxword.LVL0-.Ltext0   ! Location list begin address 
 (*.LLST2)
 .uaxword.LVL1-.Ltext0   ! Location list end address (*.LLST2)
 .uahalf 0x6 ! Location expression size
 .byte   0x88! DW_OP_breg24
 .byte   0   ! sleb128 0
 .byte   0x89! DW_OP_breg25
 .byte   0   ! sleb128 0
 .byte   0x22! DW_OP_plus
 .byte   0x9f! DW_OP_stack_value
 .uaxword.LVL1-.Ltext0   ! Location list begin address 
 (*.LLST2)
 .uaxword.LFE0-.Ltext0   ! Location list end address (*.LLST2)
 .uahalf 0x1 ! Location expression size
 .byte   0x58! DW_OP_reg8
 .uaxword0   ! Location list terminator begin (*.LLST2)
 .uaxword0   ! Location list terminator end (*.LLST2)
 where I'd expect breg8/breg9 instead.

The fix for this is trivial, just a missing leaf renumbering in dwarf2out.c:

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 06cfb18..765d5c5 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -10864,7 +10864,16 @@ based_loc_descr (rtx reg, HOST_WIDE_INT offset,
}
 }
 
-  regno = DWARF_FRAME_REGNUM (REGNO (reg));
+  regno = REGNO (reg);
+#ifdef LEAF_REG_REMAP
+  if (crtl-uses_only_leaf_regs)
+{
+  int leaf_reg = LEAF_REG_REMAP (regno);
+  if (leaf_reg != -1)
+   regno = (unsigned) leaf_reg;
+}
+#endif
+  regno = DWARF_FRAME_REGNUM (regno);
 
   if (!optimize  fde
(fde-drap_reg == regno || fde-vdrap_reg == regno))

Re: var-tracking wrt. leaf regs on sparc

[David Miller]

From: David Miller da...@davemloft.net
Date: Thu, 07 Feb 2013 14:38:18 -0500 (EST)

 From: Jakub Jelinek ja...@redhat.com
 Date: Thu, 7 Feb 2013 18:22:32 +0100
 
 Then supposedly somewhere in dwarf2out we do some adjustment,
 but still end up with d/e loclist of:
 .LLST2:
 .uaxword.LVL0-.Ltext0   ! Location list begin address 
 (*.LLST2)
 .uaxword.LVL1-.Ltext0   ! Location list end address (*.LLST2)
 .uahalf 0x6 ! Location expression size
 .byte   0x88! DW_OP_breg24
 .byte   0   ! sleb128 0
 .byte   0x89! DW_OP_breg25
 .byte   0   ! sleb128 0
 .byte   0x22! DW_OP_plus
 .byte   0x9f! DW_OP_stack_value
 .uaxword.LVL1-.Ltext0   ! Location list begin address 
 (*.LLST2)
 .uaxword.LFE0-.Ltext0   ! Location list end address (*.LLST2)
 .uahalf 0x1 ! Location expression size
 .byte   0x58! DW_OP_reg8
 .uaxword0   ! Location list terminator begin (*.LLST2)
 .uaxword0   ! Location list terminator end (*.LLST2)
 where I'd expect breg8/breg9 instead.
 
 The fix for this is trivial, just a missing leaf renumbering in dwarf2out.c:

So the combined patch is below, any objections?

Here is the testsuite diff:

@@ -155,8 +148,8 @@ FAIL: gcc.dg/guality/vla-2.c  -O2 -flto

=== gcc Summary ===

-# of expected passes   2128
-# of unexpected failures   122
+# of expected passes   2135
+# of unexpected failures   115
 # of unexpected successes  31
 # of expected failures 17
 # of unsupported tests 136

This is undoubtedly an improvement.

gcc/

2013-02-07  David S. Miller  da...@davemloft.net

* dwarf2out.c (based_loc_descr): Perform leaf register remapping
on 'reg'.
* var-tracking.c (vt_add_function_parameter): Test the presence of
HAVE_window_save properly and do not remap argument registers when
we have a leaf function.

diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 06cfb18..765d5c5 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -10864,7 +10864,16 @@ based_loc_descr (rtx reg, HOST_WIDE_INT offset,
}
 }
 
-  regno = DWARF_FRAME_REGNUM (REGNO (reg));
+  regno = REGNO (reg);
+#ifdef LEAF_REG_REMAP
+  if (crtl-uses_only_leaf_regs)
+{
+  int leaf_reg = LEAF_REG_REMAP (regno);
+  if (leaf_reg != -1)
+   regno = (unsigned) leaf_reg;
+}
+#endif
+  regno = DWARF_FRAME_REGNUM (regno);
 
   if (!optimize  fde
(fde-drap_reg == regno || fde-vdrap_reg == regno))
diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c
index 714acb69..0db1562 100644
--- a/gcc/var-tracking.c
+++ b/gcc/var-tracking.c
@@ -9502,31 +9502,34 @@ vt_add_function_parameter (tree parm)
   /* DECL_INCOMING_RTL uses the INCOMING_REGNO of parameter registers.
  If the target machine has an explicit window save instruction, the
  actual entry value is the corresponding OUTGOING_REGNO instead.  */
-  if (REG_P (incoming)
-   HARD_REGISTER_P (incoming)
-   OUTGOING_REGNO (REGNO (incoming)) != REGNO (incoming))
+  if (HAVE_window_save  !crtl-uses_only_leaf_regs)
 {
-  parm_reg_t p;
-  p.incoming = incoming;
-  incoming
-   = gen_rtx_REG_offset (incoming, GET_MODE (incoming),
- OUTGOING_REGNO (REGNO (incoming)), 0);
-  p.outgoing = incoming;
-  vec_safe_push (windowed_parm_regs, p);
-}
-  else if (MEM_P (incoming)
-   REG_P (XEXP (incoming, 0))
-   HARD_REGISTER_P (XEXP (incoming, 0)))
-{
-  rtx reg = XEXP (incoming, 0);
-  if (OUTGOING_REGNO (REGNO (reg)) != REGNO (reg))
+  if (REG_P (incoming)
+  HARD_REGISTER_P (incoming)
+  OUTGOING_REGNO (REGNO (incoming)) != REGNO (incoming))
{
  parm_reg_t p;
- p.incoming = reg;
- reg = gen_raw_REG (GET_MODE (reg), OUTGOING_REGNO (REGNO (reg)));
- p.outgoing = reg;
+ p.incoming = incoming;
+ incoming
+   = gen_rtx_REG_offset (incoming, GET_MODE (incoming),
+ OUTGOING_REGNO (REGNO (incoming)), 0);
+ p.outgoing = incoming;
  vec_safe_push (windowed_parm_regs, p);
- incoming = replace_equiv_address_nv (incoming, reg);
+   }
+  else if (MEM_P (incoming)
+   REG_P (XEXP (incoming, 0))
+   HARD_REGISTER_P (XEXP (incoming, 0)))
+   {
+ rtx reg = XEXP (incoming, 0);
+ if (OUTGOING_REGNO (REGNO (reg)) != REGNO (reg))
+   {
+ parm_reg_t p;
+ p.incoming = reg;
+ reg = gen_raw_REG (GET_MODE (reg), OUTGOING_REGNO (REGNO (reg)));
+ p.outgoing = reg;
+ vec_safe_push (windowed_parm_regs, p);
+ incoming = replace_equiv_address_nv (incoming, reg);
+   }
}
 }
 #endif

Re: var-tracking wrt. leaf regs on sparc

[David Miller]

From: Jakub Jelinek ja...@redhat.com
Date: Thu, 7 Feb 2013 20:43:32 +0100

 This and earlier patch are ok, if it bootstraps/regtests fine, and suitable
 ChangeLog entry is provided.
 Running gdb testsuite before and after wouldn't hurt though.

I've done all of this, and committed to trunk and the gcc-4.7 branch,
thanks.

In looking at the remaining failures, several have to do with
an early clobber if the first incoming argument register.

The issue is that this is where return values are placed, so we run
into a situation where that incoming argument value can't be
reconstituted in any way by the variable tracking code and thus gdb
says that it has been optimized out.

Many non-x86 cpus are going to run into this problem.  For example,
from pr36728-1.c:

foo:
save%sp, -96, %sp
add %sp, -40, %sp
mov 2, %g2
add %sp, 123, %g1
mov 25, %g4
and %g1, -32, %g1
sethi   %hi(b), %g3
st  %g2, [%g1]
ld  [%fp+92], %g2
nop
ld  [%g1], %i0
add %g2, 14, %g2
and %g2, -8, %g2
sub %sp, %g2, %sp
stb %g4, [%sp+96]
add %sp, 96, %g2
sethi   %hi(a), %g4
nop
return  %i7+8
 nop

Here %i0 is written early, and then the tests can't view 'arg1'
properly later in the function.

Also, I noticed that calculation of the on-stack address of values
with alignment regressed in gcc-4.8 vs. gcc-4.7 Again, in pr36728-1.c,
'y' can be printed properly in gcc-4.7 but in gcc-4.8 it cannot.

I think it might be getting the base register wrong, I'll look
more deeply if I get a chance.

Re: [PATCH] Fix up get_reload_reg (PR rtl-optimization/56195)

[David Miller]

From: Jakub Jelinek ja...@redhat.com
Date: Fri, 8 Feb 2013 01:27:02 +0100

 +void
 +fn (void)
 +{
 +  if (b)
 +{
 +  int *p, *q;
 +  char g;
 +
 +  if (f++)
 + for (;; e++);
 +lbl:
 +  for (b = 0; b  2; b++)
 + t /= d + 1 ? : i || a  c  (d = f) ? : 1 | (j = 2);
 +
 +  *p = g = *q ^ c != a ^ *p;

I know this is just a testcase but it looks like both 'p' and 'q'
can be uninitialized at this point.

Re: var-tracking wrt. leaf regs on sparc

[David Miller]

From: Eric Botcazou ebotca...@adacore.com
Date: Wed, 06 Feb 2013 11:13:30 +0100

 I think testing crtl-uses_only_leaf_regs is sufficient here (and
 while you're at it, you could also test the value of
 HAVE_window_save, which can be 0 if -mflat is passed on the SPARC),
 so
 
 #ifdef HAVE_window_save
 if (HAVE_window_save  !crtl-uses_only_leaf_regs)
   {
 
   }
 #endif

Yes, this works perfectly, Jakub any objections?

gcc/

2013-02-06  David S. Miller  da...@davemloft.net

* var-tracking.c (vt_add_function_parameter): Test the presence of
HAVE_window_save properly and do not remap argument registers when
we have a leaf function.

diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c
index 714acb69..0db1562 100644
--- a/gcc/var-tracking.c
+++ b/gcc/var-tracking.c
@@ -9502,31 +9502,34 @@ vt_add_function_parameter (tree parm)
   /* DECL_INCOMING_RTL uses the INCOMING_REGNO of parameter registers.
  If the target machine has an explicit window save instruction, the
  actual entry value is the corresponding OUTGOING_REGNO instead.  */
-  if (REG_P (incoming)
-   HARD_REGISTER_P (incoming)
-   OUTGOING_REGNO (REGNO (incoming)) != REGNO (incoming))
+  if (HAVE_window_save  !crtl-uses_only_leaf_regs)
 {
-  parm_reg_t p;
-  p.incoming = incoming;
-  incoming
-   = gen_rtx_REG_offset (incoming, GET_MODE (incoming),
- OUTGOING_REGNO (REGNO (incoming)), 0);
-  p.outgoing = incoming;
-  vec_safe_push (windowed_parm_regs, p);
-}
-  else if (MEM_P (incoming)
-   REG_P (XEXP (incoming, 0))
-   HARD_REGISTER_P (XEXP (incoming, 0)))
-{
-  rtx reg = XEXP (incoming, 0);
-  if (OUTGOING_REGNO (REGNO (reg)) != REGNO (reg))
+  if (REG_P (incoming)
+  HARD_REGISTER_P (incoming)
+  OUTGOING_REGNO (REGNO (incoming)) != REGNO (incoming))
{
  parm_reg_t p;
- p.incoming = reg;
- reg = gen_raw_REG (GET_MODE (reg), OUTGOING_REGNO (REGNO (reg)));
- p.outgoing = reg;
+ p.incoming = incoming;
+ incoming
+   = gen_rtx_REG_offset (incoming, GET_MODE (incoming),
+ OUTGOING_REGNO (REGNO (incoming)), 0);
+ p.outgoing = incoming;
  vec_safe_push (windowed_parm_regs, p);
- incoming = replace_equiv_address_nv (incoming, reg);
+   }
+  else if (MEM_P (incoming)
+   REG_P (XEXP (incoming, 0))
+   HARD_REGISTER_P (XEXP (incoming, 0)))
+   {
+ rtx reg = XEXP (incoming, 0);
+ if (OUTGOING_REGNO (REGNO (reg)) != REGNO (reg))
+   {
+ parm_reg_t p;
+ p.incoming = reg;
+ reg = gen_raw_REG (GET_MODE (reg), OUTGOING_REGNO (REGNO (reg)));
+ p.outgoing = reg;
+ vec_safe_push (windowed_parm_regs, p);
+ incoming = replace_equiv_address_nv (incoming, reg);
+   }
}
 }
 #endif

Re: var-tracking wrt. leaf regs on sparc

[David Miller]

From: David Miller da...@davemloft.net
Date: Tue, 05 Feb 2013 18:18:39 -0500 (EST)

 The only other alternative I can see would be to get everything in
 var-tracking.c and the other subsystems it uses to do leaf register
 remapping, but that seems completely like the wrong way to handle
 this.

Following up to myself... :-)

Now that I understand fully what we're trying to accomplish with the
DT_OP_GNU_entry_value and DT_OP_GNU_call_site_parameter extensions, it
does in fact seem like we will need to do leaf register remapping in
var-tracking.c

Here below is a patch I'm playing with.  It's a rough draft but it
definitely fixes the pr54200.c problem completely.

Another way to do this would be to not translate the incoming
parameter registers (leave them at %i*) if we don't see the window
save.  That way we only have to play the regno remapping game for
these specific incoming argument pieces, rather than for everything we
look at in the RTL stream.

diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c
index 714acb69..14635b9 100644
--- a/gcc/var-tracking.c
+++ b/gcc/var-tracking.c
@@ -1057,6 +1057,32 @@ adjust_mem_stores (rtx loc, const_rtx expr, void *data)
 }
 }
 
+/* Given a regno from the RTL instruction stream, return the
+   actual register number that will be used by final and debug
+   info emission.  */
+static unsigned int
+real_regno (unsigned int regno)
+{
+#ifdef LEAF_REG_REMAP
+  if (regno  FIRST_PSEUDO_REGISTER
+   crtl-uses_only_leaf_regs)
+{
+  int remapped = LEAF_REG_REMAP (regno);
+
+  if (remapped = 0)
+   regno = (unsigned int) remapped;
+}
+#endif
+
+  return regno;
+}
+
+static unsigned int
+real_regno_rtx (rtx reg)
+{
+  return real_regno (REGNO (reg));
+}
+
 /* Simplify INSN.  Remove all {PRE,POST}_{INC,DEC,MODIFY} rtxes,
replace them with their value in the insn and add the side-effects
as other sets to the insn.  */
@@ -1804,12 +1830,12 @@ var_reg_decl_set (dataflow_set *set, rtx loc, enum 
var_init_status initialized,
   if (decl_p)
 dv = dv_from_decl (var_debug_decl (dv_as_decl (dv)));
 
-  for (node = set-regs[REGNO (loc)]; node; node = node-next)
+  for (node = set-regs[real_regno_rtx (loc)]; node; node = node-next)
 if (dv_as_opaque (node-dv) == dv_as_opaque (dv)
 node-offset == offset)
   break;
   if (!node)
-attrs_list_insert (set-regs[REGNO (loc)], dv, offset, loc);
+attrs_list_insert (set-regs[real_regno_rtx (loc)], dv, offset, loc);
   set_variable_part (set, loc, dv, offset, initialized, set_src, iopt);
 }
 
@@ -1875,7 +1901,7 @@ var_reg_delete_and_set (dataflow_set *set, rtx loc, bool 
modify,
   if (initialized == VAR_INIT_STATUS_UNKNOWN)
 initialized = get_init_value (set, loc, dv_from_decl (decl));
 
-  nextp = set-regs[REGNO (loc)];
+  nextp = set-regs[real_regno_rtx (loc)];
   for (node = *nextp; node; node = next)
 {
   next = node-next;
@@ -1904,7 +1930,7 @@ var_reg_delete_and_set (dataflow_set *set, rtx loc, bool 
modify,
 static void
 var_reg_delete (dataflow_set *set, rtx loc, bool clobber)
 {
-  attrs *nextp = set-regs[REGNO (loc)];
+  attrs *nextp = set-regs[real_regno_rtx (loc)];
   attrs node, next;
 
   if (clobber)
@@ -2386,7 +2412,7 @@ val_bind (dataflow_set *set, rtx val, rtx loc, bool 
modified)
   if (REG_P (loc))
 {
   if (modified)
-   var_regno_delete (set, REGNO (loc));
+   var_regno_delete (set, real_regno_rtx (loc));
   var_reg_decl_set (set, loc, VAR_INIT_STATUS_INITIALIZED,
dv_from_value (val), 0, NULL_RTX, INSERT);
 }
@@ -2584,7 +2610,7 @@ val_resolve (dataflow_set *set, rtx val, rtx loc, rtx 
insn)
 {
   attrs node, found = NULL;
 
-  for (node = set-regs[REGNO (loc)]; node; node = node-next)
+  for (node = set-regs[real_regno_rtx (loc)]; node; node = node-next)
if (dv_is_value_p (node-dv)
 GET_MODE (dv_as_value (node-dv)) == GET_MODE (loc))
  {
@@ -2838,7 +2864,8 @@ variable_union (variable src, dataflow_set *set)
{
  if (!((REG_P (node2-loc)
  REG_P (node-loc)
- REGNO (node2-loc) == REGNO (node-loc))
+ (real_regno_rtx (node2-loc)
+== real_regno_rtx (node-loc)))
|| rtx_equal_p (node2-loc, node-loc)))
{
  if (node2-init  node-init)
@@ -2871,7 +2898,8 @@ variable_union (variable src, dataflow_set *set)
  for (node = src-var_part[i].loc_chain; node; node = node-next)
if (!((REG_P (dstnode-loc)
REG_P (node-loc)
-   REGNO (dstnode-loc) == REGNO (node-loc))
+   (real_regno_rtx (dstnode-loc)
+  == real_regno_rtx (node-loc)))
  || rtx_equal_p (dstnode-loc, node-loc)))
  {
location_chain new_node;
@@ -2920,7 +2948,8

Re: patch to fix PR55775

[David Miller]

From: Vladimir Makarov vmaka...@redhat.com
Date: Fri, 21 Dec 2012 16:22:15 -0500

 2012-12-21  Vladimir Makarov  vmaka...@redhat.com
 
 PR middle-end/55775
 * lra-assigns.c (improve_inheritance): Do nothing after
 LRA_MAX_INHERITANCE_PASSES pass.
 * lra-constraints.c (MAX_CONSTRAINT_ITERATION_NUMBER): Rename to
 LRA_MAX_CONSTRAINT_ITERATION_NUMBER.  Move to lra-int.h.
 (MAX_INHERITANCE_PASSES): Rename to LRA_MAX_INHERITANCE_PASSES.
 Move to lra-int.h.
 * lra-int.h (LRA_MAX_CONSTRAINT_ITERATION_NUMBER): Move from
 lra-constraints.c.
 (LRA_MAX_INHERITANCE_PASSES): Ditto.

The changes to lra_inheritabnce() and lra_undo_inheritance() are not
listed.

Also, why is it OK to simply ignore the fact that a relaxation
algorithm is still making changes?  Shouldn't we be instead fixing
whatever prevents proper convergence?

Re: patch to fix PR55775

[David Miller]

From: Vladimir Makarov vmaka...@redhat.com
Date: Fri, 21 Dec 2012 17:04:34 -0500

 If I go this way, it will be another reload which is trying to do
 everything at once.  Also after 2 passes the inheritance improve code
 (as inheritance code itself) usually does nothing for big majority of
 programs.  It has no sense to run them all the time.  So for
 stability, LRA after a few iterations is trying to do only most
 important and necessary code for generation of the correct code.

Thanks for explaining.

Re: [SPARC] Fix PR target/54121

[David Miller]

From: Eric Botcazou ebotca...@adacore.com
Date: Tue, 11 Dec 2012 19:37:36 +0100

 This is a regression present on mainline and 4.7 branch for the SPARC.  
 Reload 
 is trying to change the value of a symbol(!) because it is mightily confused 
 by an output constraint on a source operand (old pasto in some TLS patterns).
 
 Fixed thusly, tested on SPARC64/Linux, applied on all branches.

Thanks for fixing this Eric.

Re: Sparc ASAN

[David Miller]

From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
Date: Tue, 27 Nov 2012 18:12:00 +0400

 On Wed, Nov 21, 2012 at 9:05 PM, Konstantin Serebryany
 konstantin.s.serebry...@gmail.com wrote:
 On Wed, Nov 21, 2012 at 8:40 PM, David Miller da...@davemloft.net wrote:
 From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
 Date: Wed, 21 Nov 2012 19:39:52 +0400

 There are various other things that asan library does not support.

 I'm trying to understand why making the page size variable
 is such a difficult endeavour.

 Maybe it's not *that* difficult.
 Looking at it carefully, the major problem I can see is that some
 other constants are defined based on this one.
 Give me a few days to resolve it...
 http://code.google.com/p/address-sanitizer/issues/detail?id=128
 
  http://gcc.gnu.org/viewcvs?root=gccview=revrev=193849 removes the
 kPageSize constant in favor of a function call.
 Please give it a try.
 
 BTW, libsanitizer now has a usable process to quickly pull the upstream 
 changes.
 It should make it easier for us to iterate on platform-specific patches.

So, with the hacks for unaligned accesses, Sparc seems to be working
here.

The only changes to libsantizier is to put __sparc__ checks where
__powerpc__ checks exist in the unwind code.

Are there any clear thoughts about what we should do in the end
wrt. the stack ASAN alignment issues?  Do we plan to 32-byte
align the stack variables or similar?  Otherwise we need to add
some ugly code to do half-word/byte at a time accesses, as needed.

Re: Sparc ASAN

[David Miller]

From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
Date: Mon, 3 Dec 2012 22:18:56 +0400

 On Mon, Dec 3, 2012 at 10:02 PM, David Miller da...@davemloft.net wrote:
 The only changes to libsantizier is to put __sparc__ checks where
 __powerpc__ checks exist in the unwind code.
 
 Like this?
 
 ===
 --- asan/asan_linux.cc  (revision 169136)
 +++ asan/asan_linux.cc  (working copy)
 @@ -158,7 +158,9 @@
stack-trace[0] = pc;
if ((max_s)  1) {
  stack-max_size = max_s;
 -#if defined(__arm__) || defined(__powerpc__) || defined(__powerpc64__)
 +#if defined(__arm__) || \
 +defined(__powerpc__) || defined(__powerpc64__) || \
 +defined(__sparc__)
  _Unwind_Backtrace(Unwind_Trace, stack);
  // Pop off the two ASAN functions from the backtrace.
  stack-PopStackFrames(2);

Yes, that's perfect.

We could also add a __sparc__ block to sanitizer_stacktrace.cc:patch_pc().
The Sparc PC is actually 8 bytes after the caller's jump.  Sparc has
a delay slot, the place to return to is 2 instructions after the call/jump,
and instructions are all 4 bytes long.

 We either need to align the redzones by 32 always, or for some platforms.
 Either is fine for me.

I'm ambivalent as well.

Re: Sparc ASAN

[David Miller]

From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
Date: Mon, 3 Dec 2012 22:33:12 +0400

 On Mon, Dec 3, 2012 at 10:29 PM, David Miller da...@davemloft.net wrote:
 We could also add a __sparc__ block to sanitizer_stacktrace.cc:patch_pc().
 The Sparc PC is actually 8 bytes after the caller's jump.  Sparc has
 a delay slot, the place to return to is 2 instructions after the call/jump,
 and instructions are all 4 bytes long.
 
 Like this?
 
 --- sanitizer_common/sanitizer_stacktrace.cc(revision 169136)
 +++ sanitizer_common/sanitizer_stacktrace.cc(working copy)
 @@ -36,6 +36,8 @@
  #if defined(__powerpc__) || defined(__powerpc64__)
// PCs are always 4 byte aligned.
return pc - 4;
 +#elif defined(__sparc__)
 +  return pc - 8;
  #else
return pc - 1;
  #endif
 

Perfect.

Re: Sparc ASAN

[David Miller]

From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
Date: Mon, 3 Dec 2012 22:44:15 +0400

 On Mon, Dec 3, 2012 at 10:37 PM, David Miller da...@davemloft.net wrote:
 From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
 Date: Mon, 3 Dec 2012 22:33:12 +0400

 On Mon, Dec 3, 2012 at 10:29 PM, David Miller da...@davemloft.net wrote:
 We could also add a __sparc__ block to sanitizer_stacktrace.cc:patch_pc().
 The Sparc PC is actually 8 bytes after the caller's jump.  Sparc has
 a delay slot, the place to return to is 2 instructions after the call/jump,
 and instructions are all 4 bytes long.

 Like this?

 --- sanitizer_common/sanitizer_stacktrace.cc(revision 169136)
 +++ sanitizer_common/sanitizer_stacktrace.cc(working copy)
 @@ -36,6 +36,8 @@
  #if defined(__powerpc__) || defined(__powerpc64__)
// PCs are always 4 byte aligned.
return pc - 4;
 +#elif defined(__sparc__)
 +  return pc - 8;
  #else
return pc - 1;
  #endif


 Perfect.
 
 http://llvm.org/viewvc/llvm-project?view=revrevision=169141
 Will reach gcc with the next libsanitizer merge (or feel free to
 commit the same patch directly to gcc).

Thanks for taking care of this.

Re: Sparc ASAN

[David Miller]

From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
Date: Wed, 21 Nov 2012 17:39:05 +0400

 Today, kPageSize is used in several places where it is expected to be
 a compile-time constant.
 Even if it seems like replacing it with GetPageSize() is safe, it
 would need very significant testing (including performance testing).
 Can we just define kPageSize=1UL13 under ifdef __sparc__?
 
 What are the possible page size values for SPARC?

4K, 8K, 64K, 512K

It's not a constant and the library really cannot expect it to be one.

Re: Sparc ASAN

[David Miller]

From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
Date: Wed, 21 Nov 2012 19:39:52 +0400

 There are various other things that asan library does not support.

I'm trying to understand why making the page size variable
is such a difficult endeavour.

Re: Sparc ASAN

[David Miller]

From: Peter Bergner berg...@vnet.ibm.com
Date: Wed, 21 Nov 2012 11:28:51 -0600

 On Tue, 2012-11-20 at 23:19 -0500, David Miller wrote:
 The address violation detection seems to work properly and the only
 thing that seems to be left are some backtrace/unwind issues.  These
 are perhaps similar to the unwind bits that the powerpc folks ran
 into.
 
 David, does the following patch (will have some fuzz since I removed
 one ppc only hunk from the patch) fix your backtrace issue?  I'll note
 you'll have to add || defined(__sparc__) to the #if ... or as
 it's probably going to turn out, just replace the whole thing
 with a #if !defined(__i386__)  !defined(__x86_64__).

This patch works well but I have some unrelated sanitizer sparc
issues to resolve before the testcase will pass properly.

Feel free to submit this with the __sparc__ cpp test added, or
the !x86 variant, at your discretion.

Re: Sparc ASAN

[David Miller]

From: David Miller da...@davemloft.net
Date: Wed, 21 Nov 2012 12:54:17 -0500 (EST)

 From: Peter Bergner berg...@vnet.ibm.com
 Date: Wed, 21 Nov 2012 11:28:51 -0600
 
 On Tue, 2012-11-20 at 23:19 -0500, David Miller wrote:
 The address violation detection seems to work properly and the only
 thing that seems to be left are some backtrace/unwind issues.  These
 are perhaps similar to the unwind bits that the powerpc folks ran
 into.
 
 David, does the following patch (will have some fuzz since I removed
 one ppc only hunk from the patch) fix your backtrace issue?  I'll note
 you'll have to add || defined(__sparc__) to the #if ... or as
 it's probably going to turn out, just replace the whole thing
 with a #if !defined(__i386__)  !defined(__x86_64__).
 
 This patch works well but I have some unrelated sanitizer sparc
 issues to resolve before the testcase will pass properly.
 
 Feel free to submit this with the __sparc__ cpp test added, or
 the !x86 variant, at your discretion.

Actually I looked more closely at this, and the trigger is hit one
stack frame too late on sparc.

The BP computed in the memcmp() interceptor is the frame pointer
%fp, but on sparc that's the CFA of the caller, main() in the
case of the memcmp-1.c testcase.

So only main() appears in the backtrace.

It might be easier to implement this by comparing the PC instead.

And it also occurs to me that we probably need to be using
__builtin_extract_return_addr() when recording the PC at the
error trigger point.

Re: Sparc ASAN

[David Miller]

From: Jakub Jelinek ja...@redhat.com
Date: Wed, 21 Nov 2012 21:30:37 +0100

 On Wed, Nov 21, 2012 at 03:27:16PM -0500, David Miller wrote:
 Actually I looked more closely at this, and the trigger is hit one
 stack frame too late on sparc.
 
 Are you testing with -fno-builtin-memcmp?  Without it the check is done
 directly in main...

I made sure that the error triggered in the ASAN memcmp interceptor,
please read the paragraph after the one you are quoting.

Re: Sparc ASAN

[David Miller]

From: Peter Bergner berg...@vnet.ibm.com
Date: Wed, 21 Nov 2012 17:46:57 -0600

 If you have a suggested change/patch that does that, let me know
 and I can try it out on powerpc to make sure it works for us too.

I will try to do so, but I am pretty sure at this point that
it will end up being some time early next week.

Re: sparc bootstrap still broken

[David Miller]

From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
Date: Tue, 20 Nov 2012 11:41:03 +0400

 Ok. Will this work?
 
 // Are we using 32-bit or 64-bit syscalls?
 // x32 (which defines __x86_64__) has __WORDSIZE == 32
 // but it still needs to use 64-bit syscalls.
 #if defined(__x86_64__) || __WORDSIZE == 64
 # define SANITIZER_LINUX_USES_64BIT_SYSCALLS 1
 #else
 # define SANITIZER_LINUX_USES_64BIT_SYSCALLS 0
 #endif

Of course, as it matches the test H.J. Liu's patch used.

Please, at a bare minimum, give him some credit for this fix.

Re: sparc bootstrap still broken

[David Miller]

From: Peter Bergner berg...@vnet.ibm.com
Date: Tue, 20 Nov 2012 12:08:00 -0600

 On Tue, 2012-11-20 at 13:00 +0400, Konstantin Serebryany wrote:
 On Tue, Nov 20, 2012 at 12:19 PM, David Miller da...@davemloft.net wrote:
  From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
  Date: Tue, 20 Nov 2012 11:41:03 +0400
 
  Ok. Will this work?
 
  // Are we using 32-bit or 64-bit syscalls?
  // x32 (which defines __x86_64__) has __WORDSIZE == 32
  // but it still needs to use 64-bit syscalls.
  #if defined(__x86_64__) || __WORDSIZE == 64
  # define SANITIZER_LINUX_USES_64BIT_SYSCALLS 1
  #else
  # define SANITIZER_LINUX_USES_64BIT_SYSCALLS 0
  #endif
 
  Of course, as it matches the test H.J. Liu's patch used.
 
  Please, at a bare minimum, give him some credit for this fix.
 
 Done: http://llvm.org/viewvc/llvm-project?rev=168358view=rev
 
 I assume we are just waiting for someone to commit this to the GCC src,
 correct?  David (Miller), were you going to do that?  I'd like that
 change committed before I commit our ppc asan changes.

The problem is there are other dependencies in those two commits, the
change doesn't apply cleanly.

This situation is a very serious mess, and a merge burdon like this
really shouldn't fall upon the gcc community at large.

Re: sparc bootstrap still broken

[David Miller]

From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
Date: Tue, 20 Nov 2012 23:02:36 +0400

 I really need your help to resolve this mess.

I thought it was abundantly clear that the burdon falls upon the ASAN
folks, since they are the ones who care about the external dependency.

Nobody else inside of the GCC community cares about that.

Other examples of identical situations were given, including libffi
and GO.  Where it is %100 up to the maintainer of those modules to
deal with the merge hassles created by the external dependency, and to
shield the GCC development process completely from any part of that.

Finally, a bugzilla entry with a very limited audience is absolutely
not the appropriate place to discuss this issue.  The GCC mailing
lists are.

Re: sparc bootstrap still broken

[David Miller]

From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
Date: Tue, 20 Nov 2012 23:19:51 +0400

 On Tue, Nov 20, 2012 at 11:09 PM, David Miller da...@davemloft.net wrote:
 From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
 Date: Tue, 20 Nov 2012 23:02:36 +0400

 I really need your help to resolve this mess.

 I thought it was abundantly clear that the burdon falls upon the ASAN
 folks, since they are the ones who care about the external dependency.

 Nobody else inside of the GCC community cares about that.
 
 If nobody else in the GCC community cares about ASAN, we should
 disable the SPARC build and
 let us handle the issue without rush.
 We are interested in SPARC, but much less than in our own sanity.

I am saying that nobody has a direct interest in the LLVM
dependencies, therefore they are entirely your responsibility.  Please
don't twist my words.

Everyone in the GCC community cares that core features are supported
on as many targets as possible.

Re: sparc bootstrap still broken

[David Miller]

From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
Date: Tue, 20 Nov 2012 23:52:48 +0400

 Please apply whatever minimal patch required to unbreak the SPARC
 build.  We will not be accepting any non-trivial patches until we
 set up semi-automated way to pull the upstream sources.

Will do.

[PATCH] Fix sanitizer build on sparc64.

[David Miller]

[ Sorry, flubbed the gcc-patches address the first time. ]

libsanitizer/

* sanitizer_common/sanitizer_linux.cc
(SANITIZER_LINUX_USES_64BIT_SYSCALLS): Define.
(internal_mmap): Use it.
(internal_filesize): Likewise.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@193676 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 libsanitizer/ChangeLog   |  7 +++
 libsanitizer/sanitizer_common/sanitizer_linux.cc | 13 +++--
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/libsanitizer/ChangeLog b/libsanitizer/ChangeLog
index 7aade50..22f65b2 100644
--- a/libsanitizer/ChangeLog
+++ b/libsanitizer/ChangeLog
@@ -1,3 +1,10 @@
+2012-11-20  Konstantin Serebryany  konstantin.s.serebry...@gmail.com
+
+   * sanitizer_common/sanitizer_linux.cc
+   (SANITIZER_LINUX_USES_64BIT_SYSCALLS): Define.
+   (internal_mmap): Use it.
+   (internal_filesize): Likewise.
+
 2012-11-16  Tom Tromey  tro...@redhat.com
 
* configure.ac: Invoke AM_MAINTAINER_MODE.
diff --git a/libsanitizer/sanitizer_common/sanitizer_linux.cc 
b/libsanitizer/sanitizer_common/sanitizer_linux.cc
index e90a68c..f2a0d39 100644
--- a/libsanitizer/sanitizer_common/sanitizer_linux.cc
+++ b/libsanitizer/sanitizer_common/sanitizer_linux.cc
@@ -29,12 +29,21 @@
 #include unistd.h
 #include errno.h
 
+// Are we using 32-bit or 64-bit syscalls?
+// x32 (which defines __x86_64__) has __WORDSIZE == 32
+// but it still needs to use 64-bit syscalls.
+#if defined(__x86_64__) || __WORDSIZE == 64
+# define SANITIZER_LINUX_USES_64BIT_SYSCALLS 1
+#else
+# define SANITIZER_LINUX_USES_64BIT_SYSCALLS 0
+#endif
+
 namespace __sanitizer {
 
 // --- sanitizer_libc.h
 void *internal_mmap(void *addr, uptr length, int prot, int flags,
 int fd, u64 offset) {
-#if defined __x86_64__
+#if SANITIZER_LINUX_USES_64BIT_SYSCALLS
   return (void *)syscall(__NR_mmap, addr, length, prot, flags, fd, offset);
 #else
   return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset);
@@ -67,7 +76,7 @@ uptr internal_write(fd_t fd, const void *buf, uptr count) {
 }
 
 uptr internal_filesize(fd_t fd) {
-#if defined __x86_64__
+#if SANITIZER_LINUX_USES_64BIT_SYSCALLS
   struct stat st;
   if (syscall(__NR_fstat, fd, st))
 return -1;
-- 
1.7.12.2.dirty

Sparc ASAN (was Re: sparc bootstrap still broken)

[David Miller]

From: David Miller da...@davemloft.net
Date: Tue, 20 Nov 2012 14:59:10 -0500 (EST)

 From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
 Date: Tue, 20 Nov 2012 23:52:48 +0400
 
 Please apply whatever minimal patch required to unbreak the SPARC
 build.  We will not be accepting any non-trivial patches until we
 set up semi-automated way to pull the upstream sources.
 
 Will do.

I tossed together a quick sparc implementation and there seems to
be only two issues to fix:

1) As noticed by the powerpc people, you have to probe the page
   size of the system properly.  It's variable even within a
   target/OS.

   Probably a new hook, implemented in asan_linux.cc via:

#include unistd.h

uptr GetPageSize()
{
  return getpagesize();
}

   I would just get rid of kPageSizeBits, rather than compute it
   dynamically as well, as it's really not used as far as I can tell.

   The mmap of the shadow area won't work on sparc without this being
   resolved.

2) The current code emitted to set the shadow values results in
   unaligned stores.  For example, for the memcmp-1.c test on 32-bit
   we get:

   0x10488 main+8:add  %fp, -160, %i5
 ...
   0x10490 main+16:   sethi  %hi(0xf1f1f000), %g2
 ...
   0x104a0 main+32:   srl  %i5, 3, %i5
 ...
   0x104a8 main+40:   or  %g2, 0x1f1, %g2
   0x104ac main+44:   sethi  %hi(0x2000), %g1
 ...
= 0x104b4 main+52:   st  %g2, [ %i5 + %g1 ]

   Here %fp is 0xd538, and this %i5 + %g1 is 0x3a93, which
   is not aligned properly for a 32-bit store.

   Therefore, this won't work for any STRICT_ALIGNMENT target.

Those seem to be the only problems that need to be resolved for this
feature to be fully working.

Re: Sparc ASAN

[David Miller]

From: David Miller da...@davemloft.net
Date: Tue, 20 Nov 2012 21:20:40 -0500 (EST)

 Those seem to be the only problems that need to be resolved for this
 feature to be fully working.

FWIW, here are the changes I am using which, besides the sparc backend
bits, has some temporary workarounds for the issues I brought up.

The address violation detection seems to work properly and the only
thing that seems to be left are some backtrace/unwind issues.  These
are perhaps similar to the unwind bits that the powerpc folks ran
into.

diff --git a/gcc/asan.c b/gcc/asan.c
index bd90e0a..d9b3f1b 100644
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -321,7 +321,10 @@ asan_emit_stack_protection (rtx base, HOST_WIDE_INT 
*offsets, tree *decls,
  NULL_RTX, 1, OPTAB_DIRECT);
   gcc_assert (asan_shadow_set != -1
   (ASAN_RED_ZONE_SIZE  ASAN_SHADOW_SHIFT) == 4);
-  shadow_mem = gen_rtx_MEM (SImode, shadow_base);
+  if (STRICT_ALIGNMENT)
+shadow_mem = gen_rtx_MEM (QImode, shadow_base);
+  else
+shadow_mem = gen_rtx_MEM (SImode, shadow_base);
   set_mem_alias_set (shadow_mem, asan_shadow_set);
   prev_offset = base_offset;
   for (l = length; l; l -= 2)
@@ -349,7 +352,20 @@ asan_emit_stack_protection (rtx base, HOST_WIDE_INT 
*offsets, tree *decls,
  }
else
  shadow_bytes[i] = ASAN_STACK_MAGIC_PARTIAL;
- emit_move_insn (shadow_mem, asan_shadow_cst (shadow_bytes));
+ if (STRICT_ALIGNMENT)
+   {
+ for (i = 0; i  4; i++)
+   {
+ rtx mem = adjust_address (shadow_mem, VOIDmode, i);
+ rtx val;
+
+ val = GEN_INT (trunc_int_for_mode (shadow_bytes[i],
+QImode));
+ emit_move_insn (mem, val);
+   }
+   }
+ else
+   emit_move_insn (shadow_mem, asan_shadow_cst (shadow_bytes));
  offset = aoff;
}
   while (offset = offsets[l - 2] - ASAN_RED_ZONE_SIZE)
@@ -359,7 +375,22 @@ asan_emit_stack_protection (rtx base, HOST_WIDE_INT 
*offsets, tree *decls,
ASAN_SHADOW_SHIFT);
  prev_offset = offset;
  memset (shadow_bytes, cur_shadow_byte, 4);
- emit_move_insn (shadow_mem, asan_shadow_cst (shadow_bytes));
+ if (STRICT_ALIGNMENT)
+   {
+ int i;
+
+ for (i = 0; i  4; i++)
+   {
+ rtx mem = adjust_address (shadow_mem, VOIDmode, i);
+ rtx val;
+
+ val = GEN_INT (trunc_int_for_mode (shadow_bytes[i],
+QImode));
+ emit_move_insn (mem, val);
+   }
+   }
+ else
+   emit_move_insn (shadow_mem, asan_shadow_cst (shadow_bytes));
  offset += ASAN_RED_ZONE_SIZE;
}
   cur_shadow_byte = ASAN_STACK_MAGIC_MIDDLE;
diff --git a/gcc/config/sparc/sparc.c b/gcc/config/sparc/sparc.c
index 4e9de98..7bcc815 100644
--- a/gcc/config/sparc/sparc.c
+++ b/gcc/config/sparc/sparc.c
@@ -600,6 +600,7 @@ static void sparc_print_operand_address (FILE *, rtx);
 static reg_class_t sparc_secondary_reload (bool, rtx, reg_class_t,
   enum machine_mode,
   secondary_reload_info *);
+static unsigned HOST_WIDE_INT sparc_asan_shadow_offset (void);
 
 #ifdef SUBTARGET_ATTRIBUTE_TABLE
 /* Table of valid machine attributes.  */
@@ -754,6 +755,9 @@ char sparc_hard_reg_printed[8];
 #undef TARGET_OPTION_OVERRIDE
 #define TARGET_OPTION_OVERRIDE sparc_option_override
 
+#undef TARGET_ASAN_SHADOW_OFFSET
+#define TARGET_ASAN_SHADOW_OFFSET sparc_asan_shadow_offset
+
 #if TARGET_GNU_TLS  defined(HAVE_AS_SPARC_UA_PCREL)
 #undef TARGET_ASM_OUTPUT_DWARF_DTPREL
 #define TARGET_ASM_OUTPUT_DWARF_DTPREL sparc_output_dwarf_dtprel
@@ -11034,6 +11038,14 @@ get_some_local_dynamic_name_1 (rtx *px, void *data 
ATTRIBUTE_UNUSED)
   return 0;
 }
 
+/* Implement the TARGET_ASAN_SHADOW_OFFSET hook.  */
+
+static unsigned HOST_WIDE_INT
+sparc_asan_shadow_offset (void)
+{
+  return (unsigned HOST_WIDE_INT) 1  (TARGET_ARCH64 ? 44 : 29);
+}
+
 /* This is called from dwarf2out.c via TARGET_ASM_OUTPUT_DWARF_DTPREL.
We need to emit DTP-relative relocations.  */
 
diff --git a/libsanitizer/sanitizer_common/sanitizer_common.h 
b/libsanitizer/sanitizer_common/sanitizer_common.h
index cddefd7..00628fc 100644
--- a/libsanitizer/sanitizer_common/sanitizer_common.h
+++ b/libsanitizer/sanitizer_common/sanitizer_common.h
@@ -21,7 +21,7 @@ namespace __sanitizer {
 // Constants.
 const uptr kWordSize = __WORDSIZE / 8;
 const uptr kWordSizeInBits = 8 * kWordSize;
-const uptr kPageSizeBits = 12;
+const uptr kPageSizeBits = 13;
 const uptr kPageSize = 1UL  kPageSizeBits;
 const uptr kCacheLineSize = 64;
 #ifndef _WIN32

sparc bootstrap still broken

[David Miller]

I don't think it's reasonable that the sparc bootstrap is still broken
in the tree, even though a fix has existed for nearly a week.

It is not acceptable to say everyone has to apply a special patch
until some external dependency that will take an unknown, variable,
length of time to resolve is out of the way

This is exactly why changes should be installed directly into the
GCC sources as soon as they are ready, and the current way things
are being handled with ASAN is beyond unacceptable.

I'm very tempted to just commit the build fix in myself at this point.

Re: sparc bootstrap still broken

[David Miller]

From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
Date: Tue, 20 Nov 2012 09:20:29 +0400

 Please do (the same that was applied upstream).

Which one was that?

 Please also note:
   - I am on vacation with random access to PC, that's why I did not
 want to rush with my first commits to gcc trunk.

This is actually another argument for not having external dependencies
on fixing ASAN problems directly in the GCC sources.

   - asan for SPARC is not known to work at all (is it?) and thus a
 simpler fix might be to disable it for now.

I asked for the code to be enabled, because this code should be
portable to all Linux systems and I also plan to work on Sparc support
as the backend bits doesn't look terribly difficult (and this is
largely proven by how fast the powerpc port was written).

But this fix also cures problems on supported targets.

Re: sparc bootstrap still broken

[David Miller]

From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
Date: Tue, 20 Nov 2012 09:34:14 +0400

 On Tue, Nov 20, 2012 at 9:26 AM, David Miller da...@davemloft.net wrote:
 From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
 Date: Tue, 20 Nov 2012 09:20:29 +0400

 Please do (the same that was applied upstream).

 Which one was that?
 http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/sanitizer_common/sanitizer_linux.cc?r1=168301r2=168300pathrev=168301

That change is broken and will not work.

There is no such CPP define as __sparc64__

You have to check __sparc__  __arch64__

HJ's patch was more concise and actually works for all known
targets supported by both GCC and LLVM combined.

It is also likely to just work out of the box for new targets as well.

Whereas your version of the fix is higher maintainence in the long run
since it creates yet another spot where each new 64-bit target has to
place a target specific check.

Re: [PATCH] Enable building of libsanitizer on sparc linux again.

[David Miller]

From: Eric Botcazou ebotca...@adacore.com
Date: Sun, 18 Nov 2012 00:18:15 +0100

 error: '__NR_mmap2' was not declared in this scope
return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, offset);

The people making libsanitizer changes are really going to have to
stop making i386 specific changes to these generic files.

Specifically, in this case, they are checking for whether mmap2 is
available using __x86_64__ cpp tests.  A more appropriate test is
necessary.

Oh nevermind, H.J. Liu added this build regression, I should have
known.

H.J., either fix or revert this code back to using __WORDSIZE if you
cannot come up with an appropriate test.

Re: [PATCH] Enable building of libsanitizer on sparc linux again.

[David Miller]

From: H.J. Lu hjl.to...@gmail.com
Date: Sat, 17 Nov 2012 16:06:23 -0800

 On Sat, Nov 17, 2012 at 4:04 PM, David Miller da...@davemloft.net wrote:
 From: Eric Botcazou ebotca...@adacore.com
 Date: Sun, 18 Nov 2012 00:18:15 +0100

 error: '__NR_mmap2' was not declared in this scope
return (void *)syscall(__NR_mmap2, addr, length, prot, flags, fd, 
 offset);

 The people making libsanitizer changes are really going to have to
 stop making i386 specific changes to these generic files.

 Specifically, in this case, they are checking for whether mmap2 is
 available using __x86_64__ cpp tests.  A more appropriate test is
 necessary.

 Oh nevermind, H.J. Liu added this build regression, I should have
 known.

 H.J., either fix or revert this code back to using __WORDSIZE if you
 cannot come up with an appropriate test.
 
 Please follow:
 
 http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00951.html

The whole way this libsanitizer merge is being handled is
beyond unreasonable.

A build fix being held up for 4 days just proves that requiring things
get merged into LLVM first is completely the wrong way for this stuff
to work.

The people who merged in this library should be responsible for
keeping changes in sync, not the individual developers who fix bugs
and make improvements to this code on the gcc side.

It's lunacy that this build problem is in the tree for 4 days because
of this.

Re: [PATCH] Enable building of libsanitizer on sparc linux again.

[David Miller]

From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
Date: Sat, 17 Nov 2012 19:01:56 -0800

 I am open to suggestions on how to avoid forking the two versions.
 If we fork, the original asan team will not be able to cope with two
 repositories.

The maintainer of the sanitizer's job is to do the merging and resolve
the conflicts between the two trees.  This is how every other similar
situation is handled.

What's happening here, frankly, is garbage.

The current situation is unacceptable and HJ's fix should go into the
GCC tree right now.

The current situation is preventing people from getting work done, and
unnecessarily consuming developer resources.

Re: [PATCH] Enable building of libsanitizer on sparc linux again.

[David Miller]

From: Konstantin Serebryany konstantin.s.serebry...@gmail.com
Date: Sat, 17 Nov 2012 19:17:17 -0800

 I'd prefer to mention the ARCHs explicitly where possible, i.e.
   #if defined(__x86_64__) || definde (__sparc64__)
 instead of
#if __WORDSIZE == 64 || ...

You really do need to check __x86_64__ as well the word size, in order
to distinguish x32 from traditional x86-64.

So no, it is not possible to just use an ARCH check all by itself
to handle this case.

Therefore, HJ's check is the correct check, and mirrors similar
existing checks elsewhere in the tree (f.e. libffi).

Re: [PATCH] Enable building of libsanitizer on sparc linux again.

[David Miller]

From: Diego Novillo dnovi...@google.com
Date: Sat, 17 Nov 2012 22:26:24 -0500

 We have some new maintainers that are trying to understand how the
 system works.

Wouldn't we have someone become at least roughly familiar with these
kinds of things before we allow them to commit such an invasive set of
changes which have a non-trivial effect on pretty much everyone?

You cannot get around the fact that this was all handled poorly.

Re: [PATCH] Enable building of libsanitizer on sparc linux again.

[David Miller]

From: Andrew Pinski pins...@gmail.com
Date: Sat, 17 Nov 2012 19:34:34 -0800

 (glibc is the best at doing this).

It also uses make in pretty much the most inefficient way possible,
by causing it to consider 10s of thousands of prefix rules for every
rule target.

GLIBC has the same ifdef check that is being suggested here in various
places.

Re: [PATCH v4] Add support for sparc fused compare-and-branch.

[David Miller]

From: Eric Botcazou ebotca...@adacore.com
Date: Thu, 15 Nov 2012 09:16:26 +0100

 The bootstrap comparison failure no longer happens, and this is fully
 regstrapped on sparc-linux-gnu w/--with-cpu=niagara4, and I also did a
 quick bootstrap check using --with-cpu=niagara3.
 
 Eric, any objections to committing this?
 
 Only a minor one:
 
 @@ -1088,7 +1093,12 @@ sparc_option_override (void)
if (TARGET_VIS3)
  target_flags |= MASK_VIS2 | MASK_VIS;
 
 -  /* Don't allow -mvis, -mvis2, -mvis3, or -mfmaf if FPU is disabled.  */
 +  /* -mcbcond implies -mvis3, -mvis2 and -mvis */
 +  if (TARGET_CBCOND)
 +target_flags |= MASK_VIS3 | MASK_VIS2 | MASK_VIS;
 
 We agreed to drop this part and consequently...

Oh yes, forgot to trim this and update the docs.  I'll fix that up
right now.

 Thanks for persevering in getting this through despite all the
 roadblocks. ;-)

Thanks for reviewing.

I'll commit the result after a quick re-regstrap.

Thanks again.

Re: [PATCH] Enable building of libsanitizer on sparc linux again.

[David Miller]

From: Dodji Seketeli do...@redhat.com
Date: Thu, 15 Nov 2012 11:56:40 +0100

 David Miller da...@davemloft.net wrote
 
 From: Dodji Seketeli do...@redhat.com
 Date: Wed, 14 Nov 2012 14:26:40 +0100
 
  I guess we could do that.  That would build libsanitizer, but asan will
  still not be available on sparc if the asan_shadow_offset() target hook
  is not provided.  Is that OK to you?
 
 Yes.
 
 So, here is the (IMO obvious) patch to enable libsanitizer's build on
 sparc linux, even if asan is not supported on that platform yet.
 
 OK for trunk?

I'm fine with it.

Re: expansion of vector shifts...

[David Miller]

From: Richard Sandiford rdsandif...@googlemail.com
Date: Mon, 29 Oct 2012 10:14:53 +

 ...given that the code is like you say written:
 
   if (SHIFT_COUNT_TRUNCATED)
 {
   if (CONST_INT_P (op1)
 ...
   else if (GET_CODE (op1) == SUBREG
   subreg_lowpart_p (op1)
   INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1
   op1 = SUBREG_REG (op1);
 }
 
 INTEGRAL_MODE_P (GET_MODE (op1)) might be better than an explicit
 VECTOR_MODE_P check.  The code really doesn't make sense for anything
 other than integers.
 
 (It amounts to the same thing in practice, of course...)

Agreed, I've just committed the following.  Thanks!


Fix gcc.c-torture/compile/pr53410-2.c on sparc.

* expmed.c (expand_shift_1): Don't strip non-integral SUBREGs.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@193547 
138bc75d-0d04-0410-961f-82ee72b054a4
---
 gcc/ChangeLog | 2 ++
 gcc/expmed.c  | 3 ++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 9abd396..62bde4e 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,7 @@
 2012-11-15  David S. Miller  da...@davemloft.net
 
+   * expmed.c (expand_shift_1): Don't strip non-integral SUBREGs.
+
* configure.ac: Add check for assembler SPARC4 instruction
support.
* configure: Rebuild.
diff --git a/gcc/expmed.c b/gcc/expmed.c
index 5b697a1..8640427 100644
--- a/gcc/expmed.c
+++ b/gcc/expmed.c
@@ -2165,7 +2165,8 @@ expand_shift_1 (enum tree_code code, enum machine_mode 
mode, rtx shifted,
   % GET_MODE_BITSIZE (mode));
   else if (GET_CODE (op1) == SUBREG
subreg_lowpart_p (op1)
-   INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1
+   INTEGRAL_MODE_P (GET_MODE (SUBREG_REG (op1)))
+   INTEGRAL_MODE_P (GET_MODE (op1)))
op1 = SUBREG_REG (op1);
 }
 
-- 
1.7.12.2.dirty

Re: ASAN merge...

[David Miller]

From: Dodji Seketeli do...@redhat.com
Date: Wed, 14 Nov 2012 14:26:40 +0100

 I guess we could do that.  That would build libsanitizer, but asan will
 still not be available on sparc if the asan_shadow_offset() target hook
 is not provided.  Is that OK to you?

Yes.

Re: [patch] [sparc] add multiarch definitions for sparc-linux-gnu

[David Miller]

From: Matthias Klose d...@ubuntu.com
Date: Wed, 14 Nov 2012 23:36:17 +0100

 The following patch adds the multiarch definitions for sparc-linux-gnu. Tested
 using a Debian/Ubuntu package build. Ok for the trunk?

I'm fine with this.

[PATCH v4] Add support for sparc fused compare-and-branch.

[David Miller]

This integrates the Solaris2 work from Eric Botcazou, and has
some changes based upon feedback from Richard Henderson.

The bootstrap comparison failure no longer happens, and this is fully
regstrapped on sparc-linux-gnu w/--with-cpu=niagara4, and I also did a
quick bootstrap check using --with-cpu=niagara3.

Eric, any objections to committing this?

Thanks!

gcc/

2012-11-12  David S. Miller  da...@davemloft.net

* configure.ac: Add check for assembler SPARC4 instruction
support.
* configure: Rebuild.
* config.in: Add HAVE_AS_SPARC4 section.
* config/sparc/sparc.opt (mcbcond): New option.
* doc/invoke.texi: Document it.
* config/sparc/constraints.md: New constraint 'A' for 5-bit signed
immediates.
* doc/md.texi: Document it.
* config/sparc/sparc.c (dump_target_flag_bits): Handle MASK_CBCOND.
(sparc_option_override): Likewise.
(emit_cbcond_insn): New function.
(emit_conditional_branch_insn): Call it.
(emit_cbcond_nop): New function.
(output_ubranch): Use cbcond, remove label arg.
(output_cbcond): New function.
* config/sparc/sparc-protos.h (output_ubranch): Update.
(output_cbcond): Declare it.
(emit_cbcond_nop): Likewise.
* config/sparc/sparc.md (type attribute): New types 'cbcond'
and uncond_cbcond.
(emit_cbcond_nop): New attribute.
(length attribute): Handle cbcond and uncond_cbcond.
(in_call_delay attribute): Reject cbcond and uncond_cbcond.
(in_branch_delay attribute): Likewise.
(in_uncond_branch_delay attribute): Likewise.
(in_annul_branch_delay attribute): Likewise.
(*cbcond_sp32, *cbcond_sp64): New insn patterns.
(jump): Rewrite into an expander.
(*jump_ubranch, *jump_cbcond): New patterns.
* config/sparc/niagara4.md: Match 'cbcond' in 'n4_cti'.
* config/sparc/sparc.h (AS_NIAGARA4_FLAG): New macro, use it
when target default is niagara4.
(SPARC_SIMM5_P): Define.
* config/sparc/sol2.h (AS_SPARC64_FLAG): Adjust.
(AS_SPARC32_FLAG): Define.
(ASM_CPU32_DEFAULT_SPEC, ASM_CPU64_DEFAULT_SPEC): Use
AS_NIAGARA4_FLAG as needed.
---
 gcc/config.in   |   6 +
 gcc/config/sparc/constraints.md |   7 +-
 gcc/config/sparc/niagara4.md|   6 +-
 gcc/config/sparc/predicates.md  |   8 ++
 gcc/config/sparc/sol2.h |  95 +--
 gcc/config/sparc/sparc-protos.h |   4 +-
 gcc/config/sparc/sparc.c| 249 ++--
 gcc/config/sparc/sparc.h|  13 ++-
 gcc/config/sparc/sparc.md   |  81 +++--
 gcc/config/sparc/sparc.opt  |   4 +
 gcc/configure   |  42 +++
 gcc/configure.ac|  18 +++
 gcc/doc/invoke.texi |  11 ++
 gcc/doc/md.texi |   3 +
 14 files changed, 485 insertions(+), 62 deletions(-)

diff --git a/gcc/config.in b/gcc/config.in
index ee2a4d8..7038906 100644
--- a/gcc/config.in
+++ b/gcc/config.in
@@ -266,6 +266,12 @@
 #endif
 
 
+/* Define if your assembler supports SPARC4 instructions. */
+#ifndef USED_FOR_TARGET
+#undef HAVE_AS_SPARC4
+#endif
+
+
 /* Define if your assembler supports fprnd. */
 #ifndef USED_FOR_TARGET
 #undef HAVE_AS_FPRND
diff --git a/gcc/config/sparc/constraints.md b/gcc/config/sparc/constraints.md
index 8963a31..525e3ac 100644
--- a/gcc/config/sparc/constraints.md
+++ b/gcc/config/sparc/constraints.md
@@ -18,7 +18,7 @@
 ;; http://www.gnu.org/licenses/.
 
 ;;; Unused letters:
-;;;AB
+;;; B
 ;;;ajklq  tuv xyz
 
 
@@ -58,6 +58,11 @@
 
 ;; Integer constant constraints
 
+(define_constraint A
+ Signed 5-bit integer constant
+ (and (match_code const_int)
+  (match_test SPARC_SIMM5_P (ival
+
 (define_constraint H
  Valid operand of double arithmetic operation
  (and (match_code const_double)
diff --git a/gcc/config/sparc/niagara4.md b/gcc/config/sparc/niagara4.md
index 272c8ff..26f2391 100644
--- a/gcc/config/sparc/niagara4.md
+++ b/gcc/config/sparc/niagara4.md
@@ -54,10 +54,10 @@
 (eq_attr type store,fpstore))
   (n4_slot0 | n4_slot2) + n4_load_store)
 
-(define_insn_reservation n4_cti 2
+(define_insn_reservation n4_cti 1
   (and (eq_attr cpu niagara4)
-(eq_attr type 
branch,call,sibcall,call_no_delay_slot,uncond_branch,return))
-  n4_slot1, nothing)
+(eq_attr type 
cbcond,uncond_cbcond,branch,call,sibcall,call_no_delay_slot,uncond_branch,return))
+  n4_slot1)
 
 (define_insn_reservation n4_fp 11
   (and (eq_attr cpu niagara4)
diff --git a/gcc/config/sparc/predicates.md b/gcc/config/sparc/predicates.md
index 326524b..b64e109 100644
--- a/gcc/config/sparc/predicates.md
+++ b/gcc/config/sparc/predicates.md
@@ -391,6 +391,14 @@
   (ior (match_operand 0 register_operand)
(match_operand 0 uns_small_int_operand)))
 
+;; Return true if OP is a register, or is a CONST_INT that can fit in a
+;; signed 5-bit 

Re: ASAN merge...

[David Miller]

From: Diego Novillo dnovi...@google.com
Date: Tue, 13 Nov 2012 11:21:59 -0500

 On Tue, Nov 13, 2012 at 12:07 AM, David Miller da...@davemloft.net wrote:

 This has broken the build on every Linux target that hasn't added
 the necessary cpu specific code to asan_linux.cc
 
 This should be fixed by Dodji's recent patch.  ASAN is not currently
 ported to any target other than x86/linux, so it should just be
 completely disabled until the other ports start showing up.
 
 Dodji is your patch committed?

So I wasted my time by writing the sparc bits necessary to fix
the build?

Please leave enabled the platforms that do actually build.

Thanks.

Re: [PATCH v3] Add support for sparc compare-and-branch

[David Miller]

From: Eric Botcazou ebotca...@adacore.com
Date: Tue, 13 Nov 2012 20:32:40 +0100

 Working on this, I discovered an oddity in GNU as: -xarch=sparc4 -64 yields a 
 64-bit object file whereas -64 -xarch=sparc4 yields a 32-bit object file.  My 
 understanding is that Sun as will generate a 64-bit object file in both cases.

Thanks for finding this, that's definitely incorrect behavior.  I bet there
is some unintended override triggered by sparc4 selection, and I'll go and
fix that soon.

Re: [PATCH v3] Add support for sparc compare-and-branch

[David Miller]

From: Eric Botcazou ebotca...@adacore.com
Date: Tue, 13 Nov 2012 22:50:49 +0100

 Thanks for finding this, that's definitely incorrect behavior.  I bet there
 is some unintended override triggered by sparc4 selection, and I'll go and
 fix that soon.
 
 You're welcome.  That's the reason why I needed to go the ASM_ARCH way, the 
 straightforward approach would have put the -32/-64 first.

Right.  And meanwhile I found the problem, there is this code block in
the Sparc option parser of GAS that goes:

case OPTION_XARCH:
#ifdef OBJ_ELF
  if (strncmp (arg, v9, 2) != 0)
md_parse_option (OPTION_32, NULL);
  else
md_parse_option (OPTION_64, NULL);
#endif
  /* Fall through.  */

And that's where the unexpected size override is happening.  That test
simply needs to be adjusted and I'll try to sort that out tonight.

 And I managed to miss a substitution in the previous patch, so please drop it 
 and use the attached one instead.

Thanks for this, I was just starting to work on integrating our work
together and debugging the result.

Re: [PATCH v3] Add support for sparc compare-and-branch

[David Miller]

From: Rainer Orth r...@cebitec.uni-bielefeld.de
Date: Mon, 12 Nov 2012 16:46:37 +0100

 Eric Botcazou ebotca...@adacore.com writes:
 
 No, quite the contrary.  as is just a (sometimes partial) backport of
 Studio fbe, though it's hard to tell exactly which Studio version of fbe
 forms the basis of as.  Especially for the Solaris 10 as patches, only
 particular bugfixes/enhancements have been backported.
 
 Backward compatibility is maintained, of course.  as(1) lists
 
  -xarch=v9
 
  Equivalent to: -m64 -xarch=sparc
 
 and many more.

 Does it list -xarch=v8pluse/-xarch=v9e as equivalent to -m32/64 
 -xarch=sparc4?
 If so, I don't think that we need to change our scheme, using 'e' instead of 
 'd' for SPARC4 instructions should work just fine with both GNU and Sun as.
 
 as(1) mentions no -xarch value beyond v9b, while strings on the as binary
 reveals v9, v9[a-dv], but no v9e.  Seems to be a gas invention.

It is indeed, a gas invention.

We really need to start using the newer names, as Sun is not going to
provide single letter indicators for sparc4 or future xarch values.

In fact, that's exactly what needed to be worked on from the beginning
for the solaris side of this cbcond patch.  We're talking in circles.
:-)

Re: [PATCH v3] Add support for sparc compare-and-branch

[David Miller]

From: Eric Botcazou ebotca...@adacore.com
Date: Mon, 12 Nov 2012 09:35:48 +0100

 I strongly doubt that they will be different from the options
 supported both in cc and fbe in the Solaris Studio 12.3 release:
 
 They need to provide some form of backward compatibility though, they cannot 
 break the interface of 'as' like that.  Apparently 'fbe' has had its own set 
 of -xarch values for a while and they haven't been compatible with 'as'.

You give them far too much credit :-)

The 'as' updates constantly add inconsistencies in options and
behavior, and even worse (in my opinion) they effectively stopped
updating the 'as' manual page in this area.

Re: [PATCH v3] Add support for sparc compare-and-branch

[David Miller]

From: Richard Henderson r...@redhat.com
Date: Mon, 12 Nov 2012 09:56:21 -0800

 On 10/22/2012 08:39 PM, David Miller wrote:
 +  /* Compare and Branch is limited to +-2KB.  If it is too far away,
 + change
 +
 + cxbne X, Y, .LC30
 +
 + to
 +
 + cxbe X, Y, .+12
 + ba,pt xcc, .LC30
 +  nop  */
 
 Based on your no-control-after cbcond comment at the top
 of the patch, surely this should contain another nop as well.

Indeed, I'll fix this up.

 And surely all this code isn't so performance sensitive that
 it needs to be written in such an unreadable way.

Sure, I'll change the code to use one of the the clearer mechanisms
you suggested.

Thanks for the review.

Re: [PATCH v3] Add support for sparc compare-and-branch

[David Miller]

From: Rainer Orth r...@cebitec.uni-bielefeld.de
Date: Fri, 26 Oct 2012 11:14:33 +0200

 I tried a bootstrap on Solaris 11.1, but ran into lots of comparison
 failures I've not yet investigated.

I started working on this patch again, in order to incorporate
Richard Henderson's feedback, and I am now getting a comparison
failure.  Is this what you're seeing?

Comparing stages 2 and 3
warning: gcc/cc1-checksum.o differs
warning: gcc/cc1plus-checksum.o differs
warning: gcc/cc1obj-checksum.o differs
Bootstrap comparison failure!
libdecnumber/decNumber.o differs
make[2]: *** [compare] Error 1
make[1]: *** [stage3-bubble] Error 2
make: *** [all] Error 2

In any case, I'm looking into it.

ASAN merge...

[David Miller]

This has broken the build on every Linux target that hasn't added
the necessary cpu specific code to asan_linux.cc

I'm working on the sparc bits, but I'm really surprised this
happened.

[PATCH] Get sparc building again after ASAN merge.

[David Miller]

libsanitizer/

* asan/asan_linux.cc (GetPcSpBp): Add sparc support.
---
 libsanitizer/ChangeLog.asan |  4 
 libsanitizer/asan/asan_linux.cc | 14 ++
 2 files changed, 18 insertions(+)

diff --git a/libsanitizer/ChangeLog.asan b/libsanitizer/ChangeLog.asan
index 7fe3c0c..5592092 100644
--- a/libsanitizer/ChangeLog.asan
+++ b/libsanitizer/ChangeLog.asan
@@ -1,3 +1,7 @@
+2012-11-12  David S. Miller  da...@davemloft.net
+
+   * asan/asan_linux.cc (GetPcSpBp): Add sparc support.
+
 2012-10-29  Wei Mi  w...@google.com
 
Initial checkin: migrate asan runtime from llvm.
diff --git a/libsanitizer/asan/asan_linux.cc b/libsanitizer/asan/asan_linux.cc
index 2922740..ea7ee9e 100644
--- a/libsanitizer/asan/asan_linux.cc
+++ b/libsanitizer/asan/asan_linux.cc
@@ -66,6 +66,20 @@ void GetPcSpBp(void *context, uptr *pc, uptr *sp, uptr *bp) {
   *pc = ucontext-uc_mcontext.gregs[REG_EIP];
   *bp = ucontext-uc_mcontext.gregs[REG_EBP];
   *sp = ucontext-uc_mcontext.gregs[REG_ESP];
+# elif defined(__sparc__)
+  ucontext_t *ucontext = (ucontext_t*)context;
+  uptr *stk_ptr;
+# if defined (__arch64__)
+  *pc = ucontext-uc_mcontext.mc_gregs[MC_PC];
+  *sp = ucontext-uc_mcontext.mc_gregs[MC_O6];
+  stk_ptr = (uptr *) (*sp + 2047);
+  *bp = stk_ptr[15];
+# else
+  *pc = ucontext-uc_mcontext.gregs[REG_PC];
+  *sp = ucontext-uc_mcontext.gregs[REG_O6];
+  stk_ptr = (uptr *) *sp;
+  *bp = stk_ptr[15];
+# endif
 #else
 # error Unsupported arch
 #endif
-- 
1.7.12.2.dirty

Re: [PATCH v3] Add support for sparc compare-and-branch

[David Miller]

From: Eric Botcazou ebotca...@adacore.com
Date: Sun, 11 Nov 2012 23:28:38 +0100

 Eric and Rainer, I think that functionally this patch is fully ready
 to go into the tree except for the Solaris aspects which I do not have
 the means to work on.  Have either of you made any progress in this
 area?
 
 Rainer, could you post an excerpt of the man page of a recent 'as' supporting 
 the SPARC-T4?  I'm mainly interested in the values of the -xarch= option.
 
 Thanks in advance.

I strongly doubt that they will be different from the options
supported both in cc and fbe in the Solaris Studio 12.3 release:

 -xarch=sparc Enables the assembler  to  accept  instructions
  defined  in  the  SPARC-V9  architecture.   The
  resulting object code is in ELF32  format  when
  compiled  with -m32, ELF64 format with -m64. It
  will not execute on a Oracle Solaris V8  system
  (a  machine with a V8 processor).  It will exe-
  cute on a Oracle Solaris V8+ system.

 -xarch=sparcvis
  Enables the assembler  to  accept  instructions
  defined  in  the SPARC-V9 architecture plus the
  instructions  in  the  Visual  Instruction  Set
  (VIS)  version  1.0.  The resulting object code
  is in V8+ ELF32 format when compiled with -m32,
  ELF64  format with -m64. It will not execute on
  a Oracle Solaris system with a V8 processor. It
  will  execute on a Oracle Solaris system with a
  V8+ processor.

 -xarch=sparcvis2
  Enables the assembler  to  accept  instructions
  defined  in the SPARC-V9 architecture, plus the
  instructions  in  the  Visual  Instruction  Set
  (VIS)  version  2.0, with UltraSPARC-III exten-
  sions.  The resulting object  code  is  in  V8+
  ELF32  format  when  compiled  with -m32, ELF64
  format with -m64.

 -xarch=sparcvis3
  Accept instructions defined for the  SPARC  VIS
  version   3  of  the  SPARC-V9  ISA  which  are
  instructions from the SPARC-V9 instruction set,
  plus  the  UltraSPARC extensions, including the
  Visual Instruction Set (VIS) version  1.0,  the
  UltraSPARC-III extensions, including the Visual
  Instruction Set (VIS) version  2.0,  the  fused
  multiply-add   instructions,   and  the  Visual
  Instruction Set (VIS) version 3.0

 -xarch=sparcfmaf
  Accept instructions defined for  the  sparcfmaf
  version   of   the   SPARC-V9   ISA,  plus  the
  UltraSPARC  extensions,  including  the  Visual
  Instruction   Set   (VIS)   version   1.0,  the
  UltraSPARC-III extensions, including the Visual
  Instruction  Set  (VIS)  version  2.0,  and the
  SPARC64  VI   extensions   for   floating-point
  multiply-add.

 -xarch=sparcima
  Accept instructions defined  for  the  sparcima
  version  of the SPARC-V9 ISA which are instruc-
  tions from the SPARC-V9 instruction  set,  plus
  the UltraSPARC extensions, including the Visual
  Instruction  Set   (VIS)   version   1.0,   the
  UltraSPARC-III extensions, including the Visual
  Instruction Set (VIS) version 2.0, the  SPARC64
  VI  extensions for floating-point multiply-add,
  and the  SPARC64  VII  extensions  for  integer
  multiply-add.

 -xarch=sparc4
  Accept instructions defined for the sparc4 ver-
  sion of the SPARC-V9 ISA which are instructions
  from the SPARC-V9  instruction  set,  plus  the
  extensions,   which   includes   VIS  1.0,  the
  UltraSPARC-III extensions, which  includes  VIS
  2.0,   the  fused  floating-point  multiply-add
  instructions, VIS 3.0, and SPARC4 instructions.

[PATCH] Revert sparc U constraint removal.

[David Miller]

PR bootstrap/55211
Revert:
* config/sparc/constraints.md (U): Delete.
* config/sparc/sparc.md: Use 'r' constraint instead of 'U'.
* config/sparc/sync.md: Likewise.
And revert parts of:
* doc/md.texi: Sync sparc constraint documentation with reality.
---
 gcc/ChangeLog   | 10 ++
 gcc/config/sparc/constraints.md | 11 ++-
 gcc/config/sparc/sparc.md   | 16 
 gcc/config/sparc/sync.md|  4 ++--
 gcc/doc/md.texi |  3 +++
 5 files changed, 33 insertions(+), 11 deletions(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index eb4bd88..dc62c59 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,13 @@
+2012-11-07  David S. Miller  da...@davemloft.net
+
+   PR bootstrap/55211
+   Revert:
+   * config/sparc/constraints.md (U): Delete.
+   * config/sparc/sparc.md: Use 'r' constraint instead of 'U'.
+   * config/sparc/sync.md: Likewise.
+   And revert parts of:
+   * doc/md.texi: Sync sparc constraint documentation with reality.
+
 2012-11-07  Jakub Jelinek  ja...@redhat.com
 
* config/i386/i386.c (ix86_avx_u128_mode_after): Don't
diff --git a/gcc/config/sparc/constraints.md b/gcc/config/sparc/constraints.md
index 71670ee..2f8c6ad 100644
--- a/gcc/config/sparc/constraints.md
+++ b/gcc/config/sparc/constraints.md
@@ -18,7 +18,7 @@
 ;; http://www.gnu.org/licenses/.
 
 ;;; Unused letters:
-;;;AB  U
+;;;AB
 ;;;ajklq  tuv xyz
 
 
@@ -130,6 +130,15 @@
   (match_code mem)
   (match_test memory_ok_for_ldd (op
 
+;; Not needed in 64-bit mode
+(define_constraint U
+ Pseudo-register or hard even-numbered integer register
+ (and (match_test TARGET_ARCH32)
+  (match_code reg)
+  (ior (match_test REGNO (op)  FIRST_PSEUDO_REGISTER)
+  (not (match_test reload_in_progress  reg_renumber [REGNO (op)]  
0)))
+  (match_test register_ok_for_ldd (op
+
 ;; Equivalent to 'T' but available in 64-bit mode
 (define_memory_constraint W
  Memory reference for 'e' constraint floating-point register
diff --git a/gcc/config/sparc/sparc.md b/gcc/config/sparc/sparc.md
index 4a44078..f604f46 100644
--- a/gcc/config/sparc/sparc.md
+++ b/gcc/config/sparc/sparc.md
@@ -1595,9 +1595,9 @@
 
 (define_insn *movdi_insn_sp32
   [(set (match_operand:DI 0 nonimmediate_operand
-   
=T,o,T,r,o,r,r,r,?T,?*f,?*f,?o,?*e,?*e,  r,?*f,?*e,?W,b,b)
+   
=T,o,T,U,o,r,r,r,?T,?*f,?*f,?o,?*e,?*e,  r,?*f,?*e,?W,b,b)
 (match_operand:DI 1 input_operand
-J,J,r,T,r,o,i,r,*f,  T,  o,*f, *e, 
*e,?*f,  r,  W,*e,J,P))]
+J,J,U,T,r,o,i,r,*f,  T,  o,*f, *e, 
*e,?*f,  r,  W,*e,J,P))]
   ! TARGET_ARCH64
 (register_operand (operands[0], DImode)
|| register_or_zero_operand (operands[1], DImode))
@@ -2302,8 +2302,8 @@
 })
 
 (define_insn *movdf_insn_sp32
-  [(set (match_operand:DF 0 nonimmediate_operand =b,b,e,e,*r, f,  
e,T,W,r,T,  f,  *r,  o,o)
-   (match_operand:DF 1 input_operand G,C,e,e, 
f,*r,W#F,G,e,T,r,o#F,*roF,*rG,f))]
+  [(set (match_operand:DF 0 nonimmediate_operand =b,b,e,e,*r, f,  
e,T,W,U,T,  f,  *r,  o,o)
+   (match_operand:DF 1 input_operand G,C,e,e, 
f,*r,W#F,G,e,T,U,o#F,*roF,*rG,f))]
   ! TARGET_ARCH64
 (register_operand (operands[0], DFmode)
|| register_or_zero_or_all_ones_operand (operands[1], DFmode))
@@ -2541,8 +2541,8 @@
 })
 
 (define_insn *movtf_insn_sp32
-  [(set (match_operand:TF 0 nonimmediate_operand =b, e,o, o,r,  r)
-   (match_operand:TF 1 input_operand G,oe,e,rG,o,roG))]
+  [(set (match_operand:TF 0 nonimmediate_operand =b, e,o,  o,U,  r)
+   (match_operand:TF 1 input_operand G,oe,e,rGU,o,roG))]
   ! TARGET_ARCH64
 (register_operand (operands[0], TFmode)
|| register_or_zero_operand (operands[1], TFmode))
@@ -7911,8 +7911,8 @@
(set_attr cpu_feature vis,vis,vis,*,*,*,*,*,vis3,vis3,*)])
 
 (define_insn *movVM64:mode_insn_sp32
-  [(set (match_operand:VM64 0 nonimmediate_operand =e,e,e,*r, f,e,m,m,r,T, 
o,*r)
-   (match_operand:VM64 1 input_operand Y,C,e, 
f,*r,m,e,Y,T,r,*r,*r))]
+  [(set (match_operand:VM64 0 nonimmediate_operand =e,e,e,*r, f,e,m,m,U,T, 
o,*r)
+   (match_operand:VM64 1 input_operand Y,C,e, 
f,*r,m,e,Y,T,U,*r,*r))]
   TARGET_VIS
 ! TARGET_ARCH64
 (register_operand (operands[0], VM64:MODEmode)
diff --git a/gcc/config/sparc/sync.md b/gcc/config/sparc/sync.md
index 302cd74..d11f663 100644
--- a/gcc/config/sparc/sync.md
+++ b/gcc/config/sparc/sync.md
@@ -115,7 +115,7 @@
 })
 
 (define_insn atomic_loaddi_1
-  [(set (match_operand:DI 0 register_operand =r,?*f)
+  [(set (match_operand:DI 0 register_operand =U,?*f)
(unspec:DI [(match_operand:DI 1 memory_operand m,m)]
   UNSPEC_ATOMIC))]
   !TARGET_ARCH64
@@ -144,7 +144,7 

[PATCH] Add extensive commentary to sparc's U constraint.

[David Miller]

Vlad, I wanted to make you aware of the following because it's
a major barrier for using LRA on sparc at this time.  I therefore
do not think moving to LRA on this target is possible in the 4.8
timeframe, which is fine.  The situation is described completely
in the comment I am adding in the patch below.

The most alarming aspect of this to me was discovering that IRA could
allocate registers to a pseudo that did not pass HARD_REGNO_MODE_OK,
and this anomaly is completely masked because reload and our splitters
end up fixing things up.

I wanted to explicitly thank you for your work on LRA because without
it we would never have discovered these inconsistencies in the sparc
backend.

One idea that occurred to me was perhaps to extend
define_register_constraint such that an extra condition can be
specified.  So for sparc's constraint U it would evaluate to
GENERAL_REGS but also express the condition that the hard register
must be even.  Then we could make the implementation of the macro
REG_CLASS_FROM_CONSTRAINT test the extra condition specified in
define_register_constraint, and return NO_REGS if that condition does
not pass.

But it would be much nicer if register classes could do what we need
them to.  Such a solution would be both cleaner, and significantly
more efficient.

* config/sparc/constraints.md (U): Document, in detail,
which this constraint is necessary.
---
 gcc/ChangeLog   |  5 +
 gcc/config/sparc/constraints.md | 38 +-
 2 files changed, 42 insertions(+), 1 deletion(-)

diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 24d9845..64e7596 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2012-11-07  David S. Miller  da...@davemloft.net
+
+   * config/sparc/constraints.md (U): Document, in detail,
+   which this constraint is necessary.
+
 2012-11-07  Richard Henderson  r...@redhat.com
 
* trans-mem.c (pass_ipa_tm): Don't use TODO_update_ssa.
diff --git a/gcc/config/sparc/constraints.md b/gcc/config/sparc/constraints.md
index 2f8c6ad..440dc57 100644
--- a/gcc/config/sparc/constraints.md
+++ b/gcc/config/sparc/constraints.md
@@ -130,7 +130,43 @@
   (match_code mem)
   (match_test memory_ok_for_ldd (op
 
-;; Not needed in 64-bit mode
+;; This awkward register constraint is necessary because it is not
+;; possible to express the must be even numbered regsiter condition
+;; using register classes.  The problem is that membership in a
+;; register class requires that all registers of a multi-regno
+;; register be included in the set.  It is add_to_hard_reg_set
+;; and in_hard_reg_set_p which populate and test regsets with these
+;; semantics.
+;;
+;; So this means that we would have to put both the even and odd
+;; register into the register class, which would not restrict things
+;; at all.
+;;
+;; Using a combination of GENERAL_REGS and HARD_REGNO_MODE_OK is not a
+;; full solution either.  In fact, even though IRA uses the macro
+;; HARD_REGNO_MODE_OK to calculate which registers are prohibited from
+;; use in certain modes, it still can allocate an odd hard register
+;; for DImode values.  This is due to how IRA populates the table
+;; ira_useful_class_mode_regs[][].  It suffers from the same problem
+;; as using a register class to describe this restriction.  Namely, it
+;; sets both the odd and even part of an even register pair in the
+;; regset.  Therefore IRA can and will allocate odd registers for
+;; DImode values on 32-bit.
+;;
+;; There are legitimate cases where DImode values can end up in odd
+;; hard registers, the most notable example is argument passing.
+;;
+;; What saves us is reload and the DImode splitters.  Both are
+;; necessary.  The odd register splitters cannot match if, for
+;; example, we have a non-offsetable MEM.  Reload will notice this
+;; case and reload the address into a single hard register.
+;;
+;; The real downfall of this awkward register constraint is that it does
+;; not evaluate to a true register class like a bonafide use of
+;; define_register_constraint would.  This currently means that we cannot
+;; use LRA on Sparc, since the constraint processing of LRA really depends
+;; upon whether an extra constraint is for registers or not.  It uses
+;; REG_CLASS_FROM_CONSTRAINT, and checks it against NO_REGS.
 (define_constraint U
  Pseudo-register or hard even-numbered integer register
  (and (match_test TARGET_ARCH32)
-- 
1.7.12.2.dirty

Re: [PATCH] Add extensive commentary to sparc's U constraint.

[David Miller]

From: Steven Bosscher stevenb@gmail.com
Date: Thu, 8 Nov 2012 01:19:11 +0100

 On Wed, Nov 7, 2012 at 11:39 PM, David Miller wrote:
 One idea that occurred to me was perhaps to extend
 define_register_constraint such that an extra condition can be
 specified.  So for sparc's constraint U it would evaluate to
 GENERAL_REGS but also express the condition that the hard register
 must be even.
 
 I haven't looked at the details of this all, but there are ports that
 use define_predicate to request an even-numbered register. See e.g.
 frv and v850. I'm not sure if/how the RA takes predicates into account
 when selecting a register.

That would only influence instruction recognition.

 (bfin uses define_register_constraints, but it has separate register
 classes for the even-numbered registers, so apparently that's not for
 multi-word hardregs like your case.)

Right.

 diff --git a/gcc/config/sparc/constraints.md 
 b/gcc/config/sparc/constraints.md
 index 2f8c6ad..440dc57 100644
 --- a/gcc/config/sparc/constraints.md
 +++ b/gcc/config/sparc/constraints.md
 @@ -130,7 +130,43 @@
(match_code mem)
(match_test memory_ok_for_ldd (op

 -;; Not needed in 64-bit mode
 +;; This awkward register constraint is necessary because it is not
 +;; possible to express the must be even numbered regsiter condition
 
 s/regsiter/register/

Thanks, I'll fix that.

Re: New badness metric for inliner

[David Miller]

From: Jan Hubicka hubi...@ucw.cz
Date: Tue, 6 Nov 2012 19:21:46 +0100

 The problem here is really that MAX_TIME * MAX_FREQ do not fit into 32bit 
 integer. Fixed thus.
 
   * ipa-inline.c (compute_uninlined_call_time): Return gcov_type.
   (compute_inlined_call_time): Watch overflows.
   (relative_time_benefit): Compute in gcov_type.

Thanks Jan, I'll test this right now.

Re: New badness metric for inliner

[David Miller]

From: David Miller da...@davemloft.net
Date: Tue, 06 Nov 2012 13:26:53 -0500 (EST)

 From: Jan Hubicka hubi...@ucw.cz
 Date: Tue, 6 Nov 2012 19:21:46 +0100
 
 The problem here is really that MAX_TIME * MAX_FREQ do not fit into 32bit 
 integer. Fixed thus.
 
  * ipa-inline.c (compute_uninlined_call_time): Return gcov_type.
  (compute_inlined_call_time): Watch overflows.
  (relative_time_benefit): Compute in gcov_type.
 
 Thanks Jan, I'll test this right now.

Bootstrap still fails with this change installed:

../../gcc/gcc/graphite-interchange.c:645:1: internal compiler error: in 
relative_time_benefit, at \
ipa-inline.c:785
 }
 ^
0x108289f relative_time_benefit
../../gcc/gcc/ipa-inline.c:785
0x1082fcb edge_badness
../../gcc/gcc/ipa-inline.c:895
0x108372f update_edge_key
../../gcc/gcc/ipa-inline.c:963
0x10840db update_callee_keys
../../gcc/gcc/ipa-inline.c:1142
0x1085b47 inline_small_functions
../../gcc/gcc/ipa-inline.c:1595
0x10864f7 ipa_inline
../../gcc/gcc/ipa-inline.c:1770
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
make[3]: *** [graphite-interchange.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[2]: *** [all-stage2-gcc] Error 2
make[1]: *** [stage2-bubble] Error 2
make: *** [all] Error 2

And as Toon pointed out, even x86-64 is seeing this problem, so something
other than the size of the datum holding the value is at work here.