Re: RFA: Testsuite PATCH to add support for dlopen tests
Jason Merrill writes: > Hmm, the PCH tests already use nested calls to dg-test, Do they? I don't think so. There are calls to dg-test in dg-flags-pch, which is called by dg-pch, and then pch.exp runs dg-pch on each test, but I see no other dg-test in the call chain. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
Re: Fixing PR60773
On Tue, Apr 08, 2014 at 07:40:09PM -0700, Cong Hou wrote: > On Tue, Apr 8, 2014 at 12:07 AM, Jakub Jelinek wrote: > > On Mon, Apr 07, 2014 at 12:16:12PM -0700, Cong Hou wrote: > >> --- a/gcc/testsuite/ChangeLog > >> +++ b/gcc/testsuite/ChangeLog > >> @@ -1,3 +1,11 @@ > >> +2014-04-07 Cong Hou > >> + > >> + PR testsuite/60773 > >> + * testsuite/lib/target-supports.exp: > >> + Add check_effective_target_vect_widen_mult_si_to_di_pattern. > > > > No testsuite/ prefix here. Please write it as: > > * lib/target-supports.exp > > (check_effective_target_vect_widen_si_to_di_pattern): New. > > Thank you for pointing it out. Corrected. Only partially, I see there just the #include removed and testsuite/ prefix removed, but not the using the style where in () is the name of function that has been added/modified and after ): what has been done with it. Anyway, please commit it with the above proposed change, this is a P1 and thus urgent. Thanks. Jakub
Re: [DOC PATCH] Rewrite docs for inline asm
Hi,
On Tue, 8 Apr 2014, Hans-Peter Nilsson wrote:
> Also, do we really want to document the trick in
> "m" ((@{ struct @{ char x[10]; @} *p = (void *) ptr ; *p; @}))
> (note: reformatted GNU-style and confusing @{ @} dropped)
We already document this since quite some time, and yes, it's indeed
supposed to work, and not by accident :)
Ciao,
Michael.
Re: RFA: Testsuite PATCH to add support for dlopen tests
On 04/08/2014 05:58 AM, Andreas Schwab wrote: I guess this depends on dejagnu >= 1.5, which added support for nested calls to dg-test. Hmm, the PCH tests already use nested calls to dg-test, I wonder why they don't break this way? Jason
Re: [PATCH, rs6000] Improve TImode add/sub
Hello,
On Tue, Apr 08, 2014 at 07:06:58PM -0500, Pat Haugen wrote:
> The following patch improves the code generated for TImode add/sub so
> that we now generate a 2 insn sequence which makes use of the carry bit.
> +/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
> +/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
Please leave out the default arguments. Why does this need skipping
on Darwin?
> +;; Define the TImode operations that can be done in a small number
> +;; of instructions. The & constraints are to prevent the register
> +;; allocator from allocating registers that overlap with the inputs
> +;; (for example, having an input in 7,8 and an output in 6,7). We
> +;; also allow for the output being the same as one of the inputs.
> +
> +(define_insn "addti3"
> + [(set (match_operand:TI 0 "gpc_reg_operand" "=&r,&r,r,r")
> + (plus:TI (match_operand:TI 1 "gpc_reg_operand" "%r,r,0,0")
> + (match_operand:TI 2 "reg_or_short_operand" "r,I,r,I")))]
> + "TARGET_POWERPC64"
That's not the correct condition: the carry bit is set based on the 32-bit
carry in 32-bit mode, so the condition has to be TARGET_64BIT.
The adddi3 pattern has !TARGET_POWERPC64 since a 64-bit addition can
be done without addc on a 64-bit machine, no matter what mode the CPU
is in.
> + "*
> +{
Might as well leave out this stuff on new code, just use the braces :-)
Segher
Re: Fixing PR60773
Thanks for the comments, and the attached file is the updated patch.
thanks,
Cong
On Tue, Apr 8, 2014 at 12:28 AM, Rainer Orth
wrote:
> Cong Hou writes:
>
>> In the patch of
>> PR60656(http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01668.html), the
>> test case requires GCC to vectorize the widen-mult pattern from si to
>> di types. This may result in test failures on some platforms that
>> don't support this pattern. This patch adds a new target
>> vect_widen_mult_si_to_di_pattern to fix this issue.
>
> Please document the new keyword in gcc/doc/sourcebuild.texi.
>
>> diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
>> index 414a745..ea860e7 100644
>> --- a/gcc/testsuite/ChangeLog
>> +++ b/gcc/testsuite/ChangeLog
>> @@ -1,3 +1,11 @@
>> +2014-04-07 Cong Hou
>> +
>> + PR testsuite/60773
>> + * testsuite/lib/target-supports.exp:
>> + Add check_effective_target_vect_widen_mult_si_to_di_pattern.
>> + * gcc.dg/vect/pr60656.c: Update the test by checking if the targets
>> + vect_widen_mult_si_to_di_pattern and vect_long are supported.
>> +
>
> Your mailer is broken: it swallows tabs and breaks long lines. If you
> can't fix it, please attach patches instead of sending them inline.
>
> Thanks.
>
> Rainer
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
diff --git a/gcc/doc/sourcebuild.texi b/gcc/doc/sourcebuild.texi
index 85ef819..9148608 100644
--- a/gcc/doc/sourcebuild.texi
+++ b/gcc/doc/sourcebuild.texi
@@ -1428,6 +1428,10 @@ Target supports a vector widening multiplication of
@code{short} operands
into @code{int} results, or can promote (unpack) from @code{short} to
@code{int} and perform non-widening multiplication of @code{int}.
+@item vect_widen_mult_si_to_di_pattern
+Target supports a vector widening multiplication of @code{int} operands
+into @code{long} results.
+
@item vect_sdot_qi
Target supports a vector dot-product of @code{signed char}.
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 414a745..d426e29 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,11 @@
+2014-04-07 Cong Hou
+
+ PR testsuite/60773
+ * lib/target-supports.exp:
+ Add check_effective_target_vect_widen_mult_si_to_di_pattern.
+ * gcc.dg/vect/pr60656.c: Update the test by checking if the targets
+ vect_widen_mult_si_to_di_pattern and vect_long are supported.
+
2014-03-28 Cong Hou
PR tree-optimization/60656
diff --git a/gcc/testsuite/gcc.dg/vect/pr60656.c
b/gcc/testsuite/gcc.dg/vect/pr60656.c
index ebaab62..4950275 100644
--- a/gcc/testsuite/gcc.dg/vect/pr60656.c
+++ b/gcc/testsuite/gcc.dg/vect/pr60656.c
@@ -1,4 +1,5 @@
/* { dg-require-effective-target vect_int } */
+/* { dg-require-effective-target vect_long } */
#include "tree-vect.h"
@@ -12,7 +13,7 @@ foo ()
for(i = 0; i < 4; ++i)
{
long P = v[i];
- s += P*P*P;
+ s += P * P * P;
}
return s;
}
@@ -27,7 +28,7 @@ bar ()
for(i = 0; i < 4; ++i)
{
long P = v[i];
- s += P*P*P;
+ s += P * P * P;
__asm__ volatile ("");
}
return s;
@@ -35,11 +36,12 @@ bar ()
int main()
{
+ check_vect ();
+
if (foo () != bar ())
abort ();
return 0;
}
-/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" } } */
+/* { dg-final { scan-tree-dump-times "vectorized 1 loops" 1 "vect" { target
vect_widen_mult_si_to_di_pattern } } } */
/* { dg-final { cleanup-tree-dump "vect" } } */
-
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index bee8471..6d9d689 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -3732,6 +3732,27 @@ proc
check_effective_target_vect_widen_mult_hi_to_si_pattern { } {
}
# Return 1 if the target plus current options supports a vector
+# widening multiplication of *int* args into *long* result, 0 otherwise.
+#
+# This won't change for different subtargets so cache the result.
+
+proc check_effective_target_vect_widen_mult_si_to_di_pattern { } {
+global et_vect_widen_mult_si_to_di_pattern
+
+if [info exists et_vect_widen_mult_si_to_di_pattern_saved] {
+verbose "check_effective_target_vect_widen_mult_si_to_di_pattern:
using cached result" 2
+} else {
+if {[istarget ia64-*-*]
+ || [istarget i?86-*-*]
+ || [istarget x86_64-*-*] } {
+set et_vect_widen_mult_si_to_di_pattern_saved 1
+}
+}
+verbose "check_effective_target_vect_widen_mult_si_to_di_pattern:
returning $et_vect_widen_mult_si_to_di_pattern_saved" 2
+return $et_vect_widen_mult_si_to_di_pattern_saved
+}
+
+# Return 1 if the target plus current options supports a vector
# widening shift, 0 otherwise.
#
# This won't change for different subtargets so cache the result.
Re: Fixing PR60773
On Tue, Apr 8, 2014 at 12:07 AM, Jakub Jelinek wrote:
> On Mon, Apr 07, 2014 at 12:16:12PM -0700, Cong Hou wrote:
>> --- a/gcc/testsuite/ChangeLog
>> +++ b/gcc/testsuite/ChangeLog
>> @@ -1,3 +1,11 @@
>> +2014-04-07 Cong Hou
>> +
>> + PR testsuite/60773
>> + * testsuite/lib/target-supports.exp:
>> + Add check_effective_target_vect_widen_mult_si_to_di_pattern.
>
> No testsuite/ prefix here. Please write it as:
> * lib/target-supports.exp
> (check_effective_target_vect_widen_si_to_di_pattern): New.
Thank you for pointing it out. Corrected.
>
>> --- a/gcc/testsuite/gcc.dg/vect/pr60656.c
>> +++ b/gcc/testsuite/gcc.dg/vect/pr60656.c
>> @@ -1,5 +1,7 @@
>> /* { dg-require-effective-target vect_int } */
>> +/* { dg-require-effective-target vect_long } */
>>
>> +#include
>
> I fail to see why you need this include, neither your test nor tree-vect.h
> uses va_*.
I have removed this include.
thanks,
Cong
>
> Otherwise looks good to me.
>
> Jakub
[PATCH, rs6000] Improve TImode add/sub
The following patch improves the code generated for TImode add/sub so
that we now generate a 2 insn sequence which makes use of the carry bit.
Bootstrap/regtest (on both BE/LE) with no new failures. Ok for trunk and
4.8?
-Pat
2014-04-08 Pat Haugen
* config/rs6000/rs6000.md (addti3, subti3): New.
gcc/testsuite:
* gcc.target/powerpc/ti_math1.c: New.
* gcc.target/powerpc/ti_math2.c: New.
Index: gcc/testsuite/gcc.target/powerpc/ti_math1.c
===
--- gcc/testsuite/gcc.target/powerpc/ti_math1.c (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/ti_math1.c (revision 0)
@@ -0,0 +1,21 @@
+/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-options "-O2" } */
+/* { dg-final { scan-assembler-times "addc" 1 } } */
+/* { dg-final { scan-assembler-times "adde" 1 } } */
+/* { dg-final { scan-assembler-times "subfc" 1 } } */
+/* { dg-final { scan-assembler-times "subfe" 1 } } */
+/* { dg-final { scan-assembler-not "subf " } } */
+
+__int128
+add_128 (__int128 *ptr, __int128 val)
+{
+ return (*ptr + val);
+}
+
+__int128
+sub_128 (__int128 *ptr, __int128 val)
+{
+ return (*ptr - val);
+}
+
Index: gcc/testsuite/gcc.target/powerpc/ti_math2.c
===
--- gcc/testsuite/gcc.target/powerpc/ti_math2.c (revision 0)
+++ gcc/testsuite/gcc.target/powerpc/ti_math2.c (revision 0)
@@ -0,0 +1,74 @@
+/* { dg-do run { target { powerpc*-*-* && lp64 } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-options "-O2 -fno-inline" } */
+
+union U {
+ __int128 i128;
+ struct {
+long l1;
+long l2;
+ } s;
+};
+
+union U u1,u2;
+
+__int128
+create_128 (long most_sig, long least_sig)
+{
+ union U u;
+
+#if __LITTLE_ENDIAN__
+ u.s.l1 = least_sig;
+ u.s.l2 = most_sig;
+#else
+ u.s.l1 = most_sig;
+ u.s.l2 = least_sig;
+#endif
+ return u.i128;
+}
+
+long most_sig (union U * u)
+{
+#if __LITTLE_ENDIAN__
+ return (*u).s.l2;
+#else
+ return (*u).s.l1;
+#endif
+}
+
+long least_sig (union U * u)
+{
+#if __LITTLE_ENDIAN__
+ return (*u).s.l1;
+#else
+ return (*u).s.l2;
+#endif
+}
+
+__int128
+add_128 (__int128 *ptr, __int128 val)
+{
+ return (*ptr + val);
+}
+
+__int128
+sub_128 (__int128 *ptr, __int128 val)
+{
+ return (*ptr - val);
+}
+
+int
+main (void)
+{
+ /* Do a simple add/sub to make sure carry is happening between the dwords
+ and that dwords are in correct endian order. */
+ u1.i128 = create_128 (1, -1);
+ u2.i128 = add_128 (&u1.i128, 1);
+ if ((most_sig (&u2) != 2) || (least_sig (&u2) != 0))
+__builtin_abort ();
+ u2.i128 = sub_128 (&u2.i128, 1);
+ if ((most_sig (&u2) != 1) || (least_sig (&u2) != -1))
+__builtin_abort ();
+ return 0;
+}
+
Index: gcc/config/rs6000/rs6000.md
===
--- gcc/config/rs6000/rs6000.md (revision 209226)
+++ gcc/config/rs6000/rs6000.md (working copy)
@@ -6535,6 +6535,51 @@ (define_insn_and_split "*floatunsdisf2_m
[(set_attr "length" "8")
(set_attr "type" "fpload")])
+;; Define the TImode operations that can be done in a small number
+;; of instructions. The & constraints are to prevent the register
+;; allocator from allocating registers that overlap with the inputs
+;; (for example, having an input in 7,8 and an output in 6,7). We
+;; also allow for the output being the same as one of the inputs.
+
+(define_insn "addti3"
+ [(set (match_operand:TI 0 "gpc_reg_operand" "=&r,&r,r,r")
+ (plus:TI (match_operand:TI 1 "gpc_reg_operand" "%r,r,0,0")
+ (match_operand:TI 2 "reg_or_short_operand" "r,I,r,I")))]
+ "TARGET_POWERPC64"
+ "*
+{
+ if (WORDS_BIG_ENDIAN)
+return (GET_CODE (operands[2])) != CONST_INT
+ ? \"addc %L0,%L1,%L2\;adde %0,%1,%2\"
+ : \"addic %L0,%L1,%2\;add%G2e %0,%1\";
+ else
+return (GET_CODE (operands[2])) != CONST_INT
+ ? \"addc %0,%1,%2\;adde %L0,%L1,%L2\"
+ : \"addic %0,%1,%2\;add%G2e %L0,%L1\";
+}"
+ [(set_attr "type" "two")
+ (set_attr "length" "8")])
+
+(define_insn "subti3"
+ [(set (match_operand:TI 0 "gpc_reg_operand" "=&r,&r,r,r,r")
+ (minus:TI (match_operand:TI 1 "reg_or_short_operand" "r,I,0,r,I")
+ (match_operand:TI 2 "gpc_reg_operand" "r,r,r,0,0")))]
+ "TARGET_POWERPC64"
+ "*
+{
+ if (WORDS_BIG_ENDIAN)
+return (GET_CODE (operands[1]) != CONST_INT)
+ ? \"subfc %L0,%L2,%L1\;subfe %0,%2,%1\"
+ : \"subfic %L0,%L2,%1\;subf%G1e %0,%2\";
+ else
+return (GET_CODE (operands[1]) != CONST_INT)
+ ? \"subfc %0,%2,%1\;subfe %L0,%L2,%L1\"
+ : \"subfic %0,%2,%1\;subf%G1e %L0,%L2\";
+}"
+ [(set_attr "type" "two")
+ (set_attr "length" "8")])
+
+
;; Define the DImode operations that can be done in a small number
;; of instructions. The & constraints are to prevent the register
;; allocator from allocating registers that overlap with the inputs
Re: [DOC PATCH] Rewrite docs for inline asm
On Fri, 4 Apr 2014, dw wrote:
> Problem description:
> The existing documentation does an inadequate job of describing gcc's
> implementation of the "asm" keyword. This has led to a great deal of
> confusion as people struggle to understand how it works. This entire section
> requires a rewrite that provides a structured layout and detailed descriptions
> of each of the parameters along with examples.
>
> ChangeLog:
> 2014-04-03 David Wohlferd (limegreenso...@yahoo.com)
>Andrew Haley (a...@redhat.com)
>Richard Sandiford (rdsandif...@googlemail.com)
>
>* extend.texi: Completely rewrite inline asm section / minor reorg
> of asm-related sections
(No other feedback since friday?)
Thanks for doing this!
There are some *minor* issues, like two-spaces-after-"." which
(IIRC) makes a semantic difference in texinfo, and missing use
of texinfo markup like @emph{not} instead of NOT. Also, in the
ChangeLog is the first of many overly long lines. Please keep
lines shorter than 80 chars like the rest of extend.texi,
somewhere between 70-79 chars? Also, code snippets in texinfo
should use GNU formatting, including comments (full sentences
with capitalization and full stop).
Also,
+ : [d] "=rm" (d)
+ : [e] "rm" (*e)
+ : );
That last bit, the ": )" (empty last operand part) shouldn't be
in the documentation. I'm not even sure it *should* work
(apparently it does, perhaps by accident).
The general bits seems like a big improvement, but what worries
me is the deleted text. For example, the aspects of "Explicit
Reg Vars" when *directly feeding an asm* and how to write them
to avoid the named registers being call-clobbered between
assignment and the asm. (Don't confuse this with the
asm-clobber operands which I think you covered fine.) Those
details are maybe not thoughtfully described, but they can't be
just plainly removed as they also serve as gcc specification;
definitions as to what works and doesn't work! (I don't know if
that was the only occurrence.)
Also, do we really want to document the trick in
"m" ((@{ struct @{ char x[10]; @} *p = (void *) ptr ; *p; @}))
(note: reformatted GNU-style and confusing @{ @} dropped)
IIRC this is from Linux, but I don't think GCC ever promised the
described semantics, and I don't think we should document
something that works just by accident. Do we want to make that
promise now?
> Bootstrapping and testing:
> I have tested "make html" to produce html files, but my configuration doesn't
> allow for the "make dvi" test.
That requirement is somewhat arcane but maybe "make pdf" would
work for you? (Though may or may not use dvi as an intermediate
step.) The point is to verify the layout; what goes into the
info files is often different to what goes into the printable
format.
brgds, H-P
RE: RFA: Testsuite PATCH to add support for dlopen tests
Jason, I tried the patch you sent to Dominique and it doesn't fix everything on MIPS. The other problem is in gcc-dg-test-1 where you set extra_tool_flags. I don't think it can be set and restored there so I moved that into dg-build-dso. Also, I don't like setting dg-do-what-default back to compile as a hard-coded value, I think we should save the old value and restore it afterwords. Attached is a patch that fixes things in my MIPS elf build. My elf target doesn't do dso's so I don't really know if the new tests are working or not with this change but it is not causing any regressions. Steve Ellcey sell...@mips.com patch Description: patch
Re: [PATCH 2/3] libstdc++-v3: ::tmpnam depends on uClibc SUSV4_LEGACY
On 20 December 2013 13:16, Bernhard Reutner-Fischer wrote: > On 13 November 2013 18:56, Jonathan Wakely wrote: >> On 13 November 2013 09:22, Bernhard Reutner-Fischer wrote: >>> On 11 November 2013 12:30, Jonathan Wakely wrote: How does __UCLIBC_SUSV4_LEGACY__ get defined? We'd have a problem if users defined that at configure time but not later when using the library. >>> That would be defined by uClibc's configury, but the latest >>> "commit-6f2faa2" i attached does not mention this anymore, but does >>> the check in a libc-agnostic manner? >> >> Yes, but I was concerned about whether the value of that macro can >> change between configuring libstdc++ and users compiling code using >> libstdc++. If it could change (e.g. by users compiling with >> -D_POSIX_C_SOURCE=200112L or some other feature test macro) then the >> value of _GLIBCXX_USE_TMPNAM (which doesn't change) would be >> unreliable and we could end up with a "using ::tmpnam" in the library >> that causes errors when users compile. >> >> If it's set when configuring uClibc then it is a constant for a given >> libstdc++ installation, so the value of _GLIBCXX_USE_TMPNAM is >> reliable. In that case your change is OK to commit (with or without >> the "XYZ" change) - thanks. > > It is a constant, yes. I will push this after another round of regtests > against current trunk as time permits. Just rebased and saw that sje committed this as svn r207009 for me since i apparently forgot.. Thanks!
Re: [Patch, testsuite, mips] Fix gcc.dg/tree-ssa/ssa-ifcombine-13.c
On Tue, Apr 08, 2014 at 01:48:21PM -0700, Steve Ellcey wrote: > The test gcc.dg/tree-ssa/ssa-ifcombine-13.c has been failing on MIPS ever > since it was added because MIPS sets LOGICAL_OP_NON_SHORT_CIRCUIT to 0 and > so the optimization being checked for is not done. This patch removes > mips from the list of platforms where we check for the optimization. > > Tested on mips-mti-elf. OK for checkin? > > Steve Ellcey > sell...@mips.com > > > 2014-04-01 Steve Ellcey > > * gcc.dg/tree-ssa/ssa-ifcombine-13.c: Remove mips*-*-* from option > and scan lists. Ok, thanks. Jakub
[Patch, testsuite, mips] Fix gcc.dg/tree-ssa/ssa-ifcombine-13.c
The test gcc.dg/tree-ssa/ssa-ifcombine-13.c has been failing on MIPS ever
since it was added because MIPS sets LOGICAL_OP_NON_SHORT_CIRCUIT to 0 and
so the optimization being checked for is not done. This patch removes
mips from the list of platforms where we check for the optimization.
Tested on mips-mti-elf. OK for checkin?
Steve Ellcey
sell...@mips.com
2014-04-01 Steve Ellcey
* gcc.dg/tree-ssa/ssa-ifcombine-13.c: Remove mips*-*-* from option
and scan lists.
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-13.c
b/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-13.c
index 19f892e..43b92c1 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-13.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-ifcombine-13.c
@@ -1,6 +1,6 @@
/* { dg-do compile } */
/* { dg-options "-O1 -fdump-tree-optimized" } */
-/* { dg-additional-options "-mbranch-cost=2" { target { i?86-*-* x86_64-*-*
mips*-*-* s390*-*-* avr*-*-* } } } */
+/* { dg-additional-options "-mbranch-cost=2" { target { i?86-*-* x86_64-*-*
s390*-*-* avr*-*-* } } } */
_Bool f1(_Bool a, _Bool b)
{
@@ -17,5 +17,5 @@ _Bool f1(_Bool a, _Bool b)
/* For LOGICAL_OP_NON_SHORT_CIRCUIT, this should be optimized
into return a & b;, with no ifs. */
-/* { dg-final { scan-tree-dump-not "if" "optimized" { target { i?86-*-*
x86_64-*-* mips*-*-* s390*-*-* avr*-*-* } } } } */
+/* { dg-final { scan-tree-dump-not "if" "optimized" { target { i?86-*-*
x86_64-*-* s390*-*-* avr*-*-* } } } } */
/* { dg-final { cleanup-tree-dump "optimized" } } */
shift/extract SHIFT_COUNT_TRUNCATED combine bug
Something broke in the compiler to cause combine to incorrectly optimize:
(insn 12 11 13 3 (set (reg:SI 604 [ D.6102 ])
(lshiftrt:SI (subreg/s/u:SI (reg/v:DI 601 [ x ]) 0)
(reg:SI 602 [ D.6103 ]))) t.c:47 4436 {lshrsi3}
(expr_list:REG_DEAD (reg:SI 602 [ D.6103 ])
(nil)))
(insn 13 12 14 3 (set (reg:SI 605)
(and:SI (reg:SI 604 [ D.6102 ])
(const_int 1 [0x1]))) t.c:47 3658 {andsi3}
(expr_list:REG_DEAD (reg:SI 604 [ D.6102 ])
(nil)))
(insn 14 13 15 3 (set (reg:DI 599 [ D.6102 ])
(zero_extend:DI (reg:SI 605))) t.c:47 4616 {zero_extendsidi2}
(expr_list:REG_DEAD (reg:SI 605)
(nil)))
into:
(insn 11 10 12 3 (set (reg:SI 602 [ D.6103 ])
(not:SI (subreg:SI (reg:DI 595 [ D.6102 ]) 0))) t.c:47 3732
{one_cmplsi2}
(expr_list:REG_DEAD (reg:DI 595 [ D.6102 ])
(nil)))
(note 12 11 13 3 NOTE_INSN_DELETED)
(note 13 12 14 3 NOTE_INSN_DELETED)
(insn 14 13 15 3 (set (reg:DI 599 [ D.6102 ])
(zero_extract:DI (reg/v:DI 601 [ x ])
(const_int 1 [0x1])
(reg:SI 602 [ D.6103 ]))) t.c:47 4668 {c2_extzvdi}
(expr_list:REG_DEAD (reg:SI 602 [ D.6103 ])
(nil)))
This shows up in:
FAIL: gcc.c-torture/execute/builtin-bitops-1.c execution, -Og -g
for me.
diff --git a/gcc/combine.c b/gcc/combine.c
index 708691f..c1f50ff 100644
--- a/gcc/combine.c
+++ b/gcc/combine.c
@@ -7245,6 +7245,18 @@ make_extraction (enum machine_mode mode, rtx inner,
HOST_WIDE_INT pos,
extraction_mode = insn.field_mode;
}
+ /* On a SHIFT_COUNT_TRUNCATED machine, we can't promote the mode of
+ the extract to a larger size on a variable extract, as previously
+ the position might have been optimized to change a bit of the
+ index of the starting bit that would have been ignored before,
+ but, with a larger mode, will then not be. If we wanted to do
+ this, we'd have to mask out those bits or prove that those bits
+ are 0. */
+ if (SHIFT_COUNT_TRUNCATED
+ && pos_rtx
+ && GET_MODE_BITSIZE (extraction_mode) > GET_MODE_BITSIZE (mode))
+extraction_mode = mode;
+
/* Never narrow an object, since that might not be safe. */
if (mode != VOIDmode
is sufficient to never widen variable extracts on SHIFT_COUNT_TRUNCATED
machines. So, the question is, how did people expect this to work? I didn’t
spot what changed recently to cause the bad code-gen. The optimization of sub
into not is ok, despite how funny it looks, because is feeds into extract which
we know by SHIFT_COUNT_TRUNCATED is safe.
Is the patch a reasonable way to fix this?
Re: [PATCH, rs6000] Prefer vnand/vperm over vnor/vperm for Power8
On Tue, Apr 8, 2014 at 3:07 PM, Bill Schmidt wrote: > Hi, > > Recently I posted a patch to use vnor to invert the permute control > vector for little-endian permutes. It's come to my attention that, when > available, the vnand instruction should be used in preference to vnor > for possible future processor exploitation. This patch checks for > availability of vnand and uses it instead. It also removes earlier use > of emit_move_insn in this logic where that was not appropriate. > > Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no > regressions. Is this ok for trunk? > > I would also like to backport the combined patch to the FSF 4.8 branch, > if you feel that is appropriate. Please let me know. > > Thanks, > Bill > > > 2014-04-08 Bill Schmidt > > * config/rs6000/rs6000.c (rs6000_expand_vector_set): Use vnand > instead of vnor to exploit possible fusion opportunity in the > future. > (altivec_expand_vec_perm_const_le): Likewise. Okay for trunk and 4.8. Thanks, David
[Fortran-caf, patch, committed] Prepare for remote-get support
This is the first step for support coindexed variables on the RHS / in
expressions. While the committed patch only defines some variables, I
have a draft patch which handles the communication for scalars. Together
with the existing support for coarrays on the LHS (scalars and arrays),
the current support should already quite useful.
Committed as Rev. 209226.
Tobias
gcc/fortran/ChangeLog.fortran-caf |6 ++
gcc/fortran/trans-decl.c | 14 ++
gcc/fortran/trans.h |1 +
libgfortran/ChangeLog.fortran-caf |5 +
libgfortran/caf/libcaf.h |2 ++
libgfortran/caf/single.c | 13 +
6 files changed, 37 insertions(+), 4 deletions(-)
Index: libgfortran/ChangeLog.fortran-caf
===
--- libgfortran/ChangeLog.fortran-caf (Revision 209209)
+++ libgfortran/ChangeLog.fortran-caf (Arbeitskopie)
@@ -1,3 +1,8 @@
+2014-04-08 Tobias Burnus
+
+ * caf/libcaf.h (_gfortran_caf_get): New.
+ * caf/single.c (_gfortran_caf_get): New.
+
2014-04-06 Tobias Burnus
* caf/libcaf.h (_gfortran_caf_send_desc,
Index: libgfortran/caf/libcaf.h
===
--- libgfortran/caf/libcaf.h (Revision 209209)
+++ libgfortran/caf/libcaf.h (Arbeitskopie)
@@ -108,6 +108,8 @@ void *_gfortran_caf_register (size_t, caf_register
char *, int);
void _gfortran_caf_deregister (caf_token_t *, int *, char *, int);
+void _gfortran_caf_get (caf_token_t, size_t, int, void *, size_t, bool);
+
void _gfortran_caf_send (caf_token_t, size_t, int, void *, size_t, bool);
void _gfortran_caf_send_desc (caf_token_t, size_t, int, gfc_descriptor_t*,
gfc_descriptor_t*, bool);
Index: libgfortran/caf/single.c
===
--- libgfortran/caf/single.c (Revision 209209)
+++ libgfortran/caf/single.c (Arbeitskopie)
@@ -149,6 +149,19 @@ _gfortran_caf_deregister (caf_token_t *token, int
*stat = 0;
}
+
+/* Get a scalar (or contiguous) data from remote image into a buffer. */
+
+void
+_gfortran_caf_get (caf_token_t token, size_t offset,
+ int image_id __attribute__ ((unused)),
+ void *buffer, size_t size, bool async __attribute__ ((unused)))
+{
+void *src = (void *) ((char *) TOKEN (token) + offset);
+memmove (buffer, src, size);
+}
+
+
/* Send scalar (or contiguous) data from buffer to a remote image. */
void
Index: gcc/fortran/ChangeLog.fortran-caf
===
--- gcc/fortran/ChangeLog.fortran-caf (Revision 209209)
+++ gcc/fortran/ChangeLog.fortran-caf (Arbeitskopie)
@@ -1,3 +1,9 @@
+2014-04-08 Tobias Burnus
+
+ * trans.h (gfor_fndecl_caf_remote_get): Declare variables.
+ * trans-decl.c (gfor_fndecl_caf_remote_get): Define it.
+ (gfc_build_builtin_function_decls): Initialize it.
+
2014-04-06 Tobias Burnus
* trans-intrinsic.c (conv_caf_send): Fix bugs with
Index: gcc/fortran/trans.h
===
--- gcc/fortran/trans.h (Revision 209209)
+++ gcc/fortran/trans.h (Arbeitskopie)
@@ -700,6 +700,7 @@ extern GTY(()) tree gfor_fndecl_caf_this_image;
extern GTY(()) tree gfor_fndecl_caf_num_images;
extern GTY(()) tree gfor_fndecl_caf_register;
extern GTY(()) tree gfor_fndecl_caf_deregister;
+extern GTY(()) tree gfor_fndecl_caf_remote_get;
extern GTY(()) tree gfor_fndecl_caf_send;
extern GTY(()) tree gfor_fndecl_caf_send_desc;
extern GTY(()) tree gfor_fndecl_caf_send_desc_scalar;
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c (Revision 209209)
+++ gcc/fortran/trans-decl.c (Arbeitskopie)
@@ -125,6 +125,7 @@ tree gfor_fndecl_caf_this_image;
tree gfor_fndecl_caf_num_images;
tree gfor_fndecl_caf_register;
tree gfor_fndecl_caf_deregister;
+tree gfor_fndecl_caf_remote_get;
tree gfor_fndecl_caf_send;
tree gfor_fndecl_caf_send_desc;
tree gfor_fndecl_caf_send_desc_scalar;
@@ -3262,22 +3263,27 @@ gfc_build_builtin_function_decls (void)
gfor_fndecl_caf_deregister = gfc_build_library_function_decl_with_spec (
get_identifier (PREFIX("caf_deregister")), ".WWW", void_type_node, 4,
-ppvoid_type_node, pint_type, pchar_type_node, integer_type_node);
+ ppvoid_type_node, pint_type, pchar_type_node, integer_type_node);
+ gfor_fndecl_caf_remote_get = gfc_build_library_function_decl_with_spec (
+ get_identifier (PREFIX("caf_get")), "R..W..", void_type_node, 6,
+ pvoid_type_node, size_type_node, integer_type_node, pvoid_type_node,
+ size_type_node, boolean_type_node);
+
gfor_fndecl_caf_send = gfc_build_library_function_decl_with_spec (
get_identifier (PREFIX("caf_send")), "R..R..", void_type_node, 6,
-pvoid_type_node, size_type_node, integer_type_node, pvoid_type_node,
+ pvoid_type_node, size_type_node, integer_type_node, pvoid_type_node,
size_
[PATCH, rs6000] Prefer vnand/vperm over vnor/vperm for Power8
Hi,
Recently I posted a patch to use vnor to invert the permute control
vector for little-endian permutes. It's come to my attention that, when
available, the vnand instruction should be used in preference to vnor
for possible future processor exploitation. This patch checks for
availability of vnand and uses it instead. It also removes earlier use
of emit_move_insn in this logic where that was not appropriate.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu with no
regressions. Is this ok for trunk?
I would also like to backport the combined patch to the FSF 4.8 branch,
if you feel that is appropriate. Please let me know.
Thanks,
Bill
2014-04-08 Bill Schmidt
* config/rs6000/rs6000.c (rs6000_expand_vector_set): Use vnand
instead of vnor to exploit possible fusion opportunity in the
future.
(altivec_expand_vec_perm_const_le): Likewise.
Index: gcc/config/rs6000/rs6000.c
===
--- gcc/config/rs6000/rs6000.c (revision 209205)
+++ gcc/config/rs6000/rs6000.c (working copy)
@@ -5635,11 +5635,15 @@ rs6000_expand_vector_set (rtx target, rtx val, int
UNSPEC_VPERM);
else
{
- /* Invert selector. */
+ /* Invert selector. We prefer to generate VNAND on P8 so
+ that future fusion opportunities can kick in, but must
+ generate VNOR elsewhere. */
rtx notx = gen_rtx_NOT (V16QImode, force_reg (V16QImode, x));
- rtx andx = gen_rtx_AND (V16QImode, notx, notx);
+ rtx iorx = (TARGET_P8_VECTOR
+ ? gen_rtx_IOR (V16QImode, notx, notx)
+ : gen_rtx_AND (V16QImode, notx, notx));
rtx tmp = gen_reg_rtx (V16QImode);
- emit_move_insn (tmp, andx);
+ emit_insn (gen_rtx_SET (VOIDmode, tmp, iorx));
/* Permute with operands reversed and adjusted selector. */
x = gen_rtx_UNSPEC (mode, gen_rtvec (3, reg, target, tmp),
@@ -30212,12 +30216,12 @@ altivec_expand_vec_perm_const_le (rtx operands[4])
/* Similarly to altivec_expand_vec_perm_const_le, we must adjust the
permute control vector. But here it's not a constant, so we must
- generate a vector NOR to do the adjustment. */
+ generate a vector NAND or NOR to do the adjustment. */
void
altivec_expand_vec_perm_le (rtx operands[4])
{
- rtx notx, andx, unspec;
+ rtx notx, iorx, unspec;
rtx target = operands[0];
rtx op0 = operands[1];
rtx op1 = operands[2];
@@ -30236,10 +30240,13 @@ altivec_expand_vec_perm_le (rtx operands[4])
if (!REG_P (target))
tmp = gen_reg_rtx (mode);
- /* Invert the selector with a VNOR. */
+ /* Invert the selector with a VNAND if available, else a VNOR.
+ The VNAND is preferred for future fusion opportunities. */
notx = gen_rtx_NOT (V16QImode, sel);
- andx = gen_rtx_AND (V16QImode, notx, notx);
- emit_move_insn (norreg, andx);
+ iorx = (TARGET_P8_VECTOR
+ ? gen_rtx_IOR (V16QImode, notx, notx)
+ : gen_rtx_AND (V16QImode, notx, notx));
+ emit_insn (gen_rtx_SET (VOIDmode, norreg, iorx));
/* Permute with operands reversed and adjusted selector. */
unspec = gen_rtx_UNSPEC (mode, gen_rtvec (3, op1, op0, norreg),
Re: [PATCH, rs6000] Improve atomic_load/store code gen for Power8 TI mode
On 03/25/2014 11:20 AM, Pat Haugen wrote:
Power8 can use lq/stq instructions for TI mode atomic_load/store.
Bootstrap/regtest with no new failures. Ok for trunk and 4.8 (once
bootstrap/regtest finishes)?
-Pat
2014-03-25 Pat Haugen
* config/rs6000/sync.md (AINT mode_iterator): Move definition.
(loadsync_): Change mode.
(atomic_load, atomic_store): Add support for TI mode.
(load_quadpti, store_quadpti): New.
* config/rs6000/rs6000.md (unspec enum): Add UNSPEC_LSQ.
gcc/testsuite:
* gcc.target/powerpc/atomic_load_store-p8.c: New.
Updated patch which was approved off list and I have committed.
Index: testsuite/gcc.target/powerpc/atomic_load_store-p8.c
===
--- testsuite/gcc.target/powerpc/atomic_load_store-p8.c (revision 0)
+++ testsuite/gcc.target/powerpc/atomic_load_store-p8.c (revision 0)
@@ -0,0 +1,22 @@
+/* { dg-do compile { target { powerpc*-*-* && lp64 } } } */
+/* { dg-skip-if "" { powerpc*-*-darwin* } { "*" } { "" } } */
+/* { dg-require-effective-target powerpc_p8vector_ok } */
+/* { dg-options "-mcpu=power8 -O2" } */
+/* { dg-final { scan-assembler-times "lq" 1 } } */
+/* { dg-final { scan-assembler-times "stq" 1 } } */
+/* { dg-final { scan-assembler-not "bl __atomic" } } */
+/* { dg-final { scan-assembler-not "lqarx" } } */
+/* { dg-final { scan-assembler-not "stqcx" } } */
+
+__int128
+atomic_load_128_relaxed (__int128 *ptr)
+{
+ return __atomic_load_n (ptr, __ATOMIC_RELAXED);
+}
+
+void
+atomic_store_128_relaxed (__int128 *ptr, __int128 val)
+{
+ __atomic_store_n (ptr, val, __ATOMIC_RELAXED);
+}
+
Index: config/rs6000/predicates.md
===
--- config/rs6000/predicates.md (revision 209198)
+++ config/rs6000/predicates.md (working copy)
@@ -624,14 +624,14 @@ (define_predicate "offsettable_mem_opera
(match_test "offsettable_nonstrict_memref_p (op)")))
;; Return 1 if the operand is suitable for load/store quad memory.
-;; This predicate only checks for non-atomic loads/stores.
+;; This predicate only checks for non-atomic loads/stores (not lqarx/stqcx).
(define_predicate "quad_memory_operand"
(match_code "mem")
{
rtx addr, op0, op1;
int ret;
- if (!TARGET_QUAD_MEMORY)
+ if (!TARGET_QUAD_MEMORY && !TARGET_SYNC_TI)
ret = 0;
else if (!memory_operand (op, mode))
Index: config/rs6000/sync.md
===
--- config/rs6000/sync.md (revision 209198)
+++ config/rs6000/sync.md (working copy)
@@ -107,10 +107,17 @@ (define_insn "isync"
"isync"
[(set_attr "type" "isync")])
+;; Types that we should provide atomic instructions for.
+(define_mode_iterator AINT [QI
+ HI
+ SI
+ (DI "TARGET_POWERPC64")
+ (TI "TARGET_SYNC_TI")])
+
;; The control dependency used for load dependency described
;; in B.2.3 of the Power ISA 2.06B.
(define_insn "loadsync_"
- [(unspec_volatile:BLK [(match_operand:INT1 0 "register_operand" "r")]
+ [(unspec_volatile:BLK [(match_operand:AINT 0 "register_operand" "r")]
UNSPECV_ISYNC)
(clobber (match_scratch:CC 1 "=y"))]
""
@@ -118,18 +125,56 @@ (define_insn "loadsync_"
[(set_attr "type" "isync")
(set_attr "length" "12")])
+(define_insn "load_quadpti"
+ [(set (match_operand:PTI 0 "quad_int_reg_operand" "=&r")
+ (unspec:PTI
+ [(match_operand:TI 1 "quad_memory_operand" "wQ")] UNSPEC_LSQ))]
+ "TARGET_SYNC_TI
+ && !reg_mentioned_p (operands[0], operands[1])"
+ "lq %0,%1"
+ [(set_attr "type" "load")
+ (set_attr "length" "4")])
+
(define_expand "atomic_load"
- [(set (match_operand:INT1 0 "register_operand" "") ;; output
- (match_operand:INT1 1 "memory_operand" "")) ;; memory
+ [(set (match_operand:AINT 0 "register_operand" "") ;; output
+ (match_operand:AINT 1 "memory_operand" "")) ;; memory
(use (match_operand:SI 2 "const_int_operand" ""))] ;; model
""
{
+ if (mode == TImode && !TARGET_SYNC_TI)
+FAIL;
+
enum memmodel model = (enum memmodel) INTVAL (operands[2]);
if (model == MEMMODEL_SEQ_CST)
emit_insn (gen_hwsync ());
- emit_move_insn (operands[0], operands[1]);
+ if (mode != TImode)
+emit_move_insn (operands[0], operands[1]);
+ else
+{
+ rtx op0 = operands[0];
+ rtx op1 = operands[1];
+ rtx pti_reg = gen_reg_rtx (PTImode);
+
+ // Can't have indexed address for 'lq'
+ if (indexed_address (XEXP (op1, 0), TImode))
+ {
+ rtx old_addr = XEXP (op1, 0);
+ rtx new_addr = force_reg (Pmode, old_addr);
+ operands[1] = op1 = replace_equiv_address (op1, new_addr);
+ }
+
+ emit_insn (gen_load_quadpti (pti_reg, op1));
+
+ if (WORDS_BIG_ENDIAN)
+ emit_move_insn (op0, gen_lowpart (TImode, pti_reg));
+ else
+ {
+ emit_move_insn (gen_lowpart (DImode, op0), gen_highpart (DImode, pti_reg));
+ emit_move_insn (gen_highpart (DImode, op0), gen_lowpart (DImode, pti_reg));
+ }
+}
switch
Re: [C++ Patch/RFC] PR 59115
OK. Jason
Re: [PATCH][C++] Fix PR60761, diagnostics in clones
On 04/08/2014 07:58 AM, Richard Biener wrote: Jason, is good or shall I use sth else (do we annotate in-charge vs. not in-charge constructors specially for example?). The names of the in-charge and not-in-charge constructor clones are complete_ctor_identifier and base_ctor_identifier (and dtor for destructors); you could check for those. Jason
Re: RFA: Testsuite PATCH to add support for dlopen tests
On 04/08/2014 04:10 AM, Dominique Dhumieres wrote:
r209187 causes thousands of g++ test failures. AFAICT the failing tests are
those with no
explicit 'dg-do compile' directive which are now trying to give an executable
while
before r209187 they were using -S.
Does this fix it?
commit 94d8c7a26b5c0a822ebf83f448c941f27023e2fe
Author: Jason Merrill
Date: Tue Apr 8 13:47:38 2014 -0400
* lib/gcc-dg.exp (dg-build-dso): Reset dg-do-what-default to
compile.
diff --git a/gcc/testsuite/lib/gcc-dg.exp b/gcc/testsuite/lib/gcc-dg.exp
index 89eec95..21ef0c2 100644
--- a/gcc/testsuite/lib/gcc-dg.exp
+++ b/gcc/testsuite/lib/gcc-dg.exp
@@ -229,6 +229,7 @@ proc dg-build-dso { args } {
set dir "[file dirname $main_file]"
set dg-do-what-default dso
dg-test -keep-output $dir/$file "" ""
+set dg-do-what-default compile
set output_file "[file rootname [file tail $file]].so"
append final-code "remove-build-file $output_file"
[committed] PR60763: POWER8 fallout from PR60604
The patch for PR60604 stopped nonimmediate_operand from accepting (subreg:M (reg:N R)) for combinations that are forbidden by REG_CANNOT_CHANGE_MODE_P, to match the existing register_operand behaviour. This stopped rs6000's movdi pattern from accepting such subregs as a destination (they were already not accepted as the source), which in turn meant the result of the reload_vsx_from_gprsf splitter didn't match. The last two patterns generated by reload_vsx_from_gprsf had the form: (set (subreg:DI (reg:SF FPR)) (reg:DI GPR)) (set (reg:SF FPR) (... (reg:SF FPR) ...)) The target of the first move is a (subreg:DI ...) rather than (reg:DI FPR) because the mode change is forbidden by CANNOT_CHANGE_MODE_CLASS. But in this case the sequence is really: (set (reg:DI FPR1) (reg:DI GPR)) (set (reg:SF FPR2) (... (reg:DI FPR1) ...)) where no mode change takes place as such. We just happen to be using the same FPR for FPR1 and FPR2. In those circumstances gen_rtx_REG seems more appropriate than simplify_gen_subreg. Tested by Pat and approved by David in the PR trail. Applied. Thanks, Richard gcc/ PR target/60763 * config/rs6000/vsx.md (vsx_xscvdpspn_scalar): Change input to DImode. * config/rs6000/rs6000.md (reload_vsx_from_gprsf): Update accordingly. Use gen_rtx_REG rather than simplify_gen_subreg for op0_di. Index: gcc/config/rs6000/vsx.md === --- gcc/config/rs6000/vsx.md2014-04-07 15:26:00.357746782 +0100 +++ gcc/config/rs6000/vsx.md2014-04-07 15:26:00.552748458 +0100 @@ -1223,7 +1223,7 @@ (define_insn "vsx_xscvdpspn_scalar" ;; Used by direct move to move a SFmode value from GPR to VSX register (define_insn "vsx_xscvspdpn_directmove" [(set (match_operand:SF 0 "vsx_register_operand" "=wa") - (unspec:SF [(match_operand:SF 1 "vsx_register_operand" "wa")] + (unspec:SF [(match_operand:DI 1 "vsx_register_operand" "wa")] UNSPEC_VSX_CVSPDPN))] "TARGET_XSCVSPDPN" "xscvspdpn %x0,%x1" Index: gcc/config/rs6000/rs6000.md === --- gcc/config/rs6000/rs6000.md 2014-04-07 15:26:00.356746773 +0100 +++ gcc/config/rs6000/rs6000.md 2014-04-08 18:14:31.668426223 +0100 @@ -10029,13 +10029,16 @@ (define_insn_and_split "reload_vsx_from_ rtx op0 = operands[0]; rtx op1 = operands[1]; rtx op2 = operands[2]; - rtx op0_di = simplify_gen_subreg (DImode, op0, SFmode, 0); + /* Also use the destination register to hold the unconverted DImode value. + This is conceptually a separate value from OP0, so we use gen_rtx_REG + rather than simplify_gen_subreg. */ + rtx op0_di = gen_rtx_REG (DImode, REGNO (op0)); rtx op1_di = simplify_gen_subreg (DImode, op1, SFmode, 0); /* Move SF value to upper 32-bits for xscvspdpn. */ emit_insn (gen_ashldi3 (op2, op1_di, GEN_INT (32))); emit_move_insn (op0_di, op2); - emit_insn (gen_vsx_xscvspdpn_directmove (op0, op0)); + emit_insn (gen_vsx_xscvspdpn_directmove (op0, op0_di)); DONE; } [(set_attr "length" "8")
Re: RFA: Testsuite PATCH to add support for dlopen tests
On Tue, 2014-04-08 at 10:10 +0200, Dominique Dhumieres wrote: > > richi asked for a testcase for 60731, and since we didn't already > > have support for tests using dlopen, I had to add it. > > Does this approach make sense? > > r209187 causes thousands of g++ test failures. AFAICT the failing tests are > those with no > explicit 'dg-do compile' directive which are now trying to give an executable > while > before r209187 they were using -S. On x86_64-apple-darwin13 the tests now > fail with > > Undefined symbols for architecture ... > > TIA > > Dominique I am seeing failures on MIPS bare iron as well. This toolchain does not support shared libraries and before the change it was not using '-fPIC -shared' during C++ compilations. Now it is and that causes GCC to generate an error message. Steve Ellcey
Re: [C PATCH] Warn if inline attributes conflict (PR c/18079)
On Mon, Mar 31, 2014 at 10:06:18AM +0200, Richard Biener wrote:
> > Sorry for the nit, but maybe it'd be better to use %qs for the second
> > attributes, so that we can use the same translation string for all
> > conflicts.
> > Same with the later messages (where the quotes that come with %qs are
> > probably needed too).
>
> Good point, patch is pre-approved (also adjusting the two other conflict
> warnings to spell out that the attribute is ignored).
Yes, that will be better, thanks and sorry for the delay. That patch
is staged for stage1 though, so I'll commit the following variant
instead once the stage1 opens.
2014-04-08 Marek Polacek
PR c/18079
c/
* c-decl.c (diagnose_mismatched_decls): Warn for mismatched
always_inline/noinline and hot/cold attributes.
c-family/
* c-common.c (handle_noinline_attribute): Warn if the attribute
conflicts with always_inline attribute.
(handle_always_inline_attribute): Warn if the attribute conflicts
with noinline attribute.
testsuite/
* gcc.dg/pr18079.c: New test.
* gcc.dg/pr18079-2.c: New test.
diff --git gcc/c-family/c-common.c gcc/c-family/c-common.c
index 03731b4..0cd3c10 100644
--- gcc/c-family/c-common.c
+++ gcc/c-family/c-common.c
@@ -6564,8 +6564,8 @@ handle_hot_attribute (tree *node, tree name, tree
ARG_UNUSED (args),
{
if (lookup_attribute ("cold", DECL_ATTRIBUTES (*node)) != NULL)
{
- warning (OPT_Wattributes, "%qE attribute conflicts with attribute %s",
- name, "cold");
+ warning (OPT_Wattributes, "%qE attribute ignored due to conflict "
+ "with attribute %qs", name, "cold");
*no_add_attrs = true;
}
/* Most of the rest of the hot processing is done later with
@@ -6592,8 +6592,8 @@ handle_cold_attribute (tree *node, tree name, tree
ARG_UNUSED (args),
{
if (lookup_attribute ("hot", DECL_ATTRIBUTES (*node)) != NULL)
{
- warning (OPT_Wattributes, "%qE attribute conflicts with attribute %s",
- name, "hot");
+ warning (OPT_Wattributes, "%qE attribute ignored due to conflict "
+ "with attribute %qs", name, "hot");
*no_add_attrs = true;
}
/* Most of the rest of the cold processing is done later with
@@ -,7 +,16 @@ handle_noinline_attribute (tree *node, tree name,
int ARG_UNUSED (flags), bool *no_add_attrs)
{
if (TREE_CODE (*node) == FUNCTION_DECL)
-DECL_UNINLINABLE (*node) = 1;
+{
+ if (lookup_attribute ("always_inline", DECL_ATTRIBUTES (*node)))
+ {
+ warning (OPT_Wattributes, "%qE attribute ignored due to conflict "
+ "with attribute %qs", name, "always_inline");
+ *no_add_attrs = true;
+ }
+ else
+ DECL_UNINLINABLE (*node) = 1;
+}
else
{
warning (OPT_Wattributes, "%qE attribute ignored", name);
@@ -6704,9 +6713,16 @@ handle_always_inline_attribute (tree *node, tree name,
{
if (TREE_CODE (*node) == FUNCTION_DECL)
{
- /* Set the attribute and mark it for disregarding inline
-limits. */
- DECL_DISREGARD_INLINE_LIMITS (*node) = 1;
+ if (lookup_attribute ("noinline", DECL_ATTRIBUTES (*node)))
+ {
+ warning (OPT_Wattributes, "%qE attribute ignored due to conflict "
+ "with %qs attribute", name, "noinline");
+ *no_add_attrs = true;
+ }
+ else
+ /* Set the attribute and mark it for disregarding inline
+ limits. */
+ DECL_DISREGARD_INLINE_LIMITS (*node) = 1;
}
else
{
diff --git gcc/c/c-decl.c gcc/c/c-decl.c
index df84980..e30876c 100644
--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -2099,18 +2099,38 @@ diagnose_mismatched_decls (tree newdecl, tree olddecl,
/* Diagnose inline __attribute__ ((noinline)) which is silly. */
if (DECL_DECLARED_INLINE_P (newdecl)
&& lookup_attribute ("noinline", DECL_ATTRIBUTES (olddecl)))
- {
- warned |= warning (OPT_Wattributes,
-"inline declaration of %qD follows "
-"declaration with attribute noinline", newdecl);
- }
+ warned |= warning (OPT_Wattributes,
+ "inline declaration of %qD follows "
+ "declaration with attribute noinline", newdecl);
else if (DECL_DECLARED_INLINE_P (olddecl)
&& lookup_attribute ("noinline", DECL_ATTRIBUTES (newdecl)))
- {
- warned |= warning (OPT_Wattributes,
-"declaration of %q+D with attribute "
-"noinline follows inline declaration ", newdecl);
- }
+ warned |= warning (OPT_Wattributes,
+ "declaration of %q+D with attribute "
+ "noinline follows inline declaration ", newdecl);
+ else if (lookup_attri
Re: Fix wrong code issue in ipa-devirt
> Hi, > > On Tue, Apr 08, 2014 at 06:13:27AM +0200, Jan Hubicka wrote: > > Hi, > > while looking into devirtualization dumps, I noticed that I got one "false" > > typed out as "true". Not sure what I was thinking of. > > > > Martin, this may fix the wrong code issue you see in Firefox, hopefully. > > it did not segfault the whole afternoon, so yes, I believe this is the > fix. Great, because all builds of firefox now segfaults for me at startup, so I will try to fix my setup ;)) Honza > > Thanks, > > Martin
[PATCH] Don't dump bb details when removing a block
This patch removes the printing of details for BBs that are being removed.
When printing bb details, dump_bb_info will invoke check_bb_profile, which will
flag spurious profile insanities in the removed bb since the incoming edges
have already been removed. This makes it harder to identify true profile
insanities in dumps, both for the gcc testsuite and in my own testing when I
have been trying to identify and fix profile insanities introduced by
optimization.
The other effects of removing the details printing is that the profile counts
on the bb being removed, as well as its prev and next blocks, are suppressed,
which doesn't strike me as a problem. In fact, one of the tests needed its
expected dump output adjusted from my change, and in looking at that I
discovered that the profile count it was scanning for was matching that of a
removed block after a recent change (r208165), instead of a block in the
optimized code.
Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok for either trunk or
stage 1?
Thanks,
Teresa
2014-04-08 Teresa Johnson
* tree-cfg.c (remove_bb): Don't dump details during bb removal.
2014-04-08 Teresa Johnson
* gcc.dg/tree-prof/update-loopch.c: Update expected output.
Index: tree-cfg.c
===
--- tree-cfg.c (revision 208492)
+++ tree-cfg.c (working copy)
@@ -1947,7 +1947,7 @@ remove_bb (basic_block bb)
fprintf (dump_file, "Removing basic block %d\n", bb->index);
if (dump_flags & TDF_DETAILS)
{
- dump_bb (dump_file, bb, 0, dump_flags);
+ dump_bb (dump_file, bb, 0, dump_flags && ~TDF_DETAILS);
fprintf (dump_file, "\n");
}
}
Index: testsuite/gcc.dg/tree-prof/update-loopch.c
===
--- testsuite/gcc.dg/tree-prof/update-loopch.c (revision 208492)
+++ testsuite/gcc.dg/tree-prof/update-loopch.c (working copy)
@@ -15,8 +15,9 @@ main ()
is once reached directly from entry point of function, rest via loopback
edge. */
/* { dg-final-use { scan-ipa-dump "loop depth 1, count 4" "profile"} } */
-/* { dg-final-use { scan-tree-dump "loop depth 1, count 2"
"optimized"} } */
-/* { dg-final-use { scan-tree-dump-times "Removing basic block
\[^\r\n\]*\[\\r\\n\]+\[^\r\n\]*\[\\r\\n\]+Invalid sum
of\[^\r\n\]*\[\\r\\n\]+Invalid sum of" 1 "optimized"} } */
-/* { dg-final-use { scan-tree-dump-times "Invalid sum of" 2 "optimized"} } */
+/* { dg-final-use { scan-tree-dump "loop depth 1, count 3"
"optimized"} } */
+/* { dg-final-use { scan-tree-dump-not "loop depth 1, count 2"
"optimized"} } */
+/* { dg-final-use { scan-tree-dump "Removing basic block" "optimized"} } */
+/* { dg-final-use { scan-tree-dump-not "Invalid sum" "optimized"} } */
/* { dg-final-use { cleanup-ipa-dump "profile" } } */
/* { dg-final-use { cleanup-tree-dump "optimized" } } */
--
Teresa Johnson | Software Engineer | tejohn...@google.com | 408-460-2413
Re: Fix wrong code issue in ipa-devirt
Hi, On Tue, Apr 08, 2014 at 06:13:27AM +0200, Jan Hubicka wrote: > Hi, > while looking into devirtualization dumps, I noticed that I got one "false" > typed out as "true". Not sure what I was thinking of. > > Martin, this may fix the wrong code issue you see in Firefox, hopefully. it did not segfault the whole afternoon, so yes, I believe this is the fix. Thanks, Martin > > Will commit it after x86_64-linux testing finishes tomorrow. > Honza > > * ipa-devirt.c (maybe_record_node): Set completep to false > instead of true when node is not recorded. > Index: ipa-devirt.c > === > --- ipa-devirt.c (revision 209170) > +++ ipa-devirt.c (working copy) > @@ -650,7 +650,7 @@ maybe_record_node (vec & >else if (completep > && !type_in_anonymous_namespace_p >(method_class_type (TREE_TYPE (target > -*completep = true; > +*completep = false; > } > > /* See if BINFO's type match OUTER_TYPE. If so, lookup
Re: [DOC PATCH] Clarify docs about stmt exprs (PR c/51088)
On Fri, Mar 28, 2014 at 02:44:21PM +, Joseph S. Myers wrote:
> On Fri, 28 Mar 2014, Marek Polacek wrote:
>
> > PR51088 contains some Really Bizzare code. We should tell users
> > not to do any shenanigans like that.
> >
> > Ok for trunk?
>
> I don't think a doc patch resolves this bug. The compiler should never
> generate code with an undefined reference to a local label like that;
> either the code should get a compile-time error (that's what I suggest),
> or it should generate output that links but has undefined behavior at
> runtime.
Ok, with this patch the compiler should issue an error if someone's
trying to take an address of a label defined in a statement expression
outside of that statement expression.
I admit this was very tricky; I had to completely revamp the patch
several times, this one is the least disrupting and simplest one
I could come up with. It works by marking labels that are declared
outside of stmt expr while we're entering a stmt expr (but we mustn't
do this for nested stmt exprs). If we're then defining the label in
stmt expr and it was referenced outside of this stmt expr, raise an error.
This patch doesn't catch cases like ({ A:0; }); &&A;, in that case the
behavior is just undefined.
Does this approach make sense?
Regtested/bootstrapped on x86_64-linux. I don't think it's stage4 material,
so ok for next stage1?
2014-04-08 Marek Polacek
PR c/51088
* c-decl.c (stmt_expr_depth): New variable.
(struct c_label_vars): Add seen_outside_stmt_expr variable.
(c_bindings_start_stmt_expr): Bump stmt_expr_depth. Mark labels
declared outside of statement expressions.
(c_bindings_end_stmt_expr): Decrement stmt_expr_depth.
(make_label): Set seen_outside_stmt_expr.
(check_earlier_gotos): Return true if error was issued.
(define_label): Give error if taking an address of a label defined
in statement expression outside of the statement expression.
* doc/extend.texi (Statement Exprs): Add note about taking
addresses of labels inside of statement expressions.
* gcc.c-torture/compile/pr17913.c (f): Add dg-error.
* gcc.dg/pr51088.c: New test.
diff --git gcc/c/c-decl.c gcc/c/c-decl.c
index df84980..15663ae 100644
--- gcc/c/c-decl.c
+++ gcc/c/c-decl.c
@@ -157,6 +157,9 @@ enum machine_mode c_default_pointer_mode = VOIDmode;
/* If non-zero, implicit "omp declare target" attribute is added into the
attribute lists. */
int current_omp_declare_target_attribute;
+
+/* Remember how many statement expressions we've entered. */
+static int stmt_expr_depth;
/* Each c_binding structure describes one binding of an identifier to
a decl. All the decls in a scope - irrespective of namespace - are
@@ -313,6 +316,8 @@ struct GTY(()) c_label_vars {
goto statements seen before the label was defined, so that we can
issue appropriate warnings for them. */
vec *gotos;
+ /* Whether this label is referenced outside of statement expression. */
+ bool seen_outside_stmt_expr;
};
/* Each c_scope structure describes the complete contents of one
@@ -1360,6 +1365,16 @@ c_bindings_start_stmt_expr (struct c_spot_bindings*
switch_bindings)
{
struct c_scope *scope;
+ /* We entered a statement expression. */
+ stmt_expr_depth++;
+
+ if (stmt_expr_depth == 1)
+/* Remember which labels are declared outside of statement exprs. */
+for (struct c_binding *b = current_function_scope->bindings;
+b != NULL; b = b->prev)
+ if (TREE_CODE (b->decl) == LABEL_DECL)
+ b->u.label->seen_outside_stmt_expr = true;
+
for (scope = current_scope; scope != NULL; scope = scope->outer)
{
struct c_binding *b;
@@ -1393,6 +1408,9 @@ c_bindings_end_stmt_expr (struct c_spot_bindings
*switch_bindings)
{
struct c_scope *scope;
+ /* We're leaving a statement expression. */
+ stmt_expr_depth--;
+
for (scope = current_scope; scope != NULL; scope = scope->outer)
{
struct c_binding *b;
@@ -3074,6 +3092,7 @@ make_label (location_t location, tree name, bool defining,
set_spot_bindings (&label_vars->label_bindings, defining);
label_vars->decls_in_scope = make_tree_vector ();
label_vars->gotos = NULL;
+ label_vars->seen_outside_stmt_expr = false;
*p_label_vars = label_vars;
return label;
@@ -3228,11 +3247,12 @@ declare_label (tree name)
/* When we define a label, issue any appropriate warnings if there are
any gotos earlier in the function which jump to this label. */
-static void
+static bool
check_earlier_gotos (tree label, struct c_label_vars* label_vars)
{
unsigned int ix;
struct c_goto_bindings *g;
+ bool error_p = false;
FOR_EACH_VEC_SAFE_ELT (label_vars->gotos, ix, g)
{
@@ -3276,6 +3296,7 @@ check_earlier_gotos (tree label, struct c_label_vars*
label_vars)
if (g->goto_bindings.stmt_exprs > 0)
{
+ error_p = true;
error_at (g->loc, "jump in
Define patch for atxmega256a3bu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
I just found a little typo in gcc/config/avr/avr-mcus.def.
For the atxmega256a3bu the define is wrong __AVR_ATxmega258A3BU__ I
changed it to __AVR_ATxmega256A3BU__.
The patch is in the attachment.
Regards
Georg von Zengen
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/
iQIcBAEBAgAGBQJTRBZKAAoJEPFuaghsrAvJIl0QAIlrmYzN7TZS978iKLgku5IU
qRVU08BzKvJxxqjX47Hwa59t8Dych+3czRlK7dAkFhLSyGNA+MfiwoX/5R8Us5/v
7TylULoSnOe8YDdhV532lEJ9SVu1wLnzYUGTrk9r6Jn0c1B5Yg2gDmPoU4Z+Bd6l
uqReShzsEstelUdi6ESvZCIPSe4mMrcYgMKJPib3g1XCh2D6dDTFnBb1z34D1pfR
DPiEwgUxmtca3rASw1ISSWswLylwDtZZgfI8Zn7xpYIafhTuuElzEr/buUeU73Z1
TqNPbMbWJ3JJd4mTfidMUqAi8ke3Y0lwUZXD6SxocY4eLy7uOxNk3Otgqet9/igu
EnCmKJrCnGAW1cHTKz7cDTsSfVOwWItoDmbnP/o4PiitbckcF6tJLwCcpxgTFjxx
h2f5eNDt4sykp2t5QygG2DgmnPLIhIvX78U0svheste5hYUVErTcX4VG0nR/0mwg
HSYcw33jDDKDkEpVY/OOg7v7XRcc8FrGdUJ2MhtfCxH5To+QQvFnMM9oemq7k9Vh
nx2GsVidAmBJ5YIz3Mir0mBzhROs7KIJGR/KM36sxFAagg0RVB8OoHWCLOTcAOcq
v+RbKn+2U3yZxwGI+UPCroDzB4df7b8CRKXVlRvifxOHzi7CenudGTTG5eh6AYNT
q7oEWNjWSgxvXWnXmkwR
=t5JB
-END PGP SIGNATURE-
Index: ChangeLog
===
--- ChangeLog (revision 209209)
+++ ChangeLog (working copy)
@@ -1,3 +1,7 @@
+2014-04-08 Georg von Zengen
+
+ * gcc/config/avr/avr-mcus.def: Fixed typo in definition of atxmega256a3bu
+
2014-04-04 Eric Botcazou
PR bootstrap/60620
Index: gcc/config/avr/avr-mcus.def
===
--- gcc/config/avr/avr-mcus.def (revision 209209)
+++ gcc/config/avr/avr-mcus.def (working copy)
@@ -291,7 +291,7 @@
AVR_MCU ("atxmega192d3", ARCH_AVRXMEGA6, AVR_ISA_NONE, "__AVR_ATxmega192D3__", 0x2000, 4, "x192d3")
AVR_MCU ("atxmega256a3", ARCH_AVRXMEGA6, AVR_ISA_NONE, "__AVR_ATxmega256A3__", 0x2000, 5, "x256a3")
AVR_MCU ("atxmega256a3b",ARCH_AVRXMEGA6, AVR_ISA_NONE, "__AVR_ATxmega256A3B__",0x2000, 5, "x256a3b")
-AVR_MCU ("atxmega256a3bu", ARCH_AVRXMEGA6, AVR_ISA_NONE, "__AVR_ATxmega258A3BU__", 0x2000, 5, "x256a3bu")
+AVR_MCU ("atxmega256a3bu", ARCH_AVRXMEGA6, AVR_ISA_NONE, "__AVR_ATxmega256A3BU__", 0x2000, 5, "x256a3bu")
AVR_MCU ("atxmega256d3", ARCH_AVRXMEGA6, AVR_ISA_NONE, "__AVR_ATxmega256D3__", 0x2000, 5, "x256d3")
AVR_MCU ("atxmega128a3u",ARCH_AVRXMEGA6, AVR_ISA_RMW, "__AVR_ATxmega128A3U__",0x2000, 3, "x128a3u")
AVR_MCU ("atxmega128b1", ARCH_AVRXMEGA6, AVR_ISA_RMW, "__AVR_ATxmega128B1__", 0x2000, 3, "x128b1")
atxmega256a3bu.patch.sig
Description: PGP signature
Re: [PATCH] Adjust builtin-bswap-6/7
On Tue, Apr 08, 2014 at 12:41:02PM +0200, Jakub Jelinek wrote:
> Thus, please commit any of these variants, if you go for
> /* { dg-additional-options "-mbranch-cost=0" { target s390*-*-* } } */
> plus reverting your earlier changes, you can also consider
> addition of two new tests that would contain the return {1,2} and have -O2.
I've just committed the following patch:
2014-04-08 Andreas Krebbel
PR rtl-optimization/60776
* gcc.dg/builtin-bswap-6.c: Use -mbranch-cost=0 for s390.
* gcc.dg/builtin-bswap-7.c: Likewise.
* gcc.dg/builtin-bswap-6a.c: New testcase.
* gcc.dg/builtin-bswap-7a.c: New testcase.
Revert
2014-04-04 Andreas Krebbel
* gcc.dg/builtin-bswap-6.c: Adjust return value to disable GCC
optimization.
* gcc.dg/builtin-bswap-7.c: Likewise.
diff --git a/gcc/testsuite/gcc.dg/builtin-bswap-6.c
b/gcc/testsuite/gcc.dg/builtin-bswap-6.c
index 6f0c782..efda870 100644
--- a/gcc/testsuite/gcc.dg/builtin-bswap-6.c
+++ b/gcc/testsuite/gcc.dg/builtin-bswap-6.c
@@ -1,11 +1,10 @@
/* { dg-do compile { target arm*-*-* alpha*-*-* i?86-*-* powerpc*-*-*
rs6000-*-* x86_64-*-* s390*-*-* } } */
/* { dg-require-effective-target stdint_types } */
/* { dg-options "-O -fdump-rtl-combine" } */
-/* { dg-options "-O -fdump-rtl-combine -march=z900" { target s390-*-* } } */
-/* The test intentionally returns 1/2 instead of the obvious 0/1 to
- prevent GCC from calculating the return value with arithmetic
- instead of a comparison. */
+/* The branch cost setting prevents the return value from being
+ calculated with arithmetic instead of doing a compare. */
+/* { dg-additional-options "-march=z900 -mbranch-cost=0" { target s390*-*-* }
} */
#include
@@ -15,28 +14,28 @@ int foo1 (uint32_t a)
{
if (BS (a) == 0xA)
return 1;
- return 2;
+ return 0;
}
int foo2 (uint32_t a)
{
if (BS (a) != 0xA)
return 1;
- return 2;
+ return 0;
}
int foo3 (uint32_t a, uint32_t b)
{
if (BS (a) == BS (b))
return 1;
- return 2;
+ return 0;
}
int foo4 (uint32_t a, uint32_t b)
{
if (BS (a) != BS (b))
return 1;
- return 2;
+ return 0;
}
/* { dg-final { scan-rtl-dump-not "bswapsi" "combine" } } */
diff --git a/gcc/testsuite/gcc.dg/builtin-bswap-6a.c
b/gcc/testsuite/gcc.dg/builtin-bswap-6a.c
new file mode 100644
index 000..f93bcde
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/builtin-bswap-6a.c
@@ -0,0 +1,44 @@
+/* { dg-do compile { target arm*-*-* alpha*-*-* i?86-*-* powerpc*-*-*
rs6000-*-* x86_64-*-* s390*-*-* } } */
+/* { dg-require-effective-target stdint_types } */
+/* { dg-options "-O2 -fdump-rtl-combine" } */
+/* { dg-additional-options "-march=z900" { target s390-*-* } } */
+
+/* The test is similiar to builtin-bswap-6.c but returns 1/2 instead
+ of 0/1 to prevent GCC from calculating the return value with
+ arithmetic instead of a comparison. This requires the optimization
+ level to be bumped up to -O2 at least for x86_64. */
+
+#include
+
+#define BS(X) __builtin_bswap32(X)
+
+int foo1 (uint32_t a)
+{
+ if (BS (a) == 0xA)
+return 1;
+ return 2;
+}
+
+int foo2 (uint32_t a)
+{
+ if (BS (a) != 0xA)
+return 1;
+ return 2;
+}
+
+int foo3 (uint32_t a, uint32_t b)
+{
+ if (BS (a) == BS (b))
+return 1;
+ return 2;
+}
+
+int foo4 (uint32_t a, uint32_t b)
+{
+ if (BS (a) != BS (b))
+return 1;
+ return 2;
+}
+
+/* { dg-final { scan-rtl-dump-not "bswapsi" "combine" } } */
+/* { dg-final { cleanup-rtl-dump "combine" } } */
diff --git a/gcc/testsuite/gcc.dg/builtin-bswap-7.c
b/gcc/testsuite/gcc.dg/builtin-bswap-7.c
index 0eecdd8..035c736 100644
--- a/gcc/testsuite/gcc.dg/builtin-bswap-7.c
+++ b/gcc/testsuite/gcc.dg/builtin-bswap-7.c
@@ -3,9 +3,9 @@
/* { dg-require-effective-target lp64 } */
/* { dg-options "-O -fdump-rtl-combine" } */
-/* The test intentionally returns 1/2 instead of the obvious 0/1 to
- prevent GCC from calculating the return value with arithmetic
- instead of a comparison. */
+/* The branch cost setting prevents the return value from being
+ calculated with arithmetic instead of doing a compare. */
+/* { dg-additional-options "-mbranch-cost=0" { target s390x-*-* } } */
#include
@@ -15,28 +15,28 @@ int foo1 (uint64_t a)
{
if (BS (a) == 0xA)
return 1;
- return 2;
+ return 0;
}
int foo2 (uint64_t a)
{
if (BS (a) != 0xA)
return 1;
- return 2;
+ return 0;
}
int foo3 (uint64_t a, uint64_t b)
{
if (BS (a) == BS (b))
return 1;
- return 2;
+ return 0;
}
int foo4 (uint64_t a, uint64_t b)
{
if (BS (a) != BS (b))
return 1;
- return 2;
+ return 0;
}
/* { dg-final { scan-rtl-dump-not "bswapdi" "combine" } } */
diff --git a/gcc/testsuite/gcc.dg/builtin-bswap-7a.c
b/gcc/testsuite/gcc.dg/builtin-bswap-7a.c
new file mode 100644
index 000..d77bd47
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/builtin-bswap-7a.c
@@ -0,0 +1,44 @@
+/* { dg-do compile {
Re: [PATCH v7?] PR middle-end/60281
Hi Bernd, in a way,yes.I am testing it.Since I don't have a FSF copyright mark,and I have no idea what is that file saying,I can't commit my patch.If you are interested in it,please help me commit it. By the way,there is another way to work it out,and it has been mentioned in the previous(I don't know how previous) mail.That is to use unaligned instructions instead of aligned ones on the armv7 or above platform.That has to modify part of machine desc of arm platform.I can't tell you it's one of the define_peephole.I have no time to test this idea yet.If you are interested in that way,please test this one.It's always better when there is an option. -- Regards lin zuojian
RE: [PATCH v7?] PR middle-end/60281
Lin, are you still working on this? Thanks Bernd.
FW: [PATCH, FORTRAN] Class Name Clash
Sorry, wrong subject, again... > > Hi, > > this patch fixes a recently discovered name-clash in gfc_build_class_symbol. > > Fortunately it is quite easy to fix: just make sure that the class names of > target > classes end with "_t", and target array classes end with "[0-9]t". > This trick makes all names unique again. > > I hope it is not too late, and this can still go into 4.9.0. > > Boot-Strapped without any regressions on x86_64-unknown-linux-gnu. > > Ok for trunk? > > Thanks > Bernd. > gcc: 2014-04-08 Bernd Edlinger * fortran/class.c (gfc_build_class_symbol): Append "_t" to target class names to make the generated type names unique. testsuite: 2014-04-08 Bernd Edlinger * gfortran.dg/class_nameclash.f90: New test. patch-class.diff Description: Binary data
Re: Please revert the patches in bug #54040 and #59346 and special case x32
On Tue, 2014-04-08 at 09:26 +0200, Eric Botcazou wrote: > > Attached is a patch reverting the two commits for PR ada/54040: > > http://gcc.gnu.org/git/?p=gcc.git&a=search&h=HEAD&st=commit&s=PR+ada% > > 2F54040 > > I don't think that's sufficient though, IIRC there were followup changes, so > you'd better diff the current code with the revision just prior to the change. The only changes I've found are: (in the previously attached patch) (the other commits refer to 2014-01-26: lynxos 2014-01-24: android 2014-01-20: linux 2013-01-29 : vms and they are not related to the patches needing a revert. (I did make a diff from current to the version before and did not find anything new). I have also built the reverted version on GNU/Linux x86-64 out of the box. The only thing needed to change after the revert might be copyright years. commit d2a4f256f9bc035ef2d6874c4e4c20c83ebf00b4 Author: ebotcazou Date: Fri Nov 29 16:19:36 2013 + PR ada/54040 PR ada/59346 * s-osinte-hpux.ads (timespec): Change type of tv_nsec field to time_t. * s-osinte-kfreebsd-gnu.ads (timespec): Likewise. * s-osinte-solaris-posix.ads (timespec): Li2014-01-24kewise. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@205532 138bc75d-0d04-0410-961f-82ee72b0 commit e3a1f6b50495473f677f413d8740808a3fde5a9a Author: hjl Date: Fri Nov 15 12:06:25 2013 + Add and use System.Linux.time_t for time_t PR ada/54040 * s-linux-x32.ads: New file. * s-osprim-x32.adb: Likewise. * s-linux.ads (time_t): New type. * s-linux-alpha.ads (time_t): Likewise. * s-linux-hppa.ads (time_t): Likewise. * s-linux-mipsel.ads (time_t): Likewise. * s-linux-sparc.ads (time_t): Likewise. * s-osinte-linux.ads (time_t): Mark it private. Replace long with System.Linux.time_t. (timespec): Replace long with time_t. * s-osinte-posix.adb (To_Timespec): Likewise. * s-taprop-linux.adb (timeval): Replace C.long with System.OS_Interface.time_t. * gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS): Replace s-linux.ads with s-linux-x32.ads, s-osprim-posix.adb with s-osprim-x32.adb for x32. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@204840 138bc75d-0d04-0410-961f-82ee72b0 Then we have but this one was before adding x32-specific files: commit 70d595c8e41c9a7fdf5049c5a48c3b50304c8cbe Author: hjl Date: Sat Mar 3 17:04:49 2012 + Add Linux/x32 support to Ada 2012-03-03 H.J. Lu * init.c (__gnat_adjust_context_for_raise): Also check "orq $0x0,(%esp)" for x32. * link.c (__gnat_default_libgcc_subdir): set to libx32 for x32. * gcc-interface/Makefile.in (arch): Set to x32 if MULTISUBDIR is /x32. Support x32. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@184859 138bc75d-0d04-0410-961f-82ee72b0
Re: [PATCH] Fix PR60706
On 8-Apr-14, at 6:06 AM, Richard Biener wrote: Dave, did testing on hppa2.0w-hp-hpux11.11 show any testsuite fallout? No. It fixes the PR and there were no observed regressions on hppa2.0w-hp-hpux11.11, hppa-unknown-linux-gnu and hppa64-hp-hpux11.11. This covers host wide integers of 32 and 64 bits. Dave -- John David Anglin dave.ang...@bell.net
[PATCH, FORTRAN]
Hi, this patch fixes a recently discovered name-clash in gfc_build_class_symbol. Fortunately it is quite easy to fix: just make sure that the class names of target classes end with "_t", and target array classes end with "[0-9]t". This trick makes all names unique again. I hope it is not too late, and this can still go into 4.9.0. Boot-Strapped without any regressions on x86_64-unknown-linux-gnu. Ok for trunk? Thanks Bernd. gcc: 2014-04-08 Bernd Edlinger * fortran/class.c (gfc_build_class_symbol): Append "_t" to target class names to make the generated type names unique. testsuite: 2014-04-08 Bernd Edlinger * gfortran.dg/class_nameclash.f90: New test. patch-class.diff Description: Binary data
Re: [PATCH][C++] Fix PR60761, diagnostics in clones
On Tue, Apr 08, 2014 at 01:58:06PM +0200, Richard Biener wrote: > t.ii: In function 'void foo(int) ': > t.ii:14:13: warning: iteration 3u invokes undefined behavior > [-Waggressive-loop-optimizations] > z[i] = i; > ^ Looks reasonable to me, but I'll defer this to Jason. > 2014-04-08 Richard Biener > > cp/ > * error.c: Include cgraph.h Missing dot at the end of line. > (dump_decl): Print function clones as their origin plus > appended instead of just . Jakub
[PATCH][C++] Fix PR60761, diagnostics in clones
This fixes PR60761 by dumping decl context of function clones
as origin with appended instead of that now
appears after we (compared to 4.8) clear DECL_LANG_SPECIFIC.
Thus for the testcase in PR60761 we now print
t.ii: In function 'void foo(int) ':
t.ii:14:13: warning: iteration 3u invokes undefined behavior
[-Waggressive-loop-optimizations]
z[i] = i;
^
t.ii:13:3: note: containing loop
for (int i = 0; i < s; i++)
^
t.ii:14:8: warning: array subscript is above array bounds [-Warray-bounds]
z[i] = i;
^
instead of
t.ii: In function ‘’:
t.ii:14:13: warning: iteration 3u invokes undefined behavior
[-Waggressive-loop-optimizations]
z[i] = i;
^
t.ii:13:3: note: containing loop
for (int i = 0; i < s; i++)
^
t.ii:14:8: warning: array subscript is above array bounds [-Warray-bounds]
z[i] = i;
^
or with 4.8
t.ii: In function ‘void _Z3fooi.constprop.0()’:
t.ii:14:8: warning: array subscript is above array bounds [-Warray-bounds]
z[i] = i;
^
IMHO an improvement over both variants.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Honza - does ->former_clone_of apply recursively or do I have to
loop to find the "ultimate" clone-of? Jason, is good
or shall I use sth else (do we annotate in-charge vs. not in-charge
constructors specially for example?).
Ok?
Thanks,
Richard.
2014-04-08 Richard Biener
cp/
* error.c: Include cgraph.h
(dump_decl): Print function clones as their origin plus
appended instead of just .
Index: gcc/cp/error.c
===
*** gcc/cp/error.c (revision 209210)
--- gcc/cp/error.c (working copy)
*** along with GCC; see the file COPYING3.
*** 34,39
--- 34,40
#include "pointer-set.h"
#include "c-family/c-objc.h"
#include "ubsan.h"
+ #include "cgraph.h"
#include // For placement-new.
*** dump_decl (cxx_pretty_printer *pp, tree
*** 1145,1151
case FUNCTION_DECL:
if (! DECL_LANG_SPECIFIC (t))
! pp_string (pp, M_(""));
else if (DECL_GLOBAL_CTOR_P (t) || DECL_GLOBAL_DTOR_P (t))
dump_global_iord (pp, t);
else
--- 1146,1162
case FUNCTION_DECL:
if (! DECL_LANG_SPECIFIC (t))
! {
! cgraph_node *node;
! if ((node = cgraph_get_node (t))
! && node->former_clone_of)
! {
! dump_decl (pp, node->former_clone_of, flags);
! pp_string (pp, M_(" "));
! }
! else
! pp_string (pp, M_(""));
! }
else if (DECL_GLOBAL_CTOR_P (t) || DECL_GLOBAL_DTOR_P (t))
dump_global_iord (pp, t);
else
[C++ Patch/RFC] PR 59115
Hi,
I have been working on this issue, a minor regression, looking for the
safest fix. What I have got so far seems neat enough to me, but maybe
not totally safe (from the diagnostic quality point of view only, of
course).
The ICE happens in unify, in:
/* Check for mixed types and values. */
if ((TREE_CODE (parm) == TEMPLATE_TYPE_PARM
&& TREE_CODE (tparm) != TYPE_DECL)
|| (TREE_CODE (parm) == TEMPLATE_TEMPLATE_PARM
&& TREE_CODE (tparm) != TEMPLATE_DECL))
gcc_unreachable ();
because, after the meaningful error message about the float non-type
template parameter, unify wrongly handles, for parm == U, tparm == int.
Obviously something is wrong with the indexing. This is because
process_template_parm, upon error, early returns a chainon (list,
err_parm_list), where TREE_VALUE (err_parm_list) == error_mark_node,
thus no index information (build_template_parm_index is not used at
all). This means that, afterward, when process_template_parm processes
the next template parameters, the code at the beginning isn't really
able to figure out the index of tree_last (list) and all the following
template parameters have it off by one (*). Thus my idea of returning to
the changes in r116473, which included the addition of the early
returns, to not append simply an error_mark_node as parm, but the actual
parm with its TREE_TYPE replaced by an error_mark_node. This way the
indexes are computed normally and unify doesn't get confused. Besides
that, I went through the rest of r116473 and made sure we use
error_operand_p, to catch the TREE_TYPEs (I also added 3/4 more besides
those in that commit, which seemed obviously correct). What do you think?
Tested x86_64-linux.
Thanks,
Paolo.
(*) Interestingly, replacing the block at beginning of
process_template_parm with something simply using list_length would
**almost** work: the only regressions are -std=c++1y, due to the calls
by synthesize_implicit_template_parm, which tracks the end of the
template parameters list for compile-time performance reasons, thus
list_length doesn't match the actual length of the whole list as stored
as an index in tree_last. Looking forward, we should probably consider
handling consistently both real and synthesized parameters.
//
Index: cp/pt.c
===
--- cp/pt.c (revision 209212)
+++ cp/pt.c (working copy)
@@ -414,7 +414,7 @@ push_inline_template_parms_recursive (tree parmlis
{
tree parm = TREE_VALUE (TREE_VEC_ELT (parms, i));
- if (parm == error_mark_node)
+ if (error_operand_p (parm))
continue;
gcc_assert (DECL_P (parm));
@@ -2829,7 +2829,7 @@ comp_template_parms (const_tree parms1, const_tree
/* If either of the template parameters are invalid, assume
they match for the sake of error recovery. */
- if (parm1 == error_mark_node || parm2 == error_mark_node)
+ if (error_operand_p (parm1) || error_operand_p (parm2))
return 1;
if (TREE_CODE (parm1) != TREE_CODE (parm2))
@@ -3640,11 +3640,7 @@ reduce_template_parm_level (tree index, tree type,
to the LIST being built. This new parameter is a non-type
parameter iff IS_NON_TYPE is true. This new parameter is a
parameter pack iff IS_PARAMETER_PACK is true. The location of PARM
- is in PARM_LOC. NUM_TEMPLATE_PARMS is the size of the template
- parameter list PARM belongs to. This is used used to create a
- proper canonical type for the type of PARM that is to be created,
- iff PARM is a type. If the size is not known, this parameter shall
- be set to 0. */
+ is in PARM_LOC. */
tree
process_template_parm (tree list, location_t parm_loc, tree parm,
@@ -3652,7 +3648,6 @@ process_template_parm (tree list, location_t parm_
{
tree decl = 0;
tree defval;
- tree err_parm_list;
int idx = 0;
gcc_assert (TREE_CODE (parm) == TREE_LIST);
@@ -3673,8 +3668,6 @@ process_template_parm (tree list, location_t parm_
++idx;
}
- else
-idx = 0;
if (is_non_type)
{
@@ -3682,39 +3675,29 @@ process_template_parm (tree list, location_t parm_
SET_DECL_TEMPLATE_PARM_P (parm);
- if (TREE_TYPE (parm) == error_mark_node)
-{
- err_parm_list = build_tree_list (defval, parm);
- TREE_VALUE (err_parm_list) = error_mark_node;
- return chainon (list, err_parm_list);
-}
- else
- {
- /* [temp.param]
+ if (TREE_TYPE (parm) != error_mark_node)
+ {
+ /* [temp.param]
- The top-level cv-qualifiers on the template-parameter are
- ignored when determining its type. */
- TREE_TYPE (parm) = TYPE_MAIN_VARIANT (TREE_TYPE (parm));
- if (invalid_nontype_parm_type_p (TREE_TYPE (parm), 1))
- {
-err_parm_list = build_tree_list (defval, parm);
-TREE_VALUE (err_
Re: [testsuite] XFAIL gcc.c-torture/compile/pr28865.c on Solaris 9/SPARC (PR target/60602)
> diff --git a/libitm/config/generic/asmcfi.h b/libitm/config/generic/asmcfi.h > --- a/libitm/config/generic/asmcfi.h > +++ b/libitm/config/generic/asmcfi.h > @@ -24,7 +24,7 @@ > > #include "config.h" > > -#ifdef HAVE_AS_CFI_PSEUDO_OP > +#if defined(HAVE_AS_CFI_PSEUDO_OP) && defined(__GCC_HAVE_DWARF2_CFI_ASM) > > #define cfi_startproc.cfi_startproc > #define cfi_endproc .cfi_endproc > @@ -50,4 +50,4 @@ > #define cfi_restore(r) > #define cfi_undefined(r) > > -#endif /* HAVE_AS_CFI_PSEUDO_OP */ > +#endif /* HAVE_AS_CFI_PSEUDO_OP && __GCC_HAVE_DWARF2_CFI_ASM */ I didn't actually commit this part, but noticed that it had crept into the patch pre-commit. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[testsuite] XFAIL gcc.c-torture/compile/pr28865.c on Solaris 9/SPARC (PR target/60602)
As described in the PR, gcc.c-torture/compile/pr28865.c FAILs on Solaris
9/SPARC with /bin/as at -O0. Given that Solaris 9 support will be
removed post-4.9, we agreed to just XFAIL the test, which this patch
does.
Tested with the approprite runtest invocations on sparc-sun-solaris2.9
(both as and gas), and x86_64-unknown-linux-gnu, installed on mainline.
Rainer
2014-04-08 Rainer Orth
PR target/60602
* gcc.c-torture/compile/pr28865.c: XFAIL on sparc*-*-solaris2.9*
with as at -O0.
# HG changeset patch
# Parent e17640a7d95c3adb1df90271afefc67d1ee83976
XFAIL gcc.c-torture/compile/pr28865.c on Solaris 9/SPARC (PR target/60602)
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr28865.c b/gcc/testsuite/gcc.c-torture/compile/pr28865.c
--- a/gcc/testsuite/gcc.c-torture/compile/pr28865.c
+++ b/gcc/testsuite/gcc.c-torture/compile/pr28865.c
@@ -1,3 +1,5 @@
+/* { dg-xfail-if "PR target/60602" { sparc*-*-solaris2.9* && { ! gas } } { "-O0" } } */
+
struct var_len
{
int field1;
diff --git a/libitm/config/generic/asmcfi.h b/libitm/config/generic/asmcfi.h
--- a/libitm/config/generic/asmcfi.h
+++ b/libitm/config/generic/asmcfi.h
@@ -24,7 +24,7 @@
#include "config.h"
-#ifdef HAVE_AS_CFI_PSEUDO_OP
+#if defined(HAVE_AS_CFI_PSEUDO_OP) && defined(__GCC_HAVE_DWARF2_CFI_ASM)
#define cfi_startproc .cfi_startproc
#define cfi_endproc .cfi_endproc
@@ -50,4 +50,4 @@
#define cfi_restore(r)
#define cfi_undefined(r)
-#endif /* HAVE_AS_CFI_PSEUDO_OP */
+#endif /* HAVE_AS_CFI_PSEUDO_OP && __GCC_HAVE_DWARF2_CFI_ASM */
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Adjust builtin-bswap-6/7
On Tue, Apr 08, 2014 at 12:41:41PM +0200, Andreas Krebbel wrote: > what about that one? > > Tested on x86_64, s390, and s390x. LGTM, thanks. > 2014-04-08 Andreas Krebbel > > * gcc.dg/builtin-bswap-6.c: Use -mbranch-cost=0 for s390. > * gcc.dg/builtin-bswap-7.c: Likewise. > > Revert > 2014-04-04 Andreas Krebbel > > * gcc.dg/builtin-bswap-6.c: Adjust return value to disable GCC > optimization. > * gcc.dg/builtin-bswap-7.c: Likewise. Jakub
Re: [PATCH] Adjust builtin-bswap-6/7
Hi,
what about that one?
Tested on x86_64, s390, and s390x.
Bye,
-Andreas-
2014-04-08 Andreas Krebbel
* gcc.dg/builtin-bswap-6.c: Use -mbranch-cost=0 for s390.
* gcc.dg/builtin-bswap-7.c: Likewise.
Revert
2014-04-04 Andreas Krebbel
* gcc.dg/builtin-bswap-6.c: Adjust return value to disable GCC
optimization.
* gcc.dg/builtin-bswap-7.c: Likewise.
diff --git a/gcc/testsuite/gcc.dg/builtin-bswap-6.c
b/gcc/testsuite/gcc.dg/builtin-bswap-6.c
index 6f0c782..efda870 100644
--- a/gcc/testsuite/gcc.dg/builtin-bswap-6.c
+++ b/gcc/testsuite/gcc.dg/builtin-bswap-6.c
@@ -1,11 +1,10 @@
/* { dg-do compile { target arm*-*-* alpha*-*-* i?86-*-* powerpc*-*-*
rs6000-*-* x86_64-*-* s390*-*-* } } */
/* { dg-require-effective-target stdint_types } */
/* { dg-options "-O -fdump-rtl-combine" } */
-/* { dg-options "-O -fdump-rtl-combine -march=z900" { target s390-*-* } } */
-/* The test intentionally returns 1/2 instead of the obvious 0/1 to
- prevent GCC from calculating the return value with arithmetic
- instead of a comparison. */
+/* The branch cost setting prevents the return value from being
+ calculated with arithmetic instead of doing a compare. */
+/* { dg-additional-options "-march=z900 -mbranch-cost=0" { target s390*-*-* }
} */
#include
@@ -15,28 +14,28 @@ int foo1 (uint32_t a)
{
if (BS (a) == 0xA)
return 1;
- return 2;
+ return 0;
}
int foo2 (uint32_t a)
{
if (BS (a) != 0xA)
return 1;
- return 2;
+ return 0;
}
int foo3 (uint32_t a, uint32_t b)
{
if (BS (a) == BS (b))
return 1;
- return 2;
+ return 0;
}
int foo4 (uint32_t a, uint32_t b)
{
if (BS (a) != BS (b))
return 1;
- return 2;
+ return 0;
}
/* { dg-final { scan-rtl-dump-not "bswapsi" "combine" } } */
diff --git a/gcc/testsuite/gcc.dg/builtin-bswap-7.c
b/gcc/testsuite/gcc.dg/builtin-bswap-7.c
index 0eecdd8..035c736 100644
--- a/gcc/testsuite/gcc.dg/builtin-bswap-7.c
+++ b/gcc/testsuite/gcc.dg/builtin-bswap-7.c
@@ -3,9 +3,9 @@
/* { dg-require-effective-target lp64 } */
/* { dg-options "-O -fdump-rtl-combine" } */
-/* The test intentionally returns 1/2 instead of the obvious 0/1 to
- prevent GCC from calculating the return value with arithmetic
- instead of a comparison. */
+/* The branch cost setting prevents the return value from being
+ calculated with arithmetic instead of doing a compare. */
+/* { dg-additional-options "-mbranch-cost=0" { target s390x-*-* } } */
#include
@@ -15,28 +15,28 @@ int foo1 (uint64_t a)
{
if (BS (a) == 0xA)
return 1;
- return 2;
+ return 0;
}
int foo2 (uint64_t a)
{
if (BS (a) != 0xA)
return 1;
- return 2;
+ return 0;
}
int foo3 (uint64_t a, uint64_t b)
{
if (BS (a) == BS (b))
return 1;
- return 2;
+ return 0;
}
int foo4 (uint64_t a, uint64_t b)
{
if (BS (a) != BS (b))
return 1;
- return 2;
+ return 0;
}
/* { dg-final { scan-rtl-dump-not "bswapdi" "combine" } } */
Re: [PATCH] Adjust builtin-bswap-6/7
On Tue, Apr 08, 2014 at 11:21:56AM +0200, Andreas Krebbel wrote:
> On 04/08/2014 11:12 AM, Jakub Jelinek wrote:
> > On Tue, Apr 08, 2014 at 10:53:19AM +0200, Andreas Krebbel wrote:
> >> On 04/08/2014 10:41 AM, Jakub Jelinek wrote:
> >>> On Tue, Apr 08, 2014 at 10:26:30AM +0200, Richard Biener wrote:
> On Mon, Apr 7, 2014 at 6:22 PM, Andreas Krebbel
> wrote:
> > On Mon, Apr 07, 2014 at 04:19:06PM +0200, Richard Biener wrote:
> >> The adjusted testcases now fail on x86_64/i?86 at least. See PR60776.
> >
> > They seem to require at least -O2 on x86 with that change. Ok to apply?
>
> Hmm, they passed before your change. Do you mean that this was
> by accident (and only because of the special return value)? If so then
> the patch is ok.
> >>>
> >>> The reason why it worked with the if ... return 1; else return 0; case is
> >>> that in that case it has already been expanded as store flag insn and thus
> >>> in that case ce1 pass didn't discover the conditional move there, thus no
> >>> dead code waiting to be eliminated after ce1 and still present during
> >>> combine pass.
> >>>
> >>> Another alternative for -O2 would be -O -fno-if-conversion I guess.
> >>
> >> I could also revert the testcase changes and add -mbranch-cost=2 for s390?!
> >
> > That doesn't seem to work (at least for me with cross-compiler to s390x).
>
> Seems to be -mbranch-cost=0 this time.
Indeed, that works too.
Thus, please commit any of these variants, if you go for
/* { dg-additional-options "-mbranch-cost=0" { target s390*-*-* } } */
plus reverting your earlier changes, you can also consider
addition of two new tests that would contain the return {1,2} and have -O2.
Jakub
Re: RFA: Testsuite PATCH to add support for dlopen tests
Hi, On 04/08/2014 11:58 AM, Andreas Schwab wrote: I guess this depends on dejagnu >= 1.5, which added support for nested calls to dg-test. I see, thanks Andreas. In fact I'm using 1.4.4 here. Then, either update prerequisites.html or tweak the code to not rely on 1.5.x features. Paolo.
Re: [C++] Weffc++/Wnon-virtual-dtor confusion
On 04/07/14 14:22, Jason Merrill wrote: On 04/07/2014 03:39 AM, Nathan Sidwell wrote: Jason, I shall leave it to your discretion as to whether we should continue with this patch, or revert the original one (for 4.9). This is OK. Post 4.9 we might try removing the warn_ecpp check and see how that is received. Thanks all, committed.
[PATCH] Fix PR60706
Dave confirmed that a patch like the following fixes the
inconsistency in printing double-ints that fit 64bits on
HWI32 hosts vs. HWI64 hosts. When the host has a 64bit
type, that is.
Bootstrap running on x86_64-unknown-linux-gnu.
Dave, did testing on hppa2.0w-hp-hpux11.11 show any testsuite
fallout?
Thanks,
Richard.
2014-04-08 Richard Biener
PR middle-end/60706
* tree-pretty-print.c (pp_double_int): For HWI32 hosts with
a 64bit widest int print double-int similar to on HWI64 hosts.
Index: gcc/tree-pretty-print.c
===
--- gcc/tree-pretty-print.c (revision 209210)
+++ gcc/tree-pretty-print.c (working copy)
@@ -3465,6 +3467,12 @@ pp_double_int (pretty_printer *pp, doubl
pp_wide_integer (pp, d.low);
else if (d.fits_uhwi ())
pp_unsigned_wide_integer (pp, d.low);
+ else if (HOST_BITS_PER_DOUBLE_INT == HOST_BITS_PER_WIDEST_INT)
+pp_scalar (pp,
+ uns
+ ? HOST_WIDEST_INT_PRINT_UNSIGNED : HOST_WIDEST_INT_PRINT_DEC,
+ (HOST_WIDEST_INT) unsigned HOST_WIDEST_INT) d.high << 1)
+ << (HOST_BITS_PER_WIDE_INT - 1)) | d.low));
else
{
unsigned HOST_WIDE_INT low = d.low;
Re: RFA: Testsuite PATCH to add support for dlopen tests
Paolo Carlini writes:
> On 04/08/2014 11:01 AM, Andreas Schwab wrote:
>> Jason Merrill writes:
>>
>>> richi asked for a testcase for 60731, and since we didn't already have
>>> support for tests using dlopen, I had to add it. Does this approach make
>>> sense?
>> ERROR: tcl error sourcing
>> /usr/local/gcc/gcc-20140408/gcc/testsuite/g++.dg/dg.exp.
>> ERROR: can't rename "dg-save-unknown": command doesn't exist
>> while executing
>> "rename dg-save-unknown unknown"
>> (procedure "saved-dg-test" line 96)
>> invoked from within
>> "saved-dg-test
>> /usr/local/gcc/gcc-20140408/gcc/testsuite/g++.dg/dso/dlclose1.C -std=c++98 {
>> -pedantic-errors -Wno-long-long}"
>> ("eval" body line 1)
>> invoked from within
>> "eval saved-dg-test $args"
>> (procedure "dg-test" line 11)
>> invoked from within
>> "dg-test $test $flags ${default-extra-flags}"
>> (procedure "g++-dg-runtest" line 27)
>> invoked from within
>> "g++-dg-runtest $tests $DEFAULT_CXXFLAGS"
>> (file "/usr/local/gcc/gcc-20140408/gcc/testsuite/g++.dg/dg.exp" line 60)
>> invoked from within
>> "source /usr/local/gcc/gcc-20140408/gcc/testsuite/g++.dg/dg.exp"
>> ("uplevel" body line 1)
>> invoked from within
>> "uplevel #0 source /usr/local/gcc/gcc-20140408/gcc/testsuite/g++.dg/dg.exp"
>> invoked from within
>> "catch "uplevel #0 source $test_file_name""
> I can confirm this.
I guess this depends on dejagnu >= 1.5, which added support for nested
calls to dg-test.
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Re: RFA: Testsuite PATCH to add support for dlopen tests
Hi,
On 04/08/2014 11:01 AM, Andreas Schwab wrote:
Jason Merrill writes:
richi asked for a testcase for 60731, and since we didn't already have
support for tests using dlopen, I had to add it. Does this approach make
sense?
ERROR: tcl error sourcing
/usr/local/gcc/gcc-20140408/gcc/testsuite/g++.dg/dg.exp.
ERROR: can't rename "dg-save-unknown": command doesn't exist
while executing
"rename dg-save-unknown unknown"
(procedure "saved-dg-test" line 96)
invoked from within
"saved-dg-test /usr/local/gcc/gcc-20140408/gcc/testsuite/g++.dg/dso/dlclose1.C
-std=c++98 { -pedantic-errors -Wno-long-long}"
("eval" body line 1)
invoked from within
"eval saved-dg-test $args"
(procedure "dg-test" line 11)
invoked from within
"dg-test $test $flags ${default-extra-flags}"
(procedure "g++-dg-runtest" line 27)
invoked from within
"g++-dg-runtest $tests $DEFAULT_CXXFLAGS"
(file "/usr/local/gcc/gcc-20140408/gcc/testsuite/g++.dg/dg.exp" line 60)
invoked from within
"source /usr/local/gcc/gcc-20140408/gcc/testsuite/g++.dg/dg.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source /usr/local/gcc/gcc-20140408/gcc/testsuite/g++.dg/dg.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
I can confirm this.
Thanks,
Paolo.
Re: [PATCH] Adjust builtin-bswap-6/7
On 04/08/2014 11:12 AM, Jakub Jelinek wrote:
> On Tue, Apr 08, 2014 at 10:53:19AM +0200, Andreas Krebbel wrote:
>> On 04/08/2014 10:41 AM, Jakub Jelinek wrote:
>>> On Tue, Apr 08, 2014 at 10:26:30AM +0200, Richard Biener wrote:
On Mon, Apr 7, 2014 at 6:22 PM, Andreas Krebbel
wrote:
> On Mon, Apr 07, 2014 at 04:19:06PM +0200, Richard Biener wrote:
>> The adjusted testcases now fail on x86_64/i?86 at least. See PR60776.
>
> They seem to require at least -O2 on x86 with that change. Ok to apply?
Hmm, they passed before your change. Do you mean that this was
by accident (and only because of the special return value)? If so then
the patch is ok.
>>>
>>> The reason why it worked with the if ... return 1; else return 0; case is
>>> that in that case it has already been expanded as store flag insn and thus
>>> in that case ce1 pass didn't discover the conditional move there, thus no
>>> dead code waiting to be eliminated after ce1 and still present during
>>> combine pass.
>>>
>>> Another alternative for -O2 would be -O -fno-if-conversion I guess.
>>
>> I could also revert the testcase changes and add -mbranch-cost=2 for s390?!
>
> That doesn't seem to work (at least for me with cross-compiler to s390x).
Seems to be -mbranch-cost=0 this time.
>
>>>
>>> OT, when touching the testcase, I'd say it would be better if you've
>>> converted it to single dg-options + /* { dg-additional-options
>>> "-march=z900" { target s390*-*-* } } */
>>
>> Ok.
>
> Thanks.
>
> Jakub
>
Re: [libitm] Check if GCC uses assembler cfi support
Richard Henderson writes: > On 04/07/2014 04:33 AM, Rainer Orth wrote: >> The patch allowed i386-pc-solaris2.11 bootstraps to finish without >> regressions on trunk and 4.8 branch, still need to test 4.7 branch. >> >> Ok for trunk, 4.8 and 4.7 branches once testing completes? >> >> Rainer >> >> >> 2014-04-07 Rainer Orth >> >> * config/generic/asmcfi.h: Also check for >> __GCC_HAVE_DWARF2_CFI_ASM. > > Looks fine. Testing was fine on i386-pc-solaris2.11 with /bin/as on trunk, 4.8 and 4.7 branches, as well as x86_64-unknown-linux-gnu. However, i386-pc-solaris2.11 with gas was confusing at first: for the 32-bit PIC case, no .eh_frame was generated. It turned out this happens because in this case config/i386/sol2.h (ASM_PREFERRED_EH_DATA_FORMAT) is a lie: it claims datarel encoding for the 32-bit PIC case. This way, dwarf2out_do_cfi_asm returns false and c-family/c-cppbuiltin.c (c_cpp_builtins) doesn't define __GCC_HAVE_DWARF2_CFI_ASM. In fact, gas with cfi directives uses pcrel encoding, thus __GCC_HAVE_DWARF2_CFI_ASM should be defined. ISTM that the ASM_PREFERRED_EH_DATA_FORMAT redefinition above should be wrapped in HAVE_AS_IX86_DIFF_SECT_DELTA, but I'm quite reluctant to make such a change so late in the 4.9 release cycle. I'll certainly try it post-4.9, especially given that Solaris 9 support will be removed by then and current Solaris 10 and 11 assemblers *can* subtract symbols in different sections. Unless I'm missing something, I'm thus going to check in the patch as is within a day. I believe that losing unwind info in a single case here is worth avoiding the bootstrap failure. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: [PATCH] Adjust builtin-bswap-6/7
On Tue, Apr 08, 2014 at 10:53:19AM +0200, Andreas Krebbel wrote:
> On 04/08/2014 10:41 AM, Jakub Jelinek wrote:
> > On Tue, Apr 08, 2014 at 10:26:30AM +0200, Richard Biener wrote:
> >> On Mon, Apr 7, 2014 at 6:22 PM, Andreas Krebbel
> >> wrote:
> >>> On Mon, Apr 07, 2014 at 04:19:06PM +0200, Richard Biener wrote:
> The adjusted testcases now fail on x86_64/i?86 at least. See PR60776.
> >>>
> >>> They seem to require at least -O2 on x86 with that change. Ok to apply?
> >>
> >> Hmm, they passed before your change. Do you mean that this was
> >> by accident (and only because of the special return value)? If so then
> >> the patch is ok.
> >
> > The reason why it worked with the if ... return 1; else return 0; case is
> > that in that case it has already been expanded as store flag insn and thus
> > in that case ce1 pass didn't discover the conditional move there, thus no
> > dead code waiting to be eliminated after ce1 and still present during
> > combine pass.
> >
> > Another alternative for -O2 would be -O -fno-if-conversion I guess.
>
> I could also revert the testcase changes and add -mbranch-cost=2 for s390?!
That doesn't seem to work (at least for me with cross-compiler to s390x).
> >
> > OT, when touching the testcase, I'd say it would be better if you've
> > converted it to single dg-options + /* { dg-additional-options
> > "-march=z900" { target s390*-*-* } } */
>
> Ok.
Thanks.
Jakub
[PATCH] Fix PR60785
This fixes PR60785 where we tried to insert a stmt right after
the definition of a default def (oops). That can't work and
is even wrong, so the patch avoids this.
There is still possibly wrong-code going on here for a loop
like
b = foo ();
x = 0;
do {
...
x = b;
} while (...);
which also will insert the out-of-SSA copy of the
x = PHI <0(entry), b(latch)>
PHI after the definition of b. This only works when
the definition is inside the loop.
I didn't fix that with this patch (no testcase).
Bootstrap / regtest running on x86_64-unknown-linux-gnu.
Richard.
2014-04-08 Richard Biener
PR tree-optimization/60785
* graphite-sese-to-poly.c (rewrite_phi_out_of_ssa): Treat
default defs properly.
* gcc.dg/graphite/pr60785.c: New testcase.
Index: gcc/graphite-sese-to-poly.c
===
*** gcc/graphite-sese-to-poly.c (revision 209210)
--- gcc/graphite-sese-to-poly.c (working copy)
*** rewrite_phi_out_of_ssa (scop_p scop, gim
*** 2250,2255
--- 2250,2256
/* Avoid the insertion of code in the loop latch to please the
pattern matching of the vectorizer. */
if (TREE_CODE (arg) == SSA_NAME
+ && !SSA_NAME_IS_DEFAULT_DEF (arg)
&& e->src == bb->loop_father->latch)
insert_out_of_ssa_copy (scop, zero_dim_array, arg,
SSA_NAME_DEF_STMT (arg));
Index: gcc/testsuite/gcc.dg/graphite/pr60785.c
===
*** gcc/testsuite/gcc.dg/graphite/pr60785.c (revision 0)
--- gcc/testsuite/gcc.dg/graphite/pr60785.c (working copy)
***
*** 0
--- 1,27
+ /* { dg-options "-O2 -floop-interchange" } */
+
+ static int
+ aqc(void)
+ {
+ return 1;
+ }
+
+ void
+ gkd(void)
+ {
+ int wu0;
+ static int b1y;
+ static int gw2;
+ static int *ydw = &gw2;
+ static int **m3l = &ydw;
+ **m3l = 0;
+ for (b1y = 0; b1y < 1; ++b1y)
+ {
+ int *cpj = &gw2;
+ if (*ydw |= aqc())
+ {
+ *cpj = 0;
+ *ydw = wu0;
+ }
+ }
+ }
Re: RFA: Testsuite PATCH to add support for dlopen tests
Jason Merrill writes:
> richi asked for a testcase for 60731, and since we didn't already have
> support for tests using dlopen, I had to add it. Does this approach make
> sense?
ERROR: tcl error sourcing
/usr/local/gcc/gcc-20140408/gcc/testsuite/g++.dg/dg.exp.
ERROR: can't rename "dg-save-unknown": command doesn't exist
while executing
"rename dg-save-unknown unknown"
(procedure "saved-dg-test" line 96)
invoked from within
"saved-dg-test /usr/local/gcc/gcc-20140408/gcc/testsuite/g++.dg/dso/dlclose1.C
-std=c++98 { -pedantic-errors -Wno-long-long}"
("eval" body line 1)
invoked from within
"eval saved-dg-test $args "
(procedure "dg-test" line 11)
invoked from within
"dg-test $test $flags ${default-extra-flags}"
(procedure "g++-dg-runtest" line 27)
invoked from within
"g++-dg-runtest $tests $DEFAULT_CXXFLAGS"
(file "/usr/local/gcc/gcc-20140408/gcc/testsuite/g++.dg/dg.exp" line 60)
invoked from within
"source /usr/local/gcc/gcc-20140408/gcc/testsuite/g++.dg/dg.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source /usr/local/gcc/gcc-20140408/gcc/testsuite/g++.dg/dg.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Re: [PATCH] Adjust builtin-bswap-6/7
On 04/08/2014 10:41 AM, Jakub Jelinek wrote:
> On Tue, Apr 08, 2014 at 10:26:30AM +0200, Richard Biener wrote:
>> On Mon, Apr 7, 2014 at 6:22 PM, Andreas Krebbel
>> wrote:
>>> On Mon, Apr 07, 2014 at 04:19:06PM +0200, Richard Biener wrote:
The adjusted testcases now fail on x86_64/i?86 at least. See PR60776.
>>>
>>> They seem to require at least -O2 on x86 with that change. Ok to apply?
>>
>> Hmm, they passed before your change. Do you mean that this was
>> by accident (and only because of the special return value)? If so then
>> the patch is ok.
>
> The reason why it worked with the if ... return 1; else return 0; case is
> that in that case it has already been expanded as store flag insn and thus
> in that case ce1 pass didn't discover the conditional move there, thus no
> dead code waiting to be eliminated after ce1 and still present during
> combine pass.
>
> Another alternative for -O2 would be -O -fno-if-conversion I guess.
I could also revert the testcase changes and add -mbranch-cost=2 for s390?!
>
> OT, when touching the testcase, I'd say it would be better if you've
> converted it to single dg-options + /* { dg-additional-options "-march=z900"
> { target s390*-*-* } } */
Ok.
Bye,
-Andreas-
>
>>> --- a/gcc/testsuite/gcc.dg/builtin-bswap-6.c
>>> +++ b/gcc/testsuite/gcc.dg/builtin-bswap-6.c
>>> @@ -1,7 +1,7 @@
>>> /* { dg-do compile { target arm*-*-* alpha*-*-* i?86-*-* powerpc*-*-*
>>> rs6000-*-* x86_64-*-* s390*-*-* } } */
>>> /* { dg-require-effective-target stdint_types } */
>>> -/* { dg-options "-O -fdump-rtl-combine" } */
>>> -/* { dg-options "-O -fdump-rtl-combine -march=z900" { target s390-*-* } }
>>> */
>>> +/* { dg-options "-O2 -fdump-rtl-combine" } */
>>> +/* { dg-options "-O2 -fdump-rtl-combine -march=z900" { target s390-*-* } }
>>> */
>>>
>>> /* The test intentionally returns 1/2 instead of the obvious 0/1 to
>>> prevent GCC from calculating the return value with arithmetic
>>> diff --git a/gcc/testsuite/gcc.dg/builtin-bswap-7.c
>>> b/gcc/testsuite/gcc.dg/builtin-bswap-7.c
>>> index 0eecdd8..98529f2 100644
>>> --- a/gcc/testsuite/gcc.dg/builtin-bswap-7.c
>>> +++ b/gcc/testsuite/gcc.dg/builtin-bswap-7.c
>>> @@ -1,7 +1,7 @@
>>> /* { dg-do compile { target arm*-*-* alpha*-*-* ia64*-*-* x86_64-*-*
>>> s390x-*-* powerpc*-*-* rs6000-*-* } } */
>>> /* { dg-require-effective-target stdint_types } */
>>> /* { dg-require-effective-target lp64 } */
>>> -/* { dg-options "-O -fdump-rtl-combine" } */
>>> +/* { dg-options "-O2 -fdump-rtl-combine" } */
>>>
>>> /* The test intentionally returns 1/2 instead of the obvious 0/1 to
>>> prevent GCC from calculating the return value with arithmetic
>>>
>
> Jakub
>
Re: [PATCH] Adjust builtin-bswap-6/7
On Tue, Apr 08, 2014 at 10:26:30AM +0200, Richard Biener wrote:
> On Mon, Apr 7, 2014 at 6:22 PM, Andreas Krebbel
> wrote:
> > On Mon, Apr 07, 2014 at 04:19:06PM +0200, Richard Biener wrote:
> >> The adjusted testcases now fail on x86_64/i?86 at least. See PR60776.
> >
> > They seem to require at least -O2 on x86 with that change. Ok to apply?
>
> Hmm, they passed before your change. Do you mean that this was
> by accident (and only because of the special return value)? If so then
> the patch is ok.
The reason why it worked with the if ... return 1; else return 0; case is
that in that case it has already been expanded as store flag insn and thus
in that case ce1 pass didn't discover the conditional move there, thus no
dead code waiting to be eliminated after ce1 and still present during
combine pass.
Another alternative for -O2 would be -O -fno-if-conversion I guess.
OT, when touching the testcase, I'd say it would be better if you've
converted it to single dg-options + /* { dg-additional-options "-march=z900" {
target s390*-*-* } } */
> > --- a/gcc/testsuite/gcc.dg/builtin-bswap-6.c
> > +++ b/gcc/testsuite/gcc.dg/builtin-bswap-6.c
> > @@ -1,7 +1,7 @@
> > /* { dg-do compile { target arm*-*-* alpha*-*-* i?86-*-* powerpc*-*-*
> > rs6000-*-* x86_64-*-* s390*-*-* } } */
> > /* { dg-require-effective-target stdint_types } */
> > -/* { dg-options "-O -fdump-rtl-combine" } */
> > -/* { dg-options "-O -fdump-rtl-combine -march=z900" { target s390-*-* } }
> > */
> > +/* { dg-options "-O2 -fdump-rtl-combine" } */
> > +/* { dg-options "-O2 -fdump-rtl-combine -march=z900" { target s390-*-* } }
> > */
> >
> > /* The test intentionally returns 1/2 instead of the obvious 0/1 to
> > prevent GCC from calculating the return value with arithmetic
> > diff --git a/gcc/testsuite/gcc.dg/builtin-bswap-7.c
> > b/gcc/testsuite/gcc.dg/builtin-bswap-7.c
> > index 0eecdd8..98529f2 100644
> > --- a/gcc/testsuite/gcc.dg/builtin-bswap-7.c
> > +++ b/gcc/testsuite/gcc.dg/builtin-bswap-7.c
> > @@ -1,7 +1,7 @@
> > /* { dg-do compile { target arm*-*-* alpha*-*-* ia64*-*-* x86_64-*-*
> > s390x-*-* powerpc*-*-* rs6000-*-* } } */
> > /* { dg-require-effective-target stdint_types } */
> > /* { dg-require-effective-target lp64 } */
> > -/* { dg-options "-O -fdump-rtl-combine" } */
> > +/* { dg-options "-O2 -fdump-rtl-combine" } */
> >
> > /* The test intentionally returns 1/2 instead of the obvious 0/1 to
> > prevent GCC from calculating the return value with arithmetic
> >
Jakub
Re: [PATCH] Adjust builtin-bswap-6/7
On Tue, Apr 8, 2014 at 10:31 AM, Jakub Jelinek wrote:
> On Mon, Apr 07, 2014 at 06:22:14PM +0200, Andreas Krebbel wrote:
>> On Mon, Apr 07, 2014 at 04:19:06PM +0200, Richard Biener wrote:
>> > The adjusted testcases now fail on x86_64/i?86 at least. See PR60776.
>>
>> They seem to require at least -O2 on x86 with that change. Ok to apply?
>
> The reason why the modified test now requires -O2 seems to be that during
> ce1 a conditional move is detected, but there is no DCE to clean stuff
> up before combine at -O1 and thus the bswapsi result pseudo has multiple
> uses.
>
> I guess your patch is ok for now, for 5.0 I'd say we should do it at the
> GIMPLE level, probably not in the optimize_bswap pass (because there it is
> guarded with bswap* insn patterns, while we can certainly optimize this
> for libcalls too), but say fold_builtins pass, when seeing
> __builtin_bswap* builtin that couldn't be folded, just check if the lhs has
> a single use that is a comparison with constant and if so, remove the
> swapping and adjust comparison.
Or just
(match_and_simplify
(eq (bswap @1) (bswap @2))
(eq @1 @2))
and similar patterns which should then catch it everywhere.
Richard.
>> diff --git a/gcc/testsuite/gcc.dg/builtin-bswap-6.c
>> b/gcc/testsuite/gcc.dg/builtin-bswap-6.c
>> index 6f0c782..f346c2f 100644
>> --- a/gcc/testsuite/gcc.dg/builtin-bswap-6.c
>> +++ b/gcc/testsuite/gcc.dg/builtin-bswap-6.c
>> @@ -1,7 +1,7 @@
>> /* { dg-do compile { target arm*-*-* alpha*-*-* i?86-*-* powerpc*-*-*
>> rs6000-*-* x86_64-*-* s390*-*-* } } */
>> /* { dg-require-effective-target stdint_types } */
>> -/* { dg-options "-O -fdump-rtl-combine" } */
>> -/* { dg-options "-O -fdump-rtl-combine -march=z900" { target s390-*-* } } */
>> +/* { dg-options "-O2 -fdump-rtl-combine" } */
>> +/* { dg-options "-O2 -fdump-rtl-combine -march=z900" { target s390-*-* } }
>> */
>>
>> /* The test intentionally returns 1/2 instead of the obvious 0/1 to
>> prevent GCC from calculating the return value with arithmetic
>> diff --git a/gcc/testsuite/gcc.dg/builtin-bswap-7.c
>> b/gcc/testsuite/gcc.dg/builtin-bswap-7.c
>> index 0eecdd8..98529f2 100644
>> --- a/gcc/testsuite/gcc.dg/builtin-bswap-7.c
>> +++ b/gcc/testsuite/gcc.dg/builtin-bswap-7.c
>> @@ -1,7 +1,7 @@
>> /* { dg-do compile { target arm*-*-* alpha*-*-* ia64*-*-* x86_64-*-*
>> s390x-*-* powerpc*-*-* rs6000-*-* } } */
>> /* { dg-require-effective-target stdint_types } */
>> /* { dg-require-effective-target lp64 } */
>> -/* { dg-options "-O -fdump-rtl-combine" } */
>> +/* { dg-options "-O2 -fdump-rtl-combine" } */
>>
>> /* The test intentionally returns 1/2 instead of the obvious 0/1 to
>> prevent GCC from calculating the return value with arithmetic
>
> Jakub
Re: [PATCH] Fix PR59626, _FORTIFY_SOURCE wrappers and LTO
On Tue, Apr 8, 2014 at 8:12 AM, Ryan Hill wrote: > On Fri, 4 Apr 2014 08:18:26 +0200 > Jan Hubicka wrote: > >> Hi, >> here is an updated version of my earlier ipa.c change. It turns out that the >> problem was that I did not drop always_inline. >> In this version I just drop always_inline attribute on all functions whose >> body is removed. The patch will affect non-LTO compilation, too, but IMO >> only by making us to not inline&diagnose the cases where indirect call to >> always inline is turned direct in between early opts and inline. Does that >> seem acceptable? (I personally would preffer this over inventing yet another >> way to special case always_inline for LTO only; we never made any strong >> promises on always_inline and indirect calls) >> >> Honza >> >> * lto-cgraph.c (input_overwrite_node): Check that partitioning >> flags are set only during streaming. >> * ipa.c (process_references, walk_polymorphic_call_targets, >> symtab_remove_unreachable_nodes): Drop bodies of always inline >> after early inlining. >> (symtab_remove_unreachable_nodes): Remove always_inline attribute. >> >> * gcc.dg/lto/pr59626_0.c: New testcase. >> * gcc.dg/lto/pr59626_1.c: New testcase. > > Would it be possible to backport this to 4.8? It fixes a number of issues > we're seeing, including a couple unrelated to LTO (eg. PR50506). Let it have some burn-in on 4.9 please. It may cause unexpected behavior for people relying on always-inlining through indirect function calls. Richard. > > -- > Ryan Hillpsn: dirtyepic_sk >gcc-porting/toolchain/wxwidgets @ gentoo.org > > 47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463
Re: [PATCH] Adjust builtin-bswap-6/7
On Mon, Apr 07, 2014 at 06:22:14PM +0200, Andreas Krebbel wrote:
> On Mon, Apr 07, 2014 at 04:19:06PM +0200, Richard Biener wrote:
> > The adjusted testcases now fail on x86_64/i?86 at least. See PR60776.
>
> They seem to require at least -O2 on x86 with that change. Ok to apply?
The reason why the modified test now requires -O2 seems to be that during
ce1 a conditional move is detected, but there is no DCE to clean stuff
up before combine at -O1 and thus the bswapsi result pseudo has multiple
uses.
I guess your patch is ok for now, for 5.0 I'd say we should do it at the
GIMPLE level, probably not in the optimize_bswap pass (because there it is
guarded with bswap* insn patterns, while we can certainly optimize this
for libcalls too), but say fold_builtins pass, when seeing
__builtin_bswap* builtin that couldn't be folded, just check if the lhs has
a single use that is a comparison with constant and if so, remove the
swapping and adjust comparison.
> diff --git a/gcc/testsuite/gcc.dg/builtin-bswap-6.c
> b/gcc/testsuite/gcc.dg/builtin-bswap-6.c
> index 6f0c782..f346c2f 100644
> --- a/gcc/testsuite/gcc.dg/builtin-bswap-6.c
> +++ b/gcc/testsuite/gcc.dg/builtin-bswap-6.c
> @@ -1,7 +1,7 @@
> /* { dg-do compile { target arm*-*-* alpha*-*-* i?86-*-* powerpc*-*-*
> rs6000-*-* x86_64-*-* s390*-*-* } } */
> /* { dg-require-effective-target stdint_types } */
> -/* { dg-options "-O -fdump-rtl-combine" } */
> -/* { dg-options "-O -fdump-rtl-combine -march=z900" { target s390-*-* } } */
> +/* { dg-options "-O2 -fdump-rtl-combine" } */
> +/* { dg-options "-O2 -fdump-rtl-combine -march=z900" { target s390-*-* } } */
>
> /* The test intentionally returns 1/2 instead of the obvious 0/1 to
> prevent GCC from calculating the return value with arithmetic
> diff --git a/gcc/testsuite/gcc.dg/builtin-bswap-7.c
> b/gcc/testsuite/gcc.dg/builtin-bswap-7.c
> index 0eecdd8..98529f2 100644
> --- a/gcc/testsuite/gcc.dg/builtin-bswap-7.c
> +++ b/gcc/testsuite/gcc.dg/builtin-bswap-7.c
> @@ -1,7 +1,7 @@
> /* { dg-do compile { target arm*-*-* alpha*-*-* ia64*-*-* x86_64-*-*
> s390x-*-* powerpc*-*-* rs6000-*-* } } */
> /* { dg-require-effective-target stdint_types } */
> /* { dg-require-effective-target lp64 } */
> -/* { dg-options "-O -fdump-rtl-combine" } */
> +/* { dg-options "-O2 -fdump-rtl-combine" } */
>
> /* The test intentionally returns 1/2 instead of the obvious 0/1 to
> prevent GCC from calculating the return value with arithmetic
Jakub
Re: Warn when returning the address of a temporary (middle-end)
On Mon, Apr 7, 2014 at 8:51 PM, Marc Glisse wrote: > On Mon, 7 Apr 2014, Jeff Law wrote: > >> On 04/05/14 07:52, Marc Glisse wrote: >>> >>> Hello, >>> >>> we have front-end warnings about returning the address of a local >>> variable. However, quite often in C++, people don't directly return the >>> address of a temporary, it goes through a few functions which hide that >>> fact. After some inlining, the fact that we are returning the address of >>> a local variable can become obvious to the compiler, to the point where >>> I have used, for debugging purposes, grep 'return &' on the optimized >>> dump produced with -O3 -fkeep-inline-functions (I then had to sort >>> through the global/local variables). >>> >>> fold_stmt looks like a good place for this, but it could go almost >>> anywhere. It has to happen after enough inlining / copy propagation to >>> make it useful though. >> >> I was wondering if this would be better implemented as a propagation >> problem so that cases where some, but not all paths to the return statement >> have &local which reaches the return. ie >> >> ... >> if (foo) >> x = &local >> else >> x = &global >> >> return x; >> >> ISTM it ought to be a standard propagation problem and that the >> problematical ADDR_EXPRs are all going to be in PHI nodes. So I think you >> just search for problematical ADDR_EXPRs in PHI nodes as your seeds, then >> forward propagate through the CFG. Ultimately looking for any cases where >> those ADDR_EXPRs ultimately reach the return statement. >> >> Thoughts? > > > I would tend to start from the return statements (assuming the return type > is a pointer), look at the defining statement, do things if it is an > assignment of an addr_expr, and recurse if it is a PHI. But maybe my brain > is cabled backwards ;-) > > It would be good to piggy back on a pass that already does something > similar, if we go that way. Do you know a convenient one? > > I am also afraid we may get more false positives, but maybe not. If you don't mind false positives you can also do the check in points-to analysis, looking at the points-to result for the SSA name we return. Btw, the idea to add this to -fisolate-errorneous-paths sounds good to me, as well as returning NULL for them. Richard. > Last, the simple version actually works well enough that it discovered at > least one real bug in real code, and I am afraid that by refining it too > much we'll delay and get nothing in the end (my time and my knowledge of the > compiler are limited enough to make it a real possibility). But I admit > that's not a good argument. > > Thanks for the comments, > > -- > Marc Glisse
Re: [PATCH] Adjust builtin-bswap-6/7
On Mon, Apr 7, 2014 at 6:22 PM, Andreas Krebbel
wrote:
> On Mon, Apr 07, 2014 at 04:19:06PM +0200, Richard Biener wrote:
>> The adjusted testcases now fail on x86_64/i?86 at least. See PR60776.
>
> They seem to require at least -O2 on x86 with that change. Ok to apply?
Hmm, they passed before your change. Do you mean that this was
by accident (and only because of the special return value)? If so then
the patch is ok.
Thanks,
Richard.
> diff --git a/gcc/testsuite/gcc.dg/builtin-bswap-6.c
> b/gcc/testsuite/gcc.dg/builtin-bswap-6.c
> index 6f0c782..f346c2f 100644
> --- a/gcc/testsuite/gcc.dg/builtin-bswap-6.c
> +++ b/gcc/testsuite/gcc.dg/builtin-bswap-6.c
> @@ -1,7 +1,7 @@
> /* { dg-do compile { target arm*-*-* alpha*-*-* i?86-*-* powerpc*-*-*
> rs6000-*-* x86_64-*-* s390*-*-* } } */
> /* { dg-require-effective-target stdint_types } */
> -/* { dg-options "-O -fdump-rtl-combine" } */
> -/* { dg-options "-O -fdump-rtl-combine -march=z900" { target s390-*-* } } */
> +/* { dg-options "-O2 -fdump-rtl-combine" } */
> +/* { dg-options "-O2 -fdump-rtl-combine -march=z900" { target s390-*-* } } */
>
> /* The test intentionally returns 1/2 instead of the obvious 0/1 to
> prevent GCC from calculating the return value with arithmetic
> diff --git a/gcc/testsuite/gcc.dg/builtin-bswap-7.c
> b/gcc/testsuite/gcc.dg/builtin-bswap-7.c
> index 0eecdd8..98529f2 100644
> --- a/gcc/testsuite/gcc.dg/builtin-bswap-7.c
> +++ b/gcc/testsuite/gcc.dg/builtin-bswap-7.c
> @@ -1,7 +1,7 @@
> /* { dg-do compile { target arm*-*-* alpha*-*-* ia64*-*-* x86_64-*-*
> s390x-*-* powerpc*-*-* rs6000-*-* } } */
> /* { dg-require-effective-target stdint_types } */
> /* { dg-require-effective-target lp64 } */
> -/* { dg-options "-O -fdump-rtl-combine" } */
> +/* { dg-options "-O2 -fdump-rtl-combine" } */
>
> /* The test intentionally returns 1/2 instead of the obvious 0/1 to
> prevent GCC from calculating the return value with arithmetic
>
[Ada] Follow-up change for PR ada/60411
This completes the switch to EHABI for ARM/Android. 2014-04-08 Eric Botcazou PR ada/60411 * gcc-interface/Makefile.in (arm% linux-android): Switch to EHABI. * s-linux-android.ads: New file. * s-intman-android.adb: Likewise. -- Eric BotcazouIndex: s-linux-android.ads === --- s-linux-android.ads (revision 0) +++ s-linux-android.ads (revision 0) @@ -0,0 +1,112 @@ +-- +-- -- +--GNU ADA RUN-TIME LIBRARY (GNARL) COMPONENTS -- +-- -- +-- S Y S T E M . L I N U X-- +-- -- +-- S p e c -- +-- -- +--Copyright (C) 2014, Free Software Foundation, Inc.-- +-- -- +-- GNARL is free software; you can redistribute it and/or modify it under -- +-- terms of the GNU General Public License as published by the Free Soft- -- +-- ware Foundation; either version 3, or (at your option) any later ver- -- +-- sion. GNAT is distributed in the hope that it will be useful, but WITH- -- +-- OUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY -- +-- or FITNESS FOR A PARTICULAR PURPOSE. -- +-- -- +-- As a special exception under Section 7 of GPL version 3, you are granted -- +-- additional permissions described in the GCC Runtime Library Exception, -- +-- version 3.1, as published by the Free Software Foundation. -- +-- -- +-- In particular, you can freely distribute your programs built with the -- +-- GNAT Pro compiler, including any required library run-time units, using -- +-- any licensing terms of your choosing. See the AdaCore Software License -- +-- for full details.-- +-- -- +-- -- +-- + +-- This is the Android version of this package + +-- This package encapsulates cpu specific differences between implementations +-- of GNU/Linux, in order to share s-osinte-linux.ads. + +-- PLEASE DO NOT add any with-clauses to this package or remove the pragma +-- Preelaborate. This package is designed to be a bottom-level (leaf) package + +package System.Linux is + pragma Preelaborate; + + + -- time_t -- + + + type time_t is new Long_Integer; + + --- + -- Errno -- + --- + + EAGAIN: constant := 11; + EINTR : constant := 4; + EINVAL: constant := 22; + ENOMEM: constant := 12; + EPERM : constant := 1; + ETIMEDOUT : constant := 110; + + - + -- Signals -- + - + + SIGHUP : constant := 1; -- hangup + SIGINT : constant := 2; -- interrupt (rubout) + SIGQUIT: constant := 3; -- quit (ASCD FS) + SIGILL : constant := 4; -- illegal instruction (not reset) + SIGTRAP: constant := 5; -- trace trap (not reset) + SIGIOT : constant := 6; -- IOT instruction + SIGABRT: constant := 6; -- used by abort, replace SIGIOT in the future + SIGFPE : constant := 8; -- floating point exception + SIGKILL: constant := 9; -- kill (cannot be caught or ignored) + SIGBUS : constant := 7; -- bus error + SIGSEGV: constant := 11; -- segmentation violation + SIGPIPE: constant := 13; -- write on a pipe with no one to read it + SIGALRM: constant := 14; -- alarm clock + SIGTERM: constant := 15; -- software termination signal from kill + SIGUSR1: constant := 10; -- user defined signal 1 + SIGUSR2: constant := 12; -- user defined signal 2 + SIGCLD : constant := 17; -- alias for SIGCHLD + SIGCHLD: constant := 17; -- child status change + SIGPWR : constant := 30; -- power-fail restart + SIGWINCH : constant := 28; -- window size change + SIGURG : constant := 23; -- urgent condition on IO channel + SIGPOLL: constant := 29; -- pollable event occurred + SIGIO : constant := 29; -- I/O now possible (4.2 BSD) + SIGLOST: constant := 29; -- File lock lost + SIGSTOP: constant := 19; -- stop (cannot be caught or
Re: RFA: Testsuite PATCH to add support for dlopen tests
> richi asked for a testcase for 60731, and since we didn't already > have support for tests using dlopen, I had to add it. > Does this approach make sense? r209187 causes thousands of g++ test failures. AFAICT the failing tests are those with no explicit 'dg-do compile' directive which are now trying to give an executable while before r209187 they were using -S. On x86_64-apple-darwin13 the tests now fail with Undefined symbols for architecture ... TIA Dominique
Re: Fixing PR60773
Cong Hou writes: > In the patch of > PR60656(http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01668.html), the > test case requires GCC to vectorize the widen-mult pattern from si to > di types. This may result in test failures on some platforms that > don't support this pattern. This patch adds a new target > vect_widen_mult_si_to_di_pattern to fix this issue. Please document the new keyword in gcc/doc/sourcebuild.texi. > diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog > index 414a745..ea860e7 100644 > --- a/gcc/testsuite/ChangeLog > +++ b/gcc/testsuite/ChangeLog > @@ -1,3 +1,11 @@ > +2014-04-07 Cong Hou > + > + PR testsuite/60773 > + * testsuite/lib/target-supports.exp: > + Add check_effective_target_vect_widen_mult_si_to_di_pattern. > + * gcc.dg/vect/pr60656.c: Update the test by checking if the targets > + vect_widen_mult_si_to_di_pattern and vect_long are supported. > + Your mailer is broken: it swallows tabs and breaks long lines. If you can't fix it, please attach patches instead of sending them inline. Thanks. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Please revert the patches in bug #54040 and #59346 and special case x32
> Attached is a patch reverting the two commits for PR ada/54040: > http://gcc.gnu.org/git/?p=gcc.git&a=search&h=HEAD&st=commit&s=PR+ada% > 2F54040 I don't think that's sufficient though, IIRC there were followup changes, so you'd better diff the current code with the revision just prior to the change. -- Eric Botcazou
Re: Fixing PR60773
On Mon, Apr 07, 2014 at 12:16:12PM -0700, Cong Hou wrote:
> --- a/gcc/testsuite/ChangeLog
> +++ b/gcc/testsuite/ChangeLog
> @@ -1,3 +1,11 @@
> +2014-04-07 Cong Hou
> +
> + PR testsuite/60773
> + * testsuite/lib/target-supports.exp:
> + Add check_effective_target_vect_widen_mult_si_to_di_pattern.
No testsuite/ prefix here. Please write it as:
* lib/target-supports.exp
(check_effective_target_vect_widen_si_to_di_pattern): New.
> --- a/gcc/testsuite/gcc.dg/vect/pr60656.c
> +++ b/gcc/testsuite/gcc.dg/vect/pr60656.c
> @@ -1,5 +1,7 @@
> /* { dg-require-effective-target vect_int } */
> +/* { dg-require-effective-target vect_long } */
>
> +#include
I fail to see why you need this include, neither your test nor tree-vect.h
uses va_*.
Otherwise looks good to me.
Jakub
