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 
Date: Tue, 06 Jun 2017 15:02:55 -0400 (EDT)

> From: David Miller 
> Date: Mon, 05 Jun 2017 20:54:46 -0400 (EDT)
> 
>> 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.
> 
> 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 
Date: Mon, 05 Jun 2017 20:54:46 -0400 (EDT)

> 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.

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: 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.

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: David Miller 
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  
+
+   * 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  
 
* 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_class[];
register window instruction in the prologue.  */
 #de

[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 (&lra_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, &unsignedp);
  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, &unsignedp,
   gimple_call_fntype (g),
   2);
  else
pmode = promote_ssa_mode (ssa_name, &unsignedp);
  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 
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
 
+#undef TARGET_LRA_P
+#d

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

[David Miller]

From: Max Filippov 
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 
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 
Date: Tue, 30 Jul 2013 12:33:30 -1000

> On 07/30/2013 03:31 AM, Eric Botcazou wrote:
>> 2013-07-30  Eric Botcazou  
>> 
>>  * config/sparc/sparc.c (sparc_emit_membar_for_model) : 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 
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 
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 
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 
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.

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

[David Miller]

From: David Miller 
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] 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} \

[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, cstore4):
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 attribut

[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_C

Re: expansion of vector shifts...

[David Miller]

From: Richard Biener 
Date: Wed, 13 Feb 2013 12:15:13 +0100

> On Tue, Feb 12, 2013 at 11:31 PM, David Miller  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  
>>
>> * 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 
Date: Fri, 16 Nov 2012 00:33:05 -0500 (EST)

> From: Richard Sandiford 
> 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  

* 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: [PATCH] Fix up get_reload_reg (PR rtl-optimization/56195)

[David Miller]

From: Jakub Jelinek 
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: Jakub Jelinek 
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: var-tracking wrt. leaf regs on sparc

[David Miller]

From: David Miller 
Date: Thu, 07 Feb 2013 14:38:18 -0500 (EST)

> From: Jakub Jelinek 
> 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  

* 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 
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: Eric Botcazou 
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  

* 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 
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)
-  

Re: patch to fix PR55775

[David Miller]

From: Vladimir Makarov 
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: patch to fix PR55775

[David Miller]

From: Vladimir Makarov 
Date: Fri, 21 Dec 2012 16:22:15 -0500

> 2012-12-21  Vladimir Makarov  
> 
> 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: [SPARC] Fix PR target/54121

[David Miller]

From: Eric Botcazou 
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 
Date: Mon, 3 Dec 2012 22:44:15 +0400

> On Mon, Dec 3, 2012 at 10:37 PM, David Miller  wrote:
>> From: Konstantin Serebryany 
>> Date: Mon, 3 Dec 2012 22:33:12 +0400
>>
>>> On Mon, Dec 3, 2012 at 10:29 PM, David Miller  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=rev&revision=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 
Date: Mon, 3 Dec 2012 22:33:12 +0400

> On Mon, Dec 3, 2012 at 10:29 PM, David Miller  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 
Date: Mon, 3 Dec 2012 22:18:56 +0400

> On Mon, Dec 3, 2012 at 10:02 PM, David Miller  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 
Date: Tue, 27 Nov 2012 18:12:00 +0400

> On Wed, Nov 21, 2012 at 9:05 PM, Konstantin Serebryany
>  wrote:
>> On Wed, Nov 21, 2012 at 8:40 PM, David Miller  wrote:
>>> From: Konstantin Serebryany 
>>> 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=gcc&view=rev&rev=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: Peter Bergner 
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 ASAN

[David Miller]

From: Jakub Jelinek 
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: David Miller 
Date: Wed, 21 Nov 2012 12:54:17 -0500 (EST)

> From: Peter Bergner 
> 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: Peter Bergner 
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: Konstantin Serebryany 
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: Konstantin Serebryany 
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=1UL<<13 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: David Miller 
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 ASAN (was Re: sparc bootstrap still broken)

[David Miller]

From: David Miller 
Date: Tue, 20 Nov 2012 14:59:10 -0500 (EST)

> From: Konstantin Serebryany 
> 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 

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 :add  %fp, -160, %i5
 ...
   0x10490 :   sethi  %hi(0xf1f1f000), %g2
 ...
   0x104a0 :   srl  %i5, 3, %i5
 ...
   0x104a8 :   or  %g2, 0x1f1, %g2
   0x104ac :   sethi  %hi(0x2000), %g1
 ...
=> 0x104b4 :   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.

[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  
+
+   * sanitizer_common/sanitizer_linux.cc
+   (SANITIZER_LINUX_USES_64BIT_SYSCALLS): Define.
+   (internal_mmap): Use it.
+   (internal_filesize): Likewise.
+
 2012-11-16  Tom Tromey  
 
* 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 
 #include 
 
+// 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

Re: sparc bootstrap still broken

[David Miller]

From: Konstantin Serebryany 
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.

Re: sparc bootstrap still broken

[David Miller]

From: Konstantin Serebryany 
Date: Tue, 20 Nov 2012 23:19:51 +0400

> On Tue, Nov 20, 2012 at 11:09 PM, David Miller  wrote:
>> From: Konstantin Serebryany 
>> 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 
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: Peter Bergner 
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  wrote:
>> > From: Konstantin Serebryany 
>> > 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=168358&view=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 
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: Konstantin Serebryany 
Date: Tue, 20 Nov 2012 09:34:14 +0400

> On Tue, Nov 20, 2012 at 9:26 AM, David Miller  wrote:
>> From: Konstantin Serebryany 
>> 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=168301&r2=168300&pathrev=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: sparc bootstrap still broken

[David Miller]

From: Konstantin Serebryany 
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.

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: [PATCH] Enable building of libsanitizer on sparc linux again.

[David Miller]

From: Andrew Pinski 
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] Enable building of libsanitizer on sparc linux again.

[David Miller]

From: Diego Novillo 
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: Konstantin Serebryany 
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: Konstantin Serebryany 
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: "H.J. Lu" 
Date: Sat, 17 Nov 2012 16:06:23 -0800

> On Sat, Nov 17, 2012 at 4:04 PM, David Miller  wrote:
>> From: Eric Botcazou 
>> 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: Eric Botcazou 
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: expansion of vector shifts...

[David Miller]

From: Richard Sandiford 
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  
 
+   * 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: [PATCH] Enable building of libsanitizer on sparc linux again.

[David Miller]

From: Dodji Seketeli 
Date: Thu, 15 Nov 2012 11:56:40 +0100

> David Miller  wrote
> 
>> From: Dodji Seketeli 
>> 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: [PATCH v4] Add support for sparc fused compare-and-branch.

[David Miller]

From: Eric Botcazou 
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.

[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  

* 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 @@
 ;; .
 
 ;;; 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 c

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

[David Miller]

From: Matthias Klose 
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.

Re: ASAN merge...

[David Miller]

From: Dodji Seketeli 
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 v3] Add support for sparc compare-and-branch

[David Miller]

From: Eric Botcazou 
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: Eric Botcazou 
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: ASAN merge...

[David Miller]

From: Diego Novillo 
Date: Tue, 13 Nov 2012 11:21:59 -0500

> On Tue, Nov 13, 2012 at 12:07 AM, David Miller  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.

[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  
+
+   * asan/asan_linux.cc (GetPcSpBp): Add sparc support.
+
 2012-10-29  Wei Mi  
 
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

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.

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

[David Miller]

From: Rainer Orth 
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.

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

[David Miller]

From: Richard Henderson 
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: Eric Botcazou 
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: Rainer Orth 
Date: Mon, 12 Nov 2012 16:46:37 +0100

> Eric Botcazou  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 
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.

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

[David Miller]

From: Steven Bosscher 
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.

[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  
+
+   * config/sparc/constraints.md ("U"): Document, in detail,
+   which this constraint is necessary.
+
 2012-11-07  Richard Henderson  
 
* 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

[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  
+
+   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  
 
* 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 @@
 ;; .
 
 ;;; 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 "*mov_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], mode)
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

Re: New badness metric for inliner

[David Miller]

From: Jan Hubicka 
Date: Tue, 6 Nov 2012 22:11:44 +0100

> The attached patch fixes the testcase, so I comitted it as obvious.  Hope it
> will fix the bootstrap for you. I did not hit this because my bootstrap did 
> not
> have graphite enabled due to lack of proper support libraries.
> 
> Comitted as obvious.
> 
>   * ipa-inline-analysis.c (estimate_function_body_sizes,
>   inline_update_overall_summary): Cap time calculations.

Bootstrap is working again for me, thanks Jan!

Re: New badness metric for inliner

[David Miller]

From: Jan Hubicka 
Date: Tue, 6 Nov 2012 22:01:27 +0100

> Hmm, this is obvoiusly wrong.  All the caller time computation should be 
> capped
> to MAX_TIME that should be safe from overflows.

They are not capped to MAX_TIME.

They are capped to MAX_TIME * INLINE_TIME_SCALE which is
10.