Re: Request to merge Undefined Behavior Sanitizer in
On Thu, 25 Jul 2013, Joseph S. Myers wrote: On Thu, 25 Jul 2013, Marek Polacek wrote: So far it sanitizes division-by-zeros, shifts and __builtin_unreachable calls. This is of course far from being complete; I intend to write more features during this 4.9 stage. Such as everything needed for it to replace -ftrapv (for -ftrapv to become an alias for an appropriate subset of this option)? What happens if you bootstrap with this enabled - do whatever failures appear look like genuine bugs? Running the testsuite with a compiler built with this option? Running the testsuite with this option used when compiling all these tests. I guess that initially a bootstrap with this option may fail because of existing bugs, and so the other tests mentioned can't yet be run - but using this option on GCC itself, and making sure that as far as possible it doesn't break compiling things or change diagnostics generated at compile time, seem like good goals. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57324 (that is using llvm's sanitizer) and for a first patch (unreviewed): http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01466.html (started at http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01402.html ) -- Marc Glisse
Re: [PATCH] Fix illegal cast to rtx (*insn_gen_fn) (rtx, ...)
Hello!
The (static arg) generator functions are casted to a var arg
function pointer, making the assumption that the ABI for passing
the arguments will be the same as for static arguments.
This isn't a valid assumption on all architectures, var args might for
example be passed on the stack, even if there would be function argument
registers still available.
There exists a bugreport for the problem here:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12081
This patch is taken from the suggestion by Rask Ingemann Lambertsen
and updated to the current svn tip of trunk.
Stefan, can you resubmit an updated patch (with proposed update from [1])?
I would really like to see this patch in the mainline.
BTW: I am not c++ expert, but doesn't c++ offer some sort of
abstraction to get rid of
+ union {
+rtx (*argc0) (void);
+rtx (*argc1) (rtx);
+rtx (*argc2) (rtx, rtx);
+rtx (*argc3) (rtx, rtx, rtx);
+rtx (*argc4) (rtx, rtx, rtx, rtx);
+rtx (*argc5) (rtx, rtx, rtx, rtx, rtx);
+rtx (*argc6) (rtx, rtx, rtx, rtx, rtx, rtx);
+rtx (*argc7) (rtx, rtx, rtx, rtx, rtx, rtx, rtx);
+rtx (*argc8) (rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx);
+rtx (*argc9) (rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx);
+rtx (*argc10) (rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx);
+rtx (*argc11) (rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx, rtx);
+ } genfun;
[1] http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00448.html
Thanks,
Uros.
[PATCH], PING: Fix illegal cast to rtx (*insn_gen_fn) (rtx, ...)
On Fri, Jul 26, 2013 at 10:08 AM, Stefan Kristiansson stefan.kristians...@saunalahti.fi wrote: On Fri, Jul 26, 2013 at 08:51:41AM +0200, Uros Bizjak wrote: Stefan, can you resubmit an updated patch (with proposed update from [1])? I would really like to see this patch in the mainline. Attached is the updated patch. Assuming that the patch is tested according to GCC standards, can please a global reviewer comment and eventually approve the patch? Thanks, Uros.
Re: [PATCH, AArch64] Support NEG in vector registers for DI and SI mode
On 23 July 2013 13:35, Ian Bolton ian.bol...@arm.com wrote: 2013-07-23 Ian Bolton ian.bol...@arm.com gcc/ * config/aarch64/aarch64-simd.md (negmode2): Offer alternative that uses vector r Cheers, Ian OK /Marcus
[C++ testcase, committed] PR 57101
Hi,
I'm adding the testcase and keeping the PR open (the issue seems still
present in 4_8-branch).
Thanks,
Paolo.
//
2013-07-26 Paolo Carlini paolo.carl...@oracle.com
PR c++/57101
* g++.dg/cpp0x/pr57101.C: New.
Index: g++.dg/cpp0x/pr57101.C
===
--- g++.dg/cpp0x/pr57101.C (revision 0)
+++ g++.dg/cpp0x/pr57101.C (working copy)
@@ -0,0 +1,220 @@
+// { dg-options -std=c++11 -fcompare-debug }
+
+typedef long unsigned size_t;
+namespace
+{
+ template typename _Tp, _Tp __v struct integral_constant
+ {
+static const _Tp value = __v;
+ };
+ typedef integral_constant bool, false false_type;
+ template typename struct remove_cv;
+ template typename struct __is_void_helper:false_type
+ {
+ };
+ template
+
+typename
+_Tp
+
+struct
+is_void:integral_constant
+ bool, (__is_void_helper typename remove_cv _Tp ::type ::value)
+ {
+ };
+ template typename struct is_function:false_type
+ {
+ };
+ template typename _Tp struct remove_const
+ {
+typedef _Tp type;
+ };
+ template typename _Tp struct remove_volatile
+ {
+typedef _Tp type;
+ };
+ template typename _Tp struct remove_cv
+ {
+typedef
+ typename
+ remove_const typename remove_volatile _Tp ::type ::type type;
+ };
+ template typename struct is_lvalue_reference:false_type
+ {
+ };
+ template typename _Tp, bool = is_void _Tp ::value struct
__add_rvalue_reference_helper
+ {
+typedef _Tp type;
+ };
+ template
+
+typename
+_Tp struct add_rvalue_reference:__add_rvalue_reference_helper _Tp
+ {
+ };
+ template
+ typename _Tp typename add_rvalue_reference _Tp ::type declval ();
+ template
+
+typename,
+typename
+_To, bool = (is_function _To ::value) struct __is_convertible_helper;
+ template
+
+typename
+_From, typename _To struct __is_convertible_helper _From, _To, false
+ {
+static const bool __value = sizeof ((declval _From ()));
+ };
+ template
+
+typename
+_From,
+typename
+_To
+
+struct
+is_convertible:integral_constant
+ bool, __is_convertible_helper _From, _To ::__value
+ {
+ };
+ template bool, typename _Tp = void struct enable_if
+ {
+typedef _Tp type;
+ };
+ template typename _Tp struct identity
+ {
+typedef _Tp type;
+ };
+ template
+
+typename
+_Tp
+
+typename
+enable_if
+
+is_lvalue_reference
+ _Tp ::value, _Tp ::type forward (typename identity _Tp ::type)
+ {
+return 0;
+
+ }
+ template class _T1, class struct pair
+ {
+_T1 first;
+template class _U1, class = typename enable_if is_convertible _U1,
_T1 ::value ::type pair (_U1 __x):
+first
+ (forward _U1 (__x))
+{
+}
+ };
+}
+
+namespace __gnu_cxx
+{
+ template typename class new_allocator
+ {
+ };
+}
+
+namespace std
+{
+ template typename _Tp class allocator:__gnu_cxx::new_allocator _Tp
+ {
+ public:
+template typename struct rebind
+{
+ typedef allocator other;
+};
+ };
+ template typename, typename struct unary_function;
+ template typename, typename, typename struct binary_function
+ {
+ };
+ template typename _Tp struct less:binary_function _Tp, _Tp, bool
+ {
+ };
+ template
+
+typename
+_Pair
+ struct _Select1st:unary_function _Pair, typename _Pair::first_type
+ {
+ };
+ template typename struct _Rb_tree_node;
+ template
+
+typename,
+typename
+_Val,
+typename,
+typename _Compare, typename _Alloc = allocator _Val class _Rb_tree
+ {
+typedef
+ typename
+ _Alloc::template
+ rebind _Rb_tree_node _Val ::other _Node_allocator;
+ public:
+typedef _Alloc allocator_type;
+template typename _Key_compare struct _Rb_tree_impl
+{
+ _Rb_tree_impl (_Key_compare, _Node_allocator);
+};
+_Rb_tree_impl _Compare _M_impl;
+ _Rb_tree (_Compare __comp, allocator_type __a):
+_M_impl (__comp, __a)
+{
+}
+ };
+ template class _E class initializer_list
+ {
+typedef size_t size_type;
+typedef _E *iterator;
+iterator _M_array;
+size_type _M_len;
+ };
+ template
+
+typename
+_Key,
+typename
+_Tp,
+typename
+_Compare
+=
+less
+
+_Key , typename _Alloc = allocator pair _Key, _Tp class multimap
+ {
+typedef _Key key_type;
+typedef pair _Key, _Tp value_type;
+typedef _Compare key_compare;
+typedef _Alloc allocator_type;
+typedef
+ _Rb_tree
+
+ key_type,
+ value_type, _Select1st value_type , key_compare _Rep_type;
+_Rep_type _M_t;
+ public:
+ multimap (initializer_list value_type , _Compare __comp = _Compare (),
allocator_type __a = allocator_type ()):
+_M_t
+ (__comp, __a)
+{
+}
+ };
+}
+
+using namespace
[PATCH, AArch64] Skip gcc.dg/lower-subreg-1.c
Hi,
This patch changes to skip gcc.dg/lower-subreg-1.c for aarch64*-*-*.
The word mode in aarch64 is 64-bit so the lower-subreg pass won't happen
in this test case. The test is currently skipped on aarch64 with lp64
due to the directive of dg-require-effective-target ilp32, but fails
when -mabi=ilp32 is in use.
OK to commit?
Thanks,
Yufeng
gcc/testsuite/
* gcc.dg/lower-subreg-1.c: Skip aarch64*-*-*.diff --git a/gcc/testsuite/gcc.dg/lower-subreg-1.c b/gcc/testsuite/gcc.dg/lower-subreg-1.c
index f5827e1..102ba22 100644
--- a/gcc/testsuite/gcc.dg/lower-subreg-1.c
+++ b/gcc/testsuite/gcc.dg/lower-subreg-1.c
@@ -1,4 +1,4 @@
-/* { dg-do compile { target { ! { mips64 || { arm*-*-* ia64-*-* sparc*-*-* spu-*-* tilegx-*-* } } } } } */
+/* { dg-do compile { target { ! { mips64 || { aarch64*-*-* arm*-*-* ia64-*-* sparc*-*-* spu-*-* tilegx-*-* } } } } } */
/* { dg-options -O -fdump-rtl-subreg1 } */
/* { dg-skip-if { { i?86-*-* x86_64-*-* } x32 } { * } { } } */
/* { dg-require-effective-target ilp32 } */
Re: [c++-concepts] requires expressions
Fixed and committed, but I have a small follow-up related to parameter packs in requires clauses. The checking for unexpanded parameter packs treats the parameter declarations like regular PARM_DECL references and gives errors that they are unexpanded packs. 2013-07-26 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/tree.c (cp_walk_subtrees): Don't recurse through the requires expr parameter list. Andrew On Thu, Jul 25, 2013 at 3:49 PM, Jason Merrill ja...@redhat.com wrote: On 07/25/2013 10:19 AM, Andrew Sutton wrote: + pp_cxx_parameter_declaration_clause(pp, TREE_OPERAND (t, 0)); Space before (. Otherwise, looks good. Jason -- Andrew Sutton andrew.n.sut...@gmail.com requires-8.patch Description: Binary data
Re: Request to merge Undefined Behavior Sanitizer in
On Thu, Jul 25, 2013 at 10:33:46PM -0700, Andrew Pinski wrote: What does it mean by unsigned-integer-overflow? Unsigned integers never overflow. Or maybe I misread the documentation here. Well, clang can sanitize even when unsigned int wraps. But this feature seems doubtful, I don't think I ever implement it for GCC. Marek
[c++-concepts] __is_same_as
This patch implements a new trait __is_same_as. This is foundational for future work on concepts in that it provides a mechanism for reasoning about type equivalences. It also provides the correct preconditions for __is_convertible_to as required in meta.rel. 2013-07-26 Andrew Sutton andrew.n.sut...@gmail.com * gcc/cp/semantics.c (trait_expr_value): Evaluate __is_same_as. (finish_trait_expr): Check __is_same_as and __is_convertible_to. * gcc/cp/constraint.cc (diagnose_trait): Diagnose failures in __is_same_as. * gcc/cp/parser.c (cp_parser_primary_expression), (cp_parser_trait_expr): Parse __is_same_as. * gcc/cp/cp-tree.h (cp_trait_kind): Add CPTK_IS_SAME_AS. * gcc/cp/cxx-pretty-print.c (pp_cxx_trait_expression): Pretty print __is_same_as trait. Andrew is-same-as.patch Description: Binary data
Re: [c++-concepts] __is_same_as
Hi, On 07/26/2013 02:11 PM, Andrew Sutton wrote: This patch implements a new trait __is_same_as. This is foundational for future work on concepts in that it provides a mechanism for reasoning about type equivalences. Isn't the name a little misleading? I immediately wondered what was wrong with std::is_same. IMHO something a little longer/technical clarifying that the trait isn't just about comparing types is in order... Paolo.
Re: [testsuite, android] Disabling thread_local4.C and thread_local4g.C for Android.
Maxim, thank you for your input! That's for sure a better solution. __BIONIC__ is not defined in features.h so I had to change the include to ctype.h. (__BIONIC__ is defined in sys/ctypes.h, but it's not safe to include that directly..) tested on x86_64_unknow_linux and on android device. Is it OK? thanks, Alexander 2013/7/14 Maxim Kuvyrkov ma...@kugelworks.com: On 13/07/2013, at 10:34 AM, Mike Stump wrote: On Jun 20, 2013, at 4:30 AM, Alexander Ivchenko aivch...@gmail.com wrote: for Android: +2013-06-19 Alexander Ivchenko alexander.ivche...@intel.com + + * g++.dg/tls/thread_local4.C: Disable test for Android. + * g++.dg/tls/thread_local4g.C: Ditto. is it ok for trunk? Ok. Alexander, Your current patch as approved by Mike is OK, but it is more prudent to condition the tests on using Bionic libc, not the fact that target triplet has *-android* in it. [E.g., it is possible to build a toolchain for, say, arm-linux-gnueabi which will use glibc for primary multilib, and bionic for secondary multilib.] I didn't test the attached patch, so please confirm that it behaves as expected before applying it. Thank you, -- Maxim Kuvyrkov KugelWorks nonbionic_target.patch Description: Binary data
Re: [c++-concepts] __is_same_as
Isn't the name a little misleading? I immediately wondered what was wrong with std::is_same. IMHO something a little longer/technical clarifying that the trait isn't just about comparing types is in order... Sure. First, it means we don't have to instantiate any class templates in order to decide something as fundamental as type equivalence. Internalizing the computation should, hypothetically, reduce memory usage and improve compile times. I haven't tried to write a serious performance comparison, but that particular benefit should be self-evident. Although, as an extension, IMHO, none of the standard type traits should have library implementations. Many do not. I no longer see any concrete benefits to writing library implementations of things that are already known by the compiler. Second, the intrinsic also provides a canonical name or type equivalence for constraints. In the purpose of concept checking this means I have a single definition of the relation (or predicate) to reason about. Having multiple and different library implementations of the same fundamental properties (e.g., boost::is_same) makes reasoning about those properties practically impossible. For example, in Concepts Lite __is_same_as has a number of built-in implications. In particular, __is_same_as subsumes __is_convertible_to and __is_derived_from, which affects the partial ordering of overloads and partial template specializations (patch forthcoming). Essentially, that makes this function: templatetypename T, typename U requires __is_same_as(T, U) void f(T, U); more constrained than this function: templatetypename T, typename U requires __is_convertible_to(T, U) void f(T, U); IIRC, the algorithms header relies on similar properties for the optimization of copy or swap. I forget which, specifically. Without providing an intrinsic, I would have bless std::is_same with special language semantics, which will probably make users wonder why their trivial implementations of a trivial type trait don't work the same way. That is to say that boost::is_same would not subsume boost::is_convertible because that definition hasn't been blessed with additional semantics. Concepts lite also uses that canonical name and node to provide meaningful diagnostics e.g., T is not the same type as U. Taking a longer-term view of the problem, internalizing type equivalence is necessary for separate checking in concepts. In particular, I rely on these nodes to build a congruence closure over the template arguments given in template constraints. This effectively serves the same purpose as the SameType concept from C++0x and its application as described in n2914 (14.11.1 p3). I don't think that this would be made easier by relying on library implementations as a specification of type equivalence. Andrew
Re: [c++-concepts] __is_same_as
Hi, On 07/26/2013 03:23 PM, Andrew Sutton wrote: Isn't the name a little misleading? I immediately wondered what was wrong with std::is_same. IMHO something a little longer/technical clarifying that the trait isn't just about comparing types is in order... Sure. First, it means we don't have to instantiate any class templates in order to decide something as fundamental as type equivalence. Internalizing the computation should, hypothetically, reduce memory usage and improve compile times. I haven't tried to write a serious performance comparison, but that particular benefit should be self-evident. Although, as an extension, IMHO, none of the standard type traits should have library implementations. Many do not. I no longer see any concrete benefits to writing library implementations of things that are already known by the compiler. This makes a lot of sense to me, I simply didn't know we were moving in this direction. Second, the intrinsic also provides a canonical name or type equivalence for constraints. In the purpose of concept checking this means I have a single definition of the relation (or predicate) to reason about. Having multiple and different library implementations of the same fundamental properties (e.g., boost::is_same) makes reasoning about those properties practically impossible. For example, in Concepts Lite __is_same_as has a number of built-in implications. In particular, __is_same_as subsumes __is_convertible_to and __is_derived_from, which affects the partial ordering of overloads and partial template specializations (patch forthcoming). Essentially, that makes this function: templatetypename T, typename U requires __is_same_as(T, U) void f(T, U); more constrained than this function: templatetypename T, typename U requires __is_convertible_to(T, U) void f(T, U); IIRC, the algorithms header relies on similar properties for the optimization of copy or swap. I forget which, specifically. Without providing an intrinsic, I would have bless std::is_same with special language semantics, which will probably make users wonder why their trivial implementations of a trivial type trait don't work the same way. That is to say that boost::is_same would not subsume boost::is_convertible because that definition hasn't been blessed with additional semantics. Concepts lite also uses that canonical name and node to provide meaningful diagnostics e.g., T is not the same type as U. Taking a longer-term view of the problem, internalizing type equivalence is necessary for separate checking in concepts. In particular, I rely on these nodes to build a congruence closure over the template arguments given in template constraints. This effectively serves the same purpose as the SameType concept from C++0x and its application as described in n2914 (14.11.1 p3). I don't think that this would be made easier by relying on library implementations as a specification of type equivalence. Thanks a lot. Now I'm afraid that some of these nice clarifications, delicate technical details included, may get lost. Do you think they exist already in some of your design documents, papers, etc. Then a reference in the code would do. Otherwise, please consider adding some of the above to the branch. Thanks again, Paolo.
Re: [PATCH 00/18] resurrect automatic dependency tracking
Joseph == Joseph S Myers jos...@codesourcery.com writes: Joseph We have a reliable reproducer for the bug, at least in the form Joseph in which it appeared with the old patch: Joseph http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01663.html - even Joseph though it was never clear exactly what the make bug was (the one Joseph referred to in that discussion appeared to rely on makefile Joseph features that weren't used by the old GCC patch). I re-read the old thread and also the GNU make bugs. I think this comment is what led me to believe that we'd hit GNU make bug #15919: https://savannah.gnu.org/bugs/?func=detailitemitem_id=15919#comment6 gcc's Makefile uses both .INTERMEDIATE and order-only dependencies, so seems like a candidate to trigger the problem. However, it seems that there must be more involved, because the Makefile currently in svn uses these features. I'm doing some testing with make 3.81 right now. Tom
Re: [c++-concepts] __is_same_as
Thanks a lot. Now I'm afraid that some of these nice clarifications, delicate technical details included, may get lost. Do you think they exist already in some of your design documents, papers, etc. Then a reference in the code would do. Otherwise, please consider adding some of the above to the branch. I'm writing a paper on the design and implementation of Conepts Lite. The technical details will be included there, or in a longer technical report. The semantics of the various intrinsics will be documented as part of the Concepts Lite TS since they're part of the language. Andrew
[PATCH][ARM] Fix gcc.target/arm/minmax_minus.c
Hi all, The minmaxsi_minus.c test in gcc.target/arm/ was added to confirm that we generate two conditional subtractions instead of two conditional moves and an unconditional subtraction. It tests that by scanning for two conditional rsb instructions. But now, the arm backend generates sub instructions instead of rsb when compiling for Thumb2. They perform the same functionality, but makes the testcase fail. This patch fixes the testacase by scanning for the absence of moves instead. Ok for trunk? Thanks, Kyrill 2013-07-26 Kyrylo Tkachov kyrylo.tkac...@arm.com * gcc.target/arm/minmax_minus.c: Scan for absence of mov. minmax_test.patch Description: Binary data
Re: [PATCH][ARM] Fix gcc.target/arm/minmax_minus.c
On 26/07/13 15:44, Kyrylo Tkachov wrote: Hi all, The minmaxsi_minus.c test in gcc.target/arm/ was added to confirm that we generate two conditional subtractions instead of two conditional moves and an unconditional subtraction. It tests that by scanning for two conditional rsb instructions. But now, the arm backend generates sub instructions instead of rsb when compiling for Thumb2. They perform the same functionality, but makes the testcase fail. This patch fixes the testacase by scanning for the absence of moves instead. Ok for trunk? Thanks, Kyrill 2013-07-26 Kyrylo Tkachov kyrylo.tkac...@arm.com * gcc.target/arm/minmax_minus.c: Scan for absence of mov. OK. R.
[PATCH 00/11] Rewrite of pass management
The following patch series eliminates the mutable global variables representing GCC's passes, allowing for multiple compilation contexts in one process, potentially with different combinations of passes (e.g. JIT-compilation of JavaScript in one thread, JIT-compilation of OpenGL shader programs in another) and with pass instances owning additional data, including GC references. The opt_pass hierarchy becomes a true C++ class hierarchy. Patch 1 introduces a gcc::pipeline class and moves various non-GTY globals relating to pass management into it. The gcc::context gains its first field: a pointer to the gcc::pipeline instance. Patch 2 adds a new autogenerated file: pass-instances.def, built from passes.def. We need this in patch 3 and patch 11 in order to be able to generate fields of class pipeline via macros (so that passes with multiple instances can have unique field names). Patches 3, 4 and 5 convert passes from C structs to C++ classes. Patch 6 replaces XNEW/memcpy calls using fixed sizes with invocations of opt_pass::clone, thus avoiding hard-coding the sizes of pass subclasses, allowing opt_pass subclasses to have additional fields. Patches 7 and 8 show a simple example of moving non-GTY state from being global to being pass instance data. Patch 9 adds enough special-casing to gengtype to allow it to cope with types that are within the gcc namespace. Patches 10 and 11 integrate the new classes with GTY (i.e. gcc::context, the opt_pass class hierarchy and gcc::pipeline), so that pass instances can own refs to GC-managed data. I've successfully bootstrapped the *end result* of the patch series on x86_64-unknown-linux-gnu: all testcases show the same results as an unpatched build (relative to r201251). OK for trunk? (I will bootstrap each of the above logical groups of patches before committing). Thanks Dave David Malcolm (11): Introduce beginnings of a pipeline class. Generate pass-instances.def Handwritten part of conversion of passes to C++ classes Automated conversion of passes to C++ classes Add -fno-rtti when building plugins. Rewrite how instances of passes are cloned Introduce virtual functions in testsuite/gcc.dg/plugin/one_time_plugin.c Example of converting global state to per-pass state Support gcc namespace in gengtype Make gcc::context be GC-managed Make opt_pass and gcc::pipeline be GC-managed gcc/Makefile.in| 24 +- gcc/asan.c | 109 ++- gcc/auto-inc-dec.c | 52 +- gcc/bb-reorder.c | 156 ++-- gcc/bt-load.c | 108 ++- gcc/cfgcleanup.c | 102 ++- gcc/cfgexpand.c| 55 +- gcc/cfgrtl.c | 153 ++-- gcc/cgraphbuild.c | 157 ++-- gcc/cgraphunit.c | 28 +- gcc/combine-stack-adj.c| 52 +- gcc/combine.c | 52 +- gcc/compare-elim.c | 55 +- gcc/config/epiphany/epiphany.h | 4 +- gcc/config/epiphany/mode-switch-use.c | 51 +- gcc/config/epiphany/resolve-sw-modes.c | 53 +- gcc/config/i386/i386.c | 60 +- gcc/config/i386/t-i386 | 2 +- gcc/config/mips/mips.c | 53 +- gcc/config/sparc/sparc.c | 54 +- gcc/context.c | 46 + gcc/context.h | 57 +- gcc/cprop.c| 55 +- gcc/cse.c | 164 ++-- gcc/dce.c | 104 ++- gcc/df-core.c | 161 ++-- gcc/dse.c | 108 ++- gcc/dwarf2cfi.c| 54 +- gcc/except.c | 107 ++- gcc/final.c| 204 +++-- gcc/function.c | 216 +++-- gcc/fwprop.c | 107 ++- gcc/gcse.c | 108 ++- gcc/gen-pass-instances.awk | 66 ++ gcc/gengtype.c | 19 +- gcc/gimple-low.c | 51 +- gcc/gimple-ssa-strength-reduction.c| 54 +- gcc/ifcvt.c| 157 ++-- gcc/init-regs.c| 52 +- gcc/ipa-cp.c | 75 +- gcc/ipa-inline-analysis.c | 56 +- gcc/ipa-inline.c | 122 ++-
[PATCH 04/11] Automated conversion of passes to C++ classes
This is the automated part of the conversion of passes from C structs to
C++ classes.
It is generated by the refactor_passes.py script in
https://github.com/davidmalcolm/gcc-refactoring-scripts
The script has its own test suite: test_refactor_passes.py, and you can
get an idea of the behavior of the script by reviewing the test suite.
This patch converts all existing pass structs for say RTL pass_foo into
the following:
namespace {
const pass_data pass_data_foo =
{
/* initialization data */
};
class pass_foo : public rtl_opt_pass
{
public:
pass_web(gcc::context *ctxt)
: rtl_opt_pass(pass_data_web, ctxt)
{}
/* opt_pass methods: */
bool gate () { return gate_foo (); }
unsigned int execute () { return execute_foo (); }
}; // class pass_foo
} // anon namespace
rtl_opt_pass *
make_pass_foo (gcc::context *ctxt)
{
return new pass_foo (ctxt);
}
so that the only exposed API to the pass is the factory function (i.e.
make_pass_foo).
It also updates tree-pass.h to replace all of the struct declarations:
extern struct rtl_opt_pass pass_foo;
with those of the new factory functions:
extern rtl_opt_pass *make_pass_foo (gcc::context *ctxt);
The full patch is 500k in size; I have posted it to:
http://dmalcolm.fedorapeople.org/gcc/large-patches/15e12880a4c291deb984fb628e3142429019b263-0004-Automated-conversion-of-passes-to-C-classes.patch
to avoid exceeding mailing list size limits (that version of the patch
includes the ChangeLog entries).
[PATCH 01/11] Introduce beginnings of a pipeline class.
This patch introduces a gcc::pipeline class and moves various non-GTY globals relating to pass management into it. The gcc::context gains its first field: a pointer to the gcc::pipeline instance. It was previously sent as: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01090.html as part of: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01088.html and Martin Jambor raised some stylistic concerns about it: http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01155.html I'm reposting it here so that people can see how it fits into the later patches. gcc/ * Makefile.in (PIPELINE_H): New. (lto-cgraph.o): Depend on CONTEXT_H and PIPELINE_H. (passes.o): Likewise. (statistics.o): Likewise. (cgraphunit.o): Likewise. (context.o): Depend on PIPELINE_H. * pipeline.h: New. * cgraphunit.c (cgraph_add_new_function): Update for moves of globals to fields of pipeline. (analyze_function): Likewise. (expand_function): Likewise. (ipa_passes): Likewise. (compile): Likewise. * context.c (context::context): New. * context.h (context::context): New. (context::get_passes): New. (context::passes_): New. * lto-cgraph.c (input_node): Update for moves of globals to fields of pipeline. * passes.c (all_passes): Remove, in favor of a field of the same name within the new class pipeline. (all_small_ipa_passes): Likewise. (all_lowering_passes): Likewise. (all_regular_ipa_passes): Likewise. (all_late_ipa_passes): Likewise. (all_lto_gen_passes): Likewise. (passes_by_id): Likewise. (passes_by_id_size): Likewise. (gcc_pass_lists): Remove, in favor of pass_lists field within the new class pipeline. (set_pass_for_id): Convert to... (pipeline::set_pass_for_id): ...method. (get_pass_for_id): Convert to... (pipeline::get_pass_for_id): ...method. (register_one_dump_file): Move body of implementation into... (pipeline::register_one_dump_file): ...here. (register_dump_files_1): Convert to... (pipeline::register_dump_files_1): ...method. (register_dump_files): Convert to... (pipeline::register_dump_files): ...method. (create_pass_tab): Update for moves of globals to fields of pipeline. (dump_passes): Move body of implementation into... (pipeline::dump_passes): ...here. (register_pass): Move body of implementation into... (pipeline::register_pass): ...here. (init_optimization_passes): Convert into... (pipeline::pipeline): ...constructor for new pipeline class, and initialize the pass_lists array. (check_profile_consistency): Update for moves of globals to fields of pipeline. (dump_profile_report): Move body of implementation into... (pipeline::dump_profile_report): ...here. (ipa_write_summaries_1): Update for moves of pass lists from being globals to fields of pipeline. (ipa_write_optimization_summaries): Likewise. (ipa_read_summaries): Likewise. (ipa_read_optimization_summaries): Likewise. (execute_all_ipa_stmt_fixups): Likewise. * statistics.c (statistics_fini): Update for moves of globals to fields of pipeline. * toplev.c (general_init): Replace call to init_optimization_passes with construction of the pipeline instance. * tree-pass.h (all_passes): Remove, in favor of a field of the same name within the new class pipeline. (all_small_ipa_passes): Likewise. (all_lowering_passes): Likewise. (all_regular_ipa_passes): Likewise. (all_lto_gen_passes): Likewise. (all_late_ipa_passes): Likewise. (passes_by_id): Likewise. (passes_by_id_size): Likewise. (gcc_pass_lists): Remove, in favor of pass_lists field within the new class pipeline. (get_pass_for_id): Remove. gcc/lto/ * Make-lang.in (lto/lto.o:): Depend on CONTEXT_H and PIPELINE_H. * lto.c (do_whole_program_analysis): Update for move of all_regular_ipa_passes from a global to a field of class pipeline. --- gcc/Makefile.in | 15 +--- gcc/cgraphunit.c | 22 +++- gcc/context.c| 6 gcc/context.h| 11 +- gcc/lto-cgraph.c | 7 ++-- gcc/lto/Make-lang.in | 3 +- gcc/lto/lto.c| 4 ++- gcc/passes.c | 97 +++- gcc/pipeline.h | 89 +++ gcc/statistics.c | 7 ++-- gcc/toplev.c | 4 +-- gcc/tree-pass.h | 29 12 files changed, 212 insertions(+), 82 deletions(-) create mode 100644 gcc/pipeline.h diff --git a/gcc/Makefile.in b/gcc/Makefile.in index fb0cb4b..0b28c2d 100644
[PATCH 05/11] Add -fno-rtti when building plugins.
With the conversion of passes to C++ classes, plugins that add custom
passes must create them by creating their own derived classes of the
relevant subclass of opt_pass. gcc itself is built with -fno-rtti,
hence there is no RTTI available for the opt_pass class hierarchy.
Hence plugins that create passes will need to be built with RTTI
disabled in order to link against gcc, or they will fail to load, with
an error like:
cc1: error: cannot load plugin ./selfassign.so
./selfassign.so: undefined symbol: _ZTI8opt_pass
(aka typeinfo for opt_pass).
gcc/testsuite
* lib/plugin-support.exp (plugin-test-execute): Add -fno-rtti
to optstr when building plugins.
---
gcc/testsuite/lib/plugin-support.exp | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/lib/plugin-support.exp
b/gcc/testsuite/lib/plugin-support.exp
index 88033b3..017f3fd 100644
--- a/gcc/testsuite/lib/plugin-support.exp
+++ b/gcc/testsuite/lib/plugin-support.exp
@@ -104,7 +104,7 @@ proc plugin-test-execute { plugin_src plugin_tests } {
set optstr [concat $optstr -DIN_GCC -fPIC -shared -undefined
dynamic_lookup]
} else {
set plug_cflags $PLUGINCFLAGS
- set optstr $includes $extra_flags -DIN_GCC -fPIC -shared
+ set optstr $includes $extra_flags -DIN_GCC -fPIC -shared -fno-rtti
}
# Temporarily switch to the environment for the plugin compiler.
--
1.7.11.7
[PATCH 03/11] Handwritten part of conversion of passes to C++ classes
This patch is the hand-written part of the conversion of passes from C structs to C++ classes. It does not work without the subsequent autogenerated part, which is huge. Given that the autogenerated part of the conversion is very large (500k), for the sake of human comprehension I have kept the change as two separate patches to keep the hand-written changes separate from the automatically-generated ones. I would commit these as two separate changes to SVN in order to keep this readability for posterity in the logs as well as at review-time. This pair of patches eliminates the mutable global variables representing the passes, allowing for multiple compilation contexts in one process, potentially with different combinations of passes, and with pass instance owning additional data. It converts the hierarchy of opt_pass types into an actual C++ class hierarchy, where each of: * gimple_opt_pass * rtl_opt_pass * ipa_opt_pass_d * simple_ipa_opt_pass all become subclasses of opt_pass. The gate and execute function pointers become virtual functions. This gives us type-safety, allowing the possibility of adding custom fields to opt_pass subclasses accessible from the execute vfunc without a cast. There is an additional clone virtual function, which exists so that: (a) passes can wire themselves up within a context, so that all sister passes within a context can share state with each other, without sharing state with their cousins in another compilation context: (b) pass subclasses can be encapsulated, and the hardcoded sizeof() logic in passes.c:make_pass_instance can be removed, allowing pass subclasses to have additional fields. Most of the metadata about passes is moved to a new struct pass_data, keeping just the sub, next and static_pass_number fields in the pass instances. Passes also gain a: gcc::context * ctxt_; field, so that a pass instance always knows which compilation context it is associated with, giving an easy way to avoid thread-local lookups in a future gcc-as-a-shared-library build. The pass_data has an extra pair of fields: has_gate and has_execute. These exist to deal with existing code that checks to see if a pass has a non-NULL gate or execute function ptr. Given that we can't portably do that on a vfunc, it's simplest to add a couple of extra bools to the pass_data struct, preserving the exact existing behaviors. In this patch opt_pass has an is a relationship to pass_data, rather than a references relationship, i.e.: class opt_pass : public pass_data Doing this minimizes the size of the patch and avoids an extra dereference when looking up patch metadata, but is perhaps something of a wart. gcc/ * Makefile.in (PIPELINE_H): Add dep on pass-instances.def. (toplev.o): Add dep on PIPELINE_H. * cgraphunit.c (cgraph_process_new_functions): Rework invocation of early local pases to reflect this moving from a global to a member of gcc::pipeline. (cgraph_add_new_function): Likewise. * lto-cgraph.c (lto_output_node): Update for conversion of struct ipa_opt_pass_d to a C++ subclass of opt_pass. * passes.c (opt_pass::clone): New. (opt_pass::gate): New. (opt_pass::execute): New. (opt_pass::opt_pass): New. (pipeline::execute_early_local_passes): New. (pipeline::execute_pass_mode_switching): new. (finish_optimization_passes): Convert to... (pipeline::finish_optimization_passes): ...this. (finish_optimization_passes): Update for conversion of passes to C++ classes. (register_dump_files_1): Use has_gate since we cannot portably check a vtable entry against NULL. (dump_one_pass): Likewise. (ipa_write_summaries_2): Likewise. (ipa_write_optimization_summaries_1): Likewise. (ipa_read_summaries_1): Likewise. (ipa_read_optimization_summaries_1): Likewise. (execute_ipa_stmt_fixups): Likewise. (pipeline::pipeline): Rewrite pass-creation, invoking pass-creation functions rather than wiring up globals, and storing the results in fields of pipeline generated using pass-instances.def. (pipeline::dump_profile_report): Update for conversion of passes to C++ classes. (pipeline::execute_ipa_summary_passes): Likewise. (execute_one_ipa_transform_pass): Likewise. (execute_one_pass): Use has_gate and has_execute since we cannot portably check a vtable entry against NULL. * pipeline.h (pipeline::finish_optimization_passes): New. (pipeline): Use pass-instances.def to add fields for the various pass instances. * toplev.c (finalize): Update for move of finish_optimization_passes to a method of gcc::pipeline. * toplev.h (finish_optimization_passes): Move to method of class pipeline. * tree-pass.h (struct pass_data): New.
[PATCH 06/11] Rewrite how instances of passes are cloned
gcc/
Rewrite how instances of passes are cloned to remove assumptions
about their sizes (thus allowing pass subclasses to have
additional data fields, albeit non-GC-managed ones at this point).
* passes.c (make_pass_instance): Now that passes have clone
methods, rewrite this function to eliminate XNEW and memcpy
calls that used hardcoded sizes. Since this function no longer
creates pass instances, rename it to...
(add_pass_instance): ...this. Document the old way that passes
were numbered and flagged, and rework this function to continue
using it.
(next_pass_1): Add an initial_pass argument for use by
add_pass_instance.
(position_pass): When adding multiple instances of a pass, use
the pass's clone method, rather than relying on the XNEW/memcpy
within the former make_pass_instance (now add_pass_instance).
(pipeline::pipeline): When invoking next_pass_1, also supply the
initial instance of the current pass within the pipeline.
---
gcc/passes.c | 92
1 file changed, 55 insertions(+), 37 deletions(-)
diff --git a/gcc/passes.c b/gcc/passes.c
index ead41a8..ce5cdeb 100644
--- a/gcc/passes.c
+++ b/gcc/passes.c
@@ -1167,68 +1167,77 @@ is_pass_explicitly_enabled_or_disabled (struct opt_pass
*pass,
return false;
}
-/* Look at the static_pass_number and duplicate the pass
- if it is already added to a list. */
-static struct opt_pass *
-make_pass_instance (struct opt_pass *pass, bool track_duplicates)
-{
- /* A nonzero static_pass_number indicates that the
- pass is already in the list. */
- if (pass-static_pass_number)
-{
- struct opt_pass *new_pass;
+/* Update static_pass_number for passes (and the flag
+ TODO_mark_first_instance).
- if (pass-type == GIMPLE_PASS
- || pass-type == RTL_PASS
- || pass-type == SIMPLE_IPA_PASS)
-{
- new_pass = XNEW (struct opt_pass);
- memcpy (new_pass, pass, sizeof (struct opt_pass));
-}
- else if (pass-type == IPA_PASS)
-{
- new_pass = (struct opt_pass *)XNEW (struct ipa_opt_pass_d);
- memcpy (new_pass, pass, sizeof (struct ipa_opt_pass_d));
-}
- else
-gcc_unreachable ();
+ Passes are constructed with static_pass_number preinitialized to 0
+
+ This field is used in two different ways: initially as instance numbers
+ of their kind, and then as ids within the entire pipeline.
+
+ Within pipeline::pipeline:
+
+ * In add_pass_instance(), as called by next_pass_1 in
+ NEXT_PASS in init_optimization_passes
- new_pass-next = NULL;
+ * When the initial instance of a pass within a pipeline is seen,
+ it is flagged, and its static_pass_number is set to -1
+ * On subsequent times that it is seen, the static pass number
+ is decremented each time, so that if there are e.g. 4 dups,
+ they have static_pass_number -4, 2, 3, 4 respectively (note
+ how the initial one is negative and gives the count); these
+ can be thought of as instance numbers of the specific pass
+
+ * Within the register_dump_files () traversal, set_pass_for_id()
+ is called on each pass, using these instance numbers to create
+ dumpfile switches, and then overwriting them with a pass id,
+ which are global to the whole pass pipeline (based on
+ (TDI_end + current value of extra_dump_files_in_use) ) */
+
+static void
+add_pass_instance (struct opt_pass *new_pass, bool track_duplicates,
+ opt_pass *initial_pass)
+{
+ /* Are we dealing with the first pass of its kind, or a clone? */
+ if (new_pass != initial_pass)
+{
+ /* We're dealing with a clone. */
new_pass-todo_flags_start = ~TODO_mark_first_instance;
/* Indicate to register_dump_files that this pass has duplicates,
and so it should rename the dump file. The first instance will
be -1, and be number of duplicates = -static_pass_number - 1.
Subsequent instances will be 0 and just the duplicate number. */
- if ((pass-name pass-name[0] != '*') || track_duplicates)
+ if ((new_pass-name new_pass-name[0] != '*') || track_duplicates)
{
- pass-static_pass_number -= 1;
- new_pass-static_pass_number = -pass-static_pass_number;
+ initial_pass-static_pass_number -= 1;
+ new_pass-static_pass_number = -initial_pass-static_pass_number;
}
- return new_pass;
}
else
{
- pass-todo_flags_start |= TODO_mark_first_instance;
- pass-static_pass_number = -1;
+ /* We're dealing with the first pass of its kind. */
+ new_pass-todo_flags_start |= TODO_mark_first_instance;
+ new_pass-static_pass_number = -1;
- invoke_plugin_callbacks (PLUGIN_NEW_PASS, pass);
+ invoke_plugin_callbacks (PLUGIN_NEW_PASS,
[PATCH 07/11] Introduce virtual functions in testsuite/gcc.dg/plugin/one_time_plugin.c
This is an example of converting the gate and execute functions of
a pass into C++ virtual functions, so that in the next patch we can move
a variable into member data of the opt_pass subclass.
gcc/testsuite/
* gcc.dg/plugin/one_time_plugin.c: (one_pass_gate): convert
to member function...
(one_pass::gate): ...this
(one_pass_exec): convert to member function...
(one_pass::impl_execute): ...this
---
gcc/testsuite/gcc.dg/plugin/one_time_plugin.c | 36 +--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/plugin/one_time_plugin.c
b/gcc/testsuite/gcc.dg/plugin/one_time_plugin.c
index 2d996da..7e93e65 100644
--- a/gcc/testsuite/gcc.dg/plugin/one_time_plugin.c
+++ b/gcc/testsuite/gcc.dg/plugin/one_time_plugin.c
@@ -12,22 +12,6 @@
int plugin_is_GPL_compatible;
-static bool one_pass_gate (void)
-{
- return true;
-}
-
-static unsigned int one_pass_exec (void)
-{
- static int counter = 0;
-
- if (counter 0) {
-printf (Executed more than once \n);
- }
- counter++;
- return 0;
-}
-
namespace {
const pass_data pass_data_one_pass =
@@ -53,13 +37,29 @@ public:
{}
/* opt_pass methods: */
- bool gate () { return one_pass_gate (); }
- unsigned int execute () { return one_pass_exec (); }
+ bool gate ();
+ unsigned int execute ();
}; // class one_pass
} // anon namespace
+bool one_pass::gate (void)
+{
+ return true;
+}
+
+unsigned int one_pass::execute ()
+{
+ static int counter = 0;
+
+ if (counter 0) {
+printf (Executed more than once \n);
+ }
+ counter++;
+ return 0;
+}
+
gimple_opt_pass *
make_one_pass (gcc::context *ctxt)
{
--
1.7.11.7
[PATCH 08/11] Example of converting global state to per-pass state
gcc/testsuite/
Example of converting global state to per-pass state.
* gcc.dg/plugin/one_time_plugin.c (one_pass::execute): Convert
global state static int counter to...
(one_pass::counter): ...this instance data.
---
gcc/testsuite/gcc.dg/plugin/one_time_plugin.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/gcc/testsuite/gcc.dg/plugin/one_time_plugin.c
b/gcc/testsuite/gcc.dg/plugin/one_time_plugin.c
index 7e93e65..c4dace5 100644
--- a/gcc/testsuite/gcc.dg/plugin/one_time_plugin.c
+++ b/gcc/testsuite/gcc.dg/plugin/one_time_plugin.c
@@ -33,13 +33,16 @@ class one_pass : public gimple_opt_pass
{
public:
one_pass(gcc::context *ctxt)
-: gimple_opt_pass(pass_data_one_pass, ctxt)
+: gimple_opt_pass(pass_data_one_pass, ctxt),
+ counter(0)
{}
/* opt_pass methods: */
bool gate ();
unsigned int execute ();
+private:
+ int counter;
}; // class one_pass
} // anon namespace
@@ -51,8 +54,6 @@ bool one_pass::gate (void)
unsigned int one_pass::execute ()
{
- static int counter = 0;
-
if (counter 0) {
printf (Executed more than once \n);
}
--
1.7.11.7
[PATCH 10/11] Make gcc::context be GC-managed
This patch makes gcc::context instances be allocated within the GC-heap,
and adds traversal hooks for GC/PCH so that a gcc::context can own refs
to other GC-allocated objects.
gcc/
* Makefile.in (GTFILES): Add context.h.
* context.c (gcc::context::operator new): New.
(gcc::context::gt_ggc_mx): New.
(gcc::context::gt_pch_nx): New.
(gcc::context::gt_pch_nx): New.
(gt_ggc_mx (gcc::context *)): New.
(gt_pch_nx (gcc::context *)): New.
(gt_pch_nx (gcc::context *ctxt, gt_pointer_operator op,
void *cookie)): New.
* context.h (gcc::context): Add GTY((user)) marking.
(gcc::context::operator new): New.
(gcc::context::gt_ggc_mx): New.
(gcc::context::gt_pch_nx): New.
(gcc::context::gt_pch_nx): New.
(g): Add GTY marking.
(gt_ggc_mx (gcc::context *)): New.
(gt_pch_nx (gcc::context *)): New.
(gt_pch_nx (gcc::context *ctxt, gt_pointer_operator op,
void *cookie)): New.
* gengtype.c (open_base_files) ifiles: Add context.h.
---
gcc/Makefile.in | 1 +
gcc/context.c | 41 +
gcc/context.h | 46 --
gcc/gengtype.c | 2 +-
4 files changed, 87 insertions(+), 3 deletions(-)
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index c1fdb8a..e9d6247 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3819,6 +3819,7 @@ GTFILES = $(CPP_ID_DATA_H) $(srcdir)/input.h
$(srcdir)/coretypes.h \
$(srcdir)/ipa-inline.h \
$(srcdir)/asan.c \
$(srcdir)/tsan.c \
+ $(srcdir)/context.h \
@all_gtfiles@
# Compute the list of GT header files from the corresponding C sources,
diff --git a/gcc/context.c b/gcc/context.c
index 8ec2e60..72135ed 100644
--- a/gcc/context.c
+++ b/gcc/context.c
@@ -27,7 +27,48 @@ along with GCC; see the file COPYING3. If not see
/* The singleton holder of global state: */
gcc::context *g;
+void *
+gcc::context::operator new (std::size_t size)
+{
+ return ggc_internal_cleared_alloc_stat (size MEM_STAT_INFO);
+}
+
gcc::context::context()
{
passes_ = new gcc::pipeline(this);
}
+
+/* Functions relating to the garbage collector. */
+void
+gcc::context::gt_ggc_mx ()
+{
+ /* Currently a no-op. */
+}
+
+void
+gcc::context::gt_pch_nx ()
+{
+ /* Currently a no-op. */
+}
+
+void
+gcc::context::gt_pch_nx (gt_pointer_operator op ATTRIBUTE_UNUSED,
+void *cookie ATTRIBUTE_UNUSED)
+{
+ /* Currently a no-op. */
+}
+
+void gt_ggc_mx (gcc::context *ctxt)
+{
+ ctxt-gt_ggc_mx ();
+}
+
+void gt_pch_nx (gcc::context *ctxt)
+{
+ ctxt-gt_pch_nx ();
+}
+
+void gt_pch_nx (gcc::context *ctxt, gt_pointer_operator op, void *cookie)
+{
+ ctxt-gt_pch_nx (op, cookie);
+}
diff --git a/gcc/context.h b/gcc/context.h
index a83f7b2..a65e62b 100644
--- a/gcc/context.h
+++ b/gcc/context.h
@@ -27,11 +27,30 @@ class pipeline;
/* GCC's internal state can be divided into zero or more
parallel universe of state; an instance of this class is one such
context of state. */
-class context
+class GTY((user)) context
{
public:
+ /* Ensure that instances are allocated within the GC-heap. */
+ void *operator new (std::size_t size);
+
context();
+ /* Garbage-collector integration.
+
+ Each context assumes it has full control of the GC-heap that it
+ is associated with. It acts as a root for that GC-heap, owning
+ references to within it.
+
+ Note that context instances are allocated within their own GC
+ heap.
+
+ The methods are called the *first time* that the context is reached
+ during a ggc/pch traversal, rather than every time. */
+
+ void gt_ggc_mx ();
+ void gt_pch_nx ();
+ void gt_pch_nx (gt_pointer_operator op, void *cookie);
+
/* Pass-management. */
pipeline get_passes () { gcc_assert (passes_); return *passes_; }
@@ -46,6 +65,29 @@ private:
/* The global singleton context aka g.
(the name is chosen to be easy to type in a debugger). */
-extern gcc::context *g;
+extern GTY(()) gcc::context *g;
+
+/* Global hooks for ggc/pch.
+
+ The gcc::context class is marked with GTY((user)), which leads to
+ gengtype creating autogenerated functions for handling context within
+ gtype-desc.c:
+
+ void gt_ggc_mx_context (void *x_p);
+ void gt_pch_nx_context (void *x_p)
+ void gt_pch_p_7context (void *this_obj,
+void *x_p,
+gt_pointer_operator op,
+void *cookie);
+
+ Those functions call the following global functions the first time
+ that the context is reached during a traversal, and the following
+ global functions in turn simply call the corresponding methods of the
+ context (so that they can access private fields of the context). */
+
+void gt_ggc_mx (gcc::context *ctxt);
+void gt_pch_nx (gcc::context *ctxt);
+void gt_pch_nx (gcc::context *ctxt, gt_pointer_operator op, void *cookie);
+
[PATCH 09/11] Support gcc namespace in gengtype
This patch adds enough special-casing to gengtype to allow it to cope
with types that are within the gcc namespace.
gcc/
* gengtype.c (type_for_name): Add special-case support for
locating types within the gcc:: namespace.
(open_base_files): Emit a using namespace gcc directive.
---
gcc/gengtype.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/gcc/gengtype.c b/gcc/gengtype.c
index 2085496..50efa9b 100644
--- a/gcc/gengtype.c
+++ b/gcc/gengtype.c
@@ -604,6 +604,16 @@ static type_p
type_for_name (const char *s)
{
pair_p p;
+
+ /* Special-case support for types within a gcc:: namespace. Rather
+ than fully-supporting namespaces, simply strip off the gcc:: prefix
+ where present. This allows us to have GTY roots of this form:
+ extern GTY(()) gcc::some_type *some_ptr;
+ where the autogenerated functions will refer to simply some_type,
+ where they can be resolved into their namespace. */
+ if (0 == strncmp(s, gcc::, 5))
+s += 5;
+
for (p = typedefs; p != NULL; p = p-next)
if (strcmp (p-name, s) == 0)
return p-type;
@@ -1735,6 +1745,13 @@ open_base_files (void)
/* Make sure we handle cfun specially. */
oprintf (gtype_desc_c, \n/* See definition in function.h. */\n);
oprintf (gtype_desc_c, #undef cfun\n);
+
+oprintf (gtype_desc_c,
+\n
+/* Types with a \gcc::\ prefix have the prefix stripped\n
+ during gengtype parsing. Provide a \using\ directive\n
+ to ensure that the fully-qualified types are found. */\n
+using namespace gcc;\n);
}
}
--
1.7.11.7
[PATCH 11/11] Make opt_pass and gcc::pipeline be GC-managed
This patch makes gcc::pipeline and opt_pass instances be allocated
within the GC-heap, and adds traversal hooks for GC/PCH, so that passes
can own refs to other GC-allocated objects.
gcc/
Make opt_pass and gcc::pipeline be GC-managed, so that pass
instances can own GC refs.
* Makefile.in (GTFILES): Add pipeline.h and tree-pass.h.
* context.c (gcc::context::gt_ggc_mx): Traverse passes_.
(gcc::context::gt_pch_nx): Likewise.
(gcc::context::gt_pch_nx): Likewise.
* passes.c (opt_pass::operator new): New.
(opt_pass::gt_ggc_mx): New.
(opt_pass::gt_pch_nx): New.
(opt_pass::gt_pch_nx_with_op): New.
(gt_ggc_mx (opt_pass *)): New.
(gt_pch_nx (opt_pass *)): New.
(gt_pch_nx_opt_pass): New.
(pipeline::operator new): New.
(pipeline::gt_ggc_mx): New.
(pipeline::gt_pch_nx): New.
(pipeline::gt_pch_nx_with_op): New.
(gt_ggc_mx (pipeline *)): New.
(gt_pch_nx (pipeline *)): New.
(gt_pch_nx_pipeline): New.
* pipeline.h (class pipeline): Add GTY((user)) marking.
(pipeline::operator new): New.
(pipeline::gt_ggc_mx): New.
(pipeline::gt_pch_nx): New.
(pipeline::gt_pch_nx_with_op): New.
(gt_ggc_mx (pipeline *)): New.
(gt_pch_nx (pipeline *)): New.
(gt_pch_nx_pipeline): New.
* tree-pass.h (class opt_pass): Add GTY((user)) marking.
(opt_pass::operator new): New.
(opt_pass::gt_ggc_mx): New.
(opt_pass::gt_pch_nx): New.
(opt_pass::gt_pch_nx_with_op): New.
(gt_ggc_mx (opt_pass *)): New.
(gt_pch_nx (opt_pass *)): New.
(gt_pch_nx_opt_pass): New.
---
gcc/Makefile.in | 2 +
gcc/context.c | 9 ++--
gcc/passes.c| 160
gcc/pipeline.h | 15 +-
gcc/tree-pass.h | 19 ++-
5 files changed, 198 insertions(+), 7 deletions(-)
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index e9d6247..ec42f7b 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -3820,6 +3820,8 @@ GTFILES = $(CPP_ID_DATA_H) $(srcdir)/input.h
$(srcdir)/coretypes.h \
$(srcdir)/asan.c \
$(srcdir)/tsan.c \
$(srcdir)/context.h \
+ $(srcdir)/pipeline.h \
+ $(srcdir)/tree-pass.h \
@all_gtfiles@
# Compute the list of GT header files from the corresponding C sources,
diff --git a/gcc/context.c b/gcc/context.c
index 72135ed..4d9f0c6 100644
--- a/gcc/context.c
+++ b/gcc/context.c
@@ -42,20 +42,19 @@ gcc::context::context()
void
gcc::context::gt_ggc_mx ()
{
- /* Currently a no-op. */
+ ::gt_ggc_mx (passes_);
}
void
gcc::context::gt_pch_nx ()
{
- /* Currently a no-op. */
+ ::gt_pch_nx (passes_);
}
void
-gcc::context::gt_pch_nx (gt_pointer_operator op ATTRIBUTE_UNUSED,
-void *cookie ATTRIBUTE_UNUSED)
+gcc::context::gt_pch_nx (gt_pointer_operator op, void *cookie)
{
- /* Currently a no-op. */
+ op (passes_, cookie);
}
void gt_ggc_mx (gcc::context *ctxt)
diff --git a/gcc/passes.c b/gcc/passes.c
index ce5cdeb..dd1b0ba 100644
--- a/gcc/passes.c
+++ b/gcc/passes.c
@@ -82,6 +82,33 @@ struct opt_pass *current_pass;
static void register_pass_name (struct opt_pass *, const char *);
+void*
+opt_pass::operator new (size_t sz)
+{
+ return ggc_internal_cleared_alloc_stat (sz MEM_STAT_INFO);
+}
+
+void opt_pass::gt_ggc_mx ()
+{
+ ::gt_ggc_mx (ctxt_);
+ ::gt_ggc_mx (sub);
+ ::gt_ggc_mx (next);
+}
+
+void opt_pass::gt_pch_nx ()
+{
+ ::gt_pch_nx (ctxt_);
+ ::gt_pch_nx (sub);
+ ::gt_pch_nx (next);
+}
+
+void opt_pass::gt_pch_nx_with_op (gt_pointer_operator op, void *cookie)
+{
+ op ((ctxt_), cookie);
+ op ((sub), cookie);
+ op ((next), cookie);
+}
+
/* Most passes are single-instance (within their context) and thus don't
need to implement cloning, but passes that support multiple instances
*must* provide their own implementation of the clone method.
@@ -116,6 +143,118 @@ opt_pass::opt_pass(const pass_data data, context *ctxt)
{
}
+void gt_ggc_mx (opt_pass *p)
+{
+ if (ggc_test_and_set_mark (p))
+p-gt_ggc_mx ();
+}
+
+void gt_pch_nx (opt_pass *p)
+{
+ if (gt_pch_note_object (p, p, ::gt_pch_nx_opt_pass))
+p-gt_pch_nx ();
+}
+
+void gt_pch_nx_opt_pass (void *this_obj, void *p,
+gt_pointer_operator op, void *cookie)
+{
+ opt_pass *pass = (opt_pass*)p;
+ if (p == this_obj)
+pass-gt_pch_nx_with_op (op, cookie);
+}
+
+void*
+pipeline::operator new (size_t sz)
+{
+ return ggc_internal_cleared_alloc_stat (sz MEM_STAT_INFO);
+}
+
+void
+pipeline::gt_ggc_mx ()
+{
+ ::gt_ggc_mx (all_passes);
+ ::gt_ggc_mx (all_small_ipa_passes);
+ ::gt_ggc_mx (all_lowering_passes);
+ ::gt_ggc_mx (all_regular_ipa_passes);
+ ::gt_ggc_mx (all_lto_gen_passes);
+ ::gt_ggc_mx (all_late_ipa_passes);
+
+ for (int i = 0; i passes_by_id_size; i++)
+::gt_ggc_mx (passes_by_id[i]);
+
+#define INSERT_PASSES_AFTER(PASS)
+#define
[PATCH 02/11] Generate pass-instances.def
Introduce a new gen-pass-instances.awk script, and use it at build time
to make a pass-instances.def from passes.def.
An example of the result can be seen at:
http://dmalcolm.fedorapeople.org/gcc/2013-07-25/pass-instances.def
The generated pass-instances.def contains similar content to passes.def,
but the pass instances within it are explicitly numbered, so that e.g.
the third instance of:
NEXT_PASS (pass_copy_prop)
becomes:
NEXT_PASS (pass_copy_prop, 3)
This is needed by a subsequent patch so that we can create fields within
the pipeline class for each pass instance, where we need unique field
names to avoid a syntax error. For example, all 8 instances of
pass_copy_prop will need different names. e.g.
opt_pass *pass_copy_prop_1;
...
opt_pass *pass_copy_prop_8;
I have successfully tested the script with gawk, with gawk using the
-c compatibility option to turn off gawk extensions, and with busybox
awk (versions tested were gawk-4.0.1 and busybox-1.19.4).
This patch replaces a previous attempt at this:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00686.html
which converted multi-instance passes to using a new NEXT_PASS_NUM
macro, requiring the instance numbering within passes.def to be
maintained by hand.
In the new approach, the instance numbers are generated automatically,
and are visible at build time, giving the uniqueness needed by later
patches, whilst avoiding manual maintenance work, and also making it
easy to see the instance numbering (by inspecting the generated
pass-instances.def).
gcc/
* Makefile.in (pass-instances.def): New.
(passes.o): Replace dependency on passes.def with one on
pass-instances.def
* gen-pass-instances.awk: New.
* passes.c (pipeline::pipeline): Use pass-instances.def rather
than passes.def, updating local definition of NEXT_PASS macro
to add an extra NUM parameter (currently unused).
---
gcc/Makefile.in| 6 -
gcc/gen-pass-instances.awk | 66 ++
gcc/passes.c | 4 +--
3 files changed, 73 insertions(+), 3 deletions(-)
create mode 100644 gcc/gen-pass-instances.awk
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 0b28c2d..6d1f32c 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2737,6 +2737,10 @@ toplev.o : toplev.c $(CONFIG_H) $(SYSTEM_H) coretypes.h
$(TM_H) $(TREE_H) \
hwint.o : hwint.c $(CONFIG_H) $(SYSTEM_H) $(DIAGNOSTIC_CORE_H)
+pass-instances.def: $(srcdir)/passes.def $(srcdir)/gen-pass-instances.awk
+ $(AWK) -f $(srcdir)/gen-pass-instances.awk \
+ $(srcdir)/passes.def pass-instances.def
+
passes.o : passes.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \
$(RTL_H) $(FUNCTION_H) $(FLAGS_H) $(INPUT_H) $(INSN_ATTR_H) output.h \
$(DIAGNOSTIC_CORE_H) debug.h insn-config.h intl.h $(RECOG_H) toplev.h \
@@ -2747,7 +2751,7 @@ passes.o : passes.c $(CONFIG_H) $(SYSTEM_H) coretypes.h
$(TM_H) $(TREE_H) \
hosthooks.h $(CGRAPH_H) $(COVERAGE_H) $(TREE_PASS_H) $(TREE_DUMP_H) \
$(GGC_H) $(OPTS_H) $(TREE_FLOW_H) $(TREE_INLINE_H) \
gt-passes.h $(DF_H) $(PREDICT_H) $(LTO_STREAMER_H) \
- $(PLUGIN_H) $(IPA_UTILS_H) passes.def \
+ $(PLUGIN_H) $(IPA_UTILS_H) pass-instances.def \
$(CONTEXT_H) $(PIPELINE_H)
plugin.o : plugin.c $(PLUGIN_H) $(CONFIG_H) $(SYSTEM_H) coretypes.h \
diff --git a/gcc/gen-pass-instances.awk b/gcc/gen-pass-instances.awk
new file mode 100644
index 000..41b5e75
--- /dev/null
+++ b/gcc/gen-pass-instances.awk
@@ -0,0 +1,66 @@
+# Copyright (C) 2013 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by the
+# Free Software Foundation; either version 3, or (at your option) any
+# later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; see the file COPYING3. If not see
+# http://www.gnu.org/licenses/.
+
+# This Awk script takes passes.def and writes pass-instances.def,
+# counting the instances of each kind of pass, adding an instance number
+# to everywhere that NEXT_PASS is used.
+#
+# For example, the single-instanced pass:
+# NEXT_PASS (pass_warn_unused_result);
+# becomes this in the output:
+# NEXT_PASS (pass_warn_unused_result, 1);
+#
+# The various instances of
+# NEXT_PASS (pass_copy_prop);
+# become:
+# NEXT_PASS (pass_copy_prop, 1);
+# through:
+# NEXT_PASS (pass_copy_prop, 8);
+# (currently there are 8 instances of that pass)
+
+# Usage: awk -f gen-pass-instances.awk passes.def
+
+BEGIN {
+ print /* This file is auto-generated by gen-pass-instances.awk;
+ printfrom passes.def.
[PATCH 02/11] Generate pass-instances.def
Introduce a new gen-pass-instances.awk script, and use it at build time
to make a pass-instances.def from passes.def.
An example of the result can be seen at:
http://dmalcolm.fedorapeople.org/gcc/2013-07-25/pass-instances.def
The generated pass-instances.def contains similar content to passes.def,
but the pass instances within it are explicitly numbered, so that e.g.
the third instance of:
NEXT_PASS (pass_copy_prop)
becomes:
NEXT_PASS (pass_copy_prop, 3)
This is needed by a subsequent patch so that we can create fields within
the pipeline class for each pass instance, where we need unique field
names to avoid a syntax error. For example, all 8 instances of
pass_copy_prop will need different names. e.g.
opt_pass *pass_copy_prop_1;
...
opt_pass *pass_copy_prop_8;
I have successfully tested the script with gawk, with gawk using the
-c compatibility option to turn off gawk extensions, and with busybox
awk (versions tested were gawk-4.0.1 and busybox-1.19.4).
This patch replaces a previous attempt at this:
http://gcc.gnu.org/ml/gcc-patches/2013-07/msg00686.html
which converted multi-instance passes to using a new NEXT_PASS_NUM
macro, requiring the instance numbering within passes.def to be
maintained by hand.
In the new approach, the instance numbers are generated automatically,
and are visible at build time, giving the uniqueness needed by later
patches, whilst avoiding manual maintenance work, and also making it
easy to see the instance numbering (by inspecting the generated
pass-instances.def).
gcc/
* Makefile.in (pass-instances.def): New.
(passes.o): Replace dependency on passes.def with one on
pass-instances.def
* gen-pass-instances.awk: New.
* passes.c (pipeline::pipeline): Use pass-instances.def rather
than passes.def, updating local definition of NEXT_PASS macro
to add an extra NUM parameter (currently unused).
---
gcc/Makefile.in| 6 -
gcc/gen-pass-instances.awk | 66 ++
gcc/passes.c | 4 +--
3 files changed, 73 insertions(+), 3 deletions(-)
create mode 100644 gcc/gen-pass-instances.awk
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 0b28c2d..6d1f32c 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -2737,6 +2737,10 @@ toplev.o : toplev.c $(CONFIG_H) $(SYSTEM_H) coretypes.h
$(TM_H) $(TREE_H) \
hwint.o : hwint.c $(CONFIG_H) $(SYSTEM_H) $(DIAGNOSTIC_CORE_H)
+pass-instances.def: $(srcdir)/passes.def $(srcdir)/gen-pass-instances.awk
+ $(AWK) -f $(srcdir)/gen-pass-instances.awk \
+ $(srcdir)/passes.def pass-instances.def
+
passes.o : passes.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(TREE_H) \
$(RTL_H) $(FUNCTION_H) $(FLAGS_H) $(INPUT_H) $(INSN_ATTR_H) output.h \
$(DIAGNOSTIC_CORE_H) debug.h insn-config.h intl.h $(RECOG_H) toplev.h \
@@ -2747,7 +2751,7 @@ passes.o : passes.c $(CONFIG_H) $(SYSTEM_H) coretypes.h
$(TM_H) $(TREE_H) \
hosthooks.h $(CGRAPH_H) $(COVERAGE_H) $(TREE_PASS_H) $(TREE_DUMP_H) \
$(GGC_H) $(OPTS_H) $(TREE_FLOW_H) $(TREE_INLINE_H) \
gt-passes.h $(DF_H) $(PREDICT_H) $(LTO_STREAMER_H) \
- $(PLUGIN_H) $(IPA_UTILS_H) passes.def \
+ $(PLUGIN_H) $(IPA_UTILS_H) pass-instances.def \
$(CONTEXT_H) $(PIPELINE_H)
plugin.o : plugin.c $(PLUGIN_H) $(CONFIG_H) $(SYSTEM_H) coretypes.h \
diff --git a/gcc/gen-pass-instances.awk b/gcc/gen-pass-instances.awk
new file mode 100644
index 000..41b5e75
--- /dev/null
+++ b/gcc/gen-pass-instances.awk
@@ -0,0 +1,66 @@
+# Copyright (C) 2013 Free Software Foundation, Inc.
+#
+# This program is free software; you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by the
+# Free Software Foundation; either version 3, or (at your option) any
+# later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; see the file COPYING3. If not see
+# http://www.gnu.org/licenses/.
+
+# This Awk script takes passes.def and writes pass-instances.def,
+# counting the instances of each kind of pass, adding an instance number
+# to everywhere that NEXT_PASS is used.
+#
+# For example, the single-instanced pass:
+# NEXT_PASS (pass_warn_unused_result);
+# becomes this in the output:
+# NEXT_PASS (pass_warn_unused_result, 1);
+#
+# The various instances of
+# NEXT_PASS (pass_copy_prop);
+# become:
+# NEXT_PASS (pass_copy_prop, 1);
+# through:
+# NEXT_PASS (pass_copy_prop, 8);
+# (currently there are 8 instances of that pass)
+
+# Usage: awk -f gen-pass-instances.awk passes.def
+
+BEGIN {
+ print /* This file is auto-generated by gen-pass-instances.awk;
+ printfrom passes.def.
committed: Skip tests for epiphany that make invalid struct layout assumptions
Quoting Richard Guenther richard.guent...@gmail.com:
On Sun, Sep 25, 2011 at 2:36 PM, Joern Rennecke amyl...@spamcop.net wrote:
This patch has not been reviewed for eight weeks.
- Forwarded message from amyl...@spamcop.net -
  Date: Mon, 01 Aug 2011 01:01:13 -0400
  From: Joern Rennecke amyl...@spamcop.net
Reply-To: Joern Rennecke amyl...@spamcop.net
 Subject: RFA: Testsuite fixes (2/3): struct padding / alignment
   To: gcc-patches@gcc.gnu.org
I am working with a target port that adds alignment and/or padding to
certain
structures. Â This causes some tests to fail that assume such padding does
not exist.
Fixed by adding a packed attribute to the structures in question.
I think you should instead dg-skip the tests on your target. At least ...
Done thusly.
2013-07-26 Joern Rennecke joern.renne...@embecosm.com
Skip tests that make assumptions about struct layout that don't hold
on epiphany:
* g++.dg/cpp0x/cast.C: Skip for epiphany-*-*.
* g++.dg/cpp0x/iop.C: Likewise.
* g++.dg/cpp0x/named_refs.C: Likewise.
* g++.dg/cpp0x/rv1p.C: Likewise.
* g++.dg/cpp0x/rv2p.C: Likewise.
* g++.dg/cpp0x/rv3p.C: Likewise.
* g++.dg/cpp0x/rv4p.C: Likewise.
* g++.dg/cpp0x/rv5p.C: Likewise.
* g++.dg/cpp0x/rv6p.C: Likewise.
* g++.dg/cpp0x/rv7p.C: Likewise.
* g++.dg/cpp0x/rv8p.C: Likewise.
* g++.dg/ext/strncpy-chk1.C: Likewise.
* gcc.dg/builtin-object-size-10.c: Likewise.
* gcc.dg/builtin-object-size-11.c: Likewise.
* gcc.dg/builtin-stringop-chk-1.c: Likewise.
* gcc.dg/pr25805.c: Likewise.
* gcc.c-torture/execute/builtins/memcpy-chk.x: New file.
* gcc.c-torture/execute/builtins/memmove-chk.x: Likewise.
* gcc.c-torture/execute/builtins/mempcpy-chk.x: Likewise.
* gcc.c-torture/execute/builtins/memset-chk.x: Likewise.
* gcc.c-torture/execute/builtins/snprintf-chk.x: Likewise.
* gcc.c-torture/execute/builtins/sprintf-chk.x: Likewise.
* gcc.c-torture/execute/builtins/stpcpy-chk.x: Likewise.
* gcc.c-torture/execute/builtins/strcat-chk.x: Likewise.
* gcc.c-torture/execute/builtins/strcpy-chk.x: Likewise.
* gcc.c-torture/execute/builtins/strncat-chk.x: Likewise.
* gcc.c-torture/execute/builtins/strncpy-chk.x: Likewise.
* gcc.c-torture/execute/builtins/vsnprintf-chk.x: Likewise.
* gcc.c-torture/execute/builtins/vsprintf-chk.x: Likewise.
* gcc.c-torture/execute/zerolen-2.x: Likewise.
Index: testsuite/gcc.c-torture/execute/zerolen-2.x
===
--- testsuite/gcc.c-torture/execute/zerolen-2.x (revision 0)
+++ testsuite/gcc.c-torture/execute/zerolen-2.x (revision 201268)
@@ -0,0 +1,7 @@
+if [istarget epiphany-*-*] {
+# This test assumes the absence of larger-than-word padding.
+# to make this true for struct foo on epiphany would require
+# __attribute__((packed,aligned(__alignof__(word .
+return 1
+}
+return 0
Index: testsuite/gcc.c-torture/execute/builtins/mempcpy-chk.x
===
--- testsuite/gcc.c-torture/execute/builtins/mempcpy-chk.x (revision 0)
+++ testsuite/gcc.c-torture/execute/builtins/mempcpy-chk.x (revision
201268)
@@ -0,0 +1,7 @@
+if [istarget epiphany-*-*] {
+# This test assumes the absence of struct padding.
+# to make this true for test4 struct A on epiphany would require
+# __attribute__((packed)) .
+return 1
+}
+return 0
Index: testsuite/gcc.c-torture/execute/builtins/vsprintf-chk.x
===
--- testsuite/gcc.c-torture/execute/builtins/vsprintf-chk.x (revision 0)
+++ testsuite/gcc.c-torture/execute/builtins/vsprintf-chk.x (revision
201268)
@@ -0,0 +1,7 @@
+if [istarget epiphany-*-*] {
+# This test assumes the absence of struct padding.
+# to make this true for test3_sub struct A on epiphany would require
+# __attribute__((packed)) .
+return 1
+}
+return 0
Index: testsuite/gcc.c-torture/execute/builtins/vsnprintf-chk.x
===
--- testsuite/gcc.c-torture/execute/builtins/vsnprintf-chk.x(revision 0)
+++ testsuite/gcc.c-torture/execute/builtins/vsnprintf-chk.x(revision
201268)
@@ -0,0 +1,7 @@
+if [istarget epiphany-*-*] {
+# This test assumes the absence of struct padding.
+# to make this true for test3_sub struct A on epiphany would require
+# __attribute__((packed)) .
+return 1
+}
+return 0
Index: testsuite/gcc.c-torture/execute/builtins/snprintf-chk.x
===
--- testsuite/gcc.c-torture/execute/builtins/snprintf-chk.x (revision 0)
+++ testsuite/gcc.c-torture/execute/builtins/snprintf-chk.x (revision
201268)
@@ -0,0 +1,7 @@
+if [istarget epiphany-*-*] {
+
Re: [PATCH 00/18] resurrect automatic dependency tracking
Tom Good idea. I'll dig up make 3.81 and give it a try soon, if not Tom tomorrow, then early next week. I did this today. I downloaded and built GNU make 3.81 and put it in my PATH. Then I did make -j2 builds in the gcc directory of each revision. I also ran touch Makefile.in and then make -j2 again. I didn't see any hangs. So, at least for me, the branch seems safe. Anybody else can easily try it. I do need to make another revision of the series, though. I'd forgotten why gdb has this POSTCOMPILE step, but I saw the answer while re-reading the old thread: it avoids an atomicity problem if gcc is interrupted while writing the .Po file. I'll send the new series soon. Tom
[google/gcc-4_8] Fix problem with type signatures and template instantiations.
This patch is for the google/gcc-4_8 branch. I will also submit this
to trunk separately.
This fixes a problem with -fdebug-types-section where some types that
have contain nested type templates or member function templates are
given different type signatures in different compilation units,
depending on which instantiations of those members are contained
in the compilation unit. The problem is two-fold:
(1) When moving a type to its own type unit, nested template
instantiations shouldn't appear at all as children of the type in the
type unit. The skeleton declaration tree left behind in the CU,
however, may still need declarations of those instantiations -- for
example, if there's an instantiated member function template, the CU
will need a DW_TAG_subprogram DIE at the top level, with
DW_AT_specification pointing to its declaration inside the skeleton
for the class.
(2) When computing the type signature, we want to ignore
instantiations. For nested instantiated type templates, I solve this
by calling break_out_comdat_types recursively before computing the
type signature instead of later. For instantiated member function
templates, I simply ignore them during the signature computation,
since they don't get moved back to the CU until after the signature
computation.
Bootstrapped and tested with GCC and GDB test suites.
Google ref b/9884815.
2013-07-26 Cary Coutant ccout...@google.com
gcc/
* dwarf2out.c (die_checksum_ordered): Don't include template
instantiations in signature.
(is_template_parameter): New function.
(is_template_instantiation): New function.
(generate_skeleton_bottom_up): Don't include template instantiations
in type unit DIE.
(generate_skeleton): Likewise.
(break_out_comdat_types): Move recursive call to break out nested
types earlier.
(prune_unused_types_mark_generic_parms_dies): Call
is_template_parameter.
testsuite/
* g++.dg/debug/dwarf2/dwarf4-nested.C: Update test case.
Index: testsuite/g++.dg/debug/dwarf2/dwarf4-nested.C
===
--- testsuite/g++.dg/debug/dwarf2/dwarf4-nested.C (revision 201268)
+++ testsuite/g++.dg/debug/dwarf2/dwarf4-nested.C (working copy)
@@ -8,10 +8,9 @@
//
// { dg-final { scan-assembler DIE \\(\[^\n\]*\\) DW_TAG_type_unit } }
//
-// Check that func is declared exactly twice in the debug info:
-// once in the type unit for struct D, and once in the compile unit.
+// Check that func is declared exactly once in the debug info.
//
-// { dg-final { scan-assembler-times \\.ascii
\func0\\[^\n\]*DW_AT_name 2 } }
+// { dg-final { scan-assembler-times \\.ascii
\func0\\[^\n\]*DW_AT_name 1 } }
//
// Check to make sure that no type unit contains a DIE with DW_AT_low_pc
// or DW_AT_ranges. These patterns assume that the compile unit is always
Index: dwarf2out.c
===
--- dwarf2out.c (revision 201268)
+++ dwarf2out.c (working copy)
@@ -3060,6 +3060,7 @@ static void compute_section_prefix (dw_d
static int is_type_die (dw_die_ref);
static int is_comdat_die (dw_die_ref);
static int is_symbol_die (dw_die_ref);
+static inline bool is_template_instantiation (dw_die_ref);
static void assign_symbol_names (dw_die_ref);
static void break_out_includes (dw_die_ref);
static int is_declaration_die (dw_die_ref);
@@ -6120,22 +6121,29 @@ die_checksum_ordered (dw_die_ref die, st
CHECKSUM_ATTR (attrs.at_type);
CHECKSUM_ATTR (attrs.at_friend);
- /* Checksum the child DIEs, except for nested types and member functions. */
+ /* Checksum the child DIEs. */
c = die-die_child;
if (c) do {
dw_attr_ref name_attr;
c = c-die_sib;
name_attr = get_AT (c, DW_AT_name);
-if ((is_type_die (c) || c-die_tag == DW_TAG_subprogram)
- name_attr != NULL)
+if (is_template_instantiation (c))
{
+ /* Ignore instantiations of member type and function templates. */
+ }
+else if (name_attr != NULL
+ (is_type_die (c) || c-die_tag == DW_TAG_subprogram))
+ {
+ /* Use a shallow checksum for named nested types and member
+ functions. */
CHECKSUM_ULEB128 ('S');
CHECKSUM_ULEB128 (c-die_tag);
CHECKSUM_STRING (AT_string (name_attr));
}
else
{
+ /* Use a deep checksum for other children. */
/* Mark this DIE so it gets processed when unmarking. */
if (c-die_mark == 0)
c-die_mark = -1;
@@ -6540,6 +6548,36 @@ is_class_die (dw_die_ref c)
|| c-die_tag == DW_TAG_structure_type);
}
+/* Return non-zero if this DIE is a template parameter. */
+
+static inline bool
+is_template_parameter (dw_die_ref die)
+{
+ switch (die-die_tag)
+{
+case DW_TAG_template_type_param:
+case DW_TAG_template_value_param:
+case DW_TAG_GNU_template_template_param:
+case
Re: [GOOGLE] Port remaining -fopt-info messages from google/4_7 (plus dump infrastructure enhancement)
Ok for google branches. Many changes in coverage.c (such as get_coverage_counts) and value-prof.c need to be in trunk too. David On Thu, Jul 25, 2013 at 10:02 AM, Teresa Johnson tejohn...@google.com wrote: This patch ports the remaining -fopt-info messages that had been added to google/gcc-4_7 using the original -fopt-info framework implemented on that branch, to google/gcc-4_8 using the new -fopt-info framework from trunk. Specifically, this ports over the messages added/modified by r180269, r180973 and r195968. Some of these patches/messages were already ported, but this adds the remainder. I converted from the old OPT_INFO_* levels to the new MSG_* levels using the following mapping: OPT_INFO_MIN - MSG_OPTIMIZED_LOCATIONS OPT_INFO_MED - MSG_MISSED_OPTIMIZATION OPT_INFO_MAX - MSG_NOTE The affected messages relate to LIPO module imports, missing/mismatched/ corrupted profile data, and indirect call promotions performed. Additionally, after discussing with Easwaran and Rong, I flipped the default of the inline-dump-module-id parameter to 1 to enable dumping module ids in -fopt-info inlining messages for easier inlining report generation. Finally, I had to make a couple enhancements to the new dump infrastructure to get some of the new messages emitted. This change should be pushed to trunk as it will help facilitate adding new dump messages more easily (particularly number 2 below). There were two issues: 1) The module imports occurred during coverage_init which happens very early, before entering the pass manager that sets up the dumping. This was addressed by enabling dumping within coverage_init, and is modeled on how dumping is enabled after the pass manager during finish_optimization_passes. 2) Dumping was only enabled for passes marked with an optinfo_flag that isn't OPTGROUP_NONE. Currently optgroup flags are only setup for optimization groups in the categories IPA, LOOP, INLINE and VEC. What this means is that any dump messages added to a pass that isn't in one of these groups will silently be suppressed. The OPTGROUP setting is specified in opt_pass struct, and is also automatically set to OPTGROUP_IPA for any pass starting with ipa-. What I did was to add a new optgroup macro, OPTGROUP_OTHER. This is enabled only under -fopt-info-optall, which is also the default for -fopt-info. That way dump messages can be emitted without the requirement that the pass be part of a group that can be emitted under a specific optimization group subset. When setting up the dumps, any pass that has OPTGROUP_NONE after examining the opt_pass struct and the pass name will use OPTGROUP_OTHER. This doesn't mean that the list of optgroups shouldn't be expanded, but rather adds a catch-all for passes that don't currently have or need to be emitted on their own as part of a new optgroup. Bootstrapped and regression tested. Ok for google/4_8? (Attached patch as a file also since pasting below messed up the whitespace formatting.) Thanks, Teresa 2013-07-25 Teresa Johnson tejohn...@google.com * c-family/c-opts.c (lipo_max_mem_reached): Use new dump framework. * profile.c (read_profile_edge_counts): Ditto. (compute_branch_probabilities): Ditto. * value-prof.c (check_counter): Ditto. (check_ic_counter): Ditto. (find_func_by_funcdef_no): Ditto. (check_ic_target): Ditto. (gimple_ic_transform_mult_targ): Ditto. * mcf.c (find_minimum_cost_flow): Ditto. * coverage.c (incompatible_cl_args): Ditto. (read_counts_file): Ditto. (get_coverage_counts): Ditto. (coverage_init): Setup new dump framework. * common.opt (flag_ripa_verbose): Remove. * params.def (PARAM_INLINE_DUMP_MODULE_ID): Enable by default. * dumpfile.h (OPTGROUP_OTHER): Add and enable under OPTGROUP_ALL. * passes.c (register_one_dump_file): Use OPTGROUP_OTHER when pass not in any opt group. * doc/invoke.texi: Document optall -fopt-info flag. * testsuite/gcc.dg/pr32773.c: Use -fopt-info. * testsuite/gcc.dg/pr40209.c: Ditto. * testsuite/gcc.dg/pr26570.c: Ditto. * testsuite/gcc.dg/tree-prof/lipo/lipo_inline1_0.c: Ditto. * testsuite/g++.dg/tree-ssa/dom-invalid.C: Ditto. Index: coverage.c === --- coverage.c (revision 200845) +++ coverage.c (working copy) @@ -48,6 +48,7 @@ along with GCC; see the file COPYING3. If not see #include opts.h #include gcov-io.h #include tree-flow.h +#include tree-pass.h #include cpplib.h #include incpath.h #include diagnostic-core.h @@ -411,14 +412,18 @@ incompatible_cl_args (struct gcov_module_info* mod warning (OPT_Wripa_opt_mismatch, command line arguments mismatch for %s and %s, mod_info1-source_filename, mod_info2-source_filename); - if
Re: [GOOGLE] Port remaining -fopt-info messages from google/4_7 (plus dump infrastructure enhancement)
Thanks. I'll work on a trunk patch to send next week. Teresa On Fri, Jul 26, 2013 at 10:05 AM, Xinliang David Li davi...@google.com wrote: Ok for google branches. Many changes in coverage.c (such as get_coverage_counts) and value-prof.c need to be in trunk too. David On Thu, Jul 25, 2013 at 10:02 AM, Teresa Johnson tejohn...@google.com wrote: This patch ports the remaining -fopt-info messages that had been added to google/gcc-4_7 using the original -fopt-info framework implemented on that branch, to google/gcc-4_8 using the new -fopt-info framework from trunk. Specifically, this ports over the messages added/modified by r180269, r180973 and r195968. Some of these patches/messages were already ported, but this adds the remainder. I converted from the old OPT_INFO_* levels to the new MSG_* levels using the following mapping: OPT_INFO_MIN - MSG_OPTIMIZED_LOCATIONS OPT_INFO_MED - MSG_MISSED_OPTIMIZATION OPT_INFO_MAX - MSG_NOTE The affected messages relate to LIPO module imports, missing/mismatched/ corrupted profile data, and indirect call promotions performed. Additionally, after discussing with Easwaran and Rong, I flipped the default of the inline-dump-module-id parameter to 1 to enable dumping module ids in -fopt-info inlining messages for easier inlining report generation. Finally, I had to make a couple enhancements to the new dump infrastructure to get some of the new messages emitted. This change should be pushed to trunk as it will help facilitate adding new dump messages more easily (particularly number 2 below). There were two issues: 1) The module imports occurred during coverage_init which happens very early, before entering the pass manager that sets up the dumping. This was addressed by enabling dumping within coverage_init, and is modeled on how dumping is enabled after the pass manager during finish_optimization_passes. 2) Dumping was only enabled for passes marked with an optinfo_flag that isn't OPTGROUP_NONE. Currently optgroup flags are only setup for optimization groups in the categories IPA, LOOP, INLINE and VEC. What this means is that any dump messages added to a pass that isn't in one of these groups will silently be suppressed. The OPTGROUP setting is specified in opt_pass struct, and is also automatically set to OPTGROUP_IPA for any pass starting with ipa-. What I did was to add a new optgroup macro, OPTGROUP_OTHER. This is enabled only under -fopt-info-optall, which is also the default for -fopt-info. That way dump messages can be emitted without the requirement that the pass be part of a group that can be emitted under a specific optimization group subset. When setting up the dumps, any pass that has OPTGROUP_NONE after examining the opt_pass struct and the pass name will use OPTGROUP_OTHER. This doesn't mean that the list of optgroups shouldn't be expanded, but rather adds a catch-all for passes that don't currently have or need to be emitted on their own as part of a new optgroup. Bootstrapped and regression tested. Ok for google/4_8? (Attached patch as a file also since pasting below messed up the whitespace formatting.) Thanks, Teresa 2013-07-25 Teresa Johnson tejohn...@google.com * c-family/c-opts.c (lipo_max_mem_reached): Use new dump framework. * profile.c (read_profile_edge_counts): Ditto. (compute_branch_probabilities): Ditto. * value-prof.c (check_counter): Ditto. (check_ic_counter): Ditto. (find_func_by_funcdef_no): Ditto. (check_ic_target): Ditto. (gimple_ic_transform_mult_targ): Ditto. * mcf.c (find_minimum_cost_flow): Ditto. * coverage.c (incompatible_cl_args): Ditto. (read_counts_file): Ditto. (get_coverage_counts): Ditto. (coverage_init): Setup new dump framework. * common.opt (flag_ripa_verbose): Remove. * params.def (PARAM_INLINE_DUMP_MODULE_ID): Enable by default. * dumpfile.h (OPTGROUP_OTHER): Add and enable under OPTGROUP_ALL. * passes.c (register_one_dump_file): Use OPTGROUP_OTHER when pass not in any opt group. * doc/invoke.texi: Document optall -fopt-info flag. * testsuite/gcc.dg/pr32773.c: Use -fopt-info. * testsuite/gcc.dg/pr40209.c: Ditto. * testsuite/gcc.dg/pr26570.c: Ditto. * testsuite/gcc.dg/tree-prof/lipo/lipo_inline1_0.c: Ditto. * testsuite/g++.dg/tree-ssa/dom-invalid.C: Ditto. Index: coverage.c === --- coverage.c (revision 200845) +++ coverage.c (working copy) @@ -48,6 +48,7 @@ along with GCC; see the file COPYING3. If not see #include opts.h #include gcov-io.h #include tree-flow.h +#include tree-pass.h #include cpplib.h #include incpath.h #include diagnostic-core.h @@ -411,14 +412,18 @@ incompatible_cl_args (struct gcov_module_info* mod warning (OPT_Wripa_opt_mismatch,
[PATCH] fix generic std::atomicT::compare_exchange_{weak,strong}
Compiling the test program:
#include atomic
enum x { a, b };
std::atomicx v;
bool test_strong()
{
x expected = a;
return v.compare_exchange_strong(expected, b, std::memory_order_acq_rel);
}
bool test_weak()
{
x expected = a;
return v.compare_exchange_weak(expected, b, std::memory_order_acq_rel);
}
results in mysterious errors:
In file included from /home/froydnj/mini-atomic-bug.cpp:1:0:
/usr/include/c++/4.7/atomic: In function ‘bool test_strong()’:
/usr/include/c++/4.7/atomic:259:69: error: invalid failure memory model for
‘__atomic_compare_exchange’
/usr/include/c++/4.7/atomic: In function ‘bool test_weak()’:
/usr/include/c++/4.7/atomic:235:68: error: invalid failure memory model for
‘__atomic_compare_exchange’
as the generic std::atomicT versions of compare_exchange_strong and
compare_exchange_weak do not call __cmpexch_failure_order.
This patch corrects that oversight. Tested on x86_64-unknown-linux-gnu.
OK to commit to trunk and active branches?
-Nathan
* include/std/atomic (compare_exchange_weak, compare_exchange_strong):
Add call to __cmpexch_failure_order.
diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index ac2cb45..a822d0f 100644
diff --git a/libstdc++-v3/include/std/atomic b/libstdc++-v3/include/std/atomic
index 813f574..2d66729 100644
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -252,12 +252,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
bool
compare_exchange_weak(_Tp __e, _Tp __i,
memory_order __m = memory_order_seq_cst) noexcept
- { return compare_exchange_weak(__e, __i, __m, __m); }
+ { return compare_exchange_weak(__e, __i, __m,
+ __cmpexch_failure_order(__m)); }
bool
compare_exchange_weak(_Tp __e, _Tp __i,
memory_order __m = memory_order_seq_cst) volatile noexcept
- { return compare_exchange_weak(__e, __i, __m, __m); }
+ { return compare_exchange_weak(__e, __i, __m,
+ __cmpexch_failure_order(__m)); }
bool
compare_exchange_strong(_Tp __e, _Tp __i, memory_order __s,
@@ -276,12 +278,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
bool
compare_exchange_strong(_Tp __e, _Tp __i,
memory_order __m = memory_order_seq_cst) noexcept
- { return compare_exchange_strong(__e, __i, __m, __m); }
+ { return compare_exchange_strong(__e, __i, __m,
+ __cmpexch_failure_order(__m)); }
bool
compare_exchange_strong(_Tp __e, _Tp __i,
memory_order __m = memory_order_seq_cst) volatile noexcept
- { return compare_exchange_strong(__e, __i, __m, __m); }
+ { return compare_exchange_strong(__e, __i, __m,
+ __cmpexch_failure_order(__m)); }
};
Re: [PATCH] fix generic std::atomicT::compare_exchange_{weak,strong}
Hi,
Nathan Froyd nfr...@mozilla.com ha scritto:
Compiling the test program:
#include atomic
enum x { a, b };
std::atomicx v;
bool test_strong()
{
x expected = a;
return v.compare_exchange_strong(expected, b,
std::memory_order_acq_rel);
}
bool test_weak()
{
x expected = a;
return v.compare_exchange_weak(expected, b, std::memory_order_acq_rel);
}
In any case, why not adding the testcase?
Paolo
PS: committed: Skip tests for epiphany that make invalid struct layout assumptions
2013-07-26 Joern Rennecke joern.renne...@embecosm.com
* gcc.c-torture/execute/builtins/stpcpy-chk.x: New file.
Index: gcc.c-torture/execute/builtins/stpncpy-chk.x
===
--- gcc.c-torture/execute/builtins/stpncpy-chk.x(revision 0)
+++ gcc.c-torture/execute/builtins/stpncpy-chk.x(working copy)
@@ -0,0 +1,7 @@
+if [istarget epiphany-*-*] {
+# This test assumes the absence of struct padding.
+# to make this true for test4 struct A on epiphany would require
+# __attribute__((packed)) .
+return 1
+}
+return 0
testsuite, committed: use -mshort-calls for epiphany when expecting function name but once
2013-07-26 Joern Rennecke joern.renne...@embecosm.com
* gcc.dg/pr27095.c: For Epiphany, add -mshort-calls.
* gcc.dg/tree-ssa/loop-1.c: Likewise.
Index: gcc.dg/pr27095.c
===
--- gcc.dg/pr27095.c(revision 201267)
+++ gcc.dg/pr27095.c(working copy)
@@ -5,6 +5,9 @@
to the load from the GOT this also contains the name of the function so for
each call the function name would appear twice. */
/* { dg-options -O2 -mno-relax-pic-calls { target mips*-*-* } } */
+/* For epiphany, use -mshort-calls to avoid loading the address in two
+ steps using lowpart and highpart. */
+/* { dg-options -O2 -mshort-calls { target epiphany-*-* } } */
extern void *memset (void *, int, __SIZE_TYPE__);
extern __SIZE_TYPE__ strlen (const char *);
Index: gcc.dg/tree-ssa/loop-1.c
===
--- gcc.dg/tree-ssa/loop-1.c(revision 201267)
+++ gcc.dg/tree-ssa/loop-1.c(working copy)
@@ -2,6 +2,8 @@
/* -mlongcall will cause us to place foo in the CTR register. */
/* { dg-skip-if { powerpc*-*-* } { -mlongcall } { } } */
/* { dg-options -O1 -ftree-loop-ivcanon -funroll-loops
-fdump-tree-ivcanon-details -fdump-tree-cunroll-details -fdump-tree-optimized
} */
+/* { dg-options -O1 -ftree-loop-ivcanon -funroll-loops
-fdump-tree-ivcanon-details -fdump-tree-cunroll-details -fdump-tree-optimized
-mshort-calls {target epiphany-*-*} } */
+
/* On 31-bit S/390 the function address will be stored (once) in the literal
pool,
so scan-assembler-times foo will return 1 even if the loop is fully
unrolled.
testsuite,committed: Disable gcc.dg/torture/pr37868.c / enable gcc.dg/sibcall-6.c for epiphany.
2013-07-26 Joern Rennecke joern.renne...@embecosm.com
* gcc.dg/torture/pr37868.c: Disable for epiphany.
* gcc.dg/sibcall-6.c: Enable for epiphany.
Index: gcc.dg/sibcall-6.c
===
--- gcc.dg/sibcall-6.c (revision 201267)
+++ gcc.dg/sibcall-6.c (working copy)
@@ -6,7 +6,7 @@
Copyright (C) 2002 Free Software Foundation Inc.
Contributed by Andreas Bauer baue...@in.tum.de */
-/* { dg-do run { target i?86-*-* x86_64-*-* s390*-*-* } } */
+/* { dg-do run { target epiphany-*-* i?86-*-* x86_64-*-* s390*-*-* } } */
/* { dg-skip-if { { i?86-*-* x86_64-*-* } { ia32 { ! nonpic } } } {
* } { } } */
/* { dg-options -O2 -foptimize-sibling-calls -fno-ipa-cp } */
Index: gcc.dg/torture/pr37868.c
===
--- gcc.dg/torture/pr37868.c(revision 201267)
+++ gcc.dg/torture/pr37868.c(working copy)
@@ -1,6 +1,6 @@
/* { dg-do run } */
/* { dg-options -fno-strict-aliasing } */
-/* { dg-skip-if unaligned access { sparc*-*-* sh*-*-* tic6x-*-* } * } */
+/* { dg-skip-if unaligned access { epiphany-*-* sparc*-*-* sh*-*-* tic6x-*-*
} * } */
extern void abort (void);
#if (__SIZEOF_INT__ = 2)
Re: [PATCH] fix generic std::atomicT::compare_exchange_{weak,strong}
Sure, I can do that. For maximum effectiveness, it'd be good to have it check
the specializations for atomic, too. Is there something in the libstdc++
testsuite for iterating template instantiations over a list of types, or do I
have to roll the list myself?
Thanks,
-Nathan
- Original Message -
Hi,
Nathan Froyd nfr...@mozilla.com ha scritto:
Compiling the test program:
#include atomic
enum x { a, b };
std::atomicx v;
bool test_strong()
{
x expected = a;
return v.compare_exchange_strong(expected, b,
std::memory_order_acq_rel);
}
bool test_weak()
{
x expected = a;
return v.compare_exchange_weak(expected, b, std::memory_order_acq_rel);
}
In any case, why not adding the testcase?
Paolo
Re: [PATCH] Add atomic type qualifier
Andrew MacLeod amacl...@redhat.com writes: What it doesn't do: * It doesn't implement the C11 expression expansion into atomic built-ins. ie, you can't write: _Atomic int x; x = 0; and have the result be an atomic operation calling __atomic_store (x, 0). How would this work if you want a different memory order? -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: Request to merge Undefined Behavior Sanitizer in
On 07/26/2013 01:33 AM, Andrew Pinski wrote: What does it mean by unsigned-integer-overflow? Unsigned integers never overflow. This is a common misconception. Conversion to an unsigned integer type never has undefined behavior, but unsigned integer arithmetic does. C11 says, If an exceptional condition occurs during the evaluation of an expression (that is, if the result is not mathematically defined or not in the range of representable values for its type), the behavior is undefined. So UINT_MAX+1U has undefined behavior. Jason
Re: [c++-concepts] requires expressions
Makes sense. Jason
Re: [PATCH] Add atomic type qualifier
On 07/26/2013 03:01 PM, Andi Kleen wrote: Andrew MacLeod amacl...@redhat.com writes: What it doesn't do: * It doesn't implement the C11 expression expansion into atomic built-ins. ie, you can't write: _Atomic int x; x = 0; and have the result be an atomic operation calling __atomic_store (x, 0). How would this work if you want a different memory order? The way the standard is defined, any implicit operation like that is seq_cst. If you want something other than seq-cst, you have to explicitly call atomic_store (x, 0, model). C11 also provides all those same atomic routines that c++11 provides for this reason. They just decided to try to implement the c++ atomic templates in the language along the way :-P so it feels very much like c++ atomics... Andrew
Re: [PATCH] fix generic std::atomicT::compare_exchange_{weak,strong}
Hi, On 07/26/2013 08:42 PM, Nathan Froyd wrote: Sure, I can do that. For maximum effectiveness, it'd be good to have it check the specializations for atomic, too. Is there something in the libstdc++ testsuite for iterating template instantiations over a list of types, or do I have to roll the list myself? testsuite/29_atomics already uses testsuite_common_types.h Paolo.
[patch] Fix problem with -fdebug-types-section and template instantiations.
I'm committing this patch to fix a problem with -fdebug-types-section
where some types that have contain nested type templates or member
function templates are given different type signatures in different
compilation units, depending on which instantiations of those members
are contained in the compilation unit. The problem is two-fold:
(1) When moving a type to its own type unit, nested template
instantiations shouldn't appear at all as children of the type in the
type unit. The skeleton declaration tree left behind in the CU,
however, may still need declarations of those instantiations -- for
example, if there's an instantiated member function template, the CU
will need a DW_TAG_subprogram DIE at the top level, with
DW_AT_specification pointing to its declaration inside the skeleton
for the class.
(2) When computing the type signature, we want to ignore
instantiations. For nested instantiated type templates, I solve this
by calling break_out_comdat_types recursively before computing the
type signature instead of later. For instantiated member function
templates, I simply ignore them during the signature computation,
since they don't get moved back to the CU until after the signature
computation.
Bootstrapped and tested with GCC and GDB test suites.
-cary
2013-07-26 Cary Coutant ccout...@google.com
gcc/
* dwarf2out.c (die_checksum_ordered): Don't include template
instantiations in signature.
(is_template_parameter): New function.
(is_template_instantiation): New function.
(generate_skeleton_bottom_up): Don't include template instantiations
in type unit DIE.
(generate_skeleton): Likewise.
(break_out_comdat_types): Move recursive call to break out nested
types earlier.
(prune_unused_types_mark_generic_parms_dies): Call
is_template_parameter.
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 201271)
+++ gcc/dwarf2out.c (working copy)
@@ -3023,6 +3023,7 @@ static void compute_section_prefix (dw_d
static int is_type_die (dw_die_ref);
static int is_comdat_die (dw_die_ref);
static int is_symbol_die (dw_die_ref);
+static inline bool is_template_instantiation (dw_die_ref);
static void assign_symbol_names (dw_die_ref);
static void break_out_includes (dw_die_ref);
static int is_declaration_die (dw_die_ref);
@@ -6077,22 +6078,29 @@ die_checksum_ordered (dw_die_ref die, st
CHECKSUM_ATTR (attrs.at_type);
CHECKSUM_ATTR (attrs.at_friend);
- /* Checksum the child DIEs, except for nested types and member functions. */
+ /* Checksum the child DIEs. */
c = die-die_child;
if (c) do {
dw_attr_ref name_attr;
c = c-die_sib;
name_attr = get_AT (c, DW_AT_name);
-if ((is_type_die (c) || c-die_tag == DW_TAG_subprogram)
- name_attr != NULL)
+if (is_template_instantiation (c))
{
+ /* Ignore instantiations of member type and function templates. */
+ }
+else if (name_attr != NULL
+ (is_type_die (c) || c-die_tag == DW_TAG_subprogram))
+ {
+ /* Use a shallow checksum for named nested types and member
+ functions. */
CHECKSUM_ULEB128 ('S');
CHECKSUM_ULEB128 (c-die_tag);
CHECKSUM_STRING (AT_string (name_attr));
}
else
{
+ /* Use a deep checksum for other children. */
/* Mark this DIE so it gets processed when unmarking. */
if (c-die_mark == 0)
c-die_mark = -1;
@@ -6505,6 +6513,36 @@ is_class_die (dw_die_ref c)
|| c-die_tag == DW_TAG_structure_type);
}
+/* Return non-zero if this DIE is a template parameter. */
+
+static inline bool
+is_template_parameter (dw_die_ref die)
+{
+ switch (die-die_tag)
+{
+case DW_TAG_template_type_param:
+case DW_TAG_template_value_param:
+case DW_TAG_GNU_template_template_param:
+case DW_TAG_GNU_template_parameter_pack:
+ return true;
+default:
+ return false;
+}
+}
+
+/* Return non-zero if this DIE represents a template instantiation. */
+
+static inline bool
+is_template_instantiation (dw_die_ref die)
+{
+ dw_die_ref c;
+
+ if (!is_type_die (die) die-die_tag != DW_TAG_subprogram)
+return false;
+ FOR_EACH_CHILD (die, c, if (is_template_parameter (c)) return true);
+ return false;
+}
+
static char *
gen_internal_sym (const char *prefix)
{
@@ -7064,17 +7102,30 @@ generate_skeleton_bottom_up (skeleton_ch
node.new_die = NULL;
if (is_declaration_die (c))
{
-/* Clone the existing DIE, move the original to the skeleton
- tree (which is in the main CU), and put the clone, with
- all the original's children, where the original came from. */
-dw_die_ref clone = clone_die (c);
-move_all_children (c, clone);
-
-replace_child (c, clone, prev);
-generate_skeleton_ancestor_tree (parent);
-
Re: Request to merge Undefined Behavior Sanitizer in
On Fri, 26 Jul 2013, Jason Merrill wrote: On 07/26/2013 01:33 AM, Andrew Pinski wrote: What does it mean by unsigned-integer-overflow? Unsigned integers never overflow. This is a common misconception. Conversion to an unsigned integer type never has undefined behavior, but unsigned integer arithmetic does. C11 says, If an exceptional condition occurs during the evaluation of an expression (that is, if the result is not mathematically defined or not in the range of representable values for its type), the behavior is undefined. So UINT_MAX+1U has undefined behavior. Uh? C11 also says: A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type. UINT_MAX+1U is mathematically well defined, it is 0U (modulo 2^N), which is in the range. -- Marc Glisse
Re: [GOOGLE] Port remaining -fopt-info messages from google/4_7 (plus dump infrastructure enhancement)
After converting so many more messages to the new dump framework with my previous change, I noticed a bug where the dumper was not always starting a dump message on a new line. The issue is that the dump framework does not always emit the source position info, but that was where the new line was being emitted. Fix below to emit new line even when not emitting the source position info. I will include it in the patch I send to trunk. Passes gcc regression tests. Ok for google branches? 2013-07-26 Teresa Johnson tejohn...@google.com * dumpfile.c (dump_loc): Ensure newline emitted. Index: dumpfile.c === --- dumpfile.c (revision 201268) +++ dumpfile.c (working copy) @@ -269,6 +269,8 @@ dump_loc (int dump_kind, FILE *dfile, source_locat DECL_SOURCE_LINE (current_function_decl), DECL_SOURCE_COLUMN (current_function_decl)); } + else +fprintf (dfile, \n); } /* Dump gimple statement GS with SPC indentation spaces and On Fri, Jul 26, 2013 at 10:18 AM, Teresa Johnson tejohn...@google.com wrote: Thanks. I'll work on a trunk patch to send next week. Teresa On Fri, Jul 26, 2013 at 10:05 AM, Xinliang David Li davi...@google.com wrote: Ok for google branches. Many changes in coverage.c (such as get_coverage_counts) and value-prof.c need to be in trunk too. David On Thu, Jul 25, 2013 at 10:02 AM, Teresa Johnson tejohn...@google.com wrote: This patch ports the remaining -fopt-info messages that had been added to google/gcc-4_7 using the original -fopt-info framework implemented on that branch, to google/gcc-4_8 using the new -fopt-info framework from trunk. Specifically, this ports over the messages added/modified by r180269, r180973 and r195968. Some of these patches/messages were already ported, but this adds the remainder. I converted from the old OPT_INFO_* levels to the new MSG_* levels using the following mapping: OPT_INFO_MIN - MSG_OPTIMIZED_LOCATIONS OPT_INFO_MED - MSG_MISSED_OPTIMIZATION OPT_INFO_MAX - MSG_NOTE The affected messages relate to LIPO module imports, missing/mismatched/ corrupted profile data, and indirect call promotions performed. Additionally, after discussing with Easwaran and Rong, I flipped the default of the inline-dump-module-id parameter to 1 to enable dumping module ids in -fopt-info inlining messages for easier inlining report generation. Finally, I had to make a couple enhancements to the new dump infrastructure to get some of the new messages emitted. This change should be pushed to trunk as it will help facilitate adding new dump messages more easily (particularly number 2 below). There were two issues: 1) The module imports occurred during coverage_init which happens very early, before entering the pass manager that sets up the dumping. This was addressed by enabling dumping within coverage_init, and is modeled on how dumping is enabled after the pass manager during finish_optimization_passes. 2) Dumping was only enabled for passes marked with an optinfo_flag that isn't OPTGROUP_NONE. Currently optgroup flags are only setup for optimization groups in the categories IPA, LOOP, INLINE and VEC. What this means is that any dump messages added to a pass that isn't in one of these groups will silently be suppressed. The OPTGROUP setting is specified in opt_pass struct, and is also automatically set to OPTGROUP_IPA for any pass starting with ipa-. What I did was to add a new optgroup macro, OPTGROUP_OTHER. This is enabled only under -fopt-info-optall, which is also the default for -fopt-info. That way dump messages can be emitted without the requirement that the pass be part of a group that can be emitted under a specific optimization group subset. When setting up the dumps, any pass that has OPTGROUP_NONE after examining the opt_pass struct and the pass name will use OPTGROUP_OTHER. This doesn't mean that the list of optgroups shouldn't be expanded, but rather adds a catch-all for passes that don't currently have or need to be emitted on their own as part of a new optgroup. Bootstrapped and regression tested. Ok for google/4_8? (Attached patch as a file also since pasting below messed up the whitespace formatting.) Thanks, Teresa 2013-07-25 Teresa Johnson tejohn...@google.com * c-family/c-opts.c (lipo_max_mem_reached): Use new dump framework. * profile.c (read_profile_edge_counts): Ditto. (compute_branch_probabilities): Ditto. * value-prof.c (check_counter): Ditto. (check_ic_counter): Ditto. (find_func_by_funcdef_no): Ditto. (check_ic_target): Ditto. (gimple_ic_transform_mult_targ): Ditto. * mcf.c (find_minimum_cost_flow): Ditto. * coverage.c (incompatible_cl_args): Ditto. (read_counts_file): Ditto. (get_coverage_counts): Ditto. (coverage_init): Setup new dump framework.
Re: [GOOGLE] Port remaining -fopt-info messages from google/4_7 (plus dump infrastructure enhancement)
is it better to hoist the newline dump before all the branches? David On Fri, Jul 26, 2013 at 1:06 PM, Teresa Johnson tejohn...@google.com wrote: After converting so many more messages to the new dump framework with my previous change, I noticed a bug where the dumper was not always starting a dump message on a new line. The issue is that the dump framework does not always emit the source position info, but that was where the new line was being emitted. Fix below to emit new line even when not emitting the source position info. I will include it in the patch I send to trunk. Passes gcc regression tests. Ok for google branches? 2013-07-26 Teresa Johnson tejohn...@google.com * dumpfile.c (dump_loc): Ensure newline emitted. Index: dumpfile.c === --- dumpfile.c (revision 201268) +++ dumpfile.c (working copy) @@ -269,6 +269,8 @@ dump_loc (int dump_kind, FILE *dfile, source_locat DECL_SOURCE_LINE (current_function_decl), DECL_SOURCE_COLUMN (current_function_decl)); } + else +fprintf (dfile, \n); } /* Dump gimple statement GS with SPC indentation spaces and On Fri, Jul 26, 2013 at 10:18 AM, Teresa Johnson tejohn...@google.com wrote: Thanks. I'll work on a trunk patch to send next week. Teresa On Fri, Jul 26, 2013 at 10:05 AM, Xinliang David Li davi...@google.com wrote: Ok for google branches. Many changes in coverage.c (such as get_coverage_counts) and value-prof.c need to be in trunk too. David On Thu, Jul 25, 2013 at 10:02 AM, Teresa Johnson tejohn...@google.com wrote: This patch ports the remaining -fopt-info messages that had been added to google/gcc-4_7 using the original -fopt-info framework implemented on that branch, to google/gcc-4_8 using the new -fopt-info framework from trunk. Specifically, this ports over the messages added/modified by r180269, r180973 and r195968. Some of these patches/messages were already ported, but this adds the remainder. I converted from the old OPT_INFO_* levels to the new MSG_* levels using the following mapping: OPT_INFO_MIN - MSG_OPTIMIZED_LOCATIONS OPT_INFO_MED - MSG_MISSED_OPTIMIZATION OPT_INFO_MAX - MSG_NOTE The affected messages relate to LIPO module imports, missing/mismatched/ corrupted profile data, and indirect call promotions performed. Additionally, after discussing with Easwaran and Rong, I flipped the default of the inline-dump-module-id parameter to 1 to enable dumping module ids in -fopt-info inlining messages for easier inlining report generation. Finally, I had to make a couple enhancements to the new dump infrastructure to get some of the new messages emitted. This change should be pushed to trunk as it will help facilitate adding new dump messages more easily (particularly number 2 below). There were two issues: 1) The module imports occurred during coverage_init which happens very early, before entering the pass manager that sets up the dumping. This was addressed by enabling dumping within coverage_init, and is modeled on how dumping is enabled after the pass manager during finish_optimization_passes. 2) Dumping was only enabled for passes marked with an optinfo_flag that isn't OPTGROUP_NONE. Currently optgroup flags are only setup for optimization groups in the categories IPA, LOOP, INLINE and VEC. What this means is that any dump messages added to a pass that isn't in one of these groups will silently be suppressed. The OPTGROUP setting is specified in opt_pass struct, and is also automatically set to OPTGROUP_IPA for any pass starting with ipa-. What I did was to add a new optgroup macro, OPTGROUP_OTHER. This is enabled only under -fopt-info-optall, which is also the default for -fopt-info. That way dump messages can be emitted without the requirement that the pass be part of a group that can be emitted under a specific optimization group subset. When setting up the dumps, any pass that has OPTGROUP_NONE after examining the opt_pass struct and the pass name will use OPTGROUP_OTHER. This doesn't mean that the list of optgroups shouldn't be expanded, but rather adds a catch-all for passes that don't currently have or need to be emitted on their own as part of a new optgroup. Bootstrapped and regression tested. Ok for google/4_8? (Attached patch as a file also since pasting below messed up the whitespace formatting.) Thanks, Teresa 2013-07-25 Teresa Johnson tejohn...@google.com * c-family/c-opts.c (lipo_max_mem_reached): Use new dump framework. * profile.c (read_profile_edge_counts): Ditto. (compute_branch_probabilities): Ditto. * value-prof.c (check_counter): Ditto. (check_ic_counter): Ditto. (find_func_by_funcdef_no): Ditto. (check_ic_target): Ditto. (gimple_ic_transform_mult_targ): Ditto. * mcf.c (find_minimum_cost_flow): Ditto. *
Re: [PATCH] Add atomic type qualifier
On Fri, 26 Jul 2013, Andrew MacLeod wrote: This patch adds an atomic type qualifier to GCC. It can be accessed via __attribute__((atomic)) or in C11 mode via the _Atomic keyword. HP, you might want to give this a try and see if you can get the alignment correct for the cris port finally :-) Looks like the means to that end are there now. Thanks! Though I won't be able to look into it for a while. (Looking at two more weeks of vacation and likely a hectic period after that.) Note to self (mostly): also implement target-specific warning when the layout of a composite type including an atomic (naturally aligned) type would differ from normal (unaligned; packed) layout. brgds, H-P
Re: [testsuite, android] Disabling thread_local4.C and thread_local4g.C for Android.
On 27/07/2013, at 12:17 AM, Alexander Ivchenko wrote: Maxim, thank you for your input! That's for sure a better solution. __BIONIC__ is not defined in features.h so I had to change the include to ctype.h. (__BIONIC__ is defined in sys/ctypes.h, but it's not safe to include that directly..) tested on x86_64_unknow_linux and on android device. Is it OK? OK. Thanks, -- Maxim Kuvyrkov www.kugelworks.com
Re: [Patch, Fortran] PR57530 (Part 2 of 3) Support TYPE = CLASS
Hi Tobias, This patch is a follow up to the resolve part, which permits TYPE=CLASS. That approved patch is at http://gcc.gnu.org/ml/fortran/2013-06/msg00049.html (I didn't want to commit it without this trans*.c patch.) The attached patch adds support for: TYPE = CLASS additionally, it fixes some issues with CLASS = CLASS where the RHS is a polymorphic array function. Plus an issue with TYPE = TYPE where the LHS does rank remapping and the RHS is a function. Unfortunately, the patch is a bit messier than I had hoped for. Built and regtested on x86-64-gnu-linux. OK for the trunk? yes, the patch looks basically ok to me. Just one thing I did not quite understand: @@ -6485,8 +6491,14 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gfc_expr * expr2) build_int_cst (gfc_charlen_type_node, 0)); } + /* It can happen that the LHS has BT_DERIVED but it is in reality + a polymorphic variable. */ + if (expr1-ts.type == BT_DERIVED expr2-ts.type == BT_CLASS + !gfc_is_class_scalar_expr (expr1)) +rse.expr = gfc_class_data_get (rse.expr); + gfc_add_modify (block, lse.expr, - fold_convert (TREE_TYPE (lse.expr), rse.expr)); + fold_convert (TREE_TYPE (lse.expr), rse.expr)); gfc_add_block_to_block (block, rse.post); gfc_add_block_to_block (block, lse.post); How exactly can it happen that a polymorphic variable is BT_DERIVED? Cheers, Janus
[Patch, Fortran, OOP] PR 57306: ICE on valid with class pointer initialization
Hi all, here is a fix for class pointer initialization. The problem was that 'gfc_get_symbol_decl' did not recognize class pointers properly. The first version of the patch posted in the PR induced problems with NULL initialization of class pointers, which are fixed by the attached second version. Regtested on x86_64-unknown-linux-gnu. Ok for trunk? Cheers, Janus 2013-07-26 Janus Weil ja...@gcc.gnu.org PR fortran/57306 * trans-decl.c (gfc_get_symbol_decl): Treat class pointers. * trans-expr.c (gfc_conv_initializer): Ditto. 2013-07-26 Janus Weil ja...@gcc.gnu.org PR fortran/57306 * gfortran.dg/pointer_init_8.f90: New. pr57306_v2.diff Description: Binary data pointer_init_8.f90 Description: Binary data
Re: [PATCH] Add atomic type qualifier
Andrew MacLeod amacl...@redhat.com writes: The way the standard is defined, any implicit operation like that is seq_cst. If you want something other than seq-cst, you have to explicitly call atomic_store (x, 0, model). Thanks. This doesn't sound like a good default for x86. seq_cst requires somewhat expensive extra barriers that most people most likely don't need. -Andi -- a...@linux.intel.com -- Speaking for myself only
Re: [GOOGLE] Port remaining -fopt-info messages from google/4_7 (plus dump infrastructure enhancement)
Yes, and in fact I moved it inside the check for if (dump_kind)
since we wouldn't be emitting any message if that is null (in practice
all the callers of dump_loc check this too).
I don't really like the fact that the newline is being emitted for all
messages emitted via the _loc versions of the dumper, and not for
the non-loc counterparts. But it looks like various callers already
rely on this and cleaning it up will take more time.
Removed a stale comment while here. New patch:
2013-07-26 Teresa Johnson tejohn...@google.com
* dumpfile.c (dump_loc): Ensure newline emitted.
Index: dumpfile.c
===
--- dumpfile.c (revision 201268)
+++ dumpfile.c (working copy)
@@ -257,14 +257,15 @@ dump_open_alternate_stream (struct dump_file_info
void
dump_loc (int dump_kind, FILE *dfile, source_location loc)
{
- /* Currently vectorization passes print location information. */
if (dump_kind)
{
+ /* Ensure dump message starts on a new line. */
+ fprintf (dfile, \n);
if (LOCATION_LOCUS (loc) BUILTINS_LOCATION)
-fprintf (dfile, \n%s:%d:%d: note: , LOCATION_FILE (loc),
+fprintf (dfile, %s:%d:%d: note: , LOCATION_FILE (loc),
LOCATION_LINE (loc), LOCATION_COLUMN (loc));
else if (current_function_decl)
-fprintf (dfile, \n%s:%d:%d: note: ,
+fprintf (dfile, %s:%d:%d: note: ,
DECL_SOURCE_FILE (current_function_decl),
DECL_SOURCE_LINE (current_function_decl),
DECL_SOURCE_COLUMN (current_function_decl));
Teresa
On Fri, Jul 26, 2013 at 1:16 PM, Xinliang David Li davi...@google.com wrote:
is it better to hoist the newline dump before all the branches?
David
On Fri, Jul 26, 2013 at 1:06 PM, Teresa Johnson tejohn...@google.com wrote:
After converting so many more messages to the new dump framework with my
previous change, I noticed a bug where the dumper was not always starting
a dump message on a new line. The issue is that the dump framework does
not always emit the source position info, but that was where the new line
was being emitted. Fix below to emit new line even when not emitting the
source position info. I will include it in the patch I send to trunk.
Passes gcc regression tests. Ok for google branches?
2013-07-26 Teresa Johnson tejohn...@google.com
* dumpfile.c (dump_loc): Ensure newline emitted.
Index: dumpfile.c
===
--- dumpfile.c (revision 201268)
+++ dumpfile.c (working copy)
@@ -269,6 +269,8 @@ dump_loc (int dump_kind, FILE *dfile, source_locat
DECL_SOURCE_LINE (current_function_decl),
DECL_SOURCE_COLUMN (current_function_decl));
}
+ else
+fprintf (dfile, \n);
}
/* Dump gimple statement GS with SPC indentation spaces and
On Fri, Jul 26, 2013 at 10:18 AM, Teresa Johnson tejohn...@google.com
wrote:
Thanks. I'll work on a trunk patch to send next week. Teresa
On Fri, Jul 26, 2013 at 10:05 AM, Xinliang David Li davi...@google.com
wrote:
Ok for google branches. Many changes in coverage.c (such as
get_coverage_counts) and value-prof.c need to be in trunk too.
David
On Thu, Jul 25, 2013 at 10:02 AM, Teresa Johnson tejohn...@google.com
wrote:
This patch ports the remaining -fopt-info messages that had been added
to google/gcc-4_7 using the original -fopt-info framework implemented
on that branch, to google/gcc-4_8 using the new -fopt-info framework
from trunk.
Specifically, this ports over the messages added/modified by r180269,
r180973 and r195968. Some of these patches/messages were already ported,
but this adds the remainder. I converted from the old OPT_INFO_* levels
to the new MSG_* levels using the following mapping:
OPT_INFO_MIN - MSG_OPTIMIZED_LOCATIONS
OPT_INFO_MED - MSG_MISSED_OPTIMIZATION
OPT_INFO_MAX - MSG_NOTE
The affected messages relate to LIPO module imports, missing/mismatched/
corrupted profile data, and indirect call promotions performed.
Additionally, after discussing with Easwaran and Rong, I flipped the
default of the inline-dump-module-id parameter to 1 to enable dumping
module ids in -fopt-info inlining messages for easier inlining
report generation.
Finally, I had to make a couple enhancements to the new dump
infrastructure
to get some of the new messages emitted. This change should be
pushed to trunk as it will help facilitate adding new dump messages
more easily (particularly number 2 below). There were two issues:
1) The module imports occurred during coverage_init which happens
very early, before entering the pass manager that sets up the dumping.
This was addressed by enabling dumping within coverage_init, and
is modeled on how dumping is enabled after the pass manager
during finish_optimization_passes.
2) Dumping was only enabled for passes marked with an optinfo_flag
Re: [GOOGLE] Port remaining -fopt-info messages from google/4_7 (plus dump infrastructure enhancement)
ok.
thanks,
David
On Fri, Jul 26, 2013 at 2:14 PM, Teresa Johnson tejohn...@google.com wrote:
Yes, and in fact I moved it inside the check for if (dump_kind)
since we wouldn't be emitting any message if that is null (in practice
all the callers of dump_loc check this too).
I don't really like the fact that the newline is being emitted for all
messages emitted via the _loc versions of the dumper, and not for
the non-loc counterparts. But it looks like various callers already
rely on this and cleaning it up will take more time.
Removed a stale comment while here. New patch:
2013-07-26 Teresa Johnson tejohn...@google.com
* dumpfile.c (dump_loc): Ensure newline emitted.
Index: dumpfile.c
===
--- dumpfile.c (revision 201268)
+++ dumpfile.c (working copy)
@@ -257,14 +257,15 @@ dump_open_alternate_stream (struct dump_file_info
void
dump_loc (int dump_kind, FILE *dfile, source_location loc)
{
- /* Currently vectorization passes print location information. */
if (dump_kind)
{
+ /* Ensure dump message starts on a new line. */
+ fprintf (dfile, \n);
if (LOCATION_LOCUS (loc) BUILTINS_LOCATION)
-fprintf (dfile, \n%s:%d:%d: note: , LOCATION_FILE (loc),
+fprintf (dfile, %s:%d:%d: note: , LOCATION_FILE (loc),
LOCATION_LINE (loc), LOCATION_COLUMN (loc));
else if (current_function_decl)
-fprintf (dfile, \n%s:%d:%d: note: ,
+fprintf (dfile, %s:%d:%d: note: ,
DECL_SOURCE_FILE (current_function_decl),
DECL_SOURCE_LINE (current_function_decl),
DECL_SOURCE_COLUMN (current_function_decl));
Teresa
On Fri, Jul 26, 2013 at 1:16 PM, Xinliang David Li davi...@google.com wrote:
is it better to hoist the newline dump before all the branches?
David
On Fri, Jul 26, 2013 at 1:06 PM, Teresa Johnson tejohn...@google.com wrote:
After converting so many more messages to the new dump framework with my
previous change, I noticed a bug where the dumper was not always starting
a dump message on a new line. The issue is that the dump framework does
not always emit the source position info, but that was where the new line
was being emitted. Fix below to emit new line even when not emitting the
source position info. I will include it in the patch I send to trunk.
Passes gcc regression tests. Ok for google branches?
2013-07-26 Teresa Johnson tejohn...@google.com
* dumpfile.c (dump_loc): Ensure newline emitted.
Index: dumpfile.c
===
--- dumpfile.c (revision 201268)
+++ dumpfile.c (working copy)
@@ -269,6 +269,8 @@ dump_loc (int dump_kind, FILE *dfile, source_locat
DECL_SOURCE_LINE (current_function_decl),
DECL_SOURCE_COLUMN (current_function_decl));
}
+ else
+fprintf (dfile, \n);
}
/* Dump gimple statement GS with SPC indentation spaces and
On Fri, Jul 26, 2013 at 10:18 AM, Teresa Johnson tejohn...@google.com
wrote:
Thanks. I'll work on a trunk patch to send next week. Teresa
On Fri, Jul 26, 2013 at 10:05 AM, Xinliang David Li davi...@google.com
wrote:
Ok for google branches. Many changes in coverage.c (such as
get_coverage_counts) and value-prof.c need to be in trunk too.
David
On Thu, Jul 25, 2013 at 10:02 AM, Teresa Johnson tejohn...@google.com
wrote:
This patch ports the remaining -fopt-info messages that had been added
to google/gcc-4_7 using the original -fopt-info framework implemented
on that branch, to google/gcc-4_8 using the new -fopt-info framework
from trunk.
Specifically, this ports over the messages added/modified by r180269,
r180973 and r195968. Some of these patches/messages were already ported,
but this adds the remainder. I converted from the old OPT_INFO_* levels
to the new MSG_* levels using the following mapping:
OPT_INFO_MIN - MSG_OPTIMIZED_LOCATIONS
OPT_INFO_MED - MSG_MISSED_OPTIMIZATION
OPT_INFO_MAX - MSG_NOTE
The affected messages relate to LIPO module imports, missing/mismatched/
corrupted profile data, and indirect call promotions performed.
Additionally, after discussing with Easwaran and Rong, I flipped the
default of the inline-dump-module-id parameter to 1 to enable dumping
module ids in -fopt-info inlining messages for easier inlining
report generation.
Finally, I had to make a couple enhancements to the new dump
infrastructure
to get some of the new messages emitted. This change should be
pushed to trunk as it will help facilitate adding new dump messages
more easily (particularly number 2 below). There were two issues:
1) The module imports occurred during coverage_init which happens
very early, before entering the pass manager that sets up the dumping.
This was addressed by enabling dumping within coverage_init, and
is modeled on how dumping is enabled
Re: [PATCH] Add atomic type qualifier
On 07/26/2013 05:13 PM, Andi Kleen wrote: Andrew MacLeod amacl...@redhat.com writes: The way the standard is defined, any implicit operation like that is seq_cst. If you want something other than seq-cst, you have to explicitly call atomic_store (x, 0, model). Thanks. This doesn't sound like a good default for x86. seq_cst requires somewhat expensive extra barriers that most people most likely don't need. Its the only truly safe default for a multi-threaded environment. These are the same defaults you get with C++11 as well if you don't explicitly use a memory model in your atomic operations: ie __int_type load(memory_order __m = memory_order_seq_cst) const noexcept So if you don't want seq-cst, you need to specify exactly what you do want. Andrew
Re: Request to merge Undefined Behavior Sanitizer in
On 07/26/2013 04:00 PM, Marc Glisse wrote: C11 also says: A computation involving unsigned operands can never overflow, because a result that cannot be represented by the resulting unsigned integer type is reduced modulo the number that is one greater than the largest value that can be represented by the resulting type. Ah, so it does. I agree that takes priority, though it would be nice to clarify the passage I quoted... Jason
Re: [PATCH] fix generic std::atomicT::compare_exchange_{weak,strong}
- Original Message -
On 07/26/2013 08:42 PM, Nathan Froyd wrote:
Sure, I can do that. For maximum effectiveness, it'd be good to have it
check the specializations for atomic, too. Is there something in the
libstdc++ testsuite for iterating template instantiations over a list of
types, or do I have to roll the list myself?
testsuite/29_atomics already uses testsuite_common_types.h
New patch, this time with tests. Let me know if test placement, etc. need
adjusting.
Tested on x86_64-unknown-linux-gnu. OK for commit to trunk and active branches?
-Nathan
* include/std/atomic (compare_exchange_weak, compare_exchange_strong):
Add call to __cmpexch_failure_order.
* testsuite/util/testsuite_common_types.h
(compare_exchange_order_lowering): New generator.
* testsuite/29_atomics/atomic/requirements/compare_exchange_lowering.cc:
New test.
diff --git a/libstdc++-v3/ChangeLog b/libstdc++-v3/ChangeLog
index ac2cb45..3b79d91 100644
diff --git a/libstdc++-v3/include/std/atomic b/libstdc++-v3/include/std/atomic
index 813f574..2d66729 100644
--- a/libstdc++-v3/include/std/atomic
+++ b/libstdc++-v3/include/std/atomic
@@ -252,12 +252,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
bool
compare_exchange_weak(_Tp __e, _Tp __i,
memory_order __m = memory_order_seq_cst) noexcept
- { return compare_exchange_weak(__e, __i, __m, __m); }
+ { return compare_exchange_weak(__e, __i, __m,
+ __cmpexch_failure_order(__m)); }
bool
compare_exchange_weak(_Tp __e, _Tp __i,
memory_order __m = memory_order_seq_cst) volatile noexcept
- { return compare_exchange_weak(__e, __i, __m, __m); }
+ { return compare_exchange_weak(__e, __i, __m,
+ __cmpexch_failure_order(__m)); }
bool
compare_exchange_strong(_Tp __e, _Tp __i, memory_order __s,
@@ -276,12 +278,14 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
bool
compare_exchange_strong(_Tp __e, _Tp __i,
memory_order __m = memory_order_seq_cst) noexcept
- { return compare_exchange_strong(__e, __i, __m, __m); }
+ { return compare_exchange_strong(__e, __i, __m,
+ __cmpexch_failure_order(__m)); }
bool
compare_exchange_strong(_Tp __e, _Tp __i,
memory_order __m = memory_order_seq_cst) volatile noexcept
- { return compare_exchange_strong(__e, __i, __m, __m); }
+ { return compare_exchange_strong(__e, __i, __m,
+ __cmpexch_failure_order(__m)); }
};
diff --git
a/libstdc++-v3/testsuite/29_atomics/atomic/requirements/compare_exchange_lowering.cc
b/libstdc++-v3/testsuite/29_atomics/atomic/requirements/compare_exchange_lowering.cc
new file mode 100644
index 000..75e7406
--- /dev/null
+++
b/libstdc++-v3/testsuite/29_atomics/atomic/requirements/compare_exchange_lowering.cc
@@ -0,0 +1,65 @@
+// { dg-options -std=gnu++0x }
+// { dg-do compile }
+
+// Copyright (C) 2008-2013 Free Software Foundation, Inc.
+//
+// This file is part of the GNU ISO C++ Library. This library is free
+// software; you can redistribute it and/or modify it under the
+// terms of the GNU General Public License as published by the
+// Free Software Foundation; either version 3, or (at your option)
+// any later version.
+
+// This library is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+// GNU General Public License for more details.
+
+// You should have received a copy of the GNU General Public License along
+// with this library; see the file COPYING3. If not see
+// http://www.gnu.org/licenses/.
+
+#include atomic
+#include testsuite_common_types.h
+
+#define TEST_ALL_ORDERS() \
+ do { \
+ORDER_TEST(std::memory_order_relaxed); \
+ORDER_TEST(std::memory_order_consume); \
+ORDER_TEST(std::memory_order_acquire); \
+ORDER_TEST(std::memory_order_release); \
+ORDER_TEST(std::memory_order_acq_rel); \
+ORDER_TEST(std::memory_order_seq_cst); \
+ } while(0)
+
+void test01()
+{
+#define ORDER_TEST(ORDER) \
+ do { \
+__gnu_test::compare_exchange_order_loweringORDER test;\
+__gnu_cxx::typelist::apply_generator(test, \
+ __gnu_test::integral_types::type()); \
+ } while (0);
+ TEST_ALL_ORDERS();
+#undef ORDER_TEST
+
+ enum e { a, b, c };
+#define ORDER_TEST(ORDER) \
+ do { \
+std::atomice x(a);
Re: [patch] implement Cilk Plus simd loops on trunk
On 07/26/2013 11:46 AM, Aldy Hernandez wrote: How's this? What branch is this supposed to apply to? Jason
Re: [PATCH] Add atomic type qualifier
On Fri, 26 Jul 2013, Andrew MacLeod wrote: This patch adds an atomic type qualifier to GCC. It can be accessed via __attribute__((atomic)) or in C11 mode via the _Atomic keyword. Why the attribute - why not just the keyword? I'll review the patch in detail later (which will involve checking each reference to atomic or qualified in the language part of C11, checking for appropriate implementation and complaining if it appears to be missing, and checking for appropriate testcases and complaining if those appear to be missing). But some comments now: * pedwarns for using a C11 feature in previous standard modes should as per usual practice be pedwarns-if-pedantic. * I don't see anything obvious in the parser changes to implement the _Atomic ( type-name ) version of the syntax for atomic types (6.7.2.4). * When C11 refers to qualified types, by default it does not include atomic types (6.2.5#27). What's your rationale for including atomic in TYPE_QUALS rather than making it separate? With either approach, a review of every reference to qualifiers in the front end is needed to determine what's correct for atomic; did you find that including atomic in qualifiers in the implementation made for fewer changes? -- Joseph S. Myers jos...@codesourcery.com
[PATCH v4] MIPS: IEEE 754-2008 features support
On Fri, 19 Jul 2013, Richard Sandiford wrote:
while the 2008
NaN encoding has its shortcomings, e.g. unlike with the legacy encoding
there's no single sNaN bit pattern to preset FPRs or variables with to
catch uninitialised use that would work across all the floating-point
formats (S, D and PS). So it seems to me like there's no single superior
setting we could make the default for a group option.
I see what you mean, and I suppose it wouldn't be too bad having
separate -mabs=2008 and -mmac=2008 options for the legacy IEEE case.
But when going to the trouble of switching NAN encoding, which needs a
separate runtime, it seemed a shame that we couldn't also rely on the
new improved ABS/NEG behaviour in that runtime too. Instead we have
to potentially pass all three of -mnan=2008 -mabs=2008 -mmac=2008
in order to get what other targets get. Oh well...
I think the current situation does not preclude adding your proposed
-mfp-model={legacy|2008} option in the future, especially if
-mmac={legacy|2008} is eventually implemented, however I also think we
ought to consider a valid use case first.
1. Conceptually I see the toolchain as a whole and I don't see a value in
GCC producing known-unsupported assembly and relying on the assembler
(or the linker if applicable) to complain. I agree pointing at the
other tool being incapable or obsolete is a useful practice, but I also
think a clear message from GCC itself would be more appropriate (e.g.
`-mfoo' unsupported, please reconfigure against current binutils).
But doing that consistently would mean e.g. that we would need to test
assembler support for each individual -march= option, since new -march=
options are added fairly often. It seems a lot of hassle to do that
just so that we can force the user to rebuild GCC from the same sources
as before. I think it's more user-friendly to include support for -mfoo
and assume that the assembler supports whatever's needed -- leaving it
to issue an error if not -- both because the problem tool is the one that
reports the error, and because we don't force users to rebuild GCC when
the first build could quite easily have had the feature they wanted.
Yes, I have to admit that it is a bit inconvenient.
2. Technically I think we have an actual problem here, e.g. in the example
you referred we have a situation where GCC supports microMIPS
compilation in all cases, however non-microMIPS code is different
depending on whether the compiler has been configured against modern or
obsolete binutils. Now the latter case may prompt someone to upgrade
binutils, but there is nothing to prompt that person to reconfigure GCC
afterwards. As a result we have two cases of a toolchain comprised of
the same versions of both GCC and binutils, but depending on the
history of the GCC binaries code produced will be different. I think
this is subtler and riskier than just rejecting the relevant compiler
option outright.
I think your argument is that it's bad for things like
__attribute__((nomicromips)) to produce different code depending on the
configured assembler, and that we should therefore just reject the attribute
if the assembler doesn't support .set nomicromips. Is that right?
No, __attribute__((nomicromips)) is a no-op if applied to source compiled
to standard MIPS or MIPS16 code and following the principle I support here
a compiler configured against a non-microMIPS assembler by definition
could not be switched into the microMIPS mode. Therefore the attribute
can simply be silently ignored.
That has negative consequences too though. People often use GCC version
checks to decide whether an attribute is supported. Conditionally
disabling even nomicromips would force users to have an autoconf-style
test instead. And the point is that __attribute__((nomicromips))
indicates that the user _doesn't_ want a function to be micromips,
so it wouldn't be very friendly to force them to upgrade to a binutils
that does support micromips and then rebuild GCC.
I consider actual feature tests always preferable to version checks.
Instead the idea is that __attribute__((nomicromips)) should behave in
the same way as when nomicromips is the default.
Applying this to the 2008-NaN case the compiler would have to refrain from
producing the .nan directive in the legacy case if built against old
binutils but would produce the directive regardless in the 2008 case. I
don't feel safe with such an arrangement.
Hmm, I think you're arguing against something different from what I was
suggesting. I was saying that (within config/mips) the configure test
should just control whether it's safe to use .nan _when no -mnan option
has been given_. (I.e. it shouldn't affect the case when -mnan is passed.)
If no option is given, we should put a .nan legacy in there anyway for
good measure
Re: [patch] implement Cilk Plus simd loops on trunk
On 07/26/2013 11:46 AM, Aldy Hernandez wrote: + Upon return, *INITP will contain the initialization expression, + *DECLP will contain the induction variable. + + *REAL_DECLP + *FOR_BLOCK */ DECLP is a variable declared in the for-init, if any. REAL_DECLP is the induction variable. FOR_BLOCK is a bit puzzling. It seems to be a collection of initializations for class induction variables, but it gets add_stmted outside the OMP loop context, and that strikes me as wrong; shouldn't it end up in pre_body? Jakub, can you elaborate on how this works? Jason
Re: [PATCH] fix generic std::atomicT::compare_exchange_{weak,strong}
Hi, On 07/27/2013 01:07 AM, Nathan Froyd wrote: - Original Message - On 07/26/2013 08:42 PM, Nathan Froyd wrote: Sure, I can do that. For maximum effectiveness, it'd be good to have it check the specializations for atomic, too. Is there something in the libstdc++ testsuite for iterating template instantiations over a list of types, or do I have to roll the list myself? testsuite/29_atomics already uses testsuite_common_types.h New patch, this time with tests. Let me know if test placement, etc. need adjusting. Patch looks great, Ok to commit. Minor nits: in the testcase we want only 2013 as Copyright year and let's standardize on -std=gnu++11. Thanks, Paolo.
Re: [PATCH] Add atomic type qualifier
On 07/26/2013 07:21 PM, Joseph S. Myers wrote: On Fri, 26 Jul 2013, Andrew MacLeod wrote: This patch adds an atomic type qualifier to GCC. It can be accessed via __attribute__((atomic)) or in C11 mode via the _Atomic keyword. Why the attribute - why not just the keyword? 2 reasons: 1 - we currently have at least one target who cannot express their alignment requirements for an atomic value (ie, a short with 4 byte alignment). Use of__attribute((atomic)) will allow proper expression and usage within the atomic built-ins without using C11. 2 - compatibility with C11 and C++11. Ultimately, the atomic object can be upsized (ie,a 6 byte object sized up to be 8 bytes). _Atomic would do that for C11, but we cant really use _Atomic within the c++11 template files, so __attribute__((atomic)) seemed pretty natural. As well, this will allow c++ atomic templates to work on aforementioned target(s). I'll review the patch in detail later (which will involve checking each reference to atomic or qualified in the language part of C11, checking for appropriate implementation and complaining if it appears to be missing, and checking for appropriate testcases and complaining if those appear to be missing). But some comments now: * pedwarns for using a C11 feature in previous standard modes should as per usual practice be pedwarns-if-pedantic. * I don't see anything obvious in the parser changes to implement the _Atomic ( type-name ) version of the syntax for atomic types (6.7.2.4). * When C11 refers to qualified types, by default it does not include atomic types (6.2.5#27). What's your rationale for including atomic in TYPE_QUALS rather than making it separate? With either approach, a review of every reference to qualifiers in the front end is needed to determine what's correct for atomic; did you find that including atomic in qualifiers in the implementation made for fewer changes? I'm not good at front ends... don't really know them at all. Parsing and syntax and semantics scare me. This was my initial attempt to enable _Atomic and hoped for help with the rest from those who do :-) observation and changes welcome. Andrew
Re: [PATCH] Fix the bug to check if lookup_stmt_eh_lp returns positive instead of non-zero
ping^2
Thanks,
Dehao
On Tue, Jul 16, 2013 at 5:40 PM, Dehao Chen de...@google.com wrote:
ping...
Thanks,
Dehao
On Mon, Jul 8, 2013 at 5:55 PM, Dehao Chen de...@google.com wrote:
In lookup_stmt_eh_lp, negative return value indicates a MUST_NOT_THROW
region index. In this case, we should *not* add an EH edge during VPT.
Bootstrapped and passed regression test.
OK for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2013-07-08 Dehao Chen (de...@google.com)
* value-prof.c (gimple_ic): Fix the bug of adding EH edge.
Index: gcc/value-prof.c
===
--- gcc/value-prof.c (revision 200375)
+++ gcc/value-prof.c (working copy)
@@ -1359,8 +1359,7 @@ gimple_ic (gimple icall_stmt, struct cgraph_node *
/* Build an EH edge for the direct call if necessary. */
lp_nr = lookup_stmt_eh_lp (icall_stmt);
- if (lp_nr != 0
- stmt_could_throw_p (dcall_stmt))
+ if (lp_nr 0 stmt_could_throw_p (dcall_stmt))
{
edge e_eh, e;
edge_iterator ei;
Re: [c++-concepts] requires expressions
Andrew Sutton andrew.n.sut...@gmail.com writes: | Fixed and committed, but I have a small follow-up related to parameter | packs in requires clauses. The checking for unexpanded parameter packs | treats the parameter declarations like regular PARM_DECL references | and gives errors that they are unexpanded packs. | | 2013-07-26 Andrew Sutton andrew.n.sut...@gmail.com | * gcc/cp/tree.c (cp_walk_subtrees): Don't recurse through the | requires expr parameter list. | | Andrew Let me know when you commit this so I can merge from trunk. -- Gaby
