On 09/08/2016 02:53 AM, Uros Bizjak wrote:
On Mon, Sep 5, 2016 at 1:45 PM, Joseph Myers wrote:
On Sun, 4 Sep 2016, Uros Bizjak wrote:
It looks that different handling of _Complex char, _Complex short and
_Complex float is there on purpose. Is (was?) there a limitation in a
c language standard
On Sep 8, 2016, at 1:53 AM, Uros Bizjak wrote:
>
> On Mon, Sep 5, 2016 at 1:45 PM, Joseph Myers wrote:
>> On Sun, 4 Sep 2016, Uros Bizjak wrote:
>>
>>> It looks that different handling of _Complex char, _Complex short and
>>> _Complex float is there on purpose. Is (was?) there a limitation in a
Well, my concern is not what happens with overflow (which in second
case -fsanitize=undefined will address), but rather consistency of
that 2 cases.
p[x+1] generates RTL which leads to better generated code at the
expense of leading to overflow, while p[1+x] never overflows but leads
to worse code
On 09/09/2016 04:13 PM, David Malcolm wrote:
On Fri, 2016-09-09 at 14:28 +0200, Florian Weimer wrote:
For compile-time fortify checks (such as the wrappers for type-safe
open/openat), we need to add tests in glibc which examine the
compiler
output for warnings and errors.
I do not want to add D
On Sun, 11 Sep 2016, Igor Shevlyakov wrote:
Small sample below fails (at least on 6.1) for multiple targets. The
difference between two functions start at the very first tree pass...
You are missing -fsanitize=undefined (and #include ).
Please use the mailing list gcc-h...@gcc.gnu.org next ti
