RE: [PATCH][3/3] Fix PR54733 Optimize endian independent load/store
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.
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)?
I'll change to avoid such a replacement.
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.
Best regards,
Thomas
Re: [PATCH, MIPS] Alter default number of single-precision registers
Matthew Fortune matthew.fort...@imgtec.com 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.
You need to document the new option in the texi file.
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.
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.
Thanks,
Richard
Re: [PATCH] Implement -fsanitize=float-divide-by-zero
On Tue, Apr 29, 2014 at 11:34:50AM +0200, Marek Polacek wrote:
Ran ubsan testsuite (-m32/-m64) + bootstrap-ubsan on x86_64-linux, ok now?
2014-04-29 Marek Polacek pola...@redhat.com
* gcc.c (sanitize_spec_function): Handle SANITIZE_FLOAT_DIVIDE.
* builtins.def: Initialize builtins even for SANITIZE_FLOAT_DIVIDE.
* flag-types.h (enum sanitize_code): Add SANITIZE_FLOAT_DIVIDE.
* opts.c (common_handle_option): Add -fsanitize=float-divide-by-zero.
c-family/
* c-ubsan.c (ubsan_instrument_division): Handle REAL_TYPEs. Perform
INT_MIN / -1 sanitization only for integer types.
c/
* c-typeck.c (build_binary_op): Call ubsan_instrument_division
also when SANITIZE_FLOAT_DIVIDE is on.
cp/
* typeck.c (cp_build_binary_op): Call ubsan_instrument_division
even when SANITIZE_FLOAT_DIVIDE is on. Set doing_div_or_mod even
for non-integer types.
testsuite/
* c-c++-common/ubsan/div-by-zero-5.c: Fix formatting.
* c-c++-common/ubsan/float-div-by-zero-1.c: New test.
+int
+main (void)
+{
+ volatile float a = 1.3f;
+ volatile double b = 0.0;
+ volatile int c = 4;
+
+ a / b;
+ a / 0.0;
+ 2.7f / b;
+ 3.6 / (b = 0.0, b);
+ c / b;
+ b / c;
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.
Jakub
RE: [PATCH][3/3] Fix PR54733 Optimize endian independent load/store
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
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.
Sorry I made some mistakes in my reply. Signedness does matter and even
if the sign would be fine, the load size could be different from the target
size. It's the same kind of difference as size Vs range in the
symbolic_number structure.
Consider the following case:
int
foo (char *a)
{
return a[0] | (a[1] 8);
}
The load size in this case would be 16 bits while the target size would be
32 bits. Therefore a conversion would be needed.
Best regards,
Thomas
Re: [PATCH] Implement -fsanitize=float-divide-by-zero
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
Richard Sandiford rdsandif...@googlemail.com writes:
Matthew Fortune matthew.fort...@imgtec.com 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
Matthew Fortune matthew.fort...@imgtec.com writes:
Richard Sandiford rdsandif...@googlemail.com writes:
Matthew Fortune matthew.fort...@imgtec.com 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
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 rguent...@suse.de 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 rguent...@suse.de 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
Dear Tobias, On 27 April 2014 20:56, Tobias Burnus bur...@net-b.de 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
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
[ 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
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
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 paolo.carl...@oracle.com
PR c++/60999
* pt.c (maybe_begin_member_template_processing): Use
uses_template_parms.
/testsuite
2014-04-30 Paolo Carlini paolo.carl...@oracle.com
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 typename A
+struct foo
+{
+};
+
+template
+struct fooint
+{
+ static constexpr int code = 42;
+ unsigned int bar = static_castunsigned int(code);
+};
+
+fooint a;
Re: [AArch64/ARM 3/3] Add execution tests of ARM ZIP Intrinsics
On Thu, Mar 27, 2014 at 10:53 AM, Alan Lawrence alan.lawre...@arm.com 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 alan.lawre...@arm.com
* 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
+# http://www.gnu.org/licenses/.
+
+# 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 { cleanup-saved-temps } } */
diff --git a/gcc/testsuite/gcc.target/arm/simd/vzipqf32_1.c
Re: [PATCH 2/6] don't have gengtype autocreate allocation macros for variably sized types
On Wed, Apr 30, 2014 at 11:04 AM, Laurynas Biveinis laurynas.bivei...@gmail.com 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
On Wed, Apr 23, 2014 at 9:32 PM, Alan Lawrence alan.lawre...@arm.com 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 alan.lawre...@arm.com
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 } */
+
+#include arm_neon.h
+#include ../../aarch64/simd/extq_p8.x
+
+/* { dg-final { scan-assembler-times vext\.8\[
Re: [AArch64/ARM 3/3] Add execution tests of ARM UZP Intrinsics
On Thu, Mar 27, 2014 at 5:28 PM, Alan Lawrence alan.lawre...@arm.com 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 alan.lawre...@arm.com
* 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\]+,
?\[qQ\]\[0-9\]+!?\(?:\[ \t\]+@\[a-zA-Z0-9 \]+\)?\n 1 } } */
+/* { dg-final { cleanup-saved-temps } } */
diff --git
Re: [Patch, Fortran] Fix an issue with CLASS and -fcoarray=lib on the trunk
* 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
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
Committed.
Richard.
2014-04-30 Richard Biener rguent...@suse.de
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
On Wed, Apr 30, 2014 at 8:23 AM, Thomas Preud'homme
thomas.preudho...@arm.com 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
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 rguent...@suse.de
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
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 bernd.edlin...@hotmail.de 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
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 rguent...@suse.de
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
2014-04-30 14:01 GMT+02:00 Bernd Edlinger bernd.edlin...@hotmail.de: 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
Bernd Edlinger bernd.edlin...@hotmail.de writes: 2014-04-30 Bernd Edlinger bernd.edlin...@hotmail.de 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.
On Tue, Apr 29, 2014 at 4:29 PM, Yuri Rumyantsev ysrum...@gmail.com wrote: 2014-04-28 16:16 GMT+04:00 Richard Biener richard.guent...@gmail.com: On Thu, Apr 17, 2014 at 3:09 PM, Yuri Rumyantsev ysrum...@gmail.com 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 reduc_1, reduc_3 [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 ysrum...@gmail.com * 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 ysrum...@gmail.com * 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_stmt (new_assign); gsi_insert_before already calls update_stmt on new_assign, no reason to do it again. + /* Build rhs for unconditional increment/decrement. */ + rhs =
RE: [PATCH, MIPS] Alter default number of single-precision registers
Richard Sandiford rdsandif...@googlemail.com 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 matthew.fort...@imgtec.com
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,
RE: [PATCH] Work around for current Cygwin-32 Build problems
Hi Rainer, On Wed, 30 Apr 2014 14:10:48, Rainer Orth wrote: Bernd Edlinger bernd.edlin...@hotmail.de writes: 2014-04-30 Bernd Edlinger bernd.edlin...@hotmail.de 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 bernd.edlin...@hotmail.de 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
Opps... this time with the attachment. Hi Rainer, On Wed, 30 Apr 2014 14:10:48, Rainer Orth wrote: Bernd Edlinger bernd.edlin...@hotmail.de writes: 2014-04-30 Bernd Edlinger bernd.edlin...@hotmail.de 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 bernd.edlin...@hotmail.de 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
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
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
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 andreas.kreb...@de.ibm.com
* 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 state
C++ PATCH for c++/60951 (ICE with constexpr and aggregate init)
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 ja...@redhat.com
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)
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 ja...@redhat.com
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.
On Tue, Apr 29, 2014 at 9:39 PM, Richard Henderson r...@redhat.com 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.
Ping. On Fri, Apr 18, 2014 at 2:05 PM, Evgeny Stupachenko evstu...@gmail.com 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 evstu...@gmail.com * 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 evstu...@gmail.com 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 evstu...@gmail.com wrote: Missed attachment. On Thu, Mar 6, 2014 at 6:42 PM, Evgeny Stupachenko evstu...@gmail.com 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 evstu...@gmail.com * 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 rguent...@suse.de 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 rguent...@suse.de 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 evstu...@gmail.com * target.h (vect_cost_for_stmt): Defining new cost vec_perm_shuffle. * 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.
Re: [PATCH], RFC, add support for __float128/__ibm128 types on PowerPC
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
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
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03588.html. 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 ce...@codesourcery.com
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
Mike Stump mikest...@comcast.net 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.
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 richard.guent...@gmail.com: On Tue, Apr 29, 2014 at 4:29 PM, Yuri Rumyantsev ysrum...@gmail.com wrote: 2014-04-28 16:16 GMT+04:00 Richard Biener richard.guent...@gmail.com: On Thu, Apr 17, 2014 at 3:09 PM, Yuri Rumyantsev ysrum...@gmail.com 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 reduc_1, reduc_3 [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 ysrum...@gmail.com * 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 ysrum...@gmail.com * 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:
Re: [PATCH][RFC] Always require a 64bit HWI
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 rguent...@suse.de 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
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 cm...@google.com
* 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::vectorBtype*,
const std::vectorBexpression*,
@@ -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::mapstd::string, Bfunction* 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, atanl,
+
Re: [PATCH][RFC] Always require a 64bit HWI
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.
On Wed, Apr 30, 2014 at 8:50 AM, Yuri Rumyantsev ysrum...@gmail.com 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
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 rmansfi...@qnx.com * 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
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 cm...@google.com
* 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_castenum mode_class(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_castenum mode_class(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
Re: [PATCH] A new reload-rewrite pattern recognizer for GCC vectorizer.
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 ja...@redhat.com 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
On 04/25/14 03:16, Dhakshinamoorthy, Soundararajan wrote: 2014-04-25 Soundararajan Dhakshinamoorthysounderaraja...@atmel.com * 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)
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 pola...@redhat.com 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)
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 stdbool.h 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 pola...@redhat.com 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 stdbool.h. 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)
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 pola...@redhat.com 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
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 andreas.kreb...@de.ibm.com
* 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)
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 pola...@redhat.com 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)
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 pola...@redhat.com 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)
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 pola...@redhat.com 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
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
On Wed, Apr 30, 2014 at 1:31 PM, Mike Stump mikest...@comcast.net 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 i...@google.com
* 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
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 j...@gcc.gnu.org * 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)
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
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.
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 sell...@mips.com * 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
On Wed, Apr 30, 2014 at 11:18:18AM +0200, Richard Biener wrote: On Wed, Apr 30, 2014 at 11:04 AM, Laurynas Biveinis laurynas.bivei...@gmail.com 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.
On Wed, Apr 30, 2014 at 4:22 PM, Steve Ellcey sell...@mips.com 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 sell...@mips.com * 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
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
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 cm...@google.com
* 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
Currently, gengtype does not support template arguments that are
explicitly pointers, such as:
static GTY(()) vecgimple_statement_base * 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(()) vecgimple_statement_phi *, va_gc *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(()) vecgimple, va_gc *test_old_style_gimple;
static GTY(()) vecgimple_statement_base *, va_gc *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 bootstrappedregtested on x86_64-unknown-linux-gnu (Fedora
20).
OK for trunk?
Dave
From 8d7538cb6676a2f158ea9be56820a1d57eb34b82 Mon Sep 17 00:00:00 2001
From: David Malcolm dmalc...@redhat.com
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 IDID1,ID2,...,IDn.
+ simple template declarations of the form
Re: [PATCH, PR58066] preferred_stack_boundary update for tls expanded call
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
Ping.
Thanks,
Wei.
On Tue, Dec 17, 2013 at 11:34 AM, Wei Mi w...@google.com wrote:
Ping.
Thanks,
Wei.
On Mon, Dec 9, 2013 at 9:54 PM, Wei Mi w...@google.com wrote:
Ping.
Thanks,
wei.
On Sat, Nov 23, 2013 at 10:46 AM, Wei Mi w...@google.com wrote:
bootstrap and regression of the updated patch pass.
On Sat, Nov 23, 2013 at 12:05 AM, Wei Mi w...@google.com wrote:
On Thu, Nov 21, 2013 at 12:19 AM, Zdenek Dvorak
rakd...@iuuk.mff.cuni.cz 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 w...@google.com
* 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 w...@google.com
* 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 x86intrin.h
+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 ivtmp 1 ivopts} } */
+/* { 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_real_1 (tree exp, rtx target
= TYPE_ADDR_SPACE (TREE_TYPE (TREE_TYPE (TREE_OPERAND (exp,
0;
enum insn_code icode;
unsigned int align;
+ int old_cse_not_expected;
op0 = addr_for_mem_ref (exp, as, true);
+ old_cse_not_expected = cse_not_expected;
+ cse_not_expected = true;
op0 = memory_address_addr_space (mode, op0, as);
+ cse_not_expected =
