Re: Excluding dejagnu testcases for subtargets
On Fri, Aug 10, 2012 at 09:54:17AM -0700, Janis Johnson wrote:
> On 08/09/2012 10:52 PM, Senthil Kumar Selvaraj wrote:
> > Hi,
> >
> > What is the recommended way to skip specific (non target specific)
> > testcases for a subtargets?
> >
> > There are a bunch of tests in the gcc testsuite that are too big (in
> > terms of code size or memory) for a subtarget of the avr target. The
> > subtarget is specified in the dejagnu board configuration file
> > (set_board_info cflags "-mmcu ").
> >
> > Using dg-skip-if with "-mmcu " for the include part did
> > not work. Looking at the source (target-supports-dg.exp) showed that it
> > doesn't consider board_info cflags. Only board_info multilib_flags,
> > flags specified in dg-options, $TOOL_OPTIONS and $TEST_ALWAYS_FLAGS
> > appear to be considered.
> >
> > Should we set the -mmcu option to multilib_flags instead of cflags in
> > the board config? Should we use --tool_opt in RUNTESTFLAGS? How do
> > other targets handle this?
> >
> > Regards
> > Senthil
>
> Probably check-flags in target-supports-dg.exp should check cflags
> in the board_info along with the other flags. Can you try that to
> see if it does what you need?
>
Yes it does. The patch below did the job.
Is there a reason why cflags wasn't included before?
Regards
Senthil
diff --git a/gcc/testsuite/lib/target-supports-dg.exp
b/gcc/testsuite/lib/target-supports-dg.exp
index 2f6c4c2..bdf7476 100644
--- a/gcc/testsuite/lib/target-supports-dg.exp
+++ b/gcc/testsuite/lib/target-supports-dg.exp
@@ -304,6 +304,9 @@ proc check-flags { args } {
# If running a subset of the test suite, $TEST_ALWAYS_FLAGS may not exist.
catch {append compiler_flags " $TEST_ALWAYS_FLAGS "}
set dest [target_info name]
+if [board_info $dest exists cflags] {
+append compiler_flags "[board_info $dest cflags] "
+}
if [board_info $dest exists multilib_flags] {
append compiler_flags "[board_info $dest multilib_flags] "
}
Re: Excluding dejagnu testcases for subtargets
On 08/11/2012 09:18 AM, Senthil Kumar Selvaraj wrote:
> On Fri, Aug 10, 2012 at 09:54:17AM -0700, Janis Johnson wrote:
>> On 08/09/2012 10:52 PM, Senthil Kumar Selvaraj wrote:
>>> Hi,
>>>
>>> What is the recommended way to skip specific (non target specific)
>>> testcases for a subtargets?
>>>
>>> There are a bunch of tests in the gcc testsuite that are too big (in
>>> terms of code size or memory) for a subtarget of the avr target. The
>>> subtarget is specified in the dejagnu board configuration file
>>> (set_board_info cflags "-mmcu ").
>>>
>>> Using dg-skip-if with "-mmcu " for the include part did
>>> not work. Looking at the source (target-supports-dg.exp) showed that it
>>> doesn't consider board_info cflags. Only board_info multilib_flags,
>>> flags specified in dg-options, $TOOL_OPTIONS and $TEST_ALWAYS_FLAGS
>>> appear to be considered.
>>>
>>> Should we set the -mmcu option to multilib_flags instead of cflags in
>>> the board config? Should we use --tool_opt in RUNTESTFLAGS? How do
>>> other targets handle this?
>>>
>>> Regards
>>> Senthil
>>
>> Probably check-flags in target-supports-dg.exp should check cflags
>> in the board_info along with the other flags. Can you try that to
>> see if it does what you need?
>>
>
> Yes it does. The patch below did the job.
Please submit it, with a ChangeLog entry, to gcc-patc...@gcc.gnu.org.
> Is there a reason why cflags wasn't included before?
Because I didn't know about it. It wasn't intentional.
Janis
> Regards
> Senthil
>
>
> diff --git a/gcc/testsuite/lib/target-supports-dg.exp
> b/gcc/testsuite/lib/target-supports-dg.exp
> index 2f6c4c2..bdf7476 100644
> --- a/gcc/testsuite/lib/target-supports-dg.exp
> +++ b/gcc/testsuite/lib/target-supports-dg.exp
> @@ -304,6 +304,9 @@ proc check-flags { args } {
> # If running a subset of the test suite, $TEST_ALWAYS_FLAGS may not
> exist.
> catch {append compiler_flags " $TEST_ALWAYS_FLAGS "}
> set dest [target_info name]
> +if [board_info $dest exists cflags] {
> +append compiler_flags "[board_info $dest cflags] "
> +}
> if [board_info $dest exists multilib_flags] {
> append compiler_flags "[board_info $dest multilib_flags] "
> }
Hopelessly broken loop_father, loop_depth
Hello Richi, After a frustrating few days of trying to figure out what *I* was doing wrong trying to speed up rewrite_into_loop_closed_ssa(), I finally gave up and looked at the rest of GCC. One wouldn't expect anything to be very broken in an unpatched tree, after all, but the kind of failures I was seeing just couldn't be explained by any fault of my own. Such as loop_depth(bb->loop_father) != bb->loop_depth. Or even worse, flow_bb_inside_loop_p (bb->loop_father, bb) is false. This looks all related to maintaining loops in the GIMPLE optimizers, but quite frankly, I don't really understand how the loop updating API is supposed to work, and I'm not even sure whether bb->loop_depth and bb->loop_father are supposed to be accurate at all times (other places in the compiler appear to rely on this, but it's still not documented, and I've spent enough time on this already when it's probably fixed in a jiffy by you ;-). Could you please have a look at this breakage? (And please, document the loop stuff and also all the SSA name changes ASAP instead of postponing it to stage3 or later!) Lots of test cases fail with the attached patch. As a starting point for you, I'll mention 920723-1.c compiled with -O1 -ftree-unswitch-loops. This gives: 920723-1.c: In function 'f': 920723-1.c:33:1: error: bb 15 has father loop 3, should be loop 2 } ^ 920723-1.c:33:1: error: bb 1 has loop depth 0, should be 1 920723-1.c:33:1: error: bb 8 has father loop 3, should be loop 2 920723-1.c:33:1: error: bb 1 has loop depth 0, should be 1 920723-1.c:33:1: error: bb 13 has father loop 5, should be loop 2 920723-1.c:33:1: error: bb 1 has loop depth 0, should be 1 920723-1.c:33:1: error: bb 16 has father loop 4, should be loop 2 920723-1.c:33:1: error: bb 1 has loop depth 0, should be 1 920723-1.c:33:1: error: bb 17 has father loop 5, should be loop 2 920723-1.c:33:1: error: bb 1 has loop depth 0, should be 1 920723-1.c:33:1: error: bb 5 has father loop 5, should be loop 2 920723-1.c:33:1: error: bb 1 has loop depth 0, should be 1 920723-1.c:33:1: error: bb 7 has father loop 3, should be loop 2 920723-1.c:33:1: error: bb 1 has loop depth 0, should be 1 920723-1.c:33:1: error: bb 6 has father loop 4, should be loop 2 920723-1.c:33:1: error: bb 1 has loop depth 0, should be 1 920723-1.c:33:1: error: bb 13 has father loop 5, should be loop 3 920723-1.c:33:1: error: bb 1 has loop depth 0, should be 2 920723-1.c:33:1: error: bb 16 has father loop 4, should be loop 3 920723-1.c:33:1: error: bb 1 has loop depth 0, should be 2 920723-1.c:33:1: error: bb 17 has father loop 5, should be loop 3 920723-1.c:33:1: error: bb 1 has loop depth 0, should be 2 920723-1.c:33:1: error: bb 5 has father loop 5, should be loop 3 920723-1.c:33:1: error: bb 1 has loop depth 0, should be 2 920723-1.c:33:1: error: bb 6 has father loop 4, should be loop 3 920723-1.c:33:1: error: bb 1 has loop depth 0, should be 2 920723-1.c:33:1: error: bb 5 has father loop 5, should be loop 4 920723-1.c:33:1: error: bb 1 has loop depth 0, should be 3 920723-1.c:33:1: error: bb 13 has father loop 5, should be loop 4 920723-1.c:33:1: error: bb 1 has loop depth 0, should be 3 920723-1.c:33:1: error: bb 17 has father loop 5, should be loop 4 920723-1.c:33:1: error: bb 1 has loop depth 0, should be 3 920723-1.c:33:1: internal compiler error: in verify_loop_structure, at cfgloop.c:1583 Please submit a full bug report, etc. BTW, it's quite annoying that loop_depth(loop_p) returns "unsigned int", but bb->loop_depth is just "int". Is loop_depth<0 used as a special case? If so, then I think loop_depth(loop_p) should be changed to return "int", otherwise bb->loop_depth should be made an "unsigned int". What do you think about this? Ciao! Steven tighten_loop_verifier.diff Description: Binary data
gcc-4.7-20120811 is now available
Snapshot gcc-4.7-20120811 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20120811/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch revision 190320 You'll find: gcc-4.7-20120811.tar.bz2 Complete GCC MD5=c3e3e151abcf3e31cf0c7d4c2e6993ae SHA1=d5e9317de7a22ad5264625cc88ff6d2f2f127c15 Diffs from 4.7-20120804 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[cxx-conversion] Final trunk->branch merge
This is the final merge from trunk before I start sending the
branch->trunk merge patches.
This merge required some non-mechanical fixes. A recent patch
introduced DEF_VEC_A() for vectors of atomic types. When a VEC
of an atomic type needs to be GC/PCH marked, the marker
needs to do nothing.
In trunk, this is done by creating a separate vec_t structure
that declares the type with GTY((atomic)). In the branch, we can
do it a little simpler by providing explicit template
instantiations for the atomic type that do nothing.
The patch below does that. When the user declares a vector with
DEF_VEC_A(), the macro expands to 3 instances of the gt_ggc_mx
and gt_pch_nx functions that do nothing.
After I get rid of the DEF_VEC_* macros in trunk, I will probably
provide the same feature by adding an additional parameter to the
vec_t class.
Tested on x86_64. Committed to branch.
Diego.
* vec.h (DEF_VEC_A): Provide template instantiations for
GC/PCH markers that do not traverse the vector.
diff --git a/svnclient/gcc/vec.h b/svnclient/gcc/vec.h
index b139053..5fdb859 100644
--- a/svnclient/gcc/vec.h
+++ b/svnclient/gcc/vec.h
@@ -231,8 +231,36 @@ gt_pch_nx (vec_t *v, gt_pointer_operator op, void
*cookie)
#define DEF_VEC_ALLOC_O_STACK(T) struct vec_swallow_trailing_semi
#define DEF_VEC_ALLOC_I_STACK(T) struct vec_swallow_trailing_semi
-/* Vectors of atomic types. */
-#define DEF_VEC_A(T) struct vec_swallow_trailing_semi
+/* Vectors of atomic types. Atomic types do not need to have its
+ elements marked for GC and PCH. To avoid unnecessary traversals,
+ we provide template instantiations for the GC/PCH functions that
+ do not traverse the vector.
+
+ FIXME cxx-conversion - Once vec_t users are converted this can
+ be provided in some other way (e.g., adding an additional template
+ parameter to the vec_t class). */
+#define DEF_VEC_A(TYPE)\
+template \
+void \
+gt_ggc_mx (vec_t *v ATTRIBUTE_UNUSED)\
+{ \
+} \
+ \
+template \
+void \
+gt_pch_nx (vec_t *v ATTRIBUTE_UNUSED)\
+{ \
+} \
+ \
+template \
+void \
+gt_pch_nx (vec_t *v ATTRIBUTE_UNUSED,\
+ gt_pointer_operator op ATTRIBUTE_UNUSED, \
+ void *cookie ATTRIBUTE_UNUSED) \
+{ \
+} \
+struct vec_swallow_trailing_semi
+
#define DEF_VEC_ALLOC_A(T,A) struct vec_swallow_trailing_semi
/* Support functions for stack vectors. */
The cream of the crop for 2011 - GET IN EARLY!
If You've Already Making 3000% and more On THE MOST UNDERVALUED STOCK, Stop Reading. And If you don't need to Fast returns on Monday, DEFINITELY Go Away! V N DB is hitting a 3,000% gains in volume today, indicating some mighty shorting, resulting in the price to be under the where it should be. To you it could mean that as soon as they get to purchasing the stock up, the selling price will go At Least 3,000%. The momentum to BUY IN can't be any better then Today!!! Now the shorters must get buying back the stock the same volumes as they short now, which is over 3,000%. What else do you need to start buying? The share price is majorly under the value and you Will take home some wealth if you acquire V N DB shares on August 13, this Monday, 08/13/2012!!!
