This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/77779] unnecessary trap checks for pointer subtraction with -ftrapv
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 29 Sep 2016 07:50:12 +0000
- Subject: [Bug middle-end/77779] unnecessary trap checks for pointer subtraction with -ftrapv
- Auto-submitted: auto-generated
- References: <bug-77779-4@http.gcc.gnu.org/bugzilla/>
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.