This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug middle-end/77779] unnecessary trap checks for pointer subtraction with -ftrapv


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77779

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2016-09-29
     Ever confirmed|0                           |1
      Known to fail|                            |5.4.0, 6.2.0

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Same with GCC 6.  On trunk we get

diff:
.LFB0:
        .cfi_startproc
        subq    $8, %rsp
        .cfi_def_cfa_offset 16
        call    __subvdi3
        sarq    $3, %rax
        movl    $2, %esi
        movq    %rax, %rdi
        call    __mulvdi3
        addq    $8, %rsp
        .cfi_def_cfa_offset 8
        ret

because we "optimize" (canonicalize) the add to a multiplication by two.

I believe the DImode overflow minus is spurious because of the way we
represent pointer subtraction:

  a.0_1 = (long int) a_5(D);
  b.1_2 = (long int) b_6(D);
  _3 = a.0_1 - b.1_2;
  _4 = _3 /[ex] 8;

thus a - b isn't distinguishable from ((long)a - (long)b) / 8.

Anyway, confirmed.  The "fix" is to make trapping ops explicit by using
the existing builtins / internal-fns from the frontends that (want to)
implement -ftrapv.  There's a separate bug about this as well.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]