RE: [Patch, microblaze]: Add optimized lshrsi3
Hi Michael, -Original Message- From: Michael Eager [mailto:ea...@eagerm.com] Sent: Tuesday, July 01, 2014 11:12 AM To: David Holsgrove; gcc-patches@gcc.gnu.org Cc: Edgar Iglesias; John Williams; Vidhumouli Hunsigida; Nagaraju Mekala; Ajit Kumar Agarwal Subject: Re: [Patch, microblaze]: Add optimized lshrsi3 On 02/13/14 21:48, David Holsgrove wrote: > Hi Michael, > >> -Original Message- >> From: Michael Eager [mailto:ea...@eagerm.com] >> Sent: Sunday, 9 February 2014 2:58 am >> To: David Holsgrove; gcc-patches@gcc.gnu.org >> Cc: Edgar Iglesias; John Williams; Vidhumouli Hunsigida; Nagaraju >> Mekala >> Subject: Re: [Patch, microblaze]: Add optimized lshrsi3 >> >> On 11/25/13 23:53, David Holsgrove wrote: >>> Add optimized lshrsi3 instruction, to be used when optimizing for >>> size with immediate values over 5 >>> >>> Changelog >>> >>> 2013-11-26 Nagaraju Mekala >>> >>>* gcc/config/microblaze/microblaze.md: Add size optimized lshrsi3 insn. >> >> David -- >> >> Please put the description of the patch in the text of the email, >> rather than hiding it within an attached patch. >> >> The patch describes a very specific situation where this patch will >> have an effect. Please provide a test case. > > Updated version of patch attached with testcase. New Changelog entries > are; > > Changelog > > 2013-11-26 David Holsgrove > > * gcc/config/microblaze/microblaze.md: Add size optimized lshrsi3 > insn > > ChangeLog/testsuite > > 2014-02-12 David Holsgrove > > * gcc/testsuite/gcc.target/microblaze/others/lshrsi_Os_1.c: New test. > Sorry about the delay in reviewing this patch. I see number of failures in the new lshrsi_Os_1.c test case: PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O0 (test for excess errors) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O0 scan-assembler-not srli FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O0 scan-assembler ori\tr18,r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O0 scan-assembler addk\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]),r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O0 scan-assembler addik\tr18,r18,-1 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O0 scan-assembler bneid\tr18,.-4 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O0 scan-assembler srl\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O1 (test for excess errors) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O1 scan-assembler-not srli FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O1 scan-assembler ori\tr18,r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O1 scan-assembler addk\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]),r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O1 scan-assembler addik\tr18,r18,-1 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O1 scan-assembler bneid\tr18,.-4 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O1 scan-assembler srl\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O2 (test for excess errors) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O2 scan-assembler-not srli FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O2 scan-assembler ori\tr18,r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O2 scan-assembler addk\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]),r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O2 scan-assembler addik\tr18,r18,-1 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O2 scan-assembler bneid\tr18,.-4 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O2 scan-assembler srl\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -fomit-frame-pointer (test for excess errors) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -fomit-frame-pointer scan-assembler-not srli FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -fomit-frame-pointer scan-assembler ori\tr18,r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -fomit-frame-pointer scan-assembler addk\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]),r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -fomit-frame-pointer scan-assembler addik\tr18,r18,-1 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -fomit-frame-pointer scan-assembler bneid\tr18,.-4 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -fomit-frame-pointer scan-assembler srl\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -g (test for excess errors) PASS: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -g scan-assembler-not srli FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -g scan-assembler ori\tr18,r0 FAIL: gcc.target/microblaze/others/lshrsi_Os_1.c -O3 -g scan-assembler addk\tr([0-9]|[1-2][0-9]|3[0-1]),r([0-9]|[1-2][0-9]|3[0-1]),
[PATCH] Fix VRP handling of __builtin_ffs* (PR tree-optimization/61725)
Hi!
When writing this code, I've been assuming __builtin_ffs* argument
is unsigned, which is the case of popcount also handled there, and
many other builtins (clz, ctz, ...), except that clrsb has signed argument.
But in reality for some reason ffs has signed argument and some time ago
Marek has even changed the documentation to match the code rather than the
other way around.
So, here is an attempt to deal with it; to return range starting from 1
rather than 0 we need to test for argument range that doesn't include
zero (I'm now including range_includes_zero_p for that), and in case of
maximum of the range if minimum is negative, then one of the negative
values is in the range and therefore the topmost bit is sometimes set.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.9?
2014-07-08 Jakub Jelinek
PR tree-optimization/61725
* tree-vrp.c (extract_range_basic): Don't assume vr0 is unsigned
range, use range_includes_zerop_p instead of integer_zerop on
vr0->min, only use log2 of max if min is not negative.
* gcc.dg/tree-ssa/vrp93.c: New test.
* gcc.c-torture/execute/pr61725.c: New test.
--- gcc/tree-vrp.c.jj 2014-06-24 09:38:12.0 +0200
+++ gcc/tree-vrp.c 2014-07-07 11:26:30.308749523 +0200
@@ -3536,15 +3536,18 @@ extract_range_basic (value_range_t *vr,
/* If arg is non-zero, then ffs or popcount
are non-zero. */
if (((vr0->type == VR_RANGE
- && integer_nonzerop (vr0->min))
+ && range_includes_zero_p (vr0->min, vr0->max) == 0)
|| (vr0->type == VR_ANTI_RANGE
- && integer_zerop (vr0->min)))
- && !is_overflow_infinity (vr0->min))
+ && range_includes_zero_p (vr0->min, vr0->max) == 1))
+ && !is_overflow_infinity (vr0->min)
+ && !is_overflow_infinity (vr0->max))
mini = 1;
/* If some high bits are known to be zero,
we can decrease the maximum. */
if (vr0->type == VR_RANGE
&& TREE_CODE (vr0->max) == INTEGER_CST
+ && !operand_less_p (vr0->min,
+ build_zero_cst (TREE_TYPE (vr0->min)))
&& !is_overflow_infinity (vr0->max))
maxi = tree_floor_log2 (vr0->max) + 1;
}
--- gcc/testsuite/gcc.dg/tree-ssa/vrp93.c.jj2014-07-07 16:37:39.247344076
+0200
+++ gcc/testsuite/gcc.dg/tree-ssa/vrp93.c 2014-07-07 16:46:33.523847807
+0200
@@ -0,0 +1,36 @@
+/* PR target/29776 */
+/* PR tree-optimization/61725 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-vrp1" } */
+/* { dg-final { scan-tree-dump-not "link_error" "vrp1"} } */
+/* { dg-final { cleanup-tree-dump "vrp1" } } */
+
+#define A(fn, arg, min, max) \
+ if (__builtin_##fn (arg) < min || __builtin_##fn (arg) > max) \
+link_error ();
+#define B(fn, min, max) \
+ A (fn, a, min, max) A (fn##l, b, min, max) A (fn##ll, c, min, max)
+#define C(fn, min, sub) \
+ A (fn, a, min, ((int) sizeof (a) * __CHAR_BIT__ - sub)) \
+ A (fn##l, b, min, ((int) sizeof (b) * __CHAR_BIT__ - sub)) \
+ A (fn##ll, c, min, ((int) sizeof (c) * __CHAR_BIT__ - sub))
+
+extern void link_error (void);
+
+unsigned int d;
+unsigned long e;
+unsigned long long f;
+
+void
+foo (int a, long b, long long c)
+{
+ C (ffs, 0, 0)
+ a &= 63; b &= 63; c &= 63;
+ B (ffs, 0, 6)
+ a++; b++; c++;
+ B (ffs, 1, 7)
+ a -= 2; b -= 2; c -= 2;
+ C (ffs, 0, 0)
+ a -= 63; b -= 63; c -= 63;
+ C (ffs, 1, 0)
+}
--- gcc/testsuite/gcc.c-torture/execute/pr61725.c.jj2014-07-07
11:04:07.936218135 +0200
+++ gcc/testsuite/gcc.c-torture/execute/pr61725.c 2014-07-07
11:03:47.0 +0200
@@ -0,0 +1,14 @@
+/* PR tree-optimization/61725 */
+
+int
+main ()
+{
+ int x;
+ for (x = -128; x <= 128; x++)
+{
+ int a = __builtin_ffs (x);
+ if (x == 0 && a != 0)
+__builtin_abort ();
+}
+ return 0;
+}
Jakub
Re: [PATCH ARM] Improve ARM memset inlining
On Fri, Jul 4, 2014 at 1:17 PM, Bin Cheng wrote: > > > > Hi Ramana, > This is the rebased patch, there is no conflict against latest trunk. I am > still doing some tests. Is it OK if tests are fine? > Also, it depends on patch at > https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01923.html, I will update that > patch two. Hi Ramana, Bootstrap and tests for this patch are done. Is it ok for me to submit? Thanks, bin
Re: Optimize type streaming
>
> We have reverted the patch for now but I note that at least the piece
> below is a step backward from doing the compare in the on-disk
> format.
Why it is step backward from compare in the on-dist format? All the information
is still streamed, just not duplicated. Since we explicitly stream main variant
pointer, we will have all the comparsion done in on-disk format if we was able
to do it.
>
> So I'd rather push back the whole change a bit until I find the time
> to explore that (as it complicates the code quite a bit).
It indeed adds some of complexity and tree streaming is your domain ;)
I will push out the sanity checkng part (that is actually bit more important
for me
than the actual reduction in streaming) to a type verifier. There are more
invariants
to look into and more bugs to fix.
I did some more experiments in this direction (not streaming data that is
redundant). In similar way I removed streaming sizes/modes for decls (since
they are 99% copied from trees) and streaming the items that are usually shared
with main variant, but not always (fields). With copying done here in streamer
it works quite nicely and do save space in the stream/time needed to read back.
Honza
>
> Richard.
>
> > Honza
> >
> > Index: lto-streamer-in.c
> > ===
> > --- lto-streamer-in.c (revision 212098)
> > +++ lto-streamer-in.c (working copy)
> > @@ -1182,6 +1182,58 @@ lto_read_tree (struct lto_input_block *i
> > }
> >
> >
> > +/* Copy fields that are not streamed but copied from other nodes. */
> > +static void
> > +lto_copy_fields_not_streamed (tree t)
> > +{
> > + if (TYPE_P (t) && TYPE_MAIN_VARIANT (t) != t)
> > +{
> > + tree mv = TYPE_MAIN_VARIANT (t);
> > +
> > + if (COMPLETE_TYPE_P (t))
> > + {
> > + TYPE_SIZE (t) = TYPE_SIZE (mv);
> > + TYPE_SIZE_UNIT (t) = TYPE_SIZE_UNIT (mv);
> > + }
> > + TYPE_ATTRIBUTES (t) = TYPE_ATTRIBUTES (mv);
> > +
> > + if (CODE_CONTAINS_STRUCT (TREE_CODE (t), TS_TYPE_NON_COMMON))
> > + {
> > + if (TREE_CODE (t) == ENUMERAL_TYPE && COMPLETE_TYPE_P (t))
> > + TYPE_VALUES (t) = TYPE_VALUES (mv);
> > + else if (TREE_CODE (t) == ARRAY_TYPE)
> > + TYPE_DOMAIN (t) = TYPE_DOMAIN (mv);
> > +
> > + if (RECORD_OR_UNION_TYPE_P (t) && COMPLETE_TYPE_P (t))
> > + TYPE_VFIELD (t) = TYPE_VFIELD (mv);
> > + else if ((TREE_CODE (t) == ENUMERAL_TYPE && COMPLETE_TYPE_P (t))
> > + || TREE_CODE (t) == INTEGER_TYPE
> > + || TREE_CODE (t) == BOOLEAN_TYPE
> > + || TREE_CODE (t) == REAL_TYPE
> > + || TREE_CODE (t) == FIXED_POINT_TYPE)
> > + TYPE_MIN_VALUE (t) = TYPE_MIN_VALUE (mv);
> > +
> > + if (TREE_CODE (t) == METHOD_TYPE)
> > + TYPE_METHOD_BASETYPE (t) = TYPE_METHOD_BASETYPE (mv);
> > + else if (RECORD_OR_UNION_TYPE_P (t) && COMPLETE_TYPE_P (t))
> > + TYPE_METHODS (t) = TYPE_METHODS (mv);
> > + else if (TREE_CODE (t) == OFFSET_TYPE)
> > + TYPE_OFFSET_BASETYPE (t) = TYPE_OFFSET_BASETYPE (mv);
> > + else if (TREE_CODE (t) == ARRAY_TYPE)
> > + TYPE_ARRAY_MAX_SIZE (t) = TYPE_ARRAY_MAX_SIZE (mv);
> > + else if ((TREE_CODE (t) == ENUMERAL_TYPE && COMPLETE_TYPE_P (t))
> > + || TREE_CODE (t) == INTEGER_TYPE
> > + || TREE_CODE (t) == BOOLEAN_TYPE
> > + || TREE_CODE (t) == REAL_TYPE
> > + || TREE_CODE (t) == FIXED_POINT_TYPE)
> > + TYPE_MAX_VALUE (t) = TYPE_MAX_VALUE (mv);
> > +
> > + if (RECORD_OR_UNION_TYPE_P (t) && COMPLETE_TYPE_P (t))
> > + TYPE_BINFO (t) = TYPE_BINFO (mv);
> > + }
> > +}
> > +}
> > +
> > /* Populate the reader cache with trees materialized from the SCC
> > following in the IB, DATA_IN stream. */
> >
> > @@ -1194,6 +1246,7 @@ lto_input_scc (struct lto_input_block *i
> >unsigned size = streamer_read_uhwi (ib);
> >hashval_t scc_hash = streamer_read_uhwi (ib);
> >unsigned scc_entry_len = 1;
> > + unsigned from = data_in->reader_cache->nodes.length ();
> >
> >if (size == 1)
> > {
> > @@ -1233,6 +1286,12 @@ lto_input_scc (struct lto_input_block *i
> > }
> > }
> >
> > + /* Copy fileds we do not stream before unification so we can compare them
> > + without being worried if they are already initialized. */
> > + for (unsigned i = 0; i < size; ++i)
> > +lto_copy_fields_not_streamed
> > + (streamer_tree_cache_get_tree (data_in->reader_cache, from + i));
> > +
> >*len = size;
> >*entry_len = scc_entry_len;
> >return scc_hash;
> > Index: lto/lto.c
> > ===
> > --- lto/lto.c (revision 212114)
> > +++ lto/lto.c (working copy)
> > @@ -1050,58 +1050,6 @@ lto_register_function_decl_in_symtab (st
> > decl, get_resolution (data_in, ix));
> > }
> >
> > -/* Copy fields that are not streamed but copied
Re: Proper fix for PR58477
On Tue, 8 Jul 2014, Jan Hubicka wrote:
> Hi,
> I had to revert change to ipa-prop.c that made stmt_may_be_vtbl_ptr_store
> to know that clobbers can not be such stores.
>
> This triggered byg in detect_type_change_from_memory_writes. This function
> does
> two things. First is that it tries to prove that vtbl pointer was not modified
> in the function body. Second it tries to prove that the modification is a
> known
> type. For this it needs to find proper vtbl store along every path to the
> call.
> This is not what happens because it only checks that all vtbl stores it found
> are of the same type. The object may come pre-initialized to the function.
>
> The bug on stopping of clobbers sort of fixed the issue, because we consider
> only
> object in declarations and those are constructed in a dominating block, but it
> works by accident.
>
> This is patch we discussed back then adding interface to walk_aliased_vdefs
> declaring whether entry of function was reached and avoids
> stmt_may_be_vtbl_ptr_store
> to jump into conclussion about the dynamic type in that case.
>
> Bootstrapped/regtested x86_64-linux, OK?
Ok.
Thanks,
Richard.
> Honza
>
> * tree-ssa-alias.c (walk_aliased_vdefs_1): Add FUNCTION_ENTRY_REACHED
> parameter.
> (walk_aliased_vdefs): Likewise.
> * tree-ssa-alias.h (walk_aliased_vdefs): Likewise.
> * ipa-prop.c (stmt_may_be_vtbl_ptr_store): Skip clobbers
> (detect_type_change_from_memory_writes): Check if entry was reached.
> Index: tree-ssa-alias.c
> ===
> --- tree-ssa-alias.c (revision 212339)
> +++ tree-ssa-alias.c (working copy)
> @@ -2643,6 +2643,9 @@ walk_non_aliased_vuses (ao_ref *ref, tre
> WALKER is called with REF, the current vdef and DATA. If WALKER
> returns true the walk is stopped, otherwise it continues.
>
> + If function entry is reached, FUNCTION_ENTRY_REACHED is set to true.
> + The pointer may be NULL and then we do not track this information.
> +
> At PHI nodes walk_aliased_vdefs forks into one walk for reach
> PHI argument (but only one walk continues on merge points), the
> return value is true if any of the walks was successful.
> @@ -2652,8 +2655,11 @@ walk_non_aliased_vuses (ao_ref *ref, tre
> static unsigned int
> walk_aliased_vdefs_1 (ao_ref *ref, tree vdef,
> bool (*walker)(ao_ref *, tree, void *), void *data,
> - bitmap *visited, unsigned int cnt)
> + bitmap *visited, unsigned int cnt,
> + bool *function_entry_reached)
> {
> + if (function_entry_reached)
> +*function_entry_reached = false;
>do
> {
>gimple def_stmt = SSA_NAME_DEF_STMT (vdef);
> @@ -2663,7 +2669,11 @@ walk_aliased_vdefs_1 (ao_ref *ref, tree
> return cnt;
>
>if (gimple_nop_p (def_stmt))
> - return cnt;
> + {
> + if (function_entry_reached)
> + *function_entry_reached = true;
> + return cnt;
> + }
>else if (gimple_code (def_stmt) == GIMPLE_PHI)
> {
> unsigned i;
> @@ -2671,7 +2681,8 @@ walk_aliased_vdefs_1 (ao_ref *ref, tree
> *visited = BITMAP_ALLOC (NULL);
> for (i = 0; i < gimple_phi_num_args (def_stmt); ++i)
> cnt += walk_aliased_vdefs_1 (ref, gimple_phi_arg_def (def_stmt, i),
> - walker, data, visited, 0);
> + walker, data, visited, 0,
> + function_entry_reached);
> return cnt;
> }
>
> @@ -2690,7 +2701,8 @@ walk_aliased_vdefs_1 (ao_ref *ref, tree
> unsigned int
> walk_aliased_vdefs (ao_ref *ref, tree vdef,
> bool (*walker)(ao_ref *, tree, void *), void *data,
> - bitmap *visited)
> + bitmap *visited,
> + bool *function_entry_reached)
> {
>bitmap local_visited = NULL;
>unsigned int ret;
> @@ -2698,7 +2710,8 @@ walk_aliased_vdefs (ao_ref *ref, tree vd
>timevar_push (TV_ALIAS_STMT_WALK);
>
>ret = walk_aliased_vdefs_1 (ref, vdef, walker, data,
> - visited ? visited : &local_visited, 0);
> + visited ? visited : &local_visited, 0,
> + function_entry_reached);
>if (local_visited)
> BITMAP_FREE (local_visited);
>
> Index: tree-ssa-alias.h
> ===
> --- tree-ssa-alias.h (revision 212339)
> +++ tree-ssa-alias.h (working copy)
> @@ -123,7 +123,8 @@ extern void *walk_non_aliased_vuses (ao_
>void *);
> extern unsigned int walk_aliased_vdefs (ao_ref *, tree,
> bool (*)(ao_ref *, tree, void *),
> - void *, bitmap *);
> + void *, bitmap *,
> +
Re: [RFC] Add a .gitattributes file for use with git-merge-changelog
Hi Samuel, This seems like a good idea to me. On 07/08/2014 02:35 AM, Samuel Bronson wrote: > Ping? If nobody has anything else to say, I'm going to assume that such > a change is unobjectionable, and should not be listed in the ChangeLog. When in doubt, look for precedence. grep will show changes to other .git* files were listed in ChangeLog: $ grep "\.git" ChangeLog* gdb/ChangeLog* ChangeLog: * .gitignore: Import from gdb repository. ChangeLog: * .gitignore: New file. gdb/ChangeLog-2011: * .gitignore: New file. gdb/ChangeLog-2012: * .gitignore: Add go-exp.c. gdb/ChangeLog-2012: * .gitignore: Ignore more files. gdb/ChangeLog-2012: * .gitignore (/gdbtui): Remove. gdb/ChangeLog-2013: * .gitignore: Add /gcore. Likewise 'git log .gitignore gdb/.gitignore'. -- Pedro Alves
Re: [PATCH] Fix VRP handling of __builtin_ffs* (PR tree-optimization/61725)
On Tue, 8 Jul 2014, Jakub Jelinek wrote:
> Hi!
>
> When writing this code, I've been assuming __builtin_ffs* argument
> is unsigned, which is the case of popcount also handled there, and
> many other builtins (clz, ctz, ...), except that clrsb has signed argument.
> But in reality for some reason ffs has signed argument and some time ago
> Marek has even changed the documentation to match the code rather than the
> other way around.
>
> So, here is an attempt to deal with it; to return range starting from 1
> rather than 0 we need to test for argument range that doesn't include
> zero (I'm now including range_includes_zero_p for that), and in case of
> maximum of the range if minimum is negative, then one of the negative
> values is in the range and therefore the topmost bit is sometimes set.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.9?
Ok.
Thanks,
Richard.
> 2014-07-08 Jakub Jelinek
>
> PR tree-optimization/61725
> * tree-vrp.c (extract_range_basic): Don't assume vr0 is unsigned
> range, use range_includes_zerop_p instead of integer_zerop on
> vr0->min, only use log2 of max if min is not negative.
>
> * gcc.dg/tree-ssa/vrp93.c: New test.
> * gcc.c-torture/execute/pr61725.c: New test.
>
> --- gcc/tree-vrp.c.jj 2014-06-24 09:38:12.0 +0200
> +++ gcc/tree-vrp.c2014-07-07 11:26:30.308749523 +0200
> @@ -3536,15 +3536,18 @@ extract_range_basic (value_range_t *vr,
> /* If arg is non-zero, then ffs or popcount
>are non-zero. */
> if (((vr0->type == VR_RANGE
> - && integer_nonzerop (vr0->min))
> + && range_includes_zero_p (vr0->min, vr0->max) == 0)
> || (vr0->type == VR_ANTI_RANGE
> -&& integer_zerop (vr0->min)))
> - && !is_overflow_infinity (vr0->min))
> +&& range_includes_zero_p (vr0->min, vr0->max) == 1))
> + && !is_overflow_infinity (vr0->min)
> + && !is_overflow_infinity (vr0->max))
> mini = 1;
> /* If some high bits are known to be zero,
>we can decrease the maximum. */
> if (vr0->type == VR_RANGE
> && TREE_CODE (vr0->max) == INTEGER_CST
> + && !operand_less_p (vr0->min,
> + build_zero_cst (TREE_TYPE (vr0->min)))
> && !is_overflow_infinity (vr0->max))
> maxi = tree_floor_log2 (vr0->max) + 1;
> }
> --- gcc/testsuite/gcc.dg/tree-ssa/vrp93.c.jj 2014-07-07 16:37:39.247344076
> +0200
> +++ gcc/testsuite/gcc.dg/tree-ssa/vrp93.c 2014-07-07 16:46:33.523847807
> +0200
> @@ -0,0 +1,36 @@
> +/* PR target/29776 */
> +/* PR tree-optimization/61725 */
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-vrp1" } */
> +/* { dg-final { scan-tree-dump-not "link_error" "vrp1"} } */
> +/* { dg-final { cleanup-tree-dump "vrp1" } } */
> +
> +#define A(fn, arg, min, max) \
> + if (__builtin_##fn (arg) < min || __builtin_##fn (arg) > max) \
> +link_error ();
> +#define B(fn, min, max) \
> + A (fn, a, min, max) A (fn##l, b, min, max) A (fn##ll, c, min, max)
> +#define C(fn, min, sub) \
> + A (fn, a, min, ((int) sizeof (a) * __CHAR_BIT__ - sub)) \
> + A (fn##l, b, min, ((int) sizeof (b) * __CHAR_BIT__ - sub)) \
> + A (fn##ll, c, min, ((int) sizeof (c) * __CHAR_BIT__ - sub))
> +
> +extern void link_error (void);
> +
> +unsigned int d;
> +unsigned long e;
> +unsigned long long f;
> +
> +void
> +foo (int a, long b, long long c)
> +{
> + C (ffs, 0, 0)
> + a &= 63; b &= 63; c &= 63;
> + B (ffs, 0, 6)
> + a++; b++; c++;
> + B (ffs, 1, 7)
> + a -= 2; b -= 2; c -= 2;
> + C (ffs, 0, 0)
> + a -= 63; b -= 63; c -= 63;
> + C (ffs, 1, 0)
> +}
> --- gcc/testsuite/gcc.c-torture/execute/pr61725.c.jj 2014-07-07
> 11:04:07.936218135 +0200
> +++ gcc/testsuite/gcc.c-torture/execute/pr61725.c 2014-07-07
> 11:03:47.0 +0200
> @@ -0,0 +1,14 @@
> +/* PR tree-optimization/61725 */
> +
> +int
> +main ()
> +{
> + int x;
> + for (x = -128; x <= 128; x++)
> +{
> + int a = __builtin_ffs (x);
> + if (x == 0 && a != 0)
> +__builtin_abort ();
> +}
> + return 0;
> +}
>
> Jakub
>
>
--
Richard Biener
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
Re: [PATCH ARM] Improve ARM memset inlining
Hi Ramana,
This is the rebased patch, there is no conflict against latest trunk. I am
still doing some tests. Is it OK if tests are fine?
Also, it depends on patch at
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01923.html, I will update that
patch two.
Thanks,
bin
Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 212295)
+++ gcc/config/arm/arm.c(working copy)
@@ -1588,34 +1588,38 @@ const struct tune_params arm_slowmul_tune =
{
arm_slowmul_rtx_costs,
NULL,
- NULL,/* Sched adj cost. */
- 3, /* Constant limit. */
- 5, /* Max cond insns. */
+ NULL,/* Sched adj cost. */
+ 3, /* Constant limit. */
+ 5, /* Max cond insns. */
Please make sure alignment is maintained with comments as today. I'm not
sure why I see the following diffs in your patch since you don't really
should be touching those lines, that applies to all the cost tables. I
haven't called out all the places where you appear to have unrelated
formatting changes in detail, but have done so in one cost table.
Please re-create a patch that doesn't have these hunks.
ARM_PREFETCH_NOT_BENEFICIAL,
- true,/* Prefer constant
pool. */
+ true,/* Prefer constant pool. */
Likewise.
arm_default_branch_cost,
- false, /* Prefer LDRD/STRD. */
- {true, true},/* Prefer non short
circuit. */
- &arm_default_vec_cost,/* Vectorizer costs. */
- false,/* Prefer Neon for 64-bits
bitops. */
- false, false /* Prefer 32-bit encodings. */
+ false, /* Prefer LDRD/STRD. */
+ {true, true},/* Prefer non short circuit. */
+ &arm_default_vec_cost, /* Vectorizer costs. */
+ false, /* Prefer Neon for 64-bits bitops. */
+ false, false,/* Prefer 32-bit encodings. */
Likewise.
+ false, /* Prefer Neon for stringops. */
+ 8/* Maximum insns to inline memset. */
};
const struct tune_params arm_fastmul_tune =
{
arm_fastmul_rtx_costs,
NULL,
- NULL,/* Sched adj cost. */
- 1, /* Constant limit. */
- 5, /* Max cond insns. */
+ NULL,/* Sched adj cost. */
+ 1, /* Constant limit. */
+ 5, /* Max cond insns. */
ARM_PREFETCH_NOT_BENEFICIAL,
- true,/* Prefer constant
pool. */
+ true,/* Prefer constant pool. */
arm_default_branch_cost,
- false, /* Prefer LDRD/STRD. */
- {true, true},/* Prefer non short
circuit. */
- &arm_default_vec_cost,/* Vectorizer costs. */
- false,/* Prefer Neon for 64-bits
bitops. */
- false, false /* Prefer 32-bit encodings. */
+ false, /* Prefer LDRD/STRD. */
+ {true, true},/* Prefer non short circuit. */
+ &arm_default_vec_cost, /* Vectorizer costs. */
+ false, /* Prefer Neon for 64-bits bitops. */
+ false, false,/* Prefer 32-bit encodings. */
+ false, /* Prefer Neon for stringops. */
+ 8/* Maximum insns to inline memset. */
};
/* StrongARM has early execution of branches, so a sequence that is worth
@@ -1625,17 +1629,19 @@ const struct tune_params arm_strongarm_tune =
{
arm_fastmul_rtx_costs,
NULL,
- NULL,/* Sched adj cost. */
- 1, /* Constant limit. */
- 3, /* Max cond insns. */
+ NULL,/* Sched adj cost. */
+ 1, /* Constant limit. */
+ 3, /* Max cond insns. */
ARM_PREFETCH_NOT_BENEFICIAL,
- true,/* Prefer constant
pool. */
+ true,
[PATCH] Remove copy propagation restrictions on loops
As promised and analyzed in the DOM thread the following patch
removes restriction on copy propagating through PHIs on loop
exits (when we don't have to preserve loop-closed SSA form).
Fallout in out-of-SSA coalescing has been dealt with there.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2014-07-08 Richard Biener
* tree-ssa-dom.h (loop_depth_of_name): Remove.
* tree-ssa-dom.c (record_equivalences_from_phis): Remove
restriction on loop depth difference.
(record_equality): Likewise.
(propagate_rhs_into_lhs): Likewise. Simplify condition.
(loop_depth_of_name): Remove.
* tree-ssa-copy.c (copy_prop_visit_phi_node): Remove
restriction on loop depth difference.
(init_copy_prop): Likewise.
* gcc.dg/tree-ssa/ssa-pre-16.c: Adjust expected eliminations.
Index: gcc/tree-ssa-dom.c
===
--- gcc/tree-ssa-dom.c (revision 212065)
+++ gcc/tree-ssa-dom.c (working copy)
@@ -1235,12 +1235,7 @@ record_equivalences_from_phis (basic_blo
inferred from a comparison. All uses of this ssa name are dominated
by this assignment, so unwinding just costs time and space. */
if (i == gimple_phi_num_args (phi)
- && may_propagate_copy (lhs, rhs)
- /* Do not propagate copies if the propagated value is at a deeper loop
-depth than the propagatee. Otherwise, this may introduce uses
-of loop variant variables outside of their loops and prevent
-coalescing opportunities. */
- && !(loop_depth_of_name (rhs) > loop_depth_of_name (lhs)))
+ && may_propagate_copy (lhs, rhs))
set_ssa_name_value (lhs, rhs);
}
}
@@ -1575,33 +1570,6 @@ record_const_or_copy_1 (tree x, tree y,
const_and_copies_stack.quick_push (x);
}
-/* Return the loop depth of the basic block of the defining statement of X.
- This number should not be treated as absolutely correct because the loop
- information may not be completely up-to-date when dom runs. However, it
- will be relatively correct, and as more passes are taught to keep loop info
- up to date, the result will become more and more accurate. */
-
-int
-loop_depth_of_name (tree x)
-{
- gimple defstmt;
- basic_block defbb;
-
- /* If it's not an SSA_NAME, we have no clue where the definition is. */
- if (TREE_CODE (x) != SSA_NAME)
-return 0;
-
- /* Otherwise return the loop depth of the defining statement's bb.
- Note that there may not actually be a bb for this statement, if the
- ssa_name is live on entry. */
- defstmt = SSA_NAME_DEF_STMT (x);
- defbb = gimple_bb (defstmt);
- if (!defbb)
-return 0;
-
- return bb_loop_depth (defbb);
-}
-
/* Record that X is equal to Y in const_and_copies. Record undo
information in the block-local vector. */
@@ -1641,8 +1609,7 @@ record_equality (tree x, tree y)
long as we canonicalize on one value. */
if (is_gimple_min_invariant (y))
;
- else if (is_gimple_min_invariant (x)
- || (loop_depth_of_name (x) <= loop_depth_of_name (y)))
+ else if (is_gimple_min_invariant (x))
prev_x = x, x = y, y = prev_x, prev_x = prev_y;
else if (prev_x && is_gimple_min_invariant (prev_x))
x = y, y = prev_x, prev_x = prev_y;
@@ -2686,13 +2653,8 @@ get_lhs_or_phi_result (gimple stmt)
static void
propagate_rhs_into_lhs (gimple stmt, tree lhs, tree rhs, bitmap
interesting_names)
{
- /* First verify that propagation is valid and isn't going to move a
- loop variant variable outside its loop. */
- if (! SSA_NAME_OCCURS_IN_ABNORMAL_PHI (lhs)
- && (TREE_CODE (rhs) != SSA_NAME
- || ! SSA_NAME_OCCURS_IN_ABNORMAL_PHI (rhs))
- && may_propagate_copy (lhs, rhs)
- && loop_depth_of_name (lhs) >= loop_depth_of_name (rhs))
+ /* First verify that propagation is valid. */
+ if (may_propagate_copy (lhs, rhs))
{
use_operand_p use_p;
imm_use_iterator iter;
Index: gcc/tree-ssa-copy.c
===
--- gcc/tree-ssa-copy.c (revision 212065)
+++ gcc/tree-ssa-copy.c (working copy)
@@ -400,15 +400,11 @@ copy_prop_visit_phi_node (gimple phi)
else
arg_value = valueize_val (arg);
- /* Avoid copy propagation from an inner into an outer loop.
-Otherwise, this may introduce uses of loop variant variables
-outside of their loops and prevent coalescing opportunities.
-In loop-closed SSA form do not copy-propagate through
-PHI nodes in blocks with a loop exit edge predecessor. */
- if (TREE_CODE (arg_value) == SSA_NAME
- && (loop_depth_of_name (arg_value) > loop_depth_of_name (lhs)
- || (loops_state_satisfies_p (LOOP_CLOSED_SSA)
- && loop_exit_edge_p (e->src->loop_father, e
+ /* In loop-closed SSA form do not copy-propagate SSA-names across
+loop exit ed
Re: [GOMP4, OpenACC] Fixed-form Fortran code failing to parse
Cesar Philippidis wrote: > Thomas, is this OK for gomp-4_0-branch? ... > * gcc/fortran/scanner.c (gfc_next_char_literal): Fix the scan for > *$acc. This changes looks good to me. > * parse.c (next_fixed): Don't handle openmp pragmas when scanning > for openacc pragmas. This one doesn't. If both -fopenmp(-simd) and -fopenacc are both specified, parsing of $omp *and* $acc are both disabled, which does not seem to be what is intended. The current code does: 1066 if ((gfc_option.gfc_flag_openmp 1067 || gfc_option.gfc_flag_openmp_simd) 1068&& !gfc_option.gfc_flag_openacc) ... 1074else if ((gfc_option.gfc_flag_openmp 1075 || gfc_option.gfc_flag_openmp_simd) 1076 && gfc_option.gfc_flag_openacc) ... 1092else if (gfc_option.gfc_flag_openacc) The proposed patch keeps 1066 if ((gfc_option.gfc_flag_openmp 1067 || gfc_option.gfc_flag_openmp_simd) 1068&& !gfc_option.gfc_flag_openacc) ... and then it uses: + else if (gfc_option.gfc_flag_openacc + && !(gfc_option.gfc_flag_openmp + || gfc_option.gfc_flag_openmp_simd)) ... - else if (gfc_option.gfc_flag_openacc) Thus, from my side this patch is NOT OK. Tobias
[PATCH 4.9][ARM] Backport r211369 PR/61062 Fix arm_neon.h ZIP/UZP/TRN for Bigendian
No regressions on arm-none-eabi or armeb-none-eabi; also FAIL->PASS on local
copies of the execution-result tests in gcc.target/arm/simd tests (taken from
mainline, these are not present in 4.9).
gcc/ChangeLog:
PR target/61062
Backport r211369 from mainline.
2014-06-09 Alan Lawrence
* config/arm/arm_neon.h (vtrn_s8, vtrn_s16, vtrn_u8, vtrn_u16, vtrn_p8,
vtrn_p16, vtrn_s32, vtrn_f32, vtrn_u32, vtrnq_s8, vtrnq_s16, vtrnq_s32,
vtrnq_f32, vtrnq_u8, vtrnq_u16, vtrnq_u32, vtrnq_p8, vtrnq_p16, vzip_s8,
vzip_s16, vzip_u8, vzip_u16, vzip_p8, vzip_p16, vzip_s32, vzip_f32,
vzip_u32, vzipq_s8, vzipq_s16, vzipq_s32, vzipq_f32, vzipq_u8,
vzipq_u16, vzipq_u32, vzipq_p8, vzipq_p16, vuzp_s8, vuzp_s16, vuzp_s32,
vuzp_f32, vuzp_u8, vuzp_u16, vuzp_u32, vuzp_p8, vuzp_p16, vuzpq_s8,
vuzpq_s16, vuzpq_s32, vuzpq_f32, vuzpq_u8, vuzpq_u16, vuzpq_u32,
vuzpq_p8, vuzpq_p16): Correct mask for bigendian.
gcc/testsuite/ChangeLog:
PR target/61062
Backport r211369 from mainline.
2014-06-09 Alan Lawrence
*gcc.target/arm/pr48252.c (main): Expect same result as endian-neutral.
Ok?diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index 37a6e61..f86f0d4 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -7707,12 +7707,32 @@ vbslq_p16 (uint16x8_t __a, poly16x8_t __b, poly16x8_t __c)
return (poly16x8_t)__builtin_neon_vbslv8hi ((int16x8_t) __a, (int16x8_t) __b, (int16x8_t) __c);
}
+/* For big-endian, the shuffle masks for ZIP, UZP and TRN must be changed as
+ follows. (nelt = the number of elements within a vector.)
+
+ Firstly, a value of N within a mask, becomes (N ^ (nelt - 1)), as gcc vector
+ extension's indexing scheme is reversed *within each vector* (relative to the
+ neon intrinsics view), but without changing which of the two vectors.
+
+ Secondly, the elements within each mask are reversed, as the mask is itself a
+ vector, and will itself be loaded in reverse order (again, relative to the
+ neon intrinsics view, i.e. that would result from a "vld1" instruction). */
+
__extension__ static __inline int8x8x2_t __attribute__ ((__always_inline__))
vtrn_s8 (int8x8_t __a, int8x8_t __b)
{
int8x8x2_t __rv;
- __rv.val[0] = (int8x8_t) __builtin_shuffle (__a, __b, (uint8x8_t) { 0, 8, 2, 10, 4, 12, 6, 14 });
- __rv.val[1] = (int8x8_t) __builtin_shuffle (__a, __b, (uint8x8_t) { 1, 9, 3, 11, 5, 13, 7, 15 });
+#ifdef __ARM_BIG_ENDIAN
+ __rv.val[0] = __builtin_shuffle (__a, __b, (uint8x8_t)
+ { 9, 1, 11, 3, 13, 5, 15, 7 });
+ __rv.val[1] = __builtin_shuffle (__a, __b, (uint8x8_t)
+ { 8, 0, 10, 2, 12, 4, 14, 6 });
+#else
+ __rv.val[0] = __builtin_shuffle (__a, __b, (uint8x8_t)
+ { 0, 8, 2, 10, 4, 12, 6, 14 });
+ __rv.val[1] = __builtin_shuffle (__a, __b, (uint8x8_t)
+ { 1, 9, 3, 11, 5, 13, 7, 15 });
+#endif
return __rv;
}
@@ -7720,8 +7740,13 @@ __extension__ static __inline int16x4x2_t __attribute__ ((__always_inline__))
vtrn_s16 (int16x4_t __a, int16x4_t __b)
{
int16x4x2_t __rv;
- __rv.val[0] = (int16x4_t) __builtin_shuffle (__a, __b, (uint16x4_t) { 0, 4, 2, 6 });
- __rv.val[1] = (int16x4_t) __builtin_shuffle (__a, __b, (uint16x4_t) { 1, 5, 3, 7 });
+#ifdef __ARM_BIG_ENDIAN
+ __rv.val[0] = __builtin_shuffle (__a, __b, (uint16x4_t) { 5, 1, 7, 3 });
+ __rv.val[1] = __builtin_shuffle (__a, __b, (uint16x4_t) { 4, 0, 6, 2 });
+#else
+ __rv.val[0] = __builtin_shuffle (__a, __b, (uint16x4_t) { 0, 4, 2, 6 });
+ __rv.val[1] = __builtin_shuffle (__a, __b, (uint16x4_t) { 1, 5, 3, 7 });
+#endif
return __rv;
}
@@ -7729,8 +7754,17 @@ __extension__ static __inline uint8x8x2_t __attribute__ ((__always_inline__))
vtrn_u8 (uint8x8_t __a, uint8x8_t __b)
{
uint8x8x2_t __rv;
- __rv.val[0] = (uint8x8_t) __builtin_shuffle (__a, __b, (uint8x8_t) { 0, 8, 2, 10, 4, 12, 6, 14 });
- __rv.val[1] = (uint8x8_t) __builtin_shuffle (__a, __b, (uint8x8_t) { 1, 9, 3, 11, 5, 13, 7, 15 });
+#ifdef __ARM_BIG_ENDIAN
+ __rv.val[0] = __builtin_shuffle (__a, __b, (uint8x8_t)
+ { 9, 1, 11, 3, 13, 5, 15, 7 });
+ __rv.val[1] = __builtin_shuffle (__a, __b, (uint8x8_t)
+ { 8, 0, 10, 2, 12, 4, 14, 6 });
+#else
+ __rv.val[0] = __builtin_shuffle (__a, __b, (uint8x8_t)
+ { 0, 8, 2, 10, 4, 12, 6, 14 });
+ __rv.val[1] = __builtin_shuffle (__a, __b, (uint8x8_t)
+ { 1, 9, 3, 11, 5, 13, 7, 15 });
+#endif
return __rv;
}
@@ -7738,8 +7772,13 @@ __extension__ static __inline uint16x4x2_t __attribute__ ((__always_inline__))
vtrn_u16 (uint16x4_t __a, uint16x4_t __b)
{
uint16x4x2_t __rv;
- __rv.val[0] = (uint16x4_t) __builtin_shuffle (__a, __b, (uint16x4_t) { 0, 4, 2, 6 });
- __rv.val[1] = (uint16x4_t) __builtin_shuffle (__a, __b, (uint16x4_t) { 1, 5, 3, 7 });
+#ifdef __ARM_BIG_ENDIAN
+ __rv.val[0] = __builtin_shuffle (__a, __b, (uint16x4_t) { 5, 1, 7, 3 });
+ __rv.val[1] = __builtin_shuffle (__a, __b, (uint16x4_t)
Re: [GSoC][match-and-simplify] add few test-cases
On Sun, Jul 6, 2014 at 9:45 PM, Prathamesh Kulkarni wrote: > Hi, > This patch adds few test-cases for gimple match-and-simplfiy and > removes match-2.c > > [gcc/testsuite/gcc.dg/tree-ssa] > * match-2.c: Remove. > * match-plusminus.c: New test-case. > * match-bitwise.c: Likewise. > * match-realimag.c: Likewise. Thanks - committed. Richard. > Thanks and Regards, > Prathamesh
Re: [PATCH] PR bootstrap/61679 playcate old gcc
On Tue, Jul 8, 2014 at 4:21 AM, wrote:
> From: Trevor Saunders
>
> Hi,
>
> I'll admitt I'm not actually sure if the spec requires this, or if gcc 4.5 was
> too picky, but this fixes the build with gcc 4.5, and it doesn't really hurt
> anything.
>
> bootstrapped + regtested on x86_64-unknown-linux-gnu with no regressions, ok?
Ok.
Thanks,
Richard.
> Trev
>
> gcc/
>
> PR bootstrap/61679
> * hash-table.h: use hash_table::value_type instead of
> Descriptor::value_type in the return types of several methods.
>
> diff --git a/gcc/hash-table.h b/gcc/hash-table.h
> index 22af12f..9c6a34a 100644
> --- a/gcc/hash-table.h
> +++ b/gcc/hash-table.h
> @@ -663,7 +663,7 @@ hash_table::~hash_table ()
> HASH is the hash value for the element to be inserted. */
>
> template class Allocator>
> -typename Descriptor::value_type **
> +typename hash_table::value_type **
> hash_table
> ::find_empty_slot_for_expand (hashval_t hash)
> {
> @@ -803,7 +803,7 @@ hash_table::clear_slot
> (value_type **slot)
> be used to insert or delete an element. */
>
> template class Allocator>
> -typename Descriptor::value_type *
> +typename hash_table::value_type *
> hash_table
> ::find_with_hash (const compare_type *comparable, hashval_t hash)
> {
> @@ -841,7 +841,7 @@ hash_table
> entry, NULL may be returned if memory allocation fails. */
>
> template class Allocator>
> -typename Descriptor::value_type **
> +typename hash_table::value_type **
> hash_table
> ::find_slot_with_hash (const compare_type *comparable, hashval_t hash,
>enum insert_option insert)
> @@ -922,7 +922,9 @@ hash_table
>
> template class Allocator>
> template - int (*Callback) (typename Descriptor::value_type **slot, Argument
> argument)>
> + int (*Callback) (typename hash_table + false>::value_type **slot,
> + Argument argument)>
> void
> hash_table::traverse_noresize (Argument
> argument)
> {
> @@ -946,7 +948,8 @@ hash_table false>::traverse_noresize (Argument argument)
> templatetemplate class Allocator>
> template - int (*Callback) (typename Descriptor::value_type **slot,
> + int (*Callback) (typename hash_table + false>::value_type **slot,
>Argument argument)>
> void
> hash_table::traverse (Argument argument)
> @@ -1181,7 +1184,7 @@ hash_table::~hash_table ()
> HASH is the hash value for the element to be inserted. */
>
> template class Allocator>
> -typename Descriptor::value_type *
> +typename hash_table::value_type *
> hash_table
> ::find_empty_slot_for_expand (hashval_t hash)
> {
> @@ -1321,7 +1324,7 @@ hash_table::clear_slot
> (value_type *slot)
> be used to insert or delete an element. */
>
> template class Allocator>
> -typename Descriptor::value_type &
> +typename hash_table::value_type &
> hash_table
> ::find_with_hash (const compare_type &comparable, hashval_t hash)
> {
> @@ -1358,7 +1361,7 @@ hash_table
> entry, NULL may be returned if memory allocation fails. */
>
> template class Allocator>
> -typename Descriptor::value_type *
> +typename hash_table::value_type *
> hash_table
> ::find_slot_with_hash (const compare_type &comparable, hashval_t hash,
>enum insert_option insert)
> @@ -1440,7 +1443,8 @@ hash_table
> template template class Allocator>
> template - int (*Callback) (typename Descriptor::value_type *slot,
> + int (*Callback) (typename hash_table + true>::value_type *slot,
>Argument argument)>
> void
> hash_table::traverse_noresize (Argument
> argument)
> @@ -1465,7 +1469,8 @@ hash_table true>::traverse_noresize (Argument argument)
> templatetemplate class Allocator>
> template - int (*Callback) (typename Descriptor::value_type *slot,
> + int (*Callback) (typename hash_table + true>::value_type *slot,
>Argument argument)>
> void
> hash_table::traverse (Argument argument)
> --
> 2.0.1
>
Re: [PATCH] convert some hash_table to hash_map
On Tue, Jul 8, 2014 at 5:01 AM, wrote:
> From: Trevor Saunders
>
> Hi,
>
> just $subject
> bootstrapped + regtested on x86_64-unknown-linux-gnu, ok?
Ok.
Thanks,
Richard.
> Trev
>
> gcc/
>
> * graphite-htab.h: Use hash_map instead of hash_table.
> * graphite-clast-to-gimple.c: Adjust.
> * passes.c: Use hash_map instead of hash_table.
> * sese.c: Likewise.
> * sese.h: Remove now unused code.
>
> diff --git a/gcc/graphite-clast-to-gimple.c b/gcc/graphite-clast-to-gimple.c
> index 71507a0..296b893 100644
> --- a/gcc/graphite-clast-to-gimple.c
> +++ b/gcc/graphite-clast-to-gimple.c
> @@ -1012,34 +1012,16 @@ build_iv_mapping (vec iv_map, struct
> clast_user_stmt *user_stmt,
>mpz_clear (bound_two);
> }
>
> -/* Construct bb_pbb_def with BB and PBB. */
> -
> -static bb_pbb_def *
> -new_bb_pbb_def (basic_block bb, poly_bb_p pbb)
> -{
> - bb_pbb_def *bb_pbb_p;
> -
> - bb_pbb_p = XNEW (bb_pbb_def);
> - bb_pbb_p->bb = bb;
> - bb_pbb_p->pbb = pbb;
> -
> - return bb_pbb_p;
> -}
> -
> /* Mark BB with it's relevant PBB via hashing table BB_PBB_MAPPING. */
>
> static void
> mark_bb_with_pbb (poly_bb_p pbb, basic_block bb,
> bb_pbb_htab_type *bb_pbb_mapping)
> {
> - bb_pbb_def tmp;
> - bb_pbb_def **x;
> -
> - tmp.bb = bb;
> - x = bb_pbb_mapping->find_slot (&tmp, INSERT);
> -
> - if (x && !*x)
> -*x = new_bb_pbb_def (bb, pbb);
> + bool existed;
> + poly_bb_p &e = bb_pbb_mapping->get_or_insert (bb, &existed);
> + if (!existed)
> +e = pbb;
> }
>
> /* Find BB's related poly_bb_p in hash table BB_PBB_MAPPING. */
> @@ -1047,14 +1029,9 @@ mark_bb_with_pbb (poly_bb_p pbb, basic_block bb,
> poly_bb_p
> find_pbb_via_hash (bb_pbb_htab_type *bb_pbb_mapping, basic_block bb)
> {
> - bb_pbb_def tmp;
> - bb_pbb_def **slot;
> -
> - tmp.bb = bb;
> - slot = bb_pbb_mapping->find_slot (&tmp, NO_INSERT);
> -
> - if (slot && *slot)
> -return ((bb_pbb_def *) *slot)->pbb;
> + poly_bb_p *pbb = bb_pbb_mapping->get (bb);
> + if (pbb)
> +return *pbb;
>
>return NULL;
> }
> diff --git a/gcc/graphite-htab.h b/gcc/graphite-htab.h
> index 69fd05a..b1fd81e 100644
> --- a/gcc/graphite-htab.h
> +++ b/gcc/graphite-htab.h
> @@ -21,43 +21,33 @@ along with GCC; see the file COPYING3. If not see
> #ifndef GCC_GRAPHITE_HTAB_H
> #define GCC_GRAPHITE_HTAB_H
>
> -#include "hash-table.h"
> -
> -/* Stores BB's related PBB. */
> -
> -struct bb_pbb_def
> -{
> - basic_block bb;
> - poly_bb_p pbb;
> -};
> +#include "hash-map.h"
>
> /* Hashtable helpers. */
>
> -struct bb_pbb_hasher : typed_free_remove
> +struct bb_pbb_hasher : default_hashmap_traits
> {
> - typedef bb_pbb_def value_type;
> - typedef bb_pbb_def compare_type;
> - static inline hashval_t hash (const value_type *);
> - static inline bool equal (const value_type *, const compare_type *);
> + static inline hashval_t hash (const basic_block);
> + static inline bool equal_keys (const basic_block, const basic_block);
> };
>
> -/* Hash function for data base element BB_PBB. */
> +/* Hash function. */
>
> inline hashval_t
> -bb_pbb_hasher::hash (const value_type *bb_pbb)
> +bb_pbb_hasher::hash (const basic_block bb)
> {
> - return (hashval_t)(bb_pbb->bb->index);
> + return (hashval_t)(bb->index);
> }
>
> /* Compare data base element PB1 and PB2. */
>
> inline bool
> -bb_pbb_hasher::equal (const value_type *bp1, const compare_type *bp2)
> +bb_pbb_hasher::equal_keys (const basic_block a, const basic_block b)
> {
> - return (bp1->bb->index == bp2->bb->index);
> + return (a->index == b->index);
> }
>
> -typedef hash_table bb_pbb_htab_type;
> +typedef hash_map bb_pbb_htab_type;
>
> poly_bb_p find_pbb_via_hash (bb_pbb_htab_type *, basic_block);
> bool loop_is_parallel_p (loop_p, bb_pbb_htab_type *, int);
> diff --git a/gcc/passes.c b/gcc/passes.c
> index 91b644e..0533687 100644
> --- a/gcc/passes.c
> +++ b/gcc/passes.c
> @@ -84,6 +84,7 @@ along with GCC; see the file COPYING3. If not see
> #include "pass_manager.h"
> #include "tree-ssa-live.h" /* For remove_unused_locals. */
> #include "tree-cfgcleanup.h"
> +#include "hash-map.h"
>
> using namespace gcc;
>
> @@ -687,64 +688,47 @@ pass_manager::register_dump_files (opt_pass *pass)
>while (pass);
> }
>
> -struct pass_registry
> -{
> - const char* unique_name;
> - opt_pass *pass;
> -};
> -
> /* Helper for pass_registry hash table. */
>
> -struct pass_registry_hasher : typed_noop_remove
> +struct pass_registry_hasher : default_hashmap_traits
> {
> - typedef pass_registry value_type;
> - typedef pass_registry compare_type;
> - static inline hashval_t hash (const value_type *);
> - static inline bool equal (const value_type *, const compare_type *);
> + static inline hashval_t hash (const char *);
> + static inline bool equal_keys (const char *, const char *);
> };
>
> /* Pass registry hash function. */
>
> inline hashval_t
> -pass_registry_hasher::hash (const value_type *s)
> +pass_registry_hasher::h
Re: Fix representation of gcov_info_type
On Tue, Jul 8, 2014 at 2:25 AM, Jan Hubicka wrote:
>> > Index: stor-layout.c
>> > ===
>> > --- stor-layout.c (revision 212098)
>> > +++ stor-layout.c (working copy)
>> > @@ -2065,7 +2065,7 @@ void
>> > finish_builtin_struct (tree type, const char *name, tree fields,
>> >tree align_type)
>> > {
>> > - tree tail, next;
>> > + tree tail, next, variant;
>> >
>> >for (tail = NULL_TREE; fields; tail = fields, fields = next)
>> > {
>> > @@ -2074,6 +2074,10 @@ finish_builtin_struct (tree type, const
>> >DECL_CHAIN (fields) = tail;
>> > }
>> >TYPE_FIELDS (type) = tail;
>> > + for (variant = TYPE_MAIN_VARIANT (type);
>> > + variant != 0;
>> > + variant = TYPE_NEXT_VARIANT (variant))
>> > +TYPE_FIELDS (variant) = tail;
>>
>> I think that's a bogus place to fix that. Instead the caller should
>> use build_variant_type_copy. Especially that the fixup above
>> depends on all variants being added before finish_builtin_struct
>> is called.
>>
>> Please revert the above.
>
> Sorry, I missed this email at the airport. Will test revert overnight.
>
> I do not understand how you propose to fix it.
>
> The variant is produced before the builtin structure is finished and it thus
> have FIELDS and SIZE NULL (as the pointer to struct itself is field of the
> struct):
>
> /* function_info pointer pointer */
> fn_info_ptr_type = build_pointer_type
> (build_qualified_type (fn_info_ptr_type, TYPE_QUAL_CONST));
> field = build_decl (BUILTINS_LOCATION, FIELD_DECL, NULL_TREE,
> fn_info_ptr_type);
> DECL_CHAIN (field) = fields;
> fields = field;
>
> finish_builtin_struct (type, "__gcov_info", fields, NULL_TREE);
>
> which leads to build_variant_type_copy.
>
> Once the struct is finished, we need to update the variants somewhere. Same
> loop walking the variants appears in finalize_type_size that is transitively
> called by finish_builtin_struct:
>
> /* Also layout any other variants of the type. */
> if (TYPE_NEXT_VARIANT (type)
> || type != TYPE_MAIN_VARIANT (type))
> {
> tree variant;
> /* Record layout info of this variant. */
> tree size = TYPE_SIZE (type);
> tree size_unit = TYPE_SIZE_UNIT (type);
> unsigned int align = TYPE_ALIGN (type);
> unsigned int user_align = TYPE_USER_ALIGN (type);
> enum machine_mode mode = TYPE_MODE (type);
>
> /* Copy it into all variants. */
> for (variant = TYPE_MAIN_VARIANT (type);
>variant != 0;
>variant = TYPE_NEXT_VARIANT (variant))
> {
> TYPE_SIZE (variant) = size;
> TYPE_SIZE_UNIT (variant) = size_unit;
> TYPE_ALIGN (variant) = align;
> TYPE_USER_ALIGN (variant) = user_align;
> SET_TYPE_MODE (variant, mode);
> }
> }
>
> Difference to my hunk is that the code works when called on non-main variant,
> but I think it makes sense to always finish main variant of builtin structs.
> (in fact I do not see why one would finalize size on non-main variants given
> that the sizes must match either)
So the issue seems to be:
gcov_info_type = lang_hooks.types.make_type (RECORD_TYPE);
gcov_fn_info_type = lang_hooks.types.make_type (RECORD_TYPE);
gcov_fn_info_ptr_type = build_pointer_type
(build_qualified_type (gcov_fn_info_type, TYPE_QUAL_CONST));
build_fn_info_type (gcov_fn_info_type, n_counters, gcov_info_type);
build_info_type (gcov_info_type, gcov_fn_info_ptr_type);
that __gcov_info has a member of type const __gcov_info * and that
rather than using the equivalent of
struct __gcov_info;
typedef const __gcov_info *gcov_fn_info_ptr_type;
struct __gcov_info {
...
gcov_fn_info_ptr_type x;
};
we build the variant of the yet incomplete struct and complete
it later.
Sth like
Index: coverage.c
===
--- coverage.c (revision 210965)
+++ coverage.c (working copy)
@@ -1078,9 +1078,10 @@
/* Build the info and fn_info types. These are mutually recursive. */
gcov_info_type = lang_hooks.types.make_type (RECORD_TYPE);
gcov_fn_info_type = lang_hooks.types.make_type (RECORD_TYPE);
+ build_fn_info_type (gcov_fn_info_type, n_counters, gcov_info_type);
+ gcov_info_type = lang_hooks.types.make_type (RECORD_TYPE);
gcov_fn_info_ptr_type = build_pointer_type
(build_qualified_type (gcov_fn_info_type, TYPE_QUAL_CONST));
- build_fn_info_type (gcov_fn_info_type, n_counters, gcov_info_type);
build_info_type (gcov_info_type, gcov_fn_info_ptr_type);
/* Build the gcov info var, this is referred to in its own
should fix it by delaying the variant build for one case after the record
has been completed and retaining the incomplete declaration for
the pointer type.
Richard.
> What would be correct fix then?
> Honza
>
>
>>
>> Thanks,
>> Richard.
>>
>> >if (align_type)
>> >
Re: [PATCH] remove useless unused attributes in i386 code
On Mon, Jul 7, 2014 at 9:47 PM, Trevor Saunders wrote:
> On Mon, Jul 07, 2014 at 09:28:55PM +0200, Richard Biener wrote:
>> On July 7, 2014 9:06:17 PM CEST, Trevor Saunders
>> wrote:
>> >On Mon, Jul 07, 2014 at 11:46:27AM +0200, Richard Biener wrote:
>> >> On Mon, Jul 7, 2014 at 11:45 AM, Richard Biene
>> >> wrote:
>> >> > On Thu, Jul 3, 2014 at 1:08 AM, wrote:
>> >> >> From: Trevor Saunders
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> So apparently its not entirely obvious to everyone that removing
>> >the names of
>> >> >> unused arguments is the best way of dealing with warnings about
>> >unused
>> >> >> arguments in places like hooks where the argument is required for
>> >some reason.
>> >> >> Apparently this is somewhat less contravercial when the names are
>> >removed
>> >> >> consistantly throughout a section of code, so this patch does that
>> >for
>> >> >> config/i386/
>> >> >>
>> >> >> It should suprise nobody that there was a couple cases where the
>> >argument was
>> >> >> used, but still marked attribute unused.
>> >> >>
>> >> >> bootstrapped and regtested on x86_64-unknown-linux-gnu, with no
>> >regressions,
>> >> >> and a --target=i386-mingw32 run of make all-gcc completes without
>> >any unused
>> >> >> warnings. ok for trunk?
>> >> >
>> >> > Ok. Note that marked arguments but having uses is common for
>> >> > uses only in #if regions - so you might want to double-check for
>> >that
>> >> > case.
>> >>
>> >> Oh, and the proper way to annotate unused parameters is via
>> >> type ARG_UNUSED (name) because some G++ versions do not
>> >> like the unused attributes.
>> >
>> >Do you mean some g++ version warn about things like
>> >void
>> >foo (int)
>> >{
>> >}
>> >? that seems kind of crazy if so can we just suppress unused-parameter
>> >with those versions?
>>
>> No, some complain about the attribute unused variant.
>
> but just to be clear changing from
> void
> foo(int ATTRIBUTE_UNUSED x)
> to
> void
> foo (int)
> is ok?
Yes. For C code (or mixed C/C++ code) the correct way is to use
type ARG_UNUSED (name) (in C++ mode this will simply omit name).
Richard.
> Trev
>
>>
>> Richard.
>>
>> >Trev
>> >
>> >>
>> >> Richard.
>> >>
>> >> > Thanks,
>> >> > Richard.
>> >> >
>> >> >> Trev
>> >> >>
>> >> >> gcc/
>> >> >>
>> >> >> * config/i386/driver-i386.c: Remove names of unused
>> >arguments and
>> >> >> unnecessary unused attributes.
>> >> >> * config/i386/host-mingw32.c: Likewise.
>> >> >> * config/i386/i386.c: Likewise.
>> >> >> * config/i386/winnt-stubs.c: Likewise.
>> >> >> * config/i386/winnt.c: Likewise.
>> >> >>
>> >> >> diff --git a/gcc/config/i386/driver-i386.c
>> >b/gcc/config/i386/driver-i386.c
>> >> >> index 4cd0b3d..1c6385f 100644
>> >> >> --- a/gcc/config/i386/driver-i386.c
>> >> >> +++ b/gcc/config/i386/driver-i386.c
>> >> >> @@ -920,8 +920,7 @@ done:
>> >> >> -march and -mtune "native" target and will leave to the newly
>> >> >> built compiler to generate code for its default target. */
>> >> >>
>> >> >> -const char *host_detect_local_cpu (int argc ATTRIBUTE_UNUSED,
>> >> >> - const char **argv
>> >ATTRIBUTE_UNUSED)
>> >> >> +const char *host_detect_local_cpu (int, const char **)
>> >> >> {
>> >> >>return NULL;
>> >> >> }
>> >> >> diff --git a/gcc/config/i386/host-mingw32.c
>> >b/gcc/config/i386/host-mingw32.c
>> >> >> index fc01ceb..c71d25d 100644
>> >> >> --- a/gcc/config/i386/host-mingw32.c
>> >> >> +++ b/gcc/config/i386/host-mingw32.c
>> >> >> @@ -83,7 +83,7 @@ mingw32_gt_pch_alloc_granularity (void)
>> >> >> open file descriptor if the host would like to probe with
>> >mmap. */
>> >> >>
>> >> >> static void *
>> >> >> -mingw32_gt_pch_get_address (size_t size, int fd
>> >ATTRIBUTE_UNUSED)
>> >> >> +mingw32_gt_pch_get_address (size_t size, int)
>> >> >> {
>> >> >>void* res;
>> >> >>size = (size + va_granularity - 1) & ~(va_granularity - 1);
>> >> >> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>> >> >> index 8046c67..01d3f2c 100644
>> >> >> --- a/gcc/config/i386/i386.c
>> >> >> +++ b/gcc/config/i386/i386.c
>> >> >> @@ -5226,9 +5226,8 @@ x86_elf_aligned_common (FILE *file,
>> >> >> ASM_OUTPUT_ALIGNED_BSS. */
>> >> >>
>> >> >> void
>> >> >> -x86_output_aligned_bss (FILE *file, tree decl ATTRIBUTE_UNUSED,
>> >> >> - const char *name, unsigned HOST_WIDE_INT
>> >size,
>> >> >> - int align)
>> >> >> +x86_output_aligned_bss (FILE *file, tree decl, const char *name,
>> >> >> + unsigned HOST_WIDE_INT size, int align)
>> >> >> {
>> >> >>if ((ix86_cmodel == CM_MEDIUM || ix86_cmodel == CM_MEDIUM_PIC)
>> >> >>&& size > (unsigned int)ix86_section_threshold)
>> >> >> @@ -5358,7 +5357,7 @@ ix86_function_ok_for_sibcall (tree decl,
>> >tree exp)
>> >> >> static tree
>> >> >> ix86_handle_cconv_attribute (tree *node, tree name,
>> >> >>tree args,
>>
Re: [i386] Replace builtins with vector extensions
Hello Marc. On 04 Jul 21:11, Marc Glisse wrote: > On Thu, 3 Jul 2014, Kirill Yukhin wrote: > like combining 2 shuffles unless the result is the identity. And > expanding shuffles that can be done in a single instruction works > well. > > But I am happy not doing them yet. To be very specific, could you > list which intrinsics you would like to remove from the posted > patch? I am not a x86 maintainer, however while such a replacements produce correct semantics and probably enable optimizations, I support your patch. Probably you could try such your approach on AVX2, AVX-512 whose intrinsics are well covered by tests? > >On the over hand, updated in such a way intrinsic > >may actually generate different instruction then intended (e.g. FMA case). > > It is the same with scalars, we have -ffp-contract for that. Agreed. -- Thanks, K
Re: [i386] Replace builtins with vector extensions
On Tue, Jul 08, 2014 at 03:14:04PM +0400, Kirill Yukhin wrote: > > >On the over hand, updated in such a way intrinsic > > >may actually generate different instruction then intended (e.g. FMA case). > > > > It is the same with scalars, we have -ffp-contract for that. > Agreed. I don't think we actually always guarantee using the particular instructions for the intrinsics even when they are implemented using builtins, at least if they don't use UNSPECs, e.g. if combiner or peephole2 manage to combine something into some other insn, we'll happily do that. Jakub
[PATCH 4.9][AArch64] Backport 211892: PR/60825 Make float64x1_t in arm_neon.h a proper vector type
This corrects name-mangling of float64x1_t and makes it a distinct type from float64_t, as per ACLE - the error mentioned in the "Caveats" section at https://gcc.gnu.org/gcc-4.9/changes.html. (Only) Changes from the original patch are to remove references to __builtin_aarch64_im_lane_boundsi and the update to the ext_f64_1.c testcase, both of which were introduced in r211058 (http://pdtlreviewboard.cambridge.arm.com/r/1339/) which is not being backported. This means that out-of-bounds lane indices will be silently ignored (the implementation just uses lane 0) rather than raising an error message as in mainline. Also requires backporting of three other patches, adding functionality missing vs the ACLE spec, all of which apply straightforwardly with 'patch': r209559 [AArch64] vrnd<*>_f64 patch r209641 [AArch64] Vreinterpret re-implemention. r209642 [AArch64] 64-bit float vreinterpret implemention gcc/ChangeLog: Backport r211892 from mainline. 2014-06-23 Alan Lawrence PR target/60825 * config/aarch64/aarch64.c (aarch64_simd_mangle_map): Add entry for V1DFmode. * config/aarch64/aarch64-builtins.c (aarch64_simd_builtin_type_mode): add V1DFmode (BUILTIN_VD1): New. (BUILTIN_VD_RE): Remove. (aarch64_init_simd_builtins): Add V1DF to modes/modenames. (aarch64_fold_builtin): Update reinterpret patterns, df becomes v1df. * config/aarch64/aarch64-simd-builtins.def (create): Make a v1df variant but not df. (vreinterpretv1df*, vreinterpret*v1df): New. (vreinterpretdf*, vreinterpret*df): Remove. * config/aarch64/aarch64-simd.md (aarch64_create, aarch64_reinterpret*): Generate V1DFmode pattern not DFmode. * config/aarch64/iterators.md (VD_RE): Include V1DF, remove DF. (VD1): New. * config/aarch64/arm_neon.h (float64x1_t): typedef with gcc extensions. (vcreate_f64): Remove cast, use v1df builtin. (vcombine_f64): Remove cast, get elements with gcc vector extensions. (vget_low_f64, vabs_f64, vceq_f64, vceqz_f64, vcge_f64, vgfez_f64, vcgt_f64, vcgtz_f64, vcle_f64, vclez_f64, vclt_f64, vcltz_f64, vdup_n_f64, vdupq_lane_f64, vld1_f64, vld2_f64, vld3_f64, vld4_f64, vmov_n_f64, vst1_f64): Use gcc vector extensions. (vget_lane_f64, vdupd_lane_f64, vmulq_lane_f64, ): Use gcc extensions, add range check using __builtin_aarch64_im_lane_boundsi. (vfma_lane_f64, vfmad_lane_f64, vfma_laneq_f64, vfmaq_lane_f64, vfms_lane_f64, vfmsd_lane_f64, vfms_laneq_f64, vfmsq_lane_f64): Fix type signature, use gcc vector extensions. (vreinterpret_p8_f64, vreinterpret_p16_f64, vreinterpret_f32_f64, vreinterpret_f64_f32, vreinterpret_f64_p8, vreinterpret_f64_p16, vreinterpret_f64_s8, vreinterpret_f64_s16, vreinterpret_f64_s32, vreinterpret_f64_s64, vreinterpret_f64_u8, vreinterpret_f64_u16, vreinterpret_f64_u32, vreinterpret_f64_u64, vreinterpret_s8_f64, vreinterpret_s16_f64, vreinterpret_s32_f64, vreinterpret_s64_f64, vreinterpret_u8_f64, vreinterpret_u16_f64, vreinterpret_u32_f64, vreinterpret_u64_f64): Use v1df builtin not df. gcc/testsuite/ChangeLog: Backport r211892 from mainline. 2014-06-23 Alan Lawrence PR target/60825 * g++.dg/abi/mangle-neon-aarch64.C: Also test mangling of float64x1_t. * gcc.target/aarch64/aapcs/test_64x1_1.c: New test. * gcc.target/aarch64/aapcs/func-ret-64x1_1.c: New test. * gcc.target/aarch64/simd/ext_f64_1.c (main): Compare vector elements. * gcc.target/aarch64/vadd_f64.c: Rewrite with macro to use vector types. * gcc.target/aarch64/vsub_f64.c: Likewise. * gcc.target/aarch64/vdiv_f.c (INDEX*, RUN_TEST): Remove indexing scheme as now the same for all variants. * gcc.target/aarch64/vrnd_f64_1.c (compare_f64): Return float64_t not float64x1_t.diff --git a/gcc/config/aarch64/aarch64-builtins.c b/gcc/config/aarch64/aarch64-builtins.c index 591260f18bcc084bcc6cc16b6597a3d2ec098d05..4ac3d1f6683a1b6ad6bdd8521061f9743cbf34d9 100644 --- a/gcc/config/aarch64/aarch64-builtins.c +++ b/gcc/config/aarch64/aarch64-builtins.c @@ -53,6 +53,7 @@ enum aarch64_simd_builtin_type_mode T_V4HI, T_V2SI, T_V2SF, + T_V1DF, T_DI, T_DF, T_V16QI, @@ -76,6 +77,7 @@ enum aarch64_simd_builtin_type_mode #define v4hi_UP T_V4HI #define v2si_UP T_V2SI #define v2sf_UP T_V2SF +#define v1df_UP T_V1DF #define di_UPT_DI #define df_UPT_DF #define v16qi_UP T_V16QI @@ -317,6 +319,8 @@ aarch64_types_store1_qualifiers[SIMD_MAX_BUILTIN_ARGS] VAR2 (T, N, MAP, v8qi, v16qi) #define BUILTIN_VD(T, N, MAP) \ VAR4 (T, N, MAP, v8qi, v4hi, v2si, v2sf) +#define BUILTIN_VD1(T, N, MAP) \ + VAR5 (T, N, MAP, v8qi, v4hi, v2si, v2sf, v1df) #define BUILTIN_VDC(T, N, MAP) \ VAR6 (T, N, MAP, v8qi, v
Re: [PATCH 4.9][ARM] Backport r211369 PR/61062 Fix arm_neon.h ZIP/UZP/TRN for Bigendian
On Tue, Jul 8, 2014 at 10:59 AM, Alan Lawrence wrote: > No regressions on arm-none-eabi or armeb-none-eabi; also FAIL->PASS on local > copies of the execution-result tests in gcc.target/arm/simd tests (taken > from mainline, these are not present in 4.9). Ok unless an RM objects. I suspect the pr48252 fix is enough for test coverage for these on big endian. regards Ramana > > gcc/ChangeLog: > > PR target/61062 > Backport r211369 from mainline. > 2014-06-09 Alan Lawrence > > * config/arm/arm_neon.h (vtrn_s8, vtrn_s16, vtrn_u8, vtrn_u16, > vtrn_p8, > vtrn_p16, vtrn_s32, vtrn_f32, vtrn_u32, vtrnq_s8, vtrnq_s16, > vtrnq_s32, > vtrnq_f32, vtrnq_u8, vtrnq_u16, vtrnq_u32, vtrnq_p8, vtrnq_p16, > vzip_s8, > vzip_s16, vzip_u8, vzip_u16, vzip_p8, vzip_p16, vzip_s32, vzip_f32, > vzip_u32, vzipq_s8, vzipq_s16, vzipq_s32, vzipq_f32, vzipq_u8, > vzipq_u16, vzipq_u32, vzipq_p8, vzipq_p16, vuzp_s8, vuzp_s16, > vuzp_s32, > vuzp_f32, vuzp_u8, vuzp_u16, vuzp_u32, vuzp_p8, vuzp_p16, vuzpq_s8, > vuzpq_s16, vuzpq_s32, vuzpq_f32, vuzpq_u8, vuzpq_u16, vuzpq_u32, > vuzpq_p8, vuzpq_p16): Correct mask for bigendian. > > gcc/testsuite/ChangeLog: > > PR target/61062 > Backport r211369 from mainline. > 2014-06-09 Alan Lawrence > > *gcc.target/arm/pr48252.c (main): Expect same result as > endian-neutral. > > Ok?
Re: [PATCH 4.9 ARM] Backport r210219: "Neon Intrinsics TLC - remove ML"
On Mon, Jun 23, 2014 at 11:05 AM, Alan Lawrence wrote: > As for 4.8, I'm intending to backport the ZIP/UZP/TRN fix for ARM big-endian > in r211369 of mainline. That patches arm_neon.h, so again we need to remove > the OCAML code by which that file is autogenerated...ok? Ok Makes life with backports for any fixes to neon intrinsics easier, therefore OK unless an RM objects in 24 hours. Ramana > > --Alan
Re: [PATCH][ARM/AArch64 Testsuite] Fix vext[us]64_1.c test on ARM by unsharing test body
On Thu, Jul 3, 2014 at 4:08 PM, Alan Lawrence wrote: > Moving into own thread from > https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01895.html > > This fixes the compilation failures of gcc.target/arm/simd/vexts64_1.c and > gcc.target/arm/simd/vextu64_1.c that I introduced in r by unsharing the test > body on AArch64. (As [u]int64x1_t are vector types on AArch64 but scalar > types on ARM.) > > gcc/testsuite/ChangeLog: > > * gcc.target/arm/simd/vexts64_1.c: Remove #include, inline test > body. > * gcc.target/arm/simd/vextu64_1.c: Likewise. > * gcc.target/aarch64/simd/ext_s64_1.c: Likewise. > * gcc.target/aarch64/simd/ext_u64_1.c: Likewise. > * gcc.target/aarch64/simd/ext_s64.x: Remove. > * gcc.target/aarch64/simd/ext_u64.x: Remove. Ok - sigh. Ramana > > On arm-none-eabi > (arm-eabi-aem/-mthumb/-march=armv8-a/-mfpu=crypto-neon-fp-armv8/-mfloat-abi=hard): > > FAIL->PASS: gcc.target/arm/simd/vexts64_1.c (test for excess errors) > UNRESOLVED->NA: gcc.target/arm/simd/vexts64_1.c compilation failed to > produce executable > NA->PASS: gcc.target/arm/simd/vexts64_1.c execution test > FAIL->PASS: gcc.target/arm/simd/vextu64_1.c (test for excess errors) > UNRESOLVED->NA: gcc.target/arm/simd/vextu64_1.c compilation failed to > produce executable > NA->PASS: gcc.target/arm/simd/vextu64_1.c execution test > > No changes on aarch64-none-elf.
Re: [PATCH 4.9][AArch64] Backport 211892: PR/60825 Make float64x1_t in arm_neon.h a proper vector type
On Tue, Jul 08, 2014 at 12:28:54PM +0100, Alan Lawrence wrote: > This corrects name-mangling of float64x1_t and makes it a distinct type from > float64_t, as per ACLE - the error mentioned in the "Caveats" section at > https://gcc.gnu.org/gcc-4.9/changes.html. > > (Only) Changes from the original patch are to remove references to > __builtin_aarch64_im_lane_boundsi and the update to the ext_f64_1.c > testcase, both of which were introduced in r211058 > (http://pdtlreviewboard.cambridge.arm.com/r/1339/) which is not being > backported. This means that out-of-bounds lane indices will be silently > ignored (the implementation just uses lane 0) rather than raising an error > message as in mainline. If any of the changes are ABI changes, then IMHO we shouldn't apply it to release branch, better keep 4.9.0 ABI compatible with 4.9.1. Jakub
Re: [GOMP4, RFC] OpenMP4 offload support for Intel PHI targets.
Hello, We recently checked into gomp4-offload branch fix allowing bootstrap to pass as well as fix for disabling multilib for liboffloadmic (64-bit only). -- Thanks, K
Re: [PATCH 4.9][AArch64] Backport 211892: PR/60825 Make float64x1_t in arm_neon.h a proper vector type
On 8 July 2014 12:39, Jakub Jelinek wrote: > On Tue, Jul 08, 2014 at 12:28:54PM +0100, Alan Lawrence wrote: >> This corrects name-mangling of float64x1_t and makes it a distinct type from >> float64_t, as per ACLE - the error mentioned in the "Caveats" section at >> https://gcc.gnu.org/gcc-4.9/changes.html. >> >> (Only) Changes from the original patch are to remove references to >> __builtin_aarch64_im_lane_boundsi and the update to the ext_f64_1.c >> testcase, both of which were introduced in r211058 >> (http://pdtlreviewboard.cambridge.arm.com/r/1339/) which is not being >> backported. This means that out-of-bounds lane indices will be silently >> ignored (the implementation just uses lane 0) rather than raising an error >> message as in mainline. > > If any of the changes are ABI changes, then IMHO we shouldn't apply it to > release branch, better keep 4.9.0 ABI compatible with 4.9.1. > > Jakub The three patches Alan's change depends on are not ABI changing. Alan's patch in itself is ABI changing. This patch breaks mangling, the following patch which I believe Alan is about to post fixes the intx1 vectors which causes a change in parameter passing convetion. As Alan pointed out in his patch submission, the issue was called out for 4.9.0 here: >> float64_t, as per ACLE - the error mentioned in the "Caveats" section at >> https://gcc.gnu.org/gcc-4.9/changes.html. ... along with a statement that this would be fixed Clearly the ABI change between 4.9.0 and 4.9.1 is not ideal, however the X1 vectors are relatively corner case. Given that this a relatively new port and we don;t expect many folks to be using this type in production yet. A number of folk are waiting on 4.9.1 before they switch to 4.9, some of those folks are likely to be users of the intrinsics and x1 vectors. I'd like to see these changes taken now between 4.9.0 and 4.9.1 rather than take the pain between 4.9.x and 4.10 when we will have a significantly bigger deployed user base. Cheers /Marcus
Re: [PATCH][AArch64] Implement vfma_f64, vmla_f64, vfms_f64, vmls_f64 intrinsics
Ping^2 https://gcc.gnu.org/ml/gcc-patches/2014-06/msg02399.html Kyrill On 20/06/14 15:17, Kyrill Tkachov wrote: Hi all, Now that Alan fixed the float64x1_t machinery, this patch implements some low-hanging intrinsics in arm_neon.h. Tested aarch64-none-elf and bootstrapped on aarch64-linux. Ok for trunk? Thanks, Kyrill 2014-06-20 Kyrylo Tkachov * config/aarch64/arm_neon.h (vfma_f64): New intrinsic. (vmla_f64): Likewise. (vfms_f64): Likewise. (vmls_f64): Likewise. 2014-06-20 Kyrylo Tkachov * gcc.target/aarch64/simd/vfma_f64.c: New test. * gcc.target/aarch64/simd/vmla_f64.c: Likewise. * gcc.target/aarch64/simd/vfms_f64.c: Likewise. * gcc.target/aarch64/simd/vmls_f64.c: Likewise.
Re: [PATCH 4.9][AArch64] Backport 211892: PR/60825 Make float64x1_t in arm_neon.h a proper vector type
On Tue, Jul 08, 2014 at 01:08:27PM +0100, Marcus Shawcroft wrote: > >> float64_t, as per ACLE - the error mentioned in the "Caveats" section at > >> https://gcc.gnu.org/gcc-4.9/changes.html. > > ... along with a statement that this would be fixed > > Clearly the ABI change between 4.9.0 and 4.9.1 is not ideal, however > the X1 vectors are relatively corner case. Given that this a > relatively new port and we don;t expect many folks to be using this > type in production yet. A number of folk are waiting on 4.9.1 before > they switch to 4.9, some of those folks are likely to be users of the > intrinsics and x1 vectors. I'd like to see these changes taken now > between 4.9.0 and 4.9.1 rather than take the pain between 4.9.x and > 4.10 when we will have a significantly bigger deployed user base. Many people are using different patch levels interchangeably and expect them to be compatible. If X1 vectors are relatively rare, the better, fewer people will be affected when switching from 4.9.x to 4.10.x. But IMHO changing ABI between patchlevels, at least when the ABI is not inconsistent (we had in the past cases where e.g. caller and callee didn't agree where to pass some argument even when using the same compiler, then obviously no working code can use those and it can be fixed), is a very bad idea. My strong preference is to maintain ABI compatibility between patchlevel versions. Just add a -Wps-abi warning to 4.10 when you encounter this (look at what e.g. x86_64 does). You can also add a warning to 4.9.1 that next GCC version will change ABI for passing those. Jakub
Re: [GSoC] generation of Gimple loops with empty bodies
> Surprising. Is the symbol defined in libisl.so? You could use objdump to
> check?
If I am not mistaken, objdump shows that libisl.so contains it.
objdump -d libisl.so.10.2.2 | grep isl_ast_expr_get_val
00060380 :
60383: 74 4b je 603d0
60389: 75 0d jne60398 Index: gcc/graphite-isl-ast-to-gimple.c
===
--- gcc/graphite-isl-ast-to-gimple.c(revision 212294)
+++ gcc/graphite-isl-ast-to-gimple.c(working copy)
@@ -42,16 +42,549 @@
#include "cfgloop.h"
#include "tree-data-ref.h"
#include "sese.h"
+#include "tree-ssa-loop-manip.h"
+#include "tree-scalar-evolution.h"
+#include
#ifdef HAVE_cloog
#include "graphite-poly.h"
#include "graphite-isl-ast-to-gimple.h"
+#include "graphite-htab.h"
/* This flag is set when an error occurred during the translation of
ISL AST to Gimple. */
static bool graphite_regenerate_error;
+/* We always use signed 128, until isl is able to give information about
+types */
+
+static tree *graphite_expression_size_type = &int128_integer_type_node;
+
+/* Converts a GMP constant VAL to a tree and returns it. */
+
+static tree
+gmp_cst_to_tree (tree type, mpz_t val)
+{
+ tree t = type ? type : integer_type_node;
+ mpz_t tmp;
+
+ mpz_init (tmp);
+ mpz_set (tmp, val);
+ wide_int wi = wi::from_mpz (t, tmp, true);
+ mpz_clear (tmp);
+
+ return wide_int_to_tree (t, wi);
+}
+
+/* Verifies properties that GRAPHITE should maintain during translation. */
+
+static inline void
+graphite_verify (void)
+{
+#ifdef ENABLE_CHECKING
+ verify_loop_structure ();
+ verify_loop_closed_ssa (true);
+#endif
+}
+
+/* The comparison function for ivs_params_map */
+
+struct id_comp
+{
+ bool operator()(isl_id *id1, isl_id *id2) const
+ {
+const char *name1 = isl_id_get_name (id1);
+const char *name2 = isl_id_get_name (id2);
+return strcmp (name1, name2) == 0;
+ }
+};
+
+/* IVS_PARAMS_MAP maps ISL's scattering and parameter identifiers
+ to corresponding trees. */
+
+typedef struct ivs_params {
+ std::map ivs_params_map;
+ sese region;
+} *ivs_params_p;
+
+/* Free all memory allocated for ISL's identifiers. */
+
+void ivs_params_clear (ivs_params_p ip)
+{
+ std::map::iterator it;
+ for (it = ip->ivs_params_map.begin (); it != ip->ivs_params_map.end (); it++)
+{
+ isl_id_free (it->first);
+}
+}
+
+static tree
+gcc_expression_from_isl_expression (tree type, __isl_keep isl_ast_expr *,
+ ivs_params_p ip);
+
+/* Returns the tree variable from the name of isl_id, which is stored
+ in the isl_ast_expr EXPR_ID that was given in ISL representation. */
+
+static tree
+gcc_expression_from_isl_ast_expr_id (__isl_keep isl_ast_expr *expr_id,
+ivs_params_p ip)
+{
+ gcc_assert (isl_ast_expr_get_type (expr_id) == isl_ast_expr_id);
+ isl_id *tmp_isl_id = isl_ast_expr_get_id (expr_id);
+ std::map::iterator res;
+ res = ip->ivs_params_map.find (tmp_isl_id);
+ isl_id_free (tmp_isl_id);
+ gcc_assert (res != ip->ivs_params_map.end ());
+ return res->second;
+}
+
+/* Converts a isl_ast_expr_int expression E to a GCC expression tree of
+ type TYPE. */
+
+static tree
+gcc_expression_from_isl_expr_int (tree type, __isl_keep isl_ast_expr *expr)
+{
+ gcc_assert (isl_ast_expr_get_type (expr) == isl_ast_expr_int);
+ isl_int val;
+ isl_int_init (val);
+ if (isl_ast_expr_get_int (expr, &val) == -1)
+{
+ isl_int_clear (val);
+ return NULL_TREE;
+}
+ else
+return gmp_cst_to_tree (type, val);
+}
+
+/* Converts a binary isl_ast_expr_op expression E to a GCC expression tree of
+ type TYPE. */
+
+static tree
+binary_op_to_tree (tree type, __isl_keep isl_ast_expr *expr, ivs_params_p ip)
+{
+ isl_ast_expr *arg_expr = isl_ast_expr_get_op_arg (expr, 0);
+ tree tree_lhs_expr = gcc_expression_from_isl_expression (type, arg_expr, ip);
+ isl_ast_expr_free (arg_expr);
+ arg_expr = isl_ast_expr_get_op_arg (expr, 1);
+ tree tree_rhs_expr = gcc_expression_from_isl_expression (type, arg_expr, ip);
+ isl_ast_expr_free (arg_expr);
+ switch (isl_ast_expr_get_op_type (expr))
+{
+case isl_ast_op_add:
+ return fold_build2 (PLUS_EXPR, type, tree_lhs_expr, tree_rhs_expr);
+
+case isl_ast_op_sub:
+ return fold_build2 (MINUS_EXPR, type, tree_lhs_expr, tree_rhs_expr);
+
+case isl_ast_op_mul:
+ return fold_build2 (MULT_EXPR, type, tree_lhs_expr, tree_rhs_expr);
+
+case isl_ast_op_div:
+ return fold_build2 (EXACT_DIV_EXPR, type, tree_lhs_expr, tree_rhs_expr);
+
+case isl_ast_op_fdiv_q:
+ return fold_build2 (FLOOR_DIV_EXPR, type, tree_lhs_expr, tree_rhs_expr);
+
+case isl_ast_op_and:
+ return fold_build2 (TRUTH_ANDIF_EXPR, type,
+ tree_lhs_expr, tree_rhs_expr);
+
+case isl_ast_op_or:
+ return fold_build2 (TRUTH_ORIF_EXPR, type, tree_lhs_expr, tree_rhs_expr);
+
+case isl_ast_op_e
[RFC PATCH] -Wmemset-transposed-args (PR middle-end/61294)
Hi!
This is an attempt to move the warning about transposed memset arguments
from the glibc headers to gcc FEs. The problem with the warning in glibc
is that it uses __builtin_constant_p and e.g. jump threading very often
makes the warning trigger even on code where it is very unlikely a user
swapped arguments. See e.g.
https://gcc.gnu.org/PR51744
https://gcc.gnu.org/PR56977
https://gcc.gnu.org/PR61294
https://bugzilla.redhat.com/452219
https://bugs.kde.org/show_bug.cgi?id=311098
https://bugzilla.mozilla.org/show_bug.cgi?id=581227
and many others. Thus, I'd like to warn in the FEs instead, and
once we have a GCC release with that warning in, disable the glibc
bits/string3.h:
if (__builtin_constant_p (__len) && __len == 0
&& (!__builtin_constant_p (__ch) || __ch != 0))
{
__warn_memset_zero_len ();
return __dest;
}
warning for GCC versions with that new warning in.
Any thoughts on this?
If you are ok with it, either we can add it only for 4.10/5.0 and
later only, or perhaps 4.9.2 too, or even 4.9.1. For -D_FORTIFY_SOURCE=2
built code with glibc it shouldn't make a difference (other than having
fewer false positives), but for other non-fortified -Wall compilation
it would make a difference (introducing new warnings), so perhaps
doing it only for 4.10/5.0+ is best.
2014-07-08 Jakub Jelinek
PR middle-end/61294
gcc/c-family/
* c.opt (Wmemset-transposed-args): New warning.
gcc/c/
* c-typeck.c (c_build_function_call_vec): Handle
-Wmemset-transposed-args.
gcc/cp/
* semantics.c (finish_call_expr): Handle -Wmemset-transposed-args.
gcc/
* doc/invoke.texi (-Wmemset-transposed-args): Document.
gcc/testsuite/
* c-c++-common/Wmemset-transposed-args1.c: New test.
* g++.dg/warn/Wmemset-transposed-args-1.C: New test.
--- gcc/c-family/c.opt.jj 2014-07-07 10:39:43.0 +0200
+++ gcc/c-family/c.opt 2014-07-08 13:12:07.755536537 +0200
@@ -518,6 +518,10 @@ Wmain
LangEnabledBy(C ObjC C++ ObjC++,Wpedantic, 2, 0)
;
+Wmemset-transposed-args
+C ObjC C++ ObjC++ Var(warn_memset_transposed_args) Warning LangEnabledBy(C
ObjC C++ ObjC++,Wall)
+Warn about suspicious call to memset where the third argument is constant zero
and second is not zero
+
Wmissing-braces
C ObjC C++ ObjC++ Var(warn_missing_braces) Warning LangEnabledBy(C ObjC,Wall)
Warn about possibly missing braces around initializers
--- gcc/c/c-typeck.c.jj 2014-07-07 10:39:43.0 +0200
+++ gcc/c/c-typeck.c2014-07-08 13:22:36.846564329 +0200
@@ -2987,6 +2987,16 @@ c_build_function_call_vec (location_t lo
/* Convert anything with function type to a pointer-to-function. */
if (TREE_CODE (function) == FUNCTION_DECL)
{
+ if (warn_memset_transposed_args
+ && DECL_BUILT_IN_CLASS (function) == BUILT_IN_NORMAL
+ && DECL_FUNCTION_CODE (function) == BUILT_IN_MEMSET
+ && vec_safe_length (params) == 3
+ && integer_zerop ((*params)[2])
+ && !integer_zerop ((*params)[1]))
+ warning_at (loc, OPT_Wmemset_transposed_args,
+ "% used with constant zero length parameter; "
+ "this could be due to transposed parameters");
+
/* Implement type-directed function overloading for builtins.
resolve_overloaded_builtin and targetm.resolve_overloaded_builtin
handle all the type checking. The result is a complete expression
--- gcc/cp/semantics.c.jj 2014-07-02 09:04:13.0 +0200
+++ gcc/cp/semantics.c 2014-07-08 14:02:45.936782580 +0200
@@ -2361,6 +2361,18 @@ finish_call_expr (tree fn, vec used with constant zero length parameter; "
+"this could be due to transposed parameters");
+
/* A call to a namespace-scope function. */
result = build_new_function_call (fn, args, koenig_p, complain);
}
--- gcc/doc/invoke.texi.jj 2014-07-08 11:36:14.0 +0200
+++ gcc/doc/invoke.texi 2014-07-08 14:20:09.932799699 +0200
@@ -257,8 +257,8 @@ Objective-C and Objective-C++ Dialects}.
-Wno-int-to-pointer-cast -Wno-invalid-offsetof @gol
-Winvalid-pch -Wlarger-than=@var{len} -Wunsafe-loop-optimizations @gol
-Wlogical-op -Wlogical-not-parentheses -Wlong-long @gol
--Wmain -Wmaybe-uninitialized -Wmissing-braces -Wmissing-field-initializers
@gol
--Wmissing-include-dirs @gol
+-Wmain -Wmaybe-uninitialized -Wmemset-transposed-args -Wmissing-braces @gol
+-Wmissing-field-initializers -Wmissing-include-dirs @gol
-Wno-multichar -Wnonnull -Wno-overflow -Wopenmp-simd @gol
-Woverlength-strings -Wpacked -Wpacked-bitfield-compat -Wpadded @gol
-Wparentheses -Wpedantic-ms-format -Wno-pedantic-ms-format @gol
@@ -4683,6 +4683,15 @@ Warn when the @code{sizeof} operator is
declared as an array in a function definition. This warning is enabled by
default for C and C++ programs.
+@item -Wmemset-transposed-args
+@opindex Wmemset-transposed-args
+@opindex Wno-memset-transposed-args
+Warn for suspicious calls to
Re: [GSoC] Addition of __isl_give to declarations
> The ChangeLog should be per-function. Otherwise LGTM. I've fixed this. -- Cheers, Roman Gareev 2014-07-04 Roman Gareev gcc/ * graphite-isl-ast-to-gimple.c (generate_isl_context): Add __isl_give to the declaration. (generate_isl_schedule): Likewise. (scop_to_isl_ast): Likewise.
Re: [GSoC] Addition of __isl_give to declarations
On 08/07/2014 14:52, Roman Gareev wrote: The ChangeLog should be per-function. Otherwise LGTM. I've fixed this. OK, LGTM then. Tobias
Re: [PATCH][ARM] Cortex-A5 rtx costs table
On 07/07/14 12:01, Kyrill Tkachov wrote: > Hi all, > > This patch adds the rtx costs table for the Cortex-A5 core. > Tested arm-none-eabi and looked at the codegen for various codebases to > make sure there's no regression in code quality. > > Ok for trunk? > > Thanks, > Kyrill > > 2014-07-07 Kyrylo Tkachov > > * config/arm/arm.c (cortexa5_extra_costs): New table. > (arm_cortex_a5_tune): Use cortexa5_extra_costs. > OK. R.
Re: [GSoC] generation of Gimple loops with empty bodies
On 08/07/2014 14:47, Roman Gareev wrote:
Surprising. Is the symbol defined in libisl.so? You could use objdump to
>check?
If I am not mistaken, objdump shows that libisl.so contains it.
objdump -d libisl.so.10.2.2 | grep isl_ast_expr_get_val
00060380 :
60383: 74 4b je 603d0
60389: 75 0d jne60398
I would use -x to see the headers. This should tell you if it is defined
or only used there.
+#include "graphite-htab.h"
Is this still needed?
(Just a question, no need to act on it if it is still needed)
+struct id_comp
+{
+ bool operator()(isl_id *id1, isl_id *id2) const
+ {
+const char *name1 = isl_id_get_name (id1);
+const char *name2 = isl_id_get_name (id2);
+return strcmp (name1, name2) == 0;
+ }
+};
No need to provide this. Comparing by pointer should be fine.
+
+/* IVS_PARAMS_MAP maps ISL's scattering and parameter identifiers
+ to corresponding trees. */
+typedef struct ivs_params {
+ std::map ivs_params_map;
What about calling it isl_id_to_tree?
+ sese region;
Is this region needed?
+static tree
+gcc_expression_from_isl_expression (tree type, __isl_keep isl_ast_expr *,
+ ivs_params_p ip);
I would make those functions __isl_take the expression.
+
+/* Returns the tree variable from the name of isl_id, which is stored
+ in the isl_ast_expr EXPR_ID that was given in ISL representation. */
This takes a couple of turns. What about:
"Return the tree variable that corresponds to the given isl ast identifier
expression (an isl_ast_expr of type isl_ast_expr_id)."
+
+static tree
+gcc_expression_from_isl_ast_expr_id (__isl_keep isl_ast_expr *expr_id,
+ivs_params_p ip)
+{
+ gcc_assert (isl_ast_expr_get_type (expr_id) == isl_ast_expr_id);
+ isl_id *tmp_isl_id = isl_ast_expr_get_id (expr_id);
+ std::map::iterator res;
+ res = ip->ivs_params_map.find (tmp_isl_id);
+ isl_id_free (tmp_isl_id);
+ gcc_assert (res != ip->ivs_params_map.end ());
Maybe add an assert message ala "Could not map isl_id to tree expression"?
+ return res->second;
+}
+
+/* Converts a isl_ast_expr_int expression E to a GCC expression tree of
Converts _aN_ isl_ast_expr_int ...
+ type TYPE. */
+
+static tree
+gcc_expression_from_isl_expr_int (tree type, __isl_keep isl_ast_expr *expr)
+{
+ gcc_assert (isl_ast_expr_get_type (expr) == isl_ast_expr_int);
+ isl_int val;
+ isl_int_init (val);
+ if (isl_ast_expr_get_int (expr, &val) == -1)
+{
+ isl_int_clear (val);
Sorry, but this still needs to be debugged. :-( I am too busy to do it
myself, so i am afraid you may just need to dig into it yourself. :-(
+/* Converts a binary isl_ast_expr_op expression E to a GCC expression tree of
+ type TYPE. */
+
+static tree
+binary_op_to_tree (tree type, __isl_keep isl_ast_expr *expr, ivs_params_p ip)
+{
+ isl_ast_expr *arg_expr = isl_ast_expr_get_op_arg (expr, 0);
+ tree tree_lhs_expr = gcc_expression_from_isl_expression (type, arg_expr, ip);
+ isl_ast_expr_free (arg_expr);
If the from_isl_expression functions become __isl_take this free becomes
unnecessary.
+/* Converts a isl_ast_expr_op expression E with unknown number of arguments
Converts _an_ isl
+/* Converts an isl_ast_expr_op expression E to a GCC expression tree of
+ type TYPE. */
+
+static tree
+gcc_expression_from_isl_expr_op (tree type, __isl_keep isl_ast_expr *expr,
+ivs_params_p ip)
+{
+ gcc_assert (isl_ast_expr_get_type (expr) == isl_ast_expr_op);
+ switch (isl_ast_expr_get_op_type (expr))
+{
+/* These isl ast expressions are not supported yet. */
+case isl_ast_op_error:
+case isl_ast_op_call:
+case isl_ast_op_and_then:
+case isl_ast_op_or_else:
+case isl_ast_op_pdiv_q:
+case isl_ast_op_pdiv_r:
+case isl_ast_op_select:
+ gcc_unreachable ();
+
+case isl_ast_op_max:
+case isl_ast_op_min:
+ return nary_op_to_tree (type, expr, ip);
+
+case isl_ast_op_add:
+case isl_ast_op_sub:
+case isl_ast_op_mul:
+case isl_ast_op_div:
+case isl_ast_op_fdiv_q:
+case isl_ast_op_and:
+case isl_ast_op_or:
+case isl_ast_op_eq:
+case isl_ast_op_le:
+case isl_ast_op_lt:
+case isl_ast_op_ge:
+case isl_ast_op_gt:
+ return binary_op_to_tree (type, expr, ip);
+
+case isl_ast_op_minus:
+ return unary_op_to_tree (type, expr, ip);
+
+case isl_ast_op_cond:
+ return ternary_op_to_tree (type, expr, ip);
+
+default:
+ gcc_unreachable ();
+}
+
+ return NULL_TREE;
+}
+
+/* Converts a ISL AST expression E back to a GCC expression tree of
_an_
+/* We use this function to get the upper bound because of the form,
+ which is used by isl to represent loops:
+
+ for (iterator = init; cond; iterator += inc)
+
+ {
+
+ ...
+
+ }
+
+ The loop condition is an arbitrary expression, which contains the
+ current loop iterator
[patch] Some small libstdc++ fixes
A fix and some minor tweaks. Tested x86_64-linux, committed to trunk.
commit 7f2475d59cc4ca4729341021e8b418ca77f7ccb2
Author: Jonathan Wakely
Date: Tue Jul 8 13:33:02 2014 +0100
* include/bits/allocated_ptr.h (__allocated_ptr::operator=): Add
missing return.
* include/experimental/any: Remove unused header.
* include/std/functional (_Maybe_wrap_member_pointer): Fix comments.
* testsuite/experimental/any/misc/any_cast_neg.cc: Adjust dg-error.
* testsuite/util/testsuite_regex.h: Move include guard.
diff --git a/libstdc++-v3/include/bits/allocated_ptr.h b/libstdc++-v3/include/bits/allocated_ptr.h
index 5cdce20..4ae3836 100644
--- a/libstdc++-v3/include/bits/allocated_ptr.h
+++ b/libstdc++-v3/include/bits/allocated_ptr.h
@@ -73,7 +73,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
/// Release ownership of the owned pointer
- __allocated_ptr& operator=(std::nullptr_t) noexcept { _M_ptr = nullptr; }
+ __allocated_ptr&
+ operator=(std::nullptr_t) noexcept
+ {
+ _M_ptr = nullptr;
+ return *this;
+ }
/// Get the address that the owned pointer refers to.
value_type* get() { return _S_raw_ptr(_M_ptr); }
diff --git a/libstdc++-v3/include/experimental/any b/libstdc++-v3/include/experimental/any
index 8f6e372..a69d006 100644
--- a/libstdc++-v3/include/experimental/any
+++ b/libstdc++-v3/include/experimental/any
@@ -41,7 +41,6 @@
#include
#include
#include
-#include
namespace std _GLIBCXX_VISIBILITY(default)
{
diff --git a/libstdc++-v3/include/std/functional b/libstdc++-v3/include/std/functional
index e677c24..15247bf 100644
--- a/libstdc++-v3/include/std/functional
+++ b/libstdc++-v3/include/std/functional
@@ -1184,8 +1184,8 @@ _GLIBCXX_HAS_NESTED_TYPE(result_type)
/**
* Maps member pointers into instances of _Mem_fn but leaves all
- * other function objects untouched. Used by tr1::bind(). The
- * primary template handles the non--member-pointer case.
+ * other function objects untouched. Used by std::bind(). The
+ * primary template handles the non-member-pointer case.
*/
template
struct _Maybe_wrap_member_pointer
@@ -1203,7 +1203,7 @@ _GLIBCXX_HAS_NESTED_TYPE(result_type)
/**
* Maps member pointers into instances of _Mem_fn but leaves all
- * other function objects untouched. Used by tr1::bind(). This
+ * other function objects untouched. Used by std::bind(). This
* partial specialization handles the member pointer case.
*/
template
diff --git a/libstdc++-v3/testsuite/experimental/any/misc/any_cast_neg.cc b/libstdc++-v3/testsuite/experimental/any/misc/any_cast_neg.cc
index b93b039..9a12ec3 100644
--- a/libstdc++-v3/testsuite/experimental/any/misc/any_cast_neg.cc
+++ b/libstdc++-v3/testsuite/experimental/any/misc/any_cast_neg.cc
@@ -26,5 +26,5 @@ void test01()
using std::experimental::any_cast;
const any y(1);
- any_cast(y); // { dg-error "qualifiers" "" { target { *-*-* } } 381 }
+ any_cast(y); // { dg-error "qualifiers" "" { target { *-*-* } } 380 }
}
diff --git a/libstdc++-v3/testsuite/util/testsuite_regex.h b/libstdc++-v3/testsuite/util/testsuite_regex.h
index c2031e9..da20941 100644
--- a/libstdc++-v3/testsuite/util/testsuite_regex.h
+++ b/libstdc++-v3/testsuite/util/testsuite_regex.h
@@ -19,13 +19,13 @@
//
Re: [Patch AArch64_be] Fix some vec_concat big-endian confusions
On Mon, Jul 07, 2014 at 05:23:28PM +0100, James Greenhalgh wrote: > On Fri, Jul 04, 2014 at 03:45:10PM +0100, Marcus Shawcroft wrote: > > On 24 June 2014 09:45, James Greenhalgh wrote: > > > > > 2014-06-20 James Greenhalgh > > > > > > * config/aarch64/aarch64-simd.md (move_lo_quad_internal_): > > > New. > > > (move_lo_quad_internal_be_): Likewise. > > > (move_lo_quad_): Convert to define_expand. > > > (aarch64_simd_move_hi_quad_): Gate on BYTES_BIG_ENDIAN. > > > (aarch64_simd_move_hi_quad_be_): New. > > > (move_hi_quad_): Use appropriate insn for BYTES_BIG_ENDIAN. > > > (aarch64_combinez): Gate on BYTES_BIG_ENDIAN. > > > (aarch64_combinez_be): New. > > > (aarch64_combine): Convert to define_expand. > > > (aarch64_combine_internal): New. > > > (aarch64_simd_combine): Remove bogus RTL description. > > > > OK... and back port to 4.9 please? > > > > The backport applies cleanly and there are no regressions for aarch64-none-elf > or aarch64_be-none-elf in the testsuite. > > Jakub, I know you were planning a 4.9.1 release soon, is this patch OK to > port to gcc-4_9-branch now, or would you prefer I wait? > Jakub on IRC said: generally, unless the release branch is frozen, target maintainers can ack backports to the release branches, there is no need for an extra ack from RMs So, I've committed the clean backport as r212359 as this patch is a correctness issue acked by a maintainer which does not cause any ABI changes. Thanks, James
[C++ Patch] PR 57466 (DR 1584)
Hi,
the defect
(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1584) is
Ready and both clang and SolarisStudio already implement it. The below
very simple tweak seems enough, testing is fine on x86_64-linux.
Thanks!
Paolo.
/
/cp
2014-07-08 Paolo Carlini
DR 1584
PR c++/57466
* pt.c (unify): Implement resolution, disregard cv-qualifiers of
function types.
/testsuite
2014-07-08 Paolo Carlini
DR 1584
PR c++/57466
* g++.dg/template/pr57466.C: New.
* g++.dg/cpp0x/pr57466.C: Likewise.
* g++.dg/template/unify6.C: Update.
Index: cp/pt.c
===
--- cp/pt.c (revision 212347)
+++ cp/pt.c (working copy)
@@ -17831,8 +17831,13 @@ unify (tree tparms, tree targs, tree parm, tree ar
a match unless we are allowing additional qualification.
If ARG is `const int' and PARM is just `T' that's OK;
that binds `const int' to `T'. */
- if (!check_cv_quals_for_unify (strict_in | UNIFY_ALLOW_LESS_CV_QUAL,
-arg, parm))
+
+ /* DR 1584: cv-qualification of a deduced function type is
+ignored; see 8.3.5 [dcl.fct]. */
+ if (TREE_CODE (arg) != FUNCTION_TYPE
+ && !check_cv_quals_for_unify (strict_in
+ | UNIFY_ALLOW_LESS_CV_QUAL,
+ arg, parm))
return unify_cv_qual_mismatch (explain_p, parm, arg);
/* Consider the case where ARG is `const volatile int' and
Index: testsuite/g++.dg/cpp0x/pr57466.C
===
--- testsuite/g++.dg/cpp0x/pr57466.C(revision 0)
+++ testsuite/g++.dg/cpp0x/pr57466.C(working copy)
@@ -0,0 +1,18 @@
+// PR c++/57466
+// { dg-do compile { target c++11 } }
+
+template
+ constexpr bool
+ is_pointer(const T*)
+ { return true; }
+
+template
+ constexpr bool
+ is_pointer(const T&)
+ { return false; }
+
+using F = void();
+
+constexpr F* f = nullptr;
+
+static_assert( is_pointer(f), "function pointer is a pointer" );
Index: testsuite/g++.dg/template/pr57466.C
===
--- testsuite/g++.dg/template/pr57466.C (revision 0)
+++ testsuite/g++.dg/template/pr57466.C (working copy)
@@ -0,0 +1,8 @@
+// DR 1584, PR c++/57466
+
+template void f2(const T*);
+void g2();
+
+void m() {
+ f2(g2);// OK: cv-qualification of deduced function type ignored
+}
Index: testsuite/g++.dg/template/unify6.C
===
--- testsuite/g++.dg/template/unify6.C (revision 212347)
+++ testsuite/g++.dg/template/unify6.C (working copy)
@@ -3,21 +3,20 @@
void Baz ();
-template void Foo1 (T *); // #1
-template void Foo1 (T const *a) {a (1);} // #2
+template void Foo1 (T *);
+template void Foo1 (T const *a) {a (1);} // { dg-error "too many
arguments" }
template T const *Foo2 (T *);
-template void Foo3 (T *, T const * = 0); // { dg-message "note" }
+template void Foo3 (T *, T const * = 0);
void Bar ()
{
- Foo1 (&Baz); // #1
+ Foo1 (&Baz); // { dg-message "required from here" }
Foo2 (&Baz);
Foo3 (&Baz);
- Foo3 (&Baz, &Baz); // { dg-error "no matching function" "" }
- // { dg-message "(candidate|incompatible cv-qualifiers)" "candidate note" {
target *-*-* } 21 }
+ Foo3 (&Baz, &Baz);
}
Re: update address taken: don't drop clobbers
On Mon, 7 Jul 2014, Jeff Law wrote:
On 07/06/14 08:23, Marc Glisse wrote:
What is the lifetime of an SSA_NAME with a default definition? The way
we handle it now, we start from the uses and go back to all blocks that
can reach one of the uses, since there is no defining statement where we
could stop
Right, that's exactly what I would expect given the typical definition of
liveness.
(intuitively we should stop where the clobber was, if not
earlier). This huge lifetime makes it very likely for such an SSA_NAME
to conflict with others. And if an abnormal phi is involved, and thus we
must coalesce, there is a problem.
So this suggests another approach. Could we just assume that it's always
safe to coalesce with a default definition?
The patch attached (it should probably use ssa_undefined_value_p with a
new extra argument to say whether we care about partially-undefined)
makes the lifetime of undefined local variables empty and lets the
original patch work with:
def = get_or_create_ssa_default_def (cfun, sym);
instead of creating a new variable.
Not a terrible suggestion either and accomplishes the same thing as the
mental model I had of special casing this stuff in the coalescing code.
I guess this is the first thing we probably should sort out. Do we want to
handle this is the conflict, coalescing or lifetime analysis.
We've certainly had similar hacks in the code which built the conflict matrix
for the register allocator in the past (old local-alloc/global variant, pre
IRA). By not recoding those conflicts, coalescing just magically works.
By handling it when we build the lifetimes, they'll magically coalesce
because there's no conflicts as well. It may help other code which utilizes
lifetimes as well. But a part of me doesn't like it because it is different
than the traditionally formulated life analysis.
Those variables don't have a birth time so their lifetime is quite
ill-defined in any case. I first tried to force coalesce for those
variables, but it is not very convenient. We do want to consider them
for coalescing, we can't just ignore them. But when we coalesce them
with a first variable, we want to mark it somehow so we don't later
coalesce them with a second variable that conflicts with the first. The
way we do that normally is by computing the union of the lifetimes, but
if we ignore the lifetime for this variable... It isn't just a matter of
adding || ssa_undefined_value_p (var) in the conflict test. Giving them
an empty lifetime to begin with seems to do the right thing. If we don't
modify the lifetime computation, we would have in coalesce to pass only
the "defined" variables to calculate_live_ranges and re-add the
undefined variables afterwards with an empty range.
The question I havent thought much about is would the coalescing code
do the right thing if we have one of these undefined SSA_NAMEs that
coalesce into two different partitions.
ie, let's say we have two PHI nodes in different blocks. Each PHI has
one or more source/dest operations that are marked as
SSA_NAME_OCCURS_IN_ABNORMAL_PHI. Furthermore, they all reference a
single RHS undefined SSA_NAME.
When we coalesce the undefined SSA_NAME with all the others in the
first PHI, doesn't that mean that we then have to coalesce all the
SSA_NAMES in both PHIs together (because that undefined SSA_NAME
appears on the RHS on the 2nd PHI too).
Does this then argue that each use of an undefined SSA_NAME should be
a unique SSA_NAME?
I did wonder about the same thing. But without the patch, there were only
2 files in the whole gcc+testsuite that had an issue (in the ada
front-end), and with the patch they were fine, so if the situation you
describe is possible, at least it is very uncommon.
Creating a new variable instead of reusing the old one may be less
likely to cause this kind of trouble. At least at creation time we know
there is no conflict since it is coming from a variable by an operation
that is the reverse of coalescing.
Ugh, I wonder if I just opened a can of worms here...
However, I am not convinced reusing the same variable is necessarily the
best thing. For warnings, we can create a new variable with the same
name (with .1 added by gcc at the end) and copy the location info (I am
not doing that yet), so little is lost. A new variable expresses more
clearly that the value it holds is random crap. If I reuse the same
variable, the SRA patch doesn't warn because SRA explicitly sets
TREE_NO_WARNING (this can probably be changed, but that's starting to be
a lot of changes). Creating a new variable is also more general. When
reading *ssa_name after *ssa_name={v}{CLOBBER}; or after free(ssa_name);
we have no variable to reuse so we will need to create a new undefined
variable, and if a variable is global or a PARM_DECL, its default
definition is not an undefined value (though it will probably happen in
a different pass, so it doesn't have to behave the same).
My concern about usi
Re: [PATCH] Fix simplify_comparison in the combiner (PR rtl-optimization/61673)
On Thu, Jul 03, 2014 at 08:35:14AM +0200, Jakub Jelinek wrote:
> Bootstrapped/regtested on x86_64-linux, i686-linux and s390{,x}-linux. Ok
> for trunk/4.9?
I'd like to see this in 4.9.1, it is a wrong-code regression from 4.8.x,
so I'm pinging this now:
> 2014-07-03 Jakub Jelinek
>
> PR rtl-optimization/61673
> * combine.c (simplify_comparison): Test just mode's sign bit
> in tmode rather than the sign bit and any bits above it.
>
> * gcc.c-torture/execute/pr61673.c: New test.
>
> --- gcc/combine.c.jj 2014-03-28 20:49:52.892077022 +0100
> +++ gcc/combine.c 2014-07-02 16:56:02.260456040 +0200
> @@ -11987,7 +11987,7 @@ simplify_comparison (enum rtx_code code,
> = (unsigned HOST_WIDE_INT) 1 << (GET_MODE_BITSIZE (mode) - 1);
> op0 = simplify_gen_binary (AND, tmode,
>gen_lowpart (tmode, op0),
> - gen_int_mode (sign, mode));
> + gen_int_mode (sign, tmode));
> code = (code == LT) ? NE : EQ;
> break;
> }
> --- gcc/testsuite/gcc.c-torture/execute/pr61673.c.jj 2014-07-02
> 17:17:01.398908630 +0200
> +++ gcc/testsuite/gcc.c-torture/execute/pr61673.c 2014-07-02
> 17:12:36.0 +0200
> @@ -0,0 +1,50 @@
> +/* PR rtl-optimization/61673 */
> +
> +char e;
> +
> +__attribute__((noinline, noclone)) void
> +bar (char x)
> +{
> + if (x != 0x54 && x != (char) 0x87)
> +__builtin_abort ();
> +}
> +
> +__attribute__((noinline, noclone)) void
> +foo (const char *x)
> +{
> + char d = x[0];
> + int c = d;
> + if ((c >= 0 && c <= 0x7f) == 0)
> +e = d;
> + bar (d);
> +}
> +
> +__attribute__((noinline, noclone)) void
> +baz (const char *x)
> +{
> + char d = x[0];
> + int c = d;
> + if ((c >= 0 && c <= 0x7f) == 0)
> +e = d;
> +}
> +
> +int
> +main ()
> +{
> + const char c[] = { 0x54, 0x87 };
> + e = 0x21;
> + foo (c);
> + if (e != 0x21)
> +__builtin_abort ();
> + foo (c + 1);
> + if (e != (char) 0x87)
> +__builtin_abort ();
> + e = 0x21;
> + baz (c);
> + if (e != 0x21)
> +__builtin_abort ();
> + baz (c + 1);
> + if (e != (char) 0x87)
> +__builtin_abort ();
> + return 0;
> +}
Jakub
Re: Strenghten assumption about dynamic type changes (placement new)
> On 07/02/2014 01:18 PM, Jan Hubicka wrote:
> >We propagate types from places we know instances are created across pointers
> >passed to functions. Once non-POD type is created at a given memory
> >location,
> >one can not change its type by placement_new into something else.
>
> Hmm. If the memory location is untyped (i.e. from malloc) or a
> character array, or a union, you can indeed destroy an object of one
> type and create an object of a different type in that location.
>
> >Jason, this assumes that one can not destroy the type and re-construct same
> >type at the same spot.
>
> That is an invalid assumption; you can destroy one object and
> construct a new one in the same location. Doing it within a method
> would be unusual, but I don't think there's a rule against it.
>
Jason,
I am looking into tracking dynamic types now. Obviously I need to set very
exact rules about when these may change. Can you take a few minutes and tell me
what of these sequences are valid?
I think b variants are invalid, currently we also assume t1 to be invalid, but
t2 to be valid.
With placement news, I wonder if we can arrange them to do before return:
ptr = __builtin_placement_new (ptr)
this builtin would be folded away after IPA wwhen we no longer need to track
types same way as builtin_constant. That way I won't get two different dynamic
types mixed at one pointer location, since these will look as two pointers
until after inlining. But given that C++ makes placement new to be written by
hand, perhaps this is not possible?
#include
inline void* operator new(__SIZE_TYPE__, void* __p) throw() { return __p;}
struct A
{
virtual void foo() {printf ("A\n");}
};
struct B: A
{
virtual void foo() {printf ("B\n");}
};
struct C: A
{
virtual void foo() {printf ("C\n");}
};
struct A *
type(struct B *a)
{
struct C *b;
((struct B *)a)->~B();
b = new (a) C;
return b;
}
struct A *
type_back(struct A *a)
{
struct B *b;
((struct C *)a)->~C();
b = new (a) B;
return b;
}
void
t1()
{
struct B a;
struct A *b;
a.foo();
b=type(&a);
b->foo();
b=type_back (b);
a.foo();
}
void
t1b()
{
struct B a;
a.foo();
type(&a);
((struct A *)&a)->foo();
type_back (&a);
((struct A *)&a)->foo();
}
void
t2()
{
struct B *a = new (B);
struct A *b;
a->foo();
b=type(a);
b->foo();
}
void
t2b()
{
struct B *a = new (B);
struct A *b;
a->foo();
type(a);
((struct A *)a)->foo();
}
main()
{
t1();
t1b();
t2();
t2b();
}
Re: [PATCH 4.9][AArch64] Backport 211892: PR/60825 Make float64x1_t in arm_neon.h a proper vector type
On 8 July 2014 13:31, Jakub Jelinek wrote: > Many people are using different patch levels interchangeably and expect > them to be compatible. If X1 vectors are relatively rare, the better, > fewer people will be affected when switching from 4.9.x to 4.10.x. > > But IMHO changing ABI between patchlevels, at least when the ABI is not > inconsistent (we had in the past cases where e.g. caller and callee didn't > agree where to pass some argument even when using the same compiler, then > obviously no working code can use those and it can be fixed), is a very bad > idea. My strong preference is to maintain ABI compatibility between > patchlevel versions. > > Just add a -Wps-abi warning to 4.10 when you encounter this (look at what > e.g. x86_64 does). You can also add a warning to 4.9.1 that next GCC > version will change ABI for passing those. > > Jakub Alan, Ramana and I just discussed this further f2f the outcome of which was: *) Alan will look into modifying the 4.9 patches to issue a -Wpsabi gated warning that the ABI/mangling will change in 4.10 instead of making the break now. Initial thoughts were that he would need to take most of the patch in order to detect the scenario and issue the warning. *) Alan will run up a trunk patch to issue a diagnostic based on -Wpsabi to warn that mangling / ABI has changed. *) We recommend that linaro not back port the trunk mangling/ABI changes to linaro-4.9. Cheers /Marcus
Re: Fix representation of gcov_info_type
>
> So the issue seems to be:
>
> gcov_info_type = lang_hooks.types.make_type (RECORD_TYPE);
> gcov_fn_info_type = lang_hooks.types.make_type (RECORD_TYPE);
> gcov_fn_info_ptr_type = build_pointer_type
> (build_qualified_type (gcov_fn_info_type, TYPE_QUAL_CONST));
> build_fn_info_type (gcov_fn_info_type, n_counters, gcov_info_type);
> build_info_type (gcov_info_type, gcov_fn_info_ptr_type);
>
> that __gcov_info has a member of type const __gcov_info * and that
> rather than using the equivalent of
>
> struct __gcov_info;
> typedef const __gcov_info *gcov_fn_info_ptr_type;
> struct __gcov_info {
> ...
>gcov_fn_info_ptr_type x;
> };
>
> we build the variant of the yet incomplete struct and complete
> it later.
>
> Sth like
>
> Index: coverage.c
> ===
> --- coverage.c (revision 210965)
> +++ coverage.c (working copy)
> @@ -1078,9 +1078,10 @@
>/* Build the info and fn_info types. These are mutually recursive. */
>gcov_info_type = lang_hooks.types.make_type (RECORD_TYPE);
>gcov_fn_info_type = lang_hooks.types.make_type (RECORD_TYPE);
> + build_fn_info_type (gcov_fn_info_type, n_counters, gcov_info_type);
> + gcov_info_type = lang_hooks.types.make_type (RECORD_TYPE);
>gcov_fn_info_ptr_type = build_pointer_type
> (build_qualified_type (gcov_fn_info_type, TYPE_QUAL_CONST));
> - build_fn_info_type (gcov_fn_info_type, n_counters, gcov_info_type);
>build_info_type (gcov_info_type, gcov_fn_info_ptr_type);
>
>/* Build the gcov info var, this is referred to in its own
Hmm, right. I somehow misread it that gcov_info_type variant is built, but I
hope it is not - will double check. If not, then this should indeed work.
Still do not know how to use current finish_builtin_struct interface for case
where we want to have a structure that contains qualified pointer to itself.
Thanks,
Honza
Re: [GOMP4, OpenACC] Fixed-form Fortran code failing to parse
On 07/08/2014 02:21 AM, Tobias Burnus wrote: > Cesar Philippidis wrote: >> Thomas, is this OK for gomp-4_0-branch? > ... > > >> * gcc/fortran/scanner.c (gfc_next_char_literal): Fix the scan for >> *$acc. > > This changes looks good to me. > >> * parse.c (next_fixed): Don't handle openmp pragmas when scanning >> for openacc pragmas. > > This one doesn't. If both -fopenmp(-simd) and -fopenacc are both specified, > parsing of $omp *and* $acc are both disabled, which does not seem to be > what is intended. > > > The current code does: > > 1066 if ((gfc_option.gfc_flag_openmp > 1067 || gfc_option.gfc_flag_openmp_simd) > 1068 && !gfc_option.gfc_flag_openacc) > ... > 1074 else if ((gfc_option.gfc_flag_openmp > 1075|| gfc_option.gfc_flag_openmp_simd) > 1076 && gfc_option.gfc_flag_openacc) > ... > 1092 else if (gfc_option.gfc_flag_openacc) > > > The proposed patch keeps > > 1066 if ((gfc_option.gfc_flag_openmp > 1067 || gfc_option.gfc_flag_openmp_simd) > 1068 && !gfc_option.gfc_flag_openacc) > ... > > and then it uses: > + else if (gfc_option.gfc_flag_openacc > +&& !(gfc_option.gfc_flag_openmp > + || gfc_option.gfc_flag_openmp_simd)) > > ... > - else if (gfc_option.gfc_flag_openacc) > > > Thus, from my side this patch is NOT OK. Thanks for the review. I've committed the scanner portion of this patch. Cesar
Re: [patch,gomp-4_0-branch] openacc parallel reduction part 1
On 07/07/2014 02:55 AM, Thomas Schwinge wrote: > On Sun, 6 Jul 2014 16:10:56 -0700, Cesar Philippidis > wrote: >> This patch is the first step to enabling parallel reductions in openacc. > > Thanks! > >> As mentioned earlier, this patch isn't complete yet. For starters, parts >> of it depends on our internal ptx backend. I've temporarily remapped the >> ptx dependencies to their openmp equivalent, but without a proper >> openacc runtime this infrastructure won't do much. > > For the curious: we're working on preparing our implementation of the > OpenACC Runtime Library for upstream submission; if only the weeks had > more days... > >> Thomas, is this patch OK for gomp-4_0-branch? > > I still :-( haven't managed to allocate the time for a proper review, but > given this doesn't regress any existing test cases, it's fine to commit, > and then we can take it from there. > > A few minor comments: > >> 2014-07-06 Cesar Philippidis >> Thomas Schwinge > > By the way, on gomp-4_0-branch, ChangeLog snippets go into the respective > ChangeLog.gomp files. > >> --- a/gcc/c/c-parser.c >> +++ b/gcc/c/c-parser.c >> @@ -11706,7 +11710,8 @@ c_parser_oacc_kernels (location_t loc, c_parser >> *parser, char *p_name) >> */ >> >> #define OACC_LOOP_CLAUSE_MASK >> \ >> -(OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_NONE) >> +( (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_COLLAPSE) \ > > Not yet. ;-) > >> +| (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_REDUCTION)) > >> --- a/gcc/fortran/types.def >> +++ b/gcc/fortran/types.def >> @@ -86,6 +86,7 @@ DEF_FUNCTION_TYPE_1 (BT_FN_UINT_UINT, BT_UINT, BT_UINT) >> DEF_FUNCTION_TYPE_1 (BT_FN_PTR_PTR, BT_PTR, BT_PTR) >> DEF_FUNCTION_TYPE_1 (BT_FN_VOID_INT, BT_VOID, BT_INT) >> DEF_FUNCTION_TYPE_1 (BT_FN_BOOL_INT, BT_BOOL, BT_INT) >> +DEF_FUNCTION_TYPE_1 (BT_FN_INT_INT, BT_INT, BT_INT) > > That one's not actually needed, because... > >> --- a/gcc/omp-builtins.def >> +++ b/gcc/omp-builtins.def >> @@ -236,3 +236,6 @@ DEF_GOMP_BUILTIN (BUILT_IN_GOMP_TARGET_UPDATE, >> "GOMP_target_update", >>BT_FN_VOID_INT_PTR_SIZE_PTR_PTR_PTR, ATTR_NOTHROW_LIST) >> DEF_GOMP_BUILTIN (BUILT_IN_GOMP_TEAMS, "GOMP_teams", >>BT_FN_VOID_UINT_UINT, ATTR_NOTHROW_LIST) >> + >> +DEF_GOMP_BUILTIN (BUILT_IN_OMP_SET_NUM_THREADS, "omp_set_num_threads", >> + BT_FN_INT_INT, ATTR_CONST_NOTHROW_LEAF_LIST) > > ... it's actually »void omp_set_num_threads (int)«, so BT_FN_VOID_INT. > As this is only temporary code, please add a FIXME comment here. Hmm, > and I wonder, given this is using DEF_*GOMP*_BUILTIN, does this actually > do the right thing if -openmp is not specified? Thanks for catching those problems! I've committed this updated version of the patch. Cesar 2014-07-08 Cesar Philippidis Thomas Schwinge gcc/ * omp-low.c (omp_get_id): New function. (lookup_reduction): New function. (maybe_lookup_reduction): New function. (build_outer_var_ref): Remove openacc assert. (new_omp_context): Preserve ctx->reduction_map. (scan_sharing_clauses): Handle OMP_CLAUSE_REDUCTION. (scan_oacc_offload): Initialize ctx->reduction_map. (lower_reduction_clauses): Handle OpenACC reductions. (omp_gimple_assign_with_ops): New function. (initialize_reduction_data): New function. (finalize_reduction_data): New function. (process_reduction_data): New function. (lower_oacc_offload): Handle reductions. * gcc/omp-builtins.def (BUILT_IN_OMP_SET_NUM_THREADS): New. gcc/c/ * c-parser.c (c_parser_oacc_all_clauses): Handle PRAGMA_OMP_CLAUSE_REDUCTION. (OACC_LOOP_CLAUSE_MASK, OACC_PARALLEL_CLAUSE_MASK): Add PRAGMA_OMP_CLAUSE_REDUCTION. gcc/testsuite/ * gcc/testsuite/c-c++-common/goacc/reduction-1.c: New test. * gcc/testsuite/c-c++-common/goacc/reduction-2.c: New test. * gcc/testsuite/c-c++-common/goacc/reduction-3.c: New test. * gcc/testsuite/c-c++-common/goacc/reduction-4.c: New test. diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c index 03852b4..6a9271f 100644 --- a/gcc/c/c-parser.c +++ b/gcc/c/c-parser.c @@ -11332,6 +11332,10 @@ c_parser_oacc_all_clauses (c_parser *parser, omp_clause_mask mask, clauses = c_parser_oacc_data_clause (parser, c_kind, clauses); c_name = "present_or_create"; break; + case PRAGMA_OMP_CLAUSE_REDUCTION: + clauses = c_parser_omp_clause_reduction (parser, clauses); + c_name = "reduction"; + break; case PRAGMA_OMP_CLAUSE_SELF: clauses = c_parser_oacc_data_clause (parser, c_kind, clauses); c_name = "self"; @@ -11706,7 +11710,7 @@ c_parser_oacc_kernels (location_t loc, c_parser *parser, char *p_name) */ #define OACC_LOOP_CLAUSE_MASK \ - (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_NONE) + (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_REDUCTION) static tree c_parser_oacc_loop (location_t loc, c_parser *parser, char *p_name) @@ -11746,6 +11750,7 @@ c_parser_oacc_loop (location_t loc, c_parser *parser, char *p_name) | (OMP_CLAUSE_M
Re: Strenghten assumption about dynamic type changes (placement new)
On Tue, Jul 8, 2014 at 2:50 PM, Jan Hubicka wrote:
>> On 07/02/2014 01:18 PM, Jan Hubicka wrote:
>> >We propagate types from places we know instances are created across pointers
>> >passed to functions. Once non-POD type is created at a given memory
>> >location,
>> >one can not change its type by placement_new into something else.
>>
>> Hmm. If the memory location is untyped (i.e. from malloc) or a
>> character array, or a union, you can indeed destroy an object of one
>> type and create an object of a different type in that location.
>>
>> >Jason, this assumes that one can not destroy the type and re-construct same
>> >type at the same spot.
>>
>> That is an invalid assumption; you can destroy one object and
>> construct a new one in the same location. Doing it within a method
>> would be unusual, but I don't think there's a rule against it.
>>
> Jason,
> I am looking into tracking dynamic types now. Obviously I need to set very
> exact rules about when these may change. Can you take a few minutes and tell
> me
> what of these sequences are valid?
>
> I think b variants are invalid, currently we also assume t1 to be invalid, but
> t2 to be valid.
> With placement news, I wonder if we can arrange them to do before return:
> ptr = __builtin_placement_new (ptr)
> this builtin would be folded away after IPA wwhen we no longer need to track
> types same way as builtin_constant. That way I won't get two different dynamic
> types mixed at one pointer location, since these will look as two pointers
> until after inlining. But given that C++ makes placement new to be written by
> hand, perhaps this is not possible?
>
> #include
> inline void* operator new(__SIZE_TYPE__, void* __p) throw() { return __p;}
>
> struct A
> {
> virtual void foo() {printf ("A\n");}
> };
> struct B: A
> {
> virtual void foo() {printf ("B\n");}
> };
> struct C: A
> {
> virtual void foo() {printf ("C\n");}
> };
>
> struct A *
> type(struct B *a)
> {
> struct C *b;
> ((struct B *)a)->~B();
> b = new (a) C;
> return b;
> }
> struct A *
> type_back(struct A *a)
> {
> struct B *b;
> ((struct C *)a)->~C();
> b = new (a) B;
> return b;
> }
>
> void
> t1()
> {
> struct B a;
> struct A *b;
> a.foo();
> b=type(&a);
> b->foo();
> b=type_back (b);
> a.foo();
> }
> void
> t1b()
> {
> struct B a;
> a.foo();
> type(&a);
> ((struct A *)&a)->foo();
> type_back (&a);
> ((struct A *)&a)->foo();
> }
> void
> t2()
> {
> struct B *a = new (B);
> struct A *b;
> a->foo();
> b=type(a);
> b->foo();
> }
> void
> t2b()
> {
> struct B *a = new (B);
> struct A *b;
> a->foo();
> type(a);
> ((struct A *)a)->foo();
> }
> main()
> {
> t1();
> t1b();
> t2();
> t2b();
> }
Hi,
Below test also fails on arm-none-linux-gnueabi(hf):
NA->FAIL: g++.dg/ipa/imm-devirt-2.C -std=gnu++11 scan-tree-dump einline "C
NA->FAIL: g++.dg/ipa/imm-devirt-2.C -std=gnu++1y scan-tree-dump einline "C
NA->FAIL: g++.dg/ipa/imm-devirt-2.C -std=gnu++98 scan-tree-dump einline "C
Reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61748
Thanks,
bin
Re: Fix representation of gcov_info_type
On July 8, 2014 4:03:05 PM CEST, Jan Hubicka wrote:
>>
>> So the issue seems to be:
>>
>> gcov_info_type = lang_hooks.types.make_type (RECORD_TYPE);
>> gcov_fn_info_type = lang_hooks.types.make_type (RECORD_TYPE);
>> gcov_fn_info_ptr_type = build_pointer_type
>> (build_qualified_type (gcov_fn_info_type, TYPE_QUAL_CONST));
>> build_fn_info_type (gcov_fn_info_type, n_counters, gcov_info_type);
>> build_info_type (gcov_info_type, gcov_fn_info_ptr_type);
>>
>> that __gcov_info has a member of type const __gcov_info * and that
>> rather than using the equivalent of
>>
>> struct __gcov_info;
>> typedef const __gcov_info *gcov_fn_info_ptr_type;
>> struct __gcov_info {
>> ...
>>gcov_fn_info_ptr_type x;
>> };
>>
>> we build the variant of the yet incomplete struct and complete
>> it later.
>>
>> Sth like
>>
>> Index: coverage.c
>> ===
>> --- coverage.c (revision 210965)
>> +++ coverage.c (working copy)
>> @@ -1078,9 +1078,10 @@
>>/* Build the info and fn_info types. These are mutually
>recursive. */
>>gcov_info_type = lang_hooks.types.make_type (RECORD_TYPE);
>>gcov_fn_info_type = lang_hooks.types.make_type (RECORD_TYPE);
>> + build_fn_info_type (gcov_fn_info_type, n_counters,
>gcov_info_type);
>> + gcov_info_type = lang_hooks.types.make_type (RECORD_TYPE);
>>gcov_fn_info_ptr_type = build_pointer_type
>> (build_qualified_type (gcov_fn_info_type, TYPE_QUAL_CONST));
>> - build_fn_info_type (gcov_fn_info_type, n_counters,
>gcov_info_type);
>>build_info_type (gcov_info_type, gcov_fn_info_ptr_type);
>>
>>/* Build the gcov info var, this is referred to in its own
>
>Hmm, right. I somehow misread it that gcov_info_type variant is built,
>but I
>hope it is not - will double check. If not, then this should indeed
>work.
>Still do not know how to use current finish_builtin_struct interface
>for case
>where we want to have a structure that contains qualified pointer to
>itself.
You probably can't. But check what the C frontend ends up producing with
Struct x { const struct x *p; };
Doesn't it use an incomplete copy during the definition of x?
Richard.
>Thanks,
>Honza
Re: [Patch, testsuite] PR61453 gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't "call"
> I just checked. It doesn't work on hppa64-hp-hpux11.11 due to following
> statement:
>
> .type myBindC, @function
So can we settle for
--- ../_clean/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
2014-05-24 16:17:53.0 +0200
+++ gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90 2014-07-07
19:15:47.0 +0200
@@ -16,7 +16,7 @@ integer :: aa(4,4)
call test(aa)
end
-! { dg-final { scan-assembler-times "call\[^\n\r\]*myBindC" 1 { target { ! {
hppa*-*-hpux* } } } } }
-! { dg-final { scan-assembler-times "call\[^\n\r\]*myBindC,%r2" 1 { target {
hppa*-*-hpux* } } } }
+! { dg-final { scan-assembler-times "\[ \t\]\[$,_0-9\]*myBindC" 1 { target { !
{ hppa*-*-hpux* } } } } }
+! { dg-final { scan-assembler-times "myBindC,%r2" 1 { target { hppa*-*-hpux* }
} } }
! { dg-final { scan-tree-dump-times "test \\\(&parm\\." 1 "original" } }
! { dg-final { cleanup-tree-dump "original" } }
? If yes, could someone give me the "green light". The patch will fix the
failures
for the targets it has been tested.
TIA
Dominique
Re: [PATCH] Fix simplify_comparison in the combiner (PR rtl-optimization/61673)
On Tue, 8 Jul 2014, Jakub Jelinek wrote:
> On Thu, Jul 03, 2014 at 08:35:14AM +0200, Jakub Jelinek wrote:
> > Bootstrapped/regtested on x86_64-linux, i686-linux and s390{,x}-linux. Ok
> > for trunk/4.9?
>
> I'd like to see this in 4.9.1, it is a wrong-code regression from 4.8.x,
> so I'm pinging this now:
Ok.
Thanks,
Richard.
> > 2014-07-03 Jakub Jelinek
> >
> > PR rtl-optimization/61673
> > * combine.c (simplify_comparison): Test just mode's sign bit
> > in tmode rather than the sign bit and any bits above it.
> >
> > * gcc.c-torture/execute/pr61673.c: New test.
> >
> > --- gcc/combine.c.jj2014-03-28 20:49:52.892077022 +0100
> > +++ gcc/combine.c 2014-07-02 16:56:02.260456040 +0200
> > @@ -11987,7 +11987,7 @@ simplify_comparison (enum rtx_code code,
> > = (unsigned HOST_WIDE_INT) 1 << (GET_MODE_BITSIZE (mode) - 1);
> > op0 = simplify_gen_binary (AND, tmode,
> > gen_lowpart (tmode, op0),
> > -gen_int_mode (sign, mode));
> > +gen_int_mode (sign, tmode));
> > code = (code == LT) ? NE : EQ;
> > break;
> > }
> > --- gcc/testsuite/gcc.c-torture/execute/pr61673.c.jj2014-07-02
> > 17:17:01.398908630 +0200
> > +++ gcc/testsuite/gcc.c-torture/execute/pr61673.c 2014-07-02
> > 17:12:36.0 +0200
> > @@ -0,0 +1,50 @@
> > +/* PR rtl-optimization/61673 */
> > +
> > +char e;
> > +
> > +__attribute__((noinline, noclone)) void
> > +bar (char x)
> > +{
> > + if (x != 0x54 && x != (char) 0x87)
> > +__builtin_abort ();
> > +}
> > +
> > +__attribute__((noinline, noclone)) void
> > +foo (const char *x)
> > +{
> > + char d = x[0];
> > + int c = d;
> > + if ((c >= 0 && c <= 0x7f) == 0)
> > +e = d;
> > + bar (d);
> > +}
> > +
> > +__attribute__((noinline, noclone)) void
> > +baz (const char *x)
> > +{
> > + char d = x[0];
> > + int c = d;
> > + if ((c >= 0 && c <= 0x7f) == 0)
> > +e = d;
> > +}
> > +
> > +int
> > +main ()
> > +{
> > + const char c[] = { 0x54, 0x87 };
> > + e = 0x21;
> > + foo (c);
> > + if (e != 0x21)
> > +__builtin_abort ();
> > + foo (c + 1);
> > + if (e != (char) 0x87)
> > +__builtin_abort ();
> > + e = 0x21;
> > + baz (c);
> > + if (e != 0x21)
> > +__builtin_abort ();
> > + baz (c + 1);
> > + if (e != (char) 0x87)
> > +__builtin_abort ();
> > + return 0;
> > +}
>
> Jakub
>
>
--
Richard Biener
SUSE / SUSE Labs
SUSE LINUX Products GmbH - Nuernberg - AG Nuernberg - HRB 16746
GF: Jeff Hawn, Jennifer Guild, Felix Imend"orffer
Re: Strenghten assumption about dynamic type changes (placement new)
On Thu, Jul 3, 2014 at 4:20 AM, Jason Merrill wrote: > On 07/02/2014 06:30 PM, Jan Hubicka wrote: >> >> But this is one of things that was not quite clear to me. I know that >> polymorphic type A >> was created at a give memory location. THis means that accesses to that >> location in one >> alias class has been made. >> Now I destroy A and turn it into B, construct B and make memory accesses >> in different >> alias set. I see this has chance to work if one is base of another, but >> if B is completely >> different type, I think strick aliasin should just make those accesses to >> not alias and in turn >> make whole thing undefined? > > > Right, if they're unrelated types the accesses don't alias (3.10p10). > > On the subject of aliasing, there's a proposal to add explicit alias sets to > C++: > > http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3988.pdf > > Any thoughts? Well, but deleting the object at *p and constructing a new one with different alias set there doesn't make it valid for GCC to move loads/stores across that destruction/construction point, no? With placement new / delete they will basically be a no-op and be "invisible" in the IL - so what avoids GCC, for example from insn scheduling, to mess things up here? (the GCC middle-end memory model does - but as far as I understand Honza want's to play tricks to get around that, no?) Richard. > Jason >
Re: [Patch, AArch64] Restructure arm_neon.h vector types' implementation.
I've spotted another couple of issues (inline below) that I see when
trying to bootstrap an AArch64 compiler with this patch applied.
(sorry for any duplicate mails sent and received, my mailer was upset by
some of the characters in the error messages).
Thanks,
James
On Fri, Jun 27, 2014 at 04:32:19PM +0100, Tejas Belagod wrote:
> +#define ENTRY(E, M, Q, G) E,
> +enum aarch64_simd_type
> +{
> +#include "aarch64-simd-builtin-types.def"
> +};
> +#undef ENTRY
>
The final entry in this enum will have a trailing comma, resulting in:
[...]/aarch64-builtins.c:333:28
error: comma at end of enumerator list
#define ENTRY(E, M, Q, G) E,
[...]/aarch64-simd-builtin-types.def:50:3: note: in expansion of macro ENTRY
ENTRY (Float64x2_t, V2DF, none, 13)
> static void
> -aarch64_init_simd_builtins (void)
> +aarch64_init_simd_builtin_types (void)
> {
> - unsigned int i, fcode = AARCH64_SIMD_BUILTIN_BASE + 1;
> + int i;
> + int nelts = sizeof (aarch64_simd_types) / sizeof (aarch64_simd_types[0]);
> + tree tdecl;
> +
> + for (i = 0; i < nelts; i++)
> +{
> + tree eltype = aarch64_simd_types[i].eltype;
> + enum machine_mode mode = aarch64_simd_types[i].mode;
> + enum aarch64_simd_type type = aarch64_simd_types[i].type;
Type is unused here, resulting in:
[...]/aarch64-builtins.c: In function void aarch64_init_simd_builtin_types():
[...]/aarch64-builtins.c:547:30: error: unused variable
enum aarch64_simd_type type = aarch64_simd_types[i].type;
> +
> + if (aarch64_simd_types[i].itype == NULL)
> + aarch64_simd_types[i].itype =
> + build_distinct_type_copy
> + (build_vector_type (eltype, GET_MODE_NUNITS (mode)));
> +
> + tdecl = add_builtin_type (aarch64_simd_types[i].name,
> + aarch64_simd_types[i].itype);
> + TYPE_NAME (aarch64_simd_types[i].itype) = tdecl;
> + SET_TYPE_STRUCTURAL_EQUALITY (aarch64_simd_types[i].itype);
> +}
>
Re: [i386] Replace builtins with vector extensions
On Jul 8, 2014, at 4:17 AM, Jakub Jelinek wrote: > On Tue, Jul 08, 2014 at 03:14:04PM +0400, Kirill Yukhin wrote: On the over hand, updated in such a way intrinsic may actually generate different instruction then intended (e.g. FMA case). >>> >>> It is the same with scalars, we have -ffp-contract for that. >> Agreed. > > I don't think we actually always guarantee using the particular instructions > for the intrinsics even when they are implemented using builtins, at least > if they don't use UNSPECs, e.g. if combiner or peephole2 manage to combine > something into some other insn, we'll happily do that. In a testcase, one is free to hide the inputs and the output from the optimizer using standard tricks and take one step closer to having a 1-1 mapping. Of course, wether or not the port even offers a 1-1 mapping for any particular builtin is completely dependent upon the port.
[PATCH 2/2] Emit DW_tag_restrict_type for restrict-qualified pointers.
gcc/ChangeLog
PR debug/59051
* dwarf2out.h (enum dw_mod_flag): Add dw_mod_restrict.
* dwarf2out.c (dw_mod_decl_flags): Handle TYPE_RESTRICT.
(dw_mod_type_flags): Likewise.
(dw_mods_to_quals): New function.
(dw_mod_qualified_type): Likewise.
(modified_type_die): Handle dw_mod_restrict.
gcc/testsuite/ChangeLog
PR debug/59051
* gcc.dg/guality/restrict.c: New test.
---
gcc/ChangeLog | 10 ++
gcc/dwarf2out.c | 33 -
gcc/testsuite/ChangeLog |4 ++
gcc/testsuite/gcc.dg/guality/restrict.c | 48 +++
4 files changed, 87 insertions(+), 8 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/guality/restrict.c
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 3f63f1b..cc68a80 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,13 @@
+2014-07-08 Mark Wielaard
+
+ PR debug/59051
+ * dwarf2out.h (enum dw_mod_flag): Add dw_mod_restrict.
+ * dwarf2out.c (dw_mod_decl_flags): Handle TYPE_RESTRICT.
+ (dw_mod_type_flags): Likewise.
+ (dw_mods_to_quals): New function.
+ (dw_mod_qualified_type): Likewise.
+ (modified_type_die): Handle dw_mod_restrict.
+
2014-07-07 Mark Wielaard
* dwarf2out.c (decl_quals): New function.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 068bbc3..be17cad 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -10522,7 +10522,13 @@ modified_type_die (tree type, int cv_quals, dw_die_ref
context_die)
return NULL;
/* Only these cv-qualifiers are currently handled. */
- cv_quals &= (TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE);
+ cv_quals &= (TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE | TYPE_QUAL_RESTRICT);
+
+ /* Don't emit DW_TAG_restrict_type for DWARFv2, since it is a type
+ tag modifier (and not an attribute) old consumers won't be able
+ to handle it. */
+ if (dwarf_version < 3)
+cv_quals &= ~TYPE_QUAL_RESTRICT;
/* See if we already have the appropriately qualified variant of
this type. */
@@ -10567,7 +10573,7 @@ modified_type_die (tree type, int cv_quals, dw_die_ref
context_die)
else
{
int dquals = TYPE_QUALS_NO_ADDR_SPACE (dtype);
- dquals &= (TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE);
+ dquals &= (TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE | TYPE_QUAL_RESTRICT);
if ((dquals & ~cv_quals) != TYPE_UNQUALIFIED
|| (cv_quals == dquals && DECL_ORIGINAL_TYPE (name) != type))
/* cv-unqualified version of named type. Just use
@@ -10581,22 +10587,33 @@ modified_type_die (tree type, int cv_quals,
dw_die_ref context_die)
mod_scope = scope_die_for (type, context_die);
if ((cv_quals & TYPE_QUAL_CONST)
- /* If both const_type and volatile_type, prefer the path
-which leads to a qualified type. */
- && (!(cv_quals & TYPE_QUAL_VOLATILE)
- || get_qualified_type (type, TYPE_QUAL_CONST) == NULL_TREE
- || get_qualified_type (type, TYPE_QUAL_VOLATILE) != NULL_TREE))
+ /* If there are multiple type modifiers, prefer a path which
+leads to a qualified type. */
+ && (((cv_quals & ~TYPE_QUAL_CONST) == TYPE_UNQUALIFIED)
+ || get_qualified_type (type, cv_quals) == NULL_TREE
+ || (get_qualified_type (type, cv_quals & ~TYPE_QUAL_CONST)
+ != NULL_TREE)))
{
mod_type_die = new_die (DW_TAG_const_type, mod_scope, type);
sub_die = modified_type_die (type, cv_quals & ~TYPE_QUAL_CONST,
context_die);
}
- else if (cv_quals & TYPE_QUAL_VOLATILE)
+ else if ((cv_quals & TYPE_QUAL_VOLATILE)
+ && (((cv_quals & ~TYPE_QUAL_VOLATILE) == TYPE_UNQUALIFIED)
+ || get_qualified_type (type, cv_quals) == NULL_TREE
+ || (get_qualified_type (type, cv_quals & ~TYPE_QUAL_VOLATILE)
+ != NULL_TREE)))
{
mod_type_die = new_die (DW_TAG_volatile_type, mod_scope, type);
sub_die = modified_type_die (type, cv_quals & ~TYPE_QUAL_VOLATILE,
context_die);
}
+ else if (cv_quals & TYPE_QUAL_RESTRICT)
+{
+ mod_type_die = new_die (DW_TAG_restrict_type, mod_scope, type);
+ sub_die = modified_type_die (type, cv_quals & ~TYPE_QUAL_RESTRICT,
+ context_die);
+}
else if (code == POINTER_TYPE)
{
mod_type_die = new_die (DW_TAG_pointer_type, mod_scope, type);
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 1abc700..e82c07c 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2014-06-20 Mark Wielaard
+
+ * gcc.dg/guality/restrict.c: New test.
+
2014-07-03 Mark Wielaard
* lib/gcc-gdb-test.exp (gdb-test): Handle type:var for gdb ptype
diff --git a/gcc/testsuite/gcc.dg/guality/restrict.c
b/gcc/testsuite/gcc.dg/guality/restri
[PATCH 1/2] dwarf2out.c: Pass one cv_quals argument instead of two for const and volatile.
Hi, In my original patch I introduced a new enum to keep track of the qualifiers that we might want to output. But that seems silly in retrospect. We already have the tree cv_qualifier enum to encode all possible cv-qualifier combinations, so this variant of the patch just reuses those and uses TYPE_QUALS_NO_ADDR_SPACE to extract the qualifiers from the tree types. I kept this patch separate from the actual patch that introduces the DW_TAG_restrict_type because I thought that would be easier to review. But I can merge the two patches together if people feel that is more appropriate. modified_type_die and add_type_attribute take two separate arguments for whether the type should be const and/or volatile. To help add more type modifiers pass the requested modifiers as one cv_quals argument to these functions. And introduce helper function decl_quals to extract additional cv_quals from declaration trees. DWARFv3 added restrict_type [PR debug/59051] and DWARFv5 has proposals for atomic_type and aligned_type. Which will be easier to implement based on this change. gcc/ChangeLog * dwarf2out.c (decl_quals): New function. (modified_type_die): Take one cv_quals argument instead of two, one for const and one for volatile. (add_type_attribute): Likewise. (generic_parameter_die): Call add_type_attribute with one modifier argument. (base_type_for_mode): Likewise. (add_bounds_info): Likewise. (add_subscript_info): Likewise. (gen_array_type_die): Likewise. (gen_descr_array_type_die): Likewise. (gen_entry_point_die): Likewise. (gen_enumeration_type_die): Likewise. (gen_formal_parameter_die): Likewise. (gen_subprogram_die): Likewise. (gen_variable_die): Likewise. (gen_const_die): Likewise. (gen_field_die): Likewise. (gen_pointer_type_die): Likewise. (gen_reference_type_die): Likewise. (gen_ptr_to_mbr_type_die): Likewise. (gen_inheritance_die): Likewise. (gen_subroutine_type_die): Likewise. (gen_typedef_die): Likewise. (force_type_die): Likewise. --- gcc/ChangeLog | 28 ++ gcc/dwarf2out.c | 154 +++ 2 files changed, 115 insertions(+), 67 deletions(-) diff --git a/gcc/ChangeLog b/gcc/ChangeLog index cf55712..3f63f1b 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,31 @@ +2014-07-07 Mark Wielaard + + * dwarf2out.c (decl_quals): New function. + (modified_type_die): Take one cv_quals argument instead of two, + one for const and one for volatile. + (add_type_attribute): Likewise. + (generic_parameter_die): Call add_type_attribute with one modifier + argument. + (base_type_for_mode): Likewise. + (add_bounds_info): Likewise. + (add_subscript_info): Likewise. + (gen_array_type_die): Likewise. + (gen_descr_array_type_die): Likewise. + (gen_entry_point_die): Likewise. + (gen_enumeration_type_die): Likewise. + (gen_formal_parameter_die): Likewise. + (gen_subprogram_die): Likewise. + (gen_variable_die): Likewise. + (gen_const_die): Likewise. + (gen_field_die): Likewise. + (gen_pointer_type_die): Likewise. + (gen_reference_type_die): Likewise. + (gen_ptr_to_mbr_type_die): Likewise. + (gen_inheritance_die): Likewise. + (gen_subroutine_type_die): Likewise. + (gen_typedef_die): Likewise. + (force_type_die): Likewise. + 2014-07-01 Jan Hubicka * ipa-utils.h (method_class_type, vtable_pointer_value_to_binfo, diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c index b65b37e..068bbc3 100644 --- a/gcc/dwarf2out.c +++ b/gcc/dwarf2out.c @@ -3140,7 +3140,8 @@ static void output_file_names (void); static dw_die_ref base_type_die (tree); static int is_base_type (tree); static dw_die_ref subrange_type_die (tree, tree, tree, dw_die_ref); -static dw_die_ref modified_type_die (tree, int, int, dw_die_ref); +static int decl_quals (const_tree); +static dw_die_ref modified_type_die (tree, int, dw_die_ref); static dw_die_ref generic_parameter_die (tree, tree, bool, dw_die_ref); static dw_die_ref template_parameter_pack_die (tree, tree, dw_die_ref); static int type_is_enum (const_tree); @@ -3198,7 +3199,7 @@ static dw_die_ref scope_die_for (tree, dw_die_ref); static inline int local_scope_p (dw_die_ref); static inline int class_scope_p (dw_die_ref); static inline int class_or_namespace_scope_p (dw_die_ref); -static void add_type_attribute (dw_die_ref, tree, int, int, dw_die_ref); +static void add_type_attribute (dw_die_ref, tree, int, dw_die_ref); static void add_calling_convention_attribute (dw_die_ref, tree); static const char *type_tag (const_tree); static tree member_declared_type (const_tree); @@ -10490,12 +10491,24 @@ subrange_type_die (tree type, tree low, tree high, dw_die_ref context_die) return sub
Re: [patch,gomp-4_0-branch] openacc parallel reduction part 1
On 07/08/2014 07:28 AM, Cesar Philippidis wrote: > Thanks for catching those problems! I've committed this updated version > of the patch. I forgot to remove the support for the collapse clause in from the loop construct in the c frontend. I did so upstream, but not internally. I've checked in this patch which fixes that. Thomas, I don't know how you manage so many different branches. Cesar 2014-07-08 Cesar Philippidis gcc/c/ *c-parser.c (OACC_LOOP_CLAUSE_MASK): Remove PRAGMA_OMP_CLAUSE_COLLAPSE from theh mask. diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c index 66d5444..fb7e12d 100644 --- a/gcc/c/c-parser.c +++ b/gcc/c/c-parser.c @@ -11906,8 +11906,7 @@ c_parser_oacc_kernels (location_t loc, c_parser *parser, char *p_name) */ #define OACC_LOOP_CLAUSE_MASK \ - ( (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_COLLAPSE) \ - | (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_REDUCTION)) + (OMP_CLAUSE_MASK_1 << PRAGMA_OMP_CLAUSE_REDUCTION) static tree c_parser_oacc_loop (location_t loc, c_parser *parser, char *p_name)
Re: [PATCH] C++ thunk section names
On Mon, Jul 7, 2014 at 11:48 AM, Jan Hubicka wrote:
> Hello,
> I apologize for taking so long to get into this patch. I ad busy time
> (wedding
> and teaching), should be back in regular schedule now.
>
>> Sri, can you provide examples to show why putting thunks into the same
>> section as the target function when function reorder is on can be bad
>> ?
>
> C++ ABI specify that they are in the same section, but I can't think of the
> case where this would break.
> Hmm, I suppose it is the TARGET_USE_LOCAL_THUNK_ALIAS_P code that breaks -
> you end up with code in two sections where one is accessing local comdat
> of the toher. I would also like to see testcase that breaks and is fixed by
> your patch. I would expect that here, by not copying the section name,
> you actually make things wose.
Here is an example where the thunk and the original function get
placed in different sections.
class base_class_1
{
public:
virtual void vfn () {}
};
class base_class_2
{
public:
virtual void vfn () {}
};
void foo();
class need_thunk_class : public base_class_1, public base_class_2
{
public:
virtual void vfn () {
for (int i = 0; i < 10; ++i)
foo();
}
};
int main (int argc, char *argv[])
{
base_class_1 *bc1 = new need_thunk_class ();
bc1->vfn();
return 0;
}
int glob = 0;
__attribute__((noinline))
void foo()
{
glob++;
}
I am making the function that needs thunk hot. Now,
$ g++ thunkex.cc -O2 -fno-reorder-blocks-and-partition
-fprofile-generate -ffunction-sections
$ a.out
$ g++ thunkex.cc -O2 -fno-reorder-blocks-and-partition -fprofile-use
-ffunction-sections -c
$ objdump -d thunkex.o
Disassembly of section .text.hot._ZN16need_thunk_class3vfnEv:
<_ZN16need_thunk_class3vfnEv>:
0: 53 push %rbx
1: bb a0 86 01 00 mov$0x186a0,%ebx
...
Disassembly of section .text._ZN16need_thunk_class3vfnEv:
<_ZThn8_N16need_thunk_class3vfnEv>:
0: 48 83 ef 08 sub$0x8,%rdi
When the original function gets moved to .text.hot, the thunk does
not. It is not always the case that the thunk should either.
Thanks
Sri
>
> I think we need to deal with this later; use_tunk is done long before
> profiling is read and before we decide whether code is hot/cold. I suppose
> the function reordering code may need to always walk whole comdat group and
> ensure that sections are same?
> I.e. pick the highest profile of a function in the group, resolve unique
> section
> on it and then copy section names? I had verifier checking that section names
> within one comdat groups are same, perhaps it was part of the reverted patch
> for AIX. I will try to get that one back in now.
>
> Jan
>>
>> Thanks,
>>
>> David
>>
>> On Thu, Jun 26, 2014 at 10:29 AM, Sriraman Tallam
>> wrote:
>> > Hi Honza,
>> >
>> >Could you review this patch when you find time?
>> >
>> > Thanks
>> > Sri
>> >
>> > On Tue, Jun 17, 2014 at 10:42 AM, Sriraman Tallam
>> > wrote:
>> >> Ping.
>> >>
>> >> On Mon, Jun 9, 2014 at 3:54 PM, Sriraman Tallam
>> >> wrote:
>> >>> Ping.
>> >>>
>> >>> On Mon, May 19, 2014 at 11:25 AM, Sriraman Tallam
>> >>> wrote:
>> Ping.
>>
>> On Thu, Apr 17, 2014 at 10:41 AM, Sriraman Tallam
>> wrote:
>> > Ping.
>> >
>> > On Wed, Feb 5, 2014 at 4:31 PM, Sriraman Tallam
>> > wrote:
>> >> Hi,
>> >>
>> >> I would like this patch reviewed and considered for commit when
>> >> Stage 1 is active again.
>> >>
>> >> Patch Description:
>> >>
>> >> A C++ thunk's section name is set to be the same as the original
>> >> function's
>> >> section name for which the thunk was created in order to place the two
>> >> together. This is done in cp/method.c in function use_thunk.
>> >> However, with function reordering turned on, the original function's
>> >> section
>> >> name can change to something like ".text.hot." or
>> >> ".text.unlikely." in function default_function_section in
>> >> varasm.c
>> >> based on the node count of that function. The thunk function's
>> >> section name
>> >> is not updated to be the same as the original here and also is not
>> >> always
>> >> correct to do it as the original function can be hotter than the
>> >> thunk.
>> >>
>> >> I have created a patch to not name the thunk function's section to be
>> >> the same
>> >> as the original function when function reordering is enabled.
>> >>
>> >> Thanks
>> >> Sri
Re: [PATCH] C++ thunk section names
On Tue, Jul 8, 2014 at 10:38 AM, Sriraman Tallam wrote:
> On Mon, Jul 7, 2014 at 11:48 AM, Jan Hubicka wrote:
>> Hello,
>> I apologize for taking so long to get into this patch. I ad busy time
>> (wedding
>> and teaching), should be back in regular schedule now.
>>
>>> Sri, can you provide examples to show why putting thunks into the same
>>> section as the target function when function reorder is on can be bad
>>> ?
>>
>> C++ ABI specify that they are in the same section, but I can't think of the
>> case where this would break.
>> Hmm, I suppose it is the TARGET_USE_LOCAL_THUNK_ALIAS_P code that breaks -
>> you end up with code in two sections where one is accessing local comdat
>> of the toher. I would also like to see testcase that breaks and is fixed by
>> your patch. I would expect that here, by not copying the section name,
>> you actually make things wose.
>
> Here is an example where the thunk and the original function get
> placed in different sections.
>
> class base_class_1
> {
> public:
> virtual void vfn () {}
> };
>
> class base_class_2
> {
> public:
> virtual void vfn () {}
> };
> void foo();
> class need_thunk_class : public base_class_1, public base_class_2
> {
> public:
> virtual void vfn () {
> for (int i = 0; i < 10; ++i)
> foo();
> }
> };
>
> int main (int argc, char *argv[])
> {
> base_class_1 *bc1 = new need_thunk_class ();
> bc1->vfn();
> return 0;
> }
>
> int glob = 0;
> __attribute__((noinline))
> void foo()
> {
> glob++;
> }
>
>
> I am making the function that needs thunk hot. Now,
>
> $ g++ thunkex.cc -O2 -fno-reorder-blocks-and-partition
> -fprofile-generate -ffunction-sections
> $ a.out
> $ g++ thunkex.cc -O2 -fno-reorder-blocks-and-partition -fprofile-use
> -ffunction-sections -c
> $ objdump -d thunkex.o
>
> Disassembly of section .text.hot._ZN16need_thunk_class3vfnEv:
>
> <_ZN16need_thunk_class3vfnEv>:
>0: 53 push %rbx
>1: bb a0 86 01 00 mov$0x186a0,%ebx
>...
>
> Disassembly of section .text._ZN16need_thunk_class3vfnEv:
>
> <_ZThn8_N16need_thunk_class3vfnEv>:
>0: 48 83 ef 08 sub$0x8,%rdi
>
>
> When the original function gets moved to .text.hot, the thunk does
> not. It is not always the case that the thunk should either.
I forgot to add that this becomes confusing because, in this case, the
thunk is the only function sitting in a section whose name does not
correspond to its assembler name. If we are not going to have thunk
section names the same as the original function when profiles are
available and -freorder-functions is used, we as well change the name
of the thunk's section to correspond to its assembler name. That was
the intention of the patch.
Thanks
Sri
>
> Thanks
> Sri
>
>
>
>
>>
>> I think we need to deal with this later; use_tunk is done long before
>> profiling is read and before we decide whether code is hot/cold. I suppose
>> the function reordering code may need to always walk whole comdat group and
>> ensure that sections are same?
>> I.e. pick the highest profile of a function in the group, resolve unique
>> section
>> on it and then copy section names? I had verifier checking that section
>> names
>> within one comdat groups are same, perhaps it was part of the reverted patch
>> for AIX. I will try to get that one back in now.
>>
>> Jan
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> On Thu, Jun 26, 2014 at 10:29 AM, Sriraman Tallam
>>> wrote:
>>> > Hi Honza,
>>> >
>>> >Could you review this patch when you find time?
>>> >
>>> > Thanks
>>> > Sri
>>> >
>>> > On Tue, Jun 17, 2014 at 10:42 AM, Sriraman Tallam
>>> > wrote:
>>> >> Ping.
>>> >>
>>> >> On Mon, Jun 9, 2014 at 3:54 PM, Sriraman Tallam
>>> >> wrote:
>>> >>> Ping.
>>> >>>
>>> >>> On Mon, May 19, 2014 at 11:25 AM, Sriraman Tallam
>>> >>> wrote:
>>> Ping.
>>>
>>> On Thu, Apr 17, 2014 at 10:41 AM, Sriraman Tallam
>>> wrote:
>>> > Ping.
>>> >
>>> > On Wed, Feb 5, 2014 at 4:31 PM, Sriraman Tallam
>>> > wrote:
>>> >> Hi,
>>> >>
>>> >> I would like this patch reviewed and considered for commit when
>>> >> Stage 1 is active again.
>>> >>
>>> >> Patch Description:
>>> >>
>>> >> A C++ thunk's section name is set to be the same as the original
>>> >> function's
>>> >> section name for which the thunk was created in order to place the
>>> >> two
>>> >> together. This is done in cp/method.c in function use_thunk.
>>> >> However, with function reordering turned on, the original function's
>>> >> section
>>> >> name can change to something like ".text.hot." or
>>> >> ".text.unlikely." in function default_function_section in
>>> >> varasm.c
>>> >> based on the node count of that function. The thunk function's
>>> >> section name
>>> >> is not updated to be the same as the original here and also is not
>>> >> always
>>> >
Re: Fix aliases on AIX
On Mon, Jul 7, 2014 at 4:09 PM, Jan Hubicka wrote: > Hi, > AIX as' .set pseudoop has somewhat unexpected behaviour. It seems to be > implemented by syntactically replacin all appereances of the alias by > its target (that can be an expressoin) but it is still possible to globalize > the alias by .globl operation. > > This breaks the assumption we make about aliases; for example when alias is > declared static but it is alias of global/weak symbol, we assume it is static > symbol, but in AIX implementation it is handled as global. This breaks > horrible way for local aliases. > > Another unexpected behaviour is that .set output before definition of alias > target is silently compiled into something else (NULL?). We are not fully > consistent about outputing aliases after targets. > > This patch avoids use of .set for aliases. Instead > rs6000_xcoff_declare_object_name and rs6000_xcoff_declare_function_name simply > walk and outputs all associated aliases at the time they output function. > I.e. > > var: > > .set var, aliasvar > > Is now done as: > var: > aliasvar: > > > This avoids the surprises we was hitting on AIX and makes aliases to work > consistently. The way it is hooked into output machinery is not the most > beautiful, but I do not see better way except for redesigning the output > interface (adding new macro for this type of aliases) that seems to be > unnecesay > unless we find more targets that would benefit from aliases output this way. > > The testcases localalias/globalalias was added to check sanity of alias > implementation and this patch makes them to work. > > Bootstrapped/regtested rs6000-aix OK? Hi, Honza This looks really good and mostly is working. With the patch, GCC on AIX now responds that "ifunc" is supported. The C and C++ attr-ifunc testcases now run and fail. g++.dg/ipa/devirt-10 and devirt-15 now fail. Otherwise, the results look very good. Thanks, David
Re: [Patch, testsuite] PR61453 gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't "call"
On 7/8/2014 11:36 AM, Dominique Dhumieres wrote:
So can we settle for
--- ../_clean/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
2014-05-24 16:17:53.0 +0200
+++ gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90 2014-07-07
19:15:47.0 +0200
@@ -16,7 +16,7 @@ integer :: aa(4,4)
call test(aa)
end
-! { dg-final { scan-assembler-times "call\[^\n\r\]*myBindC" 1 { target { ! { hppa*-*-hpux* } } } } }
-! { dg-final { scan-assembler-times "call\[^\n\r\]*myBindC,%r2" 1 { target {
hppa*-*-hpux* } } } }
+! { dg-final { scan-assembler-times "\[ \t\]\[$,_0-9\]*myBindC" 1 { target { !
{ hppa*-*-hpux* } } } } }
+! { dg-final { scan-assembler-times "myBindC,%r2" 1 { target { hppa*-*-hpux* }
} } }
! { dg-final { scan-tree-dump-times "test \\\(&parm\\." 1 "original" } }
! { dg-final { cleanup-tree-dump "original" } }
As mentioned before, I would prefer that you change "hppa*-*-hpux*" to
"hppa*-*-*".
Dave
--
John David Anglindave.ang...@bell.net
Re: [PATCH 2/2] Emit DW_tag_restrict_type for restrict-qualified pointers.
Forgot to rebase my ChangeLog, sorry.
Here is the version with the correct one:
gcc/ChangeLog
PR debug/59051
* dwarf2out.h (modified_type_die): Handle TYPE_QUAL_RESTRICT.
gcc/testsuite/ChangeLog
PR debug/59051
* gcc.dg/guality/restrict.c: New test.
---
gcc/ChangeLog |5 +++
gcc/dwarf2out.c | 33 -
gcc/testsuite/ChangeLog |5 +++
gcc/testsuite/gcc.dg/guality/restrict.c | 48 +++
4 files changed, 83 insertions(+), 8 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/guality/restrict.c
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 3f63f1b..339f368 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,8 @@
+2014-07-08 Mark Wielaard
+
+ PR debug/59051
+ * dwarf2out.c (modified_type_die): Handle TYPE_QUAL_RESTRICT.
+
2014-07-07 Mark Wielaard
* dwarf2out.c (decl_quals): New function.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index 068bbc3..be17cad 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -10522,7 +10522,13 @@ modified_type_die (tree type, int cv_quals, dw_die_ref
context_die)
return NULL;
/* Only these cv-qualifiers are currently handled. */
- cv_quals &= (TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE);
+ cv_quals &= (TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE | TYPE_QUAL_RESTRICT);
+
+ /* Don't emit DW_TAG_restrict_type for DWARFv2, since it is a type
+ tag modifier (and not an attribute) old consumers won't be able
+ to handle it. */
+ if (dwarf_version < 3)
+cv_quals &= ~TYPE_QUAL_RESTRICT;
/* See if we already have the appropriately qualified variant of
this type. */
@@ -10567,7 +10573,7 @@ modified_type_die (tree type, int cv_quals, dw_die_ref
context_die)
else
{
int dquals = TYPE_QUALS_NO_ADDR_SPACE (dtype);
- dquals &= (TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE);
+ dquals &= (TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE | TYPE_QUAL_RESTRICT);
if ((dquals & ~cv_quals) != TYPE_UNQUALIFIED
|| (cv_quals == dquals && DECL_ORIGINAL_TYPE (name) != type))
/* cv-unqualified version of named type. Just use
@@ -10581,22 +10587,33 @@ modified_type_die (tree type, int cv_quals,
dw_die_ref context_die)
mod_scope = scope_die_for (type, context_die);
if ((cv_quals & TYPE_QUAL_CONST)
- /* If both const_type and volatile_type, prefer the path
-which leads to a qualified type. */
- && (!(cv_quals & TYPE_QUAL_VOLATILE)
- || get_qualified_type (type, TYPE_QUAL_CONST) == NULL_TREE
- || get_qualified_type (type, TYPE_QUAL_VOLATILE) != NULL_TREE))
+ /* If there are multiple type modifiers, prefer a path which
+leads to a qualified type. */
+ && (((cv_quals & ~TYPE_QUAL_CONST) == TYPE_UNQUALIFIED)
+ || get_qualified_type (type, cv_quals) == NULL_TREE
+ || (get_qualified_type (type, cv_quals & ~TYPE_QUAL_CONST)
+ != NULL_TREE)))
{
mod_type_die = new_die (DW_TAG_const_type, mod_scope, type);
sub_die = modified_type_die (type, cv_quals & ~TYPE_QUAL_CONST,
context_die);
}
- else if (cv_quals & TYPE_QUAL_VOLATILE)
+ else if ((cv_quals & TYPE_QUAL_VOLATILE)
+ && (((cv_quals & ~TYPE_QUAL_VOLATILE) == TYPE_UNQUALIFIED)
+ || get_qualified_type (type, cv_quals) == NULL_TREE
+ || (get_qualified_type (type, cv_quals & ~TYPE_QUAL_VOLATILE)
+ != NULL_TREE)))
{
mod_type_die = new_die (DW_TAG_volatile_type, mod_scope, type);
sub_die = modified_type_die (type, cv_quals & ~TYPE_QUAL_VOLATILE,
context_die);
}
+ else if (cv_quals & TYPE_QUAL_RESTRICT)
+{
+ mod_type_die = new_die (DW_TAG_restrict_type, mod_scope, type);
+ sub_die = modified_type_die (type, cv_quals & ~TYPE_QUAL_RESTRICT,
+ context_die);
+}
else if (code == POINTER_TYPE)
{
mod_type_die = new_die (DW_TAG_pointer_type, mod_scope, type);
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 1abc700..184ca67 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +1,8 @@
+2014-07-08 Mark Wielaard
+
+ PR debug/59051
+ * gcc.dg/guality/restrict.c: New test.
+
2014-07-03 Mark Wielaard
* lib/gcc-gdb-test.exp (gdb-test): Handle type:var for gdb ptype
diff --git a/gcc/testsuite/gcc.dg/guality/restrict.c
b/gcc/testsuite/gcc.dg/guality/restrict.c
new file mode 100644
index 000..e31224b
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/guality/restrict.c
@@ -0,0 +1,48 @@
+/* debuginfo tests for combinations of const, volatile, restrict pointers. */
+/* { dg-do run } */
+/* { dg-options "-std=c99 -gdwarf-3" } */
+
+int *ip;
+const int *cip;
+int * restrict irp;
+int * const icp;
+const int * restrict cirp;
+int
RE: [RFC PATCH] -Wmemset-transposed-args (PR middle-end/61294)
I don't think we want to warn about e.g. 1-1, only about literal 0.
Original Message
From: Jakub Jelinek
Sent: Tue, Jul 8, 2014 05:50 AM
To: Joseph S. Myers ; Jason Merrill
; Carlos O'Donell ; Siddhesh Poyarekar
CC: gcc-patches@gcc.gnu.org; libc-al...@sourceware.org
Subject: [RFC PATCH] -Wmemset-transposed-args (PR middle-end/61294)
Hi!
This is an attempt to move the warning about transposed memset arguments
from the glibc headers to gcc FEs. The problem with the warning in glibc
is that it uses __builtin_constant_p and e.g. jump threading very often
makes the warning trigger even on code where it is very unlikely a user
swapped arguments. See e.g.
https://gcc.gnu.org/PR51744
https://gcc.gnu.org/PR56977
https://gcc.gnu.org/PR61294
https://bugzilla.redhat.com/452219
https://bugs.kde.org/show_bug.cgi?id=311098
https://bugzilla.mozilla.org/show_bug.cgi?id=581227
and many others. Thus, I'd like to warn in the FEs instead, and
once we have a GCC release with that warning in, disable the glibc
bits/string3.h:
if (__builtin_constant_p (__len) && __len == 0
&& (!__builtin_constant_p (__ch) || __ch != 0))
{
__warn_memset_zero_len ();
return __dest;
}
warning for GCC versions with that new warning in.
Any thoughts on this?
If you are ok with it, either we can add it only for 4.10/5.0 and
later only, or perhaps 4.9.2 too, or even 4.9.1. For -D_FORTIFY_SOURCE=2
built code with glibc it shouldn't make a difference (other than having
fewer false positives), but for other non-fortified -Wall compilation
it would make a difference (introducing new warnings), so perhaps
doing it only for 4.10/5.0+ is best.
2014-07-08 Jakub Jelinek
PR middle-end/61294
gcc/c-family/
* c.opt (Wmemset-transposed-args): New warning.
gcc/c/
* c-typeck.c (c_build_function_call_vec): Handle
-Wmemset-transposed-args.
gcc/cp/
* semantics.c (finish_call_expr): Handle -Wmemset-transposed-args.
gcc/
* doc/invoke.texi (-Wmemset-transposed-args): Document.
gcc/testsuite/
* c-c++-common/Wmemset-transposed-args1.c: New test.
* g++.dg/warn/Wmemset-transposed-args-1.C: New test.
--- gcc/c-family/c.opt.jj 2014-07-07 10:39:43.0 +0200
+++ gcc/c-family/c.opt 2014-07-08 13:12:07.755536537 +0200
@@ -518,6 +518,10 @@ Wmain
LangEnabledBy(C ObjC C++ ObjC++,Wpedantic, 2, 0)
;
+Wmemset-transposed-args
+C ObjC C++ ObjC++ Var(warn_memset_transposed_args) Warning LangEnabledBy(C
ObjC C++ ObjC++,Wall)
+Warn about suspicious call to memset where the third argument is constant zero
and second is not zero
+
Wmissing-braces
C ObjC C++ ObjC++ Var(warn_missing_braces) Warning LangEnabledBy(C ObjC,Wall)
Warn about possibly missing braces around initializers
--- gcc/c/c-typeck.c.jj 2014-07-07 10:39:43.0 +0200
+++ gcc/c/c-typeck.c2014-07-08 13:22:36.846564329 +0200
@@ -2987,6 +2987,16 @@ c_build_function_call_vec (location_t lo
/* Convert anything with function type to a pointer-to-function. */
if (TREE_CODE (function) == FUNCTION_DECL)
{
+ if (warn_memset_transposed_args
+ && DECL_BUILT_IN_CLASS (function) == BUILT_IN_NORMAL
+ && DECL_FUNCTION_CODE (function) == BUILT_IN_MEMSET
+ && vec_safe_length (params) == 3
+ && integer_zerop ((*params)[2])
+ && !integer_zerop ((*params)[1]))
+ warning_at (loc, OPT_Wmemset_transposed_args,
+ "% used with constant zero length parameter; "
+ "this could be due to transposed parameters");
+
/* Implement type-directed function overloading for builtins.
resolve_overloaded_builtin and targetm.resolve_overloaded_builtin
handle all the type checking. The result is a complete expression
--- gcc/cp/semantics.c.jj 2014-07-02 09:04:13.0 +0200
+++ gcc/cp/semantics.c 2014-07-08 14:02:45.936782580 +0200
@@ -2361,6 +2361,18 @@ finish_call_expr (tree fn, vec used with constant zero length parameter; "
+"this could be due to transposed parameters");
+
/* A call to a namespace-scope function. */
result = build_new_function_call (fn, args, koenig_p, complain);
}
--- gcc/doc/invoke.texi.jj 2014-07-08 11:36:14.0 +0200
+++ gcc/doc/invoke.texi 2014-07-08 14:20:09.932799699 +0200
@@ -257,8 +257,8 @@ Objective-C and Objective-C++ Dialects}.
-Wno-int-to-pointer-cast -Wno-invalid-offsetof @gol
-Winvalid-pch -Wlarger-than=@var{len} -Wunsafe-loop-optimizations @gol
-Wlogical-op -Wlogical-not-parentheses -Wlong-long @gol
--Wmain -Wmaybe-uninitialized -Wmissing-braces -Wmissing-field-initializers
@gol
--Wmissing-include-dirs @gol
+-Wmain -Wmaybe-uninitialized -Wmemset-transposed-args -Wmissing-braces @gol
+-Wmissing-field-initializers -Wmissing-include-dirs @gol
-Wno-multichar -Wnonnull -Wno-overflow -Wopenmp-simd @gol
-Woverlength-strings -Wpacked -Wpacked-bitfield-compat -Wpadded @gol
-Wparen
Re: [RFC PATCH] -Wmemset-transposed-args (PR middle-end/61294)
On 07/08/2014 08:50 AM, Jakub Jelinek wrote:
> Hi!
>
> This is an attempt to move the warning about transposed memset arguments
> from the glibc headers to gcc FEs. The problem with the warning in glibc
> is that it uses __builtin_constant_p and e.g. jump threading very often
> makes the warning trigger even on code where it is very unlikely a user
> swapped arguments. See e.g.
> https://gcc.gnu.org/PR51744
> https://gcc.gnu.org/PR56977
> https://gcc.gnu.org/PR61294
> https://bugzilla.redhat.com/452219
> https://bugs.kde.org/show_bug.cgi?id=311098
> https://bugzilla.mozilla.org/show_bug.cgi?id=581227
> and many others. Thus, I'd like to warn in the FEs instead, and
> once we have a GCC release with that warning in, disable the glibc
> bits/string3.h:
> if (__builtin_constant_p (__len) && __len == 0
> && (!__builtin_constant_p (__ch) || __ch != 0))
> {
> __warn_memset_zero_len ();
> return __dest;
> }
> warning for GCC versions with that new warning in.
>
> Any thoughts on this?
>
> If you are ok with it, either we can add it only for 4.10/5.0 and
> later only, or perhaps 4.9.2 too, or even 4.9.1. For -D_FORTIFY_SOURCE=2
> built code with glibc it shouldn't make a difference (other than having
> fewer false positives), but for other non-fortified -Wall compilation
> it would make a difference (introducing new warnings), so perhaps
> doing it only for 4.10/5.0+ is best.
This seems like a sensible solution to fixing the false positives
caused by jump threading (I haven't looked into that in detail,
just briefly).
I would prefer we enable this for 4.10/5.0+ if only to avoid the
fallout (new warnings) that would happen for the distributions.
We can fix the glibc header once the fix is in gcc, unless someone
objects to the fix itself.
Cheers,
Carlos.
Re: [RFC PATCH] -Wmemset-transposed-args (PR middle-end/61294)
On 07/08/2014 03:24 PM, Jason Merrill wrote: > I don't think we want to warn about e.g. 1-1, only about literal 0. What rationale would you give for not warning on 1-1? Cheers, Carlos.
Re: [PATCH, AArch64, Testsuite] Specify -fno-use-caller-save for func-ret* tests
On 01-07-14 19:26, Jeff Law wrote:
On 07/01/14 09:51, Yufeng Zhang wrote:
Hi,
This patch resolves a conflict between the aapcs64 test framework for
func-ret tests and the optimization option -fuse-caller-save, which was
enabled by default at -O1 or above recently.
Minor detail: it's enabled by default at -O2 or above:
...
{ OPT_LEVELS_2_PLUS, OPT_fuse_caller_save, NULL, 1 },
...
Basically, the test framework has an inline-assembly based mechanism in
place which invokes the test facility function right on the return of a
tested function.
>> The compiler with -fuse-caller-save is unable to
>> identify the unconventional call graph and carries out the optimization
>> regardless.
AFAIU, we're overwriting the return register to implement a function call at
return in order to see the exact state of registers at return:
...
__attribute__ ((noinline)) unsigned char
func_return_val_0 (int i, double d, unsigned char t)
{
asm (""::"r" (i),"r" (d));
asm volatile ("mov %0, x30" : "=r" (saved_return_address));
asm volatile ("mov x30, %0" : : "r" ((unsigned long long) myfunc));
return t;
}
...
But we're not informing the compiler that a hidden function call takes place.
This patch fixes that, and there's no need to disable fuse-caller-save.
Tested with aarch64 build. OK for trunk?
Thanks,
- Tom
2014-07-08 Tom de Vries
* gcc.target/aarch64/aapcs64/aapcs64.exp
(additional_flags_for_func_ret): Remove.
(func-ret-*.c): Use additional_flags.
* gcc.target/aarch64/aapcs64/abitest-2.h (FUNC_VAL_CHECK): Add missing
call_used_regs clobbers.
Index: gcc/testsuite/gcc.target/aarch64/aapcs64/aapcs64.exp
===
--- gcc/testsuite/gcc.target/aarch64/aapcs64/aapcs64.exp (revision 212294)
+++ gcc/testsuite/gcc.target/aarch64/aapcs64/aapcs64.exp (working copy)
@@ -48,15 +48,11 @@ foreach src [lsort [glob -nocomplain $sr
}
# Test function return value.
-# Disable -fuse-caller-save to prevent the compiler from generating
-# conflicting code.
-set additional_flags_for_func_ret $additional_flags
-append additional_flags_for_func_ret " -fno-use-caller-save"
foreach src [lsort [glob -nocomplain $srcdir/$subdir/func-ret-*.c]] {
if {[runtest_file_p $runtests $src]} {
c-torture-execute [list $src \
$srcdir/$subdir/abitest.S] \
-$additional_flags_for_func_ret
+$additional_flags
}
}
Index: gcc/testsuite/gcc.target/aarch64/aapcs64/abitest-2.h
===
--- gcc/testsuite/gcc.target/aarch64/aapcs64/abitest-2.h (revision 212294)
+++ gcc/testsuite/gcc.target/aarch64/aapcs64/abitest-2.h (working copy)
@@ -80,10 +80,18 @@ __attribute__ ((noinline)) type FUNC_NAM
The previous approach of sequentially calling myfunc right after \
this function does not guarantee myfunc see the exact register \
content, as compiler may emit code in between the two calls, \
- especially during the -O0 codegen. */ \
+ especially during the -O0 codegen. \
+ However, since we're doing a call, we need to clobber all call \
+ used regs. */ \
asm volatile ("mov %0, x30" : "=r" (saved_return_address)); \
-asm volatile ("mov x30, %0" : : "r" ((unsigned long long) myfunc)); \
-return t; \
+asm volatile ("mov x30, %0" : : "r" ((unsigned long long) myfunc) : \
+ "x0", "x1", "x2", "x3", "x4", "x5", "x6", "x7", \
+ "x8", "x9", "x10", "x11", "x12", "x13", "x14", "x15", \
+ "x16", "x17", "x18", \
+ "v0", "v1", "v2", "v3", "v4", "v5", "v6", "v7", \
+ "v16", "v17", "v18", "v19", "v20", "v21", "v22", "v23", \
+ "v24", "v25", "v26", "v27", "v28", "v29", "v30", "v31");\
+return t;\
}
#include TESTFILE
[PATCH] java: Use build_qualified_type instead of build_type_variant.
The java frontend is one of the only places where build_type_variant is still used. New code should use build_qualified_type. See gcc/tree.h. Build and tested on x86_64-unknown-linux-gnu. gcc/java/ChangeLog * builtins.c (putVolatile_builtin): Use build_qualified_type instead of build_type_variant. (getVolatile_builtin): Likewise. (build_classdollar_field): Likewise. --- gcc/java/ChangeLog |7 +++ gcc/java/builtins.c |8 +--- gcc/java/class.c|8 3 files changed, 16 insertions(+), 7 deletions(-) diff --git a/gcc/java/ChangeLog b/gcc/java/ChangeLog index ce90e28..d12b664 100644 --- a/gcc/java/ChangeLog +++ b/gcc/java/ChangeLog @@ -1,3 +1,10 @@ +2014-07-08 Mark Wielaard + + * builtins.c (putVolatile_builtin): Use build_qualified_type + instead of build_type_variant. + (getVolatile_builtin): Likewise. + (build_classdollar_field): Likewise. + 2014-06-24 Trevor Saunders * jcf-io.c: Adjust. diff --git a/gcc/java/builtins.c b/gcc/java/builtins.c index 1ce9ce5..12c427d 100644 --- a/gcc/java/builtins.c +++ b/gcc/java/builtins.c @@ -394,7 +394,8 @@ putVolatile_builtin (tree method_return_type ATTRIBUTE_UNUSED, addr = build_addr_sum (value_type, obj_arg, offset_arg); addr -= fold_convert (build_pointer_type (build_type_variant (value_type, 0, 1)), += fold_convert (build_pointer_type (build_qualified_type + (value_type, TYPE_QUAL_VOLATILE)), addr); stmt = build_call_expr (builtin_decl_explicit (BUILT_IN_SYNC_SYNCHRONIZE), 0); @@ -418,8 +419,9 @@ getVolatile_builtin (tree method_return_type ATTRIBUTE_UNUSED, addr = build_addr_sum (method_return_type, obj_arg, offset_arg); addr -= fold_convert (build_pointer_type (build_type_variant - (method_return_type, 0, 1)), addr); += fold_convert (build_pointer_type (build_qualified_type + (method_return_type, +TYPE_QUAL_VOLATILE)), addr); stmt = build_call_expr (builtin_decl_explicit (BUILT_IN_SYNC_SYNCHRONIZE), 0); tmp = build_decl (BUILTINS_LOCATION, VAR_DECL, NULL, method_return_type); diff --git a/gcc/java/class.c b/gcc/java/class.c index dae3218..0d51165 100644 --- a/gcc/java/class.c +++ b/gcc/java/class.c @@ -1067,11 +1067,11 @@ build_classdollar_field (tree type) decl = build_decl (input_location, VAR_DECL, decl_name, - (build_type_variant + (build_qualified_type (build_pointer_type - (build_type_variant (class_type_node, -/* const */ 1, 0)), - /* const */ 1, 0))); + (build_qualified_type (class_type_node, + TYPE_QUAL_CONST)), + TYPE_QUAL_CONST))); TREE_STATIC (decl) = 1; TREE_CONSTANT (decl) = 1; TREE_READONLY (decl) = 1; -- 1.7.1
Re: [RFC PATCH] -Wmemset-transposed-args (PR middle-end/61294)
On Tue, Jul 08, 2014 at 03:24:52PM -0400, Jason Merrill wrote: > I don't think we want to warn about e.g. 1-1, only about literal 0. Well, at least literal 0 and '\0'. In any case, it seems both the C and C++ FEs fold the arguments too early, already during the parsing of the argument list. In the C FE, there is original_code in the c_expr struct, so perhaps I could somehow propagate it to the caller for the first few arguments and test that original_code is INTEGER_CST in addition to integer_zerop to check for literal 0. But in the C++ FE there isn't something like that. Do you think we shouldn't warn even if e.g. the last argument is a template parameter that turns out to be 0, so warn only during parsing and check for literal 0 and not warn again during instantiation? Any suggestions how to find out if it was literal 0 or something that folded to 0 in the C++ FE? Jakub
Re: Fix representation of gcov_info_type
> You probably can't. But check what the C frontend ends up producing with
>
> Struct x { const struct x *p; };
>
> Doesn't it use an incomplete copy during the definition of x?
I was poking around this last week with the type identification. C frontend
seems
always make the type complete by copying the fields in c-decl.c:finish_struct.
I tried to add check that types are complete when main variant is and learnt
that
C++ FE seems in some cases leave the type incomplete even if main variant is
complete
but not in such a simple cases. I will look into it a bit more after arrival -
but
that is my recollection. The finish_builtin_struct was only case where we set
DECL_SIZE but not DECL_FIELDS
Honza
>
> Richard.
>
> >Thanks,
> >Honza
>
Go patch committed: Fix C-style comment parsing
PR 61746 and gofrontend issue 35 point out a bug in C-style comment
parsing in the Go frontend. The sequence /*/ was interpreted as a
complete C-style comment. This patch fixes the bug. Bootstrapped and
ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline and
4.9 branch.
Ian
diff -r 5d0434c2007e go/lex.cc
--- a/go/lex.cc Wed Jul 02 07:22:05 2014 -0700
+++ b/go/lex.cc Tue Jul 08 13:41:25 2014 -0700
@@ -598,7 +598,7 @@
}
else if (p[1] == '*')
{
- this->lineoff_ = p - this->linebuf_;
+ this->lineoff_ = p + 2 - this->linebuf_;
Location location = this->location();
if (!this->skip_c_comment())
return Token::make_invalid_token(location);
Re: [Patch, testsuite] PR61453 gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't "call"
> As mentioned before, I would prefer that you change "hppa*-*-hpux*" to > "hppa*-*-*". Done in my tree so I won't forget. Now someone has to approve the patch! Dominique
Go patch commtited: Convert array start index before bounds check
This patch from Chris Manghane fixes an ICE-on-invalid in the gccgo
frontend, reported as PR 61308. The fix is to convert an array start
index to int before doing a bounds check on the type. Bootstrapped and
ran Go testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r d53fa58639b9 go/expressions.cc
--- a/go/expressions.cc Tue Jul 08 13:42:21 2014 -0700
+++ b/go/expressions.cc Tue Jul 08 14:12:32 2014 -0700
@@ -10218,7 +10218,8 @@
Location loc = this->location();
Gogo* gogo = context->gogo();
- Btype* int_btype = Type::lookup_integer_type("int")->get_backend(gogo);
+ Type* int_type = Type::lookup_integer_type("int");
+ Btype* int_btype = int_type->get_backend(gogo);
// We need to convert the length and capacity to the Go "int" type here
// because the length of a fixed-length array could be of type "uintptr"
@@ -10259,8 +10260,15 @@
: RUNTIME_ERROR_SLICE_SLICE_OUT_OF_BOUNDS));
Bexpression* crash = gogo->runtime_error(code, loc)->get_backend(context);
+ if (this->start_->type()->integer_type() == NULL
+ && !Type::are_convertible(int_type, this->start_->type(), NULL))
+{
+ go_assert(saw_errors());
+ return context->backend()->error_expression();
+}
+ Expression* start_expr = Expression::make_cast(int_type, this->start_, loc);
Bexpression* bad_index =
-Expression::check_bounds(this->start_, loc)->get_backend(context);
+Expression::check_bounds(start_expr, loc)->get_backend(context);
Bexpression* start = this->start_->get_backend(context);
start = gogo->backend()->convert_expression(int_btype, start, loc);
Re: [PATCH] Don't ICE with huge alignment (PR middle-end/60226)
> ... > diff --git gcc/testsuite/c-c++-common/pr60226.c > gcc/testsuite/c-c++-common/pr60226.c > ... The test fails on x86_64-apple-darwin13 with FAIL: c-c++-common/pr60226.c -std=gnu++98 (test for excess errors) Excess errors: /opt/gcc/work/gcc/testsuite/c-c++-common/pr60226.c:6:7: error: alignment of 'foo' is greater than maximum object file alignment 32768 Dominique
Re: [C++ Patch] PR 57466 (DR 1584)
I'd rather handle this in check_cv_quals_for_unify. Jason
[wwwdocs,Java] bin/gen-classpath-compare: http -> https
Java guys, -- do you still need this script or can it be removed? For now I went ahead and applied the patch below which converts the reference to the style sheet from http to https. Gerald Index: bin/gen-classpath-compare === RCS file: /cvs/gcc/wwwdocs/bin/gen-classpath-compare,v retrieving revision 1.17 diff -u -r1.17 gen-classpath-compare --- bin/gen-classpath-compare 23 Sep 2004 22:46:06 - 1.17 +++ bin/gen-classpath-compare 8 Jul 2014 22:18:39 - @@ -45,7 +45,7 @@ rm -f $OUTPUT/compare/*.diff echo " libgcj -vs- Classpath ($GUI)" > $outfile -echo 'http://gcc.gnu.org/gcc.css";>' >> $outfile +echo 'https://gcc.gnu.org/gcc.css";>' >> $outfile echo " libgcj -vs- Classpath ($GUI)" >> $outfile cat >> $outfile << 'END'
Re: [RFC PATCH] -Wmemset-transposed-args (PR middle-end/61294)
On 07/08/2014 12:38 PM, Carlos O'Donell wrote: What rationale would you give for not warning on 1-1? Because it's not likely to be a case of argument transposition; it's more likely to be an expression that just happens to evaluate to 0, which is fine as a length argument to memset. On 07/08/2014 01:31 PM, Jakub Jelinek wrote: On Tue, Jul 08, 2014 at 03:24:52PM -0400, Jason Merrill wrote: I don't think we want to warn about e.g. 1-1, only about literal 0. Well, at least literal 0 and '\0'. Right, I consider '\0' to be a literal 0. But in the C++ FE there isn't something like that. Do you think we shouldn't warn even if e.g. the last argument is a template parameter that turns out to be 0, so warn only during parsing and check for literal 0 and not warn again during instantiation? Yes, that's what I think. Any suggestions how to find out if it was literal 0 or something that folded to 0 in the C++ FE? I suppose we could use an INTEGER_CST distinct from the one in TYPE_CACHED_VALUES for raw 0, with a TREE_LANG_FLAG set. Jason
Re: [C++ Patch] PR 60686
On 07/07/2014 11:15 AM, Paolo Carlini wrote:
+ error ("only declarations can be marked %");
That's pretty unclear, since a definition is a declaration.
Let's split this into three error messages: If the problem is that we're
outside the class, we should say that. If the problem is that it's not
a constructor or conversion function, we should say that. If the
problem is that it's not a member of the current class, we should say that.
Jason
Re: [C++ Patch] PR 58155 - -Wliteral-suffix warns about tokens which are skipped
On 07/07/2014 07:20 AM, Ed Smith-Rowland wrote: OK? And for 4.9? Yes. Jason
Re: Fix aliases on AIX
The problem with devirt-10 and devirt-15 is the excellent kludge for aliases on AIX can produce multiple symbols. ipa-prop: Discovered a virtual call to a known target (void wxBufferedDC::InitCommon(wxDCBase*)/3 -> virtual void wxDCBase::_ZN8wxDCBase18SetLayoutDirectionEi.localalias.6(int)/36), for stmt OBJ_TYPE_REF(_6;_7->1) (_7, _11); Speculative call turned into direct call. ipa-prop: Discovered a virtual call to a known target (void wxBufferedDC::InitCommon(wxDCBase*)/3 -> virtual int wxDCBase::_ZNK8wxDCBase18GetLayoutDirectionEv.localalias.5() const/35), for stmt _11 = OBJ_TYPE_REF(_9;dc_2(D)->0) (dc_2(D)); The testcase expects exactly 1 occurrence, but the new code produces 2 for AIX. What is the best way to adjust the testcases? Thanks, David
[wwwdocs] Adjust a reference to an SVN file to https
...and convert one from cvsweb to SVN. Applied. Gerald Index: bugs/reghunt.html === RCS file: /cvs/gcc/wwwdocs/htdocs/bugs/reghunt.html,v retrieving revision 1.19 diff -u -r1.19 reghunt.html --- bugs/reghunt.html 29 Jun 2014 11:31:33 - 1.19 +++ bugs/reghunt.html 8 Jul 2014 23:59:52 - @@ -52,7 +52,7 @@ The first three steps are described below. They can be automated, as can the framework for the binary search. The directory http://gcc.gnu.org/svn/gcc/trunk/contrib/reghunt/";> +href="https://gcc.gnu.org/svn/gcc/trunk/contrib/reghunt/";> contrib/reghunt in the GCC repository includes scripts to do this work. Index: codingconventions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v retrieving revision 1.70 diff -u -r1.70 codingconventions.html --- codingconventions.html 27 Jun 2014 11:48:45 - 1.70 +++ codingconventions.html 8 Jul 2014 23:59:52 - @@ -165,7 +165,7 @@ C code should avoid pre-standard style function definitions, unnecessary function prototypes and use of the now deprecated PARAMS macro. See http://gcc.gnu.org/cgi-bin/cvsweb.cgi/~checkout~/gcc/gcc/README.Portability?content-type=text/plain&only_with_tag=HEAD";>README.Portability +href="https://gcc.gnu.org/svn/gcc/trunk/gcc/README.Portability";>README.Portability for details of some of the portability problems that may arise. Some of these problems are warned about by gcc -Wtraditional, which is included in the default warning options in a bootstrap.
Re: [Patch, testsuite] PR61453 gfortran.dg/bind_c_array_params_2.f90 for targets where a call insn isn't "call"
On Jul 8, 2014, at 2:07 PM, Dominique Dhumieres wrote: >> As mentioned before, I would prefer that you change "hppa*-*-hpux*" to >> "hppa*-*-*". > > Done in my tree so I won't forget. Now someone has to approve the patch! Ok. :-) I usually just expect people to check in such minor stuff once the discussion dies down and all the good feedback is incorporated.
Re: [PATCH] Don't ICE with huge alignment (PR middle-end/60226)
On Jul 8, 2014, at 3:12 PM, Dominique Dhumieres wrote:
>> diff --git gcc/testsuite/c-c++-common/pr60226.c
>> gcc/testsuite/c-c++-common/pr60226.c
>
> The test fails on x86_64-apple-darwin13 with
>
> FAIL: c-c++-common/pr60226.c -std=gnu++98 (test for excess errors)
> Excess errors:
> /opt/gcc/work/gcc/testsuite/c-c++-common/pr60226.c:6:7: error: alignment of
> 'foo' is greater than maximum object file alignment 32768
Fixed, thanks.
Index: pr60226.c
===
--- pr60226.c (revision 212379)
+++ pr60226.c (working copy)
@@ -4,7 +4,7 @@
typedef int __attribute__ ((aligned (1 << 28))) int28;
int28 foo[4] = {}; /* { dg-error "alignment of array elements is greater than
element size" } */
-typedef int __attribute__ ((aligned (1 << 29))) int29; /* { dg-error
"requested alignment is too large" } */
+typedef int __attribute__ ((aligned (1 << 29))) int29; /* { dg-error
"requested alignment is too large|maximum object file alignment" } */
void
f (void)
Re: [C++ Patch] PR 59361
OK. Jason
Re: [Patch, PR 61720] Clear regex BFS match queue after every iteration
On Mon, Jul 7, 2014 at 1:24 AM, Paolo Carlini wrote:
> Bah... too bad we have to resort to this. Then please summarize the
> discussion at the beginning of the file: what the file is *exactly* for (an
> accidental contributor should be able to understand if and what should go in
> it) and why it does exist in the first place. Also, please remember the test
> variables.
I think it is possible (but not for sure) to reduce compile time by
rewriting _Compiler. I did some simple compile time profiling on regex
and made that conclusion but I don't know why.
--
Regards,
Tim Shen
commit 5fdfa3c31049d0e1ef5166f148e9ac4906bc490a
Author: timshen
Date: Sun Jul 6 01:40:32 2014 -0700
PR libstdc++/61720
* include/bits/regex_executor.tcc (_Executor<>::_M_main_dispatch):
Clear match queue for next use.
* testsuite/28_regex/general_testcases.cc: New file for general
testcases.
diff --git a/libstdc++-v3/include/bits/regex_executor.tcc
b/libstdc++-v3/include/bits/regex_executor.tcc
index 38b8ff2..3c68668 100644
--- a/libstdc++-v3/include/bits/regex_executor.tcc
+++ b/libstdc++-v3/include/bits/regex_executor.tcc
@@ -137,6 +137,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
if (__match_mode == _Match_mode::_Exact)
__ret = _M_has_sol;
+ _M_states._M_match_queue.clear();
return __ret;
}
diff --git a/libstdc++-v3/testsuite/28_regex/general_testcases.cc
b/libstdc++-v3/testsuite/28_regex/general_testcases.cc
new file mode 100644
index 000..c7372ab
--- /dev/null
+++ b/libstdc++-v3/testsuite/28_regex/general_testcases.cc
@@ -0,0 +1,53 @@
+// { dg-options "-std=gnu++11" }
+
+//
+// Copyright (C) 2014 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+//
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+//
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+//
[texi2pod.pl] Handle command @t and embedded form @dfn{@sc{}}
Hello,
As discussed in
https://sourceware.org/ml/gdb-patches/2014-07/msg00145.html, I'd like
to put the patch for texi2pod.pl here. The patch is necessary to
output the gdb man manual correctly for such cases,
G@{++}
and
@dfn{@sc{gdb/mi} interface}
contrib/ChangeLog
2014-07-09 Mingjie Xing
* texi2pod.pl (postprocess): Move command process for '@sc' to the
front of '@dfn'. Add a new command process for '@t{...}', just print
the content.
Is it OK?
Best regards,
Mingjie
Index: contrib/texi2pod.pl
===
--- contrib/texi2pod.pl (revision 212380)
+++ contrib/texi2pod.pl (working copy)
@@ -389,15 +389,16 @@
# Formatting commands.
# Temporary escape for @r.
s/\@r\{([^\}]*)\}/R<$1>/g;
+s/\@sc\{([^\}]*)\}/\U$1/g;
s/\@(?:dfn|var|emph|cite|i)\{([^\}]*)\}/I<$1>/g;
s/\@(?:code|kbd)\{([^\}]*)\}/C<$1>/g;
s/\@(?:samp|strong|key|option|env|command|b)\{([^\}]*)\}/B<$1>/g;
-s/\@sc\{([^\}]*)\}/\U$1/g;
s/\@acronym\{([^\}]*)\}/\U$1/g;
s/\@file\{([^\}]*)\}/F<$1>/g;
s/\@w\{([^\}]*)\}/S<$1>/g;
s/\@(?:dmn|math)\{([^\}]*)\}/$1/g;
s/\@\///g;
+s/\@t\{([^\}]*)\}/$1/g;
# keep references of the form @ref{...}, print them bold
s/\@(?:ref)\{([^\}]*)\}/B<$1>/g;
Re: [PATCH] Support addsub/subadd as non-isomorphic operations for SLP vectorizer.
Cong, can you ping this patch again? There does not seem to be
pending comments left.
David
On Tue, Dec 17, 2013 at 10:05 AM, Cong Hou wrote:
> Ping?
>
>
> thanks,
> Cong
>
>
> On Mon, Dec 2, 2013 at 5:02 PM, Cong Hou wrote:
>> Any comment on this patch?
>>
>>
>> thanks,
>> Cong
>>
>>
>> On Fri, Nov 22, 2013 at 11:40 AM, Cong Hou wrote:
>>> On Fri, Nov 22, 2013 at 3:57 AM, Marc Glisse wrote:
On Thu, 21 Nov 2013, Cong Hou wrote:
> On Thu, Nov 21, 2013 at 4:39 PM, Marc Glisse wrote:
>>
>> On Thu, 21 Nov 2013, Cong Hou wrote:
>>
>>> While I added the new define_insn_and_split for vec_merge, a bug is
>>> exposed: in config/i386/sse.md, [ define_expand "xop_vmfrcz2" ]
>>> only takes one input, but the corresponding builtin functions have two
>>> inputs, which are shown in i386.c:
>>>
>>> { OPTION_MASK_ISA_XOP, CODE_FOR_xop_vmfrczv4sf2,
>>> "__builtin_ia32_vfrczss", IX86_BUILTIN_VFRCZSS, UNKNOWN,
>>> (int)MULTI_ARG_2_SF },
>>> { OPTION_MASK_ISA_XOP, CODE_FOR_xop_vmfrczv2df2,
>>> "__builtin_ia32_vfrczsd", IX86_BUILTIN_VFRCZSD, UNKNOWN,
>>> (int)MULTI_ARG_2_DF },
>>>
>>> In consequence, the ix86_expand_multi_arg_builtin() function tries to
>>> check two args but based on the define_expand of xop_vmfrcz2,
>>> the content of insn_data[CODE_FOR_xop_vmfrczv4sf2].operand[2] may be
>>> incorrect (because it only needs one input).
>>>
>>> The patch below fixed this issue.
>>>
>>> Bootstrapped and tested on ax x86-64 machine. Note that this patch
>>> should be applied before the one I sent earlier (sorry for sending
>>> them in wrong order).
>>
>>
>>
>> This is PR 56788. Your patch seems strange to me and I don't think it
>> fixes the real issue, but I'll let more knowledgeable people answer.
>
>
>
> Thank you for pointing out the bug report. This patch is not intended
> to fix PR56788.
IMHO, if PR56788 was fixed, you wouldn't have this issue, and if PR56788
doesn't get fixed, I'll post a patch to remove _mm_frcz_sd and the
associated builtin, which would solve your issue as well.
>>>
>>>
>>> I agree. Then I will wait until your patch is merged to the trunk,
>>> otherwise my patch could not pass the test.
>>>
>>>
> For your function:
>
> #include
> __m128d f(__m128d x, __m128d y){
> return _mm_frcz_sd(x,y);
> }
>
> Note that the second parameter is ignored intentionally, but the
> prototype of this function contains two parameters. My fix is
> explicitly telling GCC that the optab xop_vmfrczv4sf3 should have
> three operands instead of two, to let it have the correct information
> in insn_data[CODE_FOR_xop_vmfrczv4sf3].operand[2] which is used to
> match the type of the second parameter in the builtin function in
> ix86_expand_multi_arg_builtin().
I disagree that this is intentional, it is a bug. AFAIK there is no AMD
documentation that could be used as a reference for what _mm_frcz_sd is
supposed to do. The only existing documentations are by Microsoft (which
does *not* ignore the second argument) and by LLVM (which has a single
argument). Whatever we chose for _mm_frcz_sd, the builtin should take a
single argument, and if necessary we'll use 2 builtins to implement
_mm_frcz_sd.
>>>
>>>
>>> I also only found the one by Microsoft.. If the second argument is
>>> ignored, we could just remove it, as long as there is no "standard"
>>> that requires two arguments. Hopefully it won't break current projects
>>> using _mm_frcz_sd.
>>>
>>> Thank you for your comments!
>>>
>>>
>>> Cong
>>>
>>>
--
Marc Glisse
[PATCH] Fix bootstrap with ICL
[I couldn't find a patch submission address for ICL, so I'm sending this
here]
With ICL enabled and an LTO boot strap the ICL build always errors
out due to -Werror=maybe-undefined. The following patch fixes
the LTO build for me by initializing the variables in question.
All warnings were false positives as far as I can tell.
diff -u isl-0.12.2/isl_map_simplify.c-o isl-0.12.2/isl_map_simplify.c
--- isl-0.12.2/isl_map_simplify.c-o 2014-07-08 08:14:40.770984188 -0700
+++ isl-0.12.2/isl_map_simplify.c 2014-07-08 08:15:32.370982573 -0700
@@ -3004,7 +3004,7 @@
for (i = 0; i < bmap->n_div; ++i) {
int pos, neg;
- int last_pos, last_neg;
+ int last_pos = 0, last_neg = 0;
int redundant;
int defined;
diff -u isl-0.12.2/isl_ast.c-o isl-0.12.2/isl_ast.c
--- isl-0.12.2/isl_ast.c-o 2014-07-08 08:02:23.375007276 -0700
+++ isl-0.12.2/isl_ast.c2014-07-08 08:03:25.403005334 -0700
@@ -170,6 +170,9 @@
break;
case isl_ast_expr_error:
dup = NULL;
+ break;
+ default:
+ return NULL;
}
if (!dup)
diff -u isl-0.12.2/basis_reduction_templ.c-o isl-0.12.2/basis_reduction_templ.c
--- isl-0.12.2/basis_reduction_templ.c-o2014-07-08 08:13:05.178987181
-0700
+++ isl-0.12.2/basis_reduction_templ.c 2014-07-08 08:13:45.374985923 -0700
@@ -54,7 +54,7 @@
int i;
GBR_LP *lp = NULL;
GBR_type F_old, alpha, F_new;
- int row;
+ int row = 0;
isl_int tmp;
struct isl_vec *b_tmp;
GBR_type *F = NULL;
diff -u isl-0.12.2/isl_tab.c-o isl-0.12.2/isl_tab.c
--- isl-0.12.2/isl_tab.c-o 2014-07-08 08:09:55.782993111 -0700
+++ isl-0.12.2/isl_tab.c2014-07-08 08:11:45.694989670 -0700
@@ -2686,7 +2686,7 @@
n_marked++;
}
while (n_marked) {
- struct isl_tab_var *var;
+ struct isl_tab_var *var = NULL;
int sgn;
for (i = tab->n_redundant; i < tab->n_row; ++i) {
var = isl_tab_var_from_row(tab, i);
@@ -2886,7 +2886,7 @@
n_marked++;
}
while (n_marked) {
- struct isl_tab_var *var;
+ struct isl_tab_var *var = NULL;
int red;
for (i = tab->n_redundant; i < tab->n_row; ++i) {
var = isl_tab_var_from_row(tab, i);
diff -u isl-0.12.2/isl_sample.c-o isl-0.12.2/isl_sample.c
--- isl-0.12.2/isl_sample.c-o 2014-07-08 08:13:51.558985729 -0700
+++ isl-0.12.2/isl_sample.c 2014-07-08 08:14:26.446984637 -0700
@@ -1443,7 +1443,7 @@
__isl_give isl_point *isl_set_sample_point(__isl_take isl_set *set)
{
int i;
- isl_point *pnt;
+ isl_point *pnt = NULL;
if (!set)
return NULL;
diff -u isl-0.12.2/isl_tab_pip.c-o isl-0.12.2/isl_tab_pip.c
--- isl-0.12.2/isl_tab_pip.c-o 2014-07-08 08:11:54.950989380 -0700
+++ isl-0.12.2/isl_tab_pip.c2014-07-08 08:12:55.794987475 -0700
@@ -2156,7 +2156,7 @@
int split;
int row;
int best = -1;
- int best_r;
+ int best_r = -1;
if (isl_tab_extend_cons(context_tab, 2) < 0)
return -1;
--
a...@linux.intel.com -- Speaking for myself only.
Re: Fix aliases on AIX
> The problem with devirt-10 and devirt-15 is the excellent kludge for > aliases on AIX can produce multiple symbols. > > ipa-prop: Discovered a virtual call to a known target (void > wxBufferedDC::InitCommon(wxDCBase*)/3 -> virtual void > wxDCBase::_ZN8wxDCBase18SetLayoutDirectionEi.localalias.6(int)/36), > for stmt OBJ_TYPE_REF(_6;_7->1) (_7, _11); > Speculative call turned into direct call. > ipa-prop: Discovered a virtual call to a known target (void > wxBufferedDC::InitCommon(wxDCBase*)/3 -> virtual int > wxDCBase::_ZNK8wxDCBase18GetLayoutDirectionEv.localalias.5() > const/35), for stmt _11 = OBJ_TYPE_REF(_9;dc_2(D)->0) (dc_2(D)); > > > The testcase expects exactly 1 occurrence, but the new code produces 2 for > AIX. > > What is the best way to adjust the testcases? I guess it actually difference in inlining - those aliases are not of same symbols so we devirtualize more than the testcase's template expect. It may just go away with enabling COMDAT but I need to look into making those two testcases more robust. Definitely not a wrong code issue though, just fragile testcase. Honza > > Thanks, David
Re: Fix aliases on AIX
> With the patch, GCC on AIX now responds that "ifunc" is supported.
> The C and C++ attr-ifunc testcases now run and fail.
This is unexpected. I am testing version of the patch with
if (lookup_attribute ("ifunc", DECL_ATTRIBUTES (n->decl)))
return false;
added to beggining of rs6000_declare_alias. The problem here is that ifunc is
dealt with as an alias and becuase we output aliases ourselves, we skip the
sanity checking done in do_assemble_alias. I think that checking is way too
late, will look into moving it earlier.
I also checked that we won't skip other useful sanity checking there. (other
one is
weakref that we already know to not output in the new way)
Honza
>
> g++.dg/ipa/devirt-10 and devirt-15 now fail.
>
> Otherwise, the results look very good.
>
> Thanks, David
FW: [PATCH, aarch64] Add prefetch support
PING! -Original Message- From: Gopalasubramanian, Ganesh Sent: Sunday, July 06, 2014 2:12 AM To: gcc-patches@gcc.gnu.org Cc: marcus.shawcr...@arm.com; richard.earns...@arm.com Subject: RE: [PATCH, aarch64] Add prefetch support PING! From: Gopalasubramanian, Ganesh Sent: Friday, July 04, 2014 5:57 AM To: gcc-patches@gcc.gnu.org Cc: marcus.shawcr...@arm.com; richard.earns...@arm.com Subject: [PATCH, aarch64] Add prefetch support Hi, Attached is a patch that implements * Prefetch with immediate offset in the range 0 to 32760 (multiple of 8). Added a predicate for this. * Prefetch with immediate offset - in the range -256 to 255 (Gets generated only when we have a negative offset. Generates prfum instruction). Added a predicate for this. * Prefetch with register offset. (modified for printing the locality) This patch has been already discussed on https://gcc.gnu.org/ml/gcc-patches/2014-02/msg01644.html "make -k check" passes. Ok for trunk? Changelog 2014-07-04 Ganesh Gopalasubramanian * config/aarch64/aarch64.md (define_insn "*prefetch") (define_insn "prefetch"): New * config/aarch64/predicates.md (aarch64_prefetch_pimm) (aarch64_prefetch_unscaled): New. * config/arm/types.md (define_attr "type"): Add prefetch. Regards Ganesh
