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
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 inst
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, tha
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
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
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.
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 operatin
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
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?
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
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
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
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 l
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
>> in
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
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:
>>>
>>> ==
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
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
>> co
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.
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 sugges
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.
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
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.
From: Eric Botcazou
Date: Sat, 12 Sep 2015 16:04:09 +0200
> You need to update https://gcc.gnu.org/backends.html
Done.
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 ac
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
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
>
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 th
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?
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
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.
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 som
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
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: 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, 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: 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: 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
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
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 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
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'
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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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: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: 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: 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: 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: 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: 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: 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: 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: 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: 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
[ 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: 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.
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: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: 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 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: 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 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
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: 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
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: 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
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
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
>>&g
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 t
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)
> &
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 av
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 committin
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-cp
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.
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.
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 A
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 cas
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 fixe
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..
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.
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
fail
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
>>
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 o
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 p
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,
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 constr
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
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
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
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.
1 - 100 of 363 matches
Mail list logo
