[Bug c/68046] New: -ftrapv doesn't catch leaq-based overflows on x86-64

[Bug c/68046] New: -ftrapv doesn't catch leaq-based overflows on x86-64

[eggert at gnu dot org]

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

            Bug ID: 68046
           Summary: -ftrapv doesn't catch leaq-based overflows on x86-64
           Product: gcc
           Version: 5.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: eggert at gnu dot org
  Target Milestone: ---

On x86-64 for this program:

long i = 0x7fffffffffffffffL;
int main (void)
{
  return i + 1 < i;
}

gcc -ftrapv -O2 -S generates this code:

main:
        movq    i(%rip), %rax
        leaq    1(%rax), %rdx
        cmpq    %rdx, %rax
        setg    %al
        movzbl  %al, %eax
        ret

which does not trap, even though the addition overflows.

[Bug middle-end/68046] -ftrapv doesn't catch leaq-based overflows on x86-64

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
-fsantize=undefined is more recommended for Linux and recent versions of gcc
instead of -ftrapv.

[Bug middle-end/68046] -ftrapv doesn't catch leaq-based overflows on x86-64

[joseph at codesourcery dot com]

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

--- Comment #2 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
I wonder if it would be possible to map -ftrapv to something like 
-fsanitize=signed-integer-overflow -fsanitize-undefined-trap-on-error 
(whatever is most closely equivalent to -ftrapv and doesn't require 
libubsan).  Then we could get rid of the separate -ftrapv code paths, 
which never worked well (while keeping the shared libgcc functions for 
compatibility, of course).

[Bug middle-end/68046] -ftrapv doesn't catch leaq-based overflows on x86-64

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
If we have a variant that doesn't require libubsan (which is not available
on all targets) then yes, that would indeed be nice.  Of course it's restricted
to the C family languages while -ftrapv was "working" for all languages before
(though IIRC Ada has its own implementation).

Note this bug may be a duplicate (and I must admit I didn't end up committing
a few fixes I had for some of the -ftrapv bugs...).  The testcase works in
my dev tree:

main:
.LFB0:
        .cfi_startproc
        pushq   %rbx
        .cfi_def_cfa_offset 16
        .cfi_offset 3, -16
        movq    i(%rip), %rbx
        movl    $1, %esi
        movq    %rbx, %rdi
        call    __addvdi3
        cmpq    %rax, %rbx
        setg    %al
        movzbl  %al, %eax
        popq    %rbx
        .cfi_def_cfa_offset 8
        ret

> ./a.out
Aborted

Sorry about that... :/  (see PR61893)

I'm going to re-test and commit the optab changes (which I believe triggers
the above issue).

*** This bug has been marked as a duplicate of bug 61893 ***

[Bug middle-end/68046] -ftrapv doesn't catch leaq-based overflows on x86-64

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note that -fsanitize-undefined doesn't properly handle

  volatile int x = __INT_MAX__ + 1;

which is in PR61893, it handles the case in this PR fine and with
trap-on-error more efficiently than -ftrapv:

main:
.LFB0:
        .cfi_startproc
        movq    i(%rip), %rax
        movq    %rax, %rdx
        addq    $1, %rdx
        jo      .L6
        cmpq    %rdx, %rax
        setg    %al
        movzbl  %al, %eax
        ret
.L6:
        ud2
        .cfi_endproc

of course you simply get a SIGILL (on x86_64), an option to use
abort () would be more "compatible" with how -ftrapv behaves
(abort is also used on targets that do not have a trapping instruction
defined).

[Bug middle-end/68046] -ftrapv doesn't catch leaq-based overflows on x86-64

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Thu Oct 22 11:44:11 2015
New Revision: 229170

URL: https://gcc.gnu.org/viewcvs?rev=229170&root=gcc&view=rev
Log:
2015-10-22  Richard Biener  <rguenther@suse.de>

        PR middle-end/68046
        PR middle-end/61893
        * optabs.c (emit_libcall_block_1): Allow a NULL_RTX equiv.
        (expand_binop): For -ftrapv optabs do not record an REG_EQUAL note.
        (expand_unop): Likewise.

        * gcc.dg/torture/ftrapv-2.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/torture/ftrapv-2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/optabs.c
    trunk/gcc/testsuite/ChangeLog

[Bug middle-end/68046] -ftrapv doesn't catch leaq-based overflows on x86-64

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> If we have a variant that doesn't require libubsan (which is not available
> on all targets) then yes, that would indeed be nice.  Of course it's
> restricted to the C family languages while -ftrapv was "working" for all
> languages before (though IIRC Ada has its own implementation).

Correct, the Ada compiler doesn't use -ftrapv at all, it's too broad.