gccadmin | 28 May 00:35 2015
Picon

gcc-4.9-20150527 is now available

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

This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 223783

You'll find:

 gcc-4.9-20150527.tar.bz2             Complete GCC

  MD5=ff0c439b3b8c30026c8707adc1998130
  SHA1=f3ae7b1a4b96ac3e250bfacb6616e901d3033162

Diffs from 4.9-20150520 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
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.

Richard Henderson | 27 May 22:03 2015
Picon

Relocations to use when eliding plts

There's one problem with the couple of patches that I've seen go by wrt eliding
PLTs with -z now, and relaxing inlined PLTs (aka -fno-plt):

They're currently using the same relocations used by data, and thus the linker
and dynamic linker must ensure that pointer equality is maintained.  Which
results in branch-to-branch-(to-branch) situations.

E.g. the attached test case, in which main has a plt entry for function A in
a.so, and the function B in b.so calls A.

$ LD_BIND_NOW=1 gdb main
...
(gdb) b b
Breakpoint 1 at 0x400540
(gdb) run
Starting program: /home/rth/x/main
Breakpoint 1, b () at b.c:2
2	void b(void) { a(); }
(gdb) si
2	void b(void) { a(); }
=> 0x7ffff7bf75f4 <b+4>:	callq  0x7ffff7bf74e0
(gdb)
0x00007ffff7bf74e0 in ?? () from ./b.so
=> 0x7ffff7bf74e0:	jmpq   *0x20034a(%rip)        # 0x7ffff7df7830
(gdb)
0x0000000000400560 in a <at> plt ()
=> 0x400560 <a <at> plt>:	jmpq   *0x20057a(%rip)        # 0x600ae0
(gdb)
a () at a.c:2
2	void a() { printf("Hello, World!\n"); }
(Continue reading)

Martin Liška | 27 May 10:14 2015
Picon

Precompiled headers - still useful feature?

Hello.

I would like to ask folks what is their opinion about support of precompiled headers for
future releases of GCC. From my point of view, the feature brings some speed-up, but question
is if it's worth for?

Last time I hit precompiled headers was when I was rewriting memory
allocation statistics infrastructure, where GGC memory is 'streamed' and loaded afterwards
in usage of precompiled headers.
Because of that I was unable to track some pointers that were allocated in the first phase
of compilation.

There are numbers related to --disable-libstdcxx-pch option:

Intel(R) Core(TM) i7-4770 CPU  <at>  3.40GHz:
Boostrap time w/ precompiled headers enabled: 35m47s (100.00%)
Boostrap time w/ precompiled headers disabled: 36m27s (101.86%)

make -j9 check-target-libstdc++-v3 -k time:
precompiled headers enabled: 8m11s (100.00%)
precompiled headers disabled: 8m42s (106.31%)

Intel(R) Core(TM) i5-3320M CPU  <at>  2.60GHz:
Boostrap time w/ precompiled headers enabled: 57m35s (100.00%)
Boostrap time w/ precompiled headers disabled: 57m12s (99.33%)

Feel free to send any statistics, opinions and ideas.

Thank you,
Martin
(Continue reading)

Jeff Law | 27 May 05:31 2015
Picon

Re: [i386] Scalar DImode instructions on XMM registers

On 05/25/2015 09:27 AM, Ilya Enkovich wrote:
> 2015-05-22 15:01 GMT+03:00 Ilya Enkovich <enkovich.gnu <at> gmail.com>:
>> 2015-05-22 11:53 GMT+03:00 Ilya Enkovich <enkovich.gnu <at> gmail.com>:
>>> 2015-05-21 22:08 GMT+03:00 Vladimir Makarov <vmakarov <at> redhat.com>:
>>>> So, Ilya, to solve the problem you need to avoid sharing subregs for the
>>>> correct LRA/reload work.
>>>>
>>>>
>>>
>>> Thanks a lot for your help! I'll fix it.
>>>
>>> Ilya
>>
>> I've fixed SUBREG sharing and got a missing spill. I added
>> --enable-checking=rtl to check other possible bugs. Spill/fill code
>> still seems incorrect because different sizes are used.  Shouldn't
>> block me though.
>>
>> .L5:
>>          movl    16(%esp), %eax
>>          addl    $8, %esi
>>          movl    20(%esp), %edx
>>          movl    %eax, (%esp)
>>          movl    %edx, 4(%esp)
>>          call    counter <at> PLT
>>          movq    -8(%esi), %xmm0
>>          **movdqa  16(%esp), %xmm2**
>>          pand    %xmm0, %xmm2
>>          movdqa  %xmm2, %xmm0
>>          movd    %xmm2, %edx
(Continue reading)

gccadmin | 27 May 00:36 2015
Picon

gcc-5-20150526 is now available

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

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

You'll find:

 gcc-5-20150526.tar.bz2               Complete GCC

  MD5=3dfffc8efcbfc069d41239cb7578b054
  SHA1=bae3ce5b6c8f61bd1b273ae6908032b08aa416d7

Diffs from 5-20150519 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-5
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.

gccadmin | 25 May 00:35 2015
Picon

gcc-6-20150524 is now available

Snapshot gcc-6-20150524 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/6-20150524/
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/trunk revision 223635

You'll find:

 gcc-6-20150524.tar.bz2               Complete GCC

  MD5=3ddffb768e8ef51a779036c14d2b75b4
  SHA1=ac8e245242eb6f085cc68f7d3eac10ff0b724853

Diffs from 6-20150517 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-6
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.

Andreas Krebbel | 22 May 10:10 2015
Picon

IBM z13 support for older GCCs

Hi,

in order to get the IBM z13 support into present distros the Linux distributors asked me to get this
stuff upstream into the older GCC branches first. This would ease the whole backporting efforts,
interactions with other patches and would make sure that everybody uses the same code level.

This would affect at least the GCC 4.8 and 5 branches but for continuity reasons it probably also
should go into 4.9 then.

The patchset requires only very minor common code changes and therefore imposes only a low risk for
other platforms:

recog: Increased max number of alternatives - v2
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02059.html

optabs: Fix vec_perm -> V16QI middle end lowering.
https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02058.html

There is definitely some risk for S/390 but this again should be relatively low when compiling for
CPU levels prio to z13.

For the z13 support itself I've added a bunch of testcases but I've also run checks with about 10000
automatically generated testcases not part of the patchset.

We also ran the ABI comparison testsuite to compare the GCC and LLVM implementations regarding
vector data types.

Is it ok to apply the patchset to GCC 4.8, 4.9, and 5 branches as well?

Bye,
(Continue reading)

gccadmin | 22 May 00:35 2015
Picon

gcc-4.8-20150521 is now available

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

This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_8-branch revision 223505

You'll find:

 gcc-4.8-20150521.tar.bz2             Complete GCC

  MD5=8d0bef153f23afce2e3303da4b122d17
  SHA1=f965139b06ba671b1873f75c100046ad7403d3a9

Diffs from 4.8-20150514 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.8
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.

Alan Modra | 21 May 12:36 2015
Picon

[RFC] Combine related fail of gcc.target/powerpc/ti_math1.c

FAIL: gcc.target/powerpc/ti_math1.c scan-assembler-times adde 1
is seen on powerpc64le-linux since somewhere between revision 218587
and 218616.  See
https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg01287.html and
https://gcc.gnu.org/ml/gcc-testresults/2014-12/msg01325.html

A regression hunt fingers one of Segher's 2014-12-10 patches to the
rs6000 backend, git commit 0f1bedb4 or svn rev 218595.  Segher might
argue that generated code is better after this commit, and I'd agree
that his change is a good one in general, but even so it would be nice
to generate the ideal code.  Curiously, the ideal code is generated at
-O1, but we regress at -O2..

	before			after			ideal (-O1)
add_128:		add_128:		add_128:
	ld 10,0(3)		ld 9,0(3)		ld 9,0(3)
	ld 11,8(3)		ld 10,8(3)		ld 10,8(3)
	addc 8,4,10		addc 3,4,9		addc 3,4,9
	adde 9,5,11		addze 5,5		adde 4,5,10
	mr 3,8			add 4,5,10		blr
	mr 4,9			blr
	blr

I went looking into where the addze appeared, and found combine.

Trying 18, 9 -> 24:
Failed to match this instruction:
(set (reg:DI 4 4 [+8 ])
    (plus:DI (plus:DI (reg:DI 5 5 [ val+8 ])
            (reg:DI 76 ca))
(Continue reading)

gccadmin | 21 May 00:35 2015
Picon

gcc-4.9-20150520 is now available

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

This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 223463

You'll find:

 gcc-4.9-20150520.tar.bz2             Complete GCC

  MD5=f878eb14e8decde762c8aef8c1e231c7
  SHA1=75124e08cb6bb04c35f0f5f5e94d2bf669da4369

Diffs from 4.9-20150513 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.9
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.

H.J. Lu | 20 May 19:00 2015
Picon

Is there a way to adjust alignment of DImode and DFmode?

By default, alignment of DImode and DFmode is set to 8 bytes.
Intel MCU psABI specifies alignment of DImode and DFmode
to be 4 bytes. I'd like to make get_mode_alignment to return
32 bits for DImode and DFmode.   Is there a way to adjust alignment
of DImode and DFmode via ADJUST_ALIGNMENT?

--

-- 
H.J.


Gmane