From: Ian Lance Taylor
Date: Mon, 1 Oct 2012 11:55:56 -0700
> Steven is correct in saying that there is a tendency to move on and
> never address GCC bugs. However, there is also a counter-vailing
> tendency to fix GCC bugs. Anyhow I'm certainly not saying that in all
> cases it's OK to accept
Some recent work showed me that many of the latency values in the
documentation I have for Niagara-4 were simply inaccurate. So I
went through the instruction set and tried to determine the real
values by hand using test programs.
In particular the logical VIS operation, when working on 64-bit
o
Starting with SPARC-T4 we have support for fused compare-and-branch
instructions. These are documented at:
http://www.oracle.com/technetwork/systems/opensparc/sparc-architecture-2011-1728132.pdf
But, to summarize the form is:
c{w,x}b{$COND} rs1, {rs2,imm5}, LABEL
'w' means 32-bit, 'x
From: Eric Botcazou
Date: Sat, 13 Oct 2012 15:47:11 +0200
>> The trouble area, and where I need help from either Rainer or Eric,
>> is the Solaris2 bits.
>>
>> I think we need to move the Solaris assembler stuff over to a model
>> where it passes:
>>
>> -m{32,64} -xarch=sparcFOO
>>
>> ins
From: David Miller
Date: Sat, 13 Oct 2012 17:52:42 -0400 (EDT)
> The current assembler in Solaris Studio (called 'fbe') calls this
> stuff "sparc4" which I guess means "SPARC-T4 and later".
BTW, for reference, see:
http://docs.oracle.com/cd/E24457_01/html/E22003/fbe.1.html
From: Eric Botcazou
Date: Mon, 15 Oct 2012 10:00:02 +0200
>> > The only versions of the Solaris assembler I have access to only support
>> > v8plusX according to the man page. Has that changed recently?
>>
>> For the older stuff I mean doing something like "-m32 -xarch=v9X"
>
> OK, this is for
From: Rainer Orth
Date: Mon, 15 Oct 2012 16:28:15 +0200
> David Miller writes:
>
>> Could one of you help me get the solaris side correct? I made sure
>> that binutils accepts the same options for this stuff, that's why
>> I can unconditionally use '-x
From: Rainer Orth
Date: Mon, 15 Oct 2012 16:44:44 +0200
> David Miller writes:
>
>>>> I'm just calling it VIS4 in GCC so that we can export intrinsics of,
>>>> for example, the cryptographic instructions at some point using the
>>>> __VIS__ ve
From: Eric Botcazou
Date: Tue, 16 Oct 2012 12:10:51 +0200
>> I've scanned the documentation and there is no indication of any
>> preprocessor predefines or anything like that.
>>
>> And keep in mind that __VIS__ is our very own invention.
>>
>> Sun's compilers never predefined this.
>>
>> Thei
Differences from v1:
1) Fix configure.ac test to use it's own variable name, thanks
Rainer.
2) Get rid of __VIS__ cpp stuff.
3) The new compiler option is now called -mcbcond
4) Actually document the new option.
Thanks.
gcc/
2012-10-12 David S. Miller
* configure.ac: Add chec
Differences from v2:
1) If another control transfer comes right after a cbcond we take
an enormous performance penalty, some 20 cycles or more. The
documentation specifically warns about this, so emit a nop when
we encounter this scenerio.
2) Add a heuristic to avoid using cbcond if we
From: Vladimir Makarov
Date: Tue, 23 Oct 2012 11:46:34 -0400
> Hi, I was going to merge LRA into trunk last Sunday. It did not
> happen. LRA was actively changed last 4 weeks by implementing
> reviewer's proposals which resulted in a lot of new LRA regressions on
> GCC testsuite in comp
From: Vladimir Makarov
Date: Tue, 23 Oct 2012 19:04:03 -0400
> I am not sure that anything except x86/x86-64 will work now on the
> branch. There were too many changes on the branch and I tested only
> x86/x86-64. I'll start testing the rest of targets on the branch
> next week when LRA is sett
From: David Miller
Date: Tue, 23 Oct 2012 21:44:05 -0400 (EDT)
> The first issue sparc runs into is that it does not define it's
> extra constraints properly. In particular 'T' and 'W' must use
> define_memory_constraint.
>
> Otherwise the EXTRA_MEMORY_
While playing around with LRA on sparc I noticed that we had some
poorly formed target memory constraints on sparc.
In particular, they were not using define_memory_constraint, so we
would not get a true return from EXTRA_MEMORY_CONSTRAINT for them.
Also, these were matching 'reg' objects for sp
From: David Miller
Date: Tue, 23 Oct 2012 22:06:55 -0400 (EDT)
> From: David Miller
> Date: Tue, 23 Oct 2012 21:44:05 -0400 (EDT)
>
>> The first issue sparc runs into is that it does not define it's
>> extra constraints properly. In particular 'T' and
From: Richard Sandiford
Date: Thu, 25 Oct 2012 16:34:00 +0100
> David Miller writes:
>> I'll add the straightforward check to sparc's legitimate_address_p,
>> but I'm really surprised you never hit this case in your testing.
>
> Adding the check sounds like
From: David Miller
Date: Mon, 22 Oct 2012 23:39:23 -0400 (EDT)
> 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
>
From: Richard Sandiford
Date: Thu, 25 Oct 2012 20:57:05 +0100
> I'm hoping this will help with the x32 problems that HJ is seeing.
> Like Vlad, I don't have a set-up to try for certain, but I tried
> compiling a set of non-x32 gcc .ii files with -mx32 -maddress-mode=long
> and it fixed all but on
This was discovered while playing around with LRA, but of course
I regstrapped this using the existing reload pass.
Constraint "U" is a register constraint, that accepts either a
pseudo or an even numbered hard register. But it is bogus, and
in fact unnecessary.
First, it isn't marked as a "def
With Richard Sandiford's address decomposition patch, Sparc
looks really good on the 32-bit side. This is the patch I
am using.
2012-10-25 David S. Miller
* config/sparc/sparc.c (sparc_lra_p): New function.
(sparc_spill_class): New function.
(TARGET_LRA_P): Define.
From: "H.J. Lu"
Date: Thu, 25 Oct 2012 22:59:58 -0700
> On Wed, Oct 24, 2012 at 3:16 AM, H.J. Lu wrote:
>> On Tue, Oct 23, 2012 at 8:46 AM, Vladimir Makarov
>> wrote:
>>> Hi, I was going to merge LRA into trunk last Sunday. It did not happen.
>>> LRA was actively changed last 4 weeks by imp
From: Eric Botcazou
Date: Fri, 26 Oct 2012 09:40:08 +0200
>> While playing around with LRA on sparc I noticed that we had some
>> poorly formed target memory constraints on sparc.
>>
>> In particular, they were not using define_memory_constraint, so we
>> would not get a true return from EXTRA_M
From: Eric Botcazou
Date: Fri, 26 Oct 2012 10:04:13 +0200
>> With Richard Sandiford's address decomposition patch, Sparc
>> looks really good on the 32-bit side. This is the patch I
>> am using.
>>
>> 2012-10-25 David S. Miller
>>
>> * config/sparc/sparc.c (sparc_lra_p): New function.
From: Eric Botcazou
Date: Fri, 26 Oct 2012 10:57 +0200
>> @@ -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, -m
While I was here I filled in some gaps in the documentation.
Committed to master.
* config/sparc/constraints.md: Update unused letter list, move
"w" near other memory constraints. Remove no longer relevant
comment.
* doc/md.texi: Sync sparc constraint documentati
I'm getting a SIGBUS on every backtrace libbacktrace generates
on 32-bit sparc builds. The crashes usually happen in
add_function_range(), where 'p' is not 8-byte aligned.
It seems that the vector code doesn't take care to align the pointers
it returns. I cribbed the size alignment done in mmap
From: Ian Lance Taylor
Date: Sat, 27 Oct 2012 21:06:59 -0700
> The struct used by add_function_range is
>
> struct function_addrs
> {
> uint64_t low;
> uint64_t high;
> struct function *function;
> };
>
> So on a 32-bit system, this should have a size of 20 if uint64_t
> requires 4-byte
From: David Miller
Date: Sun, 28 Oct 2012 00:31:27 -0400 (EDT)
> The size is 24, and my patch definitely makes the crashes go away.
>
> It seems like a vector is being used for a mixed set of objects.
> I'll try to figure out how that is happening.
Ok, the problem seems t
From: Ian Lance Taylor
Date: Mon, 29 Oct 2012 08:43:42 -0700
> This patch should fix it. Bootstrapped and ran libbacktrace testsuite
> on x86_64-unknown-linux-gnu. Committed to mainline.
I can tell just by looking at your patch that it doesn't fix the
problem.
It's "vec->base + vec->size" tha
From: Jakub Jelinek
Date: Mon, 29 Oct 2012 18:56:42 +0100
> I'd like to close the stage 1 phase of GCC 4.8 development
> on Monday, November 5th. If you have still patches for new features you'd
> like to see in GCC 4.8, please post them for review soon. Patches
> posted before the freeze, but
From: Ian Lance Taylor
Date: Mon, 29 Oct 2012 11:13:19 -0700
> Sure, if you can confirm that this patch fails, I will take another look.
It fails.
Same problem, SIGBUS.
From: Ian Lance Taylor
Date: Mon, 29 Oct 2012 11:13:19 -0700
> I changed it from vec->base + vec->size. Now it is vec->base
> + size, where size is the aligned version of vec->size.
It is not.
You don't modify 'size' at all.
From: Ian Lance Taylor
Date: Mon, 29 Oct 2012 11:31:33 -0700
> On Mon, Oct 29, 2012 at 11:15 AM, David Miller wrote:
>> From: Ian Lance Taylor
>> Date: Mon, 29 Oct 2012 11:13:19 -0700
>>
>>> I changed it from vec->base + vec->size. Now it is vec->bas
From: Eric Botcazou
Date: Mon, 29 Oct 2012 20:25:15 +0100
>> I'd like to get the Sparc cbcond stuff in (3 revisions posted) which
>> is waiting for Eric B. to do some Solaris specific work.
>>
>> I'd also like to enable LRA for at least 32-bit sparc, even if I can't
>> find the time to work on a
From: David Miller
Date: Mon, 29 Oct 2012 14:33:33 -0400 (EDT)
> From: Ian Lance Taylor
> Date: Mon, 29 Oct 2012 11:31:33 -0700
>
>> On Mon, Oct 29, 2012 at 11:15 AM, David Miller wrote:
>>> From: Ian Lance Taylor
>>> Date: Mon, 29 Oct 2012 11:13:19 -0700
>
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
From: Eric Botcazou
Date: Sat, 12 Sep 2015 16:04:09 +0200
> You need to update https://gcc.gnu.org/backends.html
Done.
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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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, 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: 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
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: 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
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: 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
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: 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?
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: 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
>
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: 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
This broke the bootstrap on sparc:
/home/davem/src/GIT/GCC/build-sparc32-linux/./prev-gcc/g++
-B/home/davem/src/GIT/GCC/build-sparc32\
-linux/./prev-gcc/ -B/usr/local/sparc-unknown-linux-gnu/bin/ -nostdinc++
-B/home/davem/src/GIT/GCC\
/build-sparc32-linux/prev-sparc-unknown-linux-gnu/libstdc++-
From: Jan Hubicka
Date: Mon, 5 Nov 2012 23:19:16 +0100
> Is line 784 for you "gcc_checking_assert (uninlined_call_time >= 0);"?
Yes.
From: Jan Hubicka
Date: Tue, 6 Nov 2012 19:21:46 +0100
> The problem here is really that MAX_TIME * MAX_FREQ do not fit into 32bit
> integer. Fixed thus.
>
> * ipa-inline.c (compute_uninlined_call_time): Return gcov_type.
> (compute_inlined_call_time): Watch overflows.
> (rela
From: David Miller
Date: Tue, 06 Nov 2012 13:26:53 -0500 (EST)
> From: Jan Hubicka
> Date: Tue, 6 Nov 2012 19:21:46 +0100
>
>> The problem here is really that MAX_TIME * MAX_FREQ do not fit into 32bit
>> integer. Fixed thus.
>>
>> * ipa-inline.c (com
From: David Miller
Date: Tue, 06 Nov 2012 13:54:01 -0500 (EST)
> From: David Miller
> Date: Tue, 06 Nov 2012 13:26:53 -0500 (EST)
>
>> From: Jan Hubicka
>> Date: Tue, 6 Nov 2012 19:21:46 +0100
>>
>>> The problem here is really that MAX_TIME * MAX_FRE
From: David Miller
Date: Tue, 06 Nov 2012 14:16:32 -0500 (EST)
> (gdb) p inline_summary (edge->caller)->time
> $1205 = -1044761
This negative value is computed by inline_update_overall_summary().
I added some debugging to dump the entry->time values processed when
info->
From: David Miller
Date: Tue, 06 Nov 2012 14:28:19 -0500 (EST)
> Or perhaps we can get away with only using gcov_t for info->time, I'll
> give that a try.
That gets thing further, but if the edge times add up to such large
values it seems we have lots of other potential proble
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.
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
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
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
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
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: 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: 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: 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: 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
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.
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..
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
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: 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: 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: 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.
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: 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
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: 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: 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: "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: 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: 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
1 - 100 of 363 matches
Mail list logo
