Re: [PATCH] Implement -fsanitize=float-divide-by-zero

[Marek Polacek]

On Wed, Apr 30, 2014 at 08:55:10AM +0200, Jakub Jelinek wrote:
> Please assign the result of the divisions to some other volatile variables,
> otherwise I don't see why the compiler couldn't optimize them away all.
> 
> Otherwise looks good to me.

Done, thanks.

Marek

RE: [PATCH, MIPS] Alter default number of single-precision registers

[Matthew Fortune]

Richard Sandiford  writes:
> Matthew Fortune  writes:
> > Hi Richard,
> >
> > When MIPSr1 introduced the ability to use odd-numbered
> > single-precision registers some implementations continued to only
> > support even-numbered single-precision registers.  Notably,
> loongson3a
> > in FR=0 mode only permits the even-numbered registers to be used.
> For
> > this reason and also to coincide with other FP ABI related changes we
> > are reducing the number of single precision floating-point registers
> > available for generic architectures: MIPS32, MIPS32r2, MIPS64,
> MIP64r1
> > when using -mfp32.
> >
> > Targeting or tuning for a specific MIPS implementation which is known
> > to have odd-numbered single-precision registers usable will continue
> > to make use of all 32 registers. The -modd-spreg option has no effect
> > on the availability of odd-numbered single precision registers for -
> mfp64.
> >
> > This patch also implements REGISTER_PREFIX to simplify the use of
> > command line options like -ffixed-reg which take a register name as
> an
> > argument and the $ (dollar) in MIPS register names makes this more
> > awkward than necessary.
> >
> > Suggestions for better option names are welcome, also better
> > approaches to the tests are welcome. I'm simply relying on an ICE
> when
> > no registers are available to check the implementation.
> 
> One way would be something like:
> 
>   void
>   foo (void)
>   {
> register float foo asm ("$f1");
> asm volatile ("" : "=f" (foo));
>   }
> 
> which gives:
> 
>   error: register specified for ‘foo’ isn’t suitable for data type
> 
> when odd FP regs are disallowed.

Yes that's blatantly obvious :-). I took these tests from my work on
the FPXX ABI which I can't find a way to test using inline asm and
constraints. (patch due soon).

> You need to document the new option in the texi file.

Will do.

> > diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c index
> > 45256e9..b012dfd 100644
> > --- a/gcc/config/mips/mips.c
> > +++ b/gcc/config/mips/mips.c
> > @@ -17120,6 +17120,21 @@ mips_option_override (void)
> >  warning (0, "the %qs architecture does not support madd or msub"
> >  " instructions", mips_arch_info->name);
> >
> > +  /* If neither -modd-spreg nor -mno-odd-spreg was given on the
> command
> > + line, set MASK_ODD_SPREG bsaed on the target architecture, ABI
> and
> > + tuning flags.  */
> > +  if ((target_flags_explicit & MASK_ODD_SPREG) == 0)
> > +{
> > +  if (ISA_HAS_ODD_SPREG
> > + && ((mips_tune_info->tune_flags & PTF_AVOID_ODD_SPREG) == 0))
> > +   target_flags |= MASK_ODD_SPREG;
> > +  else
> > +   target_flags &= ~MASK_ODD_SPREG;
> > +}
> > +  else if (TARGET_ODD_SPREG && !ISA_HAS_ODD_SPREG)
> > +warning (0, "the %qs architecture does not support odd single-
> precision"
> > +" registers", mips_arch_info->name);
> 
> I think this should be an -march decision rather than an -mtune
> decision.
> The two existing PTF_s (which were supposed to be "processor tuning
> flags") really are -mtune decisions, since the question isn't whether
> the features are available (that's given accurately by ISA_HAS_*) but
> whether it's a good idea to use them.
> 
> ISA_HAS_ODD_SPREG should probably be false for loongson
> !TARGET_FLOAT64.
> Then the decision here is whether mips_arch_info is the generic ISA or
> not.
> We could add a new flag for that (and rename "tune_flags" to simply
> "flags"
> and update the commentary) but strncmp (mips_arch_info->name, "mips",
> 4) should work too.

If we make ISA_HAS_ODD_SPREG return false for:
loongson3a && !TARGET_FLOAT64
Then the tuning option starts to make sense again as the generic mips
architectures do support the odd numbered registers but for
compatibility reasons they should be avoided. 

> As you can tell, this whole what-ISA-has-what area is very old and
> needs a rework.  It predates the current option machinery (and
> certainly the use of the option machinery in the driver) by many
> years...
> > @@ -1268,6 +1282,12 @@ struct mips_cpu_info {
> >  /* By default, turn on GDB extensions.  */  #define
> > DEFAULT_GDB_EXTENSIONS 1
> >
> > +/* Registers may have a prefix which can be ignored when matching
> > +   user asm and register definitions.  */ #ifndef REGISTER_PREFIX
> > +#define REGISTER_PREFIX"$"
> > +#endif
> > +
> >  /* Local compiler-generated symbols must have a prefix that the
> assembler
> > understands.   By default, this is $, although some targets
> (e.g.,
> > NetBSD-ELF) need to override this.  */
> 
> This is OK to commit as an independent patch, thanks.

OK. We are waiting for our updated copyright assignment papers to be
completed but will prepare this separately. We are going to end up
with a few patches queued on assignment.

Regards,
Matthew

Re: [PATCH, MIPS] Alter default number of single-precision registers

[Richard Sandiford]

Matthew Fortune  writes:
> Richard Sandiford  writes:
>> Matthew Fortune  writes:
>> > Hi Richard,
>> >
>> > When MIPSr1 introduced the ability to use odd-numbered
>> > single-precision registers some implementations continued to only
>> > support even-numbered single-precision registers.  Notably,
>> loongson3a
>> > in FR=0 mode only permits the even-numbered registers to be used.
>> For
>> > this reason and also to coincide with other FP ABI related changes we
>> > are reducing the number of single precision floating-point registers
>> > available for generic architectures: MIPS32, MIPS32r2, MIPS64,
>> MIP64r1
>> > when using -mfp32.
>> >
>> > Targeting or tuning for a specific MIPS implementation which is known
>> > to have odd-numbered single-precision registers usable will continue
>> > to make use of all 32 registers. The -modd-spreg option has no effect
>> > on the availability of odd-numbered single precision registers for -
>> mfp64.
>> >
>> > This patch also implements REGISTER_PREFIX to simplify the use of
>> > command line options like -ffixed-reg which take a register name as
>> an
>> > argument and the $ (dollar) in MIPS register names makes this more
>> > awkward than necessary.
>> >
>> > Suggestions for better option names are welcome, also better
>> > approaches to the tests are welcome. I'm simply relying on an ICE
>> when
>> > no registers are available to check the implementation.
>> 
>> One way would be something like:
>> 
>>   void
>>   foo (void)
>>   {
>> register float foo asm ("$f1");
>> asm volatile ("" : "=f" (foo));
>>   }
>> 
>> which gives:
>> 
>>   error: register specified for ‘foo’ isn’t suitable for data type
>> 
>> when odd FP regs are disallowed.
>
> Yes that's blatantly obvious :-). I took these tests from my work on
> the FPXX ABI which I can't find a way to test using inline asm and
> constraints. (patch due soon).
>
>> You need to document the new option in the texi file.
>
> Will do.
>
>> > diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c index
>> > 45256e9..b012dfd 100644
>> > --- a/gcc/config/mips/mips.c
>> > +++ b/gcc/config/mips/mips.c
>> > @@ -17120,6 +17120,21 @@ mips_option_override (void)
>> >  warning (0, "the %qs architecture does not support madd or msub"
>> > " instructions", mips_arch_info->name);
>> >
>> > +  /* If neither -modd-spreg nor -mno-odd-spreg was given on the
>> command
>> > + line, set MASK_ODD_SPREG bsaed on the target architecture, ABI
>> and
>> > + tuning flags.  */
>> > +  if ((target_flags_explicit & MASK_ODD_SPREG) == 0)
>> > +{
>> > +  if (ISA_HAS_ODD_SPREG
>> > +&& ((mips_tune_info->tune_flags & PTF_AVOID_ODD_SPREG) == 0))
>> > +  target_flags |= MASK_ODD_SPREG;
>> > +  else
>> > +  target_flags &= ~MASK_ODD_SPREG;
>> > +}
>> > +  else if (TARGET_ODD_SPREG && !ISA_HAS_ODD_SPREG)
>> > +warning (0, "the %qs architecture does not support odd single-
>> precision"
>> > +   " registers", mips_arch_info->name);
>> 
>> I think this should be an -march decision rather than an -mtune
>> decision.
>> The two existing PTF_s (which were supposed to be "processor tuning
>> flags") really are -mtune decisions, since the question isn't whether
>> the features are available (that's given accurately by ISA_HAS_*) but
>> whether it's a good idea to use them.
>> 
>> ISA_HAS_ODD_SPREG should probably be false for loongson
>> !TARGET_FLOAT64.
>> Then the decision here is whether mips_arch_info is the generic ISA or
>> not.
>> We could add a new flag for that (and rename "tune_flags" to simply
>> "flags"
>> and update the commentary) but strncmp (mips_arch_info->name, "mips",
>> 4) should work too.
>
> If we make ISA_HAS_ODD_SPREG return false for:
> loongson3a && !TARGET_FLOAT64
> Then the tuning option starts to make sense again as the generic mips
> architectures do support the odd numbered registers but for
> compatibility reasons they should be avoided. 

-march is "which instructions can I use?" and -mtune is "which instructions
give good performance?".  My understanding is that you wanted to disable
the instructions for mips32r2 etc. so that they can be safely linked
with loongson3a code, in which case it's an -march rather than an
-mtune decision.

Admittedly the branch-likely case is a bit of a grey area.  It can be
justified on tuning grounds because it's unlikely that deprecated
instructions will perform will in general, and the tuning for mips*
archs is supposed to be an all-round compromise.  But disabling half
the FPRs for single floats can't be justified on tuning grounds.
That's never going to help performance. :-)

Thanks,
Richard

Re: [PATCH][RFC] Always require a 64bit HWI

[Richard Biener]

On Tue, 29 Apr 2014, Jeff Law wrote:

> On 04/29/14 05:21, Richard Biener wrote:
> > 
> > The following patch forces the availability of a 64bit HWI
> > (without applying the cleanups that result from this).  I propose
> > this exact patch for a short time to get those that are affected
> > and do not want to be affected scream.
> > 
> > But honestly I don't see any important host architecture that
> > not already requires a 64bit HWI.
> > 
> > Another concern is that the host compiler may not provide a
> > 64bit type.  I'm not sure that this is an issue nowadays
> > (even though C++98 doesn't have 'long long', so it's maybe
> > more an issue now with C++ than it was previously with
> > requiring C89).  But given that it wasn't an issue for
> > the existing 64bit HWI requiring host archs it shouldn't
> > be an issue now.
> > 
> > The benefit of this change is obviously the cleanup that
> > can result from it - especially getting rid of code
> > generation dependences on the host (!need_64bit_hwi
> > doesn't mean we force a 32bit hwi).  As followup
> > we can replace HOST_WIDE_INT and its friends with
> > int64_t variants and appear less confusing to
> > newcomers (and it's also less characters to type! yay!).
> > 
> > We'd still retain HOST_WIDEST_FAST_INT, and as Kenny
> > said elsewhere wide-int should internally operate on that,
> > not on the eventually slow int64_t.  But that's a separate
> > issue.
> > 
> > So - any objections?
> > 
> > Thanks,
> > Richard.
> > 
> > 2014-04-29  Richard Biener  
> > 
> > libcpp/
> > * configure.ac: Always set need_64bit_hwint to yes.
> > * configure: Regenerated.
> > 
> > * config.gcc: Always set need_64bit_hwint to yes.
> No objections.  The requirement for 64 bit HWINT traces its origins back to
> the MIPS R5900 target IIRC.  It's probably well past the time when we should
> just bite the bullet and make HWINT 64 bits across the board.
> 
> If the host compiler doesn't support 64-bit HWINT, then it seems to me the
> host compiler can be used to bootstrap 4.9, which can then be used to
> bootstrap more modern GCCs.
> 
> And like you I suspect it's really not going to be an issue in practice.

I realized I forgot to copy gcc-patches, so done now (patch copied
below again for reference).

I propose to apply the patch after the wide-int merge for a short
period of time and then followup with a patch to remove the
need_64bit_hwint code (I'll make sure to send that out for review
before applying this one).

Testing coverage for non-64bit hwi configs is really low these
days (I know of only 32bit hppa-*-* that is still built and
tested semi-regularly - Dave, I suppose the host compiler
has a 64bit long long type there, right?).

Thanks,
Richard.

2014-04-29  Richard Biener  

libcpp/
* configure.ac: Always set need_64bit_hwint to yes.
* configure: Regenerated.

* config.gcc: Always set need_64bit_hwint to yes.

Index: libcpp/configure.ac
===
--- libcpp/configure.ac (revision 209890)
+++ libcpp/configure.ac (working copy)
@@ -200,7 +200,7 @@ case $target in
tilegx*-*-* | tilepro*-*-* )
need_64bit_hwint=yes ;;
*)
-   need_64bit_hwint=no ;;
+   need_64bit_hwint=yes ;;
 esac
 
 case $need_64bit_hwint:$ac_cv_sizeof_long in
Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 209890)
+++ gcc/config.gcc  (working copy)
@@ -233,7 +233,7 @@ gnu_ld="$gnu_ld_flag"
 default_use_cxa_atexit=no
 default_gnu_indirect_function=no
 target_gtfiles=
-need_64bit_hwint=
+need_64bit_hwint=yes
 need_64bit_isa=
 native_system_header_dir=/usr/include
 target_type_format_char='@'

Re: [Patch, Fortran] Fix an issue with CLASS and -fcoarray=lib on the trunk

[Paul Richard Thomas]

Dear Tobias,

On 27 April 2014 20:56, Tobias Burnus  wrote:
> First, I would be really delighted if someone could review my coarray
> patches for the trunk as it makes simpler to develop patches on top of it:
> * http://gcc.gnu.org/ml/fortran/2014-04/msg00087.html

This is OK for trunk.

> * http://gcc.gnu.org/ml/fortran/2014-04/msg00091.html

"dg2final"  Surely this is a typo?  Although I note that getting
it wrong on a German keyboard should produce a 4. Therefore it might
well be a command that i do not know about.

Otherwise, OK for trunk.

> * http://gcc.gnu.org/ml/fortran/2014-04/msg00092.html
>

This is OK for trunk

> Secondly, attached is a patch which fixes an ICE - and prepares for some
> additional class-related coarray patches. In particular, the patch ensures
> that for nonallocatable *polymorphic* coarrays, the coarray token and offset
> are passed.

This is also OK for trunk.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
>
> Tobias
>
> PS: There is still something wrong (for both -fcoarray=single and
> -fcoarray=lib) with lcobound/ucobounds and polymorphic coarrays and with
> using them with select type and associated. That's something I would like to
> tackle next. If that's done, I probably should really concentrate on
> reviewing a few patches and doing some other bug fixes before continue
> working on coarrays.

Thank you truly for the effort that you are putting into co-arrays.
It is highly gratifying that gfortran seems to perform so well
compared with another product.  Frankly, if I were you I would
continue working on co-arrays, whilst you have the wind in your sails
:-)

Best regards

Paul



-- 
The knack of flying is learning how to throw yourself at the ground and miss.
   --Hitchhikers Guide to the Galaxy

[wide-int] fix 32-bit x86 builds

[Mike Stump]

We changed the underlying type a while back, and it matters on 32-bit pointer 
machines that use long long for a HOST_WIDE_INT…  Caught by fold-checking, 
thanks fold checking.

Checked in as obvious.

Index: tree.c
===
--- tree.c  (revision 209928)
+++ tree.c  (working copy)
@@ -1959,7 +1959,7 @@ tree
 make_int_cst_stat (int len, int ext_len MEM_STAT_DECL)
 {
   tree t;
-  int length = (ext_len - 1) * sizeof (tree) + sizeof (struct tree_int_cst);
+  int length = (ext_len - 1) * sizeof (HOST_WIDE_INT) + sizeof (struct 
tree_int_cst);
 
   gcc_assert (len);
   record_node_allocation_statistics (INTEGER_CST, length);

[wide-int] fix 32-bit x86 builds

[Mike Stump]

[ sorry for the dup ]

We changed the underlying type a while back, and it matters on 32-bit pointer 
machines that use long long for a HOST_WIDE_INT…  Caught by fold-checking, 
thanks fold checking.

This is the tree-vrp problem, I think this was seen on arm as well.

Checked in as obvious.

Index: tree.c
===
--- tree.c  (revision 209928)
+++ tree.c  (working copy)
@@ -1959,7 +1959,7 @@ tree
make_int_cst_stat (int len, int ext_len MEM_STAT_DECL)
{
  tree t;
-  int length = (ext_len - 1) * sizeof (tree) + sizeof (struct tree_int_cst);
+  int length = (ext_len - 1) * sizeof (HOST_WIDE_INT) + sizeof (struct 
tree_int_cst);

  gcc_assert (len);
  record_node_allocation_statistics (INTEGER_CST, length);

Re: [PATCH 2/6] don't have gengtype autocreate allocation macros for variably sized types

[Laurynas Biveinis]

> ISTR we went to typed allocs as part of a transition which not
> fully materialised?

Yes. I had plans to replace the call-based GC marker routines with a
generic routine that operates on a type marker stored next to the
object. That enables partial, generational, etc GC.

>  I actually dislike that we get back the
> ugly casts here - so, can we keep the allocators or use
> a macro similar to the XNEW family?

My 2c suggestion would be to keep the typed allocators at least until
a new plan for GC is developed.

-- 
Laurynas

[C++ Patch] PR 60999

[Paolo Carlini]

Hi,

this regression unfortunately has to do with my fix for c++/57887, thus 
the code in maybe_begin_member_template_processing:


   if (nsdmi)
 decl = (CLASSTYPE_TEMPLATE_INFO (DECL_CONTEXT (decl))
 ? CLASSTYPE_TI_TEMPLATE (DECL_CONTEXT (decl))
 : NULL_TREE);

The check is true for the new testcase and we end up with an 
unsubstituted STATIC_CAST_EXPR which leads to an ICE in 
cxx_eval_constant_expression. Having tried a number of ideas (by now we 
have got quite a few testcases in this area), I think it makes sense to 
check uses_template_parms too on DECL_CONTEXT (decl): when it returns 
false I don't think we may run into uses of template parms a la 
c++/57887 and we are back to the status pre- that fix in nsdmi handling.


Tested x86_64-linux.

Thanks,
Paolo.

/


/cp
2014-04-30  Paolo Carlini  

PR c++/60999
* pt.c (maybe_begin_member_template_processing): Use
uses_template_parms.

/testsuite
2014-04-30  Paolo Carlini  

PR c++/60999
* g++.dg/cpp0x/nsdmi-template9.C: New.
Index: cp/pt.c
===
--- cp/pt.c (revision 209916)
+++ cp/pt.c (working copy)
@@ -463,6 +463,7 @@ maybe_begin_member_template_processing (tree decl)
 
   if (nsdmi)
 decl = (CLASSTYPE_TEMPLATE_INFO (DECL_CONTEXT (decl))
+   && uses_template_parms (DECL_CONTEXT (decl))
? CLASSTYPE_TI_TEMPLATE (DECL_CONTEXT (decl))
: NULL_TREE);
 
Index: testsuite/g++.dg/cpp0x/nsdmi-template9.C
===
--- testsuite/g++.dg/cpp0x/nsdmi-template9.C(revision 0)
+++ testsuite/g++.dg/cpp0x/nsdmi-template9.C(working copy)
@@ -0,0 +1,16 @@
+// PR c++/60999
+// { dg-do compile { target c++11 } }
+
+template 
+struct foo
+{
+};
+  
+template<>
+struct foo
+{
+  static constexpr int code = 42;
+  unsigned int bar = static_cast(code);
+};
+  
+foo a;

Re: [AArch64/ARM 3/3] Add execution tests of ARM ZIP Intrinsics

[Ramana Radhakrishnan]

On Thu, Mar 27, 2014 at 10:53 AM, Alan Lawrence  wrote:
> Final patch adds new tests of the ARM ZIP Intrinsics (subsuming the
> autogenerated ones in testsuite/gcc.target/arm/neon/), that also check the
> execution results, reusing the test bodies introduced into AArch64 in the
> first patch.
>
> All tests passing on arm-none-eabi.

This is OK - thanks,

Ramana

>
> gcc/testsuite/ChangeLog:
> 2012-03-27  Alan Lawrence  
>
> * gcc.target/arm/simd/simd.exp: New file.
> * gcc.target/arm/simd/vzipqf32_1.c: New file.
> * gcc.target/arm/simd/vzipqp16_1.c: New file.
> * gcc.target/arm/simd/vzipqp8_1.c: New file.
> * gcc.target/arm/simd/vzipqs16_1.c: New file.
> * gcc.target/arm/simd/vzipqs32_1.c: New file.
> * gcc.target/arm/simd/vzipqs8_1.c: New file.
> * gcc.target/arm/simd/vzipqu16_1.c: New file.
> * gcc.target/arm/simd/vzipqu32_1.c: New file.
> * gcc.target/arm/simd/vzipqu8_1.c: New file.
> * gcc.target/arm/simd/vzipf32_1.c: New file.
> * gcc.target/arm/simd/vzipp16_1.c: New file.
> * gcc.target/arm/simd/vzipp8_1.c: New file.
> * gcc.target/arm/simd/vzips16_1.c: New file.
> * gcc.target/arm/simd/vzips32_1.c: New file.
> * gcc.target/arm/simd/vzips8_1.c: New file.
> * gcc.target/arm/simd/vzipu16_1.c: New file.
> * gcc.target/arm/simd/vzipu32_1.c: New file.
> * gcc.target/arm/simd/vzipu8_1.c: New file.
> diff --git a/gcc/testsuite/gcc.target/arm/simd/simd.exp
> b/gcc/testsuite/gcc.target/arm/simd/simd.exp
> new file mode 100644
> index 000..746429d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/simd/simd.exp
> @@ -0,0 +1,35 @@
> +# Copyright (C) 1997-2014 Free Software Foundation, Inc.
> +
> +# This program is free software; you can redistribute it and/or modify
> +# it under the terms of the GNU General Public License as published by
> +# the Free Software Foundation; either version 3 of the License, or
> +# (at your option) any later version.
> +#
> +# This program is distributed in the hope that it will be useful,
> +# but WITHOUT ANY WARRANTY; without even the implied warranty of
> +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> +# GNU General Public License for more details.
> +#
> +# You should have received a copy of the GNU General Public License
> +# along with GCC; see the file COPYING3.  If not see
> +# .
> +
> +# GCC testsuite that uses the `dg.exp' driver.
> +
> +# Exit immediately if this isn't an ARM target.
> +if ![istarget arm*-*-*] then {
> +  return
> +}
> +
> +# Load support procs.
> +load_lib gcc-dg.exp
> +
> +# Initialize `dg'.
> +dg-init
> +
> +# Main loop.
> +dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.\[cCS\]]] \
> +   "" ""
> +
> +# All done.
> +dg-finish
> diff --git a/gcc/testsuite/gcc.target/arm/simd/vzipf32_1.c
> b/gcc/testsuite/gcc.target/arm/simd/vzipf32_1.c
> new file mode 100644
> index 000..efaa96e
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/simd/vzipf32_1.c
> @@ -0,0 +1,12 @@
> +/* Test the `vzipf32' ARM Neon intrinsic.  */
> +
> +/* { dg-do run } */
> +/* { dg-require-effective-target arm_neon_ok } */
> +/* { dg-options "-save-temps -O1 -fno-inline" } */
> +/* { dg-add-options arm_neon } */
> +
> +#include "arm_neon.h"
> +#include "../../aarch64/simd/vzipf32.x"
> +
> +/* { dg-final { scan-assembler-times "vuzp\.32\[ \t\]+\[dD\]\[0-9\]+,
> ?\[dD\]\[0-9\]+!?\(?:\[ \t\]+@\[a-zA-Z0-9 \]+\)?\n" 1 } } */
> +/* { dg-final { cleanup-saved-temps } } */
> diff --git a/gcc/testsuite/gcc.target/arm/simd/vzipp16_1.c
> b/gcc/testsuite/gcc.target/arm/simd/vzipp16_1.c
> new file mode 100644
> index 000..4154333
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/simd/vzipp16_1.c
> @@ -0,0 +1,12 @@
> +/* Test the `vzipp16' ARM Neon intrinsic.  */
> +
> +/* { dg-do run } */
> +/* { dg-require-effective-target arm_neon_ok } */
> +/* { dg-options "-save-temps -O1 -fno-inline" } */
> +/* { dg-add-options arm_neon } */
> +
> +#include "arm_neon.h"
> +#include "../../aarch64/simd/vzipp16.x"
> +
> +/* { dg-final { scan-assembler-times "vzip\.16\[ \t\]+\[dD\]\[0-9\]+,
> ?\[dD\]\[0-9\]+!?\(?:\[ \t\]+@\[a-zA-Z0-9 \]+\)?\n" 1 } } */
> +/* { dg-final { cleanup-saved-temps } } */
> diff --git a/gcc/testsuite/gcc.target/arm/simd/vzipp8_1.c
> b/gcc/testsuite/gcc.target/arm/simd/vzipp8_1.c
> new file mode 100644
> index 000..9fe2384
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/simd/vzipp8_1.c
> @@ -0,0 +1,12 @@
> +/* Test the `vzipp8' ARM Neon intrinsic.  */
> +
> +/* { dg-do run } */
> +/* { dg-require-effective-target arm_neon_ok } */
> +/* { dg-options "-save-temps -O1 -fno-inline" } */
> +/* { dg-add-options arm_neon } */
> +
> +#include "arm_neon.h"
> +#include "../../aarch64/simd/vzipp8.x"
> +
> +/* { dg-final { scan-assembler-times "vzip\.8\[ \t\]+\[dD\]\[0-9\]+,
> ?\[dD\]\[0-9\]+!?\(?:\[ \t\]+@\[a-zA-Z0-9 \]+\)?\n" 1 } } */
> +/* { dg-final { cleanu

Re: [PATCH 2/6] don't have gengtype autocreate allocation macros for variably sized types

[Richard Biener]

On Wed, Apr 30, 2014 at 11:04 AM, Laurynas Biveinis
 wrote:
>> ISTR we went to typed allocs as part of a transition which not
>> fully materialised?
>
> Yes. I had plans to replace the call-based GC marker routines with a
> generic routine that operates on a type marker stored next to the
> object. That enables partial, generational, etc GC.

Ah, ok.  It would also naturally allow finalization.

>>  I actually dislike that we get back the
>> ugly casts here - so, can we keep the allocators or use
>> a macro similar to the XNEW family?
>
> My 2c suggestion would be to keep the typed allocators at least until
> a new plan for GC is developed.

The current patches keep them in some way.  But the use of
C++ (and its more complex types) made types more difficult
to access.  I suppose integrating gengtype with the C++ frontend
would be the only reasonable way out here (eh, and maybe that
then naturally develops to C++11 garbage collection support - who
knows).

Thanks,
Richard.

> --
> Laurynas

Re: [AArch64/ARM 3/3] Add execution tests of ARM EXT intrinsics

[Ramana Radhakrishnan]

On Wed, Apr 23, 2014 at 9:32 PM, Alan Lawrence  wrote:
> Final patch in series, adds new tests of the ARM EXT Intrinsics, that also
> check
> the execution results, reusing the test bodies introduced into AArch64 in
> the
> first patch. (These tests subsume the autogenerated ones in
> testsuite/gcc.target/arm/neon/ that only check assembler output.)
>
> Tests use gcc.target/arm/simd/simd.exp from corresponding patch for ZIP
> Intrinsics http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01500.html, will
> commit that first.
>
> All tests passing on arm-none-eabi.


Ok if no regressions.

Thanks,
Ramana
>
> gcc/testsuite/ChangeLog:
> 2014-04-23  Alan Lawrence  
>
> gcc.target/arm/simd/vextQf32.c: New file.
> gcc.target/arm/simd/vextQp16.c: New file.
> gcc.target/arm/simd/vextQp8.c: New file.
> gcc.target/arm/simd/vextQs16.c: New file.
> gcc.target/arm/simd/vextQs32.c: New file.
> gcc.target/arm/simd/vextQs64.c: New file.
> gcc.target/arm/simd/vextQs8.c: New file.
> gcc.target/arm/simd/vextQu16.c: New file.
> gcc.target/arm/simd/vextQu32.c: New file.
> gcc.target/arm/simd/vextQu64.c: New file.
> gcc.target/arm/simd/vextQu8.c: New file.
> gcc.target/arm/simd/vextQp64.c: New file.
> gcc.target/arm/simd/vextf32.c: New file.
> gcc.target/arm/simd/vextp16.c: New file.
> gcc.target/arm/simd/vextp8.c: New file.
> gcc.target/arm/simd/vexts16.c: New file.
> gcc.target/arm/simd/vexts32.c: New file.
> gcc.target/arm/simd/vexts64.c: New file.
> gcc.target/arm/simd/vexts8.c: New file.
> gcc.target/arm/simd/vextu16.c: New file.
> gcc.target/arm/simd/vextu32.c: New file.
> gcc.target/arm/simd/vextu64.c: New file.
> gcc.target/arm/simd/vextu8.c: New file.
> gcc.target/arm/simd/vextp64.c: New file.
>
> diff --git a/gcc/testsuite/gcc.target/arm/simd/vextQf32.c
> b/gcc/testsuite/gcc.target/arm/simd/vextQf32.c
> new file mode 100644
> index 000..c1da6d3
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/simd/vextQf32.c
> @@ -0,0 +1,12 @@
> +/* Test the `vextQf32' ARM Neon intrinsic.  */
> +
> +/* { dg-do run } */
> +/* { dg-require-effective-target arm_neon_ok } */
> +/* { dg-options "-save-temps -O3 -fno-inline" } */
> +/* { dg-add-options arm_neon } */
> +
> +#include "arm_neon.h"
> +#include "../../aarch64/simd/extq_f32.x"
> +
> +/* { dg-final { scan-assembler-times "vext\.32\[ \t\]+\[qQ\]\[0-9\]+,
> \[qQ\]\[0-9\]+, \[qQ\]\[0-9\]+, #\[0-9\]+!?\(?:\[ \t\]+@\[a-zA-Z0-9
> \]+\)?\n" 3 } } */
> +/* { dg-final { cleanup-saved-temps } } */
> diff --git a/gcc/testsuite/gcc.target/arm/simd/vextQp16.c
> b/gcc/testsuite/gcc.target/arm/simd/vextQp16.c
> new file mode 100644
> index 000..adc0861
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/simd/vextQp16.c
> @@ -0,0 +1,12 @@
> +/* Test the `vextQp16' ARM Neon intrinsic.  */
> +
> +/* { dg-do run } */
> +/* { dg-require-effective-target arm_neon_ok } */
> +/* { dg-options "-save-temps -O3 -fno-inline" } */
> +/* { dg-add-options arm_neon } */
> +
> +#include "arm_neon.h"
> +#include "../../aarch64/simd/extq_p16.x"
> +
> +/* { dg-final { scan-assembler-times "vext\.16\[ \t\]+\[qQ\]\[0-9\]+,
> \[qQ\]\[0-9\]+, \[qQ\]\[0-9\]+, #\[0-9\]+!?\(?:\[ \t\]+@\[a-zA-Z0-9
> \]+\)?\n" 7 } } */
> +/* { dg-final { cleanup-saved-temps } } */
> diff --git a/gcc/testsuite/gcc.target/arm/simd/vextQp64.c
> b/gcc/testsuite/gcc.target/arm/simd/vextQp64.c
> new file mode 100644
> index 000..e8b688d
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/simd/vextQp64.c
> @@ -0,0 +1,33 @@
> +/* Test the `vextQp64' ARM Neon intrinsic.  */
> +
> +/* { dg-do run } */
> +/* { dg-require-effective-target arm_crypto_ok } */
> +/* { dg-options "-save-temps -O3 -fno-inline" } */
> +/* { dg-add-options arm_crypto } */
> +
> +#include "arm_neon.h"
> +
> +extern void abort (void);
> +
> +poly64x2_t
> +test_vextq_p64_1 (poly64x2_t a, poly64x2_t b)
> +{
> +  return vextq_p64(a, b, 1);
> +}
> +
> +int
> +main (int argc, char **argv)
> +{
> +  int i, off;
> +  poly64x2_t in1 = {0, 1};
> +  poly64x2_t in2 = {2, 3};
> +  poly64x2_t actual = test_vextq_p64_1 (in1, in2);
> +  for (i = 0; i < 2; i++)
> +if (actual[i] != i + 1)
> +  abort ();
> +
> +  return 0;
> +}
> +
> +/* { dg-final { scan-assembler-times "vext\.64\[ \t\]+\[qQ\]\[0-9\]+,
> \[qQ\]\[0-9\]+, \[qQ\]\[0-9\]+, #\[0-9\]+!?\(?:\[ \t\]+@\[a-zA-Z0-9
> \]+\)?\n" 1 } } */
> +/* { dg-final { cleanup-saved-temps } } */
> diff --git a/gcc/testsuite/gcc.target/arm/simd/vextQp8.c
> b/gcc/testsuite/gcc.target/arm/simd/vextQp8.c
> new file mode 100644
> index 000..5f2cc53
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/simd/vextQp8.c
> @@ -0,0 +1,12 @@
> +/* Test the `vextQp8' ARM Neon intrinsic.  */
> +
> +/* { dg-do run } */
> +/* { dg-require-effective-target arm_neon_ok } */
> +/* { dg-options "-save-temps -O3 -fno-inline" } */
> +/* { dg-add-options arm_neon } 

Re: [AArch64/ARM 3/3] Add execution tests of ARM UZP Intrinsics

[Ramana Radhakrishnan]

On Thu, Mar 27, 2014 at 5:28 PM, Alan Lawrence  wrote:
> inal patch in series, adds new tests of the ARM UZP Intrinsics (subsuming
> the autogenerated ones in testsuite/gcc.target/arm/neon/), that also check
> the execution results, reusing the test bodies introduced into AArch64 in
> the first patch.
>
> Tests use gcc.target/arm/simd/simd.exp from corresponding patch for ZIP
> Intrinsics, will commit that first.
>
> All tests passing on arm-none-eabi.


Ok if no regressions.

Ramana
>
> gcc/testsuite/ChangeLog:
> 2014-03-27  Alan Lawrence  
>
> * gcc.target/arm/simd/vuzpqf32_1.c: New file.
> * gcc.target/arm/simd/vuzpqp16_1.c: New file.
> * gcc.target/arm/simd/vuzpqp8_1.c: New file.
> * gcc.target/arm/simd/vuzpqs16_1.c: New file.
> * gcc.target/arm/simd/vuzpqs32_1.c: New file.
> * gcc.target/arm/simd/vuzpqs8_1.c: New file.
> * gcc.target/arm/simd/vuzpqu16_1.c: New file.
> * gcc.target/arm/simd/vuzpqu32_1.c: New file.
> * gcc.target/arm/simd/vuzpqu8_1.c: New file.
> * gcc.target/arm/simd/vuzpf32_1.c: New file.
> * gcc.target/arm/simd/vuzpp16_1.c: New file.
> * gcc.target/arm/simd/vuzpp8_1.c: New file.
> * gcc.target/arm/simd/vuzps16_1.c: New file.
> * gcc.target/arm/simd/vuzps32_1.c: New file.
> * gcc.target/arm/simd/vuzps8_1.c: New file.
> * gcc.target/arm/simd/vuzpu16_1.c: New file.
> * gcc.target/arm/simd/vuzpu32_1.c: New file.
> * gcc.target/arm/simd/vuzpu8_1.c: New file.
>
>
> diff --git a/gcc/testsuite/gcc.target/arm/simd/vuzpf32_1.c
> b/gcc/testsuite/gcc.target/arm/simd/vuzpf32_1.c
> new file mode 100644
> index 000..723c86a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/simd/vuzpf32_1.c
> @@ -0,0 +1,12 @@
> +/* Test the `vuzpf32' ARM Neon intrinsic.  */
> +
> +/* { dg-do run } */
> +/* { dg-require-effective-target arm_neon_ok } */
> +/* { dg-options "-save-temps -O1 -fno-inline" } */
> +/* { dg-add-options arm_neon } */
> +
> +#include "arm_neon.h"
> +#include "../../aarch64/simd/vuzpf32.x"
> +
> +/* { dg-final { scan-assembler-times "vuzp\.32\[ \t\]+\[dD\]\[0-9\]+,
> ?\[dD\]\[0-9\]+!?\(?:\[ \t\]+@\[a-zA-Z0-9 \]+\)?\n" 1 } } */
> +/* { dg-final { cleanup-saved-temps } } */
> diff --git a/gcc/testsuite/gcc.target/arm/simd/vuzpp16_1.c
> b/gcc/testsuite/gcc.target/arm/simd/vuzpp16_1.c
> new file mode 100644
> index 000..c7ad757
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/simd/vuzpp16_1.c
> @@ -0,0 +1,12 @@
> +/* Test the `vuzpp16' ARM Neon intrinsic.  */
> +
> +/* { dg-do run } */
> +/* { dg-require-effective-target arm_neon_ok } */
> +/* { dg-options "-save-temps -O1 -fno-inline" } */
> +/* { dg-add-options arm_neon } */
> +
> +#include "arm_neon.h"
> +#include "../../aarch64/simd/vuzpp16.x"
> +
> +/* { dg-final { scan-assembler-times "vuzp\.16\[ \t\]+\[dD\]\[0-9\]+,
> ?\[dD\]\[0-9\]+!?\(?:\[ \t\]+@\[a-zA-Z0-9 \]+\)?\n" 1 } } */
> +/* { dg-final { cleanup-saved-temps } } */
> diff --git a/gcc/testsuite/gcc.target/arm/simd/vuzpp8_1.c
> b/gcc/testsuite/gcc.target/arm/simd/vuzpp8_1.c
> new file mode 100644
> index 000..670b550
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/simd/vuzpp8_1.c
> @@ -0,0 +1,12 @@
> +/* Test the `vuzpp8' ARM Neon intrinsic.  */
> +
> +/* { dg-do run } */
> +/* { dg-require-effective-target arm_neon_ok } */
> +/* { dg-options "-save-temps -O1 -fno-inline" } */
> +/* { dg-add-options arm_neon } */
> +
> +#include "arm_neon.h"
> +#include "../../aarch64/simd/vuzpp8.x"
> +
> +/* { dg-final { scan-assembler-times "vuzp\.8\[ \t\]+\[dD\]\[0-9\]+,
> ?\[dD\]\[0-9\]+!?\(?:\[ \t\]+@\[a-zA-Z0-9 \]+\)?\n" 1 } } */
> +/* { dg-final { cleanup-saved-temps } } */
> diff --git a/gcc/testsuite/gcc.target/arm/simd/vuzpqf32_1.c
> b/gcc/testsuite/gcc.target/arm/simd/vuzpqf32_1.c
> new file mode 100644
> index 000..53147f1
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/simd/vuzpqf32_1.c
> @@ -0,0 +1,12 @@
> +/* Test the `vuzpQf32' ARM Neon intrinsic.  */
> +
> +/* { dg-do run } */
> +/* { dg-require-effective-target arm_neon_ok } */
> +/* { dg-options "-save-temps -O1 -fno-inline" } */
> +/* { dg-add-options arm_neon } */
> +
> +#include "arm_neon.h"
> +#include "../../aarch64/simd/vuzpqf32.x"
> +
> +/* { dg-final { scan-assembler-times "vuzp\.32\[ \t\]+\[qQ\]\[0-9\]+,
> ?\[qQ\]\[0-9\]+!?\(?:\[ \t\]+@\[a-zA-Z0-9 \]+\)?\n" 1 } } */
> +/* { dg-final { cleanup-saved-temps } } */
> diff --git a/gcc/testsuite/gcc.target/arm/simd/vuzpqp16_1.c
> b/gcc/testsuite/gcc.target/arm/simd/vuzpqp16_1.c
> new file mode 100644
> index 000..feef15a
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/simd/vuzpqp16_1.c
> @@ -0,0 +1,12 @@
> +/* Test the `vuzpQp16' ARM Neon intrinsic.  */
> +
> +/* { dg-do run } */
> +/* { dg-require-effective-target arm_neon_ok } */
> +/* { dg-options "-save-temps -O1 -fno-inline" } */
> +/* { dg-add-options arm_neon } */
> +
> +#include "arm_neon.h"
> +#include "../../aarch64/simd/vuzpqp16.x"
> +
> +/* { dg-final { scan-assembler-times "vuzp\.16\[ \t\]+\[qQ\]\[0-9\]+,

Re: [Patch, Fortran] Fix an issue with CLASS and -fcoarray=lib on the trunk

[Dominique Dhumieres]

> > * http://gcc.gnu.org/ml/fortran/2014-04/msg00091.html
>
> "dg2final"  Surely this is a typo? ...

I also see dg1final and dg.final.

Dominique

Re: [PATCH] New target hook: keep_leaf_when_profiled

[Steven Bosscher]

On Tue, Apr 29, 2014 at 2:54 PM, Andreas Krebbel wrote:
> diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
> index b8ca17e..937c2d5 100644
> --- a/gcc/doc/tm.texi
> +++ b/gcc/doc/tm.texi
> @@ -4953,6 +4953,10 @@ Define this macro if the code for function profiling 
> should come before
>  the function prologue.  Normally, the profiling code comes after.
>  @end defmac
>
> +@deftypefn {Target Hook} int TARGET_KEEP_LEAF_WHEN_PROFILED (void)
> +This target hook returns true if the target wants the leaf flag for the 
> current function to stay true even if it calls mcount.  This might make sense 
> for targets using the leaf flag only to determine whether a stack frame needs 
> to be generated or not and for which the call to mcount is generated before 
> the function prologue.
> +@end deftypefn
> +
>  @node Tail Calls
>  @subsection Permitting tail calls
>  @cindex tail calls


bool?

Ciao!
Steven

[PATCH] Testcase for PR48329

[Richard Biener]

Committed.

Richard.

2014-04-30  Richard Biener  

PR tree-optimization/48329
* gfortran.dg/vect/pr48329.f90: New testcase.

Index: gcc/testsuite/gfortran.dg/vect/pr48329.f90
===
--- gcc/testsuite/gfortran.dg/vect/pr48329.f90  (revision 0)
+++ gcc/testsuite/gfortran.dg/vect/pr48329.f90  (working copy)
@@ -0,0 +1,29 @@
+! { dg-do compile }
+! { dg-require-effective-target vect_float }
+! { dg-require-effective-target vect_intfloat_cvt }
+! { dg-additional-options "-ffast-math" }
+
+program calcpi
+
+implicit none
+real(kind=4):: h,x,sum,pi
+integer:: n,i
+real(kind=4):: f
+
+   f(x) = 4.0/(1.0+x**2)
+
+   n = 21
+
+   h= 1.0 / n
+   sum = 0.0
+  DO i=1, n
+ x = h * (i-0.5)
+ sum = sum + f(x)
+  END DO
+  pi = h * sum
+  write(*,*) 'Pi=',pi
+
+end program calcpi
+
+! { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } }
+! { dg-final { cleanup-tree-dump "vect" } }

Re: [PATCH][3/3] Fix PR54733 Optimize endian independent load/store

[Richard Biener]

On Wed, Apr 30, 2014 at 8:23 AM, Thomas Preud'homme
 wrote:
> Hi Richard,
>
> I addressed all your comments but the ones below.
>
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>>
>> + /* Convert the result of load if necessary.  */
>> + if (!useless_type_conversion_p (TREE_TYPE (tgt),
>> + TREE_TYPE (val_tmp)))
>> +   {
>>
>> why's that?  Shouldn't the load already be emitted of the correct type?
>
> The size would be correct and I wasn't sure if the sign matters. I've read
> useless_type_conversion_p since and it seems I was overly worried.

Yes, the sign matters - I forgot about that.  Eventually the load type
should be just chosen from the target type though.

>>
>> You seem to replace the stmt computing the target value by directly
>> loading into the target.  IMHO that's premature optimization and it
>> would be easier to just replace its rhs (that way the stmt still has
>> a proper location for example).
>
> Right. I merely followed what was already done and indeed the whole
> statement is replaced. I don't understand why you say it's a premature
> optimization. Since the left hand side is kept, isn't it equivalent (lost of
> location excluded)?

premature optimization is the copy-propagation that is applied, but
yes, as the LHS is kept it is otherwise equivalent.  Though as the
LHS is kept you should use gsi_replace which avoids useless
insertion of debug stmts.

> I'll change to avoid such a replacement.

That's the easiest option of course.

>>
>> And now that I am looking and the patch series again - I think
>> you need to verify that you load the correct value.  Consider
>>
>> int foo (char *x, char *y)
>> {
>>char c0 = x[0];
>>char c1 = x[1];
>>*y = 1;
>>char c2 = x[2];
>>char c3 = x[3];
>>return c0 | c1 << 8 | c2 << 16 | c3 << 24;
>> }
>>
>> where do you insert the single load?  The easiest way out
>> (without doing alias walks and whatnot) is to verify that all
>> loads have the same gimple_vuse () attached (also please
>> set that gimple_vuse () on the load you build - that avoids
>> costly computation of virtual operands).
>
> Nice catch. I'll do that.
>
> Thanks for you answer and don't worry for the delay: I have other things
> to keep me busy and stage1 is not closed yet.

stage1 is going to go for at least another half year ;)

Richard.

> Best regards,
>
> Thomas
>
>

[PATCH][C++] Fix PR61004

[Richard Biener]

With no longer recording alias subsets using BINFOs we now emit
bogus alias warnings for accessing empty bases.  The following
avoids this, accessing those with an incompatible alias-set is
harmless.

Bootstrapped and tested on x86_64-unknown-linux-gnu, ok?

Thanks,
Richard.

2014-04-30  Richard Biener  

PR c++/61004
* typeck.c (cp_build_indirect_ref): Do not emit strict-aliasing
warnings for accessing empty classes.

* g++.dg/diagnostic/pr61004.C: New testcase.

Index: gcc/cp/typeck.c
===
--- gcc/cp/typeck.c (revision 209928)
+++ gcc/cp/typeck.c (working copy)
@@ -2921,8 +2921,9 @@ cp_build_indirect_ref (tree ptr, ref_ope
 of  the  result  is  "T."  */
   tree t = TREE_TYPE (type);
 
-  if (CONVERT_EXPR_P (ptr)
-  || TREE_CODE (ptr) == VIEW_CONVERT_EXPR)
+  if ((CONVERT_EXPR_P (ptr)
+  || TREE_CODE (ptr) == VIEW_CONVERT_EXPR)
+ && (!CLASS_TYPE_P (t) || !CLASSTYPE_EMPTY_P (t)))
{
  /* If a warning is issued, mark it to avoid duplicates from
 the backend.  This only needs to be done at
Index: gcc/testsuite/g++.dg/diagnostic/pr61004.C
===
--- gcc/testsuite/g++.dg/diagnostic/pr61004.C   (revision 0)
+++ gcc/testsuite/g++.dg/diagnostic/pr61004.C   (working copy)
@@ -0,0 +1,11 @@
+// { dg-do compile }
+// { dg-options "-O2 -Wall" }
+
+struct A{ };
+struct B:A{};
+void f(A const&);
+int main()
+{
+  B b;
+  f(b); // { dg-bogus "strict-aliasing" }
+}

[PATCH] Work around for current Cygwin-32 Build problems

[Bernd Edlinger]

Hi,

due to a defect in the currently available binutils-2.24 and earlier, it is not 
possible
to boot-strap GCC 4.9.0 and trunk with certain widely used configurations for 
Cygwin-32 environment.
See PR 60830 for details.

Boot-Strapped on x86-64-cygwin and i686-pc-cygwin with binutils-2.24.

OK for trunk and 4.9 branch?


Thanks
Bernd.
  2014-04-30  Bernd Edlinger  

Work around for current cygwin32 build problems (Bug gas/16858).
* config/i386/cygming-crtbegin.c (__register_frame_info,
__deregister_frame_info, _Jv_RegisterClasses): Compile weak default
functions only for 64-bit systems, when absolutely necessary.



patch-pr60830.diff
Description: Binary data

[PATCH] Fix PR61010

[Richard Biener]

This fixes an endless recursion in folding that appears because
we are inconsistent in how we treat X & CST canonicalization
if we can omit some bits in CST.  The following patch makes
the two places that do this consistent.

Bootstrap and regtest running on x86_64-unknown-linux-gnu.

Richard.

2014-04-30  Richard Biener  

PR middle-end/61010
* fold-const.c (fold_binary_loc): Consistently avoid
canonicalizing X & CST away from a CST that is the mask
of a mode.

* gcc.dg/torture/pr61010.c: New testcase.

Index: gcc/fold-const.c
===
*** gcc/fold-const.c(revision 209928)
--- gcc/fold-const.c(working copy)
*** fold_binary_loc (location_t loc,
*** 11426,11432 
{
  double_int c1, c2, c3, msk;
  int width = TYPE_PRECISION (type), w;
- bool try_simplify = true;
  
  c1 = tree_to_double_int (TREE_OPERAND (arg0, 1));
  c2 = tree_to_double_int (arg1);
--- 11426,11431 
*** fold_binary_loc (location_t loc,
*** 11463,11482 
}
}
  
! /* If X is a tree of the form (Y * K1) & K2, this might conflict
!with that optimization from the BIT_AND_EXPR optimizations.
!This could end up in an infinite recursion.  */
! if (TREE_CODE (TREE_OPERAND (arg0, 0)) == MULT_EXPR
! && TREE_CODE (TREE_OPERAND (TREE_OPERAND (arg0, 0), 1))
!   == INTEGER_CST)
! {
!   tree t = TREE_OPERAND (TREE_OPERAND (arg0, 0), 1);
!   double_int masked = mask_with_tz (type, c3, tree_to_double_int (t));
! 
!   try_simplify = (masked != c1);
! }
! 
! if (try_simplify && c3 != c1)
return fold_build2_loc (loc, BIT_IOR_EXPR, type,
fold_build2_loc (loc, BIT_AND_EXPR, type,
 TREE_OPERAND (arg0, 0),
--- 11462,11468 
}
}
  
! if (c3 != c1)
return fold_build2_loc (loc, BIT_IOR_EXPR, type,
fold_build2_loc (loc, BIT_AND_EXPR, type,
 TREE_OPERAND (arg0, 0),
*** fold_binary_loc (location_t loc,
*** 11866,11881 
  && TREE_CODE (arg0) == MULT_EXPR
  && TREE_CODE (TREE_OPERAND (arg0, 1)) == INTEGER_CST)
{
  double_int masked
!   = mask_with_tz (type, tree_to_double_int (arg1),
tree_to_double_int (TREE_OPERAND (arg0, 1)));
  
  if (masked.is_zero ())
return omit_two_operands_loc (loc, type, build_zero_cst (type),
  arg0, arg1);
! else if (masked != tree_to_double_int (arg1))
!   return fold_build2_loc (loc, code, type, op0,
!   double_int_to_tree (type, masked));
}
  
/* For constants M and N, if M == (1LL << cst) - 1 && (N & M) == M,
--- 11852,11876 
  && TREE_CODE (arg0) == MULT_EXPR
  && TREE_CODE (TREE_OPERAND (arg0, 1)) == INTEGER_CST)
{
+ double_int darg1 = tree_to_double_int (arg1);
  double_int masked
!   = mask_with_tz (type, darg1,
tree_to_double_int (TREE_OPERAND (arg0, 1)));
  
  if (masked.is_zero ())
return omit_two_operands_loc (loc, type, build_zero_cst (type),
  arg0, arg1);
! else if (masked != darg1)
!   {
! /* Avoid the transform if arg1 is a mask of some
!mode which allows further optimizations.  */
! int pop = darg1.popcount ();
! if (!(pop >= BITS_PER_UNIT
!   && exact_log2 (pop) != -1
!   && double_int::mask (pop) == darg1))
!   return fold_build2_loc (loc, code, type, op0,
!   double_int_to_tree (type, masked));
!   }
}
  
/* For constants M and N, if M == (1LL << cst) - 1 && (N & M) == M,
Index: gcc/testsuite/gcc.dg/torture/pr61010.c
===
*** gcc/testsuite/gcc.dg/torture/pr61010.c  (revision 0)
--- gcc/testsuite/gcc.dg/torture/pr61010.c  (working copy)
***
*** 0 
--- 1,8 
+ /* { dg-do compile } */
+ 
+ int main (void)
+ {
+   int a = 0;
+   unsigned b = (a * 64 & 192) | 63U;
+   return 0;
+ }

Re: [PATCH] Work around for current Cygwin-32 Build problems

[Kai Tietz]

2014-04-30 14:01 GMT+02:00 Bernd Edlinger :
> Hi,
>
> due to a defect in the currently available binutils-2.24 and earlier, it is 
> not possible
> to boot-strap GCC 4.9.0 and trunk with certain widely used configurations for 
> Cygwin-32 environment.
> See PR 60830 for details.
>
> Boot-Strapped on x86-64-cygwin and i686-pc-cygwin with binutils-2.24.
>
> OK for trunk and 4.9 branch?
>
>
> Thanks
> Bernd.
>

Yes,  please apply.

THanks,
Kai

Re: [PATCH] Work around for current Cygwin-32 Build problems

[Rainer Orth]

Bernd Edlinger  writes:

> 2014-04-30  Bernd Edlinger  
>
>   Work around for current cygwin32 build problems (Bug gas/16858).
>   * config/i386/cygming-crtbegin.c (__register_frame_info,
>   __deregister_frame_info, _Jv_RegisterClasses): Compile weak default
>   functions only for 64-bit systems, when absolutely necessary.

The reference and rationale for the change should go into
cygmin-crtbegin.c, not the ChangeLog.

Rainer

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

Re: Changes for if-convert to recognize simple conditional reduction.

[Richard Biener]

On Tue, Apr 29, 2014 at 4:29 PM, Yuri Rumyantsev  wrote:
> 2014-04-28 16:16 GMT+04:00 Richard Biener :
>> On Thu, Apr 17, 2014 at 3:09 PM, Yuri Rumyantsev  wrote:
>>> Hi All,
>>>
>>> We implemented enhancement for if-convert phase to recognize the
>>> simplest conditional reduction and to transform it vectorizable form,
>>> e.g. statement
>>> if (A[i] != 0) num+= 1; will be recognized.
>>> A new test-case is also provided.
>>>
>>> Bootstrapping and regression testing did not show any new failures.
>>
>> Clever.  Can you add a testcase with a non-constant but invariant
>> reduction value and one with a variable reduction value as well?
>>
> [Yuri]
> I added another testcase to demonstrate ability of new algorithm, i.e.
> it transforms   if (a[i] != 0)   sum += a[i];
> to unconditional form without check on zero. Note also that any checks
> on non-reduction operand were deleted.
>
>> +  if (!(is_cond_scalar_reduction (arg_0, &reduc, &op0, &op1)
>> +   || is_cond_scalar_reduction (arg_1, &reduc, &op0, &op1)))
>>
>> Actually one of the args should be defined by a PHI node in the
>> loop header and the PHI result should be the PHI arg on the
>> latch edge, so I'd pass both PHI args to the predicate and do
>> the decision on what the reduction op is there (you do that
>> anyway).  The pattern matching is somewhat awkward
>>
> [Yuri]
> I changed prototype of 'is_cond_scalar_reduction'  and now we have
> only one call:
> +  if (!is_cond_scalar_reduction (phi, &reduc, &op0, &op1))
>
>> +  /* Consider only conditional reduction.  */
>> +  bb = gimple_bb (stmt);
>> +  if (!bb_has_predicate (bb))
>> +return false;
>> +  if (is_true_predicate (bb_predicate (bb)))
>> +return false;
>>
>> should be replaced by matching the PHI structure
>>
>> loop-header:
>>   reduc_1 = PHI <..., reduc_2>
>>   ...
>>   if (..)
>> reduc_3 = ...
>>   reduc_2 = PHI 
>>
> [Yuri]
>In fact, I re-wrote this function completely as you proposed using
> PHI structure matching.
>
>> +  lhs = gimple_assign_lhs (stmt);
>> +  if (TREE_CODE (lhs) != SSA_NAME)
>> +return false;
>>
>> always true, in fact lhs == arg.
>>
> [Yuri]
> Fixed.
>
>> +  if (SSA_NAME_VAR (lhs) == NULL)
>> +return false;
>>
> [Yuri]
> Deleted.
>> no need to check that (or later verify SSA_NAME_VAR equivalency), not
>> sure why you think you need that.
>>
>> +  if (!single_imm_use (lhs, &use, &use_stmt))
>> +return false;
>> +  if (gimple_code (use_stmt) != GIMPLE_PHI)
>> +return false;
>>
>> checking has_single_use (arg) is enough.  The above is error-prone
>> wrt debug statements.
>>
> [Yuri] Only proposed check is used:
> +  if (!has_single_use (lhs))
> +return false;
>
>> +  if (reduction_op == PLUS_EXPR &&
>> +  TREE_CODE (r_op2) == SSA_NAME)
>>
>> && goes to the next line
>>
> [Yuri]
> Fixed.
>
>> +  if (TREE_CODE (r_op2) != INTEGER_CST && TREE_CODE (r_op2) != REAL_CST)
>> +return false;
>>
>> any reason for this check?  The vectorizer can cope with
>> loop invariant non-constant values as well (at least).
>>
> [Yuri]
> This checks were deleted, i.e. any operand is acceptable.
>
>> +  /* Right operand is constant, check that left operand is equal to lhs.  */
>> +  if (SSA_NAME_VAR (lhs) !=  SSA_NAME_VAR (r_op1))
>> +return false;
>>
>> see above - that looks weird.
>>
> [Yuri]
> This code was deleted.
>> Note that I think you may introduce undefined overflow in
>> unconditionally executing the increment.  So you need to
>> make sure to re-write the increment in unsigned arithmetic
>> (for integral types, that is).
> [Yuri]
> I did not catch your point: if we have
> if (cond) s += val;
> it will be transformed to
> s += (cond? val: 0)
> which looks like completely equivalent to original stmt.

Ah indeed.

>>
>> Thanks,
>> Richard.
>>
>>
>>
>>> Is it OK for trunk?
>>>
>>> gcc/ChangeLog:
>>> 2014-04-17  Yuri Rumyantsev  
>>>
>>> * tree-if-conv.c (is_cond_scalar_reduction): New function.
>>> (convert_scalar_cond_reduction): Likewise.
>>> (predicate_scalar_phi): Add recognition and transformation
>>> of simple conditioanl reduction to be vectorizable.
>>>
>>> gcc/testsuite/ChangeLog:
>>> 2014-04-17  Yuri Rumyantsev  
>>>
>>> * gcc.dg/cond-reduc.c: New test.
>
> New patch is added which includes also new test to detect
> vectorization of conditional reduction with non-invariant operand. All
> remarks found by Richard were fixed.
>
> Bootstrap and regression testing did not show any new failures.
> Is it OK for trunk?

Ok with minor stylistic changes:

+  struct loop *loop = (gimple_bb (phi))->loop_father;

no () around the gimple_bb call.

+  else if (r_op1 !=  PHI_RESULT (header_phi))
+return false;

too many spaces after =

+  c = fold_build_cond_expr (TREE_TYPE (rhs1),
+   unshare_expr (cond),
+   swap? zero: op1,
+   swap? op1: zero);

a space missing before ?

+  gsi_insert_before (gsi, new_assign, GSI_SAME_STMT);
+  update_stm

RE: [PATCH, MIPS] Alter default number of single-precision registers

[Matthew Fortune]

Richard Sandiford  writes:
> -march is "which instructions can I use?" and -mtune is "which
> instructions
> give good performance?".  My understanding is that you wanted to disable
> the instructions for mips32r2 etc. so that they can be safely linked
> with loongson3a code, in which case it's an -march rather than an
> -mtune decision.
> 
> Admittedly the branch-likely case is a bit of a grey area.  It can be
> justified on tuning grounds because it's unlikely that deprecated
> instructions will perform will in general, and the tuning for mips*
> archs is supposed to be an all-round compromise.  But disabling half
> the FPRs for single floats can't be justified on tuning grounds.
> That's never going to help performance. :-)

OK.

Updated patch attached. I've opted to check for mips as a prefix to the
architecture name as part of the default option handling.

regards,
Matthew

2014-04-30  Matthew Fortune 

gcc/
   * config/mips/mips.c: (mips_option_override) Implement -modd-spreg 
   and defaults.
* config/mips/mips.h: (TARGET_CPU_CPP_BUILTINS) Add _MIPS_SPFPSET
builtin define.  (ISA_HAS_ODD_SPREG) Define.  (MIN_FPRS_PER_FMT)
Redefine in terms of TARGET_ODD_SPREG.
* config/mips/mips.opt: Add -modd-spreg option.
* doc/invoke.texi: Document -modd-spreg option.

gcc/testsuite/

* gcc.target/mips/mips.exp: Add -m[no-]odd-spreg.  Use
_MIPS_SPFPSET to determine default odd-spreg option.  Account for
-modd-spreg in minimum arch code.
* gcc.target/mips/oddspreg-1.c: New.
* gcc.target/mips/oddspreg-2.c: New.
* gcc.target/mips/oddspreg-3.c: New.
* gcc.target/mips/oddspreg-4.c: New. 
* gcc.target/mips/oddspreg-5.c: New.
* gcc.target/mips/oddspreg-6.c: New.
* gcc.target/mips/oddspreg-7.c: New.

---
 gcc/config/mips/mips.c |   17 +
 gcc/config/mips/mips.h |   13 +++--
 gcc/config/mips/mips.opt   |4 
 gcc/doc/invoke.texi|7 +++
 gcc/testsuite/gcc.target/mips/mips.exp |   16 +++-
 gcc/testsuite/gcc.target/mips/oddspreg-1.c |   13 +
 gcc/testsuite/gcc.target/mips/oddspreg-2.c |   10 ++
 gcc/testsuite/gcc.target/mips/oddspreg-3.c |   10 ++
 gcc/testsuite/gcc.target/mips/oddspreg-4.c |   10 ++
 gcc/testsuite/gcc.target/mips/oddspreg-5.c |   15 +++
 gcc/testsuite/gcc.target/mips/oddspreg-6.c |   15 +++
 gcc/testsuite/gcc.target/mips/oddspreg-7.c |   13 +
 12 files changed, 140 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/mips/oddspreg-1.c
 create mode 100644 gcc/testsuite/gcc.target/mips/oddspreg-2.c
 create mode 100644 gcc/testsuite/gcc.target/mips/oddspreg-3.c
 create mode 100644 gcc/testsuite/gcc.target/mips/oddspreg-4.c
 create mode 100644 gcc/testsuite/gcc.target/mips/oddspreg-5.c
 create mode 100644 gcc/testsuite/gcc.target/mips/oddspreg-6.c
 create mode 100644 gcc/testsuite/gcc.target/mips/oddspreg-7.c

diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 45256e9..c855527 100644
--- a/gcc/config/mips/mips.c
+++ b/gcc/config/mips/mips.c
@@ -17120,6 +17120,23 @@ mips_option_override (void)
 warning (0, "the %qs architecture does not support madd or msub"
 " instructions", mips_arch_info->name);
 
+  /* If neither -modd-spreg nor -mno-odd-spreg was given on the command
+ line, set MASK_ODD_SPREG bsaed on the target architecture, ABI.  */
+  if ((target_flags_explicit & MASK_ODD_SPREG) == 0)
+{
+  /* Disable TARGET_ODD_SPREG for generic architectures to make them
+compatible with those implementations which are
+!ISA_HAS_ODD_SPREG.  */
+  if (ISA_HAS_ODD_SPREG
+ && (strncmp (mips_arch_info->name, "mips", 4) != 0))
+   target_flags |= MASK_ODD_SPREG;
+  else
+   target_flags &= ~MASK_ODD_SPREG;
+}
+  else if (TARGET_ODD_SPREG && !ISA_HAS_ODD_SPREG)
+warning (0, "the %qs architecture does not support odd single-precision"
+" registers", mips_arch_info->name);
+
   /* The effect of -mabicalls isn't defined for the EABI.  */
   if (mips_abi == ABI_EABI && TARGET_ABICALLS)
 {
diff --git a/gcc/config/mips/mips.h b/gcc/config/mips/mips.h
index b25865b..94dc210 100644
--- a/gcc/config/mips/mips.h
+++ b/gcc/config/mips/mips.h
@@ -491,6 +491,8 @@ struct mips_cpu_info {
   builtin_define_with_int_value ("_MIPS_SZPTR", POINTER_SIZE); \
   builtin_define_with_int_value ("_MIPS_FPSET",\
 32 / MAX_FPRS_PER_FMT);\
+  builtin_define_with_int_value ("_MIPS_SPFPSET",  \
+32 / MIN_FPRS_PER_FMT);\
\
   /* These defines reflect the ABI in use, not whet

RE: [PATCH] Work around for current Cygwin-32 Build problems

[Bernd Edlinger]

Hi Rainer,



On Wed, 30 Apr 2014 14:10:48, Rainer Orth wrote:
>
> Bernd Edlinger  writes:
>
>> 2014-04-30 Bernd Edlinger 
>>
>> Work around for current cygwin32 build problems (Bug gas/16858).
>> * config/i386/cygming-crtbegin.c (__register_frame_info,
>> __deregister_frame_info, _Jv_RegisterClasses): Compile weak default
>> functions only for 64-bit systems, when absolutely necessary.
>
> The reference and rationale for the change should go into
> cygmin-crtbegin.c, not the ChangeLog.
>

Yes, that's better of course. Thanks.
I am going to apply the patch with the updated comment in the evening.

Regards
Bernd.


  2014-04-30  Bernd Edlinger  

Work around for current cygwin32 build problems.
* config/i386/cygming-crtbegin.c (__register_frame_info,
__deregister_frame_info, _Jv_RegisterClasses): Compile weak default
functions only for 64-bit systems.

RE: [PATCH] Work around for current Cygwin-32 Build problems

[Bernd Edlinger]

Opps...

this time with the attachment.

>
> Hi Rainer,
>
>
>
> On Wed, 30 Apr 2014 14:10:48, Rainer Orth wrote:
>>
>> Bernd Edlinger  writes:
>>
>>> 2014-04-30 Bernd Edlinger 
>>>
>>> Work around for current cygwin32 build problems (Bug gas/16858).
>>> * config/i386/cygming-crtbegin.c (__register_frame_info,
>>> __deregister_frame_info, _Jv_RegisterClasses): Compile weak default
>>> functions only for 64-bit systems, when absolutely necessary.
>>
>> The reference and rationale for the change should go into
>> cygmin-crtbegin.c, not the ChangeLog.
>>
>
> Yes, that's better of course. Thanks.
> I am going to apply the patch with the updated comment in the evening.
>
> Regards
> Bernd.
>
>
>
  

patch-pr60830.diff
Description: Binary data
2014-04-30  Bernd Edlinger  

Work around for current cygwin32 build problems.
* config/i386/cygming-crtbegin.c (__register_frame_info,
__deregister_frame_info, _Jv_RegisterClasses): Compile weak default
functions only for 64-bit systems.

[PING] [PATCH, FORTRAN] Fix PR fortran/60718

[Bernd Edlinger]

Ping...

> Date: Tue, 15 Apr 2014 13:49:37 +0200
>
> Hi Tobias,
>
> On Fri, 11 Apr 2014 16:04:51, Tobias Burnus wrote:
>>
>> Hi Tobias,
>>
>> On Fri, Apr 11, 2014 at 02:39:57PM +0200, Bernd Edlinger wrote:
>>> On Fri, 11 Apr 2014 13:37:46, Tobias Burnus wrote:
>>> Hmm,
>>>
>>> I was hoping somehow that only that test case is broken,
>>> and needs to be fixed. The target attribute is somehow simple,
>>> it implies intent(in) and the actual value will in most cases
>>> be a pointer, as in the example.
>>
>> I think that passing another nonpointer TARGET to a dummy argument
>> which has a TARGET attribute is at least as common as passing a
>> POINTER to a TARGET.
>>
>> TARGET is roughtly the opposite to the restrict qualifier. By default
>> any nonpointer variable does not alias with something else, unless
>> it has the TARGET attribute; if it has, it (its address) can then
>> be assigned to a pointer. POINTER intrinsically alias and cannot
>> have the TARGET attribute.
>>
 Pointer -> Nonalloc
 Allocatable -> Noalloc
 Nonallocatable*/Allocatable* -> Pointer with intent(in)
>>>
>>> Well, this approach does not handle intent(inout) at all.
>>
>>
>
> Now I have created a test case for the different aliasing issues
> with may arise with scalar objects.
>
> As you pointed out, also conversions of allocatable -> nonalloc,
> allocatable -> pointer and nonalloc -> pointer  turn out to
> violate the strict aliasing rules. However, conversions of
> arrays of objects with different attributes seem to be safe.
>
> I have not been able to find an example where it would be
> necessary to write the modified class object back to the original
> location. But I am not really a Fortran expert.
>
> Unfortunately there are also conversions of optional allocatable ->
> optional pointer, which complicate the whole thing quite a lot.
> I have found these in class_optional_2.f90.
>
> Boot-strapped and regression-tested on x86_64-linux-gnu.
> OK for trunk?
>
>
> Thanks
> Bernd.
>
  

[committed] Remove W_TYPE_SIZE==64 handling for i386

[Richard Sandiford]

Using longlong.h for wide-int.cc failed on 32-bit x86 because the 64-bit
x86_64 patterns were being defined for i386 too.  Specifically:

#define umul_ppmm(w1, w0, u, v) \
  __asm__ ("mul{q} %3"  \
   : "=a" ((UDItype) (w0)), \
 "=d" ((UDItype) (w1))  \
   : "%0" ((UDItype) (u)),  \
 "rm" ((UDItype) (v)))

was being used if __i386__ was defined.

Tested on x86_64-linux-gnu and i686-linux-gnu.  I put a:

#if defined (__i386__)
#error FOO
#endif

trap in the old block just to make sure that libgcc wasn't using any
of the other macros.  Approved by Richard B. on irc and applied.

Thanks,
Richard


include/
* longlong.h (__i386__): Remove W_TYPE_SIZE==64 handling.

Index: include/longlong.h
===
--- include/longlong.h  2014-04-30 15:05:37.983489787 +0100
+++ include/longlong.h  2014-04-30 15:11:38.883697625 +0100
@@ -483,7 +483,7 @@ #define UMUL_TIME 40
 #define UDIV_TIME 40
 #endif /* 80x86 */
 
-#if (defined (__x86_64__) || defined (__i386__)) && W_TYPE_SIZE == 64
+#if defined (__x86_64__) && W_TYPE_SIZE == 64
 #define add_ss(sh, sl, ah, al, bh, bl) \
   __asm__ ("add{q} {%5,%1|%1,%5}\n\tadc{q} {%3,%0|%0,%3}"  \
   : "=r" ((UDItype) (sh)), \

Re: [PATCH] New target hook: keep_leaf_when_profiled

[Andreas Krebbel]

On Wed, Apr 30, 2014 at 12:18:08PM +0200, Steven Bosscher wrote:
> On Tue, Apr 29, 2014 at 2:54 PM, Andreas Krebbel wrote:
> > diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
> > index b8ca17e..937c2d5 100644
> > --- a/gcc/doc/tm.texi
> > +++ b/gcc/doc/tm.texi
> > @@ -4953,6 +4953,10 @@ Define this macro if the code for function profiling 
> > should come before
> >  the function prologue.  Normally, the profiling code comes after.
> >  @end defmac
> >
> > +@deftypefn {Target Hook} int TARGET_KEEP_LEAF_WHEN_PROFILED (void)
... 
> bool?

Right.  That's better.

2014-04-30  Andreas Krebbel  

* target.def: Add new target hook.
* doc/tm.texi: Regenerate.
* targhooks.h (default_keep_leaf_when_profiled): Add prototype.
* targhooks.c (default_keep_leaf_when_profiled): New function.

* config/s390/s390.c (s390_keep_leaf_when_profiled): New function.
(TARGET_KEEP_LEAF_WHEN_PROFILED): Define.

diff --git a/gcc/config/s390/s390.c b/gcc/config/s390/s390.c
index cc8f32e..557f0db 100644
--- a/gcc/config/s390/s390.c
+++ b/gcc/config/s390/s390.c
@@ -10160,6 +10160,14 @@ s390_expand_builtin (tree exp, rtx target, rtx 
subtarget ATTRIBUTE_UNUSED,
 return const0_rtx;
 }
 
+/* We call mcount before the function prologue.  So a profiled leaf
+   function should stay a leaf function.  */
+
+static bool
+s390_keep_leaf_when_profiled ()
+{
+  return true;
+}
 
 /* Output assembly code for the trampoline template to
stdio stream FILE.
@@ -12163,6 +12171,9 @@ s390_option_override (void)
 #undef TARGET_LIBCALL_VALUE
 #define TARGET_LIBCALL_VALUE s390_libcall_value
 
+#undef TARGET_KEEP_LEAF_WHEN_PROFILED
+#define TARGET_KEEP_LEAF_WHEN_PROFILED s390_keep_leaf_when_profiled
+
 #undef TARGET_FIXED_CONDITION_CODE_REGS
 #define TARGET_FIXED_CONDITION_CODE_REGS s390_fixed_condition_code_regs
 
diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index b8ca17e..6c06d9f 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -4953,6 +4953,10 @@ Define this macro if the code for function profiling 
should come before
 the function prologue.  Normally, the profiling code comes after.
 @end defmac
 
+@deftypefn {Target Hook} bool TARGET_KEEP_LEAF_WHEN_PROFILED (void)
+This target hook returns true if the target wants the leaf flag for the 
current function to stay true even if it calls mcount.  This might make sense 
for targets using the leaf flag only to determine whether a stack frame needs 
to be generated or not and for which the call to mcount is generated before the 
function prologue.
+@end deftypefn
+
 @node Tail Calls
 @subsection Permitting tail calls
 @cindex tail calls
diff --git a/gcc/doc/tm.texi.in b/gcc/doc/tm.texi.in
index d793d26..b42dd12 100644
--- a/gcc/doc/tm.texi.in
+++ b/gcc/doc/tm.texi.in
@@ -3963,6 +3963,8 @@ Define this macro if the code for function profiling 
should come before
 the function prologue.  Normally, the profiling code comes after.
 @end defmac
 
+@hook TARGET_KEEP_LEAF_WHEN_PROFILED
+
 @node Tail Calls
 @subsection Permitting tail calls
 @cindex tail calls
diff --git a/gcc/final.c b/gcc/final.c
index 8c6f6ee..cf649fb 100644
--- a/gcc/final.c
+++ b/gcc/final.c
@@ -4241,7 +4241,9 @@ leaf_function_p (void)
 {
   rtx insn;
 
-  if (crtl->profile || profile_arc_flag)
+  /* Some back-ends (e.g. s390) want leaf functions to stay leaf
+ functions even if they call mcount.  */
+  if (crtl->profile && !targetm.keep_leaf_when_profiled ())
 return 0;
 
   for (insn = get_insns (); insn; insn = NEXT_INSN (insn))
diff --git a/gcc/target.def b/gcc/target.def
index 3a64cd1..793f12d 100644
--- a/gcc/target.def
+++ b/gcc/target.def
@@ -2658,6 +2658,18 @@ The default version of this hook use the target macro\n\
  bool, (void),
  default_profile_before_prologue)
 
+/* Return true if a leaf function should stay leaf even with profiling
+   enabled.  */
+DEFHOOK
+(keep_leaf_when_profiled,
+ "This target hook returns true if the target wants the leaf flag for\
+ the current function to stay true even if it calls mcount.  This might\
+ make sense for targets using the leaf flag only to determine whether a\
+ stack frame needs to be generated or not and for which the call to\
+ mcount is generated before the function prologue.",
+ bool, (void),
+ default_keep_leaf_when_profiled)
+
 /* Modify and return the identifier of a DECL's external name,
originally identified by ID, as required by the target,
(eg, append @nn to windows32 stdcall function names).
diff --git a/gcc/targhooks.c b/gcc/targhooks.c
index 79491c7..0be1978 100644
--- a/gcc/targhooks.c
+++ b/gcc/targhooks.c
@@ -1447,6 +1447,15 @@ default_get_reg_raw_mode (int regno)
   return reg_raw_mode[regno];
 }
 
+/* Return true if a leaf function should stay leaf even with profiling
+   enabled.  */
+
+bool
+default_keep_leaf_when_profiled ()
+{
+  return false;
+}
+
 /* Return true if the state of option OPTION should be stored in PCH files
and checked by default_pch_valid_p.  Store the option's current stat

C++ PATCH for c++/60951 (ICE with constexpr and aggregate init)

[Jason Merrill]

I'm not sure why I changed the use of maybe_constant_init to 
maybe_constant_value when I added the call to 
fold_non_dependent_expr_sfinae.  And that caused this problem, so I'm 
changing it back.


Tested x86_64-pc-linux-gnu, applying to trunk and 4.9.
commit f103a8af382f2dcb3022cdbefa18b963612215f5
Author: Jason Merrill 
Date:   Tue Apr 29 16:57:58 2014 -0400

	PR c++/60951
	* typeck2.c (massage_init_elt): Use maybe_constant_init.

diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c
index 5bbc2efd..044d971 100644
--- a/gcc/cp/typeck2.c
+++ b/gcc/cp/typeck2.c
@@ -1138,7 +1138,7 @@ massage_init_elt (tree type, tree init, tsubst_flags_t complain)
   /* When we defer constant folding within a statement, we may want to
  defer this folding as well.  */
   tree t = fold_non_dependent_expr_sfinae (init, complain);
-  t = maybe_constant_value (t);
+  t = maybe_constant_init (t);
   if (TREE_CONSTANT (t))
 init = t;
   return init;
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-aggr1.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-aggr1.C
new file mode 100644
index 000..7e4da11
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-aggr1.C
@@ -0,0 +1,17 @@
+// PR c++/60951
+// { dg-do compile { target c++11 } }
+
+struct Foo {
+  constexpr Foo(int x = 0) : memb(x) {}
+  int memb;
+};
+
+struct FooContainer {
+  Foo foo[2];
+};
+
+void fubar() {
+  int nonConst = 0;
+  FooContainer fooContainer;
+  fooContainer = { { 0, nonConst } };
+}

C++ PATCH for c++/60980 (value-initialization of array member)

[Jason Merrill]

My change to handle trivial but not callable constructors mistakenly 
removed the check that an object is of class type before we try to call 
its constructor.


Tested x86_64-pc-linux-gnu, applying to trunk and 4.9.
commit 3635dadac4d1e507b80f21f673530f322752df9b
Author: Jason Merrill 
Date:   Tue Apr 29 17:08:16 2014 -0400

	PR c++/60980
	* init.c (build_value_init): Don't try to call an array constructor.

diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 8b9405c..46422a5 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -339,7 +339,8 @@ build_value_init (tree type, tsubst_flags_t complain)
   gcc_assert (!processing_template_decl
 	  || (SCALAR_TYPE_P (type) || TREE_CODE (type) == ARRAY_TYPE));
 
-  if (type_build_ctor_call (type))
+  if (CLASS_TYPE_P (type)
+  && type_build_ctor_call (type))
 {
   tree ctor = build_aggr_init_expr
 	(type,
diff --git a/gcc/testsuite/g++.dg/cpp0x/defaulted49.C b/gcc/testsuite/g++.dg/cpp0x/defaulted49.C
new file mode 100644
index 000..357be41
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/defaulted49.C
@@ -0,0 +1,15 @@
+// PR c++/60980
+// { dg-do compile { target c++11 } }
+
+struct x0
+{
+  x0 () = default;
+};
+struct x1
+{
+  x0 x2[2];
+  void x3 ()
+  {
+x1 ();
+  }
+};

Re: [PATCH 2/2, x86] Add palignr support for AVX2.

[Evgeny Stupachenko]

On Tue, Apr 29, 2014 at 9:39 PM, Richard Henderson  wrote:
> On 04/29/2014 10:13 AM, Evgeny Stupachenko wrote:
>> +  /* For a rotaion permutation with one operand like: {5 6 7 0 1 2 3 4}
>> + PALIGNR is better than PSHUFB.  Check for a rotation in permutation.  
>> */
>> +  for (i = 0; i < nelt; ++i)
>> +if d->perm[(i + 1) & (nelt - 1)] - d->perm[i])) & (nelt - 1)) != 1)
>> +  return false;
>> +
>> +  min = d->perm[0];
>
> Why are you running this loop NELT times instead of NELT-1 like I suggested?
> Why is that test expression so complicated?
>
> Obviously d->perm[0] is the anchor and everything else can be computed 
> relative
> to that.  I'd expect no more than
>
>   min = d->perm[0];
>   for (i = 1; i < nelt; ++i)
> if (d->perm[i] != ((min + i) & (nelt - 1)))
>   return false;

Agree on this. The loop is less complicated.

>
> Now that I think of it,
>
>> +  /* PALIGNR of 2 128-bits registers takes only 1 instrucion.
>> + Requires SSSE3.  */
>> +  if (GET_MODE_SIZE (d->vmode) == 16)
>> +{
>> +  if (!TARGET_SSSE3)
>> +   return false;
>> +}
>> +  /* PALIGNR of 2 256-bits registers on AVX2 costs only 2 instructions:
>> + PERM and PALIGNR.  It is more profitable than 2 PSHUFB and PERM.  */
>> +  else if (GET_MODE_SIZE (d->vmode) == 32)
>> +{
>> +  if (!TARGET_AVX2)
>> +   return false;
>> +}
>> +  else
>> +return false;
>> +
>> +  if (!d->one_operand_p)
>> +return false;
>
> The comments are wrong.  Move the operand_p test to the top,
> where it should be, and they're more obviously wrong:
>
>   "must have one operand"
>   "palignr of two operands..."
>
> I think your comment
>
>   /* For a rotaion permutation with one operand like: {5 6 7 0 1 2 3 4}
>  we want to use PALIGNR.  */
>
> belongs up there instead of those two incorrect comments.
>

What I mean in the comments
  16 bytes case:
For 1 operand permutation
  Rotation will cost "palignr" which is better than "pshufb" as
has smaller opcode (6 vs 9) and always costs 1 tick (pshufb takes 3-5
ticks on some x86 archs).
For 2 operands permutation
  If "palignr" is applicable it reduces instructions from: "2
pshufb and or" to "palignr and pshufb". Profitable for the same
reasons as above.
  32 bytes case:
For 1 operand permutation
  Rotation will cost only 2 instruction "palignr and perm" which
is better than "2 pshufb and perm".
For 2 operands permutation
  If palignr is applicable it reduces instructions from: "4 pshufb
2 perm and or" to "palignr, 2 pshufb, perm and or" and profitable for
the same reasons as above.

So the final reason is the same for 1 and 2 operands case. However I
agree to extend the comments as they are not clear.
Maybe we should unite one and two operand case into 1 function? I can
submit such patch when patch 1/2 is committed.

Thanks,
Evgeny

>
>
> r~

Re: [PATCH, PR52252] Vectorization for load/store groups of size 3.

[Evgeny Stupachenko]

Ping.

On Fri, Apr 18, 2014 at 2:05 PM, Evgeny Stupachenko  wrote:
> Hi,
>
> Merged with current master the patch passes bootstrap and is giving
> expected gains.
> Patch and new tests are attached.
>
> ChangeLog:
>
> 2014-04-18  Evgeny Stupachenko  
>
> * tree-vect-data-refs.c (vect_grouped_store_supported): New
> check for stores group of length 3.
> (vect_permute_store_chain): New permutations for stores group of
> length 3.
> (vect_grouped_load_supported): New check for loads group of length 3.
> (vect_permute_load_chain): New permutations for loads group of length 
> 3.
> * tree-vect-stmts.c (vect_model_store_cost): Change cost
> of vec_perm_shuffle for the new permutations.
> (vect_model_load_cost): Ditto.
>
> ChangeLog for testsuite:
>
> 2014-04-18  Evgeny Stupachenko  
>
>PR tree-optimization/52252
>* gcc.dg/vect/pr52252-ld.c: Test on loads group of size 3.
>* gcc.dg/vect/pr52252-st.c: Test on stores group of size 3.
>
> Evgeny
>
> On Thu, Mar 6, 2014 at 6:44 PM, Evgeny Stupachenko  wrote:
>> Missed attachment.
>>
>> On Thu, Mar 6, 2014 at 6:42 PM, Evgeny Stupachenko  
>> wrote:
>>> I've separated the patch into 2: cost model tuning and load/store
>>> groups parallelism.
>>> SLM tuning was partially introduced in the patch:
>>> http://gcc.gnu.org/ml/gcc-patches/2014-03/msg00226.html
>>> The patch introducing vectorization for load/store groups of size 3 
>>> attached.
>>>
>>> Is it ok for stage1?
>>>
>>> ChangeLog:
>>>
>>> 2014-03-06  Evgeny Stupachenko  
>>>
>>>* tree-vect-data-refs.c (vect_grouped_store_supported): New
>>>check for stores group of length 3.
>>>(vect_permute_store_chain): New permutations for stores group of
>>>length 3.
>>>(vect_grouped_load_supported): New check for loads group of length 3.
>>>(vect_permute_load_chain): New permutations for loads group of 
>>> length 3.
>>>* tree-vect-stmts.c (vect_model_store_cost): Change cost
>>>of vec_perm_shuffle for the new permutations.
>>>(vect_model_load_cost): Ditto.
>>>
>>>
>>>
>>> On Tue, Feb 11, 2014 at 7:19 PM, Richard Biener  wrote:
 On Tue, 11 Feb 2014, Evgeny Stupachenko wrote:

> Missed patch attached in plain-text.
>
> I have copyright assignment on file with the FSF covering work on GCC.
>
> Load/stores groups of length 3 is the most frequent non-power-of-2
> case. It is used in RGB image processing (like test case in PR52252).
> For sure we can extend the patch to length 5 and more. However, this
> potentially affect performance on some other architectures and
> requires larger testing. So length 3 it is just first step.The
> algorithm in the patch could be modified for a general case in several
> steps.
>
> I understand that the patch should wait for the stage 1, however since
> its ready we can discuss it right now and make some changes (like
> general size of group).

 Other than that I'd like to see a vectorizer hook querying the cost of a
 vec_perm_const expansion instead of adding vec_perm_shuffle
 (thus requires the constant shuffle mask to be passed as well
 as the vector type).  That's more useful for other uses that
 would require (arbitrary) shuffles.

 Didn't look at the rest of the patch yet - queued in my review
 pipeline.

 Thanks,
 Richard.

> Thanks,
> Evgeny
>
> On Tue, Feb 11, 2014 at 5:00 PM, Richard Biener  wrote:
> >
> > On Tue, 11 Feb 2014, Evgeny Stupachenko wrote:
> >
> > > Hi,
> > >
> > > The patch gives an expected 3 times gain for the test case in the 
> > > PR52252
> > > (and even 6 times for AVX2).
> > > It passes make check and bootstrap on x86.
> > > spec2000/spec2006 got no regressions/gains on x86.
> > >
> > > Is this patch ok?
> >
> > I've worked on generalizing the permutation support in the light
> > of the availability of the generic shuffle support in the IL
> > but hit some road-blocks in the way code-generation works for
> > group loads with permutations (I don't remember if I posted all 
> > patches).
> >
> > This patch seems to be to a slightly different place but it again
> > special-cases a specific permutation.  Why's that?  Why can't we
> > support groups of size 7 for example?  So - can this be generalized
> > to support arbitrary non-power-of-two load/store groups?
> >
> > Other than that the patch has to wait for stage1 to open again,
> > of course.  And it misses a testcase.
> >
> > Btw, do you have a copyright assignment on file with the FSF covering
> > work on GCC?
> >
> > Thanks,
> > Richard.
> >
> > > ChangeLog:
> > >
> > > 2014-02-11  Evgeny Stupachenko  
> > >
> > > * target.h (vect_cost_for_stmt): Defining new c

Re: [PATCH], RFC, add support for __float128/__ibm128 types on PowerPC

[Michael Meissner]

On Wed, Apr 30, 2014 at 07:56:07AM +0200, Marc Glisse wrote:
> Minor detail:
> 
> +  if ((flags & OPTION_MASK_FLOAT128) != 0)
> +rs6000_define_or_undefine_macro (define_p, "__FLOAT128__");
> 
> I recently added __SIZEOF_FLOAT128__ to the x86 target to advertise
> the availability of __float128, it would be good if we had a common
> macro (it can be in addition to __FLOAT128__). If you really don't
> like it, we can ask x86 maintainers if they like __FLOAT128__.

I would prefer to have common names between the x86 and PowerPC, since our two
ports are the main two that had long double types that weren't either a
straight IEEE 64-bit or IEEE 128-bit representation.

I can certainly switch the PowerPC to use the same name as the x86.  When I
began the port, I didn't notice there was a define that said the __float128
type was available, so I just picked a name out of the air.

I do think when we agree on a name, it would be helpful if quad.h in
libgcc/soft-fp (which comes from the glibc sources) used that to use the
__float128 type.  Unfortunately, given the IBM double-double size is 128-bits,
the attribute((mode(TF))) won't work for us.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

[patch] fix ppc spe bootstrap error in dwf_regno

[Cesar Philippidis]

I've been working on a patch to switch a few ppc targets to use softfp
in libgcc instead of fpbit and I noticed that ppc-none-eabispe fails to
bootstrap in both trunk and 4.9. The regression was introduced in
. Essentially,
the assert for a hard register in dwf_regno () is not valid on ppc spe
targets. In rs6000_dwarf_register_span (), there is a note stating:

  /* The duality of the SPE register size wreaks all kinds of havoc.
 This is a way of distinguishing r0 in 32-bits from r0 in
 64-bits.  */

and the function adds 1200 to regno, which makes that register appear to
be a pseudo. This causes problems in dwf_regno (), which asserts that
reg is a hard register. Since the dwarf2 pass is executed after register
allocation it should, in theory, be ok for the rs6000 backend to be
using a pseudo register for this application.

Is this patch ok for trunk and 4.9? If so, please commit since I don't
have an svn account.

Cesar
2014-04-30  Cesar Philippidis  

gcc/
* dwarf2cfi.c (dwf_regno): Don't assert reg is a pseudo
register.


diff --git a/gcc/dwarf2cfi.c b/gcc/dwarf2cfi.c
index 4180890..40ef0e2 100644
--- a/gcc/dwarf2cfi.c
+++ b/gcc/dwarf2cfi.c
@@ -906,7 +906,6 @@ notice_eh_throw (rtx insn)
 static inline unsigned
 dwf_regno (const_rtx reg)
 {
-  gcc_assert (REGNO (reg) < FIRST_PSEUDO_REGISTER);
   return DWARF_FRAME_REGNUM (REGNO (reg));
 }
 

Re: [wide-int] fix 32-bit x86 builds

[Richard Sandiford]

Mike Stump  writes:
> We changed the underlying type a while back, and it matters on 32-bit
> pointer machines that use long long for a HOST_WIDE_INT… Caught by
> fold-checking, thanks fold checking.
>
> This is the tree-vrp problem, I think this was seen on arm as well.

Trivial follow-up to keep within the 80-column limit.  Committed as obvious.

Thanks,
Richard


Index: gcc/tree.c
===
--- gcc/tree.c  (revision 209936)
+++ gcc/tree.c  (working copy)
@@ -1959,7 +1959,8 @@
 make_int_cst_stat (int len, int ext_len MEM_STAT_DECL)
 {
   tree t;
-  int length = (ext_len - 1) * sizeof (HOST_WIDE_INT) + sizeof (struct 
tree_int_cst);
+  int length = ((ext_len - 1) * sizeof (HOST_WIDE_INT)
+   + sizeof (struct tree_int_cst));
 
   gcc_assert (len);
   record_node_allocation_statistics (INTEGER_CST, length);

Re: Changes for if-convert to recognize simple conditional reduction.

[Yuri Rumyantsev]

Thanks a lot Richard for you review.
I did all proposed changes, checked that bootstrap and regression
testing did not show new failures.
Updated patch is attached.

Best regards.
Yuri.

2014-04-30 16:40 GMT+04:00 Richard Biener :
> On Tue, Apr 29, 2014 at 4:29 PM, Yuri Rumyantsev  wrote:
>> 2014-04-28 16:16 GMT+04:00 Richard Biener :
>>> On Thu, Apr 17, 2014 at 3:09 PM, Yuri Rumyantsev  wrote:
 Hi All,

 We implemented enhancement for if-convert phase to recognize the
 simplest conditional reduction and to transform it vectorizable form,
 e.g. statement
 if (A[i] != 0) num+= 1; will be recognized.
 A new test-case is also provided.

 Bootstrapping and regression testing did not show any new failures.
>>>
>>> Clever.  Can you add a testcase with a non-constant but invariant
>>> reduction value and one with a variable reduction value as well?
>>>
>> [Yuri]
>> I added another testcase to demonstrate ability of new algorithm, i.e.
>> it transforms   if (a[i] != 0)   sum += a[i];
>> to unconditional form without check on zero. Note also that any checks
>> on non-reduction operand were deleted.
>>
>>> +  if (!(is_cond_scalar_reduction (arg_0, &reduc, &op0, &op1)
>>> +   || is_cond_scalar_reduction (arg_1, &reduc, &op0, &op1)))
>>>
>>> Actually one of the args should be defined by a PHI node in the
>>> loop header and the PHI result should be the PHI arg on the
>>> latch edge, so I'd pass both PHI args to the predicate and do
>>> the decision on what the reduction op is there (you do that
>>> anyway).  The pattern matching is somewhat awkward
>>>
>> [Yuri]
>> I changed prototype of 'is_cond_scalar_reduction'  and now we have
>> only one call:
>> +  if (!is_cond_scalar_reduction (phi, &reduc, &op0, &op1))
>>
>>> +  /* Consider only conditional reduction.  */
>>> +  bb = gimple_bb (stmt);
>>> +  if (!bb_has_predicate (bb))
>>> +return false;
>>> +  if (is_true_predicate (bb_predicate (bb)))
>>> +return false;
>>>
>>> should be replaced by matching the PHI structure
>>>
>>> loop-header:
>>>   reduc_1 = PHI <..., reduc_2>
>>>   ...
>>>   if (..)
>>> reduc_3 = ...
>>>   reduc_2 = PHI 
>>>
>> [Yuri]
>>In fact, I re-wrote this function completely as you proposed using
>> PHI structure matching.
>>
>>> +  lhs = gimple_assign_lhs (stmt);
>>> +  if (TREE_CODE (lhs) != SSA_NAME)
>>> +return false;
>>>
>>> always true, in fact lhs == arg.
>>>
>> [Yuri]
>> Fixed.
>>
>>> +  if (SSA_NAME_VAR (lhs) == NULL)
>>> +return false;
>>>
>> [Yuri]
>> Deleted.
>>> no need to check that (or later verify SSA_NAME_VAR equivalency), not
>>> sure why you think you need that.
>>>
>>> +  if (!single_imm_use (lhs, &use, &use_stmt))
>>> +return false;
>>> +  if (gimple_code (use_stmt) != GIMPLE_PHI)
>>> +return false;
>>>
>>> checking has_single_use (arg) is enough.  The above is error-prone
>>> wrt debug statements.
>>>
>> [Yuri] Only proposed check is used:
>> +  if (!has_single_use (lhs))
>> +return false;
>>
>>> +  if (reduction_op == PLUS_EXPR &&
>>> +  TREE_CODE (r_op2) == SSA_NAME)
>>>
>>> && goes to the next line
>>>
>> [Yuri]
>> Fixed.
>>
>>> +  if (TREE_CODE (r_op2) != INTEGER_CST && TREE_CODE (r_op2) != REAL_CST)
>>> +return false;
>>>
>>> any reason for this check?  The vectorizer can cope with
>>> loop invariant non-constant values as well (at least).
>>>
>> [Yuri]
>> This checks were deleted, i.e. any operand is acceptable.
>>
>>> +  /* Right operand is constant, check that left operand is equal to lhs.  
>>> */
>>> +  if (SSA_NAME_VAR (lhs) !=  SSA_NAME_VAR (r_op1))
>>> +return false;
>>>
>>> see above - that looks weird.
>>>
>> [Yuri]
>> This code was deleted.
>>> Note that I think you may introduce undefined overflow in
>>> unconditionally executing the increment.  So you need to
>>> make sure to re-write the increment in unsigned arithmetic
>>> (for integral types, that is).
>> [Yuri]
>> I did not catch your point: if we have
>> if (cond) s += val;
>> it will be transformed to
>> s += (cond? val: 0)
>> which looks like completely equivalent to original stmt.
>
> Ah indeed.
>
>>>
>>> Thanks,
>>> Richard.
>>>
>>>
>>>
 Is it OK for trunk?

 gcc/ChangeLog:
 2014-04-17  Yuri Rumyantsev  

 * tree-if-conv.c (is_cond_scalar_reduction): New function.
 (convert_scalar_cond_reduction): Likewise.
 (predicate_scalar_phi): Add recognition and transformation
 of simple conditioanl reduction to be vectorizable.

 gcc/testsuite/ChangeLog:
 2014-04-17  Yuri Rumyantsev  

 * gcc.dg/cond-reduc.c: New test.
>>
>> New patch is added which includes also new test to detect
>> vectorization of conditional reduction with non-invariant operand. All
>> remarks found by Richard were fixed.
>>
>> Bootstrap and regression testing did not show any new failures.
>> Is it OK for trunk?
>
> Ok with minor stylistic changes:
>
> +  struct loop *loop = (gimple_bb (phi))->loop_father;
>
> no () aroun

Re: [PATCH][RFC] Always require a 64bit HWI

[Jeff Law]

On 04/30/14 02:16, Richard Biener wrote:

On Tue, 29 Apr 2014, Jeff Law wrote:


On 04/29/14 05:21, Richard Biener wrote:


The following patch forces the availability of a 64bit HWI
(without applying the cleanups that result from this).  I propose
this exact patch for a short time to get those that are affected
and do not want to be affected scream.

But honestly I don't see any important host architecture that
not already requires a 64bit HWI.

Another concern is that the host compiler may not provide a
64bit type.  I'm not sure that this is an issue nowadays
(even though C++98 doesn't have 'long long', so it's maybe
more an issue now with C++ than it was previously with
requiring C89).  But given that it wasn't an issue for
the existing 64bit HWI requiring host archs it shouldn't
be an issue now.

The benefit of this change is obviously the cleanup that
can result from it - especially getting rid of code
generation dependences on the host (!need_64bit_hwi
doesn't mean we force a 32bit hwi).  As followup
we can replace HOST_WIDE_INT and its friends with
int64_t variants and appear less confusing to
newcomers (and it's also less characters to type! yay!).

We'd still retain HOST_WIDEST_FAST_INT, and as Kenny
said elsewhere wide-int should internally operate on that,
not on the eventually slow int64_t.  But that's a separate
issue.

So - any objections?

Thanks,
Richard.

2014-04-29  Richard Biener  

libcpp/
* configure.ac: Always set need_64bit_hwint to yes.
* configure: Regenerated.

* config.gcc: Always set need_64bit_hwint to yes.

No objections.  The requirement for 64 bit HWINT traces its origins back to
the MIPS R5900 target IIRC.  It's probably well past the time when we should
just bite the bullet and make HWINT 64 bits across the board.

If the host compiler doesn't support 64-bit HWINT, then it seems to me the
host compiler can be used to bootstrap 4.9, which can then be used to
bootstrap more modern GCCs.

And like you I suspect it's really not going to be an issue in practice.


I realized I forgot to copy gcc-patches, so done now (patch copied
below again for reference).

I propose to apply the patch after the wide-int merge for a short
period of time and then followup with a patch to remove the
need_64bit_hwint code (I'll make sure to send that out for review
before applying this one).

Testing coverage for non-64bit hwi configs is really low these
days (I know of only 32bit hppa-*-* that is still built and
tested semi-regularly - Dave, I suppose the host compiler
has a 64bit long long type there, right?).
My recollection is that HP aCC supports long long, but I don't recall 
when support for that was introduced.  I'm really trying hard to forget 
hpux-isms.


Plus, they can always start the bootstrapping process with GCC 4.9.

jeff

Go patch committed: Use backend interface for built-in functions

[Ian Lance Taylor]

This patch from Chris Manghane changes the Go frontend to use the
backend interface for built-in functions.  Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu.  Committed to mainline.

Ian


2014-04-30  Chris Manghane  

* go-gcc.cc: #include "langhooks.h".
(Gcc_backend::Gcc_backend): Add constructor.
(Gcc_backend::lookup_function): New function.
(Gcc_backend::define_builtin): New private function.
(Gcc_backend::gcc_backend): Remove.
(go_get_backend): Use new to create new Gcc_backend.


Index: gcc/go/go-gcc.cc
===
--- gcc/go/go-gcc.cc	(revision 209819)
+++ gcc/go/go-gcc.cc	(working copy)
@@ -34,6 +34,7 @@
 #include "basic-block.h"
 #include "gimple-expr.h"
 #include "gimplify.h"
+#include "langhooks.h"
 #include "toplev.h"
 #include "output.h"
 #include "real.h"
@@ -131,6 +132,8 @@ class Blabel : public Gcc_tree
 class Gcc_backend : public Backend
 {
  public:
+  Gcc_backend();
+
   // Types.
 
   Btype*
@@ -425,6 +428,9 @@ class Gcc_backend : public Backend
   bool
   function_set_body(Bfunction* function, Bstatement* code_stmt);
 
+  Bfunction*
+  lookup_builtin(const std::string&);
+
   void
   write_global_definitions(const std::vector&,
const std::vector&,
@@ -459,6 +465,14 @@ class Gcc_backend : public Backend
 
   tree
   non_zero_size_type(tree);
+
+private:
+  void
+  define_builtin(built_in_function bcode, const char* name, const char* libname,
+		 tree fntype, bool const_p);
+
+  // A mapping of the GCC built-ins exposed to GCCGo.
+  std::map builtin_functions_;
 };
 
 // A helper function.
@@ -469,6 +483,172 @@ get_identifier_from_string(const std::st
   return get_identifier_with_length(str.data(), str.length());
 }
 
+// Define the built-in functions that are exposed to GCCGo.
+
+Gcc_backend::Gcc_backend()
+{
+  /* We need to define the fetch_and_add functions, since we use them
+ for ++ and --.  */
+  tree t = this->integer_type(BITS_PER_UNIT, 1)->get_tree();
+  tree p = build_pointer_type(build_qualified_type(t, TYPE_QUAL_VOLATILE));
+  this->define_builtin(BUILT_IN_SYNC_ADD_AND_FETCH_1, "__sync_fetch_and_add_1",
+		   NULL, build_function_type_list(t, p, t, NULL_TREE),
+		   false);
+
+  t = this->integer_type(BITS_PER_UNIT * 2, 1)->get_tree();
+  p = build_pointer_type(build_qualified_type(t, TYPE_QUAL_VOLATILE));
+  this->define_builtin(BUILT_IN_SYNC_ADD_AND_FETCH_2, "__sync_fetch_and_add_2",
+		   NULL, build_function_type_list(t, p, t, NULL_TREE),
+		   false);
+
+  t = this->integer_type(BITS_PER_UNIT * 4, 1)->get_tree();
+  p = build_pointer_type(build_qualified_type(t, TYPE_QUAL_VOLATILE));
+  this->define_builtin(BUILT_IN_SYNC_ADD_AND_FETCH_4, "__sync_fetch_and_add_4",
+		   NULL, build_function_type_list(t, p, t, NULL_TREE),
+		   false);
+
+  t = this->integer_type(BITS_PER_UNIT * 8, 1)->get_tree();
+  p = build_pointer_type(build_qualified_type(t, TYPE_QUAL_VOLATILE));
+  this->define_builtin(BUILT_IN_SYNC_ADD_AND_FETCH_8, "__sync_fetch_and_add_8",
+		   NULL, build_function_type_list(t, p, t, NULL_TREE),
+		   false);
+
+  // We use __builtin_expect for magic import functions.
+  this->define_builtin(BUILT_IN_EXPECT, "__builtin_expect", NULL,
+		   build_function_type_list(long_integer_type_node,
+		long_integer_type_node,
+		long_integer_type_node,
+		NULL_TREE),
+		   true);
+
+  // We use __builtin_memcmp for struct comparisons.
+  this->define_builtin(BUILT_IN_MEMCMP, "__builtin_memcmp", "memcmp",
+		   build_function_type_list(integer_type_node,
+		const_ptr_type_node,
+		const_ptr_type_node,
+		size_type_node,
+		NULL_TREE),
+		   false);
+
+  // We provide some functions for the math library.
+  tree math_function_type = build_function_type_list(double_type_node,
+		 double_type_node,
+		 NULL_TREE);
+  tree math_function_type_long =
+build_function_type_list(long_double_type_node, long_double_type_node,
+			 long_double_type_node, NULL_TREE);
+  tree math_function_type_two = build_function_type_list(double_type_node,
+			 double_type_node,
+			 double_type_node,
+			 NULL_TREE);
+  tree math_function_type_long_two =
+build_function_type_list(long_double_type_node, long_double_type_node,
+			 long_double_type_node, NULL_TREE);
+  this->define_builtin(BUILT_IN_ACOS, "__builtin_acos", "acos",
+		   math_function_type, true);
+  this->define_builtin(BUILT_IN_ACOSL, "__builtin_acosl", "acosl",
+		   math_function_type_long, true);
+  this->define_builtin(BUILT_IN_ASIN, "__builtin_asin", "asin",
+		   math_function_type, true);
+  this->define_builtin(BUILT_IN_ASINL, "__builtin_asinl", "asinl",
+		   math_function_type_long, true);
+  this->define_builtin(BUILT_IN_ATAN, "__builtin_atan", "atan",
+		   math_function_type, true);
+  this->define_builtin(BUILT_IN_ATANL, "__builtin_atanl"

Re: [PATCH][RFC] Always require a 64bit HWI

[John David Anglin]

On 4/30/2014 12:00 PM, Jeff Law wrote:
My recollection is that HP aCC supports long long, but I don't recall 
when support for that was introduced.  I'm really trying hard to 
forget hpux-isms.


Plus, they can always start the bootstrapping process with GCC 4.9.


I can't remember but without ansi support one needs to start with
an early 4.X version.

Dave

--
John David Anglindave.ang...@bell.net

Re: Changes for if-convert to recognize simple conditional reduction.

[H.J. Lu]

On Wed, Apr 30, 2014 at 8:50 AM, Yuri Rumyantsev  wrote:
> Thanks a lot Richard for you review.
> I did all proposed changes, checked that bootstrap and regression
> testing did not show new failures.
> Updated patch is attached.
>

Does this help

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21998

-- 
H.J.

[aarch64] Remove aarch64_function_profiler prototype

[Ryan Mansfield]

aarch64_function_profiler was removed in rev203028 but the prototype was 
left behind. If OK, can someone apply? Thanks.


Regards,

Ryan Mansfield

2014-04-30  Ryan Mansfield  

* config/aarch64/aarch64-protos.h (aarch64_function_profiler): 
Remove.



Index: config/aarch64/aarch64-protos.h
===
--- config/aarch64/aarch64-protos.h (revision 209944)
+++ config/aarch64/aarch64-protos.h (working copy)
@@ -223,7 +223,6 @@
 void aarch64_expand_mov_immediate (rtx, rtx);
 void aarch64_expand_prologue (void);
 void aarch64_expand_vector_init (rtx, rtx);
-void aarch64_function_profiler (FILE *, int);
 void aarch64_init_cumulative_args (CUMULATIVE_ARGS *, const_tree, rtx,
   const_tree, unsigned);
 void aarch64_init_expanders (void);

Go patch committed: Remove GCC langhooks from Go frontend

[Ian Lance Taylor]

This patch from Chris Manghane removes the GCC langhooks from the Go
frontend.  Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu.  Committed to mainline.

Ian


2014-04-30  Chris Manghane  

* go-lang.c (go_langhook_type_for_size): Do it here, rather than
calling into Go frontend.
(go_langhook_type_for_mode): Likewise.
* go-c.h (go_type_for_size, go_type_for_mode): Don't declare.


Index: gcc/go/go-lang.c
===
--- gcc/go/go-lang.c	(revision 209392)
+++ gcc/go/go-lang.c	(working copy)
@@ -288,7 +288,38 @@ go_langhook_parse_file (void)
 static tree
 go_langhook_type_for_size (unsigned int bits, int unsignedp)
 {
-  return go_type_for_size (bits, unsignedp);
+  tree type;
+  if (unsignedp)
+{
+  if (bits == INT_TYPE_SIZE)
+type = unsigned_type_node;
+  else if (bits == CHAR_TYPE_SIZE)
+type = unsigned_char_type_node;
+  else if (bits == SHORT_TYPE_SIZE)
+type = short_unsigned_type_node;
+  else if (bits == LONG_TYPE_SIZE)
+type = long_unsigned_type_node;
+  else if (bits == LONG_LONG_TYPE_SIZE)
+type = long_long_unsigned_type_node;
+  else
+type = make_unsigned_type(bits);
+}
+  else
+{
+  if (bits == INT_TYPE_SIZE)
+type = integer_type_node;
+  else if (bits == CHAR_TYPE_SIZE)
+type = signed_char_type_node;
+  else if (bits == SHORT_TYPE_SIZE)
+type = short_integer_type_node;
+  else if (bits == LONG_TYPE_SIZE)
+type = long_integer_type_node;
+  else if (bits == LONG_LONG_TYPE_SIZE)
+type = long_long_integer_type_node;
+  else
+type = make_signed_type(bits);
+}
+  return type;
 }
 
 static tree
@@ -309,9 +340,40 @@ go_langhook_type_for_mode (enum machine_
   return NULL_TREE;
 }
 
-  type = go_type_for_mode (mode, unsignedp);
-  if (type)
-return type;
+  // FIXME: This static_cast should be in machmode.h.
+  enum mode_class mc = static_cast(GET_MODE_CLASS(mode));
+  if (mc == MODE_INT)
+return go_langhook_type_for_size(GET_MODE_BITSIZE(mode), unsignedp);
+  else if (mc == MODE_FLOAT)
+{
+  switch (GET_MODE_BITSIZE (mode))
+	{
+	case 32:
+	  return float_type_node;
+	case 64:
+	  return double_type_node;
+	default:
+	  // We have to check for long double in order to support
+	  // i386 excess precision.
+	  if (mode == TYPE_MODE(long_double_type_node))
+	return long_double_type_node;
+	}
+}
+  else if (mc == MODE_COMPLEX_FLOAT)
+{
+  switch (GET_MODE_BITSIZE (mode))
+	{
+	case 64:
+	  return complex_float_type_node;
+	case 128:
+	  return complex_double_type_node;
+	default:
+	  // We have to check for long double in order to support
+	  // i386 excess precision.
+	  if (mode == TYPE_MODE(complex_long_double_type_node))
+	return complex_long_double_type_node;
+	}
+}
 
 #if HOST_BITS_PER_WIDE_INT >= 64
   /* The middle-end and some backends rely on TImode being supported
Index: gcc/go/gofrontend/gogo-tree.cc
===
--- gcc/go/gofrontend/gogo-tree.cc	(revision 209941)
+++ gcc/go/gofrontend/gogo-tree.cc	(working copy)
@@ -35,88 +35,3 @@ saw_errors()
 {
   return errorcount != 0 || sorrycount != 0;
 }
-
-// Return the integer type to use for a size.
-
-GO_EXTERN_C
-tree
-go_type_for_size(unsigned int bits, int unsignedp)
-{
-  const char* name;
-  switch (bits)
-{
-case 8:
-  name = unsignedp ? "uint8" : "int8";
-  break;
-case 16:
-  name = unsignedp ? "uint16" : "int16";
-  break;
-case 32:
-  name = unsignedp ? "uint32" : "int32";
-  break;
-case 64:
-  name = unsignedp ? "uint64" : "int64";
-  break;
-default:
-  if (bits == POINTER_SIZE && unsignedp)
-	name = "uintptr";
-  else
-	return NULL_TREE;
-}
-  Type* type = Type::lookup_integer_type(name);
-  return type_to_tree(type->get_backend(go_get_gogo()));
-}
-
-// Return the type to use for a mode.
-
-GO_EXTERN_C
-tree
-go_type_for_mode(enum machine_mode mode, int unsignedp)
-{
-  // FIXME: This static_cast should be in machmode.h.
-  enum mode_class mc = static_cast(GET_MODE_CLASS(mode));
-  if (mc == MODE_INT)
-return go_type_for_size(GET_MODE_BITSIZE(mode), unsignedp);
-  else if (mc == MODE_FLOAT)
-{
-  Type* type;
-  switch (GET_MODE_BITSIZE (mode))
-	{
-	case 32:
-	  type = Type::lookup_float_type("float32");
-	  break;
-	case 64:
-	  type = Type::lookup_float_type("float64");
-	  break;
-	default:
-	  // We have to check for long double in order to support
-	  // i386 excess precision.
-	  if (mode == TYPE_MODE(long_double_type_node))
-	return long_double_type_node;
-	  return NULL_TREE;
-	}
-  return type_to_tree(type->get_backend(go_get_gogo()));
-}
-  else if (mc == MODE_COMPLEX_FLOAT)
-{
-  Type *type;
-  switch (GET_MODE_BITSIZE (mode))
-	{
-	case 64:
-	  type = Type::l

Re: [PATCH] A new reload-rewrite pattern recognizer for GCC vectorizer.

[Cong Hou]

Thank you for reminding me the omp possibility. Yes, in this case my
pattern is incorrect, because I assume all aliases will be resolved by
alias checks, which may not be true with omp.

LOOP_VINFO_NO_DATA_DEPENDENCIES or LOOP_REQUIRES_VERSIONING_FOR_ALIAS
may not help here because vect_pattern_recog() is called prior to
vect_analyze_data_ref_dependences() in vect_analyze_loop_2().

So can we detect if omp is used in the pattern recognizer? Like
checking loop->force_vectorize? Is there any other case in which my
assumption does not hold?


thanks,
Cong


On Sat, Apr 26, 2014 at 12:54 AM, Jakub Jelinek  wrote:
> On Thu, Apr 24, 2014 at 05:32:54PM -0700, Cong Hou wrote:
>> In this patch a new reload-rewrite pattern detector is composed to
>> handle the following pattern in the loop being vectorized:
>>
>>x = *p;
>>...
>>y = *p;
>>
>>or
>>
>>*p = x;
>>...
>>y = *p;
>>
>> In both cases, *p is reloaded because there may exist other defs to
>> another memref that may alias with p.  However, aliasing is eliminated
>> with alias checks.  Then we can safely replace the last statement in
>> above cases by y = x.
>
> Not safely, at least not for #pragma omp simd/#pragma simd/#pragma ivdep
> loops if alias analysis hasn't proven there is no aliasing.
>
> So, IMNSHO you need to guard this with LOOP_VINFO_NO_DATA_DEPENDENCIES,
> assuming it has been computed at that point already (otherwise you need to
> do it elsewhere).
>
> Consider:
>
> void
> foo (int *p, int *q)
> {
>   int i;
>   #pragma omp simd safelen(16)
>   for (i = 0; i < 128; i++)
> {
>   int x = *p;
>   *q += 8;
>   *p = *p + x;
>   p++;
>   q++;
> }
> }
>
> It is valid to call the above with completely unrelated p and q, but
> also e.g. p == q, or q == p + 16 or p == q + 16.
> Your patch would certainly break it e.g. for p == q.
>
> Jakub

Re: [Testsuite] getpid in gcc.c-torture/execute/pr58419.c

[Jeff Law]

On 04/25/14 03:16, Dhakshinamoorthy, Soundararajan wrote:

2014-04-25  Soundararajan Dhakshinamoorthy

* gcc.c-torture/execute/pr58419.c: Adjust the test to work with bare 
metal targets. The
test code references to functions that is not implemented for the 
avr target (getpid()).

THanks.  I tweaked the ChangeLog slightly and installed your patch.

Jeff

Re: [C PATCH] Another column info tweak (PR c/56989)

[Jeff Law]

On 04/29/14 15:19, Marek Polacek wrote:

At least for function calls we can use their location info
to generate better diagnostics.

Regtested/bootstrapped on x86_64-linux, ok for trunk?

2014-04-29  Marek Polacek  

PR c/56989
* c-typeck.c (default_conversion): Use better location for
error call.

* gcc.dg/pr56989.c: New test.

OK.  Thanks
Jeff

Re: [C PATCH] Warn about booleans in C89 mode (PR c/29467)

[Jeff Law]

On 04/29/14 15:18, Marek Polacek wrote:

Boolean types were introduced with the advent of C99, which means
we should pedwarn when _Bool is used in ansi/c89/c90/iso9899:1990
mode with -Wpedantic, similarly what we do for _Complex.
We don't warn for system headers, so it's possible to include
 and then use bool.  I made use of that to fix some
fortran tests (it's not possible to add dg-options, since these
tests we're using C files via dg-additional-source).

Regtested/bootstrapped on x86_64-linux, ok for trunk?

2014-04-29  Marek Polacek  

PR c/29467
* c-decl.c (declspecs_add_type): Pedwarn if boolean types are used
in C89 mode.

* gcc.dg/pr29467.c: New test.
* gcc.dg/declspec-13.c: Renumber some dg-warnings.  Add dg-warnings
about boolean types.
* gfortran.dg/bind_c_usage_24_c.c: Include .  Change _Bool
to bool.
* gfortran.dg/c_f_pointer_logical_driver.c: Change _Bool to bool.

OK.  Thanks.

Jeff

Re: [C PATCH] Improve warn msg (PR c/43395)

[Jeff Law]

On 04/29/14 15:17, Marek Polacek wrote:

It's correct to warn about returning an address of a local label,
but it's clumsy to say it's "local variable.  We can easily distinguish
between a label and a variable.

Regtested/bootstrapped on x86_64-linux, ok for trunk?

2014-04-29  Marek Polacek  

PR c/43395
c/
* c-typeck.c (c_finish_return): Distinguish between label and variable
when warning about returning local address.
cp/
* typeck.c (maybe_warn_about_returning_address_of_local): Distinguish
between label and variable when warning about returning local address.
testsuite/
* c-c++-common/pr43395.c: New test.

OK.  Thanks.

Jeff

Re: [PATCH] New target hook: keep_leaf_when_profiled

[Jeff Law]

On 04/30/14 08:15, Andreas Krebbel wrote:

On Wed, Apr 30, 2014 at 12:18:08PM +0200, Steven Bosscher wrote:

On Tue, Apr 29, 2014 at 2:54 PM, Andreas Krebbel wrote:

diff --git a/gcc/doc/tm.texi b/gcc/doc/tm.texi
index b8ca17e..937c2d5 100644
--- a/gcc/doc/tm.texi
+++ b/gcc/doc/tm.texi
@@ -4953,6 +4953,10 @@ Define this macro if the code for function profiling 
should come before
  the function prologue.  Normally, the profiling code comes after.
  @end defmac

+@deftypefn {Target Hook} int TARGET_KEEP_LEAF_WHEN_PROFILED (void)

...

bool?


Right.  That's better.

2014-04-30  Andreas Krebbel  

* target.def: Add new target hook.
* doc/tm.texi: Regenerate.
* targhooks.h (default_keep_leaf_when_profiled): Add prototype.
* targhooks.c (default_keep_leaf_when_profiled): New function.

* config/s390/s390.c (s390_keep_leaf_when_profiled): New function.
(TARGET_KEEP_LEAF_WHEN_PROFILED): Define.

OK for the trunk.

Thanks,
Jeff

Re: [C PATCH] Another locus improvements (PR c/60257)

[Jeff Law]

On 04/26/14 03:15, Marek Polacek wrote:

Another column info improvements, this time for initializer
warnings.  warning_init and add_pending_init had to gain new location
parameter.

What is worth mentioning is that the "(near initialization for X)"
message seems next to useless to me now with caret diagnostics (?).

Regtested/bootstrapped on powerpc64-unknown-linux-gnu and
x86_64-unknown-linux-gnu, ok for trunk?

2014-04-25  Marek Polacek  

PR c/60257
* c-typeck.c (warning_init): Add location_t parameter.  Call
warning_at instead of warning.
(push_init_level): Pass input_location to warning_init.
(add_pending_init): Add location_t parameter.  Pass loc to
warning_init.
(set_nonincremental_init): Pass input_location to add_pending_init.
(set_nonincremental_init_from_string): Likewise.
(output_init_element): Pass loc to warning_init and to
add_pending_init.

* gcc.dg/pr60257.c: New test.

OK.  Thanks.

Jeff

Re: [C PATCH] Improve error on attrs after declarator in a fndef (PR c/60915)

[Jeff Law]

On 04/24/14 08:31, Marek Polacek wrote:

This PR is about not very clear error message when one tries to
add attributes *after* the declarator in a function definition.
cc1plus already handles this well, so I used the same message.

Regtested/bootstrapped on x86_64-linux, ok for trunk?

2014-04-24  Marek Polacek  

PR c/60915
* c-parser.c (c_parser_declaration_or_fndef): Give better error if
function-definition has an attribute after the declarator.

* gcc.dg/pr60915.c: New test.
No strong opinions on which of the two is better.  Slight preference to 
sync with g++.  You choose.  Either is OK for the trunk.

jeff

Re: [C PATCH] Add -Wdiscarded-qualifiers (PR c/43245)

[Jeff Law]

On 04/29/14 15:20, Marek Polacek wrote:

I think we should have an option to turn off various "discards
qualifier" warnings (only for C), or to make them hard errors.
This patch adds new option, called -Wdiscarded-qualifiers (as
suggested in the BZ) for that.

Regtested/bootstrapped on x86_64-linux, ok for trunk?

2014-04-29  Marek Polacek  

PR c/43245
* doc/invoke.texi: Document -Wdiscarded-qualifiers.
c-family/
* c.opt (Wdiscarded-qualifiers): Add.
c/
* c-typeck.c (convert_for_assignment): Pass OPT_Wdiscarded_qualifiers
instead of 0 to WARN_FOR_QUALIFIERS.
testsuite/
* gcc.dg/pr43245.c: New test.

OK.  Thanks.

Jeff

Re: [PATCH 00/89] Compile-time gimple-checking

[Jeff Law]

On 04/23/14 08:32, Richard Biener wrote:


Also I see you introduce a const_FOO class with every FOO one.
I wonder whether, now that we have C++, can address const-correctness
in a less awkward way than with a typedef.  Can you try to go back
in time and see why we did with that in the first place?  ISTR that
it was "oh, if we were only using C++ we wouldn't need to jump through
that hoop".


To followup myself here, it's because 'tree' is a typedef to a pointer
and thus 'const tree' is different from 'const tree_node *'.

Right.



Not sure why we re-introduced the 'mistake' of making 'tree' a pointer
when we introduced 'gimple'.  If we were to make 'gimple' the class
type itself we can use gimple *, const gimple * and also const gimple &
(when a NULL pointer is not expected).

It wasn't ever really discussed to the best of my recollection.



Anyway, gazillion new typedefs are ugly :/  (typedefs are ugly)
Yea, can't argue with that.  However, do we want to ask David to fix up 
the gimple vs gimple * vs const gimple * vs const gimple & as a 
prerequisite for this patchset or are you comfortable going forward with 
the patchset, then researching if there's a cleaner way to handle the 
const/typedef issues?


jeff

Re: wide-int testing, go bits

[Ian Lance Taylor]

On Wed, Apr 30, 2014 at 1:31 PM, Mike Stump  wrote:
>
> I am seeing the below on wide-int.  The go teststsuite violates one of the 
> principals of goo test suite hygiene, the names thought arbitrary, should be 
> stable.  These names are not stable across differing build locations.  
> s,.*/testsuite/,,g is approximately what it needs.  Thanks.


Fixed like so.  Tested on x86_64-unknown-linux-gnu.  Committed to
mainline.

Ian


2014-04-30  Ian Lance Taylor  

* go.test/go-test.exp (go-gc-tests): For rundir, pass extra files
in go_compile_args rather than in argument to go-torture-execute.
Index: go.test/go-test.exp
===
--- go.test/go-test.exp	(revision 209392)
+++ go.test/go-test.exp	(working copy)
@@ -676,8 +676,10 @@ proc go-gc-tests { } {
 		lappend del "[file rootname [file tail [lindex $p 1]]].o"
 		}
 		set dg-do-what-default "link"
-		set go_compile_args $del
-		go-torture-execute [lrange $last 1 end]
+		set go_compile_args ""
+		append go_compile_args [lrange $last 2 end]
+		append go_compile_args $del
+		go-torture-execute [lindex $last 1]
 		foreach f $del {
 		file delete $f
 		}

[PATCH, libgfortran] Use -std=gnu11

[Janne Blomqvist]

Hello,

the attached patch switches libgfortran C sources to be compiled in
gnu11 mode instead of gnu99. As the 4.9 release notes
http://gcc.gnu.org/gcc-4.9/changes.html say,

"ISO C11 support is now at a similar level of completeness to ISO C99
support: substantially complete modulo bugs, extended identifiers
(supported except for corner cases when -fextended-identifiers is
used), floating-point issues (mainly but not entirely relating to
optional C99 features from Annexes F and G) and the optional Annexes K
(Bounds-checking interfaces) and L (Analyzability)."

An overview of new features in C11 can be seen e.g. at

https://en.wikipedia.org/wiki/C11_%28C_standard_revision%29

And the current status of C11 support in GCC is at

http://gcc.gnu.org/wiki/C11Status

Similar to the case of C99 support, we cannot rely on the new library
features being present, but the language features can be used, e.g.
_Noreturn, _Static_assert, anonymous structs and unions could
potentially be useful for libgfortran.

Since libgfortran is compiled by the stage 3 compiler, there shouldn't
be any bootstrapping issues wrt. older (stage 1) compilers.

Ok for trunk?

2014-05-01  Janne Blomqvist  

* configure.ac (AM_CFLAGS): Use -std=gnu11.
(CFLAGS): Likewise.
* configure: Regenerated.


-- 
Janne Blomqvist
diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
index 24dbf2b..2126285 100644
--- a/libgfortran/configure.ac
+++ b/libgfortran/configure.ac
@@ -139,12 +139,13 @@ AM_PROG_CC_C_O
 # Add -Wall -fno-repack-arrays -fno-underscoring if we are using GCC.
 if test "x$GCC" = "xyes"; then
   AM_FCFLAGS="-I . -Wall -Werror -fimplicit-none -fno-repack-arrays 
-fno-underscoring"
-  ## We like to use C99 routines when available.  This makes sure that
+  ## We like to use C11 and C99 routines when available.  This makes
+  ## sure that
   ## __STDC_VERSION__ is set such that libc includes make them available.
-  AM_CFLAGS="-std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes 
-Wold-style-definition -Wextra -Wwrite-strings"
+  AM_CFLAGS="-std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes 
-Wold-style-definition -Wextra -Wwrite-strings"
   ## Compile the following tests with the same system header contents
   ## that we'll encounter when compiling our own source files.
-  CFLAGS="-std=gnu99 $CFLAGS"
+  CFLAGS="-std=gnu11 $CFLAGS"
 fi
 AC_SUBST(AM_FCFLAGS)
 AC_SUBST(AM_CFLAGS)

Re: Warn when returning the address of a temporary (middle-end)

[Joseph S. Myers]

On Sat, 5 Apr 2014, Marc Glisse wrote:

> One hard part is avoiding duplicate warnings. Replacing the address with 0 is
> a convenient way to do that, so I did it both for my new warning and for the
> existing C/C++ ones. The patch breaks gfortran.dg/warn_target_lifetime_2.f90

That's not safe the way you do it; you lose side effects from the original 
return value.  Consider a testcase such as:

extern void exit (int);
extern void abort (void);

int *
f (void)
{
  int a[10];
  return &a[(exit (0), 0)];
}

int
main (void)
{
  f ();
  abort ();
}

(which produces the existing warning, but which has behavior fully defined 
to exit with status 0).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH][RFC] Always require a 64bit HWI

[John David Anglin]

On 30-Apr-14, at 4:16 AM, Richard Biener wrote:


Testing coverage for non-64bit hwi configs is really low these
days (I know of only 32bit hppa-*-* that is still built and
tested semi-regularly - Dave, I suppose the host compiler
has a 64bit long long type there, right?).


I'm OK with this change as I know this causes support issues.  The HP  
ansi
C compiler and aCC have long long.  This is not an issue for linux.  I  
believe

people can find HP-UX GCC binaries on the net.

Dave
--
John David Anglin   dave.ang...@bell.net

[Patch] Simple change to include/longlong.h to quiet warnings.

[Steve Ellcey]

I would like to make a small change to include/longlong.h for glibc but
I undertand that the GCC version of this file is the master one and 
should be changed first, is that right?

My change is to check __mips16 with "defined (__mips16)" instead of
just "__mips16" so that we don't get a warning when compiling with
-Wundef (like glibc is now doing).

Ok to checkin?  I will submit it for checkin to the binutils and
glibc groups as well once it is approved here.

Steve Ellcey
sell...@mips.com


2014-04-30  Steve Ellcey  

* include/longlong.h: Use 'defined()' to check __mips16.


diff --git a/include/longlong.h b/include/longlong.h
index 0770290..31f88cb 100644
--- a/include/longlong.h
+++ b/include/longlong.h
@@ -848,7 +848,7 @@ extern UDItype __umulsidi3 (USItype, USItype);
 #define UMUL_TIME 10
 #define UDIV_TIME 100
 
-#if (__mips == 32 || __mips == 64) && ! __mips16
+#if (__mips == 32 || __mips == 64) && ! defined (__mips16)
 #define count_leading_zeros(COUNT,X)   ((COUNT) = __builtin_clz (X))
 #define COUNT_LEADING_ZEROS_0 32
 #endif

Re: [PATCH 2/6] don't have gengtype autocreate allocation macros for variably sized types

[Trevor Saunders]

On Wed, Apr 30, 2014 at 11:18:18AM +0200, Richard Biener wrote:
> On Wed, Apr 30, 2014 at 11:04 AM, Laurynas Biveinis
>  wrote:
> >> ISTR we went to typed allocs as part of a transition which not
> >> fully materialised?
> >
> > Yes. I had plans to replace the call-based GC marker routines with a
> > generic routine that operates on a type marker stored next to the
> > object. That enables partial, generational, etc GC.
> 
> Ah, ok.  It would also naturally allow finalization.

 Yeah, one thing that occured to me is we could just use a vtable for
 the identifier, and get virtual functions on some types "for free".  We
 could also use the vtable to make inheritance and dispatch simpler
 removing the manual type mangling, but I think we could get most of the
 same benefit just with function overloads.

> >>  I actually dislike that we get back the
> >> ugly casts here - so, can we keep the allocators or use
> >> a macro similar to the XNEW family?
> >
> > My 2c suggestion would be to keep the typed allocators at least until
> > a new plan for GC is developed.
> 
> The current patches keep them in some way.  But the use of
> C++ (and its more complex types) made types more difficult
> to access.  I suppose integrating gengtype with the C++ frontend
> would be the only reasonable way out here (eh, and maybe that
> then naturally develops to C++11 garbage collection support - who
> knows).

Or we could go in the direction of supporting compile time type
introspection in C++, which I think has been asked for by other people.
However even using C++ as it is today we should be able to make gengtype
a good bit simpler if we use c++ more in the code it outputs.

thanks!

Trev

> 
> Thanks,
> Richard.
> 
> > --
> > Laurynas


signature.asc
Description: Digital signature

Re: [Patch] Simple change to include/longlong.h to quiet warnings.

[Andrew Pinski]

On Wed, Apr 30, 2014 at 4:22 PM, Steve Ellcey  wrote:
>
> I would like to make a small change to include/longlong.h for glibc but
> I undertand that the GCC version of this file is the master one and
> should be changed first, is that right?

GCC version is not the master either.  GMP has the master version of
longlong.h.  But it looks like it does not have the code below at all.

Thanks,
Andrew Pinski


>
> My change is to check __mips16 with "defined (__mips16)" instead of
> just "__mips16" so that we don't get a warning when compiling with
> -Wundef (like glibc is now doing).
>
> Ok to checkin?  I will submit it for checkin to the binutils and
> glibc groups as well once it is approved here.
>
> Steve Ellcey
> sell...@mips.com
>
>
> 2014-04-30  Steve Ellcey  
>
> * include/longlong.h: Use 'defined()' to check __mips16.
>
>
> diff --git a/include/longlong.h b/include/longlong.h
> index 0770290..31f88cb 100644
> --- a/include/longlong.h
> +++ b/include/longlong.h
> @@ -848,7 +848,7 @@ extern UDItype __umulsidi3 (USItype, USItype);
>  #define UMUL_TIME 10
>  #define UDIV_TIME 100
>
> -#if (__mips == 32 || __mips == 64) && ! __mips16
> +#if (__mips == 32 || __mips == 64) && ! defined (__mips16)
>  #define count_leading_zeros(COUNT,X)   ((COUNT) = __builtin_clz (X))
>  #define COUNT_LEADING_ZEROS_0 32
>  #endif

libgo patch committed: Use $GOC for compiler characteristics

[Ian Lance Taylor]

This patch from Peter Collingbourne changes the libgo configury and make
to test $GOC (the target gccgo) for compiler characteristics rather than
$CC.  Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.

Ian


diff -r 703f1d4d9227 libgo/Makefile.am
--- a/libgo/Makefile.am	Wed Apr 30 13:54:36 2014 -0400
+++ b/libgo/Makefile.am	Wed Apr 30 20:22:56 2014 -0400
@@ -962,7 +962,7 @@
 	rm -f version.go.tmp
 	echo "package runtime" > version.go.tmp
 	echo 'const defaultGoroot = "$(prefix)"' >> version.go.tmp
-	echo 'const theVersion = "'`$(CC) --version | sed 1q`'"' >> version.go.tmp
+	echo 'const theVersion = "'`$(GOC) --version | sed 1q`'"' >> version.go.tmp
 	echo 'const theGoarch = "'$(GOARCH)'"' >> version.go.tmp
 	echo 'const theGoos = "'$(GOOS)'"' >> version.go.tmp
 	$(SHELL) $(srcdir)/../move-if-change version.go.tmp version.go
diff -r 703f1d4d9227 libgo/configure.ac
--- a/libgo/configure.ac	Wed Apr 30 13:54:36 2014 -0400
+++ b/libgo/configure.ac	Wed Apr 30 20:22:56 2014 -0400
@@ -88,7 +88,7 @@
   nover_glibgo_toolexecdir='${libdir}/gcc/${host_alias}'
   nover_glibgo_toolexeclibdir='${libdir}'
 fi
-multi_os_directory=`$CC -print-multi-os-directory`
+multi_os_directory=`$GOC -print-multi-os-directory`
 case $multi_os_directory in
   .) ;; # Avoid trailing /.
   *) nover_glibgo_toolexeclibdir=${nover_glibgo_toolexeclibdir}/${multi_os_directory} ;;

Go patch committed: Use backend interface for error detection

[Ian Lance Taylor]

This patch from Chris Manghane changes the Go frontend to use the
backend interface to detect whether any errors have been seen.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.

Ian


2014-04-30  Chris Manghane  

* go-backend.c: #include "diagnostics.h".
(saw_errors): New function.
* go-c.h (saw_errors): Declare.
* Make-lang.in (GO_OBJS): Remove go/gogo-tree.o.


Index: gcc/go/Make-lang.in
===
--- gcc/go/Make-lang.in	(revision 209392)
+++ gcc/go/Make-lang.in	(working copy)
@@ -60,7 +60,6 @@ GO_OBJS = \
 	go/go-linemap.o \
 	go/go-optimize.o \
 	go/go.o \
-	go/gogo-tree.o \
 	go/gogo.o \
 	go/import.o \
 	go/import-archive.o \
Index: gcc/go/gofrontend/gogo-tree.cc
===
--- gcc/go/gofrontend/gogo-tree.cc	(revision 209392)
+++ gcc/go/gofrontend/gogo-tree.cc	(working copy)
@@ -1,37 +0,0 @@
-// gogo-tree.cc -- convert Go frontend Gogo IR to gcc trees.
-
-// Copyright 2009 The Go Authors. All rights reserved.
-// Use of this source code is governed by a BSD-style
-// license that can be found in the LICENSE file.
-
-#include "go-system.h"
-
-#include "toplev.h"
-#include "tree.h"
-#include "stringpool.h"
-#include "stor-layout.h"
-#include "varasm.h"
-#include "gimple-expr.h"
-#include "gimplify.h"
-#include "tree-iterator.h"
-#include "cgraph.h"
-#include "langhooks.h"
-#include "convert.h"
-#include "output.h"
-#include "diagnostic.h"
-#include "go-c.h"
-
-#include "types.h"
-#include "expressions.h"
-#include "statements.h"
-#include "runtime.h"
-#include "backend.h"
-#include "gogo.h"
-
-// Whether we have seen any errors.
-
-bool
-saw_errors()
-{
-  return errorcount != 0 || sorrycount != 0;
-}
Index: gcc/go/go-backend.c
===
--- gcc/go/go-backend.c	(revision 209392)
+++ gcc/go/go-backend.c	(working copy)
@@ -29,6 +29,7 @@ along with GCC; see the file COPYING3.
 #include "output.h"	/* for assemble_string */
 #include "target.h"
 #include "common/common-target.h"
+#include "diagnostic.h"
 
 #include "go-c.h"
 
@@ -48,6 +49,14 @@ along with GCC; see the file COPYING3.
 /* This file holds all the cases where the Go frontend needs
information from gcc's backend.  */
 
+/* Return whether or not GCC has reported any errors.  */
+
+bool
+saw_errors (void)
+{
+  return errorcount != 0 || sorrycount != 0;
+}
+
 /* Return the alignment in bytes of a struct field of type T.  */
 
 unsigned int
Index: gcc/go/go-c.h
===
--- gcc/go/go-c.h	(revision 209945)
+++ gcc/go/go-c.h	(working copy)
@@ -46,6 +46,8 @@ extern void go_write_globals (void);
 
 extern void go_preserve_from_gc (tree);
 
+extern bool saw_errors (void);
+
 extern const char *go_localize_identifier (const char*);
 
 extern unsigned int go_field_alignment (tree);

[PATCH] gengtype: Support explicit pointers in template arguments

[David Malcolm]

Currently, gengtype does not support template arguments that are
explicitly pointers, such as:
  static GTY(()) vec test_gimple; giving this
error:
  ../../src/gcc/gimple-expr.c:902: parse error: expected a string constant or 
',', have '*' instead 
requiring them to be typedefs.

This patch removes this restriction, supporting up to a single pointer
in each template argument.

It also adds support for inheritance, allowing:
  static GTY(()) vec *test_phis;
where the generated gt-FOO.c file contains:

  void
  gt_ggc_mx (struct gimple_statement_phi *& x)
  {
if (x)
  gt_ggc_mx_gimple_statement_base ((void *) x);
  }

i.e. handling the subclass by calling the marking function for the base
class.

Doing so uncovered an issue within write_user_func_for_structure_ptr,
which would unconditionally write out a func.  This would lead to
gt-FOO.c containing duplicate functions e.g.:
gtype-desc.c:280: multiple definition of `gt_ggc_mx(gimple_statement_base*&)'
if more than one GTY template type referenced such a type; for example like 
this:

  static GTY(()) vec *test_old_style_gimple;
  static GTY(()) vec *test_new_style_gimple;

where "gimple" is just an alias for "gimple_statement_base *".  This
could be worked around by ensuring that the source tree consistently
uses vec<> of just one kind, but for robustness the patch also makes
write_user_func_for_structure_ptr idempotent, so it only writes out the
func once for each (struct, which-of-ggc/pch) combination.

Motivation:
In the "Compile-time gimple-checking" discussion, Richi asked me to look
at eliminating the const_gimple typedef in favor of having "gimple" be
the struct, thus making the pointer to a gimple be explicit in the type:
  http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01520.html
as in:
  http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01632.html
> [...] And I never liked the
> const_ typedef variants that were introduced.  The main reason for
> them was probably to avoid all the churn of replacing the tree pointer
> typedef with a tree (non-pointer) typedef.  The mistake was to
> repeat that for 'gimple' ...

I'm attempting a patch for that, but in the meantime, this patch adds
the needed support to gengtype.

Successfully bootstrapped®tested on x86_64-unknown-linux-gnu (Fedora
20).

OK for trunk?

Dave
>From 8d7538cb6676a2f158ea9be56820a1d57eb34b82 Mon Sep 17 00:00:00 2001
From: David Malcolm 
Date: Wed, 30 Apr 2014 15:46:16 -0400
Subject: [PATCH] gengtype: Support explicit pointers in template arguments

gcc/
	* gengtype-parse.c (require3): New.
	(require_template_declaration): Update to support optional single *
	on a type.

	* gengtype.c (get_ultimate_base_class): Add a non-const overload.
	(create_user_defined_type): Handle a single level of explicit
	pointerness within template arguments.
	(struct write_types_data): Add field "kind".
	(filter_type_name): Handle "*" character.
	(write_user_func_for_structure_ptr): Require a write_types_data
	rather than just a prefix string, so that we can look up the kind
	of the wtd and use it as an index into wrote_user_func_for_ptr,
	ensuring that such functions are written at most once.  Support
	subclasses by invoking the marking function of the ultimate base
	class.
	(write_user_func_for_structure_body): Require a write_types_data
	rather than just a prefix string, so that we can pass this to
	write_user_func_for_structure_ptr.
	(write_func_for_structure): Likewise.
	(ggc_wtd): Add initializer of new "kind" field.
	(pch_wtd): Likewise.

	* gengtype.h (enum write_types_kinds): New.
	(struct type): Add field wrote_user_func_for_ptr to the "s"
	union member.
---
 gcc/gengtype-parse.c | 38 ++---
 gcc/gengtype.c   | 69 +---
 gcc/gengtype.h   | 12 +
 3 files changed, 102 insertions(+), 17 deletions(-)

diff --git a/gcc/gengtype-parse.c b/gcc/gengtype-parse.c
index bb7bcf7..a374ef4 100644
--- a/gcc/gengtype-parse.c
+++ b/gcc/gengtype-parse.c
@@ -197,6 +197,23 @@ require2 (int t1, int t2)
   return v;
 }
 
+/* If the next token does not have one of the codes T1, T2 or T3, report a
+   parse error; otherwise return the token's value.  */
+static const char *
+require3 (int t1, int t2, int t3)
+{
+  int u = token ();
+  const char *v = advance ();
+  if (u != t1 && u != t2 && u != t3)
+{
+  parse_error ("expected %s, %s or %s, have %s",
+		   print_token (t1, 0), print_token (t2, 0),
+		   print_token (t3, 0), print_token (u, v));
+  return 0;
+}
+  return v;
+}
+
 /* Near-terminals.  */
 
 /* C-style string constant concatenation: STRING+
@@ -228,7 +245,9 @@ string_seq (void)
 
 /* The caller has detected a template declaration that starts
with TMPL_NAME.  Parse up to the closing '>'.  This recognizes
-   simple template declarations of the form ID.
+   simple template declarations of the form ID,
+   potentially with a single level of indirection e.g.
+ ID.
It does not try to parse anything mo

Re: [PATCH, PR58066] preferred_stack_boundary update for tls expanded call

[Wei Mi]

Ping. Is pr58066-3.patch or pr58066-4.patch ok for trunk?

Thanks,
Wei.

>> I attached the patch which combined your two patches and the fix in
>> legitimize_tls_address. I tried pr58066.c and c.i in ia32/x32/x86_64,
>> the code looked fine. Do you think it is ok?
>>
>> Thanks,
>> Wei.
>
> Either pr58066-3.patch or pr58066-4.patch looks good to me.
>
> Thanks.
>
> --
> H.J.

Re: [PATCH] Builtins handling in IVOPT

[Wei Mi]

Ping.

Thanks,
Wei.

On Tue, Dec 17, 2013 at 11:34 AM, Wei Mi  wrote:
> Ping.
>
> Thanks,
> Wei.
>
> On Mon, Dec 9, 2013 at 9:54 PM, Wei Mi  wrote:
>> Ping.
>>
>> Thanks,
>> wei.
>>
>> On Sat, Nov 23, 2013 at 10:46 AM, Wei Mi  wrote:
>>> bootstrap and regression of the updated patch pass.
>>>
>>> On Sat, Nov 23, 2013 at 12:05 AM, Wei Mi  wrote:
 On Thu, Nov 21, 2013 at 12:19 AM, Zdenek Dvorak
  wrote:
> Hi,
>
>> This patch works on the intrinsic calls handling issue in IVOPT 
>> mentioned here:
>> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01295.html
>>
>> In find_interesting_uses_stmt, it changes
>>
>> arg = expr
>> __builtin_xxx (arg)
>>
>> to
>>
>> arg = expr;
>> tmp = addr_expr (mem_ref(arg));
>> __builtin_xxx (tmp, ...)
>
> this looks a bit confusing (and wasteful) to me. It would make more sense 
> to
> just record the argument as USE_ADDRESS and do the rewriting in 
> rewrite_use_address.
>
> Zdenek

 I updated the patch. The gimple changing part is now moved to
 rewrite_use_address. Add support for plain address expr in addition to
 reference expr in find_interesting_uses_address.

 bootstrap and testing is going on.

 2013-11-22  Wei Mi  

 * expr.c (expand_expr_addr_expr_1): Not to split TMR.
 (expand_expr_real_1): Ditto.
 * targhooks.c (default_builtin_has_mem_ref_p): Default
 builtin.
 * tree-ssa-loop-ivopts.c (builtin_has_mem_ref_p): New function.
 (rewrite_use_address): Add TMR for builtin.
 (find_interesting_uses_stmt): Special handling of builtins.
 * gimple-expr.c (is_gimple_address): Add handling of TMR.
 * gimple-expr.h (is_gimple_addressable): Ditto.
 * config/i386/i386.c (ix86_builtin_has_mem_ref_p): New target hook.
 (ix86_atomic_assign_expand_fenv): Ditto.
 (ix86_expand_special_args_builtin): Special handling of TMR for
 builtin.
 * target.def (builtin_has_mem_ref_p): New hook.
 * doc/tm.texi.in: Ditto.
 * doc/tm.texi: Generated.

 2013-11-22  Wei Mi  

 * gcc.dg/tree-ssa/ivopt_5.c: New test.

 Index: testsuite/gcc.dg/tree-ssa/ivopt_5.c
 ===
 --- testsuite/gcc.dg/tree-ssa/ivopt_5.c (revision 0)
 +++ testsuite/gcc.dg/tree-ssa/ivopt_5.c (revision 0)
 @@ -0,0 +1,21 @@
 +/* { dg-do compile { target {{ i?86-*-* x86_64-*-* } && lp64 } } } */
 +/* { dg-options "-O2 -m64 -fdump-tree-ivopts-details" } */
 +
 +/* Make sure only one iv is selected after IVOPT.  */
 +
 +#include 
 +extern __m128i arr[], d[];
 +void test (void)
 +{
 +unsigned int b;
 +for (b = 0; b < 1000; b += 2) {
 +  __m128i *p = (__m128i *)(&d[b]);
 +  __m128i a = _mm_load_si128(&arr[4*b+3]);
 +  __m128i v = _mm_loadu_si128(p);
 +  v = _mm_xor_si128(v, a);
 +  _mm_storeu_si128(p, v);
 +}
 +}
 +
 +/* { dg-final { scan-tree-dump-times "PHI >>> +/* { dg-final { cleanup-tree-dump "ivopts" } } */
 Index: targhooks.c
 ===
 --- targhooks.c (revision 204792)
 +++ targhooks.c (working copy)
 @@ -566,6 +566,13 @@ default_builtin_reciprocal (unsigned int
  }

  bool
 +default_builtin_has_mem_ref_p (int built_in_function ATTRIBUTE_UNUSED,
 +  int i ATTRIBUTE_UNUSED)
 +{
 +  return false;
 +}
 +
 +bool
  hook_bool_CUMULATIVE_ARGS_mode_tree_bool_false (
 cumulative_args_t ca ATTRIBUTE_UNUSED,
 enum machine_mode mode ATTRIBUTE_UNUSED,
 Index: expr.c
 ===
 --- expr.c  (revision 204792)
 +++ expr.c  (working copy)
 @@ -7467,7 +7467,19 @@ expand_expr_addr_expr_1 (tree exp, rtx t
   tem = fold_build_pointer_plus (tem, TREE_OPERAND (exp, 1));
 return expand_expr (tem, target, tmode, modifier);
}
 +case TARGET_MEM_REF:
 +  {
 +   int old_cse_not_expected;
 +   addr_space_t as
 + = TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (exp, 
 0;

 +   result = addr_for_mem_ref (exp, as, true);
 +   old_cse_not_expected = cse_not_expected;
 +   cse_not_expected = true;
 +   result = memory_address_addr_space (tmode, result, as);
 +   cse_not_expected = old_cse_not_expected;
 +   return result;
 +  }
  case CONST_DECL:
/* Expand the initializer like constants above.  */
result = XEXP (expand_expr_constant (DECL_INITIAL (exp),
 @@ -9526,9 +9538,13 @@ expand_expr

Re: [Patch] Simple change to include/longlong.h to quiet warnings.

[Richard Sandiford]

"Steve Ellcey "  writes:
> I would like to make a small change to include/longlong.h for glibc but
> I undertand that the GCC version of this file is the master one and 
> should be changed first, is that right?

The copyright says:

  This file is part of the GNU C Library.

but maybe that isn't true?  Anyway, I committed a patch to longlong.h
only yesterday and no-one complained, so let's go with it.

Patch looks good to me, thanks.

Richard

Re: [PATCH, PR58066] preferred_stack_boundary update for tls expanded call

[Uros Bizjak]

On Thu, May 1, 2014 at 6:42 AM, Wei Mi  wrote:
> Ping. Is pr58066-3.patch or pr58066-4.patch ok for trunk?

None of these patches have correct ChangeLog entries. Please follow
the rules, outlined in http://gcc.gnu.org/contribute.html (Submitting
Patches section), otherwise your patches will be simply ignored.

>>> I attached the patch which combined your two patches and the fix in
>>> legitimize_tls_address. I tried pr58066.c and c.i in ia32/x32/x86_64,
>>> the code looked fine. Do you think it is ok?
>>>
>>> Thanks,
>>> Wei.
>>
>> Either pr58066-3.patch or pr58066-4.patch looks good to me.

pr58066-4 patch is definitely not OK. I wonder, how it works at all,
since you can't split the insn to the same pattern. The generic code
detects this condition and forces ICE (IIRC: this is the reason for
UNSPEC_DIV_ALREADY_SPLIT tag in divmod).

>From pr58066-3 patch:

-;; Local dynamic of a single variable is a lose.  Show combine how
-;; to convert that back to global dynamic.
-
-(define_insn_and_split "*tls_local_dynamic_32_once"
-  [(set (match_operand:SI 0 "register_operand" "=a")
-(plus:SI
- (unspec:SI [(match_operand:SI 1 "register_operand" "b")
- (match_operand 2 "constant_call_address_operand" "z")]
-UNSPEC_TLS_LD_BASE)
- (const:SI (unspec:SI
-[(match_operand 3 "tls_symbolic_operand")]
-UNSPEC_DTPOFF
-   (clobber (match_scratch:SI 4 "=d"))
-   (clobber (match_scratch:SI 5 "=c"))
-   (clobber (reg:CC FLAGS_REG))]
-  ""
-  "#"
-  ""
-  [(parallel
- [(set (match_dup 0)
-   (unspec:SI [(match_dup 1) (match_dup 3) (match_dup 2)]
-  UNSPEC_TLS_GD))
-  (clobber (match_dup 4))
-  (clobber (match_dup 5))
-  (clobber (reg:CC FLAGS_REG))])])

Why did you remove this splitter?

Please do not write:

+{
+  ix86_tls_descriptor_calls_expanded_in_cfun = true;
+})

but use a short form:

+  "ix86_tls_descriptor_calls_expanded_in_cfun = true;")

Please also add a testcase (from one of the previous mails):

--- testsuite/gcc.dg/pr58066.c (revision 0)
+++ testsuite/gcc.dg/pr58066.c (revision 0)

Put this test to gcc.target/i386 directory ...
@@ -0,0 +1,18 @@
+/* { dg-do compile { target {{ i?86-*-* x86_64-*-* } && { ! ia32 } } } } */

... to avoid target selector.

+/* { dg-options "-fPIC -O2" } */
+
+/* Check whether the stack frame starting addresses of tls expanded calls
+   in foo and goo are 16bytes aligned.  */
+static __thread char ccc1;
+void* foo()
+{
+ return &ccc1;
+}
+
+__thread char ccc2;
+void* goo()
+{
+ return &ccc2;
+}
+
+/* { dg-final { scan-assembler-times ".cfi_def_cfa_offset 16" 2 } } */

Please repost the complete patch with a proper ChangeLog.

Uros.