Re: r219977 - in /trunk/gcc: ChangeLog config/rs600...

[Jakub Jelinek]

On Tue, Feb 03, 2015 at 10:23:22PM -0500, David Edelsohn wrote:
> On Tue, Feb 3, 2015 at 5:55 PM, Andreas Schwab  wrote:
> > FAIL: gcc.dg/builtins-58.c scan-assembler-not pow
> >
> > $ grep pow builtins-58.s
> > .machine power4
> 
> Any suggestions?

Perhaps tighten up the regexp, like (untested)?
/* { dg-final { scan-assembler-not "pow\[^a-zA-Z0-9\]" } } */

Jakub

Re: [PR64817-related 2/3] don't alloc rtl when failing to simplify XOR of AND

[Jakub Jelinek]

On Wed, Feb 04, 2015 at 04:11:03AM -0200, Alexandre Oliva wrote:
> for  gcc/ChangeLog
> 
>   PR debug/64817
>   * simplify-rtx.c (simplify_binary_operation_1): Rewrite
>   simplification of XOR of AND to not allocate new rtx before
>   committing to a simplification.

Ok, thanks.

Jakub

Re: [PR64817-related 1/3] fix debug expr expand of compares

[Jakub Jelinek]

On Wed, Feb 04, 2015 at 03:56:56AM -0200, Alexandre Oliva wrote:
> for  gcc/ChangeLog
> 
>   PR debug/64817
>   * cfgexpand.c (expand_debug_expr): Compute unsignedp from
>   operands for tcc_comparison exprs.  Fix typos.
> 
> for  gcc/testsuite/ChangeLog
> 
>   PR debug/64817
>   * gcc.dg/pr64817-3.c: New.

Ok, thanks.

Jakub

RE: [PATCH] Fix PR64822: incorrect folding of bitfield in union on big endian targets

[Thomas Preud'homme]

> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Wednesday, February 04, 2015 3:54 PM
> 
> Richard already acked it with the new testcase, so yes, this is ok for the
> trunk (just use today's date).

Oups my bad, I forgot he acked it.

Thanks and best regards.

Thomas

Re: [PR64817-related 3/3] simplify xor of (and or ior) of xor

[Jakub Jelinek]

On Wed, Feb 04, 2015 at 04:21:43AM -0200, Alexandre Oliva wrote:
> I'm a bit surprised the gimple layer does not even attempt to simplify
> them, but I didn't try to tackle that, since I was not even sure this
> was a useful optimization.  After all, how often do we see xor of and of
> xor of and of xor of... in the wild, rather than in pathological
> testcases? :-)  But hey, at least the rtl simplification is cheap, so
> why not?

I think we should teach at least VRP to simplify debug stmts similarly how
it simplifies normal comparisons etc. using value ranges, but that would be
stage1 material.

> Regstrapped on x86_64-linux-gnu and i686-pc-linux-gnu.  Ok to install?
> 
> for  gcc/ChangeLog
> 
>   * simplify-rtx.c (simplify_binary_operation_1): Simplify one
>   of two XORs that have an intervening AND or IOR.

Ok, thanks.

Jakub

Re: [PR64817-related 3/3] simplify xor of (and or ior) of xor

[Richard Biener]

On February 4, 2015 9:35:13 AM CET, Jakub Jelinek  wrote:
>On Wed, Feb 04, 2015 at 04:21:43AM -0200, Alexandre Oliva wrote:
>> I'm a bit surprised the gimple layer does not even attempt to
>simplify
>> them, but I didn't try to tackle that, since I was not even sure this
>> was a useful optimization.  After all, how often do we see xor of and
>of
>> xor of and of xor of... in the wild, rather than in pathological
>> testcases? :-)  But hey, at least the rtl simplification is cheap, so
>> why not?
>
>I think we should teach at least VRP to simplify debug stmts similarly
>how
>it simplifies normal comparisons etc. using value ranges, but that
>would be
>stage1 material.

So I suppose this is only about debug exprs and we optimize regular gimple 
well?  Otherwise adding some patterns to match.PD could help.

Richard.

>> Regstrapped on x86_64-linux-gnu and i686-pc-linux-gnu.  Ok to
>install?
>> 
>> for  gcc/ChangeLog
>> 
>>  * simplify-rtx.c (simplify_binary_operation_1): Simplify one
>>  of two XORs that have an intervening AND or IOR.
>
>Ok, thanks.
>
>   Jakub

Re: PR lto/64837: lto plugin doesn't call ld_plugin_release_input_file

[Richard Biener]

On February 4, 2015 5:49:13 AM CET, Cary Coutant  wrote:
>The plugin is not supposed to call release_input_file from the
>claim_file handler. That interface is only for releasing a file
>descriptor obtained via get_input_file during the all_symbols_read
>callback. When the linker calls the claim_file handler, the file
>descriptor is open, and the plugin is required to leave it open; the
>linker manages the file descriptor at that point. The
>get_input_file/release_input_file pair of interfaces was added later,
>for the benefit of another (non-LTO) plugin (although I think the LLVM
>LTO plugin does use that pair during the all_symbols_read callback).
>
>This is described here:
>
>   https://gcc.gnu.org/wiki/whopr/driver
>
>If you're going to insist on calling the release_input_file API from
>the claim_file handler, I'm going to have to fix gold to ignore the
>call to avoid a premature unlock of the object file.

What's the proper solution for not leaking those filedescriptors?

Richard.

>-cary
>
>
>
>On Wed, Jan 28, 2015 at 4:02 PM, H.J. Lu  wrote:
>> On Wed, Jan 28, 2015 at 11:37 AM, H.J. Lu 
>wrote:
>>> On Wed, Jan 28, 2015 at 11:19 AM, Richard Biener
>>>  wrote:
 On January 28, 2015 7:12:43 PM CET, "H.J. Lu"
> wrote:
>Hi,
>
>This patch makes claim_file_handler to call release_input_file
>after it
>finishes processing input file.  OK for trunk?

 OK.  How did you test this?
>>>
>>> I did normal bootstrap and "make check" on Linux/x86-64.
>>> I also run ld.bfd and ld.gold by hand to verify that
>release_input_file
>>> is called.
>>>
>>
>> This is needed for LTO build.  ar/nm/ranlib don't provide
>> release_input_file.  I checked it in as an obvious fix.
>>
>> --
>> H.J.
>> ---
>> Index: ChangeLog
>> ===
>> --- ChangeLog (revision 220212)
>> +++ ChangeLog (working copy)
>> @@ -1,5 +1,10 @@
>>  2015-01-28  H.J. Lu  
>>
>> + * lto-plugin.c (claim_file_handler): Call release_input_file only
>> + if it is not NULL.
>> +
>> +2015-01-28  H.J. Lu  
>> +
>>   PR lto/64837
>>   * lto-plugin.c (release_input_file): New.
>>   (claim_file_handler): Call release_input_file.
>> Index: lto-plugin.c
>> ===
>> --- lto-plugin.c (revision 220212)
>> +++ lto-plugin.c (working copy)
>> @@ -1007,7 +1007,8 @@ claim_file_handler (const struct ld_plug
>>if (obj.objfile)
>>  simple_object_release_read (obj.objfile);
>>
>> -  release_input_file (file);
>> +  if (release_input_file)
>> +release_input_file (file);
>>
>>return LDPS_OK;
>>  }

Re: [PR64817-related 3/3] simplify xor of (and or ior) of xor

[Jakub Jelinek]

On Wed, Feb 04, 2015 at 09:54:53AM +0100, Richard Biener wrote:
> On February 4, 2015 9:35:13 AM CET, Jakub Jelinek  wrote:
> >On Wed, Feb 04, 2015 at 04:21:43AM -0200, Alexandre Oliva wrote:
> >> I'm a bit surprised the gimple layer does not even attempt to
> >simplify
> >> them, but I didn't try to tackle that, since I was not even sure this
> >> was a useful optimization.  After all, how often do we see xor of and
> >of
> >> xor of and of xor of... in the wild, rather than in pathological
> >> testcases? :-)  But hey, at least the rtl simplification is cheap, so
> >> why not?
> >
> >I think we should teach at least VRP to simplify debug stmts similarly
> >how
> >it simplifies normal comparisons etc. using value ranges, but that
> >would be
> >stage1 material.
> 
> So I suppose this is only about debug exprs and we optimize regular gimple
> well?  Otherwise adding some patterns to match.PD could help.

Sure.  For e.g. VRP I meant that simplify_stmt_using_ranges could also
attempt to simplify (some) debug_bind stmts, similarly how it optimizes
normal stmts.

Jakub

Re: [Ada] Fix bootstrapping on darwin9/10 (PR ada/64349)

[Tristan Gingold]

> #elif ! (defined (__vxworks))
> 
> ^^ __vxworks will not be defined by anything other than a vxworks 
> compiler, I'd assume (it is certainly not defined by Darwin toolchains)
> 
>  extern char **environ;
>  return environ;
> 
> vvv so I don't see how this case will ever be exercised.
> #elif defined (__APPLE__) && !defined (__arm__)
>  return *_NSGetEnviron ();
> #else
>  return environ;
> #endif
> }

Ehh, you're right.  They must be swapped.  I missed the '!' in the vxworks 
case, and that wasn't detected by our build.

Tristan.

Re: [RFC testsuite] Fix PR64850, tweak acc_on_device* tests

[Thomas Schwinge]

Hi Kaz!

On Wed, 04 Feb 2015 08:41:28 +0900 (JST), Kaz Kojima  
wrote:
> Several goacc/acc_on_device tests fail for a few targets:
> 
> hppa2.0w-hp-hpux11.11 (PR testsuite/64850)
> https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg02659.html
> 
> m68k-unknown-linux-gnu
> https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg02960.html
> 
> sh4-unknown-linux-gnu
> https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg02930.html
> 
> Also they fail with special options
> x86_64-unknown-linux-gnu -fpic -mcmodel=large
> https://gcc.gnu.org/ml/gcc-testresults/2015-02/msg00198.html

Thanks for looking into this -- incidentally, I also started looking into
it yesterday...  :-)

> Those tests scan .expand rtl dumps to get the number of calls for
> acc_on_device function.  For almost targets, the call rtx looks
> something like
> 
>   (call (mem:QI (symbol_ref:SI ("acc_on_device") [flags 0x41]   0xb7614100 acc_on_device>) [0 acc_on_device S1 A8])
> 
> and tests use the regular expression "\\\(call \[^\\n\]*\\\"acc_on_device"
> to detect it.
> This expression doesn't match with the corresponding call rtx
> 
>   (call (mem:SI (symbol_ref/v:SI ("@acc_on_device") [flags 0x41]  
> ) [0 acc_on_device S4 A32])
> 
> for hppa and something like
> 
>   (call (mem:QI (reg/f:SI 33) [0 acc_on_device S1 A8])
> 
> for m68k and sh.  All call rtxes have the function name in
> the alias set of its mem rtx and it seems that the regular
> expression "\\\(call \[^\\n\]* acc_on_device" works for all
> cases.  The attached patch is tested on i686-pc-linux-gnu and
> sh4-unknown-linux-gnu.

>   PR testsuite/64850
>   * gcc.dg/goacc/acc_on_device-1.c: Use a space instead of \\\" in
>   the expression to find calls.
>   * c-c++-common/goacc/acc_on_device-2.c: Likewise.
>   * c-c++-common/goacc/acc_on_device-2-off.c: Likewise.
>   * gfortran.dg/goacc/acc_on_device-1.f95: Likewise.
>   * gfortran.dg/goacc/acc_on_device-2.f95: Likewise.
>   * gfortran.dg/goacc/acc_on_device-2-off.f95: Likewise.

The other idea that I had is to separately scan/count the symbol_ref and
the call (or call_insn?), but I'm not sure if that is "better".  So, your
patch looks good to me, thanks!

> diff --git a/c-c++-common/goacc/acc_on_device-2-off.c 
> b/c-c++-common/goacc/acc_on_device-2-off.c
> index 25d21ad..ea31047 100644
> --- a/c-c++-common/goacc/acc_on_device-2-off.c
> +++ b/c-c++-common/goacc/acc_on_device-2-off.c
> @@ -20,6 +20,6 @@ f (void)
>  }
>  
>  /* Without -fopenacc, we're expecting one call.
> -   { dg-final { scan-rtl-dump-times "\\\(call \[^\\n\]*\\\"acc_on_device" 1 
> "expand" } } */
> +   { dg-final { scan-rtl-dump-times "\\\(call \[^\\n\]* acc_on_device" 1 
> "expand" } } */
>  
>  /* { dg-final { cleanup-rtl-dump "expand" } } */
> diff --git a/c-c++-common/goacc/acc_on_device-2.c 
> b/c-c++-common/goacc/acc_on_device-2.c
> index d5389a9..2f4ee2b 100644
> --- a/c-c++-common/goacc/acc_on_device-2.c
> +++ b/c-c++-common/goacc/acc_on_device-2.c
> @@ -24,6 +24,6 @@ f (void)
> perturbs expansion as a builtin, which expects an int parameter.  It's 
> fine
> when changing acc_device_t to plain int, but that's not what we're doing 
> in
> .
> -   { dg-final { scan-rtl-dump-times "\\\(call \[^\\n\]*\\\"acc_on_device" 0 
> "expand" { xfail c++ } } } */
> +   { dg-final { scan-rtl-dump-times "\\\(call \[^\\n\]* acc_on_device" 0 
> "expand" { xfail c++ } } } */
>  
>  /* { dg-final { cleanup-rtl-dump "expand" } } */
> diff --git a/gcc.dg/goacc/acc_on_device-1.c b/gcc.dg/goacc/acc_on_device-1.c
> index 1a0276e..d0dbc82 100644
> --- a/gcc.dg/goacc/acc_on_device-1.c
> +++ b/gcc.dg/goacc/acc_on_device-1.c
> @@ -15,6 +15,6 @@ f (void)
>  }
>  
>  /* Unsuitable to be handled as a builtin, so we're expecting four calls.
> -   { dg-final { scan-rtl-dump-times "\\\(call \[^\\n\]*\\\"acc_on_device" 4 
> "expand" } } */
> +   { dg-final { scan-rtl-dump-times "\\\(call \[^\\n\]* acc_on_device" 4 
> "expand" } } */
>  
>  /* { dg-final { cleanup-rtl-dump "expand" } } */
> diff --git a/gfortran.dg/goacc/acc_on_device-1.f95 
> b/gfortran.dg/goacc/acc_on_device-1.f95
> index 9dfde26..0126d9c 100644
> --- a/gfortran.dg/goacc/acc_on_device-1.f95
> +++ b/gfortran.dg/goacc/acc_on_device-1.f95
> @@ -17,6 +17,6 @@ logical function f ()
>  end function f
>  
>  ! Unsuitable to be handled as a builtin, so we're expecting four calls.
> -! { dg-final { scan-rtl-dump-times "\\\(call \[^\\n\]*\\\"acc_on_device" 4 
> "expand" } }
> +! { dg-final { scan-rtl-dump-times "\\\(call \[^\\n\]* acc_on_device" 4 
> "expand" } }
>  
>  ! { dg-final { cleanup-rtl-dump "expand" } }
> diff --git a/gfortran.dg/goacc/acc_on_device-2-off.f95 
> b/gfortran.dg/goacc/acc_on_device-2-off.f95
> index cf28264..0a4978e 100644
> --- a/gfortran.dg/goacc/acc_on_device-2-off.f95
> +++ b/gfortran.dg/goacc/acc_on_device-2-off.f95
> @@ -34,6 +34,6 @@ logical (4) function f ()
>  end function f
>  
>  ! Without -fopenacc, we're expecting one call.
> -! { dg-final { scan-rtl-dump

Re: nvptx-tools and nvptx-newlib (was: The nvptx port [10/11+] Target files)

[Jakub Jelinek]

On Mon, Feb 02, 2015 at 04:32:34PM +0100, Thomas Schwinge wrote:
> Hi!
> 
> On Tue, 23 Dec 2014 19:49:35 +0100, I wrote:
> > On Mon, 10 Nov 2014 17:19:57 +0100, Bernd Schmidt  
> > wrote:
> > > The scripts (11/11) I've put up on github, along with a hacked up 
> > > newlib. These are at [...]
> 
> > > They are likely to migrate to MentorEmbedded from bernds, but that had 
> > > some permissions problems last week.
> > 
> > That has recently been done:
> >  and
> >  are now available.
> > 
> > (I'm aware that we still are to write up how to actually build and test
> > all this.)
> 
> I just updated
> .

Can you please update the gmane URLs to corresponding
https://gcc.gnu.org/ml/gcc-patches/ URLs?  We have our own mailing list
archives, no need to use third party ones.
> 
> OK to check in the following to trunk?

> --- gcc/config/nvptx/nvptx.opt
> +++ gcc/config/nvptx/nvptx.opt
> @@ -17,13 +17,13 @@
>  ; along with GCC; see the file COPYING3.  If not see
>  ; .
>  
> -m64
> -Target Report RejectNegative Mask(ABI64)
> -Generate code for a 64 bit ABI
> -
>  m32
>  Target Report RejectNegative InverseMask(ABI64)
> -Generate code for a 32 bit ABI
> +Generate code for a 32-bit ABI
> +
> +m64
> +Target Report RejectNegative Mask(ABI64)
> +Generate code for a 64-bit ABI

I'd expect you want also Negative(m64) on the m32 option and
Negative(m32) on the m64 option.

> +@table @gcctabopt
> +
> +@item -m32
> +@itemx -m64
> +@opindex m32
> +@opindex m64
> +Generate code for 32-bit or 64-bit ABI.

I guess you should mention which one of those is the default (if it isn't
configure time configurable).

What about multilibs, is newlib built for both -m32 and -m64, or just the
default option?

Jakub

Fix scan-tree-dump for scop-19.c

[Tom de Vries]

Hi,

I've observed a FAILURE for gcc.dg/graphite/scop-19.c with fpic:
...
FAIL: gcc.dg/graphite/scop-19.c scan-tree-dump-times graphite "number of SCoPs: 
0" 2
...

In the nonpic case, d_growable_string_resize is inlined into 
d_growable_string_append_buffer, and we have 2 functions with a loop, wich 
results in two 'number of SCoPs' entries.


In the pic case, d_growable_string_resize is not inlined into 
d_growable_string_append_buffer (since it's not inlinable), and we have only one 
function with a loop, wich results in one 'number of SCoPs' entry.


This patch updates the scan-tree-dump to match the pic/nonpic behaviour.

OK for trunk?

Thanks,
- Tom
2015-02-04  Tom de Vries  

	* gcc.dg/graphite/scop-19.c: Fix scan-tree-dump for fpic.

diff --git a/gcc/testsuite/gcc.dg/graphite/scop-19.c b/gcc/testsuite/gcc.dg/graphite/scop-19.c
index 9dfc865..ab23bb4 100644
--- a/gcc/testsuite/gcc.dg/graphite/scop-19.c
+++ b/gcc/testsuite/gcc.dg/graphite/scop-19.c
@@ -31,6 +31,7 @@ d_growable_string_append_buffer (struct d_growable_string *dgs,
   if (need > dgs->alc)
 d_growable_string_resize (dgs, need);
 }
-/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite"} } */ 
+/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 2 "graphite" { target nonpic } } } */
+/* { dg-final { scan-tree-dump-times "number of SCoPs: 0" 1 "graphite" { target { ! nonpic } } } } */
 /* { dg-final { cleanup-tree-dump "graphite" } } */
 
-- 
1.9.1

Re: [PR64817-related 3/3] simplify xor of (and or ior) of xor

[Richard Biener]

On February 4, 2015 10:15:30 AM CET, Jakub Jelinek  wrote:
>On Wed, Feb 04, 2015 at 09:54:53AM +0100, Richard Biener wrote:
>> On February 4, 2015 9:35:13 AM CET, Jakub Jelinek 
>wrote:
>> >On Wed, Feb 04, 2015 at 04:21:43AM -0200, Alexandre Oliva wrote:
>> >> I'm a bit surprised the gimple layer does not even attempt to
>> >simplify
>> >> them, but I didn't try to tackle that, since I was not even sure
>this
>> >> was a useful optimization.  After all, how often do we see xor of
>and
>> >of
>> >> xor of and of xor of... in the wild, rather than in pathological
>> >> testcases? :-)  But hey, at least the rtl simplification is cheap,
>so
>> >> why not?
>> >
>> >I think we should teach at least VRP to simplify debug stmts
>similarly
>> >how
>> >it simplifies normal comparisons etc. using value ranges, but that
>> >would be
>> >stage1 material.
>> 
>> So I suppose this is only about debug exprs and we optimize regular
>gimple
>> well?  Otherwise adding some patterns to match.PD could help.
>
>Sure.  For e.g. VRP I meant that simplify_stmt_using_ranges could also
>attempt to simplify (some) debug_bind stmts, similarly how it optimizes
>normal stmts.

Sure.  Of course it's bad that debug stmts use Generic...  General fold-stmt 
could do some of the work.  Also that debug temps have no use-def chains 
doesn't help too much.

Richard.

>   Jakub

Re: [PR64817-related 3/3] simplify xor of (and or ior) of xor

[Jakub Jelinek]

On Wed, Feb 04, 2015 at 10:54:54AM +0100, Richard Biener wrote:
> Sure.  Of course it's bad that debug stmts use Generic...  General
> fold-stmt could do some of the work.  Also that debug temps have no
> use-def chains doesn't help too much.

Well, at least right now I believe debug temps work more like non-SSA
variables rather than SSA_NAMEs, the same debug temp can be bound to
different values at different points.  At least e.g. loop unrolling
certainly doesn't create new debug temps, but leaves the same debug temp
bound multiple times.  Dunno if that is intent or just a bug.

Jakub

[Patch ARM] Improve guality tests - part 1 - pr36728-1.c

[Ramana Radhakrishnan]

Hi,

	I decided to spend some time looking at the large number of guality 
test failures on arm. I see a number of fails with 
gcc.dg/guality/pr36728-1.c as below. pr36728-2.c also fails in similar 
sort of ways. Before I go adjusting too many other tests I'd like to get 
some feedback regarding this from folks.


	On ARM parameters are passed in r0 - r3 which maps to arg1 - arg4. The 
code generated appears to use r0 for the return value and as a 
temporary. r2 and r3 are used as temporaries to adjust the stack as 
those are the first temporaries used in the register allocaton order. 
Therefore it is understandeable that arg1, arg3 and arg4 end up being 
"optimized" out and there is no chance of reclaiming the information at 
line #16 or line #18 in the testcase linked. r1 gets used at O2 and 
therefore that starts failing at O2 and above.


	Depending on optimization levels, registers used for arg1 - arg4 get 
reused at various optimization levels therefore we have no choice but to 
disable this lot.


	Once you do that the only failures left are with the variable 'y' at 
optimization levels O2 and O3 which I'm going to leave as is until the 
time as I understand what's going on here. My initial thought is that 
this also appears to be a testism, but I'm not a 100% sure yet.


I pondered adding a testsuite keyword for this but it appears to be so 
special cased per target, that I don't see any easy way of handling this 
as each target appears to be special in the way in which it handles this 
- fundamentally would end up depending on the number of registers used 
as parameter registers and being caller saved registers and that varies 
from port to port.



FAIL: gcc.dg/guality/pr36728-1.c   -O1  line 16 arg3 == 3
FAIL: gcc.dg/guality/pr36728-1.c   -O1  line 16 arg4 == 4
FAIL: gcc.dg/guality/pr36728-1.c   -O1  line 18 arg1 == 1
FAIL: gcc.dg/guality/pr36728-1.c   -O1  line 18 arg3 == 3
FAIL: gcc.dg/guality/pr36728-1.c   -O1  line 18 arg4 == 4
FAIL: gcc.dg/guality/pr36728-1.c   -O2  line 18 arg2 == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O2  line 18 arg3 == 3
FAIL: gcc.dg/guality/pr36728-1.c   -O2  line 18 arg4 == 4
FAIL: gcc.dg/guality/pr36728-1.c   -O2  line 18 y == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  line 18 arg2 == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  line 18 arg3 == 3
FAIL: gcc.dg/guality/pr36728-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  line 18 arg4 == 4
FAIL: gcc.dg/guality/pr36728-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  line 18 y == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  line 18 arg1 == 1
FAIL: gcc.dg/guality/pr36728-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  line 18 arg2 == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  line 18 arg3 == 3
FAIL: gcc.dg/guality/pr36728-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  line 18 arg4 == 4
FAIL: gcc.dg/guality/pr36728-1.c   -O3 -fomit-frame-pointer  line 18 
arg2 == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O3 -fomit-frame-pointer  line 18 
arg3 == 3
FAIL: gcc.dg/guality/pr36728-1.c   -O3 -fomit-frame-pointer  line 18 
arg4 == 4

FAIL: gcc.dg/guality/pr36728-1.c   -O3 -fomit-frame-pointer  line 18 y == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O3 -g  line 18 arg2 == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O3 -g  line 18 arg3 == 3
FAIL: gcc.dg/guality/pr36728-1.c   -O3 -g  line 18 arg4 == 4
FAIL: gcc.dg/guality/pr36728-1.c   -O3 -g  line 18 y == 2

to

FAIL: gcc.dg/guality/pr36728-1.c   -O2  line 16 y == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O2  line 18 y == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O3 -fomit-frame-pointer  line 16 y == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O3 -fomit-frame-pointer  line 18 y == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O3 -g  line 16 y == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O3 -g  line 18 y == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  line 16 y == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O2 -flto -fno-use-linker-plugin 
-flto-partition=none  line 18 y == 2
FAIL: gcc.dg/guality/pr36728-1.c   -O2 -flto -fuse-linker-plugin 
-fno-fat-lto-objects  line 16 y == 2



Changelog:

* gcc.dg/guality/pr36728-1.c: Skip some tests for arm.

Ok ? Thoughts ?

regards,
Ramana


P.S. I got caught out by the yama security module in the kernel 
preventing me from running some of the guality tests on the chromebook I 
was running this on. 
https://www.kernel.org/doc/Documentation/security/Yama.txt. JFTR it may 
be a good idea to do


 echo 0 > /proc/sys/kernel/yama/ptrace_scope


to get these things to work. Also I was using a trunk gdb to get these 
results.



diff --git a/gcc/testsuite/gcc.dg/guality/pr36728-1.c 
b/gcc/testsuite/gcc.dg/guality/pr36728-1.c
index ba7a6c2..6e6ba3f 100644
--- a/gcc/testsuite/gcc.dg/guality/pr36728-1.c
+++ b/gcc/

Re: r219977 - in /trunk/gcc: ChangeLog config/rs600...

[Segher Boessenkool]

On Wed, Feb 04, 2015 at 09:00:57AM +0100, Jakub Jelinek wrote:
> On Tue, Feb 03, 2015 at 10:23:22PM -0500, David Edelsohn wrote:
> > On Tue, Feb 3, 2015 at 5:55 PM, Andreas Schwab  
> > wrote:
> > > FAIL: gcc.dg/builtins-58.c scan-assembler-not pow
> > >
> > > $ grep pow builtins-58.s
> > > .machine power4
> > 
> > Any suggestions?
> 
> Perhaps tighten up the regexp, like (untested)?
> /* { dg-final { scan-assembler-not "pow\[^a-zA-Z0-9\]" } } */

That won't work if the file ends with that "pow".  We can just use \M.
I'll send a patch (also for pr46728-6.c).


Segher

[PATCH] testsuite: Check for pow at the end of words only

[Segher Boessenkool]

These two testcases stopped working on rs6000, since we now emit
".machine power4" and similar pseudo-ops.  This fixes it by testing
for "pow" at the end of words only.

Regression checking in progress on powerpc64-linux (where it failed
before); okay if it passes?


Segher


2015-02-04  Segher Boessenkool  

gcc/testsuite/
* gcc.dg/builtins-58.c: Check for pow at the end of words only.
* gcc.dg/pr46728-6.c: Ditto.

---
 gcc/testsuite/gcc.dg/builtins-58.c | 2 +-
 gcc/testsuite/gcc.dg/pr46728-6.c   | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/builtins-58.c 
b/gcc/testsuite/gcc.dg/builtins-58.c
index 4c2f351..262f162 100644
--- a/gcc/testsuite/gcc.dg/builtins-58.c
+++ b/gcc/testsuite/gcc.dg/builtins-58.c
@@ -30,4 +30,4 @@ double test4 (double x)
 }
 #endif
 
-/* { dg-final { scan-assembler-not "pow" } } */
+/* { dg-final { scan-assembler-not {pow\M} } } */
diff --git a/gcc/testsuite/gcc.dg/pr46728-6.c b/gcc/testsuite/gcc.dg/pr46728-6.c
index bcdaf90..b566391 100644
--- a/gcc/testsuite/gcc.dg/pr46728-6.c
+++ b/gcc/testsuite/gcc.dg/pr46728-6.c
@@ -18,4 +18,4 @@ main (int argc, char *argv[])
 }
 
 
-/* { dg-final { scan-assembler-not "pow" } } */
+/* { dg-final { scan-assembler-not {pow\M} } } */
-- 
1.8.1.4

Re: [C++ PATCH] PR c++/64901

[Paolo Carlini]

Hi,

On 02/02/2015 11:26 PM, Ville Voutilainen wrote:

On 2 February 2015 at 20:50, Ville Voutilainen
 wrote:

The modified test has been tested, I'm currently running the full testsuite,
so testing is incomplete. I wanted to send this in asap, since this is a
bad regression.

/cp
2015-02-02  Ville Voutilainen  

 PR c++/64901
 * decl.c (duplicate_decls): Also duplicate DECL_FINAL_P and 
DECL_OVERRIDE_P.

/testsuite
2015-02-02  Ville Voutilainen  

 PR c++/64901
 * g++.dg/cpp0x/override1.C: Add a test for the PR.

For what it's worth, the complete testsuite passes without
regressions, tested on Linux-x64.
I see that Jason applied the fix to mainline. Today I noticed that this 
is also a regression in the 4_9-branch: shall I regression test the fix 
there too, in case apply and close the bug?


Thanks!
Paolo.

Re: [PATCH] testsuite: Check for pow at the end of words only

[Jakub Jelinek]

On Wed, Feb 04, 2015 at 02:14:53AM -0800, Segher Boessenkool wrote:
> These two testcases stopped working on rs6000, since we now emit
> ".machine power4" and similar pseudo-ops.  This fixes it by testing
> for "pow" at the end of words only.
> 
> Regression checking in progress on powerpc64-linux (where it failed
> before); okay if it passes?
> 
> 
> Segher
> 
> 
> 2015-02-04  Segher Boessenkool  
> 
> gcc/testsuite/
>   * gcc.dg/builtins-58.c: Check for pow at the end of words only.
>   * gcc.dg/pr46728-6.c: Ditto.

Ok, thanks.

Jakub

Re: [libobjc] Fix failures on AIX (PR libobjc/63765)

[Rainer Orth]

Rainer Orth  writes:

> Hi Alexandre,
>
>> On Jan 28, 2015, Mike Stump  wrote:
>>
>>> On Jan 28, 2015, at 2:27 AM, Rainer Orth  
>>> wrote:
 There are two ways to fix this:
 
 * Remove the definition of _XOPEN_SOURCE completely.  This is slightly
 more risky, but more future-proof since defining features test macros
 has been an endless source of trouble in the past.
>>
>>> I think I prefer this one...
>>
>>> But, as I say that, I read:
>>
>>>   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4372
>>
>>> and there is no hint what host caused him to put the change in, in the
>>> first place.  :-( Alexandre, do you recall what host needed the
>>> _XOPEN_SOURCE in libobjc for pthread_mutexattr_settype?
>>
>> The 2005 timeframe suggests it was probably GNU/Linux, and some digging
>> in glibc indicates this flag affected nptl's pthread.h's declarations of
>> various such functions back then.  This changed back in 2010, with glibc
>> commit d3c7e68655, in response to newer standards, so I guess this
>> confirms the suggestion from the timeframe.  Of course, this being a
>> standard-compliance issue, other targets were likely affected as well,
>> since it looks like there was a standards change, and removing the flag
>> might cause regressions in old systems that remain stuck to the old
>> standards.
>
> Thanks for digging this up.  I doubt that anyone using a 2005 vintage
> glibc is really using current GCC trunk, though ;-)
>
> I recall that either or both of IRIX and Tru64 UNIX have been affected
> by _XOPEN_SOURCE definitions in the past.  Both of them were last
> supported in GCC 4.7, so are now ancient history.
>
> I'm with Mike here: either we remove the _XOPEN_SOURCE definition now
> and, in case of breakage, add them back exactly for those targets that
> need it, documenting where and why it is necessary.  Otherwise, we will
> never get rid of this cruft and break more modern systems on the way.

It's been a week now since I posted the patches and there's still no
conclusion which of the two alternatives to install.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

[PATCH][AArch64] Add support for -mcpu=cortex-a72

[Matthew Wahab]

Hello,

The Cortex-A72 is an ARMv8 core with the same architectural features as 
the Cortex-A57. This patch adds support for the command line option 
-mcpu=cortex-a72 with the same effect as the -mcpu=cortex-a57 option, 
only the name being different. It also adds support for the 
-mcpu=cortex-a72.cortex-a53 big-little variant.


Tested with check-gcc on aarch64-none-linux-gnu with no new failures. 
Tested the new cpu options from the command line.


Matthew

gcc/
2015-02-04  Matthew Wahab  

* config/aarch64/aarch64-cores.def: Add cortex-a72 and
cortex-a72.cortex-a53.
* config/aarch64/aarch64-tune.md: Regenerate.
* doc/invoke.texi (AArch64 Options/-mtune): Add "cortex-a72".
diff --git a/gcc/config/aarch64/aarch64-cores.def b/gcc/config/aarch64/aarch64-cores.def
index f978eb1..9b2eca2 100644
--- a/gcc/config/aarch64/aarch64-cores.def
+++ b/gcc/config/aarch64/aarch64-cores.def
@@ -36,9 +36,11 @@
 
 AARCH64_CORE("cortex-a53",  cortexa53, cortexa53, 8,  AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC, cortexa53)
 AARCH64_CORE("cortex-a57",  cortexa57, cortexa57, 8,  AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC, cortexa57)
+AARCH64_CORE("cortex-a72",  cortexa72, cortexa57, 8,  AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC, cortexa57)
 AARCH64_CORE("thunderx",thunderx,  thunderx, 8,  AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC | AARCH64_FL_CRYPTO, thunderx)
 AARCH64_CORE("xgene1",  xgene1,xgene1,8,  AARCH64_FL_FOR_ARCH8, xgene1)
 
 /* V8 big.LITTLE implementations.  */
 
 AARCH64_CORE("cortex-a57.cortex-a53",  cortexa57cortexa53, cortexa53, 8,  AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC, cortexa57)
+AARCH64_CORE("cortex-a72.cortex-a53",  cortexa72cortexa53, cortexa53, 8,  AARCH64_FL_FOR_ARCH8 | AARCH64_FL_CRC, cortexa57)
diff --git a/gcc/config/aarch64/aarch64-tune.md b/gcc/config/aarch64/aarch64-tune.md
index 80f59c8..c3305f9 100644
--- a/gcc/config/aarch64/aarch64-tune.md
+++ b/gcc/config/aarch64/aarch64-tune.md
@@ -1,5 +1,5 @@
 ;; -*- buffer-read-only: t -*-
 ;; Generated automatically by gentune.sh from aarch64-cores.def
 (define_attr "tune"
-	"cortexa53,cortexa57,thunderx,xgene1,cortexa57cortexa53"
+	"cortexa53,cortexa57,cortexa72,thunderx,xgene1,cortexa57cortexa53,cortexa72cortexa53"
 	(const (symbol_ref "((enum attr_tune) aarch64_tune)")))
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2d3c4f7..2d73006 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -12102,12 +12102,12 @@ architecture.
 @opindex mtune
 Specify the name of the target processor for which GCC should tune the
 performance of the code.  Permissible values for this option are:
-@samp{generic}, @samp{cortex-a53}, @samp{cortex-a57}, @samp{thunderx},
-@samp{xgene1}.
+@samp{generic}, @samp{cortex-a53}, @samp{cortex-a57},
+@samp{cortex-a72}, @samp{thunderx}, @samp{xgene1}.
 
 Additionally, this option can specify that GCC should tune the performance
-of the code for a big.LITTLE system.  The only permissible value is
-@samp{cortex-a57.cortex-a53}.
+of the code for a big.LITTLE system.  Permissible values for this
+option are: @samp{cortex-a57.cortex-a53}, @samp{cortex-a72.cortex-a53}.
 
 Where none of @option{-mtune=}, @option{-mcpu=} or @option{-march=}
 are specified, the code is tuned to perform well across a range

Re: [PATCH, ivopt] Try aligned offset when get_address_cost

[Eric Botcazou]

> For some TARGET, like ARM THUMB1, the offset in load/store should be nature
> aligned. But in function get_address_cost, when computing max_offset, it
> only tries byte-aligned offsets:
> 
>   ((unsigned HOST_WIDE_INT) 1 << i) - 1
> 
> which can not meet thumb_legitimate_offset_p check called from
> thumb1_legitimate_address_p for HImode and SImode.
> 
> The patch adds additional try for aligned offset:
> 
>   ((unsigned HOST_WIDE_INT) 1 << i) - GET_MODE_SIZE (address_mode).

I think that the change is not fully correct, this must be mem_mode instead of 
address_mode since the alignment of the MEM is given by mem_mode:

Index: tree-ssa-loop-ivopts.c
===
--- tree-ssa-loop-ivopts.c  (revision 220343)
+++ tree-ssa-loop-ivopts.c  (working copy)
@@ -3324,12 +3324,12 @@ get_address_cost (bool symbol_present, b
  XEXP (addr, 1) = gen_int_mode (off, address_mode);
  if (memory_address_addr_space_p (mem_mode, addr, as))
break;
- /* For some TARGET, like ARM THUMB1, the offset should be nature
-aligned. Try an aligned offset if address_mode is not QImode.  */
- off = (address_mode == QImode)
+ /* For some strict-alignment targets, the offset must be naturally
+aligned.  Try an aligned offset if mem_mode is not QImode.  */
+ off = mem_mode == QImode
? 0
: ((unsigned HOST_WIDE_INT) 1 << i)
-   - GET_MODE_SIZE (address_mode);
+   - GET_MODE_SIZE (mem_mode);
  if (off > 0)
{
  XEXP (addr, 1) = gen_int_mode (off, address_mode);


This fixes unexpected differences in the result of the function between SPARC 
and SPARC64 for the same source code.  OK for mainline after testing?


* tree-ssa-loop-ivopts.c (get_address_cost): Use proper mode for offset.


-- 
Eric Botcazou

[PATCH][ARM] Add support for -mcpu=cortex-a72

[Matthew Wahab]

Hello,

The Cortex-A72 is an ARMv8 core with the same architectural features as 
the Cortex-A57. This patch adds support for the command line option 
-mcpu=cortex-a72 with the same effect as the -mcpu=cortex-a57 option, 
with only the name being different. It also adds support for the 
-mcpu=cortex-a72.cortex-a53 big-little variant.


Tested with check-gcc for arm-none-linux-gnueabihf. Tested the new cpu 
options from the command line.


Matthew

gcc/
2015-02-04  Matthew Wahab  

* config/arm/arm-cores.def: Add cortex-a72 and
cortex-a72.cortex-a53.
* config/arm/bpabi.h (BE8_LINK_SPEC): Likewise.
* config/arm/t-aprofile (MULTILIB_MATCHES): Likewise.
* config/arm/arm-tune.md: Regenerate.
* config/arm/arm-tables.opt: Add entries for "cortex-a72" and
"cortex-a72.cortex-a53".
* doc/invoke.texi (ARM Options/-mtune): Likewise.
diff --git a/gcc/config/arm/arm-cores.def b/gcc/config/arm/arm-cores.def
index f24fefd..d7e730d 100644
--- a/gcc/config/arm/arm-cores.def
+++ b/gcc/config/arm/arm-cores.def
@@ -167,7 +167,9 @@ ARM_CORE("cortex-a17.cortex-a7", cortexa17cortexa7, cortexa7,	7A,  FL_LDSCHED |
 /* V8 Architecture Processors */
 ARM_CORE("cortex-a53",	cortexa53, cortexa53,	8A, FL_LDSCHED | FL_CRC32, cortex_a53)
 ARM_CORE("cortex-a57",	cortexa57, cortexa57,	8A, FL_LDSCHED | FL_CRC32, cortex_a57)
+ARM_CORE("cortex-a72",	cortexa72, cortexa57,	8A, FL_LDSCHED | FL_CRC32, cortex_a57)
 ARM_CORE("xgene1",  xgene1,xgene1,  8A, FL_LDSCHED,xgene1)
 
 /* V8 big.LITTLE implementations */
 ARM_CORE("cortex-a57.cortex-a53", cortexa57cortexa53, cortexa53, 8A,  FL_LDSCHED | FL_CRC32, cortex_a57)
+ARM_CORE("cortex-a72.cortex-a53", cortexa72cortexa53, cortexa53, 8A,  FL_LDSCHED | FL_CRC32, cortex_a57)
diff --git a/gcc/config/arm/arm-tables.opt b/gcc/config/arm/arm-tables.opt
index 1392429..3450e5b 100644
--- a/gcc/config/arm/arm-tables.opt
+++ b/gcc/config/arm/arm-tables.opt
@@ -310,11 +310,17 @@ EnumValue
 Enum(processor_type) String(cortex-a57) Value(cortexa57)
 
 EnumValue
+Enum(processor_type) String(cortex-a72) Value(cortexa72)
+
+EnumValue
 Enum(processor_type) String(xgene1) Value(xgene1)
 
 EnumValue
 Enum(processor_type) String(cortex-a57.cortex-a53) Value(cortexa57cortexa53)
 
+EnumValue
+Enum(processor_type) String(cortex-a72.cortex-a53) Value(cortexa72cortexa53)
+
 Enum
 Name(arm_arch) Type(int)
 Known ARM architectures (for use with the -march= option):
diff --git a/gcc/config/arm/arm-tune.md b/gcc/config/arm/arm-tune.md
index dcd5054..d459f27 100644
--- a/gcc/config/arm/arm-tune.md
+++ b/gcc/config/arm/arm-tune.md
@@ -32,6 +32,6 @@
 	cortexr4f,cortexr5,cortexr7,
 	cortexm7,cortexm4,cortexm3,
 	marvell_pj4,cortexa15cortexa7,cortexa17cortexa7,
-	cortexa53,cortexa57,xgene1,
-	cortexa57cortexa53"
+	cortexa53,cortexa57,cortexa72,
+	xgene1,cortexa57cortexa53,cortexa72cortexa53"
 	(const (symbol_ref "((enum attr_tune) arm_tune)")))
diff --git a/gcc/config/arm/bpabi.h b/gcc/config/arm/bpabi.h
index 8e16434..c62130d 100644
--- a/gcc/config/arm/bpabi.h
+++ b/gcc/config/arm/bpabi.h
@@ -71,6 +71,8 @@
|mcpu=cortex-a53	\
|mcpu=cortex-a57	\
|mcpu=cortex-a57.cortex-a53\
+   |mcpu=cortex-a72	\
+   |mcpu=cortex-a72.cortex-a53\
|mcpu=xgene1 \
|mcpu=cortex-m1.small-multiply   \
|mcpu=cortex-m0.small-multiply   \
@@ -93,6 +95,8 @@
|mcpu=cortex-a53	\
|mcpu=cortex-a57	\
|mcpu=cortex-a57.cortex-a53\
+   |mcpu=cortex-a72	\
+   |mcpu=cortex-a72.cortex-a53\
|mcpu=xgene1 \
|mcpu=cortex-m1.small-multiply   \
|mcpu=cortex-m0.small-multiply   \
diff --git a/gcc/config/arm/t-aprofile b/gcc/config/arm/t-aprofile
index 6a280bd..e8b2aa3 100644
--- a/gcc/config/arm/t-aprofile
+++ b/gcc/config/arm/t-aprofile
@@ -89,6 +89,8 @@ MULTILIB_MATCHES   += march?armv7ve=mcpu?cortex-a17.cortex-a7
 MULTILIB_MATCHES   += march?armv8-a=mcpu?cortex-a53
 MULTILIB_MATCHES   += march?armv8-a=mcpu?cortex-a57
 MULTILIB_MATCHES   += march?armv8-a=mcpu?cortex-a57.cortex-a53
+MULTILIB_MATCHES   += march?armv8-a=mcpu?cortex-a72
+MULTILIB_MATCHES   += march?armv8-a=mcpu?cortex-a72.cortex-a53
 
 # Arch Matches
 MULTILIB_MATCHES   += march?armv8-a=march?armv8-a+crc
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 2d3c4f7..55586a7 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -12966,7 +12966,8 @@ Permissible names are: @samp{arm2}, @samp{arm250},
 @samp{arm1136j-s}, @samp{arm1136jf-s}, @samp{mpcore}, @samp{mpcorenovfp},
 @samp{arm1156t2-s}, @samp{arm1156t2f-s}, @samp{arm1176jz-s}, @samp{arm1176jzf-s},
 @samp{cortex-a5}, @samp{cortex-a7}, @samp{cortex-a8}, @samp{cortex-a9},
-@samp{cortex-a12}, @samp{cortex-a15}, @samp{cortex-a53}, @samp{cortex-a57},
+@samp{cortex-a12}, @samp{cortex-a15}, @samp{co

Re: Another ptx offloading patch

[Jakub Jelinek]

On Fri, Jan 16, 2015 at 11:45:40AM +0100, Richard Biener wrote:
> On Thu, Jan 15, 2015 at 7:35 PM, Jeff Law  wrote:
> > On 11/20/14 05:33, Bernd Schmidt wrote:
> >>
> >> Now that I've managed to put together and test all the submitted OpenACC
> >> patches I found there was one piece missing. The problem is that omp-low
> >> on the host likes to generate function names like "_main._omp_fn". On
> >> ptx, the dot is not allowed in identifiers, so we have to rewrite this
> >> to use a dollar sign.
> >>
> >> The patch below does this at the lto-read stage. Bootstrapped on
> >> x86_64-linux, ok if testing is successful?
> >
> > Was expecting Richi or Honza to review this...  They certainly know the LTO
> > bits far better than I.  Or have you ultimately addressed this issue some
> > other way?
> 
> I don't like the validize_symbol_for_target thing - you create proper
> symbols elsewhere from the start - what's left to fix?  IMHO we should
> have a single helper somewhere for concatenating with some separator.

The problem is that the host compiler does not and cannot know what
characters are valid or invalid on the offloading target (and, especially if
you have multiple of them, as we do now, where some of the .$_ characters
are valid and others are not).
The only universally available character is _ I assume, but that one has the
problem that users can type that in their code and clash with the internal
symbols.  And, if we do not want to use _ from the beginning, what do you
suggest otherwise?  Also note that normally the same functions are emitted
for both host and offloading target, you don't have different symbol names
for host and different for what you want to stream to the offloading LTO
sections.

So I think something like Bernd's patch is the way to go.  Another
alternative is to pick up some completely different character not valid
in any identifiers, and do two transformations of the names.  When streaming
offloading LTO from the host compiler, mangle the $ and . characters in
names to some other character, say %, and then when streaming the offloading
LTO into the offloading compiler, remap the % (or whatever) character to
the best internal symbol character there - ., $ or _ (in that order?).
But Bernd's patch looks simpler than that.

Jakub

Re: [C++ PATCH] PR c++/64901

[Ville Voutilainen]

On 4 February 2015 at 12:22, Paolo Carlini  wrote:
> I see that Jason applied the fix to mainline. Today I noticed that this is
> also a regression in the 4_9-branch: shall I regression test the fix there
> too, in case apply and close the bug?

Please do, thanks.

Re: nvptx offloading patches [2/n]

[Jakub Jelinek]

On Sat, Nov 01, 2014 at 12:51:32PM +0100, Bernd Schmidt wrote:
> LTO has a mechanism not to stream out common nodes that are expected to be
> identical on each run. When using LTO to communicate between compilers for
> different targets, the va_list_type_node and related ones must be excluded
> from this.
> 
> Richard B mentioned in a recent mail that the i386 backend uses direct
> comparisons to va_list_type_node. After investigating a bit it seems to me
> that this is not actually a problem: what's being compared is the return
> value of ix86_canonical_va_list_type, which always chooses one of
> va_list_type_node or its ABI variants, so the comparison should hold even
> with this patch.
> 
> Bootstrapped and tested on x86_64-linux, ok?

How can the offloading of functions using va_start/va_end/va_arg work,
until we apply (in GCC 6?) Michael's patches and extend them - make
all those 3 internal functions lowered only after IPA?

I mean, nvptx supposedly contains different va_list type (from quick glance
it uses void *, while e.g. x86_64 uses a struct [1]), and we gimplify it
early, so for GCC 5 the only option is IMHO to refuse to compile (sorry?)
when streaming functions that use the host va_list type.

For GCC 6, presumably if it is lowered late, if the host va_list would be
at least as big as target va_list, we could stick stuff in there, or rewrite
to the target va_list.  Still, if e.g. va_list is embedded in structures, or
used in global vars, we'd need to pad the structures or something.

Jakub

Re: nvptx offloading patches [2/n]

[Jakub Jelinek]

On Wed, Feb 04, 2015 at 11:55:54AM +0100, Jakub Jelinek wrote:
> On Sat, Nov 01, 2014 at 12:51:32PM +0100, Bernd Schmidt wrote:
> > LTO has a mechanism not to stream out common nodes that are expected to be
> > identical on each run. When using LTO to communicate between compilers for
> > different targets, the va_list_type_node and related ones must be excluded
> > from this.
> > 
> > Richard B mentioned in a recent mail that the i386 backend uses direct
> > comparisons to va_list_type_node. After investigating a bit it seems to me
> > that this is not actually a problem: what's being compared is the return
> > value of ix86_canonical_va_list_type, which always chooses one of
> > va_list_type_node or its ABI variants, so the comparison should hold even
> > with this patch.
> > 
> > Bootstrapped and tested on x86_64-linux, ok?
> 
> How can the offloading of functions using va_start/va_end/va_arg work,
> until we apply (in GCC 6?) Michael's patches and extend them - make
> all those 3 internal functions lowered only after IPA?
> 
> I mean, nvptx supposedly contains different va_list type (from quick glance
> it uses void *, while e.g. x86_64 uses a struct [1]), and we gimplify it
> early, so for GCC 5 the only option is IMHO to refuse to compile (sorry?)
> when streaming functions that use the host va_list type.
> 
> For GCC 6, presumably if it is lowered late, if the host va_list would be
> at least as big as target va_list, we could stick stuff in there, or rewrite
> to the target va_list.  Still, if e.g. va_list is embedded in structures, or
> used in global vars, we'd need to pad the structures or something.

That said, if your patch doesn't break normal LTO, I agree it doesn't make
much sense to 
> 
>   Jakub

Jakub

Re: [Patch ARM] Improve guality tests - part 1 - pr36728-1.c

[Ramana Radhakrishnan]

>
> Changelog:
>
> * gcc.dg/guality/pr36728-1.c: Skip some tests for arm.
>

Segher and I discussed an alternative approach - marking these as "m"
(arg1) , "m" (arg2)  etc in the asm blocks also gives us the same
effect and then probably removes the need to rely on such target
markers.  I've just noticed that the AArch64 port has the same issues.

I'll spin something up along those lines, maybe that is more acceptable

Ramana

Re: [PATCH] PR64387

[Ilya Tocar]

I think that fix for avx2 part should be backported to 4.8/4.9
What do you think?

On 14 Jan 14:18, Ilya Tocar wrote:
> Hi,
> 
> This patch fixes https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64387
> Which was caused by different in predicates between vec_unpacks_hi
> and vec_extract_hi.
> Ok for trunk?
> ChangeLog:
> 
> gcc/
>   PR target/64387
>   * config/i386/sse.md (vec_unpacks_hi_v8sf): Fix predicate.
>   (vec_unpacks_hi_v16sf): Ditto.
> 
> testsuite/
>   PR target/64387
>   * gcc.target/i386/pr64387.c: New test.
> ---
>  gcc/config/i386/sse.md  |  4 ++--
>  gcc/testsuite/gcc.target/i386/pr64387.c | 15 +++
>  2 files changed, 17 insertions(+), 2 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr64387.c
> 
> diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
> index 3b9108c..cd4af4e 100644
> --- a/gcc/config/i386/sse.md
> +++ b/gcc/config/i386/sse.md
> @@ -5078,7 +5078,7 @@
>  (define_expand "vec_unpacks_hi_v8sf"
>[(set (match_dup 2)
>   (vec_select:V4SF
> -   (match_operand:V8SF 1 "nonimmediate_operand")
> +   (match_operand:V8SF 1 "register_operand")
> (parallel [(const_int 4) (const_int 5)
>(const_int 6) (const_int 7)])))
> (set (match_operand:V4DF 0 "register_operand")
> @@ -5090,7 +5090,7 @@
>  (define_expand "vec_unpacks_hi_v16sf"
>[(set (match_dup 2)
>   (vec_select:V8SF
> -   (match_operand:V16SF 1 "nonimmediate_operand")
> +   (match_operand:V16SF 1 "register_operand")
> (parallel [(const_int 8) (const_int 9)
>(const_int 10) (const_int 11)
>(const_int 12) (const_int 13)
> diff --git a/gcc/testsuite/gcc.target/i386/pr64387.c 
> b/gcc/testsuite/gcc.target/i386/pr64387.c
> new file mode 100644
> index 000..dd38142
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr64387.c
> @@ -0,0 +1,15 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -ftree-vectorize -ffloat-store -mavx512er" } */
> +
> +float x[256];
> +
> +double *
> +foo (void)
> +{
> +  double *z = __builtin_malloc (sizeof (double) * 256);
> +  int i;
> +  for (i = 0; i < 256; ++i)
> +z[i] = x[i] + 1.0f;
> +  foo ();
> +  return 0;
> +}
> -- 
> 1.8.3.1
> 

Re: [PATCH][AArch64] Use target builtin instead of __builtin_sqrt for vsqrt_f64

[Kyrill Tkachov]

Ping.

https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00710.html


Thanks,
Kyrill

On 27/01/15 09:45, Kyrill Tkachov wrote:

On 19/01/15 15:46, Kyrill Tkachov wrote:

On 19/01/15 15:44, James Greenhalgh wrote:

On Mon, Jan 12, 2015 at 05:30:46PM +, Andrew Pinski wrote:

On Mon, Jan 12, 2015 at 7:52 AM, Kyrill Tkachov  wrote:

Hi all,

As raised in https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01237.html and
discussed in that thread, using __builtin_sqrt for vsqrt_f64 may end up in a
call to the library sqrt at -O0. To avoid that this patch uses a target
builtin for sqrt on DF mode and uses that to implement the intrinsic.

With this patch I don't see sqrt calls being created at -O0 on a large
arm_neon.h testcase where they were generated before.
aarch64-none-elf testing and the intrinsics testsuite in particular are
clean.
Ok for trunk?

Maybe have a target fold which folds this into sqrt if -fno-math-errno
is supplied.  This might be useful the -ffast-math case.
Maybe also fold it when a constant is supplied too.

Given that we are now in Stage 4, I'd rather see this fixed for GCC 5.0
in the way Kyrill proposed than languishing on a TODO list. Though an
IOU ticket on bugzilla for the missed optimization seems a good idea
to me.

Unless Kyrill already has something in the works to address your
comment, this looks like the right short-term solution to me
(Though Marcus/Richard will have to approve it).

Sorry, this slipped through the cracks.
I agree with James. A missed-optimization issue on bugzilla would be
helpful to keep track of this.

I've filed PR 64821 to keep track of this for GCC 6.
Can I ping https://gcc.gnu.org/ml/gcc-patches/2015-01/msg00710.html then?
It's a regression fix at -O0 so should be appropriate for stage4

Thanks,
Kyrill


Kyrill


Thanks,
James


2015-01-12  Kyrylo Tkachov  

   * config/aarch64/aarch64-simd-builtins.def (sqrt): Use BUILTIN_VDQF_DF.
   * config/aarch64/arm_neon.h (vsqrt_f64): Use __builtin_aarch64_sqrtdf
   instead of __builtin_sqrt.

Re: [Patch ARM] Improve guality tests - part 1 - pr36728-1.c

[Jakub Jelinek]

On Wed, Feb 04, 2015 at 11:03:29AM +, Ramana Radhakrishnan wrote:
> >
> > Changelog:
> >
> > * gcc.dg/guality/pr36728-1.c: Skip some tests for arm.
> >
> 
> Segher and I discussed an alternative approach - marking these as "m"
> (arg1) , "m" (arg2)  etc in the asm blocks also gives us the same
> effect and then probably removes the need to rely on such target
> markers.  I've just noticed that the AArch64 port has the same issues.

I don't think it is a good idea to significantly change the function being
tested.  Then it tests completely different thing from what it is meant to
test.
But in the pr36728-{1,2}.c case, perhaps you could instead change the
caller, by adding
  asm volatile ("" : : "r" (l));
before return 0; in main, that way DW_OP_GNU_entry_value could work if there
is no other way to find the value of the arguments, because l will need to
live somewhere (in some register or memory) across the foo call.

Jakub

RFA: RL78: Fix gcc testsuite failures

[Nick Clifton]

Hi DJ,

  Please can I apply the patch below to fix some RL78 gcc testsuite
  failures ?

  The patch does two things:  Firstly in the RL78 assembler version of
  the __addsf3 function it fixes a corner case where rounding up the 
  fraction results in an overflow into an unused bit.  The problem here
  was that the exponent was not being increased to cover this lost bit.

  The second fix is to the RL78 specific dead-code elimination pass
  which was failing to note the REGs inside a MEM are used when that MEM
  is the destination of a SET insn.

  Tested with no regressions and lots of fixes using an rl78-elf
  toolchain.

  OK to apply ?

Cheers
  Nick

libgcc/ChangeLog
2015-02-04  Nick Clifton  

* config/rl78/fpmath-sf.S (__addsf3): Add code for the special
  case where rounding the fraction up results in an overflow
  into unused bits.

gcc/ChangeLog
2015-02-04  Nick Clifton  

* config/rl8/rl78.c (rl78_note_reg_set): If the dest is a MEM
  note that any REGs that is contains are being USED.

Index: libgcc/config/rl78/fpmath-sf.S
===
--- libgcc/config/rl78/fpmath-sf.S  (revision 220389)
+++ libgcc/config/rl78/fpmath-sf.S  (working copy)
@@ -517,8 +517,14 @@
movwax, A_FRAC_L
addwax, #1
movwA_FRAC_L, ax
-   sknc
+   bnc $1f
incwA_FRAC_H
+
+   ;; If the rounding set the bit beyond the end of the fraction, 
increment the exponent.
+   mov a, A_FRAC_HH
+   bf  a.1, $1f
+   incwA_EXP
+   
 1: 
movwax, A_FRAC_H
shrwax, 1
Index: gcc/config/rl78/rl78.c
===
--- gcc/config/rl78/rl78.c  (revision 220393)
+++ gcc/config/rl78/rl78.c  (working copy)
@@ -3577,6 +3608,9 @@
 {
   int r, i;
 
+  if (GET_CODE (d) == MEM)
+rl78_note_reg_uses (dead, XEXP (d, 0), insn);
+
   if (GET_CODE (d) != REG)
 return;
 

Re: [Patch ARM] Improve guality tests - part 1 - pr36728-1.c

[Ramana Radhakrishnan]

On 04/02/2015 11:10, Jakub Jelinek wrote:

On Wed, Feb 04, 2015 at 11:03:29AM +, Ramana Radhakrishnan wrote:


Changelog:

* gcc.dg/guality/pr36728-1.c: Skip some tests for arm.



Segher and I discussed an alternative approach - marking these as "m"
(arg1) , "m" (arg2)  etc in the asm blocks also gives us the same
effect and then probably removes the need to rely on such target
markers.  I've just noticed that the AArch64 port has the same issues.


I don't think it is a good idea to significantly change the function being
tested.  Then it tests completely different thing from what it is meant to
test.
But in the pr36728-{1,2}.c case, perhaps you could instead change the
caller, by adding
   asm volatile ("" : : "r" (l));
before return 0; in main, that way DW_OP_GNU_entry_value could work if there
is no other way to find the value of the arguments, because l will need to
live somewhere (in some register or memory) across the foo call.


That's more elegant than marking them all as "used" - I didn't know 
about the DW_OP_GNU_entry_value extension. Pretty neat now that I've 
read about it. It seems to have fixed up all of these issues here.


I don't have access to s390 so I'm not about to revert the s390 bits in 
this particular case.



  Jakub Jelinek  
Ramana Radhakrishnan  

	* gcc.dg/guality/pr36728-1.c (main): Adjust for targets that pass 
parameters in registers.

* gcc.dg/guality/pr36728-2.c: Likewise.
* gcc.dg/guality/pr36728-3.c: Likewise.
* gcc.dg/guality/pr36728-4.c: Likewise.

regards
Ramana



Jakub





diff --git a/gcc/testsuite/gcc.dg/guality/pr36728-1.c 
b/gcc/testsuite/gcc.dg/guality/pr36728-1.c
index ba7a6c2..962a38a 100644
--- a/gcc/testsuite/gcc.dg/guality/pr36728-1.c
+++ b/gcc/testsuite/gcc.dg/guality/pr36728-1.c
@@ -49,5 +49,6 @@ main ()
   int l = 0;
   asm ("" : "=r" (l) : "0" (l));
   a = foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
+  asm volatile ( "" : : "r" (l));
   return 0;
 }
diff --git a/gcc/testsuite/gcc.dg/guality/pr36728-2.c 
b/gcc/testsuite/gcc.dg/guality/pr36728-2.c
index 6daa021..636b968 100644
--- a/gcc/testsuite/gcc.dg/guality/pr36728-2.c
+++ b/gcc/testsuite/gcc.dg/guality/pr36728-2.c
@@ -49,5 +49,6 @@ main ()
   int l = 0;
   asm ("" : "=r" (l) : "0" (l));
   a = foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
+  asm ("" :  : "r" (l));
   return 0;
 }
diff --git a/gcc/testsuite/gcc.dg/guality/pr36728-3.c 
b/gcc/testsuite/gcc.dg/guality/pr36728-3.c
index bb2c067..5be2cbd 100644
--- a/gcc/testsuite/gcc.dg/guality/pr36728-3.c
+++ b/gcc/testsuite/gcc.dg/guality/pr36728-3.c
@@ -47,5 +47,6 @@ main ()
   int l = 0;
   asm volatile ("" : "=r" (l) : "0" (l));
   foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
+  asm volatile ( "" : : "r" (l));
   return 0;
 }
diff --git a/gcc/testsuite/gcc.dg/guality/pr36728-4.c 
b/gcc/testsuite/gcc.dg/guality/pr36728-4.c
index fee79c4..a1cb093 100644
--- a/gcc/testsuite/gcc.dg/guality/pr36728-4.c
+++ b/gcc/testsuite/gcc.dg/guality/pr36728-4.c
@@ -47,5 +47,6 @@ main ()
   int l = 0;
   asm volatile ("" : "=r" (l) : "0" (l));
   foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
+  asm volatile ( "" : "r" (l));
   return 0;
 }

RE: [PATCH MIPS RFA] Regression cleanup for nan2008 toolchain

[Robert Suchanek]

> > 2015-02-02  Robert Suchanek  
> >
> >* gcc.target/mips/loongson-simd.c: Update comment to clarify the
> need
> >for mips_nanlegacy target.
> >
> > diff --git a/gcc/testsuite/gcc.target/mips/loongson-simd.c
> > b/gcc/testsuite/gcc.target/mips/loongson-simd.c
> > index 949632e..9c3ebce 100644
> > --- a/gcc/testsuite/gcc.target/mips/loongson-simd.c
> > +++ b/gcc/testsuite/gcc.target/mips/loongson-simd.c
> > @@ -21,7 +21,10 @@ along with GCC; see the file COPYING3.  If not see
> >  /* { dg-do run } */
> >  /* loongson.h does not handle or check for MIPS16ness or
> > microMIPSness.  There doesn't seem any good reason for it to, given
> > -   that the Loongson processors do not support either.  */
> > +   that the Loongson processors do not support either.  The effective
> target
> > +   mips_nanlegacy is required for a toolchain without the legacy NaN
> support
> > +   because inclusion of some system headers e.g. stdint.h will fail due to
> not
> > +   finding stubs-o32_hard.h.  */
> >  /* { dg-require-effective-target mips_nanlegacy } */
> >  /* { dg-options "isa=loongson -mhard-float -mno-micromips -mno-mips16 -
> > flax-vector-conversions" } */
> >
> 
> Thanks for the update.  This is OK.
> Catherine

Committed as r220393.

Thanks and regards,
Robert

Re: [PATCH][AArch64] Use target builtin instead of __builtin_sqrt for vsqrt_f64

[Marcus Shawcroft]

On 12 January 2015 at 15:52, Kyrill Tkachov  wrote:
> Hi all,
>
> As raised in https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01237.html and
> discussed in that thread, using __builtin_sqrt for vsqrt_f64 may end up in a
> call to the library sqrt at -O0. To avoid that this patch uses a target
> builtin for sqrt on DF mode and uses that to implement the intrinsic.
>
> With this patch I don't see sqrt calls being created at -O0 on a large
> arm_neon.h testcase where they were generated before.
> aarch64-none-elf testing and the intrinsics testsuite in particular are
> clean.
> Ok for trunk?
>
> Thanks,
> Kyrill
>
> 2015-01-12  Kyrylo Tkachov  
>
> * config/aarch64/aarch64-simd-builtins.def (sqrt): Use BUILTIN_VDQF_DF.
> * config/aarch64/arm_neon.h (vsqrt_f64): Use __builtin_aarch64_sqrtdf
> instead of __builtin_sqrt.

OK /Marcus

Re: nvptx offloading patches [3/n], RFD

[Jakub Jelinek]

On Sat, Nov 01, 2014 at 12:57:45PM +0100, Bernd Schmidt wrote:
> This is not against current trunk; it applies to gomp-4_0-branch where it is
> one of the necessary parts to make offloading x86->nvptx work. The issue is
> that the LTO file format depends on the machine_modes enum, it needs to
> match between host and offload target. The easiest way to do this is to just
> use the host-modes.def when compiling an offload compiler.
> 
> Ports that want to be hosts for offloading may need to modify their
> modes.def. The patch below contains changes to i386-modes.def which modifies
> XFmode depending on a target switch. I'm not actually entirely sure what to
> do about this. Do we want to make this flag an error when offloading is
> enabled? Or maybe add float format support to the -foffload-abi option?
> 
> Thoughts? Ok for the first part of the patch once the other offloading
> patches have gone in (bootstrapped and tested on x86_64-linux)?

I don't like this at all.

IMHO instead we should stream in the offloading LTO sections some kind of mode
description table (perhaps limited to the modes actually ever streamed),
and when reading back the offloading LTO sections, let the offloading
compiler remap the modes to its own modes where there is a mapping in
between the two, choose some other mapping (e.g. map various vector modes
the host has but offloading target does not to say BLKmode), or give up
otherwise with offloading (say if you attempt to stream floating point modes
the offloading target doesn't support etc.).

So perhaps stream for each used mode the mode value, corresponding mode
class, size, precision, inner mode, nunits, and for floating point modes
supposedly somehow encode the real_format (perhaps just add a name <->
struct real_format mapping for the real.c modes, and map anything else
to "unknown").

Jakub

Re: [Patch ARM] Improve guality tests - part 1 - pr36728-1.c

[Jakub Jelinek]

On Wed, Feb 04, 2015 at 11:33:19AM +, Ramana Radhakrishnan wrote:
> --- a/gcc/testsuite/gcc.dg/guality/pr36728-1.c
> +++ b/gcc/testsuite/gcc.dg/guality/pr36728-1.c
> @@ -49,5 +49,6 @@ main ()
>int l = 0;
>asm ("" : "=r" (l) : "0" (l));
>a = foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
> +  asm volatile ( "" : : "r" (l));

Please remove the space before "".

> --- a/gcc/testsuite/gcc.dg/guality/pr36728-2.c
> +++ b/gcc/testsuite/gcc.dg/guality/pr36728-2.c
> @@ -49,5 +49,6 @@ main ()
>int l = 0;
>asm ("" : "=r" (l) : "0" (l));
>a = foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
> +  asm ("" :  : "r" (l));

Please add volatile, and remove the extra space in between :  :

> --- a/gcc/testsuite/gcc.dg/guality/pr36728-3.c
> +++ b/gcc/testsuite/gcc.dg/guality/pr36728-3.c
> @@ -47,5 +47,6 @@ main ()
>int l = 0;
>asm volatile ("" : "=r" (l) : "0" (l));
>foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
> +  asm volatile ( "" : : "r" (l));

See the 1st comment.

> --- a/gcc/testsuite/gcc.dg/guality/pr36728-4.c
> +++ b/gcc/testsuite/gcc.dg/guality/pr36728-4.c
> @@ -47,5 +47,6 @@ main ()
>int l = 0;
>asm volatile ("" : "=r" (l) : "0" (l));
>foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
> +  asm volatile ( "" : "r" (l));

Likewise.  Also one : is missing, wonder how this could compile.

Jakub

[PATCH] testsuite: Do not xfail guality/pr{41447,41616}-1.c

[Segher Boessenkool]

These testcases currently XPASS on most targets and configs, so let's
reduce the noise.  Okay for mainline?


Segher


2015-02-04  Segher Boessenkool  

gcc/testsuite/
* gcc.dg/guality/pr41447-1.c: Remove xfail.
* gcc.dg/guality/pr41616-1.c: Ditto.

---
 gcc/testsuite/gcc.dg/guality/pr41447-1.c | 2 +-
 gcc/testsuite/gcc.dg/guality/pr41616-1.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/guality/pr41447-1.c 
b/gcc/testsuite/gcc.dg/guality/pr41447-1.c
index 9bb28ab..308ef94 100644
--- a/gcc/testsuite/gcc.dg/guality/pr41447-1.c
+++ b/gcc/testsuite/gcc.dg/guality/pr41447-1.c
@@ -1,4 +1,4 @@
-/* { dg-do run { xfail *-*-* } } */
+/* { dg-do run } */
 /* { dg-options "-g" } */
 
 #include "guality.h"
diff --git a/gcc/testsuite/gcc.dg/guality/pr41616-1.c 
b/gcc/testsuite/gcc.dg/guality/pr41616-1.c
index fcd1ad5..b033da7 100644
--- a/gcc/testsuite/gcc.dg/guality/pr41616-1.c
+++ b/gcc/testsuite/gcc.dg/guality/pr41616-1.c
@@ -1,4 +1,4 @@
-/* { dg-do run { xfail *-*-* } } */
+/* { dg-do run } */
 /* { dg-options "-g -fgnu89-inline" } */
 
 #include "guality.h"
-- 
1.8.1.4

Commit: MSP430: Extend msp430_use_f5_series_hwmult()

[Nick Clifton]

Hi Guys,

  I am applying the patch below to extend the MSP430 port of gcc's
  auto-recognition of F5 multiply hardware enabled MCUs.

Cheers
  Nick

gcc/ChangeLog
2015-02-04  Nick Clifton  

* config/msp430/msp430.c (msp430_use_f5_series_hwmult): Add more
prefixes of known F5 using MSP430 MCUs.

Index: gcc/config/msp430/msp430.c
===
RCS file: /cvs/cvsfiles/gnupro/gcc/config/msp430/msp430.c,v
retrieving revision 1.9.2.6
diff -u -3 -p -r1.9.2.6 msp430.c
--- gcc/config/msp430/msp430.c  15 Dec 2014 20:25:23 -  1.9.2.6
+++ gcc/config/msp430/msp430.c  22 Jan 2015 16:33:15 -
@@ -2508,6 +2508,10 @@ msp430_use_f5_series_hwmult (void)
 
   if (strncasecmp (target_mcu, "msp430f5", 8) == 0)
 return cached_result = true;
+  if (strncasecmp (target_mcu, "msp430fr5", 9) == 0)
+return cached_result = true;
+  if (strncasecmp (target_mcu, "msp430f6", 8) == 0)
+return cached_result = true;
 
   static const char * known_f5_mult_mcus [] =
 {
@@ -2516,7 +2520,8 @@ msp430_use_f5_series_hwmult (void)
   "cc430f5145","cc430f5147",   "cc430f6125",
   "cc430f6126","cc430f6127",   "cc430f6135",
   "cc430f6137","cc430f6143",   "cc430f6145",
-  "cc430f6147","msp430bt5190", "msp430sl5438a"
+  "cc430f6147","msp430bt5190", "msp430sl5438a",
+  "msp430xgeneric"
 };
   int i;
 

Re: [PATCH] testsuite: Do not xfail guality/pr{41447,41616}-1.c

[Jakub Jelinek]

On Wed, Feb 04, 2015 at 03:48:38AM -0800, Segher Boessenkool wrote:
> These testcases currently XPASS on most targets and configs, so let's
> reduce the noise.  Okay for mainline?

Doesn't look like that is the case.  obj69 is x86_64, obj70 is i686.
grep '\(41447\|41616\).*execution' obj{69,70}/gcc/testsuite/gcc/gcc.sum
obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O0  
execution test
obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O1  
execution test
obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O2  
execution test
obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O2 -flto 
-fno-use-linker-plugin -flto-partition=none  execution test
obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O2 -flto 
-fuse-linker-plugin -fno-fat-lto-objects  execution test
obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O3 
-fomit-frame-pointer  execution test
obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O3 -g  
execution test
obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -Os  
execution test
obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O0  
execution test
obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O1  
execution test
obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O2  
execution test
obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O2 -flto 
-fno-use-linker-plugin -flto-partition=none  execution test
obj69/gcc/testsuite/gcc/gcc.sum:XFAIL: gcc.dg/guality/pr41616-1.c   -O2 -flto 
-fuse-linker-plugin -fno-fat-lto-objects  execution test
obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O3 
-fomit-frame-pointer  execution test
obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O3 -g  
execution test
obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -Os  
execution test
obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O0  
execution test
obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O1  
execution test
obj70/gcc/testsuite/gcc/gcc.sum:XFAIL: gcc.dg/guality/pr41447-1.c   -O2  
execution test
obj70/gcc/testsuite/gcc/gcc.sum:XFAIL: gcc.dg/guality/pr41447-1.c   -O2 -flto  
execution test
obj70/gcc/testsuite/gcc/gcc.sum:XFAIL: gcc.dg/guality/pr41447-1.c   -O2 -flto 
-flto-partition=none  execution test
obj70/gcc/testsuite/gcc/gcc.sum:XFAIL: gcc.dg/guality/pr41447-1.c   -O3 
-fomit-frame-pointer  execution test
obj70/gcc/testsuite/gcc/gcc.sum:XFAIL: gcc.dg/guality/pr41447-1.c   -O3 -g  
execution test
obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -Os  
execution test
obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O0  
execution test
obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O1  
execution test
obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O2  
execution test
obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O2 -flto  
execution test
obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O2 -flto 
-flto-partition=none  execution test
obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O3 
-fomit-frame-pointer  execution test
obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O3 -g  
execution test
obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -Os  
execution test

At least pr41447 on i686...
So I'm not sure if this patch would not do more harm than good.

Jakub

[AArch64] Rid the world of NAMED_PARAM

[James Greenhalgh]

Hi,

HAVE_DESIGNATED_INITIALIZERS is not set for C++, so the NAMED_PARAM macros
using it provide false security when we compile aarch64.c. Removing this
is an obvious cleanup and gets rid of some confusing dead code.

This patch removes all the magic macros.

Bootstrapped and tested on aarch64-none-linux-gnu with no issues.

I can't see anyone objecting to this and would normally commit it
as obvious, but as we are in Stage 4, I'll ask for permission.

So OK for trunk/Stage 1?

Thanks,
James

---
2015-02-04  James Greenhalgh 

* config/aarch64/aarch64.c (NAMED_PARAM): Delete it.
(generic_addrcost_table): Remove NAMED_PARAM.
(cortexa57_addrcost_table): Likewise.
(xgene1_addrcost_table): Likewise.
(generic_regmove_table): Likewise.
(cortexa53_regmove_table): Likewise.
(xgene1_regmove_table): Likewise.
(generic_vector_table): Likewise.
(cortexa57_vector_table): Likewise.
(xgene1_vector_table): Likewise.
(generic_tunings): Likewise.
(cortexa53_tunings): Likewise.
(cortexa57_tunings): Likewise.
(xgene1_tunings): Likewise.
diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
index b923fdb..8886572 100644
--- a/gcc/config/aarch64/aarch64.c
+++ b/gcc/config/aarch64/aarch64.c
@@ -188,188 +188,148 @@ unsigned long aarch64_tune_flags = 0;
 
 /* Tuning parameters.  */
 
-#if HAVE_DESIGNATED_INITIALIZERS
-#define NAMED_PARAM(NAME, VAL) .NAME = (VAL)
-#else
-#define NAMED_PARAM(NAME, VAL) (VAL)
-#endif
-
-#if HAVE_DESIGNATED_INITIALIZERS && GCC_VERSION >= 2007
-__extension__
-#endif
-
-#if HAVE_DESIGNATED_INITIALIZERS && GCC_VERSION >= 2007
-__extension__
-#endif
 static const struct cpu_addrcost_table generic_addrcost_table =
 {
-#if HAVE_DESIGNATED_INITIALIZERS
-  .addr_scale_costs =
-#endif
 {
-  NAMED_PARAM (hi, 0),
-  NAMED_PARAM (si, 0),
-  NAMED_PARAM (di, 0),
-  NAMED_PARAM (ti, 0),
+  0, /* hi  */
+  0, /* si  */
+  0, /* di  */
+  0, /* ti  */
 },
-  NAMED_PARAM (pre_modify, 0),
-  NAMED_PARAM (post_modify, 0),
-  NAMED_PARAM (register_offset, 0),
-  NAMED_PARAM (register_extend, 0),
-  NAMED_PARAM (imm_offset, 0)
+  0, /* pre_modify  */
+  0, /* post_modify  */
+  0, /* register_offset  */
+  0, /* register_extend  */
+  0 /* imm_offset  */
 };
 
-#if HAVE_DESIGNATED_INITIALIZERS && GCC_VERSION >= 2007
-__extension__
-#endif
 static const struct cpu_addrcost_table cortexa57_addrcost_table =
 {
-#if HAVE_DESIGNATED_INITIALIZERS
-  .addr_scale_costs =
-#endif
 {
-  NAMED_PARAM (hi, 1),
-  NAMED_PARAM (si, 0),
-  NAMED_PARAM (di, 0),
-  NAMED_PARAM (ti, 1),
+  1, /* hi  */
+  0, /* si  */
+  0, /* di  */
+  1, /* ti  */
 },
-  NAMED_PARAM (pre_modify, 0),
-  NAMED_PARAM (post_modify, 0),
-  NAMED_PARAM (register_offset, 0),
-  NAMED_PARAM (register_extend, 0),
-  NAMED_PARAM (imm_offset, 0),
+  0, /* pre_modify  */
+  0, /* post_modify  */
+  0, /* register_offset  */
+  0, /* register_extend  */
+  0, /* imm_offset  */
 };
 
-#if HAVE_DESIGNATED_INITIALIZERS && GCC_VERSION >= 2007
-__extension__
-#endif
 static const struct cpu_addrcost_table xgene1_addrcost_table =
 {
-#if HAVE_DESIGNATED_INITIALIZERS
-  .addr_scale_costs =
-#endif
 {
-  NAMED_PARAM (hi, 1),
-  NAMED_PARAM (si, 0),
-  NAMED_PARAM (di, 0),
-  NAMED_PARAM (ti, 1),
+  1, /* hi  */
+  0, /* si  */
+  0, /* di  */
+  1, /* ti  */
 },
-  NAMED_PARAM (pre_modify, 1),
-  NAMED_PARAM (post_modify, 0),
-  NAMED_PARAM (register_offset, 0),
-  NAMED_PARAM (register_extend, 1),
-  NAMED_PARAM (imm_offset, 0),
+  1, /* pre_modify  */
+  0, /* post_modify  */
+  0, /* register_offset  */
+  1, /* register_extend  */
+  0, /* imm_offset  */
 };
 
-#if HAVE_DESIGNATED_INITIALIZERS && GCC_VERSION >= 2007
-__extension__
-#endif
 static const struct cpu_regmove_cost generic_regmove_cost =
 {
-  NAMED_PARAM (GP2GP, 1),
+  1, /* GP2GP  */
   /* Avoid the use of slow int<->fp moves for spilling by setting
  their cost higher than memmov_cost.  */
-  NAMED_PARAM (GP2FP, 5),
-  NAMED_PARAM (FP2GP, 5),
-  NAMED_PARAM (FP2FP, 2)
+  5, /* GP2FP  */
+  5, /* FP2GP  */
+  2 /* FP2FP  */
 };
 
 static const struct cpu_regmove_cost cortexa57_regmove_cost =
 {
-  NAMED_PARAM (GP2GP, 1),
+  1, /* GP2GP  */
   /* Avoid the use of slow int<->fp moves for spilling by setting
  their cost higher than memmov_cost.  */
-  NAMED_PARAM (GP2FP, 5),
-  NAMED_PARAM (FP2GP, 5),
-  NAMED_PARAM (FP2FP, 2)
+  5, /* GP2FP  */
+  5, /* FP2GP  */
+  2 /* FP2FP  */
 };
 
 static const struct cpu_regmove_cost cortexa53_regmove_cost =
 {
-  NAMED_PARAM (GP2GP, 1),
+  1, /* GP2GP  */
   /* Avoid the use of slow int<->fp moves for spilling by setting
  their cost higher than memmov_cost.  */
-  NAMED_PARAM (GP2FP, 5),
-  NAMED_PARAM (FP2GP, 5),
-  NAMED_PARAM (FP2FP, 2)
+  5, /* GP2FP  */
+  5, /* FP2GP  */
+  2 /* FP2FP  */
 };
 
 static 

[PATCH][ARM] Rewrite vc NEON patterns to use RTL operations rather than UNSPECs

[Kyrill Tkachov]

Hi all,

This patch improves the vc patterns in neon.md to use proper RTL 
operations rather than UNSPECS.
It is done in a similar way to the analogous aarch64 operations i.e. 
vceq is expressed as

(neg (eq (...) (...)))
since we want to write all 1s to the result element when 'eq' holds and 
0s otherwise.


The catch is that the floating-point comparisons can only be expanded to 
the RTL codes when -funsafe-math-optimizations is given and they must 
continue to use the UNSPECS otherwise.

For this I've created a define_expand that generates
the correct RTL depending on -funsafe-math-optimizations and two 
define_insns to match the result: one using the RTL codes and one using 
UNSPECs.


I've also compressed some of the patterns together using iterators for 
the [eq gt ge le lt] cases.
NOTE: for le and lt before this patch we would never generate 
'vclt. dm, dn, dp' instructions, only 'vclt. dm, dn, #0'.
With this patch we can now generate 'vclt. dm, dn, dp' assembly. 
According to the ARM ARM this is just a pseudo-instruction that mapps to 
vcgt with the operands swapped around.

I've confirmed that gas supports this code.

The vcage and vcagt patterns are rewritten to use the form:
(neg
  (
(abs (...))
(abs (...

and condensed together using iterators as well.

Bootstrapped and tested on arm-none-linux-gnueabihf, made sure that the 
advanced-simd-intrinsics testsuite is passing
(it did catch some bugs during development of this patch) and tried out 
other NEON intrinsics codebases.


The test gcc.target/arm/neon/pr51534.c now generates 'vclt. dn, 
dm, #0' instructions where appropriate instead of the previous vmov of 
#0 into a temp and then a 'vcgt. dn, temp, dm'.
I think that is correct behaviour since the test was trying to make sure 
that we didn't generate a .u-typed comparison with #0, which is 
what the PR was talking about (from what I can gather).


What do people think of this approach?
I'm proposing this for next stage1, of course.

Thanks,
Kyrill


2015-02-04  Kyrylo Tkachov  

* config/arm/iterators.md (GTGE, GTUGEU, COMPARISONS): New code
iterators.
(cmp_op, cmp_type): New code attributes.
(NEON_VCMP, NEON_VACMP): New int iterators.
(cmp_op_unsp): New int attribute.
* config/arm/neon.md (neon_vc): New define_expand.
(neon_vceq): Delete.
(neon_vc_insn): New pattern.
(neon_vc_insn_unspec): Likewise.
(neon_vcgeu): Delete.
(neon_vcle): Likewise.
(neon_vclt: Likewise.
(neon_vcage): Likewise.
(neon_vcagt): Likewise.
(neon_vca): New define_expand.
(neon_vca_insn): New pattern.
(neon_vca_insn_unspec): Likewise.

2015-02-04  Kyrylo Tkachov  

* gcc.target/arm/neon/pr51534.c: Update vcg* scan-assembly patterns
to look for vcl* where appropriate.diff --git a/gcc/config/arm/iterators.md b/gcc/config/arm/iterators.md
index f7f8ab7..66f3f4d 100644
--- a/gcc/config/arm/iterators.md
+++ b/gcc/config/arm/iterators.md
@@ -181,6 +181,15 @@ (define_mode_iterator VPF [V8QI V16QI V2SF V4SF])
 ;; compare a second time.
 (define_code_iterator LTUGEU [ltu geu])
 
+;; The signed gt, ge comparisons
+(define_code_iterator GTGE [gt ge])
+
+;; The unsigned gt, ge comparisons
+(define_code_iterator GTUGEU [gtu geu])
+
+;; Comparisons for vc
+(define_code_iterator COMPARISONS [eq gt ge le lt])
+
 ;; A list of ...
 (define_code_iterator ior_xor [ior xor])
 
@@ -214,6 +223,11 @@ (define_code_attr t2_binop0
 (define_code_attr arith_shift_insn
   [(plus "add") (minus "rsb") (ior "orr") (xor "eor") (and "and")])
 
+(define_code_attr cmp_op [(eq "eq") (gt "gt") (ge "ge") (lt "lt") (le "le")
+  (gtu "gt") (geu "ge")])
+
+(define_code_attr cmp_type [(eq "i") (gt "s") (ge "s") (lt "s") (le "s")])
+
 ;;
 ;; Int iterators
 ;;
@@ -221,6 +235,10 @@ (define_code_attr arith_shift_insn
 (define_int_iterator VRINT [UNSPEC_VRINTZ UNSPEC_VRINTP UNSPEC_VRINTM
 UNSPEC_VRINTR UNSPEC_VRINTX UNSPEC_VRINTA])
 
+(define_int_iterator NEON_VCMP [UNSPEC_VCEQ UNSPEC_VCGT UNSPEC_VCGE UNSPEC_VCLT UNSPEC_VCLE])
+
+(define_int_iterator NEON_VACMP [UNSPEC_VCAGE UNSPEC_VCAGT])
+
 (define_int_iterator VCVT [UNSPEC_VRINTP UNSPEC_VRINTM UNSPEC_VRINTA])
 
 (define_int_iterator NEON_VRINT [UNSPEC_NVRINTP UNSPEC_NVRINTZ UNSPEC_NVRINTM
@@ -677,6 +695,11 @@ (define_int_attr sup [
 
 ])
 
+(define_int_attr cmp_op_unsp [(UNSPEC_VCEQ "eq") (UNSPEC_VCGT "gt")
+  (UNSPEC_VCGE "ge") (UNSPEC_VCLE "le")
+  (UNSPEC_VCLT "lt") (UNSPEC_VCAGE "ge")
+  (UNSPEC_VCAGT "gt")])
+
 (define_int_attr r [
   (UNSPEC_VRHADD_S "r") (UNSPEC_VRHADD_U "r")
   (UNSPEC_VHADD_S "") (UNSPEC_VHADD_U "")
diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index 63c327e..445df2a 100644
--- a/gcc/config/arm/neon.md
++

[PATCH][AArch64] Use std::swap instead of manually swapping in aarch64-ldpstp.md

[Kyrill Tkachov]

Hi all,

This patch makes use of std::swap in every peephole2 of 
aarch64-ldp-stp.md instead of manually swapping rtxen.

No functional change, just a cleanup.
Bootstrapped and tested on aarch64.

I'm proposing this for next stage1 together with the other AArch64 patch 
that

moves a couple of places of aarch64.c to use std::swap
(https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01426.html)

Thanks,
Kyrill

2015-02-04  Kyrylo Tkachov  

* config/aarch64/aarch64-ldpstp.md: Use std::swap instead of
manual swaps in all peepholes.commit d1f937c2ed28d3d1bab09536b93906ba6fe99fa9
Author: Kyrylo Tkachov 
Date:   Mon Feb 2 14:44:54 2015 +

[AArch64] Use std::swap in aarch64-ldpstp.md

diff --git a/gcc/config/aarch64/aarch64-ldpstp.md b/gcc/config/aarch64/aarch64-ldpstp.md
index af8d50e..8d6d882 100644
--- a/gcc/config/aarch64/aarch64-ldpstp.md
+++ b/gcc/config/aarch64/aarch64-ldpstp.md
@@ -27,18 +27,14 @@ (define_peephole2
   [(parallel [(set (match_dup 0) (match_dup 1))
 	  (set (match_dup 2) (match_dup 3))])]
 {
-  rtx base, offset_1, offset_2, tmp;
+  rtx base, offset_1, offset_2;
 
   extract_base_offset_in_addr (operands[1], &base, &offset_1);
   extract_base_offset_in_addr (operands[3], &base, &offset_2);
   if (INTVAL (offset_1) > INTVAL (offset_2))
 {
-  tmp = operands[0];
-  operands[0] = operands[2];
-  operands[2] = tmp;
-  tmp = operands[1];
-  operands[1] = operands[3];
-  operands[3] = tmp;
+  std::swap (operands[0], operands[2]);
+  std::swap (operands[1], operands[3]);
 }
 })
 
@@ -51,18 +47,14 @@ (define_peephole2
   [(parallel [(set (match_dup 0) (match_dup 1))
 	  (set (match_dup 2) (match_dup 3))])]
 {
-  rtx base, offset_1, offset_2, tmp;
+  rtx base, offset_1, offset_2;
 
   extract_base_offset_in_addr (operands[0], &base, &offset_1);
   extract_base_offset_in_addr (operands[2], &base, &offset_2);
   if (INTVAL (offset_1) > INTVAL (offset_2))
 {
-  tmp = operands[0];
-  operands[0] = operands[2];
-  operands[2] = tmp;
-  tmp = operands[1];
-  operands[1] = operands[3];
-  operands[3] = tmp;
+  std::swap (operands[0], operands[2]);
+  std::swap (operands[1], operands[3]);
 }
 })
 
@@ -75,18 +67,14 @@ (define_peephole2
   [(parallel [(set (match_dup 0) (match_dup 1))
 	  (set (match_dup 2) (match_dup 3))])]
 {
-  rtx base, offset_1, offset_2, tmp;
+  rtx base, offset_1, offset_2;
 
   extract_base_offset_in_addr (operands[1], &base, &offset_1);
   extract_base_offset_in_addr (operands[3], &base, &offset_2);
   if (INTVAL (offset_1) > INTVAL (offset_2))
 {
-  tmp = operands[0];
-  operands[0] = operands[2];
-  operands[2] = tmp;
-  tmp = operands[1];
-  operands[1] = operands[3];
-  operands[3] = tmp;
+  std::swap (operands[0], operands[2]);
+  std::swap (operands[1], operands[3]);
 }
 })
 
@@ -99,18 +87,14 @@ (define_peephole2
   [(parallel [(set (match_dup 0) (match_dup 1))
 	  (set (match_dup 2) (match_dup 3))])]
 {
-  rtx base, offset_1, offset_2, tmp;
+  rtx base, offset_1, offset_2;
 
   extract_base_offset_in_addr (operands[0], &base, &offset_1);
   extract_base_offset_in_addr (operands[2], &base, &offset_2);
   if (INTVAL (offset_1) > INTVAL (offset_2))
 {
-  tmp = operands[0];
-  operands[0] = operands[2];
-  operands[2] = tmp;
-  tmp = operands[1];
-  operands[1] = operands[3];
-  operands[3] = tmp;
+  std::swap (operands[0], operands[2]);
+  std::swap (operands[1], operands[3]);
 }
 })
 
@@ -125,18 +109,14 @@ (define_peephole2
   [(parallel [(set (match_dup 0) (sign_extend:DI (match_dup 1)))
 	  (set (match_dup 2) (sign_extend:DI (match_dup 3)))])]
 {
-  rtx base, offset_1, offset_2, tmp;
+  rtx base, offset_1, offset_2;
 
   extract_base_offset_in_addr (operands[1], &base, &offset_1);
   extract_base_offset_in_addr (operands[3], &base, &offset_2);
   if (INTVAL (offset_1) > INTVAL (offset_2))
 {
-  tmp = operands[0];
-  operands[0] = operands[2];
-  operands[2] = tmp;
-  tmp = operands[1];
-  operands[1] = operands[3];
-  operands[3] = tmp;
+  std::swap (operands[0], operands[2]);
+  std::swap (operands[1], operands[3]);
 }
 })
 
@@ -149,18 +129,14 @@ (define_peephole2
   [(parallel [(set (match_dup 0) (zero_extend:DI (match_dup 1)))
 	  (set (match_dup 2) (zero_extend:DI (match_dup 3)))])]
 {
-  rtx base, offset_1, offset_2, tmp;
+  rtx base, offset_1, offset_2;
 
   extract_base_offset_in_addr (operands[1], &base, &offset_1);
   extract_base_offset_in_addr (operands[3], &base, &offset_2);
   if (INTVAL (offset_1) > INTVAL (offset_2))
 {
-  tmp = operands[0];
-  operands[0] = operands[2];
-  operands[2] = tmp;
-  tmp = operands[1];
-  operands[1] = operands[3];
-  operands[3] = tmp;
+  std::swap (operands[0], operands[2]);
+  std::swap (operands[1], operands[3]);
 }
 })
 
@@ -183,24 +159,16 @@ (define_peephole2

Re: [PATCH][AArch64] Use std::swap instead of manually swapping in aarch64-ldpstp.md

[James Greenhalgh]

On Wed, Feb 04, 2015 at 12:18:29PM +, Kyrill Tkachov wrote:
> Hi all,
> 
> This patch makes use of std::swap in every peephole2 of 
> aarch64-ldp-stp.md instead of manually swapping rtxen.
> No functional change, just a cleanup.
> Bootstrapped and tested on aarch64.
> 
> I'm proposing this for next stage1 together with the other AArch64 patch 
> that
> moves a couple of places of aarch64.c to use std::swap
> (https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01426.html)

Both of these are obvious patches that it would be hard to object to.
If you put them in now, then 6.0 -> 5.n backports will be easier.

Remember, the obvious rule is:

  "Obvious fixes can be committed without prior approval. Just check in 
   the fix and copy it to gcc-patches. A good test to determine whether a fix
   is obvious: "will the person who objects to my work the most be able to find
   a fault with my fix?" If the fix is later found to be faulty, it can always
   be rolled back.  We don't want to get overly restrictive about checkin
   policies."

Can you really see somebody objecting to this clean up? We have plenty of
uses of std::swap already, you've made the same changes to the arm port,
and other targets are also moving (and committing the patches as
obvious!)

But, as you asked - this looks fine, but you'll need Marcus or
Richard to OK it.

Thanks,
James

> 
> Thanks,
> Kyrill
> 
> 2015-02-04  Kyrylo Tkachov  
> 
>  * config/aarch64/aarch64-ldpstp.md: Use std::swap instead of
>  manual swaps in all peepholes.

> commit d1f937c2ed28d3d1bab09536b93906ba6fe99fa9
> Author: Kyrylo Tkachov 
> Date:   Mon Feb 2 14:44:54 2015 +
> 
> [AArch64] Use std::swap in aarch64-ldpstp.md
> 
> diff --git a/gcc/config/aarch64/aarch64-ldpstp.md 
> b/gcc/config/aarch64/aarch64-ldpstp.md
> index af8d50e..8d6d882 100644
> --- a/gcc/config/aarch64/aarch64-ldpstp.md
> +++ b/gcc/config/aarch64/aarch64-ldpstp.md
> @@ -27,18 +27,14 @@ (define_peephole2
>[(parallel [(set (match_dup 0) (match_dup 1))
> (set (match_dup 2) (match_dup 3))])]
>  {
> -  rtx base, offset_1, offset_2, tmp;
> +  rtx base, offset_1, offset_2;
>  
>extract_base_offset_in_addr (operands[1], &base, &offset_1);
>extract_base_offset_in_addr (operands[3], &base, &offset_2);
>if (INTVAL (offset_1) > INTVAL (offset_2))
>  {
> -  tmp = operands[0];
> -  operands[0] = operands[2];
> -  operands[2] = tmp;
> -  tmp = operands[1];
> -  operands[1] = operands[3];
> -  operands[3] = tmp;
> +  std::swap (operands[0], operands[2]);
> +  std::swap (operands[1], operands[3]);
>  }
>  })
>  
> @@ -51,18 +47,14 @@ (define_peephole2
>[(parallel [(set (match_dup 0) (match_dup 1))
> (set (match_dup 2) (match_dup 3))])]
>  {
> -  rtx base, offset_1, offset_2, tmp;
> +  rtx base, offset_1, offset_2;
>  
>extract_base_offset_in_addr (operands[0], &base, &offset_1);
>extract_base_offset_in_addr (operands[2], &base, &offset_2);
>if (INTVAL (offset_1) > INTVAL (offset_2))
>  {
> -  tmp = operands[0];
> -  operands[0] = operands[2];
> -  operands[2] = tmp;
> -  tmp = operands[1];
> -  operands[1] = operands[3];
> -  operands[3] = tmp;
> +  std::swap (operands[0], operands[2]);
> +  std::swap (operands[1], operands[3]);
>  }
>  })
>  
> @@ -75,18 +67,14 @@ (define_peephole2
>[(parallel [(set (match_dup 0) (match_dup 1))
> (set (match_dup 2) (match_dup 3))])]
>  {
> -  rtx base, offset_1, offset_2, tmp;
> +  rtx base, offset_1, offset_2;
>  
>extract_base_offset_in_addr (operands[1], &base, &offset_1);
>extract_base_offset_in_addr (operands[3], &base, &offset_2);
>if (INTVAL (offset_1) > INTVAL (offset_2))
>  {
> -  tmp = operands[0];
> -  operands[0] = operands[2];
> -  operands[2] = tmp;
> -  tmp = operands[1];
> -  operands[1] = operands[3];
> -  operands[3] = tmp;
> +  std::swap (operands[0], operands[2]);
> +  std::swap (operands[1], operands[3]);
>  }
>  })
>  
> @@ -99,18 +87,14 @@ (define_peephole2
>[(parallel [(set (match_dup 0) (match_dup 1))
> (set (match_dup 2) (match_dup 3))])]
>  {
> -  rtx base, offset_1, offset_2, tmp;
> +  rtx base, offset_1, offset_2;
>  
>extract_base_offset_in_addr (operands[0], &base, &offset_1);
>extract_base_offset_in_addr (operands[2], &base, &offset_2);
>if (INTVAL (offset_1) > INTVAL (offset_2))
>  {
> -  tmp = operands[0];
> -  operands[0] = operands[2];
> -  operands[2] = tmp;
> -  tmp = operands[1];
> -  operands[1] = operands[3];
> -  operands[3] = tmp;
> +  std::swap (operands[0], operands[2]);
> +  std::swap (operands[1], operands[3]);
>  }
>  })
>  
> @@ -125,18 +109,14 @@ (define_peephole2
>[(parallel [(set (match_dup 0) (sign_extend:DI (match_dup 1)))
> (set (match_dup 2) (sign_extend:DI (match_dup 3)))])]
>  {
> -  rtx base, offset_1, offset_2, tmp;
> +  rtx 

Re: [Patch ARM] Improve guality tests - part 1 - pr36728-1.c

[Ramana Radhakrishnan]

On 04/02/2015 11:40, Jakub Jelinek wrote:

On Wed, Feb 04, 2015 at 11:33:19AM +, Ramana Radhakrishnan wrote:

--- a/gcc/testsuite/gcc.dg/guality/pr36728-1.c
+++ b/gcc/testsuite/gcc.dg/guality/pr36728-1.c
@@ -49,5 +49,6 @@ main ()
int l = 0;
asm ("" : "=r" (l) : "0" (l));
a = foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
+  asm volatile ( "" : : "r" (l));


Please remove the space before "".


--- a/gcc/testsuite/gcc.dg/guality/pr36728-2.c
+++ b/gcc/testsuite/gcc.dg/guality/pr36728-2.c
@@ -49,5 +49,6 @@ main ()
int l = 0;
asm ("" : "=r" (l) : "0" (l));
a = foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
+  asm ("" :  : "r" (l));


Please add volatile, and remove the extra space in between :  :


--- a/gcc/testsuite/gcc.dg/guality/pr36728-3.c
+++ b/gcc/testsuite/gcc.dg/guality/pr36728-3.c
@@ -47,5 +47,6 @@ main ()
int l = 0;
asm volatile ("" : "=r" (l) : "0" (l));
foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
+  asm volatile ( "" : : "r" (l));


See the 1st comment.


--- a/gcc/testsuite/gcc.dg/guality/pr36728-4.c
+++ b/gcc/testsuite/gcc.dg/guality/pr36728-4.c
@@ -47,5 +47,6 @@ main ()
int l = 0;
asm volatile ("" : "=r" (l) : "0" (l));
foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
+  asm volatile ( "" : "r" (l));


Likewise.  Also one : is missing, wonder how this could compile.



Bah - only saw the reduction in testcases.

Now corrected and checked on armhf that number of tests failing reduces 
as expected and the pr36728-4.c test runs and shows no failures on 
arm-linux-gnueabihf


Applied with the changes suggested as r220398.

Ramana



Ramana


Jakub

diff --git a/gcc/testsuite/gcc.dg/guality/pr36728-1.c 
b/gcc/testsuite/gcc.dg/guality/pr36728-1.c
index ba7a6c2..0ab475a 100644
--- a/gcc/testsuite/gcc.dg/guality/pr36728-1.c
+++ b/gcc/testsuite/gcc.dg/guality/pr36728-1.c
@@ -49,5 +49,6 @@ main ()
   int l = 0;
   asm ("" : "=r" (l) : "0" (l));
   a = foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
+  asm volatile ("" :: "r" (l));
   return 0;
 }
diff --git a/gcc/testsuite/gcc.dg/guality/pr36728-2.c 
b/gcc/testsuite/gcc.dg/guality/pr36728-2.c
index 6daa021..7ba8663 100644
--- a/gcc/testsuite/gcc.dg/guality/pr36728-2.c
+++ b/gcc/testsuite/gcc.dg/guality/pr36728-2.c
@@ -49,5 +49,6 @@ main ()
   int l = 0;
   asm ("" : "=r" (l) : "0" (l));
   a = foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
+  asm volatile ("" :: "r" (l));
   return 0;
 }
diff --git a/gcc/testsuite/gcc.dg/guality/pr36728-3.c 
b/gcc/testsuite/gcc.dg/guality/pr36728-3.c
index bb2c067..4700d50 100644
--- a/gcc/testsuite/gcc.dg/guality/pr36728-3.c
+++ b/gcc/testsuite/gcc.dg/guality/pr36728-3.c
@@ -47,5 +47,6 @@ main ()
   int l = 0;
   asm volatile ("" : "=r" (l) : "0" (l));
   foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
+  asm volatile ("" :: "r" (l));
   return 0;
 }
diff --git a/gcc/testsuite/gcc.dg/guality/pr36728-4.c 
b/gcc/testsuite/gcc.dg/guality/pr36728-4.c
index fee79c4..bf6e9e9 100644
--- a/gcc/testsuite/gcc.dg/guality/pr36728-4.c
+++ b/gcc/testsuite/gcc.dg/guality/pr36728-4.c
@@ -47,5 +47,6 @@ main ()
   int l = 0;
   asm volatile ("" : "=r" (l) : "0" (l));
   foo (l + 1, l + 2, l + 3, l + 4, l + 5, l + 6, l + 30);
+  asm volatile ("" :: "r" (l));
   return 0;
 }

Re: [AArch64] Rid the world of NAMED_PARAM

[Marcus Shawcroft]

On 4 February 2015 at 12:06, James Greenhalgh  wrote:
>
> Hi,
>
> HAVE_DESIGNATED_INITIALIZERS is not set for C++, so the NAMED_PARAM macros
> using it provide false security when we compile aarch64.c. Removing this
> is an obvious cleanup and gets rid of some confusing dead code.
>
> This patch removes all the magic macros.
>
> Bootstrapped and tested on aarch64-none-linux-gnu with no issues.
>
> I can't see anyone objecting to this and would normally commit it
> as obvious, but as we are in Stage 4, I'll ask for permission.
>
> So OK for trunk/Stage 1?
>
> Thanks,
> James
>
> ---
> 2015-02-04  James Greenhalgh 
>
> * config/aarch64/aarch64.c (NAMED_PARAM): Delete it.
> (generic_addrcost_table): Remove NAMED_PARAM.
> (cortexa57_addrcost_table): Likewise.
> (xgene1_addrcost_table): Likewise.
> (generic_regmove_table): Likewise.
> (cortexa53_regmove_table): Likewise.
> (xgene1_regmove_table): Likewise.
> (generic_vector_table): Likewise.
> (cortexa57_vector_table): Likewise.
> (xgene1_vector_table): Likewise.
> (generic_tunings): Likewise.
> (cortexa53_tunings): Likewise.
> (cortexa57_tunings): Likewise.
> (xgene1_tunings): Likewise.


This is pure churn, no functional change. I'd rather take this now in
stage than defer to stage 1.  Taking it now will mean less back port
pain next year. OK /Marcus

Re: [PATCH, ivopt] Try aligned offset when get_address_cost

[Richard Biener]

On February 4, 2015 11:32:54 AM CET, Eric Botcazou  
wrote:
>> For some TARGET, like ARM THUMB1, the offset in load/store should be
>nature
>> aligned. But in function get_address_cost, when computing max_offset,
>it
>> only tries byte-aligned offsets:
>> 
>>   ((unsigned HOST_WIDE_INT) 1 << i) - 1
>> 
>> which can not meet thumb_legitimate_offset_p check called from
>> thumb1_legitimate_address_p for HImode and SImode.
>> 
>> The patch adds additional try for aligned offset:
>> 
>>   ((unsigned HOST_WIDE_INT) 1 << i) - GET_MODE_SIZE (address_mode).
>
>I think that the change is not fully correct, this must be mem_mode
>instead of 
>address_mode since the alignment of the MEM is given by mem_mode:
>
>Index: tree-ssa-loop-ivopts.c
>===
>--- tree-ssa-loop-ivopts.c  (revision 220343)
>+++ tree-ssa-loop-ivopts.c  (working copy)
>@@ -3324,12 +3324,12 @@ get_address_cost (bool symbol_present, b
>  XEXP (addr, 1) = gen_int_mode (off, address_mode);
>  if (memory_address_addr_space_p (mem_mode, addr, as))
>break;
>- /* For some TARGET, like ARM THUMB1, the offset should be
>nature
>-aligned. Try an aligned offset if address_mode is not
>QImode.  */
>- off = (address_mode == QImode)
>+ /* For some strict-alignment targets, the offset must be
>naturally
>+aligned.  Try an aligned offset if mem_mode is not QImode.
> */
>+ off = mem_mode == QImode
>? 0
>: ((unsigned HOST_WIDE_INT) 1 << i)
>-   - GET_MODE_SIZE (address_mode);
>+   - GET_MODE_SIZE (mem_mode);
>  if (off > 0)
>{
>  XEXP (addr, 1) = gen_int_mode (off, address_mode);
>
>
>This fixes unexpected differences in the result of the function between
>SPARC 
>and SPARC64 for the same source code.  OK for mainline after testing?

OK.

Thanks,
Richard.

>
>   * tree-ssa-loop-ivopts.c (get_address_cost): Use proper mode for
>offset.

Re: [PATCH][AArch64] Use std::swap instead of manually swapping in aarch64-ldpstp.md

[Marcus Shawcroft]

On 4 February 2015 at 12:18, Kyrill Tkachov  wrote:
> Hi all,
>
> This patch makes use of std::swap in every peephole2 of aarch64-ldp-stp.md
> instead of manually swapping rtxen.
> No functional change, just a cleanup.
> Bootstrapped and tested on aarch64.
>
> I'm proposing this for next stage1 together with the other AArch64 patch
> that
> moves a couple of places of aarch64.c to use std::swap
> (https://gcc.gnu.org/ml/gcc-patches/2014-11/msg01426.html)
>
> Thanks,
> Kyrill
>
> 2015-02-04  Kyrylo Tkachov  
>
> * config/aarch64/aarch64-ldpstp.md: Use std::swap instead of
> manual swaps in all peepholes.

OK for this and the related one linked above to go in now. /Marcus

Re: [PATCH][AArch64] Add support for -mcpu=cortex-a72

[Marcus Shawcroft]

On 4 February 2015 at 10:35, Matthew Wahab  wrote:
> Hello,
>
> The Cortex-A72 is an ARMv8 core with the same architectural features as the
> Cortex-A57. This patch adds support for the command line option
> -mcpu=cortex-a72 with the same effect as the -mcpu=cortex-a57 option, only
> the name being different. It also adds support for the
> -mcpu=cortex-a72.cortex-a53 big-little variant.
>
> Tested with check-gcc on aarch64-none-linux-gnu with no new failures. Tested
> the new cpu options from the command line.
>
> Matthew
>
> gcc/
> 2015-02-04  Matthew Wahab  
>
> * config/aarch64/aarch64-cores.def: Add cortex-a72 and
> cortex-a72.cortex-a53.
> * config/aarch64/aarch64-tune.md: Regenerate.
> * doc/invoke.texi (AArch64 Options/-mtune): Add "cortex-a72".

Thanks.   Anyone using this new option, -mcpu=cortex-a72, will need to
have a binutils build which includes your related binutils change
(which I just OK'd) because the aarch64 backend in its current form
will inject a .cpu directive into the output .S.  This dependency is a
tad unpleasant.  James G has a patch in the works that will change gcc
behaviour such that we pass through a .arch xxx+feature+feature
directive into GAS which will remove this particular dependency but I
think that change will need to wait for stage-1 now.  This patch is
low risk and I'd like the -mcpu=cortex-a72 recognition support in for
gcc5. OK, commit it.  /Marcus

Re: [PATCH] PR64387

[Uros Bizjak]

On Wed, Feb 4, 2015 at 12:05 PM, Ilya Tocar  wrote:
> I think that fix for avx2 part should be backported to 4.8/4.9
> What do you think?

OK also for branches.

Thanks,
Uros.

Re: [PATCH][AArch64] Add support for -mcpu=cortex-a72

[Ramana Radhakrishnan]

On Wed, Feb 4, 2015 at 12:57 PM, Marcus Shawcroft
 wrote:
> On 4 February 2015 at 10:35, Matthew Wahab  wrote:
>> Hello,
>>
>> The Cortex-A72 is an ARMv8 core with the same architectural features as the
>> Cortex-A57. This patch adds support for the command line option
>> -mcpu=cortex-a72 with the same effect as the -mcpu=cortex-a57 option, only
>> the name being different. It also adds support for the
>> -mcpu=cortex-a72.cortex-a53 big-little variant.
>>
>> Tested with check-gcc on aarch64-none-linux-gnu with no new failures. Tested
>> the new cpu options from the command line.
>>
>> Matthew
>>
>> gcc/
>> 2015-02-04  Matthew Wahab  
>>
>> * config/aarch64/aarch64-cores.def: Add cortex-a72 and
>> cortex-a72.cortex-a53.
>> * config/aarch64/aarch64-tune.md: Regenerate.
>> * doc/invoke.texi (AArch64 Options/-mtune): Add "cortex-a72".
>
> Thanks.   Anyone using this new option, -mcpu=cortex-a72, will need to
> have a binutils build which includes your related binutils change
> (which I just OK'd) because the aarch64 backend in its current form
> will inject a .cpu directive into the output .S.  This dependency is a
> tad unpleasant.  James G has a patch in the works that will change gcc
> behaviour such that we pass through a .arch xxx+feature+feature
> directive into GAS which will remove this particular dependency but I
> think that change will need to wait for stage-1 now.  This patch is
> low risk and I'd like the -mcpu=cortex-a72 recognition support in for
> gcc5. OK, commit it.  /Marcus

That's usual practice these days. If it affects many people an option
might be to backport the basic GAS support into the 2.25 release
branch so that it's available in a release branch.

Ramana

Re: PATCH: PR target/64905: unsigned short is loaded with 4-byte load (movl)

[Uros Bizjak]

On Mon, Feb 2, 2015 at 10:39 PM, H.J. Lu  wrote:
> This patch fixes a long standing bug where aligned_operand ignores
> alignment of memory operand less than 32 bits.  It drops address
> decomposition and returns false if alignment of memory operand less
> is than 32 bits. Tested on Linux/x86-64.   OK for trunk, 4.9 and 4.8
> branches?

Can you please find some references in gcc mainlig lists why and for
what reason is the predicate written in the current way? Are there
some (older?) processors that require this approach, so a tuning flag
should be used here?

OTOH, this is not a regression, so not a stage-4 material.

Uros.

[PATCH, x86] Add TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE hook

[Christian Bruel]

While trying to reduce the PR64835 case for ARM and x86, I noticed that 
the alignment flags are cleared for x86 when attribute optimized is used.


With the attached testcases, the visible effects are twofold :

1) Functions compiled in with attribute optimize (-O2) are not aligned 
as if they were with the -O2 flag.


2) can_inline_edge_p fails because opts_for_fn (caller->decl) != 
opts_for_fn (callee->decl)) even-though they are compiled with the same 
optimization level.


indeed we have:

 The problem is that the alignment flags are not recomputed when setting 
the attribute flags in DECL_FUNCTION_SPECIFIC_OPTIMIZATION. Implementing 
the TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE hook to set them fixes the problem.


NB: TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE is also used to hold options 
from attribute target, so.this patch is a prerequisite to fix PR/64835 
on ARM and x86


bootstrapped, regtested with no new failures for x86_64-unknown-linux-gnu

Comments ? I'd like to candidate this for trunk when stage1 opens again.

Many Thanks

Christian






2015-02-06  Christian Bruel  

	PR target/64835
	* config/i386/i386.c (ix86_default_align): New function.
	(ix86_override_options_after_change): Call ix86_default_align.
	(TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE): New hook.
	(ix86_override_options_after_change): New function.

2015-02-06  Christian Bruel  

	PR target/64835
	* gcc.dg/ipa/iinline-attr.c: New test.
	* gcc.target/i386/iinline-attr-2.c: New test.

Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c	(revision 220394)
+++ gcc/config/i386/i386.c	(working copy)
@@ -3105,6 +3105,35 @@
 }
 
 
+/* Default align_* from the processor table.  */
+
+static void
+ix86_default_align (struct gcc_options *opts)
+{
+  if (opts->x_align_loops == 0)
+{
+  opts->x_align_loops = processor_target_table[ix86_tune].align_loop;
+  align_loops_max_skip = processor_target_table[ix86_tune].align_loop_max_skip;
+}
+  if (opts->x_align_jumps == 0)
+{
+  opts->x_align_jumps = processor_target_table[ix86_tune].align_jump;
+  align_jumps_max_skip = processor_target_table[ix86_tune].align_jump_max_skip;
+}
+  if (opts->x_align_functions == 0)
+{
+  opts->x_align_functions = processor_target_table[ix86_tune].align_func;
+}
+}
+
+/* Implement TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE hook.  */
+
+static void
+ix86_override_options_after_change (void)
+{
+  ix86_default_align (&global_options);
+}
+
 /* Override various settings based on options.  If MAIN_ARGS_P, the
options are from the command line, otherwise they are from
attributes.  */
@@ -3902,20 +3931,7 @@
 opts->x_ix86_regparm = REGPARM_MAX;
 
   /* Default align_* from the processor table.  */
-  if (opts->x_align_loops == 0)
-{
-  opts->x_align_loops = processor_target_table[ix86_tune].align_loop;
-  align_loops_max_skip = processor_target_table[ix86_tune].align_loop_max_skip;
-}
-  if (opts->x_align_jumps == 0)
-{
-  opts->x_align_jumps = processor_target_table[ix86_tune].align_jump;
-  align_jumps_max_skip = processor_target_table[ix86_tune].align_jump_max_skip;
-}
-  if (opts->x_align_functions == 0)
-{
-  opts->x_align_functions = processor_target_table[ix86_tune].align_func;
-}
+  ix86_default_align (opts);
 
   /* Provide default for -mbranch-cost= value.  */
   if (!opts_set->x_ix86_branch_cost)
@@ -51928,6 +51944,9 @@
 #undef TARGET_PROMOTE_FUNCTION_MODE
 #define TARGET_PROMOTE_FUNCTION_MODE ix86_promote_function_mode
 
+#undef  TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE
+#define TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE ix86_override_options_after_change
+
 #undef TARGET_MEMBER_TYPE_FORCES_BLK
 #define TARGET_MEMBER_TYPE_FORCES_BLK ix86_member_type_forces_blk
 
Index: gcc/testsuite/gcc.dg/ipa/iinline-attr.c
===
--- gcc/testsuite/gcc.dg/ipa/iinline-attr.c	(revision 0)
+++ gcc/testsuite/gcc.dg/ipa/iinline-attr.c	(working copy)
@@ -0,0 +1,27 @@
+/* Verify that simple indirect calls are inlined even when
+   attribute __optimize is used.  */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-ipa-inline"  } */
+
+extern void non_existent(int);
+
+static void hooray ()
+{
+  non_existent (1);
+}
+
+__attribute__ ((__optimize__ ("O2")))
+static void hiphip (void (*f)())
+{
+  non_existent (2);
+  f ();
+}
+
+int test (void)
+{
+  hiphip (hooray);
+  return 0;
+}
+
+/* { dg-final { scan-ipa-dump "hooray\[^\\n\]*inline copy in test"  "inline"  } } */
+/* { dg-final { cleanup-ipa-dump "inline" } } */
Index: gcc/testsuite/gcc.target/i386/iinline-attr-2.c
===
--- gcc/testsuite/gcc.target/i386/iinline-attr-2.c	(revision 0)
+++ gcc/testsuite/gcc.target/i386/iinline-attr-2.c	(working copy)
@@ -0,0 +1,29 @@
+/* Verify that alignment flags are set when  attribute __optimize is used.  */
+/* { dg-do comp

Re: [PATCH][ARM] Add support for -mcpu=cortex-a72

[Ramana Radhakrishnan]

On Wed, Feb 4, 2015 at 10:36 AM, Matthew Wahab  wrote:
> Hello,
>
> The Cortex-A72 is an ARMv8 core with the same architectural features as the
> Cortex-A57. This patch adds support for the command line option
> -mcpu=cortex-a72 with the same effect as the -mcpu=cortex-a57 option, with
> only the name being different. It also adds support for the
> -mcpu=cortex-a72.cortex-a53 big-little variant.
>
> Tested with check-gcc for arm-none-linux-gnueabihf. Tested the new cpu
> options from the command line.
>
> Matthew
>
> gcc/
> 2015-02-04  Matthew Wahab  
>
> * config/arm/arm-cores.def: Add cortex-a72 and
> cortex-a72.cortex-a53.
> * config/arm/bpabi.h (BE8_LINK_SPEC): Likewise.
> * config/arm/t-aprofile (MULTILIB_MATCHES): Likewise.
> * config/arm/arm-tune.md: Regenerate.
> * config/arm/arm-tables.opt: Add entries for "cortex-a72" and
> "cortex-a72.cortex-a53".
> * doc/invoke.texi (ARM Options/-mtune): Likewise.


This is OK - it's purely wiring up a new name and treating that the
same as an existing tune. No new functionality and no point in waiting
for a year for this cpu option to be available for folks.

Ramana

Re: [PATCH][ARM] Add support for -mcpu=cortex-a72

[James Greenhalgh]

On Wed, Feb 04, 2015 at 01:23:06PM +, Ramana Radhakrishnan wrote:
> On Wed, Feb 4, 2015 at 10:36 AM, Matthew Wahab  wrote:
> > Hello,
> >
> > The Cortex-A72 is an ARMv8 core with the same architectural features as the
> > Cortex-A57. This patch adds support for the command line option
> > -mcpu=cortex-a72 with the same effect as the -mcpu=cortex-a57 option, with
> > only the name being different. It also adds support for the
> > -mcpu=cortex-a72.cortex-a53 big-little variant.
> >
> > Tested with check-gcc for arm-none-linux-gnueabihf. Tested the new cpu
> > options from the command line.
> >
> > Matthew
> >
> > gcc/
> > 2015-02-04  Matthew Wahab  
> >
> > * config/arm/arm-cores.def: Add cortex-a72 and
> > cortex-a72.cortex-a53.
> > * config/arm/bpabi.h (BE8_LINK_SPEC): Likewise.
> > * config/arm/t-aprofile (MULTILIB_MATCHES): Likewise.
> > * config/arm/arm-tune.md: Regenerate.
> > * config/arm/arm-tables.opt: Add entries for "cortex-a72" and
> > "cortex-a72.cortex-a53".
> > * doc/invoke.texi (ARM Options/-mtune): Likewise.
> 
> 
> This is OK - it's purely wiring up a new name and treating that the
> same as an existing tune. No new functionality and no point in waiting
> for a year for this cpu option to be available for folks.

On Matthew's (offline) request, I've installed this as r220399 with the
following minor change:

> +@samp{cortex-a15.cortex-a7}, @samp{cortex-a57.cortex-a53}, 
> @samp{cortex-a72.cortex-a53}.

Split this long line:

> +@samp{cortex-a15.cortex-a7}, @samp{cortex-a57.cortex-a53},
> +@samp{cortex-a72.cortex-a53}.

As so.

Cheers,
James

Re: [PATCH][AArch64] Add support for -mcpu=cortex-a72

[James Greenhalgh]

On Wed, Feb 04, 2015 at 12:57:11PM +, Marcus Shawcroft wrote:
> On 4 February 2015 at 10:35, Matthew Wahab  wrote:
> > Hello,
> >
> > The Cortex-A72 is an ARMv8 core with the same architectural features as the
> > Cortex-A57. This patch adds support for the command line option
> > -mcpu=cortex-a72 with the same effect as the -mcpu=cortex-a57 option, only
> > the name being different. It also adds support for the
> > -mcpu=cortex-a72.cortex-a53 big-little variant.
> >
> > Tested with check-gcc on aarch64-none-linux-gnu with no new failures. Tested
> > the new cpu options from the command line.
> >
> > Matthew
> >
> > gcc/
> > 2015-02-04  Matthew Wahab  
> >
> > * config/aarch64/aarch64-cores.def: Add cortex-a72 and
> > cortex-a72.cortex-a53.
> > * config/aarch64/aarch64-tune.md: Regenerate.
> > * doc/invoke.texi (AArch64 Options/-mtune): Add "cortex-a72".
> 
> Thanks.   Anyone using this new option, -mcpu=cortex-a72, will need to
> have a binutils build which includes your related binutils change
> (which I just OK'd) because the aarch64 backend in its current form
> will inject a .cpu directive into the output .S.  This dependency is a
> tad unpleasant.  James G has a patch in the works that will change gcc
> behaviour such that we pass through a .arch xxx+feature+feature
> directive into GAS which will remove this particular dependency but I
> think that change will need to wait for stage-1 now.  This patch is
> low risk and I'd like the -mcpu=cortex-a72 recognition support in for
> gcc5. OK, commit it.  /Marcus

Can you also make sure that support for Cortex-A72 gets a mention
(with the caveat above I should think) in the GCC 5.0 changes
(htdocs/gcc-5/changes.html).

Cheers,
James

Commit: FR30: Fix di_operand and nonimmediate_di_operand predicates

[Nick Clifton]

Hi Guys,

  I am checking in the patch below to add SUBREG to the list of rtx
  codes accepted by the di_operand and nonimmediate_di_operand
  predicates in the FR30 backend.  This should resolve PR 64408.

Cheers
  Nick

gcc/ChangeLog
2015-02-04  Nick Clifton  

PR target/64408
* config/fr30/predicates.md (di_operand): Add SUBREG to the list
of accepted codes.
(nonimmediate_di_operand): Likewise.

Index: gcc/config/fr30/predicates.md
===
--- gcc/config/fr30/predicates.md   (revision 220398)
+++ gcc/config/fr30/predicates.md   (working copy)
@@ -64,7 +64,7 @@
 ;; Returns TRUE if OP is a valid operand of a DImode operation.
 
 (define_predicate "di_operand"
-  (match_code "const_int,const_double,reg,mem")
+  (match_code "const_int,const_double,reg,subreg,mem")
 {
   if (register_operand (op, mode))
 return TRUE;
@@ -92,7 +92,7 @@
 ;; Returns TRUE if OP is a DImode register or MEM.
 
 (define_predicate "nonimmediate_di_operand"
-  (match_code "reg,mem")
+  (match_code "reg,subreg,mem")
 {
   if (register_operand (op, mode))
 return TRUE;

Re: [PATCH][ARM] Add support for -mcpu=cortex-a72

[Kyrill Tkachov]

On 04/02/15 13:37, James Greenhalgh wrote:

On Wed, Feb 04, 2015 at 01:23:06PM +, Ramana Radhakrishnan wrote:

On Wed, Feb 4, 2015 at 10:36 AM, Matthew Wahab  wrote:

Hello,

The Cortex-A72 is an ARMv8 core with the same architectural features as the
Cortex-A57. This patch adds support for the command line option
-mcpu=cortex-a72 with the same effect as the -mcpu=cortex-a57 option, with
only the name being different. It also adds support for the
-mcpu=cortex-a72.cortex-a53 big-little variant.

Tested with check-gcc for arm-none-linux-gnueabihf. Tested the new cpu
options from the command line.

Matthew

gcc/
2015-02-04  Matthew Wahab  

 * config/arm/arm-cores.def: Add cortex-a72 and
 cortex-a72.cortex-a53.
 * config/arm/bpabi.h (BE8_LINK_SPEC): Likewise.
 * config/arm/t-aprofile (MULTILIB_MATCHES): Likewise.
 * config/arm/arm-tune.md: Regenerate.
 * config/arm/arm-tables.opt: Add entries for "cortex-a72" and
 "cortex-a72.cortex-a53".
 * doc/invoke.texi (ARM Options/-mtune): Likewise.


This is OK - it's purely wiring up a new name and treating that the
same as an existing tune. No new functionality and no point in waiting
for a year for this cpu option to be available for folks.

On Matthew's (offline) request, I've installed this as r220399 with the
following minor change:


I guess we now need the wwwdocs changes.html update for arm and aarch64 
to let users know.


Kyrill




+@samp{cortex-a15.cortex-a7}, @samp{cortex-a57.cortex-a53}, 
@samp{cortex-a72.cortex-a53}.

Split this long line:


+@samp{cortex-a15.cortex-a7}, @samp{cortex-a57.cortex-a53},
+@samp{cortex-a72.cortex-a53}.

As so.

Cheers,
James

Re: PATCH: PR target/64905: unsigned short is loaded with 4-byte load (movl)

[Uros Bizjak]

On Wed, Feb 4, 2015 at 2:21 PM, Uros Bizjak  wrote:
> On Mon, Feb 2, 2015 at 10:39 PM, H.J. Lu  wrote:
>> This patch fixes a long standing bug where aligned_operand ignores
>> alignment of memory operand less than 32 bits.  It drops address
>> decomposition and returns false if alignment of memory operand less
>> is than 32 bits. Tested on Linux/x86-64.   OK for trunk, 4.9 and 4.8
>> branches?
>
> Can you please find some references in gcc mainlig lists why and for
> what reason is the predicate written in the current way? Are there
> some (older?) processors that require this approach, so a tuning flag
> should be used here?

After some more thinking, it looks the failure is due to:

emit-rtl.c:  REGNO_POINTER_ALIGN (HARD_FRAME_POINTER_REGNUM) = STACK_BOUNDARY;

The testcase forces the pointer to %rbp (== HARD_FRAME_POINTER_REGNUM
in the above line), so the predicate thinks that the value is aligned,
since %rbp has its REGNO_POINTER_ALIGN set to STACK_BOUNDARY.

Looks like generic RTL infrastructure problem to me, the
REGNO_POINTER_ALIGNMENT of hard_frame_pointer should be cleared when
H_F_P is omitted and reused.

Please let's move discussion back to the PR.

Adding CC.

Uros.

Re: [PATCH] testsuite: Do not xfail guality/pr{41447,41616}-1.c

[Segher Boessenkool]

On Wed, Feb 04, 2015 at 12:55:55PM +0100, Jakub Jelinek wrote:
> On Wed, Feb 04, 2015 at 03:48:38AM -0800, Segher Boessenkool wrote:
> > These testcases currently XPASS on most targets and configs, so let's
> > reduce the noise.  Okay for mainline?
> 
> Doesn't look like that is the case.  obj69 is x86_64, obj70 is i686.
> grep '\(41447\|41616\).*execution' obj{69,70}/gcc/testsuite/gcc/gcc.sum
> obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O0  
> execution test
> obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O1  
> execution test
> obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O2  
> execution test
> obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O2 -flto 
> -fno-use-linker-plugin -flto-partition=none  execution test
> obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O2 -flto 
> -fuse-linker-plugin -fno-fat-lto-objects  execution test
> obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O3 
> -fomit-frame-pointer  execution test
> obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O3 -g  
> execution test
> obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -Os  
> execution test
> obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O0  
> execution test
> obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O1  
> execution test
> obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O2  
> execution test
> obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O2 -flto 
> -fno-use-linker-plugin -flto-partition=none  execution test
> obj69/gcc/testsuite/gcc/gcc.sum:XFAIL: gcc.dg/guality/pr41616-1.c   -O2 -flto 
> -fuse-linker-plugin -fno-fat-lto-objects  execution test
> obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O3 
> -fomit-frame-pointer  execution test
> obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O3 -g  
> execution test
> obj69/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -Os  
> execution test

x86_64, 41447 everything passes; 41616 one fail (the one with linker plugin).
This is the situation on most targets (on some there are no fails; on ia64
41447 has one fail, 41616 has five fails).

> obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O0  
> execution test
> obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -O1  
> execution test
> obj70/gcc/testsuite/gcc/gcc.sum:XFAIL: gcc.dg/guality/pr41447-1.c   -O2  
> execution test
> obj70/gcc/testsuite/gcc/gcc.sum:XFAIL: gcc.dg/guality/pr41447-1.c   -O2 -flto 
>  execution test
> obj70/gcc/testsuite/gcc/gcc.sum:XFAIL: gcc.dg/guality/pr41447-1.c   -O2 -flto 
> -flto-partition=none  execution test
> obj70/gcc/testsuite/gcc/gcc.sum:XFAIL: gcc.dg/guality/pr41447-1.c   -O3 
> -fomit-frame-pointer  execution test
> obj70/gcc/testsuite/gcc/gcc.sum:XFAIL: gcc.dg/guality/pr41447-1.c   -O3 -g  
> execution test
> obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41447-1.c   -Os  
> execution test
> obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O0  
> execution test
> obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O1  
> execution test
> obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O2  
> execution test
> obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O2 -flto 
>  execution test
> obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O2 -flto 
> -flto-partition=none  execution test
> obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O3 
> -fomit-frame-pointer  execution test
> obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -O3 -g  
> execution test
> obj70/gcc/testsuite/gcc/gcc.sum:XPASS: gcc.dg/guality/pr41616-1.c   -Os  
> execution test

On a native i686 there are only four fails (the one with linker plugin works).

> At least pr41447 on i686...
> So I'm not sure if this patch would not do more harm than good.

i686 with linker plugin is 4/4 pass/fail, without it is 3/5.  Everything else
(on gcc-testresults) is 8/0 (except ia64 -- does anyone care?)

I can xfail 41447 for ia32 if you want?  The change for 41616 is good for
everything IMO -- at least we then *see* there is one FAIL :-)


Segher

Re: [Patch, fortran] PR 64757 - [5 Regression] ICE in fold_convert_loc, at fold-const.c:2353

[Paul Richard Thomas]

Dear All,

Please find attached a reworked version of the patch for this PR. I
have no idea at all, why the original version worked for array
components on my laptop. In this version, the treatment of scalar and
array components is cleanly separated.

Bootstrapped and regtested on FC21/x86_64. OK for trunk?

Paul

2015-02-04  Paul Thomas  

PR fortran/640757
* resolve.c (resolve_structure_cons): Obtain the rank of class
components.
* trans-expr.c (gfc_trans_alloc_subarray_assign): Do the
assignment to allocatable class array components.
(alloc_scalar_allocatable_for_subcomponent_assignment): If comp
is a class component, allocate to the _data field.
(gfc_trans_subcomponent_assign): If a class component with a
derived type expression set the _vptr field and for array
components, call gfc_trans_alloc_subarray_assign. For scalars,
the assignment is performed here.

2015-02-04  Paul Thomas  

PR fortran/640757
* gfortran.dg/type_to_class_2.f90: New test
* gfortran.dg/type_to_class_3.f90: New test

On 3 February 2015 at 22:36, Paul Richard Thomas
 wrote:
> Dear Dominique,
>
> I have fixed all the problems except the last one. For that case, the
> other brand gives
> type_to_class_30.f90(19): error #7822: Variables containing ultimate
> allocatable array components are forbidden from appearing directly in
> input/output lists.
> print *, TestReference([Test(99), Test(199)])
> -^
> compilation aborted for type_to_class_30.f90 (code 1)
>
> which seems to me to be correct. I'll see what I can do to fix it.
>
> Thanks for the help
>
> Paul
>
> On 2 February 2015 at 17:53, Dominique Dhumieres  wrote:
>> Dear Paul,
>>
>> I have tested your patch at 
>> https://gcc.gnu.org/ml/fortran/2015-01/txtwnaoa1115V.txt
>> (the latest version) and I found that the test type_to_class_3.f03 is 
>> miscompiled
>> (FAIL) with -flto -O0 -m64 (this does not happens with -flto -O0 -m32 or 
>> with -Ox and
>> x!=0).
>>
>> In addition, while the reduced test
>>
>>   type :: Test
>> integer :: i
>>   end type
>>
>>   type :: TestReference
>>  class(Test), allocatable :: test(:)
>>   end type
>>
>>   type(TestReference) :: testList
>>   type(test), allocatable :: x(:)
>>
>>  allocate (testList%test(2), source = [Test(99), Test(199)]) ! Works, of 
>> course
>>  print *, size(testList%test)
>>  x = testList%test
>>  print *, x
>> end
>>
>> gives what I expect, i.e.,
>>
>>2
>>   99 199
>>
>>   type :: Test
>> integer :: i
>>   end type
>>
>>   type :: TestReference
>>  class(Test), allocatable :: test(:)
>>   end type
>>
>>   type(TestReference) :: testList
>>   type(test), allocatable :: x(:)
>>
>>   testList = TestReference([Test(99), Test(199)])  ! Gave: The rank of the 
>> element in the
>>! structure constructor 
>> at (1) does not
>>! match that of the 
>> component (1/0)
>>   print *, size(testList%test)
>>   x = testList%test
>>   print *, x
>> end
>>
>> gives
>>
>>1
>>   99
>>
>> Last problem I see,
>>
>> print *, TestReference([Test(99), Test(199)])
>>
>> gives the following ICE
>>
>> f951: internal compiler error: Bad IO basetype (7)
>>
>> type_to_class_3_red_2.f03:12:0:
>>
>>print *, TestReference([Test(99), Test(199)])
>>
>>
>> Cheers,
>>
>> Dominique
>
>
>
> --
> Outside of a dog, a book is a man's best friend. Inside of a dog it's
> too dark to read.
>
> Groucho Marx



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c   (revision 220305)
--- gcc/fortran/resolve.c   (working copy)
*** resolve_structure_cons (gfc_expr *expr,
*** 1155,1160 
--- 1155,1163 
}
  
rank = comp->as ? comp->as->rank : 0;
+   if (comp->ts.type == BT_CLASS && CLASS_DATA (comp)->as)
+   rank = CLASS_DATA (comp)->as->rank;
+ 
if (cons->expr->expr_type != EXPR_NULL && rank != cons->expr->rank
  && (comp->attr.allocatable || cons->expr->rank))
{
Index: gcc/fortran/trans-expr.c
===
*** gcc/fortran/trans-expr.c(revision 220305)
--- gcc/fortran/trans-expr.c(working copy)
*** gfc_trans_alloc_subarray_assign (tree de
*** 6211,6216 
--- 6211,6230 
  tmp = gfc_copy_alloc_comp (cm->ts.u.derived,
   se.expr, dest,
   cm->as->rank);
+   else if (cm->ts.type == BT_CLASS && expr->ts.type == BT_DERIVED
+  && CLASS_DATA(cm)->attr.allocatable)
+ {
+   if (cm->ts.u.derived->attr.alloc_comp)
+   tmp = gfc_copy_alloc_comp (expr->ts.u.derived,
+  se.expr, dest,
+  e

[PATCH, committed] jit: fix typo in docs

[David Malcolm]

Fix for a trivial but confusing typo in the jit docs.

Committed to trunk as r220408.

gcc/jit/ChangeLog:
* docs/topics/contexts.rst (gcc_jit_context_acquire): Fix
typo.
* docs/_build/texinfo/libgccjit.texi: Regenerate.

---
 gcc/jit/docs/topics/contexts.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/jit/docs/topics/contexts.rst b/gcc/jit/docs/topics/contexts.rst
index cc52077..46a08bd 100644
--- a/gcc/jit/docs/topics/contexts.rst
+++ b/gcc/jit/docs/topics/contexts.rst
@@ -39,7 +39,7 @@ cleanup of such objects is done for you when the context is 
released.
 
 .. function:: gcc_jit_context *gcc_jit_context_acquire (void)
 
-  This function acquires a new :c:type:`gcc_jit_object *` instance,
+  This function acquires a new :c:type:`gcc_jit_context *` instance,
   which is independent of any others that may be present within this
   process.
 
-- 
1.8.5.3

Re: Merge current set of OpenACC changes from gomp-4_0-branch

[Julian Brown]

On Tue, 3 Feb 2015 23:01:04 +0300
Ilya Verbin  wrote:

> On 03 Feb 13:00, Julian Brown wrote:
> > On Tue, 3 Feb 2015 14:28:44 +0300
> > Ilya Verbin  wrote:
> > > On 27 Jan 14:07, Julian Brown wrote:
> > > > On Mon, 26 Jan 2015 17:34:26 +0300
> > > > Ilya Verbin  wrote:
> > > > > Here is my current patch, it works for OpenMP->MIC, but
> > > > > obviously will not work for PTX, since it requires
> > > > > symmetrical changes in the plugin.  Could you please take a
> > > > > look, whether it is possible to support this new interface in
> > > > > PTX plugin?
> > > > 
> > > > I think it can probably be made to work. I'll have a look in
> > > > more detail.
> > > 
> > > Do you have any progress on this?
> > 
> > I'm still working on a patch to update OpenACC support and the PTX
> > backend to use load/unload_image and to unify
> > initialisation/"opening". So far I think the answer is basically
> > "yes, the new interface can be supported", though I might request a
> > minor tweak -- e.g. that load_image takes an extra "void **"
> > argument so that a libgomp backend can allocate a block of generic
> > metadata relating to the image, then that same block would be
> > passed (void *) to the unload hook so the backend can use it there
> > and deallocate it when it's finished with.
> > 
> > Would that be possible? (It'd mostly be for a "CUmodule" handle:
> > this could be stashed away somewhere within the nvptx backend, but
> > it might be neater to put it in generic code since it'll probably
> > be useful for other backends anyway.)
> 
> An extra argument is not a problem, however I don't quite get the
> idea. PTX plugin allocates some data while loading, and needs this
> data while unloading?  Then why not to create a hash table with
> image_ptr -> metadata mapping inside the plugin? [...]

Right -- that's what I meant by "could be stashed away somewhere within
the nvptx backend". I just thought that retaining a generic chunk of
state for each (JIT-compiled, in this case) block of code might be
something that would be useful for other targets too. I've kept
the required information (for now at least) within the nvptx backend as
an associative list.

This (WIP) patch is based on top of a version of your patch that I
merged to our internal branch: that's still the easiest way for me to
test the PTX backend (with unloading support) at present, and it passes
libgomp testing that way. Trunk should be fairly close, but I haven't
tried applying it there yet.

The major changes are:

* The removal of the OpenACC-specific plugin hooks open_device,
  close_device, set_device_num and get_device_num. The functionality
  has been moved into the init/fini hooks (for the first two) or moved
  into the target-independent OpenACC parts, respectively.

* The PTX mkoffload utility has been extended to support variables as
  well as function mapping, to fill out support for the load/unload
  image hooks. (Not really tested so far!)

* The plugin hooks that are shared between OpenMP and OpenACC now
  support the "device number" argument properly: that should help with
  (eventually) unifying the plugin interface for the two APIs. (With
  set_device_num and get_device_num removed, the plugin is "stateless"
  with respect to which device is currently active. The rest of the
  OpenACC hooks -- async functions, etc. -- should probably be changed
  to take a device number argument too, but that could be a follow-on
  patch.)

* The limitation of having only one type of device active simultaneously
  in the OpenACC runtime has (theoretically!) been removed.

Thoughts?

Thanks,

Julian

ChangeLog

gcc/
* config/nvptx/mkoffload.c (process): Support variable mapping.

libgomp/
* libgomp.h (acc_dispatch_t): Remove open_device_func,
close_device_func, get_device_num_func, set_device_num_func,
target_data members. Change create_thread_data_func argument to
device number instead of generic pointer.
* oacc-async.c (assert.h): Include.
(acc_async_test, acc_async_test_all, acc_wait, acc_wait_async)
(acc_wait_all, acc_wait_all_async): Use current host thread's
active device, not base_dev.
* oacc-cuda.c (acc_get_current_cuda_device)
(acc_get_current_cuda_context, acc_get_cuda_stream)
(acc_set_cuda_stream): Likewise.
* oacc-host.c (host_dispatch): Don't set open_device_func,
close_device_func, get_device_num_func or set_device_num_func.
* oacc-init.c (base_dev, init_key): Remove.
(cached_base_dev): New.
(name_of_acc_device_t): New.
(acc_init_1): Initialise default-numbered device, not zeroth.
(acc_shutdown_1): Close all devices of a given type.
(goacc_destroy_thread): Don't use base_dev.
(lazy_open, lazy_init, lazy_init_and_open): Remove.
(goacc_attach_host_thread_to_device): New.
(acc_init): Reimplement with goacc_attach_host_thread_to_device.
(acc_get_num_devices): Don't use base_dev.
(acc_set_device_type): Reimplement.
(acc_get_device_type

Re: RFA: RL78: Fix gcc testsuite failures

[DJ Delorie]

Ok.

Re: PR lto/64837: lto plugin doesn't call ld_plugin_release_input_file

[Cary Coutant]

>>If you're going to insist on calling the release_input_file API from
>>the claim_file handler, I'm going to have to fix gold to ignore the
>>call to avoid a premature unlock of the object file.
>
> What's the proper solution for not leaking those filedescriptors?

There was a bug in gold where it wasn't unlocking external members of
thin archives that got claimed by the plugin. See PR 15660:

   https://sourceware.org/bugzilla/show_bug.cgi?id=15660

-cary

Re: PR lto/64837: lto plugin doesn't call ld_plugin_release_input_file

[H.J. Lu]

On Wed, Feb 4, 2015 at 7:35 AM, Cary Coutant  wrote:
>>>If you're going to insist on calling the release_input_file API from
>>>the claim_file handler, I'm going to have to fix gold to ignore the
>>>call to avoid a premature unlock of the object file.
>>
>> What's the proper solution for not leaking those filedescriptors?
>
> There was a bug in gold where it wasn't unlocking external members of
> thin archives that got claimed by the plugin. See PR 15660:
>
>https://sourceware.org/bugzilla/show_bug.cgi?id=15660
>

FWIW, ld doesn't have the file descriptor leak since it does

  /* fd belongs to us, not the plugin; but we don't need it.  */
  close (file->fd);

after calling claim_file_handler.  It only works with GCC plug-in
library.  I going to change it:

https://sourceware.org/ml/binutils/2015-02/msg1.html


-- 
H.J.

[PATCH] PR rtl-optimization/64905: Clear hard frame pointer alignment if not needed

[H.J. Lu]

When hard frame pointer isn't needed, the register for hard frame pointer
may be reused.  This patch clears alignment on hard frame pointer if hard
frame pointer isn't needed.  OK for trunk after bootstrap and test on
Linux/x86-64?

Thanks.

H.J.
--
gcc/

PR rtl-optimization/64905
* ira.c (ira_setup_eliminable_regset): Clear hard frame pointer
alignment if it isn't needed.

gcc/testsuite/

PR rtl-optimization/64905
* gcc.target/i386/pr64905.c: New file.
---
 gcc/ira.c   |  2 ++
 gcc/testsuite/gcc.target/i386/pr64905.c | 22 ++
 2 files changed, 24 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr64905.c

diff --git a/gcc/ira.c b/gcc/ira.c
index ea2b69f..a7cf476 100644
--- a/gcc/ira.c
+++ b/gcc/ira.c
@@ -2313,6 +2313,8 @@ ira_setup_eliminable_regset (void)
 
   if (frame_pointer_needed)
 df_set_regs_ever_live (HARD_FRAME_POINTER_REGNUM, true);
+  else
+REGNO_POINTER_ALIGN (HARD_FRAME_POINTER_REGNUM) = 0;
 
   COPY_HARD_REG_SET (ira_no_alloc_regs, no_unit_alloc_regs);
   CLEAR_HARD_REG_SET (eliminable_regset);
diff --git a/gcc/testsuite/gcc.target/i386/pr64905.c 
b/gcc/testsuite/gcc.target/i386/pr64905.c
new file mode 100644
index 000..bc87d85
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr64905.c
@@ -0,0 +1,22 @@
+/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-options "-Os -ffixed-rax -ffixed-rbx -ffixed-rcx -ffixed-rdx 
-ffixed-rdi -ffixed-rsi -ffixed-r8 -ffixed-r9 -ffixed-r10 -ffixed-r11 
-ffixed-r12 -ffixed-r13 -ffixed-r14 -ffixed-r15" } */
+/* { dg-final { scan-assembler-not "movl\[ \t\]0\\(%.*\\), %.*" } } */
+
+typedef unsigned short uint16_t;
+uint16_t a_global;
+
+void __attribute__ ((noinline))
+function (uint16_t **a_p)
+{
+  // unaligned access by address in %rbp: mov0x0(%rbp),%ebp
+  a_global = **a_p;
+}
+
+int main(int argc, char **argv)
+{
+  uint16_t array [4] = { 1, 2, 3, 4 };
+  uint16_t *array_elem_p = &array [3];
+
+  function (&array_elem_p);
+  return 0;
+}
-- 
1.9.3

Re: [PATCH] testsuite: Do not xfail guality/pr{41447,41616}-1.c

[Jakub Jelinek]

On Wed, Feb 04, 2015 at 08:10:35AM -0600, Segher Boessenkool wrote:
> On a native i686 there are only four fails (the one with linker plugin works).

Yeah, I wrap linker because it is 64-bit and thus doesn't support 32-bit
plugins.

> I can xfail 41447 for ia32 if you want?  The change for 41616 is good for
> everything IMO -- at least we then *see* there is one FAIL :-)

Ok, let's go with the patch you've posted as is then.

Jakub

[PATCH][wwwdocs] Document support for Cortex-A72

[Matthew Wahab]

Hello,

This patch documents in gcc-5/changes.html the addition of support for 
the Cortex-A72 to the ARM and the AArch64 backends.


Tested by checking the updated webpage in firefox.

Matthew
Index: htdocs/gcc-5/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.77
diff --unified -r1.77 changes.html
--- htdocs/gcc-5/changes.html	2 Feb 2015 08:49:09 -	1.77
+++ htdocs/gcc-5/changes.html	4 Feb 2015 16:12:32 -
@@ -478,6 +478,11 @@
  Support for the Cavium ThunderX processor is now available through the
 -mcpu=thunderx and -mtune=thunderx options.
  
+ Support for the Cortex-A72 processor has been added through
+   the -mcpu=cortex-a72 option and the big.LITTLE
+   variant -mcpu=cortex-a72.cortex-a53.  Using these options
+   requires a version of GNU binutils that has support for the Cortex-A72.
+ 
  The transitional options -mlra and -mno-lra
have been removed. The AArch64 backend now uses the local register
allocator (LRA) only.
@@ -513,6 +518,11 @@
-mcpu=cortex-a17.cortex-a7  and
-mtune=cortex-a17.cortex-a7 options.
   
+  Support for the Cortex-A72 processor has been added through
+the -mcpu=cortex-a72 option and the big.LITTLE
+variant -mcpu=cortex-a72.cortex-a53.  Using these options
+requires a version of GNU binutils that has support for the Cortex-A72.
+  
The deprecated option -mwords-little-endian
has been removed.
   

[PATCH,WWWDOCS] MIPS changes for GCC 5.0

[Matthew Fortune]

Hi Catherine,

I've made a first pass at writing up the MIPS changes for GCC 5.0.
Could you take a read and see what needs some more work?

Thanks,
Matthew

Index: htdocs/gcc-5/changes.html
 
=== 
 
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v  
 
retrieving revision 1.77
 
diff -r1.77 changes.html
 
562a563,614 
 
> MIPS   
>  
>   
>  
> MIPS Releases 3 and 5 are now directly supported using 
> -mips32r3,
> -mips64r3, -mips32r5 and -mips64r5 instead of relying on the 
> Release
> 2 options.   
>  
> Support for the Imagination P5600 processor has been added using  
>  
> -march=p5600.
>  
>  
> Support for the Cavium Networks Octeon3 processor has been added 
> using 
> -march=octeon3. 
>  
> MIPS Release 6 is now supported using -mips32r6 and -mips64r6   
>  
> .  
>  
> The previous o32 64-bit floating-point register support has been  
>  
> obsoleted and removed.  This was previously enabled using -mfp64
>  
>  which has been re-purposed for the new ABI extensions described   
>  
> below.   
>  
> New o32 ABI extensions have been added to enable software to 
> transition
> away from the original layout of double-precision floating-point 
> registers.
>   
>  
>   The first of these extensions is o32 FPXX which places restrictions 
>  
>   on code-generation to never access the upper 32-bits of 
> double-precision 
>   registers via odd-numbered single-precision registers.  By default the  
>  
>   odd-numbered single-precision registers are not used at all with this   
>  
>   extension.  o32 FPXX code is link compatible with all other o32 
>  
>   double-precision ABI variants and will execute correctly in all 
> hardware 
>   FPU modes.  Enable o32 FPXX using -mabi=32 -mfpxx for  
>  
>   MIPS II onwards.   
>  
>   The second extension is o32 FP64A which requires 64-bit 
>  
>   floating-point registers and places a mandatory restriction on the use 
> of
>   odd-numbered single-precision registers.  o32 FP64A is link compatible  
>  
>   with all other o32 double-precision ABI variants.  Enable o32 FP64A 
>  
>   using -mabi=32 -mfp64 -mno-odd-spreg for MIPS32R2 onwards. 
>  
>  
>  
>   Finally, the o32 FP64 extension which also requires 64-bit  
>  
>   floating-point registers but permits the use of all single-precision
>  
>   registers.  Enable o32 FP64 using -mfp64 for MIPS32R2  
>  
>   onwards.   
>  
>  
>  
> All new ABI variants can be enabled by default using configure time   
>  
> options --with-fp-32=[32|xx|64] and  
>  
> --with(out)-odd-sp-reg-32.  It is strongly recommended that
> all vendors begin to set o32 FPXX as default ABI to be able to run the
> generated code on MIPSR5 cores alongside future MIPS SIMD (MSA) code and
> MIPSR6 cores.
> When using binutils 2.25 GCC will now pass options like
> -msoft-float and -msingle-float to the 
> assembler.
> This change can affect inline assembly code that is built as soft-float 
> but
> contains hard-float instructions.  In such cases the code must be amended
> to use appropriate .set directives to override the global
> assembler options.
>   
>

Re: [PATCH,WWWDOCS] MIPS changes for GCC 5.0

[Andrew Pinski]

On Wed, Feb 4, 2015 at 8:46 AM, Matthew Fortune
 wrote:
> Hi Catherine,
>
> I've made a first pass at writing up the MIPS changes for GCC 5.0.
> Could you take a read and see what needs some more work?

One comment below.


>
> Thanks,
> Matthew
>
> Index: htdocs/gcc-5/changes.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
> retrieving revision 1.77
> diff -r1.77 changes.html
> 562a563,614
>> MIPS
>>   
>> MIPS Releases 3 and 5 are now directly supported using 
>> -mips32r3,
>> -mips64r3, -mips32r5 and -mips64r5 instead of relying on the 
>> Release
>> 2 options.
>> Support for the Imagination P5600 processor has been added using
>> -march=p5600.
>> 
>> Support for the Cavium Networks Octeon3 processor has been added 
>> using
>> -march=octeon3.

We are known as just Cavium now. That is remove the Networks part.

Thanks,
Andrew

>> MIPS Release 6 is now supported using -mips32r6 and -mips64r6
>> .
>> The previous o32 64-bit floating-point register support has been
>> obsoleted and removed.  This was previously enabled using -mfp64
>>  which has been re-purposed for the new ABI extensions described
>> below.
>> New o32 ABI extensions have been added to enable software to 
>> transition
>> away from the original layout of double-precision floating-point 
>> registers.
>> 
>>   The first of these extensions is o32 FPXX which places restrictions
>>   on code-generation to never access the upper 32-bits of 
>> double-precision
>>   registers via odd-numbered single-precision registers.  By default the
>>   odd-numbered single-precision registers are not used at all with this
>>   extension.  o32 FPXX code is link compatible with all other o32
>>   double-precision ABI variants and will execute correctly in all 
>> hardware
>>   FPU modes.  Enable o32 FPXX using -mabi=32 -mfpxx for
>>   MIPS II onwards.
>>   The second extension is o32 FP64A which requires 64-bit
>>   floating-point registers and places a mandatory restriction on the use 
>> of
>>   odd-numbered single-precision registers.  o32 FP64A is link compatible
>>   with all other o32 double-precision ABI variants.  Enable o32 FP64A
>>   using -mabi=32 -mfp64 -mno-odd-spreg for MIPS32R2 onwards.
>>   
>>   Finally, the o32 FP64 extension which also requires 64-bit
>>   floating-point registers but permits the use of all single-precision
>>   registers.  Enable o32 FP64 using -mfp64 for MIPS32R2
>>   onwards.
>> 
>> All new ABI variants can be enabled by default using configure time
>> options --with-fp-32=[32|xx|64] and
>> --with(out)-odd-sp-reg-32.  It is strongly recommended that
>> all vendors begin to set o32 FPXX as default ABI to be able to run the
>> generated code on MIPSR5 cores alongside future MIPS SIMD (MSA) code and
>> MIPSR6 cores.
>> When using binutils 2.25 GCC will now pass options like
>> -msoft-float and -msingle-float to the 
>> assembler.
>> This change can affect inline assembly code that is built as soft-float 
>> but
>> contains hard-float instructions.  In such cases the code must be amended
>> to use appropriate .set directives to override the global
>> assembler options.
>>   
>>

RE: [PATCH,WWWDOCS] MIPS changes for GCC 5.0

[Matthew Fortune]

Andrew Pinski  writes:
> On Wed, Feb 4, 2015 at 8:46 AM, Matthew Fortune
>  wrote:
> > Hi Catherine,
> >
> > I've made a first pass at writing up the MIPS changes for GCC 5.0.
> > Could you take a read and see what needs some more work?
> 
> One comment below.
> 
> >> Support for the Cavium Networks Octeon3 processor has been
> added using
> >> -march=octeon3.
> 
> We are known as just Cavium now. That is remove the Networks part.

My apologies, I meant to cc you directly to check on that entry.

Thanks,
Matthew

> 
> Thanks,
> Andrew
> 
> >> MIPS Release 6 is now supported using -mips32r6 and -
> mips64r6
> >> .
> >> The previous o32 64-bit floating-point register support has
> been
> >> obsoleted and removed.  This was previously enabled using -
> mfp64
> >>  which has been re-purposed for the new ABI extensions
> described
> >> below.
> >> New o32 ABI extensions have been added to enable software to
> transition
> >> away from the original layout of double-precision floating-point
> registers.
> >> 
> >>   The first of these extensions is o32 FPXX which places
> restrictions
> >>   on code-generation to never access the upper 32-bits of double-
> precision
> >>   registers via odd-numbered single-precision registers.  By
> default the
> >>   odd-numbered single-precision registers are not used at all with
> this
> >>   extension.  o32 FPXX code is link compatible with all other o32
> >>   double-precision ABI variants and will execute correctly in all
> hardware
> >>   FPU modes.  Enable o32 FPXX using -mabi=32 -mfpxx
> for
> >>   MIPS II onwards.
> >>   The second extension is o32 FP64A which requires 64-bit
> >>   floating-point registers and places a mandatory restriction on
> the use of
> >>   odd-numbered single-precision registers.  o32 FP64A is link
> compatible
> >>   with all other o32 double-precision ABI variants.  Enable o32
> FP64A
> >>   using -mabi=32 -mfp64 -mno-odd-spreg for MIPS32R2
> onwards.
> >>   
> >>   Finally, the o32 FP64 extension which also requires 64-bit
> >>   floating-point registers but permits the use of all single-
> precision
> >>   registers.  Enable o32 FP64 using -mfp64 for
> MIPS32R2
> >>   onwards.
> >> 
> >> All new ABI variants can be enabled by default using configure time
> >> options --with-fp-32=[32|xx|64] and
> >> --with(out)-odd-sp-reg-32.  It is strongly recommended
> that
> >> all vendors begin to set o32 FPXX as default ABI to be able to run
> the
> >> generated code on MIPSR5 cores alongside future MIPS SIMD (MSA)
> code and
> >> MIPSR6 cores.
> >> When using binutils 2.25 GCC will now pass options like
> >> -msoft-float and -msingle-float to the
> assembler.
> >> This change can affect inline assembly code that is built as soft-
> float but
> >> contains hard-float instructions.  In such cases the code must be
> amended
> >> to use appropriate .set directives to override the
> global
> >> assembler options.
> >>   
> >>

Re: [libobjc] Fix failures on AIX (PR libobjc/63765)

[Mike Stump]

On Feb 4, 2015, at 2:28 AM, Rainer Orth  wrote:
> Rainer Orth  writes:
>>> On Jan 28, 2015, Mike Stump  wrote:
 On Jan 28, 2015, at 2:27 AM, Rainer Orth  
 wrote:
> 
> * Remove the definition of _XOPEN_SOURCE completely.

 I think I prefer this one…

 and there is no hint what host caused him to put the change in
>>> 
>>> The 2005 timeframe suggests it was probably GNU/Linux

>> I'm with Mike here: either we remove the _XOPEN_SOURCE definition now

> It's been a week now since I posted the patches and there's still no
> conclusion which of the two alternatives to install.

Well, my position is the removal of _XOPEN_SOURCE is the right patch.  I’ve not 
seen any substantive disagreement.  I’d post and test that patch.  A build 
person, a libobjc person, a reasonably an affected target person or a global 
person can approve in my book.  I’m not any of them…  If Pinski is happy with 
my approving it, he can weigh in.  I’d be happy to approve it.

Re: [PATCH][wwwdocs] Document support for Cortex-A72

[Gerald Pfeifer]

On Wednesday 2015-02-04 16:19, Matthew Wahab wrote:
This patch documents in gcc-5/changes.html the addition of 
support for the Cortex-A72 to the ARM and the AArch64 backends.


Looks good to me, but you may want to wait a bit for ARMers to 
chime in.  Or go ahead and thing can always be tweaked later.


Gerald

Re: [libobjc] Fix failures on AIX (PR libobjc/63765)

[Andrew Pinski]

On Wed, Feb 4, 2015 at 9:07 AM, Mike Stump  wrote:
> On Feb 4, 2015, at 2:28 AM, Rainer Orth  wrote:
>> Rainer Orth  writes:
 On Jan 28, 2015, Mike Stump  wrote:
> On Jan 28, 2015, at 2:27 AM, Rainer Orth  
> wrote:
>>
>> * Remove the definition of _XOPEN_SOURCE completely.
>
> I think I prefer this one…
>
> and there is no hint what host caused him to put the change in

 The 2005 timeframe suggests it was probably GNU/Linux
>
>>> I'm with Mike here: either we remove the _XOPEN_SOURCE definition now
>
>> It's been a week now since I posted the patches and there's still no
>> conclusion which of the two alternatives to install.
>
> Well, my position is the removal of _XOPEN_SOURCE is the right patch.  I’ve 
> not seen any substantive disagreement.  I’d post and test that patch.  A 
> build person, a libobjc person, a reasonably an affected target person or a 
> global person can approve in my book.  I’m not any of them…  If Pinski is 
> happy with my approving it, he can weigh in.  I’d be happy to approve it.


I am happy with which ever approach is decided as the safest and most portable.

Thanks,
Andrew Pinski

Re: [PATCH 2/4] Add liboffloadmic

[Ilya Verbin]

Hi,

On 12 Dec 11:46, Thomas Schwinge wrote:
> On Tue, 21 Oct 2014 21:20:34 +0400, Ilya Verbin  wrote:
> > This patch contains liboffloadmic library.
> 
> > liboffloadmic/
> > Initial commit.  Imported from upstream:
> > https://www.openmprtl.org/sites/default/files/liboffload_oss.tgz
> > * Makefile.am: New file.
> > * Makefile.in: New file, generated by automake.
> > * aclocal.m4: New file, generated by aclocal.
> > * configure: New file, generated by autoconf.
> > * configure.ac: New file.
> 
> contrib/gcc_update:files_and_dependencies needs to be updated for those
> build machinery files as well as those added in liboffloadmic/plugin/
> later on.

This patch adds rules for liboffloadmic and liboffloadmic/plugin to gcc_update.
OK for trunk?


contrib/
* gcc_update (files_and_dependencies): Add rules for liboffloadmic and
liboffloadmic/plugin.


diff --git a/contrib/gcc_update b/contrib/gcc_update
index 5ba3a05..2df9da4 100755
--- a/contrib/gcc_update
+++ b/contrib/gcc_update
@@ -167,6 +167,12 @@ libvtv/configure: libvtv/configure.ac libvtv/aclocal.m4
 libcilkrts/aclocal.m4: libcilkrts/configure.ac
 libcilkrts/Makefile.in: libcilkrts/Makefile.am
 libcilkrts/configure: libcilkrts/configure.ac
+liboffloadmic/aclocal.m4: liboffloadmic/configure.ac
+liboffloadmic/Makefile.in: liboffloadmic/Makefile.am
+liboffloadmic/configure: liboffloadmic/configure.ac
+liboffloadmic/plugin/aclocal.m4: liboffloadmic/plugin/configure.ac
+liboffloadmic/plugin/Makefile.in: liboffloadmic/plugin/Makefile.am
+liboffloadmic/plugin/configure: liboffloadmic/plugin/configure.ac
 # Top level
 Makefile.in: Makefile.tpl Makefile.def
 configure: configure.ac config/acx.m4


  -- Ilya

Re: [PATCH 2/4] Add liboffloadmic

[Jakub Jelinek]

On Wed, Feb 04, 2015 at 08:44:42PM +0300, Ilya Verbin wrote:
> contrib/
>   * gcc_update (files_and_dependencies): Add rules for liboffloadmic and
>   liboffloadmic/plugin.

Ok, thanks.

Jakub

Re: [patch+7.9] compile: Filter out -fpreprocessed

[Doug Evans]

On Tue, Feb 3, 2015 at 11:10 AM, Mark Wielaard  wrote:
> On Tue, 2015-02-03 at 19:59 +0100, Jan Kratochvil wrote:
>> On Tue, 03 Feb 2015 19:50:40 +0100, Doug Evans wrote:
>> > On Fri, Jan 16, 2015 at 2:42 PM, Jan Kratochvil
>> >  wrote:
>> > > [...]
>> > > It is wrong that gcc puts -fpreprocessed into DW_AT_producer - I may 
>> > > post a gcc
>> > > patch for it.
>> >
>> > I wasn't aware there are now rules for what can and cannot go in 
>> > DW_AT_producer.
>> > DW_AT_producer has gone from being informational to having a formal
>> > spec (in the sense that something will break if, for example, a
>> > particular option is mentioned).
>> > Is this spec written down somewhere? [At least guidelines for what
>> > things may lead to breakage?]
>>
>> No. Do you have a suggestion where to put it? Should it be only a GNU
>> extension or should it be even DWARF-standardized?
>
> The gcc documentation describes it:
> https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html
>
> -grecord-gcc-switches
> This switch causes the command-line options used to invoke the
> compiler that may affect code generation to be appended to the
> DW_AT_producer attribute in DWARF debugging information. The
> options are concatenated with spaces separating them from each
> other and from the compiler version. See also
> -frecord-gcc-switches for another way of storing compiler
> options into the object file. This is the default.
>
> -gno-record-gcc-switches
> Disallow appending command-line options to the DW_AT_producer
> attribute in DWARF debugging information.
>
> So Jan is right that gcc adding -fpreprocessed, which doesn't affect
> code generation, but is a preprocessor option, shouldn't be there.

Thanks.

Still, there's no hint to the reader that things may break if certain rules
are not followed. It still seems like it's for informational purposes for
human readers, with no suggestion that programs use this information too.

[For completeness sake, I'm setting aside the compiler and version string.
That seemed common enough knowledge to not need documentation
as much as this does.  I realize we're now talking about -grecord-gcc-switches,
but this thread was originally about DW_AT_producer in general.]

[PATCH] More fixes for update_web_docs_svn for jit docs (PR jit/64257)

[David Malcolm]

To build the jit docs, we need to use sphinx 1.0 or later; the
0.6.6 in EPEL 6 doesn't support all the directives we need.

The alternate python-sphinx10 in EPEL 6 has 1.0.8:
  python-sphinx10-1.0.8-1.el6.noarch
which is able to build the jit docs, apart from not having the
"pyramid" theme (this theme appears to have been added in 1.1).

Change the theme to "sphinxdoc", which seems to be the most
attractive theme in 1.0.8 (FWIW, it appears that LLVM are using
a custom variant of this sphinx theme for the docs on their
website).

I was able to use these changes to run the jit docs Makefile on
sourceware.org; the generated HTML can be seen at:
https://dmalcolm.fedorapeople.org/gcc/2015-02-04/jit-docs-sphinxdocs/

OK for trunk?

gcc/jit/ChangeLog:
PR jit/64257
* docs/conf.py (html_theme): Change from 'pyramid'
to 'sphinxdoc'.

maintainer-scripts/ChangeLog:
PR jit/64257
* update_web_docs_svn: Update build of jit docs to use EPEL6
variant install of sphinx 1.0.8, rather than 0.6.6.
---
 gcc/jit/docs/conf.py   |  2 +-
 maintainer-scripts/update_web_docs_svn | 18 ++
 2 files changed, 15 insertions(+), 5 deletions(-)

diff --git a/gcc/jit/docs/conf.py b/gcc/jit/docs/conf.py
index 1bdc081..8f4dd8b 100644
--- a/gcc/jit/docs/conf.py
+++ b/gcc/jit/docs/conf.py
@@ -107,7 +107,7 @@ pygments_style = 'sphinx'
 
 # The theme to use for HTML and HTML Help pages.  See the documentation for
 # a list of builtin themes.
-html_theme = 'pyramid'
+html_theme = 'sphinxdoc'
 
 # Theme options are theme-specific and customize the look and feel of a theme
 # further.  For a list of options available for each theme, see the
diff --git a/maintainer-scripts/update_web_docs_svn 
b/maintainer-scripts/update_web_docs_svn
index ac3bae6..e0132dc 100755
--- a/maintainer-scripts/update_web_docs_svn
+++ b/maintainer-scripts/update_web_docs_svn
@@ -166,11 +166,21 @@ for file in $MANUALS; do
 done
 
 # The jit is a special-case, using sphinx rather than texinfo.
-# The jit Makefile uses "sphinx-build".  This is packaged in
-# Fedora and EPEL 6 within "python-sphinx", and in openSUSE
-# within "python-Sphinx".
+# Specifically, the jit docs need sphinx 1.0 or later.
+#
+# The jit/docs Makefile uses the executable $(SPHINXBUILD),
+# defaulting to "sphinx-build".
+#
+# sphinx is packaged in Fedora and EPEL 6 within "python-sphinx",
+# and in openSUSE within "python-Sphinx".
+#
+# For EPEL6, python-sphinx is sphinx 0.6.6, which is missing various
+# directives (e.g. ":c:macro:"), so we need the variant
+# python-sphinx10 package.  The latter installs its executable as:
+#   /usr/bin/sphinx-1.0-build
+# so we need to override SPHINXBUILD with this when invoking "make".
 pushd gcc/gcc/jit/docs
-make html
+make SPHINXBUILD=/usr/bin/sphinx-1.0-build html
 popd
 cp -a gcc/gcc/jit/docs/_build/html jit
 mkdir -p $DOCSDIR/jit
-- 
1.8.5.3

Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations

[Sriraman Tallam]

On Tue, Feb 3, 2015 at 5:16 PM, H.J. Lu  wrote:
> On Tue, Feb 3, 2015 at 2:19 PM, Jakub Jelinek  wrote:
>> On Tue, Feb 03, 2015 at 02:03:14PM -0800, H.J. Lu wrote:
>>> So we aren't SYMBOL_REF_EXTERNAL_P nor
>>> SYMBOL_REF_LOCAL_P.  What do we reference?
>>
>> That is reasonable.  There is no guarantee the extern weak symbol is local,
>> it could very well be non-local.  All that you know about the symbols is
>> that its address is non-NULL in that case.
>>
>
> This may be true for shared library.  But it isn't true for PIE:


Also, gcc and g++ are inconsistent about something even more simple:

$ cat x.c

int a;

int main() {
  printf("%d\n", a);
}

With gcc -fPIE x.c
SYMBOL_REF_LOCAL_P(op0) = false

With g++ -fPIE x.c
SYMBOL_REF_LOCAL_P(op0) = true



Sri


>
> [hjl@gnu-6 copyreloc-3]$ cat x.c
> __attribute__((weak))
> int a;
>
> extern void bar (void);
>
> int main()
> {
>   if (a != 0)
> __builtin_abort();
>   bar ();
>   if (a != 30)
> __builtin_abort();
>   return 0;
> }
> [hjl@gnu-6 copyreloc-3]$ cat bar.c
> int a = -1;
>
> void
> bar ()
> {
>   a = 30;
> }
> [hjl@gnu-6 copyreloc-3]$ make
> gcc -pie -O3 -g -fuse-ld=gold -fpie  -c x.i
> gcc -pie -O3 -g -fuse-ld=gold -fpic-c -o bar.o bar.c
> gcc -pie  -shared -o libbar.so bar.o
> gcc -pie -O3 -g -fuse-ld=gold -o x x.o libbar.so -Wl,-R,.
> ./x
> [hjl@gnu-6 copyreloc-3]$
>
> Even if a common symbol, a, is weak, all references to
> a within PIE is local.
>
> --
> H.J.

Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations

[Jakub Jelinek]

On Wed, Feb 04, 2015 at 10:27:34AM -0800, Sriraman Tallam wrote:
> On Tue, Feb 3, 2015 at 5:16 PM, H.J. Lu  wrote:
> > On Tue, Feb 3, 2015 at 2:19 PM, Jakub Jelinek  wrote:
> >> On Tue, Feb 03, 2015 at 02:03:14PM -0800, H.J. Lu wrote:
> >>> So we aren't SYMBOL_REF_EXTERNAL_P nor
> >>> SYMBOL_REF_LOCAL_P.  What do we reference?
> >>
> >> That is reasonable.  There is no guarantee the extern weak symbol is local,
> >> it could very well be non-local.  All that you know about the symbols is
> >> that its address is non-NULL in that case.
> >>
> >
> > This may be true for shared library.  But it isn't true for PIE:
> 
> 
> Also, gcc and g++ are inconsistent about something even more simple:
> 
> $ cat x.c
> 
> int a;
> 
> int main() {
>   printf("%d\n", a);
> }
> 
> With gcc -fPIE x.c
> SYMBOL_REF_LOCAL_P(op0) = false
> 
> With g++ -fPIE x.c
> SYMBOL_REF_LOCAL_P(op0) = true

Try -fno-common for C and you'll get the same result as in C++.
Common symbols can't be considered SYMBOL_REF_LOCAL_P, they might resolve
to a non-common symbol from different TU.

Jakub

Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations

[H.J. Lu]

On Wed, Feb 4, 2015 at 10:31 AM, Jakub Jelinek  wrote:
> On Wed, Feb 04, 2015 at 10:27:34AM -0800, Sriraman Tallam wrote:
>> On Tue, Feb 3, 2015 at 5:16 PM, H.J. Lu  wrote:
>> > On Tue, Feb 3, 2015 at 2:19 PM, Jakub Jelinek  wrote:
>> >> On Tue, Feb 03, 2015 at 02:03:14PM -0800, H.J. Lu wrote:
>> >>> So we aren't SYMBOL_REF_EXTERNAL_P nor
>> >>> SYMBOL_REF_LOCAL_P.  What do we reference?
>> >>
>> >> That is reasonable.  There is no guarantee the extern weak symbol is 
>> >> local,
>> >> it could very well be non-local.  All that you know about the symbols is
>> >> that its address is non-NULL in that case.
>> >>
>> >
>> > This may be true for shared library.  But it isn't true for PIE:
>>
>>
>> Also, gcc and g++ are inconsistent about something even more simple:
>>
>> $ cat x.c
>>
>> int a;
>>
>> int main() {
>>   printf("%d\n", a);
>> }
>>
>> With gcc -fPIE x.c
>> SYMBOL_REF_LOCAL_P(op0) = false
>>
>> With g++ -fPIE x.c
>> SYMBOL_REF_LOCAL_P(op0) = true
>
> Try -fno-common for C and you'll get the same result as in C++.
> Common symbols can't be considered SYMBOL_REF_LOCAL_P, they might resolve
> to a non-common symbol from different TU.

Common symbol should be resolved locally for PIE.


-- 
H.J.

Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations

[Jakub Jelinek]

On Wed, Feb 04, 2015 at 10:38:48AM -0800, H.J. Lu wrote:
> Common symbol should be resolved locally for PIE.

binds_local_p yes, binds_to_current_def_p no.

Jakub

Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations

[H.J. Lu]

On Wed, Feb 4, 2015 at 10:42 AM, Jakub Jelinek  wrote:
> On Wed, Feb 04, 2015 at 10:38:48AM -0800, H.J. Lu wrote:
>> Common symbol should be resolved locally for PIE.
>
> binds_local_p yes, binds_to_current_def_p no.
>

Is SYMBOL_REF_LOCAL_P set to binds_local_p or
binds_to_current_def_p?


-- 
H.J.

Re: Re: PR39570 (gfortran) cabs and cabsf are named differently on NetBSD 5

[Krister Walfridsson]

Apologies for the slow response.

On Mon, 26 Jan 2015, Kai-Uwe Eckhardt wrote:


according to gcc/MAINTAINERS Jason and Krister are NetBSD
maintainers for GCC and can approve patches like yours, so
let me copy them.

(Should this be applied now, at least the copyright years
need to be adjusted to include 2015.)


Due to the latest changes in tree-core.h and darwin.c I had
to change the patch for netbsd.c as well:


Looks good to me.

   /Krister

Re: [PATCH] More fixes for update_web_docs_svn for jit docs (PR jit/64257)

[Gerald Pfeifer]

On Wednesday 2015-02-04 13:32, David Malcolm wrote:
> OK for trunk?
> 
> gcc/jit/ChangeLog:
>   PR jit/64257
>   * docs/conf.py (html_theme): Change from 'pyramid'
>   to 'sphinxdoc'.
> 
> maintainer-scripts/ChangeLog:
>   PR jit/64257
>   * update_web_docs_svn: Update build of jit docs to use EPEL6
>   variant install of sphinx 1.0.8, rather than 0.6.6.

Yes.

> +# python-sphinx10 package.  The latter installs its executable as:

Here I'd omit the colon, but that is more of a stylistic question
I guess.

Gerald

Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations

[Sriraman Tallam]

On Wed, Feb 4, 2015 at 10:45 AM, H.J. Lu  wrote:
> On Wed, Feb 4, 2015 at 10:42 AM, Jakub Jelinek  wrote:
>> On Wed, Feb 04, 2015 at 10:38:48AM -0800, H.J. Lu wrote:
>>> Common symbol should be resolved locally for PIE.
>>
>> binds_local_p yes, binds_to_current_def_p no.
>>
>
> Is SYMBOL_REF_LOCAL_P set to binds_local_p or
> binds_to_current_def_p?

Looks like binds_local_p:

varasm.c:
void
default_encode_section_info (tree decl, rtx rtl, int first ATTRIBUTE_UNUSED)
{
  ...
  if (targetm.binds_local_p (decl))
flags |= SYMBOL_FLAG_LOCAL;

>
>
> --
> H.J.

Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations

[H.J. Lu]

On Wed, Feb 4, 2015 at 10:51 AM, Sriraman Tallam  wrote:
> On Wed, Feb 4, 2015 at 10:45 AM, H.J. Lu  wrote:
>> On Wed, Feb 4, 2015 at 10:42 AM, Jakub Jelinek  wrote:
>>> On Wed, Feb 04, 2015 at 10:38:48AM -0800, H.J. Lu wrote:
 Common symbol should be resolved locally for PIE.
>>>
>>> binds_local_p yes, binds_to_current_def_p no.
>>>
>>
>> Is SYMBOL_REF_LOCAL_P set to binds_local_p or
>> binds_to_current_def_p?
>
> Looks like binds_local_p:
>
> varasm.c:
> void
> default_encode_section_info (tree decl, rtx rtl, int first ATTRIBUTE_UNUSED)
> {
>   ...
>   if (targetm.binds_local_p (decl))
> flags |= SYMBOL_FLAG_LOCAL;
>

Why is SYMBOL_REF_LOCAL_P false?


-- 
H.J.

Re: [PATCH] More fixes for update_web_docs_svn for jit docs (PR jit/64257)

[David Malcolm]

On Wed, 2015-02-04 at 19:47 +0100, Gerald Pfeifer wrote:
> On Wednesday 2015-02-04 13:32, David Malcolm wrote:
> > OK for trunk?
> > 
> > gcc/jit/ChangeLog:
> > PR jit/64257
> > * docs/conf.py (html_theme): Change from 'pyramid'
> > to 'sphinxdoc'.
> > 
> > maintainer-scripts/ChangeLog:
> > PR jit/64257
> > * update_web_docs_svn: Update build of jit docs to use EPEL6
> > variant install of sphinx 1.0.8, rather than 0.6.6.
> 
> Yes.
> 
> > +# python-sphinx10 package.  The latter installs its executable as:
> 
> Here I'd omit the colon, but that is more of a stylistic question
> I guess.

Thanks. I've committed it to svn trunk as r220412, omitting the colon.

Gerald: Please can you do the "svn up" on the relevant machine again, so
that it gets the updated "update_web_docs_svn"?

Hopefully this will fix the cronjob...

Dave

Re: [PATCH] PR rtl-optimization/64905: Clear hard frame pointer alignment if not needed

[Vladimir Makarov]

On 2015-02-04 11:16 AM, H.J. Lu wrote:

When hard frame pointer isn't needed, the register for hard frame pointer
may be reused.  This patch clears alignment on hard frame pointer if hard
frame pointer isn't needed.  OK for trunk after bootstrap and test on
Linux/x86-64?
LRA can set up frame_pointer_needed in some complicated cases (in 
lra-eliminations.c::setup_can_eliminate).  So I'd reset 
REGNO_POINTER_ALIGN in setup_can_eleminate for any case even although 
without the change the patch is safe.


So, H.J., if you add resetting REGNO_POINTER_ALIGN in 
setup_can_eliminate, the patch is automatically approved.

Thanks.

H.J.
--
gcc/

PR rtl-optimization/64905
* ira.c (ira_setup_eliminable_regset): Clear hard frame pointer
alignment if it isn't needed.

gcc/testsuite/

PR rtl-optimization/64905
* gcc.target/i386/pr64905.c: New file.
---
  gcc/ira.c   |  2 ++
  gcc/testsuite/gcc.target/i386/pr64905.c | 22 ++
  2 files changed, 24 insertions(+)
  create mode 100644 gcc/testsuite/gcc.target/i386/pr64905.c

Patch ping

[Jakub Jelinek]

Hi!

I'd like to ping 2 patches:

http://gcc.gnu.org/ml/gcc-patches/2015-01/msg02530.html
  - P2 - PR61925 - fix x86 #pragma GCC target handling

http://gcc.gnu.org/ml/gcc-patches/2015-01/msg02432.html
  - emit DW_LANG_Fortran{03,08} for -gdwarf-5

Jakub

Re: [PATCH] PR rtl-optimization/64905: Clear hard frame pointer alignment if not needed

[H.J. Lu]

On Wed, Feb 4, 2015 at 11:20 AM, Vladimir Makarov  wrote:
>
> On 2015-02-04 11:16 AM, H.J. Lu wrote:
>>
>> When hard frame pointer isn't needed, the register for hard frame pointer
>> may be reused.  This patch clears alignment on hard frame pointer if hard
>> frame pointer isn't needed.  OK for trunk after bootstrap and test on
>> Linux/x86-64?
>
> LRA can set up frame_pointer_needed in some complicated cases (in
> lra-eliminations.c::setup_can_eliminate).  So I'd reset REGNO_POINTER_ALIGN
> in setup_can_eleminate for any case even although without the change the
> patch is safe.
>
> So, H.J., if you add resetting REGNO_POINTER_ALIGN in setup_can_eliminate,
> the patch is automatically approved.

This is what I checked in.

Thanks.

-- 
H.J.
---
When hard frame pointer isn't needed, the register for hard frame pointer
may be reused.  This patch clears alignment on hard frame pointer if hard
frame pointer isn't needed.

gcc/

PR rtl-optimization/64905
* lra-eliminations.c (setup_can_eliminate): Clear hard frame
pointer alignment if it isn't needed.

gcc/testsuite/

PR rtl-optimization/64905
* gcc.target/i386/pr64905.c: New file.
---
 gcc/lra-eliminations.c  |  2 ++
 gcc/testsuite/gcc.target/i386/pr64905.c | 22 ++
 2 files changed, 24 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/i386/pr64905.c

diff --git a/gcc/lra-eliminations.c b/gcc/lra-eliminations.c
index fe05a1f..64eec4a 100644
--- a/gcc/lra-eliminations.c
+++ b/gcc/lra-eliminations.c
@@ -182,6 +182,8 @@ setup_can_eliminate (struct lra_elim_table *ep, bool value)
   if (! value
   && ep->from == FRAME_POINTER_REGNUM && ep->to == STACK_POINTER_REGNUM)
 frame_pointer_needed = 1;
+  if (!frame_pointer_needed)
+REGNO_POINTER_ALIGN (HARD_FRAME_POINTER_REGNUM) = 0;
 }

 /* Map: eliminable "from" register -> its current elimination,
diff --git a/gcc/testsuite/gcc.target/i386/pr64905.c
b/gcc/testsuite/gcc.target/i386/pr64905.c
new file mode 100644
index 000..bc87d85
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr64905.c
@@ -0,0 +1,22 @@
+/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-options "-Os -ffixed-rax -ffixed-rbx -ffixed-rcx -ffixed-rdx
-ffixed-rdi -ffixed-rsi -ffixed-r8 -ffixed-r9 -ffixed-r10 -ffixed-r11
-ffixed-r12 -ffixed-r13 -ffixed-r14 -ffixed-r15" } */
+/* { dg-final { scan-assembler-not "movl\[ \t\]0\\(%.*\\), %.*" } } */
+
+typedef unsigned short uint16_t;
+uint16_t a_global;
+
+void __attribute__ ((noinline))
+function (uint16_t **a_p)
+{
+  // unaligned access by address in %rbp: mov0x0(%rbp),%ebp
+  a_global = **a_p;
+}
+
+int main(int argc, char **argv)
+{
+  uint16_t array [4] = { 1, 2, 3, 4 };
+  uint16_t *array_elem_p = &array [3];
+
+  function (&array_elem_p);
+  return 0;
+}
--

Remove parameters after converting call to gcc_unreachable

[Jan Hubicka]

Hi,
this is second attempt to fix the issue with arguments being passed
to builtlin_unreachable after 
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01025.html

As suggested, I fixup the IL right after redirection instead waiting for 
tree-ssa-dce.

Bootstrapped/regtested x86_64-linux, OK?
PR middle-end/64922
* gimple.c: Include gimple-ssa.h
(maybe_remove_unused_call_args): New function.
* gimple.h (maybe_remove_unused_call_args): Declare.
* craph.c (cgraph_edge::redirect_call_stmt_to_callee): Use it.
* tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): Likewise.
* gimple-fold.c (gimple_fold_call): Likewise.
Index: gimple.c
===
--- gimple.c(revision 220411)
+++ gimple.c(working copy)
@@ -67,6 +67,7 @@ along with GCC; see the file COPYING3.
 #include "ipa-ref.h"
 #include "lto-streamer.h"
 #include "cgraph.h"
+#include "gimple-ssa.h"
 
 
 /* All the tuples have their operand vector (if present) at the very bottom
@@ -2950,3 +2951,20 @@ gimple_seq_discard (gimple_seq seq)
   ggc_free (stmt);
 }
 }
+
+/* See if STMT now calls function that takes no parameters and if so, drop
+   call arguments.  This is used when devirtualization machinery redirects
+   to __builtiln_unreacahble or __cfa_pure_virutal.  */
+
+void
+maybe_remove_unused_call_args (struct function *fn, gimple stmt)
+{
+  tree decl = gimple_call_fndecl (stmt);
+  if (TYPE_ARG_TYPES (TREE_TYPE (decl))
+  && TREE_VALUE (TYPE_ARG_TYPES (TREE_TYPE (decl))) == void_type_node
+  && gimple_call_num_args (stmt))
+{
+  gimple_set_num_ops (stmt, 3);
+  update_stmt_fn (fn, stmt);
+}
+}
Index: gimple.h
===
--- gimple.h(revision 220411)
+++ gimple.h(working copy)
@@ -1404,6 +1404,7 @@ extern void sort_case_labels (vec)
 extern void preprocess_case_label_vec_for_gimple (vec, tree, tree *);
 extern void gimple_seq_set_location (gimple_seq, location_t);
 extern void gimple_seq_discard (gimple_seq);
+extern void maybe_remove_unused_call_args (struct function *, gimple);
 
 /* Formal (expression) temporary table handling: multiple occurrences of
the same scalar expression are evaluated into the same temporary.  */
Index: cgraph.c
===
--- cgraph.c(revision 220411)
+++ cgraph.c(working copy)
@@ -1324,7 +1324,8 @@ cgraph_edge::redirect_call_stmt_to_calle
 (int64_t)e->count);
  gcc_assert (e2->speculative);
  push_cfun (DECL_STRUCT_FUNCTION (e->caller->decl));
- new_stmt = gimple_ic (e->call_stmt, dyn_cast 
(ref->referred),
+ new_stmt = gimple_ic (e->call_stmt,
+   dyn_cast (ref->referred),
e->count || e2->count
?  RDIV (e->count * REG_BR_PROB_BASE,
 e->count + e2->count)
@@ -1464,6 +1465,9 @@ cgraph_edge::redirect_call_stmt_to_calle
   update_stmt_fn (DECL_STRUCT_FUNCTION (e->caller->decl), new_stmt);
 }
 
+  maybe_remove_unused_call_args (DECL_STRUCT_FUNCTION (e->caller->decl),
+new_stmt);
+
   e->caller->set_call_stmt_including_clones (e->call_stmt, new_stmt, false);
 
   if (symtab->dump_file)
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c  (revision 220411)
+++ tree-ssa-pre.c  (working copy)
@@ -4406,6 +4406,7 @@ eliminate_dom_walker::before_dom_childre
   cgraph_node::get (fn)->name ());
}
  gimple_call_set_fndecl (call_stmt, fn);
+ maybe_remove_unused_call_args (cfun, call_stmt);
  gimple_set_modified (stmt, true);
}
}
Index: gimple-fold.c
===
--- gimple-fold.c   (revision 220411)
+++ gimple-fold.c   (working copy)
@@ -3120,6 +3120,7 @@ gimple_fold_call (gimple_stmt_iterator *
}
  gimple_call_set_lhs (stmt, NULL_TREE);
}
+ maybe_remove_unused_call_args (cfun, stmt);
}
  else
{

Re: Remove parameters after converting call to gcc_unreachable

[Jakub Jelinek]

On Wed, Feb 04, 2015 at 08:47:20PM +0100, Jan Hubicka wrote:
> Bootstrapped/regtested x86_64-linux, OK?
>   PR middle-end/64922
>   * gimple.c: Include gimple-ssa.h

Missing dot at the end of line.

>   (maybe_remove_unused_call_args): New function.
>   * gimple.h (maybe_remove_unused_call_args): Declare.
>   * craph.c (cgraph_edge::redirect_call_stmt_to_callee): Use it.
>   * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children): Likewise.
>   * gimple-fold.c (gimple_fold_call): Likewise.

> +   to __builtiln_unreacahble or __cfa_pure_virutal.  */

  to __builtin_unreachable or __cxa_pure_virtual.

Ok with that change.

Jakub

Re: [Patch, fortran] PR 64757 - [5 Regression] ICE in fold_convert_loc, at fold-const.c:2353

[Tobias Burnus]

Dear Paul, dear all,

Paul Richard Thomas wrote:

Please find attached a reworked version of the patch for this PR. [...]
In this version, the treatment of scalar and array components is cleanly
separated.

Bootstrapped and regtested on FC21/x86_64. OK for trunk?


Looks good to me. Thanks for the patch.

 * * *

However, as follow up, one should check also the initialization of a 
(polymorphic) pointer component. Quoting the standard:


"For a pointer component, the corresponding component-data-source shall 
be an allowable data-target or proctarget for such a pointer in a 
pointer assignment statement (7.2.2). If the component data source is a 
pointer, the association of the component is that of the pointer; 
otherwise, the component is pointer associated with the component data 
source."


Thus, one should check CLASS => CLASS and CLASS <-> TYPE.

 * * *

And, finally, I wonder whether we need to take care of:

type m
end type m
type t
  CLASS(m), allocatable :: caf[:]
end type t
type(t), save :: x = t(m())
end

We probably do. I think that's valid as it is (kind of) statically 
allocated. That means we need to call for -fcoarray=lib the 
_gfortran_caf_register function for x%caf as constructor (in the C 
sense) - such that the address is registered at program start up. The 
(pointer) assignment of that address to x%caf can be done later, e.g. 
when the procedure (or __MAIN) is actually entered.


Tobias


2015-02-04  Paul Thomas  

 PR fortran/640757
 * resolve.c (resolve_structure_cons): Obtain the rank of class
 components.
 * trans-expr.c (gfc_trans_alloc_subarray_assign): Do the
 assignment to allocatable class array components.
 (alloc_scalar_allocatable_for_subcomponent_assignment): If comp
 is a class component, allocate to the _data field.
 (gfc_trans_subcomponent_assign): If a class component with a
 derived type expression set the _vptr field and for array
 components, call gfc_trans_alloc_subarray_assign. For scalars,
 the assignment is performed here.

2015-02-04  Paul Thomas  

 PR fortran/640757
 * gfortran.dg/type_to_class_2.f90: New test
 * gfortran.dg/type_to_class_3.f90: New test

On 3 February 2015 at 22:36, Paul Richard Thomas
 wrote:

Dear Dominique,

I have fixed all the problems except the last one. For that case, the
other brand gives
type_to_class_30.f90(19): error #7822: Variables containing ultimate
allocatable array components are forbidden from appearing directly in
input/output lists.
print *, TestReference([Test(99), Test(199)])
-^
compilation aborted for type_to_class_30.f90 (code 1)

which seems to me to be correct. I'll see what I can do to fix it.

Thanks for the help

Paul

On 2 February 2015 at 17:53, Dominique Dhumieres  wrote:

Dear Paul,

I have tested your patch at 
https://gcc.gnu.org/ml/fortran/2015-01/txtwnaoa1115V.txt
(the latest version) and I found that the test type_to_class_3.f03 is 
miscompiled
(FAIL) with -flto -O0 -m64 (this does not happens with -flto -O0 -m32 or with 
-Ox and
x!=0).

In addition, while the reduced test

   type :: Test
 integer :: i
   end type

   type :: TestReference
  class(Test), allocatable :: test(:)
   end type

   type(TestReference) :: testList
   type(test), allocatable :: x(:)

  allocate (testList%test(2), source = [Test(99), Test(199)]) ! Works, of course
  print *, size(testList%test)
  x = testList%test
  print *, x
end

gives what I expect, i.e.,

2
   99 199

   type :: Test
 integer :: i
   end type

   type :: TestReference
  class(Test), allocatable :: test(:)
   end type

   type(TestReference) :: testList
   type(test), allocatable :: x(:)

   testList = TestReference([Test(99), Test(199)])  ! Gave: The rank of the 
element in the
! structure constructor at 
(1) does not
! match that of the 
component (1/0)
   print *, size(testList%test)
   x = testList%test
   print *, x
end

gives

1
   99

Last problem I see,

print *, TestReference([Test(99), Test(199)])

gives the following ICE

f951: internal compiler error: Bad IO basetype (7)

type_to_class_3_red_2.f03:12:0:

print *, TestReference([Test(99), Test(199)])


Cheers,

Dominique



--
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx

Fix PR64878: do not jump thread across two loop iterations

[Sebastian Pop]

Hi,

The attached patch stops the recursion in the detection of FSM jump-threads at
loop phi nodes after having visited a loop phi node.  This avoids jump-threading
two iterations forward that were possible due to a flip-flop operation that
exchange the value of the switch control variable as illustrated in the
testcase:

do {
  c = read_from_memory;
  switch (a) {
  case 0:
if (c == ' ')
 [...]
else
  a = b;   // flip-flop
break;
  case 1:
a = 0;
b = 15; // this will jump-thread to 15
break;

  case 15:
  [...]
  }
} while (...);

The patch has passed bootstrap and regression testing on x86_64-linux.
Ok to commit?

Thanks,
Sebastian
>From 59c486720749fc3d5feac2a5364d52eac60ba2d0 Mon Sep 17 00:00:00 2001
From: Sebastian Pop 
Date: Wed, 4 Feb 2015 11:17:54 -0600
Subject: [PATCH] PR 64878: do not jump thread across more than one back-edge

2015-02-04  Sebastian Pop  
	Brian Rzycki  

	PR tree-optimization/64878
	* tree-ssa-threadedge.c: Include tree-ssa-loop.h.
	(fsm_find_control_statement_thread_paths): Add parameter seen_loop_phi.
	Stop recursion at loop phi nodes after having visited a loop phi node.

	* testsuite/gcc.dg/tree-ssa/ssa-dom-thread-8.c: New.
---
 gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-8.c | 440 +++
 gcc/tree-ssa-threadedge.c|  20 +-
 2 files changed, 457 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-8.c

diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-8.c b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-8.c
new file mode 100644
index 000..9be75aa
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-dom-thread-8.c
@@ -0,0 +1,440 @@
+/* PR 64878 */
+/* { dg-options "-O2" } */
+/* { dg-do run } */
+
+struct A { int a1; };
+struct B { char *b1; int b2; int b3; };
+struct C { char *c1; int c2; struct B *c3; };
+extern struct A *f1 (char *s);
+static struct A *f2 (struct C *x);
+__attribute__ ((noinline, noclone)) int f3 (struct A *x, struct A *z) { asm volatile ("" : : "g" (x), "g" (z) : "memory"); return 0; }
+__attribute__ ((noinline, noclone)) void f4 (struct A *x, char *y, struct A *z) { asm volatile ("" : : "g" (x), "g" (z), "g" (y) : "memory"); }
+__attribute__ ((noinline, noclone)) struct B *f5 (void) { static char b[32]; static struct B f3 = { b, 0, 32 }; return &f3; }
+__attribute__ ((noinline, noclone)) int f6 (struct B *p, char *w, int z) { asm volatile ("" : : "g" (p), "g" (w), "g" (z) : "memory"); return 0; }
+__attribute__ ((noinline, noclone)) void f7 (struct B *p) { asm volatile ("" : : "g" (p) : "memory"); }
+__attribute__ ((noinline, noclone)) void f8 (struct B *p) { asm volatile ("" : : "g" (p) : "memory"); }
+__attribute__ ((noinline, noclone)) void f9 (struct A *x) { asm volatile ("" : : "g" (x) : "memory"); }
+__attribute__ ((noinline, noclone)) struct A *f10 (void) { static struct A j; asm volatile ("" : :  : "memory"); return &j; }
+__attribute__ ((noinline, noclone)) struct A *f11 (void) { static struct A j; asm volatile ("" : :  : "memory"); return &j; }
+__attribute__ ((noinline, noclone)) struct A *f12 (int b) { static struct A j; asm volatile ("" : : "g" (b) : "memory"); return &j; }
+__attribute__ ((noinline, noclone)) struct A *f13 (int i) { static struct A j; asm volatile ("" : : "g" (i) : "memory"); return &j; }
+__attribute__ ((noinline, noclone)) struct A *f14 (double d) { static struct A j; asm volatile ("" : : "g" (&d) : "memory"); return &j; }
+__attribute__ ((noinline, noclone)) struct A *f15 (char *s) { static struct A j; asm volatile ("" : : "g" (s) : "memory"); return &j; }
+char *t = "0123456789abcdef";
+char *u = "0123456789.+-e";
+
+__attribute__ ((noinline, noclone)) struct A *
+f1 (char *s)
+{
+  struct C f;
+  struct A *o;
+  f.c1 = s;
+  f.c2 = 0;
+  f.c3 = f5 ();
+  o = f2 (&f);
+  f8 (f.c3);
+  return o;
+}
+
+static struct A *
+f2 (struct C *x)
+{
+  int a, b, e = 0;
+  struct A *f = 0, *o;
+  char *g = 0;
+  char h = '\0';
+  int i = 0, j = 0;
+  a = 0;
+  b = 1;
+  char c;
+  do
+{
+  c = x->c1[x->c2];
+  switch (a)
+	{
+	case 0:
+	  if (c == ' ')
+	x->c2++;
+	  else if (c == '/')
+	{
+	  a = 4;
+	  j = x->c2++;
+	}
+	  else
+	a = b;
+	  break;
+	case 1:
+	  switch (c)
+	{
+	case '{':
+	  a = 0;
+	  b = 15;
+	  f = f10 ();
+	  x->c2++;
+	  break;
+	case '[':
+	  a = 0;
+	  b = 13;
+	  f = f11 ();
+	  x->c2++;
+	  break;
+	case 'N':
+	case 'n':
+	  a = 3;
+	  j = x->c2++;
+	  break;
+	case '"':
+	case '\'':
+	  h = c;
+	  f7 (x->c3);
+	  a = 8;
+	  j = ++x->c2;
+	  break;
+	case 'T':
+	case 't':
+	case 'F':
+	case 'f':
+	  a = 11;
+	  j = x->c2++;
+	  break;
+	case '0' ... '9':
+	case '-':
+	  i = 0;
+	  a = 12;
+	  j = x->c2++;
+	  break;
+	default:
+	  e = 1;
+	  goto out;
+	}
+	  break;
+	case 2:

Re: [PATCH] More fixes for update_web_docs_svn for jit docs (PR jit/64257)

[Gerald Pfeifer]

On Wednesday 2015-02-04 14:10, David Malcolm wrote:
> Gerald: Please can you do the "svn up" on the relevant machine again, 
> so that it gets the updated "update_web_docs_svn"?

That was my plan, yes. :-)  I just did that and manually ran
the script, and it seems to work.

Still, do you think you can add a bit of error handling such
that an issue like the one we had (cf. 
https://gcc.gnu.org/ml/gccadmin/2015-q1/msg00077.html ) does
not kill the entire script?  A bit of resilience would be good.

Gerald

RE: [PATCH,WWWDOCS] MIPS changes for GCC 5.0

[Moore, Catherine]

Hi Matthew,

I made a few edits.  I removed the markup in the process, so that will need to 
be added back.
See the text at the end.

Thanks,
Catherine

> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Wednesday, February 04, 2015 11:46 AM
> To: Moore, Catherine
> Cc: 'gcc-patches@gcc.gnu.org' (gcc-patches@gcc.gnu.org)
> Subject: [PATCH,WWWDOCS] MIPS changes for GCC 5.0
> 
> Hi Catherine,
> 
> I've made a first pass at writing up the MIPS changes for GCC 5.0.
> Could you take a read and see what needs some more work?
> 
> Thanks,
> Matthew
> 
> Index: htdocs/gcc-5/changes.html
> ==
> =
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
> retrieving revision 1.77
> diff -r1.77 changes.html
> 562a563,614
> > MIPS
> >   
> > MIPS Releases 3 and 5 are now directly supported using -
> mips32r3,
> > -mips64r3, -mips32r5 and -mips64r5 instead of relying on the
> Release
> > 2 options.
> > Support for the Imagination P5600 processor has been added using
> > -march=p5600.
> > 
> > Support for the Cavium Networks Octeon3 processor has been added
> using
> > -march=octeon3.
> > MIPS Release 6 is now supported using -mips32r6 and -
> mips64r6
> > .
> > The previous o32 64-bit floating-point register support has been
> > obsoleted and removed.  This was previously enabled using -
> mfp64
> >  which has been re-purposed for the new ABI extensions
> described
> > below.
> > New o32 ABI extensions have been added to enable software to
> transition
> > away from the original layout of double-precision floating-point 
> > registers.
> > 
> >   The first of these extensions is o32 FPXX which places 
> > restrictions
> >   on code-generation to never access the upper 32-bits of double-
> precision
> >   registers via odd-numbered single-precision registers.  By default the
> >   odd-numbered single-precision registers are not used at all with this
> >   extension.  o32 FPXX code is link compatible with all other o32
> >   double-precision ABI variants and will execute correctly in all 
> > hardware
> >   FPU modes.  Enable o32 FPXX using -mabi=32 -mfpxx for
> >   MIPS II onwards.
> >   The second extension is o32 FP64A which requires 64-bit
> >   floating-point registers and places a mandatory restriction on the 
> > use of
> >   odd-numbered single-precision registers.  o32 FP64A is link compatible
> >   with all other o32 double-precision ABI variants.  Enable o32 FP64A
> >   using -mabi=32 -mfp64 -mno-odd-spreg for MIPS32R2
> onwards.
> >   
> >   Finally, the o32 FP64 extension which also requires 64-bit
> >   floating-point registers but permits the use of all single-precision
> >   registers.  Enable o32 FP64 using -mfp64 for MIPS32R2
> >   onwards.
> > 
> > All new ABI variants can be enabled by default using configure time
> > options --with-fp-32=[32|xx|64] and
> > --with(out)-odd-sp-reg-32.  It is strongly recommended
> that
> > all vendors begin to set o32 FPXX as default ABI to be able to run the
> > generated code on MIPSR5 cores alongside future MIPS SIMD (MSA)
> code and
> > MIPSR6 cores.
> > When using binutils 2.25 GCC will now pass options like
> > -msoft-float and -msingle-float to the
> assembler.
> > This change can affect inline assembly code that is built as soft-float 
> > but
> > contains hard-float instructions.  In such cases the code must be
> amended
> > to use appropriate .set directives to override the global
> > assembler options.
> >   
> >

MIPS Releases 3 and 5 are now directly supported.  Use the command-line options
-mips32r3, -mips64r3, -mips32r5 and -mips64r5 to enable code-generation for
these processors.

Support for the Imagination P5600 processor is now supported through
use of the -march=p5600 command-line option.

The Cavium Octeon3 processor is now supported through the use of the
command-line option -march=octeon3.

MIPS Release 6 is now supported through the use of the -mips32r6 and -mips64r6
command-line options.

The o32 ABI has been modified and extended.  The o32 64-bit floating-point
register support is now obsolete and has been removed.  It has been replaced by
three ABI extensions FPXX, FP64A, and FP64.  The meaning of the -mfp64
command-line option has been changed and it is now used to enable the ABI
extensions.

The FPXX extension requires that code generated to access double-precision
values use even-numbered registers.  Code that adheres to this extension is
link-compatible with the other o32 double-precision ABI variants and will
execute correctly in all hardware FPU modes.  The command-line options
-mabi=32 -mfpxx can be used to enable this extension.  MIPS II is the minimum
processor required.

The o32 FP64A extension requires that floating-point registers be 

Re: [PATCH x86_64] Optimize access to globals in "-fpie -pie" builds with copy relocations

[Sriraman Tallam]

On Wed, Feb 4, 2015 at 10:57 AM, H.J. Lu  wrote:
> On Wed, Feb 4, 2015 at 10:51 AM, Sriraman Tallam  wrote:
>> On Wed, Feb 4, 2015 at 10:45 AM, H.J. Lu  wrote:
>>> On Wed, Feb 4, 2015 at 10:42 AM, Jakub Jelinek  wrote:
 On Wed, Feb 04, 2015 at 10:38:48AM -0800, H.J. Lu wrote:
> Common symbol should be resolved locally for PIE.

 binds_local_p yes, binds_to_current_def_p no.

>>>
>>> Is SYMBOL_REF_LOCAL_P set to binds_local_p or
>>> binds_to_current_def_p?
>>
>> Looks like binds_local_p:
>>
>> varasm.c:
>> void
>> default_encode_section_info (tree decl, rtx rtl, int first ATTRIBUTE_UNUSED)
>> {
>>   ...
>>   if (targetm.binds_local_p (decl))
>> flags |= SYMBOL_FLAG_LOCAL;
>>
>
> Why is SYMBOL_REF_LOCAL_P false?

In varasm.c, default_binds_local_p_1


 /* Default visibility weak data can be overridden by a strong symbol
 in another module and so are not local.  */
  else if (DECL_WEAK (exp)
  && !resolved_locally)
local_p = false;

For weak definition, it is set to false here.

Sri


>
>
> --
> H.J.

Re: [RFC PATCH] Emit DW_LANG_Fortran{03,08}

[Cary Coutant]

> DW_LANG_Fortran03 and DW_LANG_Fortran08 DW_AT_language values were recently
> accepted into DWARF5.  This patch changes GCC to handle those similarly to
> how e.g. the -std=c++11, -std=c++14 or -std=c11 are handled.
>
> As it will take some time for consumers to catch up, I'm enabling that
> only if -gdwarf-5 is used for now.

My concern with enabling -gdwarf-5 at this point is that all we're
really doing with it is enabling a subset of DWARF-5 features (as we
did with -gdwarf-4). We're still putting a version number of 2 in the
compilation unit header! But I guess even upgrading the CU header to
version 3 is something not all consumers are yet ready for. As long as
we selectively enable DWARF-5 features while still claiming to be
DWARF-2, I guess we're OK, but how will we decide to upgrade fully
beyond DWARF-2, and what option will we use for that?

The DWARF bits of this patch are OK with me.

-cary