Hi,
On 11/10/19 18:25, Jason Merrill wrote:
On 10/10/19 2:33 PM, Paolo Carlini wrote:
Hi,
On 10/10/19 19:57, Jason Merrill wrote:
On 10/10/19 1:53 PM, Jakub Jelinek wrote:
On Thu, Oct 10, 2019 at 06:12:02PM +0200, Paolo Carlini wrote:
while working on cp_build_binary_op I noticed that the testsuite
wasn't
exercising the warnings in case RROTATE_EXPR / LROTATE_EXPR, even
more the
code handling those tree codes seemed completely unused. Turned
out that the
C front-end doesn't handle those tree codes at all: I'm coming to the
conclusion that the C++ front-end bits too are now obsolete and
may be
removed, because only the middle-end generates those codes in
order to
implement optimizations. Anything I'm missing? Any additional
testing?
I guess it depends on where.
fold_binary_loc certainly has code to create {L,R}ROTATE_EXPR,
just look at
unsigned foo (unsigned x)
{
return (x << 3) + (x >> (__SIZEOF_INT__ * __CHAR_BIT__ - 3));
}
unsigned bar (unsigned x, unsigned y)
{
return (x << y) | (x >> (__SIZEOF_INT__ * __CHAR_BIT__ - y));
}
and the *.original dump.
The cp_build_binary_op case is unlikely to ever trigger, unless
we'd rerun
it on cp_folded trees.
cxx_eval_constant_expression is unlikely, because recently we've
switched to
performing constexpr evaluation on pre-cp_folded bodies, not sure
if we
never encounter folded trees though.
cp_fold itself depends on whether we ever reprocess the already folded
trees, I'd be afraid we could.
True, and the failure mode there is silent. Let's leave the codes
in that switch.
Ok, thanks Jason and Jakub for the additional information.
While I give this more thought and maybe manage to come up with a
testcase triggering the warning, shall we simply pass the location to
those two warnings too - cannot hurt, AFAICS?
I meant let's omit the changes to cp_fold, the rest of the patch is
still OK.
Nice, thanks, I'll do that.
Paolo.
