[Bug c/59708] New: clang-compatible checked arithmetic builtins

[Bug c/59708] New: clang-compatible checked arithmetic builtins

[josh at joshtriplett dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708

            Bug ID: 59708
           Summary: clang-compatible checked arithmetic builtins
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: c
          Assignee: unassigned at gcc dot gnu.org
          Reporter: josh at joshtriplett dot org

It would be nice to have a set of builtins for arithmetic operations that check
for overflow, ideally compatible with those available in clang; see
http://clang.llvm.org/docs/LanguageExtensions.html#checked-arithmetic-builtins
for details.

Such builtins could take advantage of native instructions that set overflow
flags, for instance.

[Bug c/59708] clang-compatible checked arithmetic builtins

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-01-07
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.

[Bug c/59708] clang-compatible checked arithmetic builtins

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Not sure I like their naming though, I'd say they should be type generic
builtins handled in the FEs depending on the first argument's type, so that
it works even for say __int128_t and similar.

For the implementation, we'd need to find out how to represent it in the GIMPLE
IL (because the functions have two return values rather than just one and
return by reference would be very optimization unfriendly).  For expansion, we
already handle this for ubsan (well, the signed +/-/* overflow), so that could
be just adjusted.

[Bug c/59708] clang-compatible checked arithmetic builtins

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> Not sure I like their naming though, I'd say they should be type generic
> builtins handled in the FEs depending on the first argument's type, so that
> it works even for say __int128_t and similar.
> 
> For the implementation, we'd need to find out how to represent it in the
> GIMPLE IL (because the functions have two return values rather than just one
> and return by reference would be very optimization unfriendly).  For
> expansion, we already handle this for ubsan (well, the signed +/-/*
> overflow), so that could be just adjusted.

If just source compatibility is asked for a functional implementation shouldn't
be difficult.

[Bug c/59708] clang-compatible checked arithmetic builtins

[josh at joshtriplett dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708

--- Comment #4 from Josh Triplett <josh at joshtriplett dot org> ---
(In reply to Jakub Jelinek from comment #2)
> Not sure I like their naming though, I'd say they should be type generic
> builtins handled in the FEs depending on the first argument's type, so that
> it works even for say __int128_t and similar.

I'd like to have builtins compatible with the clang versions, but adding a set
of type-generic versions sounds like a great idea as well.

[Bug c/59708] clang-compatible checked arithmetic builtins

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708

--- Comment #5 from joseph at codesourcery dot com <joseph at codesourcery dot com> ---
See what I said in <http://gcc.gnu.org/ml/gcc/2013-10/msg00280.html> about 
the issues with something type-generic regarding detecting overflow on 
types smaller than int.

[Bug c/59708] clang-compatible checked arithmetic builtins

[josh at joshtriplett dot org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59708

--- Comment #6 from Josh Triplett <josh at joshtriplett dot org> ---
(In reply to joseph@codesourcery.com from comment #5)
> See what I said in <http://gcc.gnu.org/ml/gcc/2013-10/msg00280.html> about 
> the issues with something type-generic regarding detecting overflow on 
> types smaller than int.

Yeah, I'd agree with the conclusion in that mail: a type-generic version
primarily needs to care about the result type, since that's where overflow
would occur.

[Bug c/59708] clang-compatible checked arithmetic builtins

[Martin.vGagern at gmx dot net]

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

Martin von Gagern <Martin.vGagern at gmx dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Martin.vGagern at gmx dot net

--- Comment #7 from Martin von Gagern <Martin.vGagern at gmx dot net> ---
I really like this request, thanks!

Cross references: bug #49467 asked for access to carry, and got duped to bug
#48580 which originally was about detecting and optimizing certain idioms which
may be used to detect overflow within the limits of the language standard. I'd
say bug #49467 might be better off duped to this one here instead.

[Bug c/59708] clang-compatible checked arithmetic builtins

[Martin.vGagern at gmx dot net]

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

--- Comment #9 from Martin von Gagern <Martin.vGagern at gmx dot net> ---
(In reply to Andrew Pinski from comment #8)
> I rather not have builtins as you can write portable C code that detects
> overflow just fine.  GCC could have internal functions if needed which are
> used when converting the pattern for detecting overflow.

Then it sounds as if bug #48580 should cater for your needs. Although bug
#48580 comment #7 raised the concern that there appears to be no commonly
established pattern, therefore detecting such patterns would become difficult.

http://stackoverflow.com/q/199333/1468366 also discusses overflow detection
patterns, and the current highest-voted answer is a performance nightmare. But
better solutions seem impossible due to the fact that according to (at least
some version of) the language specs, signed overflow leads to undefined
behavior, so the overflow has to be detected before the operation is performed.

If you want to prove me wrong, answer bug #48580 comment #5 with your favorite
pattern and show examples to support that this is in reasonably wide-spread
use.

I believe that builtins would be easier to read and easier to maintain. To me,
this sounds like an overall win, albeit at the cost of portability. But with
this proposal here we'd at least have compatibility with clang.

In any case, I don't think there is a reason against supporting both, a builtin
and a pattern detection. I consider the former far more realistic in the
forseeable future, and the latter can build on that internally.

[Bug c/59708] clang-compatible checked arithmetic builtins

[manu at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 6738 bytes --]

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |noloader at gmail dot com

--- Comment #10 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
*** Bug 49467 has been marked as a duplicate of this bug. ***
>From gcc-bugs-return-459167-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Aug 24 18:40:06 2014
Return-Path: <gcc-bugs-return-459167-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7322 invoked by alias); 24 Aug 2014 18:40:06 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 7236 invoked by uid 48); 24 Aug 2014 18:39:59 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/49467] Enhancement: Intrinsic to read CARRY and OVERFLOW flags (where applicable)
Date: Sun, 24 Aug 2014 18:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-49467-4-N5maeLbHEw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-49467-4@http.gcc.gnu.org/bugzilla/>
References: <bug-49467-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-08/txt/msg01664.txt.bz2
Content-length: 481

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

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

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

--- Comment #3 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---


*** This bug has been marked as a duplicate of bug 59708 ***
>From gcc-bugs-return-459168-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sun Aug 24 18:46:15 2014
Return-Path: <gcc-bugs-return-459168-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 9987 invoked by alias); 24 Aug 2014 18:46:15 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 9951 invoked by uid 48); 24 Aug 2014 18:46:05 -0000
From: "mikulas at artax dot karlin.mff.cuni.cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/62253] New: gcc incorrectly mixes direct atomic instructions with calls to atomic library
Date: Sun, 24 Aug 2014 18:46:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.9.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mikulas at artax dot karlin.mff.cuni.cz
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cf_gcchost cf_gcctarget cf_gccbuild attachments.created
Message-ID: <bug-62253-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-08/txt/msg01665.txt.bz2
Content-length: 2111

https://gcc.gnu.org/bugzilla/show_bug.cgi?idb253

            Bug ID: 62253
           Summary: gcc incorrectly mixes direct atomic instructions with
                    calls to atomic library
           Product: gcc
           Version: 4.9.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: mikulas at artax dot karlin.mff.cuni.cz
              Host: x86_64-unknown-linux-gnu
            Target: x86_64-unknown-linux-gnu
             Build: x86_64-unknown-linux-gnu

Created attachment 33390
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id3390&actioníit
a test case for broken atomicity on 386. Compile with -O3 -m32 -march=i386

The 386 processor lacks some atomic instructions, thus they must be emulated
using calls to a library.

The library is supposed to take a lock (possibly hashed by the address or the
atomic variable), perform the operation non-atomically, and drop the lock.

However, for some atomic operations, gcc still generates atomic instructions,
even on 386 (lock add, lock sub, lock or, lock and, lock xor, lock inc, lock
dec, xchg). The problem is that when these instructions race with the library
implementation, they break atomicity.

For example, to emulate cmpxchg, the library takes the lock, reads the value,
compares the value, writes the new value, drops the lock. If this sequence
races with directly generated "lock add" instruction, atomicity is broken,
because the lock add instruction can be executed between the read and write in
the cmpxchg library implementation.

To maintain atomicity, gcc must for each data type either always use atomic
instructions or always use calls to the library. It must not mix atomic
instructions and library calls.

To see the bug, compile the attached file with -O3 -m32 -march=i386 . You see
that functions test1, test3, test5 generate direct atomic instructions and
functions test2 and test4 generate calls to the library. When these functions
race with each other, atomicity is not guaranteed.

[Bug c/59708] clang-compatible checked arithmetic builtins

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 33855
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33855&action=edit
gcc5-pr59708-wip1.patch

WIP untested patch, which implements so far the clang compatible builtins (with
the exception of __builtin_umul*_overflow, that needs extra work) and has a
start of implementation for the Joseph's idea of type-generic builtins
(__builtin_{add,sub,mul}_overflow), which perform infinite precision signed
+/-/*, store some low bits into the memory pointed by the third argument and
return true iff the infinite precision signed result is equal to the stored
value.

Internally, where needed this is implemented as internal calls returning two
values as a _Complex int, which turned out to be easiest and generates very
good code during expansion.

I'll work on BUILTIN_UMUL*_OVERFLOW next and when that is done, continue
hacking on the type-generic stuff (so far it handles just the case where it is
easy to prove the operation never overflows, or where it can be handled like
the clang-compatible builtins (extended for other integral types like
char/short/__int128).

[Bug c/59708] clang-compatible checked arithmetic builtins

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33855|0                           |1
        is obsolete|                            |

--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 33891
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33891&action=edit
gcc5-pr59708-wip2.patch

Updated patch, this time __builtin_umul{,l,ll}_overflow should work fully, and
with the exception of widest type ({,un}signed __int128 on targets that do
support that, {,un}signed long long otherwise) also the type-generic variants.
What is still unhandled is in the widest type signed +- signed -> unsigned,
unsigned +- unsigned -> signed and mixed sign (either between operands, or
between operand and result) multiplication in the widest type.

[Bug c/59708] clang-compatible checked arithmetic builtins

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #33891|0                           |1
        is obsolete|                            |
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 33912
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33912&action=edit
gcc5-pr59708-wip3.patch

After discussions with richi on IRC, I've revamped the patch so that it uses
the
internal calls for all cases through GIMPLE, and only does all the special
casing how to best emit code during expansion.  So, all the
{ADD,SUB,MUL}_OVERFLOW internal calls now can have arbitrary types in the
arguments (signed vs. unsigned, different precision) and the result type is the
type of __real__ of the result.  The advantage of doing that is that we don't
have to decide during gimplification about the best way to emit the more rare
sign/precision combination, and depending on propagation and VRP we can emit
better code.

In this version, I've recoded most of the code I had in builtins.c to be done
during expansion and finished up handling of the last few add/sub cases (signed
+- signed into unsigned and unsigned +- unsigned into signed).  From the
previous patch, what is missing right now is type promotion (i.e. when the
result type is narrower than that of the arguments and the computation needs to
be done in wider mode, then converted to the result mode, sign or zero extended
back and compared to the wider mode result and overflow set if it doesn't
compare equal) which I'll handle tomorrow, and the 4 different cases for
multiplication not handled yet (when multiplication arguments differ or when
they are the same, but result has different sign); plus of course more
testcases and documentation.

[Bug c/59708] clang-compatible checked arithmetic builtins

[danglin at gcc dot gnu.org]

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

John David Anglin <danglin at gcc dot gnu.org> changed:

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

--- Comment #18 from John David Anglin <danglin at gcc dot gnu.org> ---
On hppa-unknown-linux-gnu, I get:

FAIL: c-c++-common/torture/builtin-arith-overflow-14.c   -O0  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-14.c   -O2  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-14.c   -O2 -flto
-fno-use-link
er-plugin -flto-partition=none  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-14.c   -O2 -flto
-fuse-linker-
plugin -fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-18.c   -O0  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-18.c   -O2  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-18.c   -O2 -flto
-fno-use-link
er-plugin -flto-partition=none  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-18.c   -O2 -flto
-fuse-linker-
plugin -fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-3.c   -O0  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-3.c   -O2  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-3.c   -O2 -flto
-fno-use-linke
r-plugin -flto-partition=none  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-3.c   -O2 -flto
-fuse-linker-p

[Bug c/59708] clang-compatible checked arithmetic builtins

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to John David Anglin from comment #18)
> On hppa-unknown-linux-gnu, I get:
> 
> FAIL: c-c++-common/torture/builtin-arith-overflow-14.c   -O0  execution test
> FAIL: c-c++-common/torture/builtin-arith-overflow-14.c   -O2  execution test
> FAIL: c-c++-common/torture/builtin-arith-overflow-14.c   -O2 -flto
> -fno-use-link
> er-plugin -flto-partition=none  execution test
> FAIL: c-c++-common/torture/builtin-arith-overflow-14.c   -O2 -flto
> -fuse-linker-
> plugin -fno-fat-lto-objects  execution test
> FAIL: c-c++-common/torture/builtin-arith-overflow-18.c   -O0  execution test
> FAIL: c-c++-common/torture/builtin-arith-overflow-18.c   -O2  execution test
> FAIL: c-c++-common/torture/builtin-arith-overflow-18.c   -O2 -flto
> -fno-use-link
> er-plugin -flto-partition=none  execution test
> FAIL: c-c++-common/torture/builtin-arith-overflow-18.c   -O2 -flto
> -fuse-linker-
> plugin -fno-fat-lto-objects  execution test
> FAIL: c-c++-common/torture/builtin-arith-overflow-3.c   -O0  execution test
> FAIL: c-c++-common/torture/builtin-arith-overflow-3.c   -O2  execution test
> FAIL: c-c++-common/torture/builtin-arith-overflow-3.c   -O2 -flto
> -fno-use-linke
> r-plugin -flto-partition=none  execution test
> FAIL: c-c++-common/torture/builtin-arith-overflow-3.c   -O2 -flto
> -fuse-linker-p

Is that with r217946 or later?

[Bug c/59708] clang-compatible checked arithmetic builtins

[dave.anglin at bell dot net]

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

--- Comment #20 from dave.anglin at bell dot net ---
On 22-Nov-14, at 2:31 AM, jakub at gcc dot gnu.org wrote:

> Is that with r217946 or later?

No.  My latest build is r217898.

--
John David Anglin    dave.anglin@bell.net

[Bug c/59708] clang-compatible checked arithmetic builtins

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

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

--- Comment #22 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
So fixed?

[Bug c/59708] clang-compatible checked arithmetic builtins

[trippels at gcc dot gnu.org]

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

--- Comment #23 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
(In reply to Marek Polacek from comment #22)
> So fixed?

Not on ppc64:

trippels@gcc2-power8 ~ % cat out_check15 | grep overflow
FAIL: gcc.dg/builtin-arith-overflow-1.c execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-10.c   -O2  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-10.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-10.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-11.c   -O2  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-11.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-11.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-17.c   -O0  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-17.c   -O2  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-17.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-17.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: c-c++-common/ubsan/float-cast-overflow-7.c   -O2  execution test
FAIL: c-c++-common/ubsan/float-cast-overflow-7.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: c-c++-common/ubsan/float-cast-overflow-7.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: c-c++-common/ubsan/float-cast-overflow-8.c   -O2  output pattern test, is
../../../../gcc/libsanitizer/ubsan/ubsan_handlers.cc:300: runtime error: value
0 is outside the range of representable values of type 'signed char'
FAIL: c-c++-common/ubsan/float-cast-overflow-8.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  output pattern test, is
../../../../gcc/libsanitizer/ubsan/ubsan_handlers.cc:300: runtime error: value
0 is outside the range of representable values of type 'signed char'
FAIL: c-c++-common/ubsan/float-cast-overflow-8.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  output pattern test, is
../../../../gcc/libsanitizer/ubsan/ubsan_handlers.cc:300: runtime error: value
0 is outside the range of representable values of type 'signed char'
FAIL: c-c++-common/torture/builtin-arith-overflow-10.c   -O2  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-10.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-10.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-11.c   -O2  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-11.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-11.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-17.c   -O0  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-17.c   -O2  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-17.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: c-c++-common/torture/builtin-arith-overflow-17.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: c-c++-common/ubsan/float-cast-overflow-7.c   -O2  execution test
FAIL: c-c++-common/ubsan/float-cast-overflow-7.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: c-c++-common/ubsan/float-cast-overflow-7.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: c-c++-common/ubsan/float-cast-overflow-8.c   -O2  output pattern test, is
../../../../gcc/libsanitizer/ubsan/ubsan_handlers.cc:300: runtime error: value
0 is outside the range of representable values of type 'signed char'
FAIL: c-c++-common/ubsan/float-cast-overflow-8.c   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  output pattern test, is
../../../../gcc/libsanitizer/ubsan/ubsan_handlers.cc:300: runtime error: value
0 is outside the range of representable values of type 'signed char'
FAIL: c-c++-common/ubsan/float-cast-overflow-8.c   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  output pattern test, is
../../../../gcc/libsanitizer/ubsan/ubsan_handlers.cc:300: runtime error: value
0 is outside the range of representable values of type 'signed char'

[Bug c/59708] clang-compatible checked arithmetic builtins

[schwab@linux-m68k.org]

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

--- Comment #24 from Andreas Schwab <schwab@linux-m68k.org> ---
builtin-arith-overflow-14.c still fails on ppc32 as of r218249.

[Bug c/59708] clang-compatible checked arithmetic builtins

[jakub at gcc dot gnu.org]

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

--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 34179
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34179&action=edit
gcc5-pr59708.patch

Untested fix for the ppc32 builtin-arith-overflow-14.c failure. 
expand_widening_mult something, const0_rtx was happily trying to expand double
word shifts by -1.

[Bug c/59708] clang-compatible checked arithmetic builtins

[jakub at gcc dot gnu.org]

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

--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Dec  3 20:35:08 2014
New Revision: 218331

URL: https://gcc.gnu.org/viewcvs?rev=218331&root=gcc&view=rev
Log:
    PR c/59708
    * expmed.c (expand_widening_mult): Return const0_rtx if
    coeff is 0.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/expmed.c

[Bug c/59708] clang-compatible checked arithmetic builtins

[jakub at gcc dot gnu.org]

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

--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Wed Dec  3 20:38:44 2014
New Revision: 218333

URL: https://gcc.gnu.org/viewcvs?rev=218333&root=gcc&view=rev
Log:
    PR c/59708
    * expmed.c (expand_widening_mult): Return const0_rtx if
    coeff is 0.

Modified:
    branches/gcc-4_9-branch/gcc/ChangeLog
    branches/gcc-4_9-branch/gcc/expmed.c

[Bug c/59708] clang-compatible checked arithmetic builtins

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #28 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Assuming fixed.

[Bug c/59708] clang-compatible checked arithmetic builtins

[pthaugen at gcc dot gnu.org]

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

--- Comment #30 from Pat Haugen <pthaugen at gcc dot gnu.org> ---
(In reply to Pat Haugen from comment #29)
> (In reply to Jakub Jelinek from comment #28)
> > Assuming fixed.
> 
> builtin-arith-overflow-14/17 are fixed with the patch, but
> builtin-arith-overflow-1/10/11 still fail for me.
> 
> 

builtin-arith-overflow-1 has been fixed by testsuite patch.
builtin-arith-overflow-10/11 are target problem, I'm working on a fix.

[Bug c/59708] clang-compatible checked arithmetic builtins

[pthaugen at gcc dot gnu.org]

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

--- Comment #31 from Pat Haugen <pthaugen at gcc dot gnu.org> ---
(In reply to Pat Haugen from comment #30)
> builtin-arith-overflow-10/11 are target problem, I'm working on a fix.

builtin-arith-overflow-10/11 are fixed with the patch for pr64358.