[Bug target/90309] New: Spurious warning shift-negative-value

2019-05-02 Thread philipp.lucas at siemens dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90309

Bug ID: 90309
   Summary: Spurious warning shift-negative-value
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: philipp.lucas at siemens dot com
  Target Milestone: ---

Created attachment 46272
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46272&action=edit
Test case

Consider the following code:

  struct O { 
char c;
  };

  typedef void (O::*MP)(void);

  struct Uv : O {
virtual void v();
void f();  
  };

  MP mfv=static_cast(&Uv::f);

When compiled for MIPS, this triggers the following warning:

  > mips-sde-elf-gcc -c -Wshift-negative-value shift.cpp

  warning: left shift of negative value [-Wshift-negative-value]
 MP mfv=static_cast(&Uv::f);

The reason for this seems to be the left shift in 

  build_ptrmemfunc (tree type, tree pfn, int force, bool c_cast_p,
  tsubst_flags_t complain)
  ...
  if (!integer_zerop (n))
{
  if (TARGET_PTRMEMFUNC_VBIT_LOCATION == ptrmemfunc_vbit_in_delta)
  n = cp_build_binary_op (input_location,
LSHIFT_EXPR, n, integer_one_node,
complain);
  delta = cp_build_binary_op (input_location,
  PLUS_EXPR, delta, n, complain);
}

where n->int_cst.val == -4 , which is to be expected.

I do not think such an internally generated shift should give rise to a user
visible warning, which will make the user search in vain for a shift in the
original code.

[Bug c++/90309] Spurious warning shift-negative-value

2019-05-21 Thread philipp.lucas at siemens dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90309

Philipp Lucas  changed:

   What|Removed |Added

 Target|mips|mips, arm
URL||https://gcc.godbolt.org/z/8
   ||PBJOW

--- Comment #2 from Philipp Lucas  ---
The problem also occurs on ARM, see https://gcc.godbolt.org/z/8PBJOW .

[Bug c++/90309] Spurious warning shift-negative-value

2019-05-22 Thread philipp.lucas at siemens dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90309

--- Comment #5 from Philipp Lucas  ---
(In reply to Marek Polacek from comment #4)
> ...but first it'd be nice to find out *why* we're shifting by -4 and how
> that can be.

It's not shifting /by/ -4, the -4 is shifted by 1. The ARM ABI says in ยง3.2.1
"This ABI specifies that adj contains /twice the this adjustment/, plus 1 if
the member function is virtual.", and the shift seems to be the choice of
implementation for the "twice". 

As a layman's guess, replacing the shift by a multiplication with 2 should fix
it, right?