Hi Alan,
>> I'm still not really comfortable with those target lists; they tend to
>> artificially exclude tests on targets where they are perfectly capable
>> of running. At least with the comments added, it's better than before
>> with no explanation whatsoever. Perhaps Mike can weigh in here?
Rainer Orth wrote:
I'm still not really comfortable with those target lists; they tend to
artificially exclude tests on targets where they are perfectly capable
of running. At least with the comments added, it's better than before
with no explanation whatsoever. Perhaps Mike can weigh in here?
Alan,
sorry for letting the ball drop on this one.
> Well, I'd be happy with that. Curiously, that patch is identical to what I
> have here...and that's not what I got having built gcc with
> --target=sparc-sun-solaris2.11, but on further investigation it looks like
> the require-effective-target
Well, I'd be happy with that. Curiously, that patch is identical to what I have
here...and that's not what I got having built gcc with
--target=sparc-sun-solaris2.11, but on further investigation it looks like the
require-effective-target-ilp32/64 is not working correctly on my setup.
FWIW I'v
Alan Lawrence writes:
> Rainer Orth wrote:
>>> However, as a quick first step, does adding the ilp32 / lp64 (and keeping
>>> the architectures list for now) solve the immediate problem? Patch
>>> attached, OK for trunk?
>>
>> No, as I said this is wrong for biarch targets like sparc and i386.
>
>
Rainer Orth wrote:
However, as a quick first step, does adding the ilp32 / lp64 (and keeping
the architectures list for now) solve the immediate problem? Patch
attached, OK for trunk?
No, as I said this is wrong for biarch targets like sparc and i386.
When you say no this does not solve the
Alan Lawrence writes:
> Mmmm, I've made a few attempts at filtering according to LP64 and ILP32,
> but not managed to get anything working so far (that is, I've ended up with
> the test not being executed on platforms where it should)ah, I see now
> where I've been going wrong, patch attached
target ILP32
--Alan
From: Rainer Orth [r...@cebitec.uni-bielefeld.de]
Sent: 23 October 2014 14:10
To: Andreas Schwab
Cc: Alan Lawrence; Jeff Law; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Relax check against commuting XOR and ASHIFTRT in combine.c
An
Andreas Schwab writes:
> Alan Lawrence writes:
>
>> diff --git a/gcc/testsuite/gcc.dg/combine_ashiftrt_1.c
>> b/gcc/testsuite/gcc.dg/combine_ashiftrt_1.c
>> new file mode 100644
>> index
>> ..90e64fd10dc358f10ad03a90041605bc3ccb7011
>> --- /dev/null
>> +++
Alan Lawrence writes:
> diff --git a/gcc/testsuite/gcc.dg/combine_ashiftrt_1.c
> b/gcc/testsuite/gcc.dg/combine_ashiftrt_1.c
> new file mode 100644
> index
> ..90e64fd10dc358f10ad03a90041605bc3ccb7011
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/combine_a
On 22 September 2014 12:16, Alan Lawrence wrote:
> Ok thanks Jeff. In that case I think I should draw this to the attention of
> the AArch64 maintainers to check the testsuite updates are OK before I
> commit...?
OK with me.
Cheers
/Marcus
On 09/22/14 05:16, Alan Lawrence wrote:
Ok thanks Jeff. In that case I think I should draw this to the attention
of the AArch64 maintainers to check the testsuite updates are OK before
I commit...?
Can't hurt.
Methinks it may be possible to get further, or at least increase our
confidence, if
Ok thanks Jeff. In that case I think I should draw this to the attention of the
AArch64 maintainers to check the testsuite updates are OK before I commit...?
Methinks it may be possible to get further, or at least increase our confidence,
if I "mock" out try_widen_shift_mode, and/or try injecti
On 09/18/14 03:35, Alan Lawrence wrote:
Moreover, I think we both agree that if result_mode==shift_mode, the
transformation is correct. "Just" putting that check in, achieves
what I'm trying for here, so I'd be happy to go with the attached
patch and call it a day. However, I'm a little concerned
Thanks for the reply - and the in-depth investigation. I agree that the
correctness of the compiler is critical rather than particular platforms such as
Ada / Alpha.
Moreover, I think we both agree that if result_mode==shift_mode, the
transformation is correct. "Just" putting that check in, achie
On 07/17/14 10:56, Alan Lawrence wrote:
Ok, the attached tests are passing on x86_64-none-linux-gnu,
aarch64-none-elf, arm-none-eabi, and a bunch of smaller platforms for
which I've only built a stage 1 compiler (i.e. as far as necessary to
assemble). That's with either change to simplify_shift_c
Thanks to Arnaud for confirming that Adacore does not have interest in the
Ada/Alpha combination
(https://gcc.gnu.org/ml/gcc-patches/2014-08/msg01832.html).
As per below, I've tested check-ada on x86_64-none-linux-gnu without problems.
Can I say, "ping"? :)
Cheers, Alan
Alan Lawrence wrote:
Ok, the attached tests are passing on x86_64-none-linux-gnu, aarch64-none-elf,
arm-none-eabi, and a bunch of smaller platforms for which I've only built a
stage 1 compiler (i.e. as far as necessary to assemble). That's with either
change to simplify_shift_const_1.
As to the addition of "result
Thanks for the suggestions! I think I've got a reasonably platform-independent
testcase that scans the rtl dump, just trying it on a few more platforms now...
As to running on Alpha: bootstrap succeeds, and the regression testsuite doesn't
raise any issues (https://gcc.gnu.org/ml/gcc-testresult
On 06/30/14 13:05, Alan Lawrence wrote:
combine.c includes a check which prevents
(ashiftrt (xor A C2) C1)
from being commuted to
(xor (ashiftrt A C1) (ashiftrt C2 C1))
for constants C1, C2 if C2 has its sign bit set.
Specifically, this prevents (ashiftrt (not A) C1) from being commuted to
combine.c includes a check which prevents
(ashiftrt (xor A C2) C1)
from being commuted to
(xor (ashiftrt A C1) (ashiftrt C2 C1))
for constants C1, C2 if C2 has its sign bit set.
Specifically, this prevents (ashiftrt (not A) C1) from being commuted to
(not (ashiftrt A C1))
because the former
21 matches
Mail list logo
