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
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 sug
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
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
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).
>>
>
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
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
&g
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
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.
>>
>&
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.
[ 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@1
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 un
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 is
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 tes
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.
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
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
>>>
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?
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
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 +0
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.
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
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:
>>&g
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.
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
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 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 can
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. The
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 m
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 b
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
> il
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.
W
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 patte
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_NUMBE
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 s
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.
Fol
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 (HA
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
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:
>>
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 branc
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);
> +
>
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_
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'
Richard reported to me that we wouldn't have a mulsi3 pattern with
"-m32 -mv8plus", which left me dumbfounded. It seemed impossible.
Clarifying further, the case is when gcc is built for a target of
sparc64-linux. And indeed I was able to reproduce this, a 32-bit
mutliply results in a libcall.
From: Eric Botcazou
Date: Tue, 18 Oct 2011 00:09:55 +0200
> I think that the original motivation for the previous design was the 32-bit
> vector ABI, where the arguments are passed in integer registers. So for:
>
> typedef char vec8 __attribute__((vector_size(8)));
>
> extern vec8 foo (vec8)
From: Eric Botcazou
Date: Tue, 18 Oct 2011 00:57:18 +0200
>> I would suggest we start with my patch, get the int<-->float move
>> instructions working reasonably, and then re-add vector-only cases for
>> the scenerios you describe above, making sure that we don't end up with
>> silly code generat
A small patch from Richard to fix the edge predicates, committed
to trunk.
* config/sparc/sparc.md: Use register_or_zero_operand where rJ
is the constraint.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180113
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog
This is Richard's patch to add vec_perm patterns for VIS2, I verified
that the patterns do get used in some of the slp test cases and that
such test cases pass.
I only had to make a minor adjustment due to a conflict with the
vector segregation patch, namely the mode iterator had to be changed
fr
From: Uros Bizjak
Date: Wed, 19 Oct 2011 21:50:14 +0200
> Hello!
>
> These two tests require non_strict_aligned effective target, since IPA
> fails in tree_non_mode_aligned_mem_p () for "cow" and "calf"
> candidates for STRICT_ALIGNMENT targets. Mode alignment requires 32
> bytes, while data is
Committed to trunk.
gcc/
* config/sparc/sparc.c (sparc_expand_move): Use
can_create_pseudo_p.
(sparc_emit_set_const32): Likewise.
(sparc_emit_set_const64_longway): Likewise.
(sparc_emit_set_const64): Likewise.
(sparc_legitimize_pic_address): Likewi
Committed to trunk.
gcc/
* config/sparc/sparc.h (SECONDARY_INPUT_RELOAD_CLASS,
SECONDARY_OUTPUT_RELOAD_CLASS): Delete.
* config/sparc/sparc.c (TARGET_SECONDARY_RELOAD): Redefine.
(sparc_secondary_reload): New function.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/tr
We used to actually need to get at 'sparc_costs' in sparc.h but those
days are long gone.
Committed to trunk.
* config/sparc/sparc.h (sparc_costs): Remove extern decl.
(struct processor_costs): Move from here..
* config/sparc/sparc.c (struct processor_costs): To here.
All uses of reg_unused_after() were removed in my rewrite of the sparc
backend back in 1998.
short_branch() was removed in various pieces over time, the final references
died in Eric B.'s removal of -mflat in 2004.
Committed to trunk.
gcc/
* config/sparc/sparc.c (short_branch, reg_unus
From: Eric Botcazou
Date: Sun, 23 Oct 2011 00:22:14 +0200
> This breaks -mcpu on Solaris though because TARGET_DEFAULT has MASK_V8PLUS.
> So any setting below or equal to -mcpu=v8 triggers an architecture mismatch
> between assembler and compiler.
>
> I think we need to go the specs route. I'd
From: Eric Botcazou
Date: Sat, 22 Oct 2011 21:27:46 +0200
>> All uses of reg_unused_after() were removed in my rewrite of the sparc
>> backend back in 1998.
>
> Btw, it recently occurred to me that the SPARC back-end is the only
> mainstream
> RISC port that doesn't define PROMOTE_MODE. Do yo
From: Eric Botcazou
Date: Sun, 23 Oct 2011 11:58:57 +0200
>> I'll try to brainstorm on this, thanks for letting me know about the
>> Solaris target problem.
>
> Let's fix the regression quickly though.
I'll fix it by the end of tonight.
Since there is a mixture of signed vs. unsigned regnos used in these
tests, I had to code this as ((unsigned) x <= 31) otherwise we get
warnings in the unsigned cases for x >= 0.
Perhaps the signedness should be shored up at some point, but I left
that for some other time.
I'm currently just try
While working on the vis3 fp move support, I came to find that we
weren't making sure that non-trivial vector constants went to memory.
The vector move patterns only support -1 and 0, so we have to force
all other values to memory.
Committed to trunk.
gcc/
* config/sparc/predicates.md
A good example of a case where this matters is pdist.c in the testsuite.
Before this change we get code for the beginning of function 'foo' like:
add %sp, -112, %sp
std %o0, [%sp+96]
stx %g0, [%sp+104]
ldd [%sp+96], %f10
std %o2, [%sp+96
These tests are already growing big and ugly, and they will get even
more conditions when the VIS3 FP moves arrive.
Furthermore, we will need to have to do the same check in a third location,
in a new spliiter for the 64-bit vector moves that will be added for VIS3.
Committed to trunk.
The non-trivial aspects (and what took the most time for me) of these
changes are:
1) Getting the register move costs and class preferencing right such
that the VIS3 moves do get effectively used for incoming
float/vector argument passing on 32-bit, yet IRA and reload don't
go nuts alloc
From: David Miller
Date: Sun, 23 Oct 2011 16:32:36 -0400 (EDT)
> From: Eric Botcazou
> Date: Sun, 23 Oct 2011 11:58:57 +0200
>
>>> I'll try to brainstorm on this, thanks for letting me know about the
>>> Solaris target problem.
>>
>> Let's fi
Eric, if you could give this some eyeballs I'd really appreciate it.
I think this brings the number of move patterns down to a more
acceptable level. I didn't have the muster to attack the TFmode
moves just yet. But honestly I think this is a good start.
I quickly ran this through check-gcc bo
From: Eric Botcazou
Date: Mon, 24 Oct 2011 19:00:42 +0200
>> Great, committed to trunk.
>
> Minor nit: can't you uncouple the GY, ZC and DF couples of constraints now?
> We presumably need only one member of the couples per alternative now, i.e
> F,G,C in FP insns and D,Y,Z in vector insns.
Ri
From: Richard Henderson
Date: Mon, 24 Oct 2011 14:05:28 -0700
> You shouldn't need to split these anymore. See the enabled attribute, as
> used on several other targets so far.
See the patch I posted 2 hours after this one.
From: Eric Botcazou
Date: Mon, 24 Oct 2011 19:06:53 +0200
> ...notv9fpu is somewhat ambiguous, fpunotv9 sounds better. I'd also change
> the
> final (const_int 1) to (const_int 0) if you explicitly test "none" above.
Agreed, I'll make these changes and commit to trunk.
Thanks for the review
As discussed earlier today.
Committed to trunk.
gcc/
* config/sparc/sparc.md: Only use F, G, and C constraints in FP
insns. Only use D, Y, and Z constraints in vector insns.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180410
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/C
Eric, could you please take a look again at your reload bug fix
first posted at:
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01671.html
It looks correct to me, and I can reproduce it with the VIS3 fp moves
enabled by simply adjusting the costs and register class preferences
such that IR
Eric, David Brenner noticed that sparc little-endian support is
a candidate for deprecation or deletion. I support the latter,
we have no real OS targets supporting it and sparclet support
was removed in 2003 (!!!).
In fact, only sp64-elf.h even tries to override the endianness
macros correctly,
Comitted to trunk.
gcc/testsuite/
* gcc.target/sparc/vis3move-1.c: New test.
* gcc.target/sparc/vis3move-2.c: New test.
* gcc.target/sparc/vis3move-3.c: New test.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180418
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/testsu
From: Eric Botcazou
Date: Wed, 26 Oct 2011 00:22:26 +0200
>> Eric, could you please take a look again at your reload bug fix
>> first posted at:
>>
>> http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01671.html
>>
>> It looks correct to me, and I can reproduce it with the VIS3 fp moves
>> enable
The background is that I was putting together some test cases for
gcc.target/sparc that make sure the most optimal setcc sequences
are being generated.
When v9, and thus conditional moves, are enabled we sometimes fall
back to conditional moves even when the addx/subx sequence is more
efficient.
This makes sure the addx/subx sequence is used even when v9 conditional
moves are available.
It also shows the compiler that the setcc instructions emitting
-1, 0, or 1 all extend to DImode.
I left all the "*x_{plus,minus}_foo" and related patterns alone for
now, I'll get to those and add approp
Committed to trunk.
gcc/testsuite/
* gcc.target/sparc/fmaf-1.c: New test.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180551
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/testsuite/ChangeLog |2 +
gcc/testsuite/gcc.target/sparc/fmaf-1.c | 51 ++
From: Alan Modra
Date: Thu, 27 Oct 2011 13:29:56 +1030
> Some recent patch has exposed a reload bug. I'm seeing
I think this might be a side effect or Eric's recent changes,
CC:'d.
More extensive testing showed that we have to force the usage of
v9 scc patterns when comparing DImode values with comparison codes
other than EQ and NE.
Soon we'll be able to add exceptions this this, because VIS3 has addxc
and addxccc instructions which test the 64-bit carry condition.
Committ
From: David Miller
Date: Wed, 26 Oct 2011 23:07:11 -0400 (EDT)
> From: Alan Modra
> Date: Thu, 27 Oct 2011 13:29:56 +1030
>
>> Some recent patch has exposed a reload bug. I'm seeing
>
> I think this might be a side effect or Eric's recent changes,
>
As discussed in the thread starting at:
http://gcc.gnu.org/ml/gcc/2011-10/msg00478.html
We need to make the tests done in copyprop_hardreg_forward_1()
match those performed in copy_value(), and in particular make
sure that if we are narrowing the mode on big-endian we do
not perform the substitu
Noticed this while combing through a sparc 64-bit testsuite run.
Committed to trunk.
gcc/
* config/sparc/sparc.md (64-bit vector moves): Use 'e' not 'f'
constraint.
---
gcc/ChangeLog |3 +++
gcc/config/sparc/sparc.md |4 ++--
2 files changed, 5 insertions(+)
'addxc' is like 'addx', but it uses the 64-bit carry condition
as input instead of the 32-bit one.
This allows us to do ne/ltu/gtu setcc operations comparing 64-bit
integers without temporaries.
Unfortunately, VIS3 only has addxc (not subxc) and only the 3-register
opcode is provided (no immedia
My check-gcc runs are completely dominated by the time it takes to
test compile.exp=20001226-1.c
On sparc when compiling this function at -O1 the lowest hanging fruit
is some sillyness in reorg. It is trying to test a very specific
condition within a well contained code block, but the label scan
Tests such as limits-fndefn.c spend %97 of their time in
next_real_insn() when -g is on the command line.
It's the invocation from dwarf2out_var_location(). These test cases
are basically 100,000 consecutive var location notes, followed by a
real instruction.
This is similar to the reorg issue
There is definitely more than can be done in this area, but at least
this is a start.
Next we can start trying to use the ASI_FL{8,16,32}_P short floating
point loads which zero extend a 8, 16, or 32 bit integer value into a
double precision float register.
gcc/
* config/sparc/sparc.c (
From: Jakub Jelinek
Date: Mon, 31 Oct 2011 11:26:40 +0100
> Or alternatively you could remove the whole if (! !next_note ...)
> next_note = NULL_RTX; stmt and move your cache to a global var and
> clear it when reaching end of function (like
> e.g. last_var_location_insn is cleared in dwarf2out_e
I noticed this while working on vcond patterns for sparc.
Committed to trunk.
gcc/
* config/sparc/sparc.md (cmask patterns): Allow zero operand.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180715
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog |2 ++
gcc/co
I really wanted to make this work using the define_expand rtl to
generate the pattern, but I ran into two problems:
1) In addition to mode "GCM", we also need to iterate over "P" mode
for the sake of the rtl of fpcmp and cmask. So we'd get dups in
the insn output files.
2) I couldn't subs
From: Richard Henderson
Date: Tue, 01 Nov 2011 08:15:51 -0700
> Given that I believe that essentially all Sparcs still running
> are actually v9 and have native CAS, I think we can ignore this
> problem entirely.
Unfortunately, this is not true.
Otherwise we could change the 32-bit default code
From: Richard Henderson
Date: Tue, 01 Nov 2011 13:48:26 -0700
> (2) Can we have the kernel implement some {SWAP,CAS}{4,8} primitives (possibly
> via a special trap) that we can export from libgcc, as we do for ARM, PA,
> & SH?
>
> I believe that would allow all of the non-embedded linux
Committed to trunk.
gcc/
* config/sparc/sparc.c (vector_init_faligndata): New function.
(sparc_expand_vector_init): Use it for V4HImode on VIS1.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@180752
138bc75d-0d04-0410-961f-82ee72b054a4
---
gcc/ChangeLog|3 +++
From: Eric Botcazou
Date: Wed, 2 Nov 2011 21:07:15 +0100
> This is a fallout of the consolidation patch for floating-point insns. When
> the regular and no_fpu patterns for movdf were merged, the r/ro alternative
> of
> the latter pattern was merged with the r/rFo alternative of the former.
From: Eric Botcazou
Date: Wed, 2 Nov 2011 13:29:45 +0100
> This has reintroduced PR target/49965.
I am working on fixing this right now, thanks for reporting Eric.
My sparc-linux-gnu builds with --enable-targets=all is failing with:
../../../../gcc/libgcc/config/sparc/lb1spc.S: Assembler messages:
../../../../gcc/libgcc/config/sparc/lb1spc.S:124: Error: detected global
register use not covered by .register pseudo-op
../../../../gcc/libgcc/config/sparc/lb1s
From: Joel Sherrill
Date: Wed, 2 Nov 2011 16:29:16 -0500
> Is this similar to what I just got for sparc-rtems when compiling
> libgcc2 with -mcpu=v8?
>
> /tmp/cczMc4jN.s: Assembler messages:
> /tmp/cczMc4jN.s:16: Error: Hardware capability "mul32" not enabled for
> "smul".
> /tmp/cczMc4jN.s:18:
From: David Miller
Date: Wed, 02 Nov 2011 18:30:56 -0400 (EDT)
> From: Joel Sherrill
> Date: Wed, 2 Nov 2011 16:29:16 -0500
>
>> Is this similar to what I just got for sparc-rtems when compiling
>> libgcc2 with -mcpu=v8?
>>
>> /tmp/cczMc4jN.s: Assembler messa
From: David Miller
Date: Wed, 02 Nov 2011 18:43:52 -0400 (EDT)
> So t-softmul gets appended anyways, and this causes us to try and
> build config/sparc/lb1spc.S for the 64-bit libgcc which we should
> never do.
I tried the patch below but it just results in syntax errors in the
Make
From: Andrew Pinski
Date: Wed, 2 Nov 2011 16:40:13 -0700
> On Wed, Nov 2, 2011 at 4:28 PM, David Miller wrote:
>> +LIB1ASMSRC = `if test x$$($(CC) -print-multi-os-directory) \
>> + = x../lib64; then echo sparc/lb1spc.S; fi`
>> +LIB1ASMFUNCS = `if
From: "Joseph S. Myers"
Date: Thu, 3 Nov 2011 00:22:49 + (UTC)
> On Wed, 2 Nov 2011, David Miller wrote:
>
>> Actually the problem is that libgcc/config.host checks ${host}
>> to decide whether to append config/sparc/t-softmul to the tmake
>> variable.
From: "Joseph S. Myers"
Date: Thu, 3 Nov 2011 01:21:35 + (UTC)
> What is new is that you can now put tests in libgcc/configure.ac
> such as the "Check 32bit or 64bit for x86." one, and select t-*
> files based on those tests - whereas in the gcc/ directory there is
> no possibility at all for
From: David Miller
Date: Wed, 02 Nov 2011 16:17:33 -0400 (EDT)
> From: Eric Botcazou
> Date: Wed, 2 Nov 2011 13:29:45 +0100
>
>> This has reintroduced PR target/49965.
>
> I am working on fixing this right now, thanks for reporting Eric.
This took longer than expected
From: Eric Botcazou
Date: Thu, 3 Nov 2011 17:26:28 +0100
> Tested on SPARC/Solaris, applied on the mainline.
Thanks for doing this work Eric.
101 - 200 of 363 matches
Mail list logo
