gcc-7-20171130 is now available

[gccadmin]

Snapshot gcc-7-20171130 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/7-20171130/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch 
revision 255283

You'll find:

 gcc-7-20171130.tar.xzComplete GCC

  SHA256=67943b4a7d72c93a3b7e89b7e3632cf021360385131b1f9ebfc983fcd4dfd01c
  SHA1=9615abf9437980227f5caff2b791b0a1b979c02d

Diffs from 7-20171123 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: loading of zeros into {x,y,z}mm registers

[Kirill Yukhin]

Hello Jan,
On 29 Nov 08:59, Jan Beulich wrote:
> Kirill,
> 
> in an unrelated context I've stumbled across a change of yours
> from Aug 2014 (revision 213847) where you "extend" the ways
> of loading zeros into registers. I don't understand why this was
> done, and the patch submission mail also doesn't give any reason.
> My point is that simple VEX-encoded vxorps/vxorpd/vpxor with
> 128-bit register operands ought to be sufficient to zero any width
> registers, due to the zeroing of the high parts the instructions do.
> Hence by using EVEX encoded insns it looks like all you do is grow
> the instruction length by one or two bytes (besides making the
> source somewhat more complicated to follow). At the very least
> the shorter variants should be used for -Os imo.
As far as I can recall, this was done since we cannot load zeroes
into upper 16 MM registers, which are available in EVEX exclusively.

> 
> Thanks for any insight,
> Jan
>

--
Thanks, K