Snapshot gcc-6-20161117 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20161117/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6
Thanks for the comments.
Richard Biener writes:
> On Fri, Nov 11, 2016 at 6:50 PM, Richard Sandiford
>> Constructing variable-length vectors
>>
>>
>> Currently both tree and rtl vector constants require the number of
>> elements to be known at compile time and
Got an error from gcc@gcc.gnu.org alias. Remove the pdf attachment and
re-send it to the alias ...
On 11/14/2016 4:34 PM, Bin Fan wrote:
Hi All,
I have an updated version of libatomic ABI specification draft. Please
take a look to see if it matches GCC implementation. The purpose of
this doc
On 17 November 2016 at 03:58, lhmouse wrote:
> If a program is compiled with `-fno-exceptions` and an exception
> will have been thrown otherwise, `std::abort()` (or an equivalent such as
> `__builtin_trap()`) is called. This preserves the semantical correctness
> of not checking the value of a thr
Hi Markus,
I feel deeply embarrassed now ... the sanitizer indeed found a spot
where I relied on (undefined) semantics of signed integer overflow.
Changing the offending "int" to "unsigned" fixed the problem.
Thanks a lot for the tip - I will definitely use the sanitizers more
often in the future
On Fri, Nov 11, 2016 at 6:50 PM, Richard Sandiford
wrote:
> As described in the covering note, one of big differences for SVE is that
> things like mode sizes, offsets, and numbers of vector elements can depend
> on a runtime parameter. This message describes how the SVE patches handle
> that and
On Thu, 17 Nov 2016, Martin Reinecke wrote:
> Hi,
>
> At some point in May 2016 there was a patch to the gcc trunk which
> caused one of my numerical codes to give incorrect results when compiled
> with this gcc version. This may of course be caused by some undefined
> behavior I'm unknowingly in
On 2016.11.17 at 10:49 +0100, Martin Reinecke wrote:
> Hi,
>
> At some point in May 2016 there was a patch to the gcc trunk which
> caused one of my numerical codes to give incorrect results when compiled
> with this gcc version. This may of course be caused by some undefined
> behavior I'm unknow
Hi,
At some point in May 2016 there was a patch to the gcc trunk which
caused one of my numerical codes to give incorrect results when compiled
with this gcc version. This may of course be caused by some undefined
behavior I'm unknowingly invoking in the code, or it may be a code
generation bug in
