This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Possible issue with ARC gcc 4.8
- From: Vineet Gupta <Vineet dot Gupta1 at synopsys dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Joern Rennecke <amylaar at spamcop dot net>, "jeremy dot bennett at embecosm dot com" <jeremy dot bennett at embecosm dot com>, Claudiu Zissulescu <Claudiu dot Zissulescu at synopsys dot com>, GCC Development <gcc at gcc dot gnu dot org>
- Date: Mon, 6 Jul 2015 07:03:44 +0000
- Subject: Re: Possible issue with ARC gcc 4.8
- Authentication-results: sourceware.org; auth=none
- References: <559689BD dot 2050506 at synopsys dot com> <CAFiYyc2XN79uERqzJj8_=q6bcZu69zn4ALDbn3f+jrZ+p5riPA at mail dot gmail dot com> <C2D7FE5348E1B147BCA15975FBA23075665AB2D0 at IN01WEMBXB dot internal dot synopsys dot com> <CAFiYyc2yUTkVHT2RuKSiqJ_Mrq6kGD18Mw4EeSq+fn7AjzvK7w at mail dot gmail dot com>
On Monday 06 July 2015 12:04 PM, Richard Biener wrote:
>> The point being ARC ISA provides a neat feature where core only considers lower 5
>> > bits of bitpos operands. Thus we can make such behaviour not only deterministic in
>> > the context of ARC, but also optimal, eliding the need for doing specific
>> > masking/clamping to 5 bits.
> There is SHIFT_COUNT_TRUNCATED which allows you to combine
> b & 31 with the shift value if you instead write a << (b & 31).
Awesome, this is what we need for ARC then along with the user code change to add
the masking so the combiner will nullify the masking.
>
> Of course a << 63 is still undefined behavior regardless of target behavior.
Sure
Thx,
-Vineet