Re: symtab cleanups 3/17: fix alias visibility logic
Jan Hubicka writes: > * gcc.dg/tree-ssa/attr-alias.c: New testcase. I've removed the duplicated contents. Andreas. -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
[PATCH] Fix some LTO streaming issues, report the number of merged types
This prepares for the LTO type merging re-org by pushing bugfixes I
noticed when implementing the rewrite to trunk. It also adds counting
of the number of merged types so we can easily compare the results.
LTO bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-06-05 Richard Biener
* tree-streamer.c (streamer_tree_cache_insert_1): Update the
index associated with the tree we are supposed to replace.
* tree-streamer-out.c (pack_ts_base_value_fields): Output
TREE_ASM_WRITTEN as zero for everything but SSA names.
lto/
* lto.c (num_merged_types): New global variable.
(uniquify_nodes): Increase num_merged_types when merging a type.
(print_lto_report_1): Output the number of merged types.
Index: gcc/tree-streamer.c
===
*** gcc/tree-streamer.c (revision 199650)
--- gcc/tree-streamer.c (working copy)
*** streamer_tree_cache_insert_1 (struct str
*** 152,157
--- 152,158
the requested location slot. */
ix = *ix_p;
streamer_tree_cache_add_to_node_array (cache, ix, t);
+ *slot = (void *)(size_t) (ix + 1);
}
/* Indicate that T was already in the cache. */
Index: gcc/tree-streamer-out.c
===
*** gcc/tree-streamer-out.c (revision 199650)
--- gcc/tree-streamer-out.c (working copy)
*** pack_ts_base_value_fields (struct bitpac
*** 87,94
bp_pack_value (bp, TYPE_UNSIGNED (expr), 1);
else
bp_pack_value (bp, 0, 1);
! /* We write debug info two times, do not confuse the second one. */
! bp_pack_value (bp, ((TYPE_P (expr) || TREE_CODE (expr) == TYPE_DECL)
? 0 : TREE_ASM_WRITTEN (expr)), 1);
if (TYPE_P (expr))
bp_pack_value (bp, TYPE_ARTIFICIAL (expr), 1);
--- 87,95
bp_pack_value (bp, TYPE_UNSIGNED (expr), 1);
else
bp_pack_value (bp, 0, 1);
! /* We write debug info two times, do not confuse the second one.
! The only relevant TREE_ASM_WRITTEN use is on SSA names. */
! bp_pack_value (bp, (TREE_CODE (expr) != SSA_NAME
? 0 : TREE_ASM_WRITTEN (expr)), 1);
if (TYPE_P (expr))
bp_pack_value (bp, TYPE_ARTIFICIAL (expr), 1);
Index: gcc/lto/lto.c
===
*** gcc/lto/lto.c (revision 199650)
--- gcc/lto/lto.c (working copy)
*** lto_register_function_decl_in_symtab (st
*** 1788,1793
--- 1788,1794
}
}
+ static unsigned long num_merged_types = 0;
/* Given a streamer cache structure DATA_IN (holding a sequence of trees
for one compilation unit) go over all trees starting at index FROM until
the
*** uniquify_nodes (struct data_in *data_in,
*** 1817,1823
to reset that flag afterwards - nothing that refers
to those types is left and they are collected. */
if (newt != t)
! TREE_VISITED (t) = 1;
}
}
--- 1818,1827
to reset that flag afterwards - nothing that refers
to those types is left and they are collected. */
if (newt != t)
! {
! num_merged_types++;
! TREE_VISITED (t) = 1;
! }
}
}
*** print_lto_report_1 (void)
*** 3136,3141
--- 3140,3146
htab_collisions (type_hash_cache));
else
fprintf (stderr, "[%s] GIMPLE type hash cache table is empty\n", pfx);
+ fprintf (stderr, "[%s] Merged %lu types\n", pfx, num_merged_types);
print_gimple_types_stats (pfx);
print_lto_report (pfx);
Re: [GOOGLE] More strict checking for call args
On Wed, Jun 5, 2013 at 2:19 AM, Dehao Chen wrote:
> attached is a testcase that would cause problem when source has changed:
>
> $ g++ test.cc -O2 -fprofile-generate -DOLD
> $ ./a.out
> $ g++ test.cc -O2 -fprofile-use
> test.cc:34:1: internal compiler error: in operator[], at vec.h:815
> }
> ^
> 0x512740 vec::operator[](unsigned int)
> ../../gcc/vec.h:815
> 0x512740 vec::operator[](unsigned int)
> ../../gcc/vec.h:1244
> 0xf24464 vec::operator[](unsigned int)
> ../../gcc/vec.h:815
> 0xf24464 vec::operator[](unsigned int)
> ../../gcc/vec.h:1244
> 0xf24464 ipa_get_indirect_edge_target_1
> ../../gcc/ipa-cp.c:1535
This use needs to be properly guarded. We can perfectly well have
mismatching fndecl nodes in gimple calls. If we start with
void fn(int, int, int);
...
void (*x)(float, double, struct X, int) = fn;
(*x)(1., 2., {}, 1);
the GIMPLE_CALL receives the function type effective for the call
from the source (gimple_call_fntype). Then CCP happily propagates the
'fn' decl and we end up with
fn (1., 2., {}, 1);
that is, gimple_call_fndecl is 'fn' but gimple_call_fntype is still
void (*x)(float, double, struct X, int)!
So the solution is not to fix the argument verification predicate but to make
code aware of the fact that for the call statement gimple_call_fntype is
relevant for what is a valid call (that's also what is verified against in
verify_stmts) even though the ultimate called function-decl 'fn' has a
different prototype. Thus any code propagating from a call site to
the callee has to deal with mismatches.
Richard.
> 0x971b9a estimate_edge_devirt_benefit
> ../../gcc/ipa-inline-analysis.c:2757
> 0x973f59 estimate_edge_size_and_time
> ../../gcc/ipa-inline-analysis.c:2789
> 0x973f59 estimate_calls_size_and_time
> ../../gcc/ipa-inline-analysis.c:2842
> 0x97429f estimate_node_size_and_time
> ../../gcc/ipa-inline-analysis.c:2929
> 0x976077 do_estimate_edge_size(cgraph_edge*)
> ../../gcc/ipa-inline-analysis.c:3472
> 0x97614f estimate_edge_size
> ../../gcc/ipa-inline.h:274
> 0x97614f estimate_edge_growth
> ../../gcc/ipa-inline.h:286
> 0x97614f do_estimate_growth_1
> ../../gcc/ipa-inline-analysis.c:3582
> 0x7e41df cgraph_for_node_and_aliases
> ../../gcc/cgraph.c:1777
> 0x976675 do_estimate_growth(cgraph_node*)
> ../../gcc/ipa-inline-analysis.c:3596
> 0xf314ea estimate_growth
> ../../gcc/ipa-inline.h:261
> 0xf314ea inline_small_functions
> ../../gcc/ipa-inline.c:1432
> 0xf314ea ipa_inline
> ../../gcc/ipa-inline.c:1797
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See for instructions.
[Fortran, committed] Re: testsuite directive dg-run, again
Committed as Rev. 199684. Thanks for the patch!
Tobias
Manfred Schwarb wrote:
I reran my script made in January to detect strange
dg directives, and indeed, we grew a new one in
the mean time:
Index: string_length_2.f90
===
--- string_length_2.f90 (revision 199673)
+++ string_length_2.f90 (working copy)
@@ -1,4 +1,4 @@
-! { dg-run }
+! { dg-do run }
! { dg-options "-fdump-tree-original" }
! Test that all string length calculations are
! optimized away.
Re: [PATCH] Remove unused pass_update_address_taken
On Wed, Jun 5, 2013 at 4:48 AM, David Malcolm wrote: > If I'm reading things right, pass_update_address_taken is never actually > used. > > Deleting it, I was able to still successfully bootstrap on > x86_64-unknown-linux-gnu (using gcc-4.7.2-2.fc17.x86_64). > > The use of the pass appears to have been removed in: > http://gcc.gnu.org/r164525 > > Should I remove it from trunk? I haven't settled for whether the current scheme of using TODOs is really the best thing yet... (it probably is not). So I'd rather keep the pass around. Thanks, Richard. > 2013-06-05 David Malcolm > > * tree-pass.h (pass_update_address_taken): Remove. > * tree-ssa.c (pass_update_address_taken): Remove. >
Re: [PATCH] Improve folding of bitwise ops on booleans
On Tue, Jun 4, 2013 at 9:20 PM, Jeff Law wrote: > On 06/03/2013 08:23 AM, Kai Tietz wrote: >> >> >> Btw there is one optimization in this context which might be something >> worth here too. >> -X -> X for 1-bit typed X (signed doesn't matter here). > > I've had a hell of a time trying to trigger a case where this isn't already > handled. Samples welcome. Samples should pop up when including BOOLEAN_TYPEs in the handling of tree-ssa-forwprop.c:truth_valued_ssa_name (). It's probably Ada indeed (gfortran also has various BOOLEAN_TYPEs but they all have precision 1 but different sizes IIRC). Eventually we should force all BOOLEAN_TYPEs to have precision 1 but as Kai remembers Ada uses alternate values for verification (true, false, NaT or so). Eric may be able to explain. Thanks, Richard.
Re: [PATCH] tsan.c: mark tsan_atomic_table as constant
On Wed, Jun 5, 2013 at 6:40 AM, David Malcolm wrote: > The table of struct tsan_map_atomic within tsan.c is never modified, so > it can be marked as const. > > Successfully bootstrapped on x86_64-unknown-linux-gnu (using > gcc-4.7.2-2.fc17.x86_64). > > OK for trunk? Looks good, thanks. --kcc > > 2013-06-05 David Malcolm > > * tsan.c (tsan_atomic_table): Make const. >
Re: [PATCH] Remove unused pass_update_address_taken
On Wed, 2013-06-05 at 10:33 +0200, Richard Biener wrote: > On Wed, Jun 5, 2013 at 4:48 AM, David Malcolm wrote: > > If I'm reading things right, pass_update_address_taken is never actually > > used. > > > > Deleting it, I was able to still successfully bootstrap on > > x86_64-unknown-linux-gnu (using gcc-4.7.2-2.fc17.x86_64). > > > > The use of the pass appears to have been removed in: > > http://gcc.gnu.org/r164525 > > > > Should I remove it from trunk? > > I haven't settled for whether the current scheme of using TODOs is really > the best thing yet... (it probably is not). So I'd rather keep the pass > around. Fair enough - thanks.
Re: [PATCH] tsan.c: mark tsan_atomic_table as constant
On Wed, 2013-06-05 at 13:27 +0400, Konstantin Serebryany wrote: > On Wed, Jun 5, 2013 at 6:40 AM, David Malcolm wrote: > > The table of struct tsan_map_atomic within tsan.c is never modified, so > > it can be marked as const. > > > > Successfully bootstrapped on x86_64-unknown-linux-gnu (using > > gcc-4.7.2-2.fc17.x86_64). > > > > OK for trunk? > > Looks good, thanks. Thanks; committed to SVN trunk as r199690.
Re: [PATCH][ARM][1/n] Partial IT block deprecation in ARMv8 AArch32
On 04/06/13 16:53, Kyrylo Tkachov wrote: Hi Joseph, It creates a command line option, -mrestrict-it, that can be used to Command-line options need documenting in invoke.texi. I've added some documentation in invoke.texi Confirmed that documentation builds ok. Thanks, Kyrill 2013-06-04 Kyrylo Tkachov * config/arm/arm.c (MAX_INSN_PER_IT_BLOCK): New macro. (arm_option_override): Override arm_restrict_it where appropriate. (thumb2_final_prescan_insn): Use MAX_INSN_PER_IT_BLOCK. * config/arm/arm.opt (mrestrict-it): New command-line option. * doc/invoke.texi: Document -mrestrict-it. OK. R.
[Testsuite] Fix arm triplets in some testcases.
Hi,
Some ARM triplets are of the form armv7l-unknown-linux-gnueabihf.
For these arm-*-* will not match, so fix this with arm*-*-*.
Nor will arm*-*-*eabi, so fix this with arm*-*-*eabi*.
Tested with a run of the affected tests on an
armv7l-unknown-linux-gnueabihf target, showing FAIL->PASS.
OK?
Thanks,
James
---
gcc/testsuite
2013-06-05 James Greenhalgh
* gcc.dg/fshort-wchar.c: Add extra dg-options for
arm*-*-*eabi* targets.
* gcc.dg/tree-ssa/pr42585.c: Change dg-final to catch
arm*-*-* targets.
* gcc.dg/tree-ssa/pr43491.c: Likewise.
diff --git a/gcc/testsuite/gcc.dg/fshort-wchar.c b/gcc/testsuite/gcc.dg/fshort-wchar.c
index c9c7515..bb69881 100644
--- a/gcc/testsuite/gcc.dg/fshort-wchar.c
+++ b/gcc/testsuite/gcc.dg/fshort-wchar.c
@@ -2,7 +2,7 @@
/* { dg-do run } */
/* { dg-options "-fshort-wchar" } */
-/* { dg-options "-fshort-wchar -Wl,--no-wchar-size-warning" { target arm*-*-*eabi } } */
+/* { dg-options "-fshort-wchar -Wl,--no-wchar-size-warning" { target arm*-*-*eabi* } } */
/* Source: Neil Booth, 10 Dec 2002.
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c b/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c
index d01b8ab..520c357 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c
@@ -35,6 +35,6 @@ Cyc_string_ungetc (int ignore, struct _fat_ptr *sptr)
/* Whether the structs are totally scalarized or not depends on the
MOVE_RATIO macro defintion in the back end. The scalarization will
not take place when using small values for MOVE_RATIO. */
-/* { dg-final { scan-tree-dump-times "struct _fat_ptr _ans" 0 "optimized" { target { ! "arm-*-* powerpc*-*-* s390*-*-* sh*-*-*" } } } } */
-/* { dg-final { scan-tree-dump-times "struct _fat_ptr _T2" 0 "optimized" { target { ! "arm-*-* powerpc*-*-* s390*-*-* sh*-*-*" } } } } */
+/* { dg-final { scan-tree-dump-times "struct _fat_ptr _ans" 0 "optimized" { target { ! "arm*-*-* powerpc*-*-* s390*-*-* sh*-*-*" } } } } */
+/* { dg-final { scan-tree-dump-times "struct _fat_ptr _T2" 0 "optimized" { target { ! "arm*-*-* powerpc*-*-* s390*-*-* sh*-*-*" } } } } */
/* { dg-final { cleanup-tree-dump "optimized" } } */
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr43491.c b/gcc/testsuite/gcc.dg/tree-ssa/pr43491.c
index 2473400..44dc5f2 100644
--- a/gcc/testsuite/gcc.dg/tree-ssa/pr43491.c
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr43491.c
@@ -37,6 +37,6 @@ long foo(long data, long v)
}
/* We should not eliminate global register variable when it is the RHS of
a single assignment. */
-/* { dg-final { scan-tree-dump-times "Eliminated: 2" 1 "pre" { target { arm-*-* i?86-*-* mips*-*-* x86_64-*-* } } } } */
-/* { dg-final { scan-tree-dump-times "Eliminated: 3" 1 "pre" { target { ! { arm-*-* i?86-*-* mips*-*-* x86_64-*-* } } } } } */
+/* { dg-final { scan-tree-dump-times "Eliminated: 2" 1 "pre" { target { arm*-*-* i?86-*-* mips*-*-* x86_64-*-* } } } } */
+/* { dg-final { scan-tree-dump-times "Eliminated: 3" 1 "pre" { target { ! { arm*-*-* i?86-*-* mips*-*-* x86_64-*-* } } } } } */
/* { dg-final { cleanup-tree-dump "pre" } } */
Re: [Testsuite] Fix arm triplets in some testcases.
On 05/06/13 11:32, James Greenhalgh wrote: Hi, Some ARM triplets are of the form armv7l-unknown-linux-gnueabihf. For these arm-*-* will not match, so fix this with arm*-*-*. Nor will arm*-*-*eabi, so fix this with arm*-*-*eabi*. Tested with a run of the affected tests on an armv7l-unknown-linux-gnueabihf target, showing FAIL->PASS. OK? Thanks, James --- gcc/testsuite 2013-06-05 James Greenhalgh * gcc.dg/fshort-wchar.c: Add extra dg-options for arm*-*-*eabi* targets. * gcc.dg/tree-ssa/pr42585.c: Change dg-final to catch arm*-*-* targets. * gcc.dg/tree-ssa/pr43491.c: Likewise. OK. R.
[testsuite] Adding target nonpic to certain tests part. 2
Hi,
Another bunch of tests that fails with -fpic.
from here: http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00539.html
"Since -fpic option is turned on by default in Android we have certain test
fails. The reason for that is that those tests rely on the
availability of functions, defined in them
and with -fpic compiler conservatively assumes that they are
AVAIL_OVERWRITABLE."
I added {target nonpic} to them as before.
Is it ok for trunk?
thanks,
Alexander
add_target_nonpic.patch
Description: Binary data
Re: [testsuite] Adding target nonpic to certain tests part. 2
Hi Alexander,
At least for TM testcase, I would prefer to add 'transaction_safe'
attribute on foobar as in the attached patch.
Aldy and Richard H: What do you think?
Thanks,
--
Patrick
On Wed, Jun 5, 2013 at 1:13 PM, Alexander Ivchenko wrote:
> Hi,
>
> Another bunch of tests that fails with -fpic.
>
> from here: http://gcc.gnu.org/ml/gcc-patches/2013-01/msg00539.html
> "Since -fpic option is turned on by default in Android we have certain test
> fails. The reason for that is that those tests rely on the
> availability of functions, defined in them
> and with -fpic compiler conservatively assumes that they are
> AVAIL_OVERWRITABLE."
>
> I added {target nonpic} to them as before.
>
>
> Is it ok for trunk?
>
>
> thanks,
> Alexander
tm-nested-2.patch
Description: Binary data
Re: [PATCH] Improve folding of bitwise ops on booleans
> Eventually we should force all BOOLEAN_TYPEs to have precision 1 but > as Kai remembers Ada uses alternate values for verification (true, false, > NaT or so). Eric may be able to explain. Correct, see: http://gcc.gnu.org/ml/gcc-patches/2011-05/msg01214.html A boolean type isn't a modular type of precision 1 in Ada, it's an enumeration type with two values so a standard scalar type, i.e. precision == mode size. IIRC I already mentioned that if boolean_type_node was to be unified across languages, we'll very likely need to reimplement the boolean types in Ada and use boolean_type_node only for the result of comparisons. -- Eric Botcazou
[Patch, Fortran] PR57530 - fix rejects valid with gfc_type_compatible
A TYPE is type compatible with a CLASS if both have the same declared type.
Or in words of the standard (cf. PR):
"A nonpolymorphic entity is type compatible only with entities of the
same declared type. A polymorphic entity that is not an unlimited
polymorphic entity is type compatible with entities of the same declared
type or any of its extensions." (F2008, 4.3.1.3).
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-06-05 Tobias Burnus
PR fortran/57530
* symbol.c (gfc_type_compatible): A type is type compatible with
a class if both have the same declared type.
2013-06-05 Tobias Burnus
PR fortran/57530
* gfortran.dg/pointer_assign_8.f90: New.
diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index c72974d..9d23e8b 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -4489,6 +4489,9 @@ gfc_type_compatible (gfc_typespec *ts1, gfc_typespec *ts2)
if (is_derived1 && is_derived2)
return gfc_compare_derived_types (ts1->u.derived, ts2->u.derived);
+ if (is_derived1 && is_class2)
+return gfc_compare_derived_types (ts1->u.derived,
+ ts2->u.derived->components->ts.u.derived);
if (is_class1 && is_derived2)
return gfc_type_is_extension_of (ts1->u.derived->components->ts.u.derived,
ts2->u.derived);
--- /dev/null 2013-06-05 09:13:09.179105369 +0200
+++ gcc/gcc/testsuite/gfortran.dg/pointer_assign_8.f90 2013-06-05 13:55:12.580621132 +0200
@@ -0,0 +1,14 @@
+! { dg-do compile }
+!
+! PR fortran/57530
+!
+module m
+ type t
+ end type t
+contains
+ subroutine sub (tgt)
+class(t), target :: tgt
+type(t), pointer :: ptr
+ptr => tgt ! TYPE => CLASS of same declared type
+ end subroutine sub
+end module m
[PATCH] Change uint*_type_node definition to make_or_reuse_type
Hi, I'm trying to implement a builtin with a uint64_t* argument type as build_pointer_type (uint64_type_node). Unfortunately this fails for a simple case like: uint64_t a; __builtin_test (&a); t.c:7:3: warning: passing argument 1 of ‘__builtin_test’ from incompatible pointer type [enabled by default] __builtin_test(&a); ^ t.c:7:3: note: expected ‘long unsigned int *’ but argument is of type ‘uint64_t *’ The problem is how the uint64_type_node is generated. We just create a new "unsigned long" data type which cannot be unified with the existing in convert_for_assignment because its main_variant type just points to itself. Reusing the existing integer data types as a base this matches the implementation in stdint.h and works fine for me. The only other user appears to be the bswap64 builtin. This keeps working as before with that change. Ok for mainline? Bye, -Andreas- 2013-06-05 Andreas Krebbel * tree.c (build_common_tree_nodes): Create uint*_t type nodes with make_or_reuse_type. --- gcc/tree.c |6 !! 1 file changed, 6 modifications(!) Index: gcc/tree.c === *** gcc/tree.c.orig --- gcc/tree.c *** build_common_tree_nodes (bool signed_cha *** 9550,9558 integer_ptr_type_node = build_pointer_type (integer_type_node); /* Fixed size integer types. */ ! uint16_type_node = build_nonstandard_integer_type (16, true); ! uint32_type_node = build_nonstandard_integer_type (32, true); ! uint64_type_node = build_nonstandard_integer_type (64, true); /* Decimal float types. */ dfloat32_type_node = make_node (REAL_TYPE); --- 9550,9558 integer_ptr_type_node = build_pointer_type (integer_type_node); /* Fixed size integer types. */ ! uint16_type_node = make_or_reuse_type (16, true); ! uint32_type_node = make_or_reuse_type (32, true); ! uint64_type_node = make_or_reuse_type (64, true); /* Decimal float types. */ dfloat32_type_node = make_node (REAL_TYPE);
Re: [Patch, Fortran] PR57530 - fix rejects valid with gfc_type_compatible
I accidentally attached a slightly out-dated patch. The old patch permitted CLASS<->TYPE differences in cases where the characteristic had to match (e.g. dummy arguments in a proc-pointer assignment). - Sorry for the confusion. Build and regtested on x86-64-gnu-linux. OK for the trunk? Tobias Tobias Burnus wrote: A TYPE is type compatible with a CLASS if both have the same declared type. Or in words of the standard (cf. PR): "A nonpolymorphic entity is type compatible only with entities of the same declared type. A polymorphic entity that is not an unlimited polymorphic entity is type compatible with entities of the same declared type or any of its extensions." (F2008, 4.3.1.3). Build and regtested on x86-64-gnu-linux. OK for the trunk?
Re: [Patch, Fortran] PR57530 - fix rejects valid with gfc_type_compatible
Now with attached patch.
Tobias Burnus wrote:
I accidentally attached a slightly out-dated patch. The old patch
permitted CLASS<->TYPE differences in cases where the characteristic
had to match (e.g. dummy arguments in a proc-pointer assignment). -
Sorry for the confusion.
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
Tobias Burnus wrote:
A TYPE is type compatible with a CLASS if both have the same declared
type.
Or in words of the standard (cf. PR):
"A nonpolymorphic entity is type compatible only with entities of the
same declared type. A polymorphic entity that is not an unlimited
polymorphic entity is type compatible with entities of the same
declared type or any of its extensions." (F2008, 4.3.1.3).
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
2013-06-05 Tobias Burnus
PR fortran/57530
* symbol.c (gfc_type_compatible): A type is type compatible with
a class if both have the same declared type.
* interface.c (compare_type): Reject CLASS/TYPE even if they
are type compatible.
2013-06-05 Tobias Burnus
PR fortran/57530
* gfortran.dg/pointer_assign_8.f90: New.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index f06ecfe..17a47a2 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -514,6 +514,12 @@ compare_type (gfc_symbol *s1, gfc_symbol *s2)
if (s2->attr.ext_attr & (1 << EXT_ATTR_NO_ARG_CHECK))
return 1;
+ /* TYPE and CLASS of the same declared type are type compatible,
+ but have different characteristics. */
+ if ((s1->ts.type == BT_CLASS && s2->ts.type == BT_DERIVED)
+ || (s1->ts.type == BT_DERIVED && s2->ts.type == BT_CLASS))
+return 0;
+
return gfc_compare_types (&s1->ts, &s2->ts) || s2->ts.type == BT_ASSUMED;
}
diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c
index c72974d..9d23e8b 100644
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -4489,6 +4489,9 @@ gfc_type_compatible (gfc_typespec *ts1, gfc_typespec *ts2)
if (is_derived1 && is_derived2)
return gfc_compare_derived_types (ts1->u.derived, ts2->u.derived);
+ if (is_derived1 && is_class2)
+return gfc_compare_derived_types (ts1->u.derived,
+ ts2->u.derived->components->ts.u.derived);
if (is_class1 && is_derived2)
return gfc_type_is_extension_of (ts1->u.derived->components->ts.u.derived,
ts2->u.derived);
--- /dev/null 2013-06-05 09:13:09.179105369 +0200
+++ gcc/gcc/testsuite/gfortran.dg/pointer_assign_8.f90 2013-06-05 13:55:12.580621132 +0200
@@ -0,0 +1,14 @@
+! { dg-do compile }
+!
+! PR fortran/57530
+!
+module m
+ type t
+ end type t
+contains
+ subroutine sub (tgt)
+class(t), target :: tgt
+type(t), pointer :: ptr
+ptr => tgt ! TYPE => CLASS of same declared type
+ end subroutine sub
+end module m
RE: [PATCH RX] Added target specific macros for macros for RX100, RX200, and RX600
Hi Chung-Ju Wu, Thanks for your help. Suggested changes has been committed. Regards, Sandeep Kumar Singh, KPIT Cummins InfoSystems Ltd. Pune, India > -Original Message- > From: Chung-Ju Wu [mailto:jasonw...@gmail.com] > Sent: Monday, June 03, 2013 8:02 PM > To: Sandeep Kumar Singh > Cc: Gerald Pfeifer; gcc-patches@gcc.gnu.org; Kaushik Phatak > Subject: Re: [PATCH RX] Added target specific macros for macros for RX100, > RX200, and RX600 > > 2013/6/3 Sandeep Kumar Singh : > > Hi Gerald, > > > > Below is the update to mention under changes link on GCC website. > > > > RX > > The port now allows to specify the RX100, RX200, and RX600 > > processors > with the command > > line options -mcpu=rx100, -mcpu=rx200 and -mcpu=rx600 > > > > This update will go into: > > "New Targets and Target Specific Improvements" heading > > > > Help to guide me for updating this on GCC website would be highly > appreciated. > > > > > > Regards, > > Sandeep Kumar Singh, > > KPIT Cummins InfoSystems Ltd. > > Pune, India > > > > > > Hi, Sandeep, > > GCC website is available via CVS access: > http://gcc.gnu.org/cvs.html > > I think your patch for wwwdoc can be presented as follows: > > Index: htdocs/gcc-4.9/changes.html > = > == > RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v > retrieving revision 1.15 > diff -r1.15 changes.html > 176d175 > < > --- > > RX > > > > The port now allows to specify the RX100, RX200, and RX600 > > processors > > with the command line options -mcpu=rx100, -mcpu=rx200 and - > mcpu=rx600. > > > > > > > Best regards, > jasonwucj
Re: [C++ Patch] PR 51908
On 06/04/2013 08:34 PM, Paolo Carlini wrote:
/* After seeing a decl-specifier-seq, if the next token is not a
- "(", there is no possibility that the code is a valid
+ "(" nor '...', there is no possibility that the code is a valid
expression. Therefore, if parsing tentatively, we commit at
this point. */
clearly in the case at issue of decl-specifier-seq followed by ellipsis
we may be parsing a perfectly valid declaration.
Yes, but not an expression, which is why we are committing there: we
know it *has* to be a declaration. The non-variadic case should hit
that commit, so your change doesn't seem to make the variadic case more
consistent.
Jason
Re: [C++ Patch] PR 51908
Hi,
On 06/05/2013 02:53 PM, Jason Merrill wrote:
On 06/04/2013 08:34 PM, Paolo Carlini wrote:
/* After seeing a decl-specifier-seq, if the next token is not a
- "(", there is no possibility that the code is a valid
+ "(" nor '...', there is no possibility that the code is a valid
expression. Therefore, if parsing tentatively, we commit at
this point. */
clearly in the case at issue of decl-specifier-seq followed by ellipsis
we may be parsing a perfectly valid declaration.
Yes, but not an expression, which is why we are committing there: we
know it *has* to be a declaration.
I see, I didn't notice the reference to *expressions* in the comment.
The non-variadic case should hit that commit, so your change doesn't
seem to make the variadic case more consistent.
But the non-variadic case does *not* hit the commit, because is handled
above:
/* If the next token is a `)', `,', `=', `>', or `...', then there
is no declarator. However, when variadic templates are enabled,
there may be a declarator following `...'. */
if (token->type == CPP_CLOSE_PAREN
|| token->type == CPP_COMMA
|| token->type == CPP_EQ
|| token->type == CPP_GREATER)
{
declarator = NULL;
if (parenthesized_p)
*parenthesized_p = false;
}
Thus it seems to me that the variadic case should also somehow not-hit
the commit, do you agree?
Paolo.
Re: [C++ Patch] PR 51908
On 06/05/2013 09:07 AM, Paolo Carlini wrote:
Hi,
On 06/05/2013 02:53 PM, Jason Merrill wrote:
On 06/04/2013 08:34 PM, Paolo Carlini wrote:
/* After seeing a decl-specifier-seq, if the next token is not a
- "(", there is no possibility that the code is a valid
+ "(" nor '...', there is no possibility that the code is a valid
expression. Therefore, if parsing tentatively, we commit at
this point. */
clearly in the case at issue of decl-specifier-seq followed by ellipsis
we may be parsing a perfectly valid declaration.
Yes, but not an expression, which is why we are committing there: we
know it *has* to be a declaration.
I see, I didn't notice the reference to *expressions* in the comment.
The non-variadic case should hit that commit, so your change doesn't
seem to make the variadic case more consistent.
But the non-variadic case does *not* hit the commit, because is handled
above:
/* If the next token is a `)', `,', `=', `>', or `...', then there
is no declarator. However, when variadic templates are enabled,
there may be a declarator following `...'. */
if (token->type == CPP_CLOSE_PAREN
|| token->type == CPP_COMMA
|| token->type == CPP_EQ
|| token->type == CPP_GREATER)
{
declarator = NULL;
if (parenthesized_p)
*parenthesized_p = false;
}
Thus it seems to me that the variadic case should also somehow not-hit
the commit, do you agree?
Well, the comment here is correct: (Args... args) would also be
well-formed. But in the testcase there isn't a declarator, so the
comment following the above, "Otherwise, there should be a declarator",
is wrong. I guess the above should also check for ... followed by one
of those tokens.
In any case, the commit doesn't seem like the problem. I'm not sure why
it's in the else block rather than before the if.
Jason
Re: [PATCH RX] Added target specific macros for macros for RX100, RX200, and RX600
2013/6/5 Sandeep Kumar Singh : > Hi Chung-Ju Wu, > > Thanks for your help. Suggested changes has been committed. > > Regards, > Sandeep Kumar Singh, > KPIT Cummins InfoSystems Ltd. > Pune, India > > Oops~ I should have said that my suggested changes still require Gerald's approval. Gerald is web page maintainer and he is the one who has right to approve the web page patches. By the way, the changes that Kaushik committed didn't remove html comment mark surrounding "New Targets and Target Specific Improvements", causing the description of RX target went into "New Languages and Language specific improvements" section. I think you (or Kaushik) need to make such change: --- changes.html.kaushik2013-06-05 21:32:39.542693802 +0800 +++ changes.html.new2013-06-05 21:32:56.099351574 +0800 @@ -173,10 +173,8 @@ Java (GCJ) --> - RX The port now allows to specify the RX100, RX200, and RX600 processors Let's see if Gerald has any other comments or suggestions to the patch. :) Best regards, jasonwucj
Re: [C++ Patch] PR 51908
.. true that my first try didn't fix this non-variadic variant, because
we have a declarator and again we hit the commit:
struct foo
{
template
operator decltype(static_cast(0)) () const;
};
Paolo.
Re: RFA: Switching LRA on for s390
On Fri, May 31, 2013 at 02:11:38PM -0400, Vladimir Makarov wrote: > The patch was successfully bootstrapped and tested on s390x. > > Any comments? > Is it ok to commit the patch into trunk? > > Thanks. > > > 2013-05-31 Vladimir Makarov > > * config/s390/s390.opt (mlra): New option. > * config/s390/s390.c (s390_decompose_address): Check displacement > for all registers for LRA. > (s390_secondary_reload): Don't used secondary reloads for LRA. > (s390_lra_p): New function. > (TARGET_LRA_P): Define. > * config/s390/s390.md (*movmem_short, *clrmem_short): Change value > of attribute cpu_facility to zarch for the last alternative. > (*cmpmem_short): Ditto. In the last chunk z900 can be used instead of zarch. The splitters are guarded with TARGET_CPU_ZARCH. This requires a zarch cpu but it does not need to run in zarch mode. z900 is the first zarch cpu. Ok with that change. Many thanks for doing the migration. We'll try to do a performance regression run soon. Bye, -Andreas-
Re: Fix PR 53743 and other -freorder-blocks-and-partition failures
On Wed, May 29, 2013 at 7:57 AM, Teresa Johnson wrote: > On Thu, May 23, 2013 at 6:18 AM, Teresa Johnson wrote: >> On Wed, May 22, 2013 at 2:05 PM, Teresa Johnson wrote: >>> Revised patch included below. The spacing of my pasted in patch text >>> looks funky again, let me know if you want the patch as an attachment >>> instead. >>> >>> I addressed all of Steven's comments, except for the suggestion to use >>> gcc_assert >>> instead of error() in verify_hot_cold_block_grouping() to keep this >>> consistent >>> with the rest of the verify_flow_info subroutines (let me know if this is >>> ok). >> >> I fixed this issue too, which was actually in >> insert_section_boundary_note(), so that it gcc_asserts more >> efficiently as suggested. Retested, latest patch below. >> >> Honza, would you be able to review the patch? > > Ping. Still needs a global maintainer to review and approve. Ping. Thanks! Teresa > > Also, I submitted a PR for the debug range issue: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57451 > > Thanks! > Teresa > >> >> Thanks! >> Teresa >> >>> >>> The other main changes: >>> (1) Added several test cases (cloned from the torture subdirectories, >>> where I manually >>> built/ran with FDO and -freorder-blocks-and-partition with both the >>> current trunk and >>> my fixed trunk compiler, and was able to expose some failures I fixed. >>> (2) Changed existing tree-prof tests that used >>> -freorder-blocks-and-partition to be >>> built with -O2 instead of -O, so that partitioning actually kicks in. >>> (3) Fixed a couple of failures in the new >>> verify_hot_cold_block_grouping() checks >>> exposed by the torture tests I ran manually with splitting (2 of the >>> tests cloned >>> to tree-prof in this patch). One was in computed goto where we were >>> too aggressive >>> about cloning crossing edges, and the other was in rtl_split_edge >>> called from the "stack" >>> pass which was not correctly inserting the new bb in the correct partition >>> since >>> bb layout is complete at that point. >>> >>> Re-tested on x86_64-unknown-linux-gnu with bootstrap and profiledbootstrap >>> builds and regression testing. Re-built/ran cpu2006int with profile >>> feedback and -freorder-blocks-and-partition enabled. >>> >>> Ok for trunk? >>> >>> Thanks! >>> Teresa >> >> 2013-05-23 Teresa Johnson >> >> * ifcvt.c (find_if_case_1): Replace BB_COPY_PARTITION with assert >> as this is now done by redirect_edge_and_branch_force. >> * function.c (thread_prologue_and_epilogue_insns): Insert new bb after >> barriers, and fix interaction with splitting. >> * emit-rtl.c (try_split): Copy REG_CROSSING_JUMP notes. >> * cfgcleanup.c (try_forward_edges): Fix early return value to properly >> reflect changes made in the routine. >> * bb-reorder.c (emit_barrier_after_bb): Move to cfgrtl.c. >> (fix_up_fall_thru_edges): Remove incorrect check for bb layout order >> since this is called in cfglayout mode, and replace partition fixup >> with assert as that is now done by force_nonfallthru_and_redirect. >> (add_reg_crossing_jump_notes): Handle the fact that some jumps may >> already be marked with region crossing note. >> (insert_section_boundary_note): Make non-static, gate on flag >> has_bb_partition, rewrite to also check for multiple partitions. >> (rest_of_handle_reorder_blocks): Remove call to >> insert_section_boundary_note, now done later during free_cfg. >> (duplicate_computed_gotos): Don't duplicate partition crossing edge. >> * bb-reorder.h (insert_section_boundary_note): Declare. >> * Makefile.in (cfgrtl.o): Depend on bb-reorder.h >> * cfgrtl.c (rest_of_pass_free_cfg): If partitions exist >> invoke insert_section_boundary_note. >> (try_redirect_by_replacing_jump): Remove unnecessary >> check for region crossing note. >> (fixup_partition_crossing): New function. >> (rtl_redirect_edge_and_branch): Fixup partition boundaries. >> (emit_barrier_after_bb): Move here from bb-reorder.c, handle insertion >> in non-cfglayout mode. >> (force_nonfallthru_and_redirect): Fixup partition boundaries, >> remove old code that tried to do this. Emit barrier correctly >> when we are in cfglayout mode. >> (last_bb_in_partition): New function. >> (rtl_split_edge): Correctly fixup partition boundaries. >> (commit_one_edge_insertion): Remove old code that tried to >> fixup region crossing edge since this is now handled in >> split_block, and set up insertion point correctly since >> block may now end in a jump. >> (verify_hot_cold_block_grouping): Guard against checking when not in >> linearized RTL mode. >> (rtl_verify_edges): Add checks for incorrect/missing REG_CROSSING_JUMP >> notes. >> (rtl_verify_flow_info_1): Move verify_hot_cold_block_grouping to >> rtl_verify_flow_info, so not called in cfglayout mode. >> (rtl_verify_flow_info): Move verify_hot_co
Re: [PATCH, x86] Use vector moves in memmove expanding
I'll prepare some tests shortly, What about the rest questions? Thanks, Michael On 15 May 2013 19:45, H.J. Lu wrote: > On Wed, May 15, 2013 at 5:47 AM, Michael Zolotukhin > wrote: >> Hi HJ, >>> You use Pmode as the largest integer mode. Is word_mode better >>> than Pmode since word_mode is DI and Pmode may be SI for x32. >> I updated the patch to use word_mode instead of Pmode. Bootstrap, >> make check and Specs2000 are ok. >> >> Thanks, Michael >> >> On 14 May 2013 19:55, H.J. Lu wrote: >>> On Tue, May 14, 2013 at 7:34 AM, Michael Zolotukhin >>> wrote: Hi, I attached an updated version of the patch. Looks like the 64-bit issue is resolved in it (now a vector mode is explicitly chosen instead of TI- or another integer mode). Also, some of remarks are fixed in it - some others are still not changed, because I don't know what to do with them right now (see my questions in the previous letter). Could you take a look at the patch? I checked it on i386/x86_64 bootstrap and make check, and on Specs2000/2006 (I checked only stability). >>> >>> You use Pmode as the largest integer mode. Is word_mode better >>> than Pmode since word_mode is DI and Pmode may be SI for x32. >>> >>> > > You should include tests to verify that it works as > expected. > > > -- > H.J. -- --- Best regards, Michael V. Zolotukhin, Software Engineer Intel Corporation.
Symtab cleanups 4/17
Hi,
this patch deals with C++ keyed methods and explicit instantiations. Currently
C++ calls mark_used that ultimately sets force_output on the functions. This
is equivalent to attribute ((used)) on the function/variable and it is bit too
strong.
For example at LTO time we can ignore the C++ ABI as long as we see all uses of
the symbols (i.e. we have resolution info and the symbol is hidden).
This patch thus implements specific flag forced_by_abi. used for this purpose
and cleanups the code dealing with it. This affects abour 3800 symbols on
Firefox
turning them to regular non-forced symbols. This allows bit more unreachable
code
removal and optimization across these.
Bootstrapped/regtested x86_64-linux on ppc64-linux (in bit earlier version) as
well
as tested on LTO Firefox, comitted.
Honza
* class.c (emit_register_classes_in_jcr_section): Use DECL_PRESERVE_P
instead of mark_decl_referenced.
* decl2.c (maybe_make_one_only): Use forced_by_abi instad of
mark_decl_referenced.
(mark_needed): Likewise.
* cgraph.c (cgraph_remove_node): Clear forced_by_abi.
(cgraph_node_cannot_be_local_p_1): Honnor symbol.forced_by_abi
and symtab_used_from_object_file_p.
(cgraph_make_node_local_1): Clear forced_by_abi.
(cgraph_can_remove_if_no_direct_calls_and): Use forced_by_abi
* cgraph.h (symtab_node_base): Add forced_by_abi.
(decide_is_variable_needed): Remove.
(varpool_can_remove_if_no_refs): Honnor symbol.forced_by_abi.
* cgraphunit.c (cgraph_decide_is_function_needed): Rename to ..
(decide_is_symbol_needed): ... this one; handle symbols in general;
always analyze virtuals; honnor forced_by_abi.
(cgraph_finalize_function): Update.
(varpool_finalize_decl): Update.
(symbol_defined_and_needed): Remove.
(analyze_functions): Update.
* lto-cgraph.c (lto_output_node, lto_output_varpool_node,
output_refs, input_overwrite_node): Handle forced_by_abi.
* ipa.c (cgraph_address_taken_from_non_vtable_p): Rename to ...
(address_taken_from_non_vtable_p): ... this one.
(comdat_can_be_unshared_p_1): New function.
(cgraph_comdat_can_be_unshared_p): Rename to ...
(comdat_can_be_unshared_p): ... this one; handle symbols in general.
(varpool_externally_visible_p): Use comdat_can_be_unshared_p.
(function_and_variable_visibility): Clear forced_by_abi as needed.
* trans-mem.c (ipa_tm_mark_forced_by_abi_node): New functoin.
(ipa_tm_create_version_alias, ipa_tm_create_version): Update.
* varasm.c (mark_decl_referenced): Remove.
* symtab.c (dump_symtab_base): Dump forced_by_abi.
* varpool.c (decide_is_variable_needed): Remove.
Index: java/class.c
===
*** java/class.c(revision 199608)
--- java/class.c(working copy)
*** emit_register_classes_in_jcr_section (vo
*** 2814,2823
TREE_CONSTANT (cdecl) = 1;
DECL_ARTIFICIAL (cdecl) = 1;
DECL_IGNORED_P (cdecl) = 1;
pushdecl_top_level (cdecl);
relayout_decl (cdecl);
rest_of_decl_compilation (cdecl, 1, 0);
- mark_decl_referenced (cdecl);
#else
/* A target has defined TARGET_USE_JCR_SECTION,
but doesn't have a JCR_SECTION_NAME. */
--- 2814,2823
TREE_CONSTANT (cdecl) = 1;
DECL_ARTIFICIAL (cdecl) = 1;
DECL_IGNORED_P (cdecl) = 1;
+ DECL_PRESERVE_P (cdecl) = 1;
pushdecl_top_level (cdecl);
relayout_decl (cdecl);
rest_of_decl_compilation (cdecl, 1, 0);
#else
/* A target has defined TARGET_USE_JCR_SECTION,
but doesn't have a JCR_SECTION_NAME. */
Index: cgraph.c
===
*** cgraph.c(revision 199608)
--- cgraph.c(working copy)
*** cgraph_remove_node (struct cgraph_node *
*** 1326,1331
--- 1326,1332
/* Incremental inlining access removed nodes stored in the postorder list.
*/
node->symbol.force_output = false;
+ node->symbol.forced_by_abi = false;
for (n = node->nested; n; n = n->next_nested)
n->origin = NULL;
node->nested = NULL;
*** cgraph_node_cannot_be_local_p_1 (struct
*** 1712,1717
--- 1713,1720
{
return !(!node->symbol.force_output
&& ((DECL_COMDAT (node->symbol.decl)
+ && !node->symbol.forced_by_abi
+ && !symtab_used_from_object_file_p ((symtab_node) node)
&& !node->symbol.same_comdat_group)
|| !node->symbol.externally_visible));
}
*** cgraph_make_node_local_1 (struct cgraph_
*** 1804,1809
--- 1807,1813
symtab_make_decl_local (node->symbol.decl);
node->symbol.externally_visible = false;
+ node->symbol.forced_by_abi = false;
node->local.local = true;
node->symbol.unique_name = (nod
Re: [C++ Patch] PR 51908
On 06/05/2013 09:19 AM, Jason Merrill wrote: In any case, the commit doesn't seem like the problem. Oh, I see, of course it is. The problem is that it commits to all levels, so that if we happen to be in a nested tentative parse we can't commit to the inner one without committing to the outer one, which might not be appropriate. This seems like a basic flaw in our tentative parsing mechanism. What happens if we disable that commit entirely? Jason
Re: [PATCH, rs6000] power8 patches, patch #4 (revised), new power8 builtins
On Tue, Jun 4, 2013 at 2:48 PM, Michael Meissner wrote: > I revised this patch for power8 to add new miscellaneous vector instructions > to > not turn off splitting wide moves. In doing the patch, I discovered that we > never supported the 'eqv' instruction, and I have added support for eqv in the > GPR registers. > > I also fixed the issue David raised in patch #2, that I did not protect the > crypt tests in case an assembler that does not understand ISA 2.07 > instructions > was used to build the compiler. I brought in the changes to > target-supports.exp from patch #5 to fix this. > > This patch bootstraps and causes no regressions, is it ok to check in? > > [gcc] > 2013-06-04 Michael Meissner > Pat Haugen > Peter Bergner > > * doc/extend.texi (PowerPC AltiVec/VSX Built-in Functions): > Document new power8 builtins. > > * config/rs6000/vector.md (and3): Add a clobber/scratch of a > condition code register, so TImode logical operations can be done > either in VSX registers or GPRs. > (nor3): Use the canonical form for nor. > (eqv3): Add expanders for power8 xxleqv, xxlnand, xxlorc, > vclz*, and vpopcnt* vector instructions. > (nand3): Likewise. > (orc3): Likewise. > (clz2): LIkewise. > (popcount2): Likewise. > > * config/rs6000/predicates.md (int_reg_operand): Rework tests so > that only the GPRs are recognized. > > * config/rs6000/rs6000-builtin.def (xscvspdpn): Add new power8 > builtin functions. > (xscvdpspn): Likewise. > (vclzb): Likewise. > (vclzh): Likewise. > (vclzw): Likewise. > (vclzd): Likewise. > (vpopcntb): Likewise. > (vpopcnth): Likewise. > (vpopcntw): Likewise. > (vpopcntd): Likewise. > (vgbbd): Likewise. > (vmrgew): Likewise. > (vmrgow): Likewise. > (eqv_v16qi3): Likewise. > (eqv_v8hi3): Likewise. > (eqv_v4si3): Likewise. > (eqv_v2di3): Likewise. > (eqv_v4sf3): Likewise. > (eqv_v2df3): Likewise. > (nand_v16qi3): Likewise. > (nand_v8hi3): Likewise. > (nand_v4si3): Likewise. > (nand_v2di3): Likewise. > (nand_v4sf3): Likewise. > (nand_v2df3): Likewise. > (orc_v16qi3): Likewise. > (orc_v8hi3): Likewise. > (orc_v4si3): Likewise. > (orc_v2di3): Likewise. > (orc_v4sf3): Likewise. > (orc_v2df3): Likewise. > (vclz): Likewise. > (vclzb): Likewise. > (vclzh): Likewise. > (vclzw): Likewise. > (vclzd): Likewise. > (vpopcnt): Likewise. > (vpopcntb): Likewise. > (vpopcnth): Likewise. > (vpopcntw): Likewise. > (vpopcntd): Likewise. > (vgbbd): Likewise. > (eqv): Likewise. > (nand): Likewise. > (orc): Likewise. > (vmrgew): Likewise. > (vmrgow): Likewise. > > * config/rs6000/rs6000-c.c (altivec_overloaded_builtins): Add > support for new power8 builtins. > > * config/rs6000/rs6000.c (rs6000_option_override_internal): Only > allow power8 quad mode in 64-bit. > (rs6000_builtin_vectorized_function): Vectorize count leading > zeros, population count builtins. > (rs6000_expand_vector_init): On power8 use xscvdpspn to form V4SF > vectors instead of xscvdpsp to avoid IEEE related traps. > (builtin_function_type): Add vgbbd builtin function which takes an > unsigned argument. > (altivec_expand_vec_perm_const): Add support for new power8 merge > instructions. > > * config/rs6000/vsx.md (VSX_L2): New iterator for 128-bit types, > that does not include TImdoe for use with 32-bit. > (UNSPEC_VSX_CVSPDPN): Support for power8 xscvdpspn and xscvspdpn > instructions. > (UNSPEC_VSX_CVDPSPN): Likewise. > (vsx_xscvdpspn): Likewise. > (vsx_xscvspdpn): Likewise. > (vsx_xscvdpspn_scalar): Likewise. > (vsx_xscvspdpn_directmove): Likewise. > (vsx_and3): Split logical operations into 32-bit and > 64-bit. Add support to do logical operations on TImode as well as > VSX vector types. Allow logical operations to be done in either > VSX registers or in general purpose registers in 64-bit mode. Add > splitters if GPRs were used. For and, add clobber of CCmode to > allow use of ANDI on GPRs. > (vsx_and3_32bit): Likewise. > (vsx_and3_64bit): Likewise. > (vsx_ior3): Likewise. > (vsx_ior3_32bit): Likewise. > (vsx_ior3_64bit): Likewise. > (vsx_xor3): Likewise. > (vsx_xor3_32bit): Likewise. > (vsx_xor3_64bit): Likewise. > (vsx_one_cmpl2): Likewise. > (vsx_one_cmpl2_32bit): Likewise. > (vsx_one_cmpl2_64bit): Likewise. >
[2/n] Partial IT block deprecation in ARMv8 AArch32 - define_cond_exec machinery
Hi all, This patch adds the attributes to arm.md that are used to control the conditions under which we can predicate an insn. We use the new attributes field for define_cond_exec that was defined in a recent patch. Whenever an insn is predicated through define_cond_exec, it has the attribute "predicated" set to "yes". The "enabled" definition is updated to take "predicated" and arm_restric_it into account to disable the predicated version when appropriate. Now, if we want to disable the predicated version of an alternative for arm_restrict_it we leave the "predicable" attribute as "yes" and set the "predicable_short_it" attribute to "no". The enabled_for_depr_it attribute is used to disable alternatives in some cases where explicit IT blocks are used in the output template. Ok for trunk? 2013-06-05 Kyrylo Tkachov * config/arm/arm.md (enabled_for_depr_it): New attribute. (predicable_short_it): Likewise. (predicated): Likewise. (enabled): Handle above. (define_cond_exec): Set predicated attribute to yes. 03-enablers.patch Description: Binary data
Re: Symtab cleanups 4/17
The removal of mark_decl_referenced() breaks bootstrap because some target-specific code uses that function. I am trying with a change to DECL_PRESERVE_P to see if that will fix the problem in rs6000.c - David
RE: [PATCH] pr57457
> -Original Message-
> From: Jeff Law [mailto:l...@redhat.com]
> Sent: Tuesday, June 04, 2013 11:49 PM
> To: Iyer, Balaji V
> Cc: gcc-patches@gcc.gnu.org; Steve Ellcey
> Subject: Re: [PATCH] pr57457
>
> On 06/04/13 12:58, Iyer, Balaji V wrote:
> >
> >
> > Actually, you can eliminate the entire if-statement (i.e. remove
> > if-statement and make the body unconditional). This is because, if
> > flag_enable_cilkplus is true and is_cilkplus_reduce_builtin (fundecl)
> > is true, then it would have returned vec_safe_length(values) and will
> > not even get to this point in the first place. So, this is technically
> > equivalent to if (1). So, can I remove that and check it in also? It
> > passes all my regression tests.
> I originally thought it could be eliminated as well, but after further
> reflection I
> couldn't convince myself it'd do the right thing for the case when
> flag_enable_cilkplus is true but is_cilkplus_reduce_builtin was false.
>
> Note that triggering that code my be nontrivial, AFAICT we're suppressing a
> diagnostic. So you're going to need to write invalid code to get into that
> condition at the bottom of the loop at all.
Hi Jeff,
This email is going to be a bit long, so I apologize for it ahead of
time.
Here is the diff of c-typeck.c (to show that I have removed the
unwanted if statement)
Index: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c(revision 199672)
+++ gcc/c/c-typeck.c(working copy)
@@ -2942,6 +2942,8 @@
break;
}
}
+ if (flag_enable_cilkplus && fundecl && is_cilkplus_reduce_builtin (fundecl))
+return vec_safe_length (values);
/* Scan the given expressions and types, producing individual
converted arguments. */
@@ -2959,17 +2961,6 @@
bool npc;
tree parmval;
- // FIXME: I assume this code is here to handle the overloaded
- // behavior of the __sec_reduce* builtins, and avoid giving
- // argument mismatch warnings/errors. We should probably handle
- // this with the resolve_overloaded_builtin infrastructure.
- /* If the function call is a builtin function call, then we do not
-worry about it since we break them up into its equivalent later and
-we do the appropriate checks there. */
- if (flag_enable_cilkplus
- && is_cilkplus_reduce_builtin (fundecl))
- continue;
-
if (type == void_type_node)
{
if (selector)
@@ -3207,16 +3198,10 @@
if (typetail != 0 && TREE_VALUE (typetail) != void_type_node)
{
- /* If array notation is used and Cilk Plus is enabled, then we do not
-worry about this error now. We will handle them in a later place. */
- if (!flag_enable_cilkplus
- || !is_cilkplus_reduce_builtin (fundecl))
- {
- error_at (input_location,
- "too few arguments to function %qE", function);
- inform_declaration (fundecl);
- return -1;
- }
+ error_at (input_location,
+ "too few arguments to function %qE", function);
+ inform_declaration (fundecl);
+ return -1;
}
return error_args ? -1 : (int) parmnum;
=
Here is the testcode that I have written that should trigger the "too few
arguments to function error" with the appropriate note to say where the
function declaration is.
--
/* { dg-do compile } */
/* { dg-options "-fcilkplus" } */
/* Test-case contains no array notation but is compiled with -fcilkplus.
It will still print the too few arguments func, thereby saying the
if-statement after the for-loop to check for !flag_enable_cilkplus ||
!is_cilkplus_reduce_function (fundecl) is not valid is always taken. */
int func (int, int); /* { dg-message "declared here" } */
int main (void)
{
int a = 5, b = 2;
return func (a); /* { dg-error "too few arguments to function" } */
}
Here is the output when I run this:
bviyer@lakshmi2a:/export/users/gcc-svn/b-trunk-gcc/gcc>
../../install_dir/trunk-install/bin/gcc -fcilkplus test.c
test.c: In function âmainâ:
test.c:14:3: error: too few arguments to function âfuncâ
return func (a); /* { dg-error "too few arguments to function" } */
^
test.c:9:5: note: declared here
int func (int, int); /* { dg-message "declared here" } */
^
The whole patch with testcode is attached, so is this Ok for trunk?
Here are the ChangeLog entries:
gcc/c/ChangeLog
2013-06-05 Balaji V. Iyer
* c-typeck.c (convert_arguments): Moved checking of builtin cilkplus
reduction functions outside the for-loop. Added a check if the fundecl
is non-NULL. Finally, removed an unwanted if-statement, and made the
body unconditional
gcc/testsuite/ChangeLog
2013-06-05 Balaji V. Iyer
PR C/57457
* c-c
Re: Symtab cleanups 4/17
Honza, Also, you did not remove the declaration of mark_decl_referenced() in tree.h - David On Wed, Jun 5, 2013 at 11:15 AM, David Edelsohn wrote: > The removal of mark_decl_referenced() breaks bootstrap because some > target-specific code uses that function. > > I am trying with a change to DECL_PRESERVE_P to see if that will fix > the problem in rs6000.c > > - David
Re: [PATCH] Change uint*_type_node definition to make_or_reuse_type
On Wed, 5 Jun 2013, Andreas Krebbel wrote: > 2013-06-05 Andreas Krebbel > > * tree.c (build_common_tree_nodes): Create uint*_t type nodes with > make_or_reuse_type. I don't think either version is really what's wanted. Ideally these should match stdint.h, and sometimes you may e.g. have both unsigned long and unsigned long long as 64-bit types and need the stdint.h data to tell which to use. (That is, eliminate the separation between uint32_type_node and c_uint32_type_node, etc., with the existing c-common.c logic setting up the latter being used to set up the former.) We are, it appears, still missing stdint.h type information in GCC for NetBSD, VxWorks, Symbian, LynxOS, QNX, Interix, TPF. Maybe we need to issue a last call to maintainers caring about those targets to fill in this information, and failing that deprecate them. -- Joseph S. Myers jos...@codesourcery.com
Re: [C++ Patch] PR 51908
Hi,
On 06/05/2013 04:19 PM, Jason Merrill wrote:
On 06/05/2013 09:19 AM, Jason Merrill wrote:
In any case, the commit doesn't seem like the problem.
Oh, I see, of course it is. The problem is that it commits to all
levels, so that if we happen to be in a nested tentative parse we
can't commit to the inner one without committing to the outer one,
which might not be appropriate. This seems like a basic flaw in our
tentative parsing mechanism.
Uhmmm.
What happens if we disable that commit entirely?
Not a disaster, I'm attaching a breakdown of the regressions.
Essentially no accept invalid or reject valid, but in some cases the
quality of the diagnostic worsen a lot and/or becomes more verbose.
Now, something else I noticed a few days ago is that for C-style casts
things work fine in any case: the difference being that in that case we
set parser->in_type_id_in_expr_p to true, something we don't do for
static_cast (and the other C++ casts) in cp_parser_postfix_expression.
If I do that, then all the testcases we are considering pass with no
regressions in the testsuite. Is it something we could do? Patch draft
attached.
Thanks,
Paolo.
///
FAIL: g++.dg/other/pr39060.C -std=c++98 (test for errors, line 19)
FAIL: g++.dg/other/pr39060.C -std=c++98 (test for excess errors)
FAIL: g++.dg/other/pr39060.C -std=c++11 (test for errors, line 19)
FAIL: g++.dg/other/pr39060.C -std=c++11 (test for excess errors)
FAIL: g++.dg/parse/crash50.C -std=c++98 (test for errors, line 5)
FAIL: g++.dg/parse/crash50.C -std=c++98 (test for errors, line 9)
FAIL: g++.dg/parse/crash50.C -std=c++98 (test for excess errors)
FAIL: g++.dg/parse/crash50.C -std=c++11 (test for errors, line 5)
FAIL: g++.dg/parse/crash50.C -std=c++11 (test for errors, line 9)
FAIL: g++.dg/parse/crash50.C -std=c++11 (test for excess errors)
FAIL: g++.dg/parse/error6.C -std=gnu++98 (test for errors, line 4)
FAIL: g++.dg/parse/error6.C -std=gnu++98 (test for errors, line 5)
FAIL: g++.dg/parse/error6.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/parse/error6.C -std=gnu++11 (test for errors, line 4)
FAIL: g++.dg/parse/error6.C -std=gnu++11 (test for errors, line 5)
FAIL: g++.dg/parse/error6.C -std=gnu++11 (test for excess errors)
FAIL: g++.dg/parse/error7.C -std=gnu++98 (test for errors, line 5)
FAIL: g++.dg/parse/error7.C -std=gnu++98 (test for excess errors)
FAIL: g++.dg/parse/error7.C -std=gnu++11 (test for errors, line 5)
FAIL: g++.dg/parse/error7.C -std=gnu++11 (test for excess errors)
FAIL: g++.dg/parse/varmod1.C -std=c++98 (test for excess errors)
FAIL: g++.dg/parse/varmod1.C -std=c++11 (test for excess errors)
FAIL: g++.dg/template/crash77.C -std=c++98 (test for errors, line 3)
FAIL: g++.dg/template/crash77.C -std=c++11 (test for errors, line 3)
FAIL: g++.old-deja/g++.brendan/crash61.C -std=c++98 (test for excess errors)
FAIL: g++.old-deja/g++.brendan/crash61.C -std=c++11 (test for excess errors)
Index: cp/parser.c
===
--- cp/parser.c (revision 199690)
+++ cp/parser.c (working copy)
@@ -5546,6 +5546,7 @@ cp_parser_postfix_expression (cp_parser *parser, b
tree type;
tree expression;
const char *saved_message;
+ bool saved_in_type_id_in_expr_p;
/* All of these can be handled in the same way from the point
of view of parsing. Begin by consuming the token
@@ -5560,7 +5561,10 @@ cp_parser_postfix_expression (cp_parser *parser, b
/* Look for the opening `<'. */
cp_parser_require (parser, CPP_LESS, RT_LESS);
/* Parse the type to which we are casting. */
+ saved_in_type_id_in_expr_p = parser->in_type_id_in_expr_p;
+ parser->in_type_id_in_expr_p = true;
type = cp_parser_type_id (parser);
+ parser->in_type_id_in_expr_p = saved_in_type_id_in_expr_p;
/* Look for the closing `>'. */
cp_parser_require (parser, CPP_GREATER, RT_GREATER);
/* Restore the old message. */
Index: testsuite/g++.dg/cpp0x/decltype54.C
===
--- testsuite/g++.dg/cpp0x/decltype54.C (revision 0)
+++ testsuite/g++.dg/cpp0x/decltype54.C (working copy)
@@ -0,0 +1,26 @@
+// PR c++/51908
+// { dg-do compile { target c++11 } }
+
+struct foo1
+{
+ template
+ operator decltype(static_cast(nullptr)) () const;
+};
+
+struct foo2
+{
+ template
+ operator decltype(static_cast(nullptr)) () const;
+};
+
+struct foo3
+{
+ template
+ operator decltype(static_cast(nullptr)) () const;
+};
+
+struct foo4
+{
+ template
+ operator decltype(static_cast(nullptr)) () const;
+};
Re: Symtab cleanups 4/17
> Honza,
>
> Also, you did not remove the declaration of mark_decl_referenced() in tree.h
Sorry for the breakage. It was change in final version of patch where I noticed
that mark_decl_referenced is dead and I did not get into idea that targets may
use it.
Looking at the use cases, I think it may be completely removed or replaced
by DECL_PRESERVE_P as you do, but I will try to do this case by case.
For this reason I just commited patch reverting removal of this function.
Index: ChangeLog
===
--- ChangeLog (revision 199698)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2013-06-05 Jan Hubicka
+
+ * varasm.c (mark_decl_referenced): Revert the removal until targets
+ are fixed.
+
2013-06-05 David Edelsohn
* config/rs6000/rs6000.c (print_operand, 'z'): Use DECL_PRESERVE_P
Index: varasm.c
===
--- varasm.c(revision 199698)
+++ varasm.c(working copy)
@@ -2244,6 +2244,33 @@ mark_referenced (tree id)
TREE_SYMBOL_REFERENCED (id) = 1;
}
+/* Set the symbol_referenced flag for DECL and notify callgraph. */
+void
+mark_decl_referenced (tree decl)
+{
+ if (TREE_CODE (decl) == FUNCTION_DECL)
+{
+ /* Extern inline functions don't become needed when referenced.
+If we know a method will be emitted in other TU and no new
+functions can be marked reachable, just use the external
+definition. */
+ struct cgraph_node *node = cgraph_get_create_node (decl);
+ if (!DECL_EXTERNAL (decl)
+ && !node->symbol.definition)
+ cgraph_mark_force_output_node (node);
+}
+ else if (TREE_CODE (decl) == VAR_DECL)
+{
+ struct varpool_node *node = varpool_node_for_decl (decl);
+ /* C++ frontend use mark_decl_references to force COMDAT variables
+ to be output that might appear dead otherwise. */
+ node->symbol.force_output = true;
+}
+ /* else do nothing - we can get various sorts of CST nodes here,
+ which do not need to be marked. */
+}
+
+
/* Follow the IDENTIFIER_TRANSPARENT_ALIAS chain starting at *ALIAS
until we find an identifier that is not itself a transparent alias.
Modify the alias passed to it by reference (and all aliases on the
Re: [PATCH, rs6000] power8 patches, patch #4 (revised), new power8 builtins
* config/rs6000/rs6000.md (eqv3): Add support for powerp eqv instruction. [Typo, "powerp". There are many more typos and non-grammatical sentences.] Why isn't this covered by boolean_operator and %q output operand? The existing patterns (boolc3_...) do for eqv: (set reg (xor (not reg) reg)) which is not canonical RTL. Segher
Re: [PATCH, rs6000] power8 patches, patch #4 (revised), new power8 builtins
On Wed, Jun 05, 2013 at 05:50:21PM +0200, Segher Boessenkool wrote: > >* config/rs6000/rs6000.md (eqv3): Add support for powerp eqv > >instruction. > > [Typo, "powerp". There are many more typos and non-grammatical > sentences.] > > >Why isn't this covered by boolean_operator and %q output operand? > > The existing patterns (boolc3_...) do for eqv: > > (set reg (xor (not reg) reg)) > > which is not canonical RTL. I wasn't really aware of boolc and friends when I wrote the patches. However, I need named insns to enable vector builtin functions, so except for the splitting part, I wouldn't be able to save much rtl. I also wonder whether it would be useful to have 32-bit do the vector logical ops in gprs as well. At the moment, the patches don't allow it (vector types must be done in the altivec/vsx registers, an TImode is done by splitting the operation into 4 separate categories). On the 64-bit side, having __int128_t passed in GPRs, means you want to avoid ping-ponging between the GPRs and VSX registers. In addition, the atomic quad word support (patch #7) has to run in GPRs, so we need add/subtract/logical to have versions that run in GPRs. I can rewrite the pattern for the vector eqv so that when split it uses the format used by boolc, but since it is not canonical we would never generate it in the rare cases it might be useful to generate it. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Re: [GOOGLE] More strict checking for call args
Right, except that in the context of FDO/autoFDO, where this happens
the most (note in FDO case, it can happen with fresh profile too for
multi-threaded programs), it is not that important to handle -- the
mismatch path will never be executed, so why bother to inline and
bloat the code for it?
if (fptr_new == func_old) {
func_old (ptr); <--- do not want to inline.
}
else
fptr_new(ptr);
David
On Wed, Jun 5, 2013 at 1:31 AM, Richard Biener
wrote:
> On Wed, Jun 5, 2013 at 2:19 AM, Dehao Chen wrote:
>> attached is a testcase that would cause problem when source has changed:
>>
>> $ g++ test.cc -O2 -fprofile-generate -DOLD
>> $ ./a.out
>> $ g++ test.cc -O2 -fprofile-use
>> test.cc:34:1: internal compiler error: in operator[], at vec.h:815
>> }
>> ^
>> 0x512740 vec::operator[](unsigned int)
>> ../../gcc/vec.h:815
>> 0x512740 vec::operator[](unsigned int)
>> ../../gcc/vec.h:1244
>> 0xf24464 vec::operator[](unsigned int)
>> ../../gcc/vec.h:815
>> 0xf24464 vec::operator[](unsigned int)
>> ../../gcc/vec.h:1244
>> 0xf24464 ipa_get_indirect_edge_target_1
>> ../../gcc/ipa-cp.c:1535
>
> This use needs to be properly guarded. We can perfectly well have
> mismatching fndecl nodes in gimple calls. If we start with
>
> void fn(int, int, int);
>
> ...
> void (*x)(float, double, struct X, int) = fn;
> (*x)(1., 2., {}, 1);
>
> the GIMPLE_CALL receives the function type effective for the call
> from the source (gimple_call_fntype). Then CCP happily propagates the
> 'fn' decl and we end up with
>
> fn (1., 2., {}, 1);
>
> that is, gimple_call_fndecl is 'fn' but gimple_call_fntype is still
> void (*x)(float, double, struct X, int)!
>
> So the solution is not to fix the argument verification predicate but to make
> code aware of the fact that for the call statement gimple_call_fntype is
> relevant for what is a valid call (that's also what is verified against in
> verify_stmts) even though the ultimate called function-decl 'fn' has a
> different prototype. Thus any code propagating from a call site to
> the callee has to deal with mismatches.
>
> Richard.
>
>> 0x971b9a estimate_edge_devirt_benefit
>> ../../gcc/ipa-inline-analysis.c:2757
>> 0x973f59 estimate_edge_size_and_time
>> ../../gcc/ipa-inline-analysis.c:2789
>> 0x973f59 estimate_calls_size_and_time
>> ../../gcc/ipa-inline-analysis.c:2842
>> 0x97429f estimate_node_size_and_time
>> ../../gcc/ipa-inline-analysis.c:2929
>> 0x976077 do_estimate_edge_size(cgraph_edge*)
>> ../../gcc/ipa-inline-analysis.c:3472
>> 0x97614f estimate_edge_size
>> ../../gcc/ipa-inline.h:274
>> 0x97614f estimate_edge_growth
>> ../../gcc/ipa-inline.h:286
>> 0x97614f do_estimate_growth_1
>> ../../gcc/ipa-inline-analysis.c:3582
>> 0x7e41df cgraph_for_node_and_aliases
>> ../../gcc/cgraph.c:1777
>> 0x976675 do_estimate_growth(cgraph_node*)
>> ../../gcc/ipa-inline-analysis.c:3596
>> 0xf314ea estimate_growth
>> ../../gcc/ipa-inline.h:261
>> 0xf314ea inline_small_functions
>> ../../gcc/ipa-inline.c:1432
>> 0xf314ea ipa_inline
>> ../../gcc/ipa-inline.c:1797
>> Please submit a full bug report,
>> with preprocessed source if appropriate.
>> Please include the complete backtrace with any bug report.
>> See for instructions.
Re: [PATCH, rs6000] power8 patches, patch #4 (revised), new power8 builtins
On Wed, Jun 05, 2013 at 10:28:02AM -0400, David Edelsohn wrote: > +;; The canonical form is to have the negated elment first, so we need to > +;; reverse arguments. > > Please fix the typo in the comment: "element". Ok. I need to proof-read the patches before sending them out. > +;; Like VSX_L, but don't support TImode for doing logical instructions in > +;; 32-bit > +(define_mode_iterator VSX_L2 [V16QI V8HI V4SI V2DI V4SF V2DF]) > + > ;; Iterator for memory move. Handle TImode specially to allow > ;; it to use gprs as well as vsx registers. > (define_mode_iterator VSX_M [V16QI V8HI V4SI V2DI V4SF V2DF]) > > +(define_mode_iterator VSX_M2 [V16QI > + V8HI > + V4SI > + V2DI > + V4SF > + V2DF > + (TI"TARGET_VSX_TIMODE")]) > > The patch adds new iterators VSX_L2 and VSX_M2. The original > ChangeLog only mentioned M2 and the new ChangeLog only mentions L2. > What's going on? I thought I had deleted VSX_M2 from this patch. It will be needed in patch #8 for the fusion peephole. The difference is VSX_L2 avoids TImode altogether, and was used by the logical ops to prevent TImode operations in VSX registers in 32-bit. The problem is unless we have expanders/splitters for logical DImode, the compiler when it wants to do a logical DImode operation says, aha I have a TImode operation, and then it converts the DImode value to TImode, does the operation (which in turn may mean transfer between GPR and VSX registers). I can add splitters and such for 32-bit DImode to prevent this, but I don't know if you want me to do it in the context of this patch, or do it as a later patch. > * config/rs6000/rs6000.md (eqv3): Add support for powerp eqv > instruction. > > Why isn't this covered by boolean_operator and %q output operand? And > why can't that predicate and output operand handle vsx as well, e.g., > *vsx_eqv? Why don't we simply have vsx_bool3, etc. See my reply to Segher that boolc doesn't use the canonical form, so eqv is not currently generated. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Re: [2/n] Partial IT block deprecation in ARMv8 AArch32 - define_cond_exec machinery
On 05/06/13 15:41, Kyrylo Tkachov wrote: Hi all, This patch adds the attributes to arm.md that are used to control the conditions under which we can predicate an insn. We use the new attributes field for define_cond_exec that was defined in a recent patch. Whenever an insn is predicated through define_cond_exec, it has the attribute "predicated" set to "yes". The "enabled" definition is updated to take "predicated" and arm_restric_it into account to disable the predicated version when appropriate. Now, if we want to disable the predicated version of an alternative for arm_restrict_it we leave the "predicable" attribute as "yes" and set the "predicable_short_it" attribute to "no". The enabled_for_depr_it attribute is used to disable alternatives in some cases where explicit IT blocks are used in the output template. Ok for trunk? 2013-06-05 Kyrylo Tkachov * config/arm/arm.md (enabled_for_depr_it): New attribute. (predicable_short_it): Likewise. (predicated): Likewise. (enabled): Handle above. (define_cond_exec): Set predicated attribute to yes. OK. R.
better gdb support for debugging gcc
Here is a little one to add support for __FUNCTION__ to gdb so that we can debug gcc… Committed revision 199702. 2013-06-05 Mike Stump * gdbinit.in (__FUNCTION__): Add. Index: gdbinit.in === --- gdbinit.in (revision 199700) +++ gdbinit.in (working copy) @@ -184,6 +184,7 @@ end # Define some macros helpful to gdb when it is expanding macros. macro define __FILE__ "gdb" macro define __LINE__ 1 +macro define __FUNCTION__ "gdb" macro define __null 0 # Gracefully handle aborts in functions used from gdb.
[PATCH][ARM][3/n] Partial IT block deprecation in ARMv8 AArch32 - atomics patterns
Hi all, This patch restricts predication for the various atomics patterns in sync.md by using the new predicable_short_it mechanism. The load/store exclusive and the acquire/release instructions cannot be contained inside IT blocks in ARMv8 so the logic behind disabling their predicable versions for ARMv8 Thumb mode is pretty straightforward. Tested together with the other patches in the series by bootstrap on Cortex-A15 and regtest arm-none-eabi on qemu and model. Ok for trunk? Thanks, Kyrill 2013-06-05 Kyrylo Tkachov * config/arm/sync.md (atomic_loaddi_1): Disable predication for arm_restrict_it. (arm_load_exclusive): Likewise. (arm_load_exclusivesi): Likewise. (arm_load_exclusivedi): Likewise. (arm_load_acquire_exclusive): Likewise. (arm_load_acquire_exclusivesi): Likewise. (arm_load_acquire_exclusivedi): Likewise. (arm_store_exclusive): Likewise. (arm_store_exclusive): Likewise. (arm_store_release_exclusivedi): Likewise. (arm_store_release_exclusive): Likewise. 04-atomics.patch Description: Binary data
Re: [PATCH] Improve folding of bitwise ops on booleans
2013/6/4 Jeff Law :
> On 06/03/2013 08:23 AM, Kai Tietz wrote:
>>
>>
>> Btw there is one optimization in this context which might be something
>> worth here too.
>> -X -> X for 1-bit typed X (signed doesn't matter here).
>
> I've had a hell of a time trying to trigger a case where this isn't already
> handled. Samples welcome.
A sample for this is
typedef struct onebit {
unsigned int i : 1;
} onebit;
_Bool boo (onebit a, onebit b, onebit c)
{
onebit i1, i2;
i1.i = a.i + b.i;
i2.i = a.i + c.i;
i1.i -= i2.i;
i1.i -= b.i;
return i1.i;
}
Kai
[PATCH][ARM][4/n] Partial IT block deprecation in ARMv8 AArch32 - load/store multiple patterns
Hi all, ARMv8-style IT blocks don't allow load/store multiple instructions (ldm, stm), so this patch disables the predicable forms of the corresponding patterns. The ldm/stm patterns are generated through an Ocaml script, which is updated to reflect the new rules. The ldmstm.md file is regenerated. The changes are quite straightforward. Tested together with the other patches in the series by bootstrap on a Cortex-A15 and regtest arm-none-eabi on qemu and model. Ok for trunk? Thanks, Kyrill 2013-06-05 Kyrylo Tkachov * config/arm/arm-ldmstm.ml: Set "predicable_short_it" to "no" where appropriate. * config/arm/ldmstm.md: Regenerate. 05-ldmstm.patch Description: Binary data
RFA: fix libstdc++ pretty-printer test
The pretty-printer test "shared_ptr.cc" fails for me on x86-64 Fedora 18.
The local variable "esp" is optimized out.
Since the purpose of this test is to test the pretty-printers, it seemed
simplest to me to just disable optimizations. The appended fixes the
problem for me.
Ok?
Tom
2013-06-05 Tom Tromey
* testsuite/libstdc++-prettyprinters/shared_ptr.cc: Use -O0.
diff --git a/libstdc++-v3/testsuite/libstdc++-prettyprinters/shared_ptr.cc
b/libstdc++-v3/testsuite/libstdc++-prettyprinters/shared_ptr.cc
index 547213f..0e4e6c2 100644
--- a/libstdc++-v3/testsuite/libstdc++-prettyprinters/shared_ptr.cc
+++ b/libstdc++-v3/testsuite/libstdc++-prettyprinters/shared_ptr.cc
@@ -1,5 +1,5 @@
// { dg-do run }
-// { dg-options "-std=gnu++11 -g" }
+// { dg-options "-std=gnu++11 -g -O0" }
// Copyright (C) 2012-2013 Free Software Foundation, Inc.
//
Re: [C++ Patch] PR 51908
On 06/05/2013 11:45 AM, Paolo Carlini wrote: Now, something else I noticed a few days ago is that for C-style casts things work fine in any case: the difference being that in that case we set parser->in_type_id_in_expr_p to true, something we don't do for static_cast (and the other C++ casts) in cp_parser_postfix_expression. If I do that, then all the testcases we are considering pass with no regressions in the testsuite. Is it something we could do? Patch draft attached. OK. Jason
Re: better gdb support for debugging gcc
> "Mike" == Mike Stump writes: Mike> Here is a little one to add support for __FUNCTION__ to gdb so that we Mike> can debug gcc… Arguably this should be done in gdb. Could you file a bug for that? Tom
Re: [PATCH, rs6000] power8 patches, patch #4 (revised), new power8 builtins
On Wed, Jun 5, 2013 at 12:13 PM, Michael Meissner wrote: > I thought I had deleted VSX_M2 from this patch. It will be needed in patch #8 > for the fusion peephole. The difference is VSX_L2 avoids TImode altogether, > and was used by the logical ops to prevent TImode operations in VSX registers > in 32-bit. > > The problem is unless we have expanders/splitters for logical DImode, the > compiler when it wants to do a logical DImode operation says, aha I have a > TImode operation, and then it converts the DImode value to TImode, does the > operation (which in turn may mean transfer between GPR and VSX registers). > > I can add splitters and such for 32-bit DImode to prevent this, but I don't > know if you want me to do it in the context of this patch, or do it as a later > patch. I don't have a preference whether the iterator is added now or later, but I want the ChangeLog to match the patch. > >> * config/rs6000/rs6000.md (eqv3): Add support for powerp eqv >> instruction. >> >> Why isn't this covered by boolean_operator and %q output operand? And >> why can't that predicate and output operand handle vsx as well, e.g., >> *vsx_eqv? Why don't we simply have vsx_bool3, etc. > > See my reply to Segher that boolc doesn't use the canonical form, so eqv is > not > currently generated. Okay, I understand that the bool patterns no longer are matching canonical RTL after the canonical RTL was changed. Unfortunately, there were no powerpc-specific tests to ensure that those instructions are generated. I also understand that you need to match builtins. But I would like vector.md and vsx.md to use the boolean operator iterators. I don't think that the patterns explicitly need to be duplicated. This creates more clutter and more opportunity for mistakes and differences. Thanks, David
Re: RFA: fix libstdc++ pretty-printer test
On 5 June 2013 17:59, Tom Tromey wrote: > The pretty-printer test "shared_ptr.cc" fails for me on x86-64 Fedora 18. > The local variable "esp" is optimized out. > > Since the purpose of this test is to test the pretty-printers, it seemed > simplest to me to just disable optimizations. The appended fixes the > problem for me. > > Ok? OK, thanks.
[RFC] Implement Undefined Behavior Sanitizer
Hi!
This is an attempt to add the Undefined Behavior Sanitizer to GCC.
Note that it's very alpha version; so far it doesn't do that much,
at the moment it should handle division by zero cases, INT_MIN / -1,
and various shift cases (shifting by a negative value, shifting when
second operand is >= than TYPE_PRECISION (first_operand) and suchlike.
(On integer types, so far.)
It works by creating a COMPOUND_EXPR around original expression, so e.g.
it creates:
if (b < 0 || (b > 31 || a < 0))
{
__builtin___ubsan_handle_shift_out_of_bounds ();
}
else
{
0
}, a << b;
from original "a <<= b;".
There is of course a lot of stuff that needs to be done, more
specifically:
0) fix an ICE which I've noticed right now ;(
long a = 1;
int b = 3;
a <<= b;
(error: mismatching comparison operand types)
temporarily solved by surrounding "doing_shift = true;"
with if (comptypes (type0, type1))
But that needs a better solution I'm afraid. Bah.
1) import & build the ubsan library from LLVM
I've already spent some time on this, but failed miserably. I've thought
that importing ubsan/ from LLVM into libsanitizer/, adding
libsanitizer/ubsan/Makefile.{am,in}, editing libsanitizer/Makefile.am
and libsanitizer/configure.ac, then something like aclocal && automake
could be sufficient, but no. I'd very much appreciate any help with
this; is someone willing to help me with this one? And it seemed so
easy...
2) construct arguments for ubsan library
I guess that if we want to call for instance
void __ubsan::__ubsan_handle_shift_out_of_bounds(ShiftOutOfBoundsData
*Data,
ValueHandle LHS, ValueHandle
RHS)
from GCC, we need to construct arguments compatible with
ShiftOutOfBoundsData/ValueHandle.
So, perhaps we need some helper function that constructs the CALL_EXPR
for the builtin; so far I haven't spent much time on this and don't know
what exactly to do here. Time to look at what asan/tsan do.
3) add parsing of -fsanitize=<...>
LLVM supports e.g. -fsanitize=shift,divbyzero combination, we should too.
This doesn't sound like a big deal; just parse the arguments and set
various flags, or error out on invalid combinations.
4) and of course, more instrumentation (C/C++ FE, gimple level)
What comes to mind is:
- float/double to integer conversions,
- integer overflows (a long list of various cases here),
- invalid conversions of int to bool,
- reaching a __builtin_unreachable() call,
- VLAs size (e.g. negative size),
- store to/load of misaligned address,
- store to/load of null pointer,
- etc.
For the time being, I plan to work on overflows instrumentation.
Regtested/bootstrapped on x86_64-linux.
Comments, please?
2013-06-05 Marek Polacek
* Makefile.in: Add ubsan.c
* common.opt: Add -fsanitize=undefined option.
* doc/invoke.texi: Document the new flag.
* ubsan.h: New file.
* ubsan.c): New file.
* sanitizer.def (DEF_SANITIZER_BUILTIN):
* builtins.def: Define BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW and
BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS.
* cp/typeck.c (cp_build_binary_op): Add division by zero and shift
instrumentation.
* c/c-typeck.c (build_binary_op): Likewise.
* builtin-attrs.def: Define ATTR_COLD.
* asan.c (initialize_sanitizer_builtins): Build
BT_FN_VOID_PTR_PTR_PTR.
--- gcc/sanitizer.def.mp2013-06-05 18:23:41.077439836 +0200
+++ gcc/sanitizer.def 2013-06-05 18:26:04.749921181 +0200
@@ -283,3 +283,13 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_ATOM
DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_ATOMIC_SIGNAL_FENCE,
"__tsan_atomic_signal_fence",
BT_FN_VOID_INT, ATTR_NOTHROW_LEAF_LIST)
+
+/* Undefined Behavior Sanitizer */
+DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW,
+ "__ubsan_handle_divrem_overflow",
+ BT_FN_VOID_PTR_PTR_PTR,
+ ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST)
+DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS,
+ "__ubsan_handle_shift_out_of_bounds",
+ BT_FN_VOID_PTR_PTR_PTR,
+ ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST)
--- gcc/builtins.def.mp 2013-06-05 18:23:41.072439816 +0200
+++ gcc/builtins.def2013-06-05 18:26:04.728921097 +0200
@@ -155,7 +155,7 @@ along with GCC; see the file COPYING3.
#define DEF_SANITIZER_BUILTIN(ENUM, NAME, TYPE, ATTRS) \
DEF_BUILTIN (ENUM, "__builtin_" NAME, BUILT_IN_NORMAL, TYPE, TYPE,\
true, true, true, ATTRS, true, \
- (flag_asan || flag_tsan))
+ (flag_asan || flag_tsan || flag_ubsan))
#undef DEF_CILKPLUS_BUILTIN
#define DEF_CILKPLUS_BUILTIN(ENUM, NAME, TYPE, ATTRS) \
--- gcc/Makefile.in.m
Re: [patch] gcov intermediate format
Ping.
Thanks,
Sharad
On Tue, May 28, 2013 at 11:35 AM, Sharad Singhai wrote:
> Sorry, my patch had bad formatting in one of the functions
> (output_gcov_file). Here is the corrected version.
>
> Thanks,
> Sharad
>
> (2013-05-28
>
> * gcov.c (print_usage): Handle new option.
> (process_args): Ditto.
> (get_gcov_intermediate_filename): New function.
> (output_intermediate_file): New function.
> (output_gcov_file): New function
> (generate_results): Handle new option.
> (release_function): Relase demangled name.
> (read_graph_file): Handle demangled name.
> (output_lines): Ditto.
> * doc/gcov.texi: Document gcov intermediate format.
>
> testsuite/ChangeLog:
>
> 2013-05-28 Sharad Singhai
>
> * g++.dg/gcov/gcov-8.C: New testcase.
> * lib/gcov.exp: Handle intermediate format.
>
> Index: doc/gcov.texi
> ===
> --- doc/gcov.texi (revision 199273)
> +++ doc/gcov.texi (working copy)
> @@ -122,15 +122,17 @@ gcov [@option{-v}|@option{--version}] [@option{-h}
> [@option{-a}|@option{--all-blocks}]
> [@option{-b}|@option{--branch-probabilities}]
> [@option{-c}|@option{--branch-counts}]
> - [@option{-u}|@option{--unconditional-branches}]
> + [@option{-d}|@option{--display-progress}]
> + [@option{-f}|@option{--function-summaries}]
> + [@option{-i}|@option{--intermediate-format}]
> + [@option{-l}|@option{--long-file-names}]
> + [@option{-m}|@option{--demangled-names}]
> [@option{-n}|@option{--no-output}]
> - [@option{-l}|@option{--long-file-names}]
> + [@option{-o}|@option{--object-directory} @var{directory|file}]
> [@option{-p}|@option{--preserve-paths}]
> [@option{-r}|@option{--relative-only}]
> - [@option{-f}|@option{--function-summaries}]
> - [@option{-o}|@option{--object-directory} @var{directory|file}]
> [@option{-s}|@option{--source-prefix} @var{directory}]
> - [@option{-d}|@option{--display-progress}]
> + [@option{-u}|@option{--unconditional-branches}]
> @var{files}
> @c man end
> @c man begin SEEALSO
> @@ -232,6 +234,50 @@ Unconditional branches are normally not interestin
> @itemx --display-progress
> Display the progress on the standard output.
>
> +@item -i
> +@itemx --intermediate-format
> +Output gcov file in an easy-to-parse intermediate text format that can
> +be used by @command{lcov} or other tools. The output is a single
> +@file{.gcov} file per @file{.gcda} file. No source code is required.
> +
> +The format of the intermediate @file{.gcov} file is plain text with
> +one entry per line
> +
> +@smallexample
> +file:@var{source_file_name}
> +function:@var{line_number},@var{execution_count},@var{function_name}
> +lcount:@var{line number},@var{execution_count}
> +branch:@var{line_number},@var{branch_coverage_type}
> +
> +Where the @var{branch_coverage_type} is
> + notexec (Branch not executed)
> + taken (Branch executed and taken)
> + nottaken (Branch executed, but not taken)
> +
> +There can be multiple @var{file} entries in an intermediate gcov
> +file. All entries following a @var{file} pertain to that source file
> +until the next @var{file} entry.
> +@end smallexample
> +
> +Here is a sample when @option{-i} is used in conjuction with
> @option{-b} option:
> +
> +@smallexample
> +file:array.cc
> +function:11,1,_Z3sumRKSt6vectorIPiSaIS0_EE
> +function:22,1,main
> +lcount:11,1
> +lcount:12,1
> +lcount:14,1
> +branch:14,taken
> +lcount:26,1
> +branch:28,nottaken
> +@end smallexample
> +
> +@item -m
> +@itemx --demangled-names
> +Display demangled function names in output. The default is to show
> +mangled function names.
> +
> @end table
>
> @command{gcov} should be run with the current directory the same as that
> Index: gcov.c
> ===
> --- gcov.c (revision 199273)
> +++ gcov.c (working copy)
> @@ -37,6 +37,7 @@ along with Gcov; see the file COPYING3. If not se
> #include "intl.h"
> #include "diagnostic.h"
> #include "version.h"
> +#include "demangle.h"
>
> #include
>
> @@ -168,6 +169,7 @@ typedef struct function_info
> {
>/* Name of function. */
>char *name;
> + char *demangled_name;
>unsigned ident;
>unsigned lineno_checksum;
>unsigned cfg_checksum;
> @@ -325,6 +327,14 @@ static int flag_gcov_file = 1;
>
> static int flag_display_progress = 0;
>
> +/* Output *.gcov file in intermediate format used by 'lcov'. */
> +
> +static int flag_intermediate_format = 0;
> +
> +/* Output demangled function names. */
> +
> +static int flag_demangled_names = 0;
> +
> /* For included files, make the gcov output file name include the name
> of the input source file. For example, if x.h is included in a.c,
> then the output file name is a.c##x.h.gcov instead of x.h.gcov. */
> @@ -388,6 +398,7 @@ static void executed_summary (unsigned, unsigned);
> static void function_summary (const coverage_t *, const char *);
> static const char *for
Re: [patch] Fix parsing bug in validate_patches.py
On 06/04/2013 03:57 PM, Diego Novillo wrote:
OK with this predicate factored into a predicate function (maybe
SummaryLineHasAttributes?)
Thanks! Once I dove into that, I ended up doing a bit more refactoring;
it really makes sense to pull the whole line-splitting into a separate
function along with this.
Thus, I'm attaching an updated patch file that reflects that, along with
a couple of other trivial changes I added since submitting the initial
patch.
I've tested the adjusted line-stripping parts of the refactored code by
adding and removing spaces in lines in my xfails file and confirming
that things are still correctly matched.
Is this refactoring also OK to commit?
Thanks,
- Brooks
This patch implements a bit of refactoring of the validate_failures.py script
in contrib/testsuite-management. In the script, there are two separate
locations where a (potential) summary line is split off from any preceding
attributes and extraneous whitespace is stripped. This patch refactors those
into calls to a single SplitAttributesFromSummaryLine function.
In addition, a couple of bugs are fixed in the process.
First, validate_failures.py has problems with test lines that contain a "|"
character in the actual message, because the DejaGnu output will be split
at the "|" as if it is prefixed by attributes, and the remainder is then
discarded as it does not match the pattern for a valid summary line. Thus,
we only split a line if it is not already valid.
Second, we do not correctly handle xfailing of lines where the description
is empty, as occurs occasionally in tests such as the libstdc++-abi/abi_check
test. This patch fixes that by adjusting the regular-expression matching to
allow for the absence of whitespace after the name.
Finally, the comment for "expected results not present" has been clarified to
account for the cases such as when a given testsuite simply wasn't run.
Index: contrib/testsuite-management/validate_failures.py
===
--- contrib/testsuite-management/validate_failures.py (revision 199615)
+++ contrib/testsuite-management/validate_failures.py (working copy)
@@ -119,20 +119,15 @@
def __init__(self, summary_line, ordinal=-1):
try:
- self.attrs = ''
- if '|' in summary_line:
-(self.attrs, summary_line) = summary_line.split('|', 1)
+ (self.attrs, summary_line) = SplitAttributesFromSummaryLine(summary_line)
try:
(self.state,
self.name,
- self.description) = re.match(r' *([A-Z]+):\s*(\S+)\s+(.*)',
+ self.description) = re.match(r'([A-Z]+):\s*(\S+)\s*(.*)',
summary_line).groups()
except:
print 'Failed to parse summary line: "%s"' % summary_line
raise
- self.attrs = self.attrs.strip()
- self.state = self.state.strip()
- self.description = self.description.strip()
self.ordinal = ordinal
except ValueError:
Error('Cannot parse summary line "%s"' % summary_line)
@@ -208,11 +203,20 @@
return line.startswith('#')
+def SplitAttributesFromSummaryLine(line):
+ """Splits off attributes from a summary line, if present."""
+ if '|' in line and not _VALID_TEST_RESULTS_REX.match(line):
+(attrs, line) = line.split('|', 1)
+attrs = attrs.strip()
+ else:
+attrs = ''
+ line = line.strip()
+ return (attrs, line)
+
+
def IsInterestingResult(line):
"""Return True if line is one of the summary lines we care about."""
- if '|' in line:
-(_, line) = line.split('|', 1)
-line = line.strip()
+ (_, line) = SplitAttributesFromSummaryLine(line)
return bool(_VALID_TEST_RESULTS_REX.match(line))
@@ -416,8 +420,9 @@
if not ignore_missing_failures and len(expected_vs_actual) > 0:
PrintSummary('Expected results not present in this build (fixed tests)'
'\n\nNOTE: This is not a failure. It just means that these '
- 'tests were expected\nto fail, but they worked in this '
- 'configuration.\n', expected_vs_actual)
+ 'tests were expected\nto fail, but either they worked in '
+ 'this configuration or they were not\npresent at all.\n',
+ expected_vs_actual)
if tests_ok:
print '\nSUCCESS: No unexpected failures.'
Re: [RFC] Implement Undefined Behavior Sanitizer
On Wed, Jun 5, 2013 at 10:57 AM, Marek Polacek wrote:
> Hi!
>
> This is an attempt to add the Undefined Behavior Sanitizer to GCC.
> Note that it's very alpha version; so far it doesn't do that much,
> at the moment it should handle division by zero cases, INT_MIN / -1,
> and various shift cases (shifting by a negative value, shifting when
> second operand is >= than TYPE_PRECISION (first_operand) and suchlike.
> (On integer types, so far.)
>
> It works by creating a COMPOUND_EXPR around original expression, so e.g.
> it creates:
>
> if (b < 0 || (b > 31 || a < 0))
> {
> __builtin___ubsan_handle_shift_out_of_bounds ();
> }
> else
> {
> 0
> }, a << b;
>
> from original "a <<= b;".
>
> There is of course a lot of stuff that needs to be done, more
> specifically:
> 0) fix an ICE which I've noticed right now ;(
> long a = 1;
> int b = 3;
> a <<= b;
> (error: mismatching comparison operand types)
> temporarily solved by surrounding "doing_shift = true;"
> with if (comptypes (type0, type1))
> But that needs a better solution I'm afraid. Bah.
> 1) import & build the ubsan library from LLVM
> I've already spent some time on this, but failed miserably. I've thought
> that importing ubsan/ from LLVM into libsanitizer/, adding
> libsanitizer/ubsan/Makefile.{am,in}, editing libsanitizer/Makefile.am
> and libsanitizer/configure.ac, then something like aclocal && automake
> could be sufficient, but no. I'd very much appreciate any help with
> this; is someone willing to help me with this one? And it seemed so
> easy...
> 2) construct arguments for ubsan library
> I guess that if we want to call for instance
> void __ubsan::__ubsan_handle_shift_out_of_bounds(ShiftOutOfBoundsData
> *Data,
> ValueHandle LHS, ValueHandle
> RHS)
> from GCC, we need to construct arguments compatible with
> ShiftOutOfBoundsData/ValueHandle.
> So, perhaps we need some helper function that constructs the CALL_EXPR
> for the builtin; so far I haven't spent much time on this and don't know
> what exactly to do here. Time to look at what asan/tsan do.
> 3) add parsing of -fsanitize=<...>
> LLVM supports e.g. -fsanitize=shift,divbyzero combination, we should too.
> This doesn't sound like a big deal; just parse the arguments and set
> various flags, or error out on invalid combinations.
> 4) and of course, more instrumentation (C/C++ FE, gimple level)
> What comes to mind is:
> - float/double to integer conversions,
> - integer overflows (a long list of various cases here),
> - invalid conversions of int to bool,
> - reaching a __builtin_unreachable() call,
> - VLAs size (e.g. negative size),
> - store to/load of misaligned address,
> - store to/load of null pointer,
> - etc.
> For the time being, I plan to work on overflows instrumentation.
>
> Regtested/bootstrapped on x86_64-linux.
>
> Comments, please?
I think it might be better to do handle this while gimplification
happens rather than while parsing. The main reason is that constexpr
might fail due to the added function calls.
Also please don't shorten file names like ubsan, we already have file
names which don't fit in the older POSIX tar format and needs extended
length support.
Thanks,
Andrew Pinski
>
> 2013-06-05 Marek Polacek
>
> * Makefile.in: Add ubsan.c
> * common.opt: Add -fsanitize=undefined option.
> * doc/invoke.texi: Document the new flag.
> * ubsan.h: New file.
> * ubsan.c): New file.
> * sanitizer.def (DEF_SANITIZER_BUILTIN):
> * builtins.def: Define BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW and
> BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS.
> * cp/typeck.c (cp_build_binary_op): Add division by zero and shift
> instrumentation.
> * c/c-typeck.c (build_binary_op): Likewise.
> * builtin-attrs.def: Define ATTR_COLD.
> * asan.c (initialize_sanitizer_builtins): Build
> BT_FN_VOID_PTR_PTR_PTR.
>
> --- gcc/sanitizer.def.mp2013-06-05 18:23:41.077439836 +0200
> +++ gcc/sanitizer.def 2013-06-05 18:26:04.749921181 +0200
> @@ -283,3 +283,13 @@ DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_ATOM
> DEF_SANITIZER_BUILTIN(BUILT_IN_TSAN_ATOMIC_SIGNAL_FENCE,
> "__tsan_atomic_signal_fence",
> BT_FN_VOID_INT, ATTR_NOTHROW_LEAF_LIST)
> +
> +/* Undefined Behavior Sanitizer */
> +DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW,
> + "__ubsan_handle_divrem_overflow",
> + BT_FN_VOID_PTR_PTR_PTR,
> + ATTR_COLD_NORETURN_NOTHROW_LEAF_LIST)
> +DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS,
> + "__ubsan_handle_shift_out_of_bounds",
> + BT_FN_VOID_PTR_PTR_PTR,
> +
Re: [RFC] Implement Undefined Behavior Sanitizer
On Wed, Jun 05, 2013 at 07:57:28PM +0200, Marek Polacek wrote:
> There is of course a lot of stuff that needs to be done, more
> specifically:
> 0) fix an ICE which I've noticed right now ;(
> long a = 1;
> int b = 3;
> a <<= b;
> (error: mismatching comparison operand types)
> temporarily solved by surrounding "doing_shift = true;"
> with if (comptypes (type0, type1))
> But that needs a better solution I'm afraid. Bah.
> + tree t, tt;
> + tree orig = build2 (code, TREE_TYPE (op0), op0, op1);
> + tree prec = build_int_cst (TREE_TYPE (op0),
> + TYPE_PRECISION (TREE_TYPE (op0)));
You compare prec with op1, thus they should have the same type, shifts
are one of the few binary ops that can have different types of the
operands (result type is the same as first argument, second argument
is something else). So, if you use TREE_TYPE (op1) as the type of prec,
you should be fine. More importantly, perhaps you can just use
precm1 in all the places and just use GT_EXPR for tt with precm1, and
use it in EQ.
That said, the C99 rules look somewhat different. 0 << 31 is perfectly
valid, int x = 0; x << 31 is as well. Undefined is in C99 (likely C11 too
and maybe C89 as well?) is the usual shift count out of bounds (negative or
>= prec), or if the first operand is signed and negative, or if the first
operand is signed positive, but for x << y the expression x * 2^y overflows
in the type of x.
> 1) import & build the ubsan library from LLVM
> I've already spent some time on this, but failed miserably. I've thought
> that importing ubsan/ from LLVM into libsanitizer/, adding
> libsanitizer/ubsan/Makefile.{am,in}, editing libsanitizer/Makefile.am
> and libsanitizer/configure.ac, then something like aclocal && automake
> could be sufficient, but no. I'd very much appreciate any help with
> this; is someone willing to help me with this one? And it seemed so
> easy...
I'll look at this tomorrow.
> 2) construct arguments for ubsan library
> I guess that if we want to call for instance
> void __ubsan::__ubsan_handle_shift_out_of_bounds(ShiftOutOfBoundsData
> *Data,
> ValueHandle LHS, ValueHandle
> RHS)
> from GCC, we need to construct arguments compatible with
> ShiftOutOfBoundsData/ValueHandle.
> So, perhaps we need some helper function that constructs the CALL_EXPR
> for the builtin; so far I haven't spent much time on this and don't know
> what exactly to do here. Time to look at what asan/tsan do.
> 3) add parsing of -fsanitize=<...>
> LLVM supports e.g. -fsanitize=shift,divbyzero combination, we should too.
> This doesn't sound like a big deal; just parse the arguments and set
> various flags, or error out on invalid combinations.
> 4) and of course, more instrumentation (C/C++ FE, gimple level)
> What comes to mind is:
> - float/double to integer conversions,
> - integer overflows (a long list of various cases here),
> - invalid conversions of int to bool,
> - reaching a __builtin_unreachable() call,
> - VLAs size (e.g. negative size),
> - store to/load of misaligned address,
> - store to/load of null pointer,
> - etc.
> For the time being, I plan to work on overflows instrumentation.
For at least signed addition, subtraction, multiplication overflow we
ideally want to handle it very efficiently on CPUs that can handle it
efficiently, so pretty much say on x86_64/i386 addl followed by jo
We need some builtin for that, either one with two return values
(this can be done right now say by returning a vector or complex int,
one integer will be the result of the addition/subtraction/multiplication,
another one a flag whether we've overflowed), or maybe we want new tree code
for that or something.
> 2013-06-05 Marek Polacek
>
> * Makefile.in: Add ubsan.c
Missing dot at end of line.
> * common.opt: Add -fsanitize=undefined option.
> * doc/invoke.texi: Document the new flag.
> * ubsan.h: New file.
> * ubsan.c): New file.
Extra ). If prefer if the support routines for ubsan instrumentation
done in the C/C++ FEs only would live in c-family/c-ubsan.[ch] or so.
ubsan.[ch] can perhaps then be used for any instrumentation done at the
gimplification level (if anything is suitable for that), or as support code
for both of that and c-ubsan.c.
> * sanitizer.def (DEF_SANITIZER_BUILTIN):
Define. ?
> * builtins.def: Define BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW and
> BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS.
* builtins.def (BUILT_IN_UBSAN_HANDLE_DIVREM_OVERFLOW,
BUILT_IN_UBSAN_HANDLE_SHIFT_OUT_OF_BOUNDS): Define.
cp/ stuff goes into cp/ ChangeLog, without cp/ paths.
> * cp/typeck.c (cp_build_binary_op): Add division by zero and shift
> instrumentation.
Please make sure you o
[libstdc++-v3][C++14] Implement N3654 - Quoted Strings
Greetings,
This patch implements quoted string manipulators for C++14.
27.7.6 - Quoted manipulators[quoted.manip].
The idea is to allow round trip insert and extract of strings with spaces.
std::stringstream ss;
std::string original = "thing1 thing1";
std::string round_trip;
ss << std::quoted(original);
ss >> std::quoted(round_trip);
assert( original == round_trip );
Builds and tests clean on x86-64-linux.
Ed Smith-Rowland
2013-06-05 Ed Smith-Rowland <3dw...@verizon.net>
Implement N3654 - Quoted Strings Library Proposal
* include/std/iomanip: Add quoted(String, Char delim, Char escape)
manipulators and supporting machinery in c++1y mode.
* testsuite/27_io/manipulators/standard/char/quoted.cc: New.
* testsuite/27_io/manipulators/standard/wchar_t/quoted.cc: New.
Index: include/std/iomanip
===
--- include/std/iomanip (revision 199583)
+++ include/std/iomanip (working copy)
@@ -336,6 +336,160 @@
#endif
+#if __cplusplus > 201103L
+
+ namespace __detail {
+
+/**
+ * @brief Struct for delimited strings.
+ *The left and right delimiters can be different.
+ */
+template
+ struct _Quoted_string
+ {
+ _Quoted_string(_String __str, _CharT __del, _CharT __esc)
+ : __string(__str), __delim{__del}, __escape{__esc}, __delim2{__del}
+ { }
+
+ _Quoted_string(_String __str, _CharT __del, _CharT __esc,
+ _CharT __del2)
+ : __string(__str), __delim{__del}, __escape{__esc}, __delim2{__del2}
+ { }
+
+ _Quoted_string&
+ operator=(_Quoted_string&) = delete;
+
+ _String __string;
+ _CharT __delim;
+ _CharT __escape;
+ _CharT __delim2;
+ };
+
+/**
+ * @brief Inserter for delimited strings.
+ *The left and right delimiters can be different.
+ */
+template
+ std::basic_ostream<_CharT, _Traits>&
+ operator<<(std::basic_ostream<_CharT, _Traits>& __os,
+const _Quoted_string& __str)
+ {
+ __os << __str.__delim;
+ for (const _CharT* __c = __str.__string; *__c; ++__c)
+ {
+ if (*__c == __str.__delim || *__c == __str.__escape)
+ __os << __str.__escape;
+ __os << *__c;
+ }
+ __os << __str.__delim2;
+
+ return __os;
+ }
+
+/**
+ * @brief Inserter for delimited strings.
+ *The left and right delimiters can be different.
+ */
+template
+ std::basic_ostream<_CharT, _Traits>&
+ operator<<(std::basic_ostream<_CharT, _Traits>& __os,
+const _Quoted_string<_String, _CharT>& __str)
+ {
+ __os << __str.__delim;
+ for (auto& __c : __str.__string)
+ {
+ if (__c == __str.__delim || __c == __str.__escape)
+ __os << __str.__escape;
+ __os << __c;
+ }
+ __os << __str.__delim2;
+
+ return __os;
+ }
+
+/**
+ * @brief Extractor for delimited strings.
+ *The left and right delimiters can be different.
+ */
+template
+ std::basic_istream<_CharT, _Traits>&
+ operator>>(std::basic_istream<_CharT, _Traits>& __is,
+const _Quoted_string&,
+ _CharT>& __str)
+ {
+ __str.__string.clear();
+
+ _CharT __c;
+ __is >> __c;
+ if (__c != __str.__delim)
+ {
+ __is.unget();
+ __is >> __str.__string;
+ return __is;
+ }
+ std::ios_base::fmtflags __flags
+ = __is.flags(__is.flags() & ~std::ios_base::skipws);
+ do
+ {
+ __is >> __c;
+ if (!__is.good())
+ break;
+ if (__c == __str.__escape)
+ {
+ __is >> __c;
+ if (!__is.good())
+ break;
+ }
+ else if (__c == __str.__delim2)
+ break;
+ __str.__string += __c;
+ }
+ while (true);
+ __is.setf(__flags);
+
+ return __is;
+ }
+
+ } // namespace __detail
+
+ /**
+ * @brief Manipulator for quoted strings.
+ * @param __strString to quote.
+ * @param __delim Character to quote string with.
+ * @param __escape Escape character to escape itself or quote character.
+ */
+ template
+__detail::_Quoted_string
+inline quoted(const _CharT* __str,
+ _CharT __delim = _CharT('"'), _CharT __escape = _CharT('\\'))
+{
+ return __detail::_Quoted_string(__str, __delim,
+__escape);
+}
+
+ template
+__detail::_Quoted_string<
+ const basic_string<_CharT, _Traits, _Alloc>&, _CharT>
+inline quoted(const basic_string<_CharT, _Traits, _Alloc>& __str,
+ _CharT __delim = _CharT('"'), _CharT __escape = _CharT('\\'))
+{
+ retu
Re: [RFC] Implement Undefined Behavior Sanitizer
On Wed, Jun 05, 2013 at 11:44:07AM -0700, Andrew Pinski wrote: > On Wed, Jun 5, 2013 at 10:57 AM, Marek Polacek wrote: > > Comments, please? > I think it might be better to do handle this while gimplification > happens rather than while parsing. The main reason is that constexpr > might fail due to the added function calls. Gimplification is too late, the FEs perform various operation shortenings etc. in many cases, and what exactly is undefined behavior is apparently heavily dependent on the particular language (C has different rules from C++). Yes, constexpr is something to consider in this light, but not something that can't be handled (recognizing ubsan builtins and just handling them specially). > Also please don't shorten file names like ubsan, we already have file > names which don't fit in the older POSIX tar format and needs extended > length support. We already have asan.c and tsan.c, and that is how it is commonly called. Jakub
Re: [RFC] Implement Undefined Behavior Sanitizer
On Wed, Jun 05, 2013 at 09:19:10PM +0200, Jakub Jelinek wrote: > On Wed, Jun 05, 2013 at 07:57:28PM +0200, Marek Polacek wrote: > > + tree t, tt; > > + tree orig = build2 (code, TREE_TYPE (op0), op0, op1); > > + tree prec = build_int_cst (TREE_TYPE (op0), > > +TYPE_PRECISION (TREE_TYPE (op0))); BTW, also, to check that the shift count is not < 0 or >= prec, you can just test that fold_convert_loc (loc, unsigned_type_for (TREE_TYPE (op1)), op1) is LE_EXPR than precm1 (also using the unsigned type). While optimizers often fold it to that, you might very well just create fewer trees from the start. The C99 undefined behavior of left signed shift can be tested by testing if ((unsigned type for op0's type) op0) >> (precm1 - y) is non-zero. Jakub
Re: [RFC] Implement Undefined Behavior Sanitizer
On Wed, Jun 5, 2013 at 12:23 PM, Jakub Jelinek wrote: > On Wed, Jun 05, 2013 at 11:44:07AM -0700, Andrew Pinski wrote: >> On Wed, Jun 5, 2013 at 10:57 AM, Marek Polacek wrote: >> > Comments, please? >> I think it might be better to do handle this while gimplification >> happens rather than while parsing. The main reason is that constexpr >> might fail due to the added function calls. > > Gimplification is too late, the FEs perform various operation shortenings > etc. in many cases, and what exactly is undefined behavior is apparently > heavily dependent on the particular language (C has different rules from > C++). Yes, constexpr is something to consider in this light, but not > something that can't be handled (recognizing ubsan builtins and just > handling them specially). > >> Also please don't shorten file names like ubsan, we already have file >> names which don't fit in the older POSIX tar format and needs extended >> length support. > > We already have asan.c and tsan.c, and that is how it is commonly called. Can we just move them to array-sanitizer and thread-sanitizer? I think those are better names than asan and tsan. Shorten names are not useful when a new person is learning the code. Thanks, Andrew > > Jakub
Re: [PATCH] pr57457
On 06/05/13 09:18, Iyer, Balaji V wrote:
-Original Message-
From: Jeff Law [mailto:l...@redhat.com]
Sent: Tuesday, June 04, 2013 11:49 PM
To: Iyer, Balaji V
Cc: gcc-patches@gcc.gnu.org; Steve Ellcey
Subject: Re: [PATCH] pr57457
On 06/04/13 12:58, Iyer, Balaji V wrote:
Actually, you can eliminate the entire if-statement (i.e. remove
if-statement and make the body unconditional). This is because, if
flag_enable_cilkplus is true and is_cilkplus_reduce_builtin (fundecl)
is true, then it would have returned vec_safe_length(values) and will
not even get to this point in the first place. So, this is technically
equivalent to if (1). So, can I remove that and check it in also? It
passes all my regression tests.
I originally thought it could be eliminated as well, but after further
reflection I
couldn't convince myself it'd do the right thing for the case when
flag_enable_cilkplus is true but is_cilkplus_reduce_builtin was false.
Note that triggering that code my be nontrivial, AFAICT we're suppressing a
diagnostic. So you're going to need to write invalid code to get into that
condition at the bottom of the loop at all.
Hi Jeff,
This email is going to be a bit long, so I apologize for it ahead of
time.
Here is the diff of c-typeck.c (to show that I have removed the
unwanted if statement)
Index: gcc/c/c-typeck.c
===
--- gcc/c/c-typeck.c(revision 199672)
+++ gcc/c/c-typeck.c(working copy)
@@ -2942,6 +2942,8 @@
break;
}
}
+ if (flag_enable_cilkplus && fundecl && is_cilkplus_reduce_builtin (fundecl))
+return vec_safe_length (values);
/* Scan the given expressions and types, producing individual
converted arguments. */
@@ -2959,17 +2961,6 @@
bool npc;
tree parmval;
- // FIXME: I assume this code is here to handle the overloaded
- // behavior of the __sec_reduce* builtins, and avoid giving
- // argument mismatch warnings/errors. We should probably handle
- // this with the resolve_overloaded_builtin infrastructure.
- /* If the function call is a builtin function call, then we do not
-worry about it since we break them up into its equivalent later and
-we do the appropriate checks there. */
- if (flag_enable_cilkplus
- && is_cilkplus_reduce_builtin (fundecl))
- continue;
-
if (type == void_type_node)
{
if (selector)
@@ -3207,16 +3198,10 @@
if (typetail != 0 && TREE_VALUE (typetail) != void_type_node)
{
- /* If array notation is used and Cilk Plus is enabled, then we do not
-worry about this error now. We will handle them in a later place. */
- if (!flag_enable_cilkplus
- || !is_cilkplus_reduce_builtin (fundecl))
- {
- error_at (input_location,
- "too few arguments to function %qE", function);
- inform_declaration (fundecl);
- return -1;
- }
+ error_at (input_location,
+ "too few arguments to function %qE", function);
+ inform_declaration (fundecl);
+ return -1;
}
return error_args ? -1 : (int) parmnum;
=
Here is the testcode that I have written that should trigger the "too few arguments
to function error" with the appropriate note to say where the function declaration
is.
--
/* { dg-do compile } */
/* { dg-options "-fcilkplus" } */
/* Test-case contains no array notation but is compiled with -fcilkplus.
It will still print the too few arguments func, thereby saying the
if-statement after the for-loop to check for !flag_enable_cilkplus ||
!is_cilkplus_reduce_function (fundecl) is not valid is always taken. */
int func (int, int); /* { dg-message "declared here" } */
int main (void)
{
int a = 5, b = 2;
return func (a); /* { dg-error "too few arguments to function" } */
}
Here is the output when I run this:
bviyer@lakshmi2a:/export/users/gcc-svn/b-trunk-gcc/gcc>
../../install_dir/trunk-install/bin/gcc -fcilkplus test.c
test.c: In function âmainâ:
test.c:14:3: error: too few arguments to function âfuncâ
return func (a); /* { dg-error "too few arguments to function" } */
^
test.c:9:5: note: declared here
int func (int, int); /* { dg-message "declared here" } */
^
The whole patch with testcode is attached, so is this Ok for trunk?
Here are the ChangeLog entries:
gcc/c/ChangeLog
2013-06-05 Balaji V. Iyer
* c-typeck.c (convert_arguments): Moved checking of builtin cilkplus
reduction functions outside the for-loop. Added a check if the fundecl
is non-NULL. Finally, removed an unwanted if-statement, and made the
body unconditional
gcc/testsuite/ChangeLog
2013-06-05 Balaji V. Iyer
PR C/57457
Re: [RFC] Implement Undefined Behavior Sanitizer
On Wed, 5 Jun 2013, Marek Polacek wrote:
> It works by creating a COMPOUND_EXPR around original expression, so e.g.
> it creates:
>
> if (b < 0 || (b > 31 || a < 0))
> {
> __builtin___ubsan_handle_shift_out_of_bounds ();
> }
> else
> {
> 0
> }, a << b;
>
> from original "a <<= b;".
For the "a < 0" here, and signed left shift of a positive value shifting a
1 into or past the sign bit, I think it should be possible to control the
checks separately from other checks on shifts - both because those cases
were implementation-defined in C90, only undefined in C99/C11, and because
they are widely used in practice.
> There is of course a lot of stuff that needs to be done, more
> specifically:
5) Testcases (or if applicable, running existing testcases coming with the
library).
6) Map -ftrapv onto an appropriate subset of this option that handles the
cases -ftrapv was meant to handle (so arithmetic overflow, which I'd say
should include INT_MIN / -1).
> 4) and of course, more instrumentation (C/C++ FE, gimple level)
> What comes to mind is:
> - float/double to integer conversions,
Under Annex F, these return an unspecified value rather than being
undefined behavior.
> - integer overflows (a long list of various cases here),
Strictly, including INT_MIN % -1 (both / and % are undefined if the result
of either is unrepresentable) - it appears you've already got that. Of
course INT_MIN % -1 and INT_MIN / -1 should *work* reliably with -fwrapv,
which is another bug (30484).
> - invalid conversions of int to bool,
What do you mean? Conversion to bool is just a comparison != 0.
> - VLAs size (e.g. negative size),
Or the multiplication used to compute the size in bytes overflows (really,
there should be some code generated expanding the stack bit by bit to
avoid it accidentally overflowing into another allocated area of memory, I
suppose).
> +@item -fsanitize=undefined
> +Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector
> +Various computations will be instrumented to detect
> +undefined behavior, e.g. division by zero or various overflows.
e.g.@:
--
Joseph S. Myers
jos...@codesourcery.com
Re: [RFC] Implement Undefined Behavior Sanitizer
On Wed, 5 Jun 2013, Jakub Jelinek wrote: > On Wed, Jun 05, 2013 at 11:44:07AM -0700, Andrew Pinski wrote: > > On Wed, Jun 5, 2013 at 10:57 AM, Marek Polacek wrote: > > > Comments, please? > > I think it might be better to do handle this while gimplification > > happens rather than while parsing. The main reason is that constexpr > > might fail due to the added function calls. > > Gimplification is too late, the FEs perform various operation shortenings > etc. in many cases, and what exactly is undefined behavior is apparently > heavily dependent on the particular language (C has different rules from > C++). Yes, constexpr is something to consider in this light, but not > something that can't be handled (recognizing ubsan builtins and just > handling them specially). Agreed, this needs handling before folding and other optimizations in the front ends to have predictable results. It may make sense to try running the whole testsuite with this option, minus tests of -fwrapv, to make sure it doesn't break any corner cases of valid tests (of course it may well show up some invalid tests). In particular, gcc.dg/*const-expr* and gcc.dg/overflow-warn*. Generating extra diagnostics for code in those tests that already gets a diagnostic is OK, as long as it doesn't generate diagnostics for non-overflow cases in those tests that aren't meant to be treated as overflow, or lose diagnostics for cases that are required to be diagnosed. -- Joseph S. Myers jos...@codesourcery.com
Re: [libstdc++-v3][C++14] Implement N3654 - Quoted Strings
On 5 June 2013 20:18, Ed Smith-Rowland wrote: > Greetings, > This patch implements quoted string manipulators for C++14. > > 27.7.6 - Quoted manipulators[quoted.manip]. > > The idea is to allow round trip insert and extract of strings with spaces. > > std::stringstream ss; > std::string original = "thing1 thing1"; > std::string round_trip; > ss << std::quoted(original); > ss >> std::quoted(round_trip); > assert( original == round_trip ); > > Builds and tests clean on x86-64-linux. As I suggested for your literals patch, couldn't the test for: #if __cplusplus > 201103L go inside the existing one? i.e. #if __cplusplus >= 201103L [...] #if __cplusplus > 201103L [...] #endif #endif _Quoted_string appears to do two copies of the string, one for the constructor argument and one for the member variable, do they definitely get elided? The members of _Quoted_string should be named _M_xxx not __xxx, to follow the coding style guidelines. What is __delim2 for? What if the first extraction in the operator>> fails, is doing __is.unget() the right thing to do? You could simplify the quoted() overloads by using auto return type deduction, is it an intentional choice not to use that?
Re: [PATCH, rs6000] power8 patches, patch #4 (revised), new power8 builtins
I also wonder whether it would be useful to have 32-bit do the vector logical ops in gprs as well. At the moment, the patches don't allow it (vector types must be done in the altivec/vsx registers, an TImode is done by splitting the operation into 4 separate categories). On the 64-bit side, having __int128_t passed in GPRs, means you want to avoid ping-ponging between the GPRs and VSX registers. In addition, the atomic quad word support (patch #7) has to run in GPRs, so we need add/subtract/logical to have versions that run in GPRs. It might work better if you added a mode V1TI for TI in vector regs, and then used plain TI only for GPRs. It certainly will make things a lot more regular; whether it actually works better, I have no idea. The way you have things now, only after reload the vector patterns are split to GPR patterns; much too late to do most optimisations on it. On the other hand, deciding early what register set some op should go to isn't too pleasant either; is it always the best choice to use the vector regs when possible? Segher
Re: [PATCH, rs6000] power8 patches, patch #4 (revised), new power8 builtins
On Wed, Jun 05, 2013 at 10:06:08PM +0200, Segher Boessenkool wrote:
> >I also wonder whether it would be useful to have 32-bit do the
> >vector logical
> >ops in gprs as well. At the moment, the patches don't allow it
> >(vector types
> >must be done in the altivec/vsx registers, an TImode is done by
> >splitting the
> >operation into 4 separate categories). On the 64-bit side, having
> >__int128_t
> >passed in GPRs, means you want to avoid ping-ponging between the
> >GPRs and VSX
> >registers. In addition, the atomic quad word support (patch #7)
> >has to run in
> >GPRs, so we need add/subtract/logical to have versions that run in
> >GPRs.
>
> It might work better if you added a mode V1TI for TI in vector
> regs, and then used plain TI only for GPRs. It certainly will
> make things a lot more regular; whether it actually works better,
> I have no idea.
>
> The way you have things now, only after reload the vector patterns
> are split to GPR patterns; much too late to do most optimisations
> on it. On the other hand, deciding early what register set some
> op should go to isn't too pleasant either; is it always the best
> choice to use the vector regs when possible?
It depends. For example consider:
#ifndef TYPE
#define TYPE __int128_t
#endif
TYPE a_and (TYPE p, TYPE q) { return p & q; }
void p_and (TYPE *p, TYPE *q, TYPE *r) { *p = *q & *r; }
In a_and, p and q are passed in GPRs, so you want to use the GPR based
instructions. In p_and, it is simpler to do the instruction in the VSX
registers.
This is what my code from patch 4 generates:
.L.a_and:
and 3,3,5
and 4,4,6
blr
.L.p_and:
lxvd2x 12,0,4
lxvd2x 0,0,5
xxland 0,12,0
stxvd2x 0,0,3
blr
Unfortunately when I added the TImode in VSX registers, I didn't notice this,
and the current code generates:
.L.a_and:
addi 9,1,-16
std 3,0(9)
std 4,8(9)
ori 2,2,0
lxvd2x 12,0,9
std 5,0(9)
std 6,8(9)
ori 2,2,0
lxvd2x 0,0,9
xxland 0,12,0
stxvd2x 0,0,9
ori 2,2,0
ld 3,0(9)
ld 4,8(9)
blr
.L.p_and:
lxvd2x 12,0,4
lxvd2x 0,0,5
xxland 0,12,0
stxvd2x 0,0,3
blr
Previous versions (and -mno-vsx-timode) generate:
.L.a_and:
and 3,3,5
and 4,4,6
blr
.L.p_and:
ld 10,0(4)
ld 9,0(5)
and 9,10,9
std 9,0(3)
ld 10,8(4)
ld 9,8(5)
and 9,10,9
std 9,8(3)
blr
Note, that the scheduler does not interleave the loads and the and's, instead
it does ld/ld/and/std.
This bouncing back and forth will get somewhat worse when the support for doing
128int_t add/subtract in the vector registers is added. We don't want to hard
wire doing all of TImode in vector registers, because this breaks the 8-byte
atomic fetch_and_add functions (without having to use an UNSPEC to hide the
add).
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Re: [PATCH] ARM: Don't clobber CC reg when it is live after the peephole window
Ping.
On 05/29/2013 12:15 PM, Meador Inge wrote:
> Hi All,
>
> This patch fixes a bug in one of the ARM peephole2 optimizations. The
> peephole2 optimization in question was changed to use the CC-updating
> form for all of the instructions produced by the peephole so that the
> encoding will be smaller when compiling for thumb [1]. However, I don't
> think that is always safe.
>
> For example, the CC register might be used by something *after* the
> peephole window. The current peephole will transform:
>
>
> (insn:TI 7 49 18 2 (set (reg:CC 24 cc)
> (compare:CC (reg:SI 3 r3 [orig:136 *endname_1(D) ] [136])
> (const_int 0 [0]))) repro.c:5 212 {*arm_cmpsi_insn}
> (nil))
>
> (insn:TI 18 7 11 2 (cond_exec (ne (reg:CC 24 cc)
> (const_int 0 [0]))
> (set (reg:SI 3 r3 [140])
> (const_int 0 [0]))) repro.c:8 3366 {*p *arm_movsi_vfp}
> (expr_list:REG_EQUIV (const_int 0 [0])
> (nil)))
>
> (insn 11 18 19 2 (cond_exec (eq (reg:CC 24 cc)
> (const_int 0 [0]))
> (set (reg:SI 3 r3 [138])
> (const_int 1 [0x1]))) repro.c:6 3366 {*p *arm_movsi_vfp}
> (expr_list:REG_EQUIV (const_int 1 [0x1])
> (nil)))
>
> (insn:TI 19 11 12 2 (cond_exec (ne (reg:CC 24 cc)
> (const_int 0 [0]))
> (set (mem/c:SI (reg/f:SI 2 r2 [143]) [2 atend+0 S4 A32])
> (reg:SI 3 r3 [140]))) repro.c:8 3366 {*p *arm_movsi_vfp}
> (expr_list:REG_DEAD (reg/f:SI 2 r2 [143])
> (nil)))
>
> (insn:TI 12 19 22 2 (cond_exec (eq (reg:CC 24 cc)
> (const_int 0 [0]))
> (set (mem/c:SI (reg/f:SI 2 r2 [143]) [2 atend+0 S4 A32])
> (reg:SI 3 r3 [138]))) repro.c:6 3366 {*p *arm_movsi_vfp}
> (nil))
>
> (insn:TI 22 12 58 2 (cond_exec (ne (reg:CC 24 cc)
> (const_int 0 [0]))
> (set (mem:QI (reg/v/f:SI 0 r0 [orig:135 endname ] [135]) [0
> *endname_1(D)+0 S1 A8])
> (reg:QI 3 r3 [140]))) repro.c:9 3115 {*p *arm_movqi_insn}
> (expr_list:REG_DEAD (reg:CC 24 cc)
> (expr_list:REG_DEAD (reg:QI 3 r3 [140])
> (expr_list:REG_DEAD (reg/v/f:SI 0 r0 [orig:135 endname ]
> [135])
> (nil)
>
> into the following:
>
>
> (insn 59 49 60 2 (parallel [
> (set (reg:CC 24 cc)
> (compare:CC (reg:SI 3 r3 [orig:136 *endname_1(D) ] [136])
> (const_int 0 [0])))
> (set (reg:SI 1 r1)
> (minus:SI (reg:SI 3 r3 [orig:136 *endname_1(D) ] [136])
> (const_int 0 [0])))
> ]) repro.c:6 -1
> (nil))
>
> (insn 60 59 61 2 (parallel [
> (set (reg:CC 24 cc)
> (compare:CC (const_int 0 [0])
> (reg:SI 1 r1)))
> (set (reg:SI 3 r3 [140])
> (minus:SI (const_int 0 [0])
> (reg:SI 1 r1)))
> ]) repro.c:6 -1
> (nil))
>
> (insn 61 60 19 2 (parallel [
> (set (reg:SI 3 r3 [140])
> (plus:SI (plus:SI (reg:SI 3 r3 [140])
> (reg:SI 1 r1))
> (geu:SI (reg:CC 24 cc)
> (const_int 0 [0]
> (clobber (reg:CC 24 cc))
> ]) repro.c:6 -1
> (nil))
>
> (insn:TI 19 61 12 2 (cond_exec (ne (reg:CC 24 cc)
> (const_int 0 [0]))
> (set (mem/c:SI (reg/f:SI 2 r2 [143]) [2 atend+0 S4 A32])
> (reg:SI 3 r3 [140]))) repro.c:8 3366 {*p *arm_movsi_vfp}
> (nil))
>
> (insn:TI 12 19 22 2 (cond_exec (eq (reg:CC 24 cc)
> (const_int 0 [0]))
> (set (mem/c:SI (reg/f:SI 2 r2 [143]) [2 atend+0 S4 A32])
> (reg:SI 3 r3 [138]))) repro.c:6 3366 {*p *arm_movsi_vfp}
> (expr_list:REG_DEAD (reg/f:SI 2 r2 [143])
> (nil)))
>
> (insn:TI 22 12 58 2 (cond_exec (ne (reg:CC 24 cc)
> (const_int 0 [0]))
> (set (mem:QI (reg/v/f:SI 0 r0 [orig:135 endname ] [135]) [0
> *endname_1(D)+0 S1 A8])
> (reg:QI 3 r3 [140]))) repro.c:9 3115 {*p *arm_movqi_insn}
> (expr_list:REG_DEAD (reg:CC 24 cc)
> (expr_list:REG_DEAD (reg:QI 3 r3 [140])
> (expr_list:REG_DEAD (reg/v/f:SI 0 r0 [orig:135 endname ]
> [135])
> (nil)
>
>
> This gets compiled into the incorrect sequence:
>
>
> ldrbr3, [r0, #0]
> ldr r2, .L4
> subsr1, r3, #0
> rsbsr3, r1, #0
> adcsr3, r3, r1
> strne r3, [r2, #0]
> streq r3, [r2, #0]
> strneb r3, [r0, #0]
>
>
> The conditional stores are now dealing with an incorrect condition state.
>
> This patch fixes the problem by ens
[google/gcc-4_7]Add new validator file for native ppc toolchain
Add new validator manifest xfail file for native powerpc64 toolchain. Ok for google/gcc-4_7? Tested: ./validate_failures.py --manifest=powerpc64-grtev3-linux-gnu-native.xfail -- results="gcc/gcc.sum g++/g++.sum gfortran/gfortran.sum" 2013-06-05 * powerpc64-grtev3-linux-gnu-native.xfail: New. patch.diff Description: Binary data
Re: [google/gcc-4_7]Add new validator file for native ppc toolchain
OK for google/gcc-4_7. On Wed, Jun 5, 2013 at 2:45 PM, Jing Yu wrote: > Add new validator manifest xfail file for native powerpc64 toolchain. > Ok for google/gcc-4_7? > > Tested: > ./validate_failures.py > --manifest=powerpc64-grtev3-linux-gnu-native.xfail -- > results="gcc/gcc.sum g++/g++.sum gfortran/gfortran.sum" > > 2013-06-05 > > * powerpc64-grtev3-linux-gnu-native.xfail: New.
Re: better gdb support for debugging gcc
On Jun 5, 2013, at 10:17 AM, Tom Tromey wrote: > Arguably this should be done in gdb. __FUNCTION__ is a private detail of gcc and a user of another compiler is free to define it in a way differently than gcc, and gdb shouldn't impinge that use... > Could you file a bug for that? I'd rather someone else do that, if they feel that is a good thing to do… I'm less sure about it. Let's copy the gdb list, so they can at least have visibility into it, and contemplate it. In gcc, we use the below definitions to hide some internal details of gcc and some internal details of a language standard that might be used in #defines that we might want to use at the gdb command prompt (with -g3), so those macros just-work. So, the open question is, would is be better for gcc to ensure this into the macro table in the debug output of a translation unit, or drop it in to gdb with the .gdbinit file, or would it be better for gdb to _fix_ it? # Define some macros helpful to gdb when it is expanding macros. macro define __FILE__ "gdb" macro define __LINE__ 1 macro define __FUNCTION__ "gdb" macro define __null 0
[PATCH arm/embedded-4_7-branch]fix fialure of mtune option
Hi,
This patch fixes failure of command "arm-none-eabi-gcc -O2 -mthumb
-mtune=cortex-m4 ..." on arm/embedded-4_7-branch by removing the assertion
in arm_cortex_v7m_branch_cost.
Is it OK?
Thanks.
2013-06-06 Bin Cheng
* config/arm/arm.c (arm_cortex_v7m_branch_cost): Remove assertion
on TARGET_32BIT and TARGET_THUMB2.Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 199680)
+++ gcc/config/arm/arm.c(working copy)
@@ -8760,8 +8760,6 @@ arm_cortex_a5_branch_cost (bool speed_p, bool pred
static int
arm_cortex_v7m_branch_cost (bool speed_p, bool predictable_p ATTRIBUTE_UNUSED)
{
- gcc_assert (TARGET_32BIT && TARGET_THUMB2);
-
return 1;
}
Re: [PATCH arm/embedded-4_7-branch]fix fialure of mtune option
OK to embedded-4_7-branch. Thanks, Joey On Thu, Jun 6, 2013 at 9:43 AM, Bin Cheng wrote: > Hi, > This patch fixes failure of command "arm-none-eabi-gcc -O2 -mthumb > -mtune=cortex-m4 ..." on arm/embedded-4_7-branch by removing the assertion > in arm_cortex_v7m_branch_cost. > > Is it OK? > > Thanks. > > 2013-06-06 Bin Cheng > > * config/arm/arm.c (arm_cortex_v7m_branch_cost): Remove assertion > on TARGET_32BIT and TARGET_THUMB2.
[PING] Re: [PATCH 0/5] Submission of Altera Nios II port
Pinging the nios2 port. On 13/5/15 1:04 AM, Chung-Lin Tang wrote: > On 2013/4/26 04:35 AM, Joseph S. Myers wrote: >> I should ask the following general standard new-port questions: >> >> * Does the port build cleanly when configured with --enable-werror-always >> and built using a native compiler from current GCC trunk - for both 32-bit >> host, and 64-bit host? It should. This is the standard way of ensuring >> the same level of warning-cleanness in a cross build as native bootstrap >> automatically enforces (and the build compiler needs to be from current >> trunk because warning-cleanness is only expected when the build compiler >> is the same version as the compiler being built). >> >> The new targets should be added to contrib/config-list.mk, which helps >> test all targets with --enable-werror-always. This is mentioned in "Back >> End" in sourcebuild.texi - check there for any other pieces that should be >> included in the port submission. > > Currently, nios2 seems to be another affected target by PR 55035, when > building with a recent trunk with --enable-werror-always: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55035 > > I would like to ask this --enable-werror-always requirement be relaxed > for the nios2 port submission, as it is not alone in the above PR, and > we are early in the release cycle; there should be plenty of time to fix > any problems afterwards. > > Though not included in the submitted patches, I will add the target > entries in contrib/config-list.mk when committing. > >> * What are test results like for the port? Again, both 32-bit and 64-bit >> hosts, to detect any dependencies on whether the host is 32-bit or 64-bit. > > Tests of i686 and x86_64 Linux hosts show same test results. FAILs that > still exist include g++.dg/debug/dwarf2/non-virtual-thunk.C, due to the > lack of target specific MI-thunk hooks right now, and a few tree-ssa > optimization FAILs, that might be worked around by augmenting the > testcase. The port in whole should be fairly stable. > > Thanks, > Chung-Lin > >
Re: [RFC] Implement Undefined Behavior Sanitizer
On Wed, Jun 05, 2013 at 09:35:08PM +0200, Jakub Jelinek wrote: > On Wed, Jun 05, 2013 at 09:19:10PM +0200, Jakub Jelinek wrote: > > On Wed, Jun 05, 2013 at 07:57:28PM +0200, Marek Polacek wrote: > > > + tree t, tt; > > > + tree orig = build2 (code, TREE_TYPE (op0), op0, op1); > > > + tree prec = build_int_cst (TREE_TYPE (op0), > > > + TYPE_PRECISION (TREE_TYPE (op0))); > > BTW, also, to check that the shift count is not < 0 or >= prec, you can > just test that fold_convert_loc (loc, unsigned_type_for (TREE_TYPE (op1)), > op1) > is LE_EXPR than precm1 (also using the unsigned type). > While optimizers often fold it to that, you might very well just create > fewer trees from the start. > > The C99 undefined behavior of left signed shift can be tested by > testing if ((unsigned type for op0's type) op0) >> (precm1 - y) is > non-zero. The C++11/C++14 undefined behavior of left signed shift can be tested similarly, if ((unsigned type for op0's type) op0) >> (precm1 - y) is greater than one, then it is undefined behavior. Jason, does http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3675.html#1457 apply just to C++11/C++14, or to C++03 too? In C++03 I see in [expr.shift]/2 "The value of E1 << E2 is E1 (interpreted as a bit pattern) left-shifted E2 bit positions; vacated bits are zero-filled. If E1 has an unsigned type, the value of the result is E1 multiplied by the quantity 2 raised to the power E2, reduced modulo ULONG_MAX+1 if E1 has type unsigned long, UINT_MAX+1 otherwise." Is that the same case as C90 then, the wording seems to be pretty much the same? As for controlling the C99 (or even C++11?) warning individually, either it can be a separate suboption of -fsanitize=, like -fsanitize=shift,lshiftc99 (but then, would lshiftc99 be included in undefined and similar option groups), or IMHO better we just convince ubsan upstream to have env var for controlling the lshift diagnostics, gcc emits always checks for precisely what the current -std= makes as undefined behavior (though, because of DRs that is somewhat fuzzy, pre-DR1457 C++11 vs. post-DR1457 C++11), and users would through env var just choose, ok, please ignore left shift warnings of the 1 << 31 style, or ignore those and also 2 << 31 style. Jakub
