On Thu, Nov 27, 2014 at 08:24:03PM +0100, Marek Polacek wrote:
> On Thu, Nov 27, 2014 at 10:56:06AM +0100, Richard Biener wrote:
> > But then rather than using integer_type_node I'd convert to
> > unsigned_type_node (if that doesn't work you know we have some nasty
> > dependence on negative shift
On Thu, Nov 27, 2014 at 10:56:06AM +0100, Richard Biener wrote:
> But then rather than using integer_type_node I'd convert to
> unsigned_type_node (if that doesn't work you know we have some nasty
> dependence on negative shift counts "working")
Yeah, I think adding the conversion into c_gimplify_
On Thu, 27 Nov 2014, Jakub Jelinek wrote:
> On Thu, Nov 27, 2014 at 10:30:16AM +0100, Richard Biener wrote:
> > On Wed, 26 Nov 2014, Jakub Jelinek wrote:
> >
> > > On Wed, Nov 26, 2014 at 10:20:39PM +0100, Richard Biener wrote:
> > > > Well, if you want to aggressively prune unused bits then you
On Thu, Nov 27, 2014 at 10:30:16AM +0100, Richard Biener wrote:
> On Wed, 26 Nov 2014, Jakub Jelinek wrote:
>
> > On Wed, Nov 26, 2014 at 10:20:39PM +0100, Richard Biener wrote:
> > > Well, if you want to aggressively prune unused bits then you could
> > > "back-propagate" the shift count value-r
On Wed, 26 Nov 2014, Jakub Jelinek wrote:
> On Wed, Nov 26, 2014 at 10:20:39PM +0100, Richard Biener wrote:
> > Well, if you want to aggressively prune unused bits then you could
> > "back-propagate" the shift count value-range.
> >
> > And note that all the frontend shorten-optimizations should
On Wed, Nov 26, 2014 at 10:20:39PM +0100, Richard Biener wrote:
> Well, if you want to aggressively prune unused bits then you could
> "back-propagate" the shift count value-range.
>
> And note that all the frontend shorten-optimizations should move to the
> middle-end.
>
> That said, instead o
On November 26, 2014 8:33:52 PM CET, Jakub Jelinek wrote:
>On Wed, Nov 26, 2014 at 02:25:54PM -0500, Jason Merrill wrote:
>> How about converting the rhs to unsigned int if it is already
>unsigned?
>
>That is fine. I'm just worried about the casts to wider types.
>So perhaps just promote and cast
On November 26, 2014 8:25:54 PM CET, Jason Merrill wrote:
>How about converting the rhs to unsigned int if it is already unsigned?
Does the standard say so? I think not.
IMHO it's not the front ends business to do this. And I don't see how it helps
either.
Richard.
>Jason
On Wed, Nov 26, 2014 at 02:25:54PM -0500, Jason Merrill wrote:
> How about converting the rhs to unsigned int if it is already unsigned?
That is fine. I'm just worried about the casts to wider types.
So perhaps just promote and cast to int if the promoted type is
signed or unsigned if it is unsig
How about converting the rhs to unsigned int if it is already unsigned?
Jason
On November 26, 2014 7:49:55 PM CET, Jakub Jelinek wrote:
>On Wed, Nov 26, 2014 at 07:20:04PM +0100, Marek Polacek wrote:
>> On Wed, Nov 26, 2014 at 06:50:29PM +0100, Jakub Jelinek wrote:
>> > On Wed, Nov 26, 2014 at 06:39:44PM +0100, Marek Polacek wrote:
>> > > Both C11 and C++14 standards specif
On Wed, Nov 26, 2014 at 07:20:04PM +0100, Marek Polacek wrote:
> On Wed, Nov 26, 2014 at 06:50:29PM +0100, Jakub Jelinek wrote:
> > On Wed, Nov 26, 2014 at 06:39:44PM +0100, Marek Polacek wrote:
> > > Both C11 and C++14 standards specify that integral promotions are
> > > performed on both operands
On 11/26/2014 01:18 PM, Joseph Myers wrote:
On Wed, 26 Nov 2014, Marek Polacek wrote:
Joseph, is that C FE part ok?
The C changes are OK once Jakub's middle-end/expander issue is resolved
(possibly by adding execution tests of shifts by in-range 64-bit and
128-bit integers, both constant and
On Wed, Nov 26, 2014 at 06:50:29PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 26, 2014 at 06:39:44PM +0100, Marek Polacek wrote:
> > Both C11 and C++14 standards specify that integral promotions are
> > performed on both operands of a shift-expression. This we do just
> > fine. But then we convert
On Wed, 26 Nov 2014, Marek Polacek wrote:
> Joseph, is that C FE part ok?
The C changes are OK once Jakub's middle-end/expander issue is resolved
(possibly by adding execution tests of shifts by in-range 64-bit and
128-bit integers, both constant and non-constant, and compilation tests of
shif
On Wed, Nov 26, 2014 at 06:39:44PM +0100, Marek Polacek wrote:
> Both C11 and C++14 standards specify that integral promotions are
> performed on both operands of a shift-expression. This we do just
> fine. But then we convert the right operand to integer_type_node.
> Not only is this unnecessary
Both C11 and C++14 standards specify that integral promotions are
performed on both operands of a shift-expression. This we do just
fine. But then we convert the right operand to integer_type_node.
Not only is this unnecessary, it can also be harfmul, because for
e.g.
void
foo (unsigned int x)
{
17 matches
Mail list logo
