Re: restore do { mistakenly taken out in SUBSUBTARGET_OVERRIDE_OPTIONS for ppc-vxworks
On Jun 1, 2012, at 19:09 , Eric Botcazou wrote:
* config/rs6000/vxworks.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Restore
the do { part of the do-while(0) loop.
This is needed on the 4.7 branch as well.
Hmm, I don't think so. The removal was part of the E500
related reorg, which was not committed to the branch.
Indeed, the original code, with both the E500 resets and
the 'do {', is there.
Re: restore do { mistakenly taken out in SUBSUBTARGET_OVERRIDE_OPTIONS for ppc-vxworks
Hmm, I don't think so. The removal was part of the E500 related reorg, which was not committed to the branch. You're right, I looked at the wrong branch. -- Eric Botcazou
[C PATCH] Diagnose compound literals with incomplete type (PR c/53532)
Hi!
As the testcase shows, we weren't diagnosing compound literals with
incomplete type at all. Fixed thusly, bootstrapped/regtested on
x86_64-linux and i686-linux, ok for trunk?
2012-06-02 Jakub Jelinek ja...@redhat.com
PR c/53532
* c-decl.c (build_compound_literal): Call c_incomplete_type_error
if type isn't complete.
* gcc.dg/pr53532.c: New test.
* gcc.dg/c99-complit-2.c: Add two new dg-error directives,
adjust line numbers.
* gcc.dg/noncompile/950825-1.c: Expect incomplete type error message.
* gcc.dg/Wcxx-compat-8.c: Likewise.
--- gcc/c-decl.c.jj 2012-06-01 14:40:55.636420798 +0200
+++ gcc/c-decl.c2012-06-01 17:52:04.587343492 +0200
@@ -4638,7 +4638,10 @@ build_compound_literal (location_t loc,
}
if (type == error_mark_node || !COMPLETE_TYPE_P (type))
-return error_mark_node;
+{
+ c_incomplete_type_error (NULL_TREE, type);
+ return error_mark_node;
+}
stmt = build_stmt (DECL_SOURCE_LOCATION (decl), DECL_EXPR, decl);
complit = build1 (COMPOUND_LITERAL_EXPR, type, stmt);
--- gcc/testsuite/gcc.dg/pr53532.c.jj 2012-06-01 17:52:04.603343388 +0200
+++ gcc/testsuite/gcc.dg/pr53532.c 2012-06-02 08:51:39.837776539 +0200
@@ -0,0 +1,13 @@
+/* PR c/53532 */
+/* { dg-do compile } */
+/* { dg-options } */
+
+struct S {};
+extern int foo (struct S);
+
+int
+main ()
+{
+ foo ((struct T) {}); /* { dg-error invalid use of undefined type } */
+ return 0;
+}
--- gcc/testsuite/gcc.dg/c99-complit-2.c.jj 2008-09-05 12:54:36.0
+0200
+++ gcc/testsuite/gcc.dg/c99-complit-2.c2012-06-02 08:50:49.984082757
+0200
@@ -18,45 +18,47 @@ foo (int a)
/* { dg-error init void type { target *-*-* } 17 } */
(struct si) { 1 }; /* { dg-bogus warning warning in place of error } */
/* { dg-error init incomplete struct type { target *-*-* } 19 } */
+ /* { dg-error invalid use of undefined type { target *-*-* } 19 } */
(union ui) { 1 }; /* { dg-bogus warning warning in place of error } */
- /* { dg-error init incomplete union type { target *-*-* } 21 } */
+ /* { dg-error init incomplete union type { target *-*-* } 22 } */
+ /* { dg-error invalid use of undefined type { target *-*-* } 22 } */
(void (void)) { 0 }; /* { dg-bogus warning warning in place of error } */
- /* { dg-error init function type { target *-*-* } 23 } */
+ /* { dg-error init function type { target *-*-* } 25 } */
(int [a]) { 1 }; /* { dg-bogus warning warning in place of error } */
- /* { dg-error init|variable VLA type { target *-*-* } 25 } */
+ /* { dg-error init|variable VLA type { target *-*-* } 27 } */
/* Initializers must not attempt to initialize outside the object
declared. */
(int [1]) { [1] = 2 }; /* { dg-bogus warning warning in place of error }
*/
- /* { dg-error init value outside array { target *-*-* } 29 } */
- (int [1]) { [-1] = 2 }; /* { dg-bogus warning warning in place of error
} */
/* { dg-error init value outside array { target *-*-* } 31 } */
- (int [1]) { 0, 1 }; /* { dg-bogus warning warning in place of error } */
+ (int [1]) { [-1] = 2 }; /* { dg-bogus warning warning in place of error
} */
/* { dg-error init value outside array { target *-*-* } 33 } */
+ (int [1]) { 0, 1 }; /* { dg-bogus warning warning in place of error } */
+ /* { dg-error init value outside array { target *-*-* } 35 } */
}
int z;
/* Outside a function, initializers must be constant. */
struct s *s0 = (struct s) { 0, z }; /* { dg-bogus warning warning in place
of error } */
-/* { dg-error init non-const { target *-*-* } 40 } */
-int sz = sizeof((struct s) { 0, z }); /* { dg-bogus warning warning in
place of error } */
/* { dg-error init non-const { target *-*-* } 42 } */
+int sz = sizeof((struct s) { 0, z }); /* { dg-bogus warning warning in
place of error } */
+/* { dg-error init non-const { target *-*-* } 44 } */
/* Compound literals aren't themselves constant expressions. */
int x = (int) { 0 }; /* { dg-bogus warning warning in place of error } */
-/* { dg-error init non-const { target *-*-* } 46 } */
+/* { dg-error init non-const { target *-*-* } 48 } */
/* Nor are they suitable structure or union initializers
outside a function. */
struct s s1 = (struct s) { 0, 1 }; /* { dg-bogus warning warning in place
of error } */
-/* { dg-error init struct bad init { target *-*-* } 51 } */
+/* { dg-error init struct bad init { target *-*-* } 53 } */
union u u1 = (union u) { 0 }; /* { dg-bogus warning warning in place of
error } */
-/* { dg-error init union bad init { target *-*-* } 53 } */
+/* { dg-error init union bad init { target *-*-* } 55 } */
/* They aren't suitable for array initializers, either inside or outside
a function. */
int y[2] = (int [2]) { 0, 1 }; /* { dg-bogus warning warning in place of
error } */
-/* { dg-error init array bad init { target *-*-* } 58 } */
+/* { dg-error init array bad init { target *-*-* } 60 } */
void
[PATCH] Fix number_of_iterations_cond (PR tree-optimization/53550)
Hi!
tree-chrec.c and tree-scalar-evolutions.c uses sizetype as type of
iv-step, but the following spot would use POINTER_TYPE, which leads
to ICEs. Fixed thusly, bootstrapped/regtested onx 86_64-linux and
i686-linux, ok for trunk/4.7?
2012-06-02 Jakub Jelinek ja...@redhat.com
PR tree-optimization/53550
* tree-ssa-loop-niter.c (number_of_iterations_cond): If type
is POINTER_TYPE_P, use sizetype as step type instead of type.
* gcc.dg/pr53550.c: New test.
--- gcc/tree-ssa-loop-niter.c.jj2012-06-01 14:40:59.336398386 +0200
+++ gcc/tree-ssa-loop-niter.c 2012-06-01 17:52:09.128317401 +0200
@@ -1275,13 +1275,14 @@ number_of_iterations_cond (struct loop *
practice, but it is simple enough to manage. */
if (!integer_zerop (iv0-step) !integer_zerop (iv1-step))
{
+ tree step_type = POINTER_TYPE_P (type) ? sizetype : type;
if (code != NE_EXPR)
return false;
- iv0-step = fold_binary_to_constant (MINUS_EXPR, type,
+ iv0-step = fold_binary_to_constant (MINUS_EXPR, step_type,
iv0-step, iv1-step);
iv0-no_overflow = false;
- iv1-step = build_int_cst (type, 0);
+ iv1-step = build_int_cst (step_type, 0);
iv1-no_overflow = true;
}
--- gcc/testsuite/gcc.dg/pr53550.c.jj 2012-06-01 17:52:09.128317401 +0200
+++ gcc/testsuite/gcc.dg/pr53550.c 2012-06-02 08:53:53.345935193 +0200
@@ -0,0 +1,12 @@
+/* PR tree-optimization/53550 */
+/* { dg-do compile } */
+/* { dg-options -O2 -fprefetch-loop-arrays -w } */
+
+int *
+foo (int *x)
+{
+ int *a = x + 10, *b = x, *c = a;
+ while (b != c)
+*--c = *b++;
+ return x;
+}
Jakub
Re: [RFC] Fix SRA with respect of BIT_FIELD_REF
On Fri, Jun 1, 2012 at 4:44 AM, Martin Jambor mjam...@suse.cz wrote:
Hi,
On Fri, Jun 01, 2012 at 11:31:20AM +0200, Richard Guenther wrote:
On Fri, Jun 1, 2012 at 6:02 AM, Andrew Pinski
andrew.pin...@caviumnetworks.com wrote:
Hi,
When I modified GCC to change the majority of bitfield accesses
which were done via component ref to BIT_FIELD_REF, SRA messes up
because when it does the replacement it still tries to use the
BIT_FIELD_REF except it never places the old value in the struct for
the BIT_FIELD_REF to work correctly.
This patch fixes the problem by expanding what BIT_FIELD_REF does
internally for both writing and reading. Note we can't use
BIT_FIELD_REF directly on the left hand since we don't support partial
writes yet (except for vector and complex types).
This is only a RFC since I don't know a way to reproduce this bug on
the trunk. I tested it on x86_64-linux-gnu with no regressions.
I'd rather disqualify SRA of BIT_FIELD_REFs on the LHS for now. My goal
was to enable SRA of bitfields using the DECL_BIT_FIELD_REPRESENTATIVE
work - something you go against with replacing them with BIT_FIELD_REFs.
SRA of bit-fields works now, it is just rather simple and can't
optimize the bit-field accesses as we probably should. Therefore I am
all for using DECL_BIT_FIELD_REPRESENTATIVEs and looked at those
patches with interest, I'm just wondering why we'd want to do it for
non-addressable structures only, which is something SRA would imply if
this lowering was part of it.
BIT_FIELD_REFs of non-vectors on the LHS are not much tested, I'm
afraid. I it is quite possible it does not do the right thing.
Nevertheless, making regions accessed through them unscalarizable
might also be an option, if it does not induce significant penalties
anywhere.
Here is a new patch which fixes BFR's in a much simpler way. The
problem is SRA recognizes it needs to reread the replacement but it
forgets it needs to the write in the replacement right before the
action happens.
Thanks,
Andrew pinski
Thanks,
Martin
You'd replace
x = a.b;
with
tem = a.representative for b;
x = BIT_FIELD_REF tem, ;
and for stores with a read-modify-write sequence, possibly adding
the bitfield-insert tree I proposed some time ago. Replace
a.b = x;
with
tem = a.representative for b
tem = BIT_FIELD_EXPR tem, x, ...;
a.representative for b = tem;
and I'd do this replacement in SRA for now whenever it would decide to
SRA a bitfield.
Richard.
Thanks,
Andrew Pinski
ChangeLog:
* tree-sra.c (sra_modify_expr): Handle BIT_FIELD_REF specially if we
are doing a replacement of the struct with one variable.
Index: tree-sra.c
===
--- tree-sra.c (revision 188138)
+++ tree-sra.c (working copy)
@@ -2602,10 +2602,20 @@ sra_modify_expr (tree *expr, gimple_stmt
if (!useless_type_conversion_p (type, access-type))
{
tree ref;
+ gimple stmt;
ref = build_ref_for_model (loc, access-base, access-offset, access,
NULL, false);
+ /* Reads and writes need at least the original access setup. */
+ if (access-grp_partial_lhs)
+ repl = force_gimple_operand_gsi (gsi, repl, true, NULL_TREE,
+true, GSI_SAME_STMT);
+ stmt = gimple_build_assign (ref, repl);
+ gimple_set_location (stmt, loc);
+ gsi_insert_before (gsi, stmt, GSI_SAME_STMT);
+
+ /* Writes read from the original access after the write has happened.
*/
if (write)
{
gimple stmt;
@@ -2617,17 +2627,6 @@ sra_modify_expr (tree *expr, gimple_stmt
gimple_set_location (stmt, loc);
gsi_insert_after (gsi, stmt, GSI_NEW_STMT);
}
- else
- {
- gimple stmt;
-
- if (access-grp_partial_lhs)
- repl = force_gimple_operand_gsi (gsi, repl, true, NULL_TREE,
-true, GSI_SAME_STMT);
- stmt = gimple_build_assign (ref, repl);
- gimple_set_location (stmt, loc);
- gsi_insert_before (gsi, stmt, GSI_SAME_STMT);
- }
}
else
*expr = repl;
Re: [google] Add options to pattern match function name for hotness attributes
Hi, This patch adds 4 flags to enable user to type in a list of name patterns. Compiler will match the function name with the given patterns, and add hot, cold, likely_hot, likely_cold attributes to function declaration. The static branch prediction checks if a basic block contains call to a annotated function, and set the branch probability accordingly. Bootstrapped and passed gcc testsuites. Ok for google branches? Just out of curiosity, what is main advantage of this over annotating your source? Honza
Re: [google] Add options to pattern match function name for hotness attributes
On Sat, Jun 2, 2012 at 2:36 AM, Jan Hubicka hubi...@ucw.cz wrote: Hi, This patch adds 4 flags to enable user to type in a list of name patterns. Compiler will match the function name with the given patterns, and add hot, cold, likely_hot, likely_cold attributes to function declaration. The static branch prediction checks if a basic block contains call to a annotated function, and set the branch probability accordingly. Bootstrapped and passed gcc testsuites. Ok for google branches? Just out of curiosity, what is main advantage of this over annotating your source? This is to avoid too much annotation at source level. Some applications have good per application knowledge of library functions (that are compiled and statically linked in). Another example of its -- coarse grain (function level) profile data collected from data center can be used to guide branch prediction/estimation. thanks, David Honza
Re: [google] Add options to pattern match function name for hotness attributes
On Sat, Jun 2, 2012 at 2:36 AM, Jan Hubicka hubi...@ucw.cz wrote: Hi, This patch adds 4 flags to enable user to type in a list of name patterns. Compiler will match the function name with the given patterns, and add hot, cold, likely_hot, likely_cold attributes to function declaration. The static branch prediction checks if a basic block contains call to a annotated function, and set the branch probability accordingly. Bootstrapped and passed gcc testsuites. Ok for google branches? Just out of curiosity, what is main advantage of this over annotating your source? This is to avoid too much annotation at source level. Some applications have good per application knowledge of library functions (that are compiled and statically linked in). Another example of its -- coarse grain (function level) profile data collected from data center can be used to guide branch prediction/estimation. Well, perhaps the feature would be more useful with command line option allowing to add an attribute instead of having special case command line options for individual cases. I guess the problem would be also solvable with header included after the library adding the attributes to the declarations typeof (printf) printf __attribute__ ((cold)); Honza thanks, David Honza
Re: [google] Add options to pattern match function name for hotness attributes
On Sat, Jun 2, 2012 at 6:06 PM, Jan Hubicka hubi...@ucw.cz wrote: On Sat, Jun 2, 2012 at 2:36 AM, Jan Hubicka hubi...@ucw.cz wrote: Hi, This patch adds 4 flags to enable user to type in a list of name patterns. Compiler will match the function name with the given patterns, and add hot, cold, likely_hot, likely_cold attributes to function declaration. The static branch prediction checks if a basic block contains call to a annotated function, and set the branch probability accordingly. Bootstrapped and passed gcc testsuites. Ok for google branches? Just out of curiosity, what is main advantage of this over annotating your source? This is to avoid too much annotation at source level. Some applications have good per application knowledge of library functions (that are compiled and statically linked in). Another example of its -- coarse grain (function level) profile data collected from data center can be used to guide branch prediction/estimation. Well, perhaps the feature would be more useful with command line option allowing to add an attribute instead of having special case command line options for individual cases. Hi, Honza, I'm not sure what you mean by command line option allowing to add an attribution. But this seems what this patch does: it adds attributes to functions with specified name patterns. I guess the problem would be also solvable with header included after the library adding the attributes to the declarations typeof (printf) printf __attribute__ ((cold)); Do you mean that for each specific application, we extract a common header file to include all function annotations, and all source files will include this header file? Thanks, Dehao Honza thanks, David Honza
[Fortran, DRAFT patch] PR 46321 - [OOP] Polymorphic deallocation
Dear all,
I have realized a draft patch for the PR 46321, currently it works
only with the explicit DEALLOCATE.
Running the regression tests it doesn't pass the following:
- gfortran.dg/class_19.f03 (too much __builtin_free)
- gfortran.dg/auto_dealloc_2.f90 (too much __builtin_free)
- gfortran.dg/dynamic_dispatch_4.f03 (free on invalid pointer)
- gfortran.dg/typebound_operator_9.f03 (fails during the execution test)
The first two tests fail due to the introduction of __builtin_free
in the freeing functions, so it is not a problem.
The gfortran.dg/dynamic_dispatch_4.f03 had this problem in the past
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986); currently it
calls the __free_s_bar_mod_S_bar function instead of the proper
doit().
Regarding typebound_operator_9.f03, I don't know how to fix the patch...
The patch is written in a raw way due to my newbieness, so any
suggestion is well accepted.
Regards.
Alessandro
Index: gcc/fortran/class.c
===
--- gcc/fortran/class.c (revisione 188002)
+++ gcc/fortran/class.c (copia locale)
@@ -717,6 +717,7 @@
gfc_namespace *ns;
gfc_symbol *vtab = NULL, *vtype = NULL, *found_sym = NULL, *def_init = NULL;
gfc_symbol *copy = NULL, *src = NULL, *dst = NULL;
+ gfc_symbol *free = NULL, *tofree = NULL;
/* Find the top-level namespace (MODULE or PROGRAM). */
for (ns = gfc_current_ns; ns; ns = ns-parent)
@@ -907,6 +908,119 @@
c-ts.interface = copy;
}
+ /* Add component _free. */
+ gfc_component *temp = NULL;
+ bool der_comp_alloc = false, comp_alloc = false;
+ bool class_comp_alloc = false;
+ for (temp = derived-components; temp; temp = temp-next)
+ {
+ if (temp == derived-components derived-attr.extension)
+ continue;
+
+ if (temp-ts.type == BT_DERIVED
+ !temp-attr.pointer
+ (temp-attr.alloc_comp || temp-attr.allocatable))
+ der_comp_alloc = true;
+ else if (temp-ts.type != BT_DERIVED
+ !temp-attr.pointer
+ (temp-attr.alloc_comp
+ || temp-attr.allocatable))
+ comp_alloc = true;
+ else if (temp-ts.u.derived
+ temp-ts.type == BT_CLASS
+ CLASS_DATA (temp)
+ // (CLASS_DATA (temp)-attr.class_pointer
+ //|| CLASS_DATA (temp)-attr.allocatable))
+ CLASS_DATA (temp)-attr.allocatable)
+ class_comp_alloc = true;
+ }
+ if (derived-attr.extension
+ (!der_comp_alloc !comp_alloc !class_comp_alloc))
+ {
+ gfc_component *parent = derived-components;
+ gfc_component *free_proc = NULL;
+ gfc_symbol *vtab2 = NULL;
+ gfc_expr *tmp1 = NULL, *tmp2 = NULL;
+ vtab2 = gfc_find_derived_vtab (parent-ts.u.derived);
+
+ for (free_proc = vtab2-ts.u.derived-components;
+ free_proc; free_proc = free_proc-next)
+ if (free_proc-name[0] == '_'
+free_proc-name[1] == 'f')
+ break;
+
+ if (!free_proc)
+ goto end_vtab;
+
+ if (gfc_add_component (vtype, _free, c) == FAILURE)
+ goto cleanup;
+ c-attr.proc_pointer = 1;
+ c-attr.access = ACCESS_PRIVATE;
+ c-tb = XCNEW (gfc_typebound_proc);
+ c-tb-ppc = 1;
+ /* Not sure about this part */
+ tmp1 = gfc_lval_expr_from_sym (free_proc-ts.interface);
+ tmp2 = gfc_copy_expr (tmp1);
+ c-initializer = tmp2;
+ c-ts.interface = tmp2-symtree-n.sym;
+ goto end_vtab;
+
+ }
+
+ if (derived-attr.alloc_comp || der_comp_alloc
+ || class_comp_alloc)
+ {
+ gfc_alloc *head = NULL;
+ if (gfc_add_component (vtype, _free, c) == FAILURE)
+ goto cleanup;
+ c-attr.proc_pointer = 1;
+ c-attr.access = ACCESS_PRIVATE;
+ c-tb = XCNEW (gfc_typebound_proc);
+ c-tb-ppc = 1;
+ if (derived-attr.abstract)
+ c-initializer = gfc_get_null_expr (NULL);
+ else
+ {
+ /* Set up namespace. */
+ gfc_namespace *sub_ns2 = gfc_get_namespace (ns, 0);
+ sub_ns2-sibling = ns-contained;
+ ns-contained = sub_ns2;
+ sub_ns2-resolved = 1;
+
Re: [google] Add options to pattern match function name for hotness attributes
Well, perhaps the feature would be more useful with command line option allowing to add an attribute instead of having special case command line options for individual cases. Hi, Honza, I'm not sure what you mean by command line option allowing to add an attribution. But this seems what this patch does: it adds attributes to functions with specified name patterns. I mean that if we want to go this route, we may want to allow this interface to i.e. add always_inline attrbute or noinline or such. I can imagine this to be useful especially for languages that has no attributes. I guess the problem would be also solvable with header included after the library adding the attributes to the declarations typeof (printf) printf __attribute__ ((cold)); Do you mean that for each specific application, we extract a common header file to include all function annotations, and all source files will include this header file? Yes, something like that... Where do you use the likely_hot/likely_cold logic? Honza Thanks, Dehao Honza thanks, David Honza
PATCH: PR bootstrap/53555: [4.8 Regression] Bootstrap failure
Hi,
ix86_sched_reorder should skip debug insns. Tested on Linux/ia32.
OK to install?
Thanks.
H.J.
---
2012-06-02 H.J. Lu hongjiu...@intel.com
PR bootstrap/53555
* config/i386/i386.c (ix86_sched_reorder) Skip debug insns.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index c6c2c5e..13755f4 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -23919,6 +23919,8 @@ ix86_sched_reorder(FILE *dump, int sched_verbose, rtx
*ready, int *pn_ready,
{
rtx con;
con = DEP_CON (dep);
+ if (!NONDEBUG_INSN_P (con))
+ continue;
insn1 = PATTERN (con);
if (GET_CODE (insn1) == PARALLEL)
insn1 = XVECEXP (insn1, 0, 0);
@@ -23935,6 +23937,8 @@ ix86_sched_reorder(FILE *dump, int sched_verbose, rtx
*ready, int *pn_ready,
{
rtx pro;
pro = DEP_PRO (dep1);
+ if (!NONDEBUG_INSN_P (pro))
+ continue;
if (pro != insn)
index = -1;
}
Re: [google] Add options to pattern match function name for hotness attributes
On Sat, Jun 2, 2012 at 9:17 PM, Jan Hubicka hubi...@ucw.cz wrote: Well, perhaps the feature would be more useful with command line option allowing to add an attribute instead of having special case command line options for individual cases. Hi, Honza, I'm not sure what you mean by command line option allowing to add an attribution. But this seems what this patch does: it adds attributes to functions with specified name patterns. I mean that if we want to go this route, we may want to allow this interface to i.e. add always_inline attrbute or noinline or such. I can imagine this to be useful especially for languages that has no attributes. This annotation is mainly for static branch prediction. Some functions may be very cold, but it may still be good to inline it. I guess the problem would be also solvable with header included after the library adding the attributes to the declarations typeof (printf) printf __attribute__ ((cold)); Do you mean that for each specific application, we extract a common header file to include all function annotations, and all source files will include this header file? Yes, something like that... Where do you use the likely_hot/likely_cold logic? For really cold functions, we predict the branch to be 0.04% taken. However, some callee functions are not that extremely cold, and predicting them as 0.04% is too aggressive. Likely_cold is for such functions, and we predict them as 25% taken (at least we can predict the direction right). Vise versa for likely_hot annotation. Thanks, Dehao Honza Thanks, Dehao Honza thanks, David Honza
Re: [PATCH 2/2] Better system header location detection for built-in macro tokens
For built-in macros, the patch is now stepping up until it sees a
location that is not for a built-in macro, and at point, checks if we
are in a system header.
It also uses the location of the '=' operator as the location for
assignment expressions. I had to adjust a couple of tests due to that change.
Bootstrapped and tested on x86_64-unknown-linux-gnu against trunk.
OK for trunk?
libcpp/
* line-map.c (linemap_location_in_system_header_p): For built-in
macro tokens, check the first expansion point location for that is
not for a token coming from a built-in macro.
gcc/cp/
* parser.c (cp_parser_assignment_expression): Use the location
for the LHS as the default location for the expression.
gcc/testsuite/
* g++.dg/cpp/limits.C: New test.
* g++.dg/parse/error19.C: Adjust.
* g++.dg/warn/Wconversion-real-integer2.C: Likewise.
* g++.dg/warn/pr35635.C: Likewise.
* g++.old-deja/g++.pt/assign1.C: Likewise.
---
gcc/cp/parser.c|4 ++-
gcc/testsuite/g++.dg/cpp/limits.C | 21 ++
gcc/testsuite/g++.dg/parse/error19.C |2 +-
.../g++.dg/warn/Wconversion-real-integer2.C|4 +-
gcc/testsuite/g++.dg/warn/pr35635.C|4 +-
gcc/testsuite/g++.old-deja/g++.pt/assign1.C|5 ++-
libcpp/line-map.c | 30 +--
7 files changed, 58 insertions(+), 12 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp/limits.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 9fd8c84..e393f48 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -7491,7 +7491,9 @@ cp_parser_assignment_expression (cp_parser* parser, bool
cast_p,
if (cp_parser_non_integral_constant_expression (parser,
NIC_ASSIGNMENT))
return error_mark_node;
- /* Build the assignment expression. */
+ /* Build the assignment expression. Its default
+location is the location of the '=' token. */
+ input_location = loc;
expr = build_x_modify_expr (loc, expr,
assignment_operator,
rhs,
diff --git a/gcc/testsuite/g++.dg/cpp/limits.C
b/gcc/testsuite/g++.dg/cpp/limits.C
new file mode 100644
index 000..b64e1e2
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp/limits.C
@@ -0,0 +1,21 @@
+// { dg-options -pedantic }
+// { dg-do compile }
+
+#include limits
+
+// Compiling this with -pedantic was wrongly triggering this error:
+// libstdc++-v3/include/limits:1269:45: warning : use of C++0x long long
integer constant [-Wlong-long]
+// min() _GLIBCXX_USE_NOEXCEPT { return -__LONG_LONG_MAX__ - 1; }
+// ^
+// libstdc++-v3/include/limits:1272:44: warning : use of C++0x long long
integer constant [-Wlong-long]
+// max() _GLIBCXX_USE_NOEXCEPT { return __LONG_LONG_MAX__; }
+//^
+// libstdc++-v3/include/limits:1342:44: warning : use of C++0x long long
integer constant [-Wlong-long]
+// max() _GLIBCXX_USE_NOEXCEPT { return __LONG_LONG_MAX__ * 2ULL + 1
+//^
+
+int
+main ()
+{
+return 0;
+}
diff --git a/gcc/testsuite/g++.dg/parse/error19.C
b/gcc/testsuite/g++.dg/parse/error19.C
index 010a403..6d84f71 100644
--- a/gcc/testsuite/g++.dg/parse/error19.C
+++ b/gcc/testsuite/g++.dg/parse/error19.C
@@ -10,6 +10,6 @@ const A foo();
void bar()
{
- foo()=A(0); // { dg-error 12:no match for 'operator=' }
+ foo()=A(0); // { dg-error 8:no match for 'operator=' }
// { dg-message candidate candidate note { target *-*-* } 13 }
}
diff --git a/gcc/testsuite/g++.dg/warn/Wconversion-real-integer2.C
b/gcc/testsuite/g++.dg/warn/Wconversion-real-integer2.C
index 6a95b0e..0494588 100644
--- a/gcc/testsuite/g++.dg/warn/Wconversion-real-integer2.C
+++ b/gcc/testsuite/g++.dg/warn/Wconversion-real-integer2.C
@@ -23,11 +23,11 @@
//
// That is more useful.
-#define INT_MAX __INT_MAX__ // { dg-warning conversion to .float. alters
.int. constant value }
+#define INT_MAX __INT_MAX__
float vfloat;
void h (void)
{
-vfloat = INT_MAX; // { dg-message in expansion of macro 'INT_MAX' }
+vfloat = INT_MAX; // { dg-warning conversion to .float. alters .int.
constant value }
}
diff --git a/gcc/testsuite/g++.dg/warn/pr35635.C
b/gcc/testsuite/g++.dg/warn/pr35635.C
index 66ade8b..de68ceb 100644
--- a/gcc/testsuite/g++.dg/warn/pr35635.C
+++ b/gcc/testsuite/g++.dg/warn/pr35635.C
@@ -62,9 +62,9 @@ void func3()
/* At least one branch of ? does not fit in the destination, thus
warn. */
uchar_x = bar != 0 ? 2.1 : 10; /* { dg-warning conversion } */
- uchar_x = bar != 0
+ uchar_x = bar != 0 /* { dg-warning negative integer implicitly
Re: [SH] PR 53512 - Allow fsca and fsrra for non-SH4A
On Fri, 2012-06-01 at 22:15 +0900, Kaz Kojima wrote:
I see a new failure
FAIL: gcc.target/sh/pr53512-1.c scan-assembler fsca
on sh4-unknown-linux-gnu with the patch. Looks that the test
fails due to TARGET_HAS_SINCOS which is defined on linux targets.
It seems that we need a sincossf3 expander for this test on
TARGET_HAS_SINCOS targets.
Thanks for catching this!
The attached patch should fix the issue, by folding the existing sinsf2
and cossf2 expanders into a single sincossf3. I ran the test cases
again with TARGET_HAS_SINCOS set to '1' and to '0' and they pass.
Cheers,
Oleg
ChangeLog:
PR target/53512
* sh.opt (mfsca, mfsrra): New options.
* sh.md (rsqrtsf2): Use TARGET_FPU_ANY and TARGET_FSRRA
condition.
(fsca): Use TARGET_FPU_ANY and TARGET_FSCA condition.
(sinssf2, cossf2): Fold expanders to...
(sincossf3): ...this new expander. Use TARGET_FPU_ANY and
TARGET_FSCA condition.
* sh.c (sh_option_override): Handle TARGET_FSRRA and
TARGET_FSCA.
* doc/invoke.texi (SH Options): Add descriptions for -mfsca,
-mno-fsca, -mfsrra, -mno-fsrra.
testsuite/ChangeLog:
PR target/53512
* gcc.target/sh/pr53512-1.c: New.
* gcc.target/sh/pr53512-2.c: New.
* gcc.target/sh/pr53512-3.c: New.
* gcc.target/sh/pr53512-4.c: New.
Index: gcc/config/sh/sh.c
===
--- gcc/config/sh/sh.c (revision 188026)
+++ gcc/config/sh/sh.c (working copy)
@@ -876,13 +876,30 @@
align_functions = min_align;
}
- /* Enable fmac insn for a * b + c SFmode calculations when -ffast-math
- is enabled and -mno-fused-madd is not specified by the user.
- The fmac insn can't be enabled by default due to the implied
- FMA semantics. See also PR target/29100. */
- if (global_options_set.x_TARGET_FMAC == 0 flag_unsafe_math_optimizations)
-TARGET_FMAC = 1;
+ if (flag_unsafe_math_optimizations)
+{
+ /* Enable fmac insn for a * b + c SFmode calculations when -ffast-math
+ is enabled and -mno-fused-madd is not specified by the user.
+ The fmac insn can't be enabled by default due to the implied
+ FMA semantics. See also PR target/29100. */
+ if (global_options_set.x_TARGET_FMAC == 0)
+ TARGET_FMAC = 1;
+ /* Enable fsca insn for SH4A if not otherwise specified by the user. */
+ if (global_options_set.x_TARGET_FSCA == 0 TARGET_SH4A_FP)
+ TARGET_FSCA = 1;
+
+ /* Enable fsrra insn for SH4A if not otherwise specified by the user. */
+ if (global_options_set.x_TARGET_FSRRA == 0 TARGET_SH4A_FP)
+ TARGET_FSRRA = 1;
+}
+
+ /* Allow fsrra insn only if -funsafe-math-optimizations and
+ -ffinite-math-only is enabled. */
+ TARGET_FSRRA = TARGET_FSRRA
+ flag_unsafe_math_optimizations
+ flag_finite_math_only;
+
if (sh_fixed_range_str)
sh_fix_range (sh_fixed_range_str);
@@ -896,7 +913,6 @@
error (-msoft-atomic and -mhard-atomic cannot be used at the same time);
if (TARGET_HARD_ATOMIC ! TARGET_SH4A_ARCH)
error (-mhard-atomic is only available for SH4A targets);
-
}
/* Print the operand address in x to the stream. */
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 188026)
+++ gcc/config/sh/sh.md (working copy)
@@ -10689,7 +10689,7 @@
(div:SF (match_operand:SF 1 immediate_operand i)
(sqrt:SF (match_operand:SF 2 register_operand 0
(use (match_operand:PSI 3 fpscr_operand c))]
- TARGET_SH4A_FP flag_unsafe_math_optimizations
+ TARGET_FPU_ANY TARGET_FSRRA
operands[1] == CONST1_RTX (SFmode)
fsrra %0
[(set_attr type fsrra)
@@ -10705,50 +10705,38 @@
(unspec:SF [(mult:SF (float:SF (match_dup 1)) (match_dup 2))
] UNSPEC_FCOSA)))
(use (match_operand:PSI 3 fpscr_operand c))]
- TARGET_SH4A_FP flag_unsafe_math_optimizations
+ TARGET_FPU_ANY TARGET_FSCA
operands[2] == sh_fsca_int2sf ()
fsca fpul,%d0
[(set_attr type fsca)
(set_attr fp_mode single)])
-(define_expand sinsf2
+;; When the sincos pattern is defined, the builtin functions sin and cos
+;; will be expanded to the sincos pattern and one of the output values will
+;; remain unused.
+(define_expand sincossf3
[(set (match_operand:SF 0 nonimmediate_operand )
- (unspec:SF [(match_operand:SF 1 fp_arith_reg_operand )]
- UNSPEC_FSINA))]
- TARGET_SH4A_FP flag_unsafe_math_optimizations
+ (unspec:SF [(match_operand:SF 2 fp_arith_reg_operand )]
+ UNSPEC_FSINA))
+ (set (match_operand:SF 1 nonimmediate_operand )
+ (unspec:SF [(match_dup 2)] UNSPEC_FCOSA))]
+ TARGET_FPU_ANY TARGET_FSCA
{
rtx scaled = gen_reg_rtx (SFmode);
rtx truncated = gen_reg_rtx (SImode);
rtx fsca = gen_reg_rtx (V2SFmode);
rtx scale_reg = force_reg (SFmode, sh_fsca_sf2int ());
- emit_sf_insn (gen_mulsf3 (scaled, operands[1], scale_reg));
+ emit_sf_insn (gen_mulsf3
Re: patch to clean up the many ways of saying 2 * HOST_BITS_PER_WIDE_INT
committed as revision 188139 2012-06-2 Kenneth Zadeck zad...@naturalbridge.com * expmed.c (expand_mult, choose_multiplier): Change 2 * HOST_BITS_PER_WIDE_INT to HOST_BITS_PER_DOUBLE_INT. * expr.c (convert_modes): Likewise. * explow.c (plus_constant): Likewise. * fixed-value.c (fixed_saturate1, fixed_saturate2) (do_fixed_add, do_fixed_multiply, do_fixed_multiply) (do_fixed_multiply, do_fixed_multiply, do_fixed_divide) (do_fixed_divide, do_fixed_divide, do_fixed_divide) (do_fixed_divide, do_fixed_divide, do_fixed_shift, do_fixed_shift) (do_fixed_shift, fixed_convert, fixed_convert) (fixed_convert_from_int, fixed_convert_from_int) (fixed_convert_from_real): Likewise. * fold-const.c (fold_convert_const_int_from_fixed, sign_bit_p) (native_interpret_int, fold_binary_loc, fold_ternary_loc): Likewise. * varasm.c (output_constructor_bitfield): Likewise. * tree-vrp.c (register_edge_assert_for_2): Likewise. * double-int.c (rshift_double, lshift_double): Likewise. * double-int.h (double_int_fits_in_uhwi_p, double_int, double_int): Likewise. * simplify-rtx.c (mode_signbit_p) (simplify_const_unary_operation, simplify_binary_operation_1) (simplify_immed_subreg): Likewise. * builtins.c (c_readstr, fold_builtin_bitop): Likewise. * tree-vect-generic.c (build_replicated_const): Likewise. * dbxout.c (stabstr_O): Likewise. * emit-rtl.c (immed_double_int_const, immed_double_const) (gen_lowpart_common, init_emit_once): Likewise. * tree.c (integer_pow2p, tree_log2, tree_floor_log2) (widest_int_cst_value, upper_bound_in_type): Likewise. * stor-layout.c (initialize_sizetypes, fixup_signed_type) (fixup_unsigned_type): Likewise. * real.c (real_to_integer2, real_from_integer): Likewise. * dwarf2out.c (size_of_loc_descr, size_of_die, output_die) (clz_loc_descriptor, mem_loc_descriptor): Likewise.
Re: [Fortran, DRAFT patch] PR 46321 - [OOP] Polymorphic deallocation
Hi Alessandro, I have realized a draft patch for the PR 46321, currently it works only with the explicit DEALLOCATE. thanks for the patch! Some first comments without actually looking at the patch in detail ... Running the regression tests it doesn't pass the following: - gfortran.dg/class_19.f03 (too much __builtin_free) - gfortran.dg/auto_dealloc_2.f90 (too much __builtin_free) - gfortran.dg/dynamic_dispatch_4.f03 (free on invalid pointer) - gfortran.dg/typebound_operator_9.f03 (fails during the execution test) The first two tests fail due to the introduction of __builtin_free in the freeing functions, so it is not a problem. Right. You should certainly fix the scan-tree-dump-times checks (by adjusting the numbers properly, and making sure that they are actually what one would expect), in order to make them pass. The gfortran.dg/dynamic_dispatch_4.f03 had this problem in the past (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986); currently it calls the __free_s_bar_mod_S_bar function instead of the proper doit(). Sorry, I don't understand the last sentence. Why should it call some __free... instead of doit? And why is that test case even affected by your patch (you said it would only work with explicit DEALLOCATE, which does not appear in that test case)? Regarding typebound_operator_9.f03, I don't know how to fix the patch... Unfortunately that test case is rather large, so maybe you should reduce it a bit to find the error (or just do some debugging in order to find out where exactly it fails). Another possibility: Compare the dump (using -fdump-tree-original) with and without the patch. The patch is written in a raw way due to my newbieness, so any suggestion is well accepted. The patch actually gives a few warnings: /home/jweil/gcc48/trunk/gcc/fortran/class.c: In function ‘gfc_find_derived_vtab’: /home/jweil/gcc48/trunk/gcc/fortran/class.c:912:8: warning: ISO C90 forbids mixed declarations and code [-pedantic] /home/jweil/gcc48/trunk/gcc/fortran/class.c:932:7: warning: C++ style comments are not allowed in ISO C90 [enabled by default] /home/jweil/gcc48/trunk/gcc/fortran/class.c:932:7: warning: (this will be reported only once per input file) [enabled by default] (and similar things in trans-stmt.c). You should definitely fix those. Although a non-buildstrap build still works with those warnings, a full bootstrap will fail. Cheers, Janus
Re: [PATCH 2/2] Better system header location detection for built-in macro tokens
Hi, - /* Build the assignment expression. */ + /* Build the assignment expression. Its default + location is the location of the '=' token. */ + input_location = loc; expr = build_x_modify_expr (loc, expr, assignment_operator, rhs, Now I have one more reason to be interested in this issue ;) Background: as you may have noticed, I'm working on replacing the various build_min* functions used by the various build_x_* functions with _loc variants. One of the problems I'm facing with replacing completely one of them has to do exactly with assignment expressions and the location of the error we get for a library testcase not having the location of the left hand side, as it does now, after the patch. Thus, in short, your change here may well help me as-is ;) That said, the tricks we are playing with the global input_location vs the loc we are passing around still confuse me quite a lot. Actually any *assignment* to input_location makes me a bit more nervous than I was already ;) Do you have any idea whether just passing down to build_x_modify_expr a different value for loc instead of assigning to input_location would also work for you? Maybe together with more throughly forwarding the loc from build_x_modify_expr itself to the build_min* functions (ie the project I mentioned above)?? In any case in a day or two I'll let you know how whether your patch as-is works well for the specific issue I'm facing and anyway I will send over the actual work in progress patch which I can't submit because of the regression it would cause. Thanks, Paolo
Re: [Fortran, DRAFT patch] PR 46321 - [OOP] Polymorphic deallocation
Hi Janus,
Sorry, I don't understand the last sentence. Why should it call some
__free... instead of doit? And why is that test case even affected
by your patch (you said it would only work with explicit DEALLOCATE,
which does not appear in that test case)?
Yes, it is as I said... In
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986#c4 the doit() call
produces a segfault because r26 is 0 instead of the address of
__s_bar_mod_MOD_doit. With my patched version, the doit call is in
reality a _free __free_s_bar_mod_S_bar call. To better understand I
report a little portion (only the MAIN__) of the fdump-tree-original
and the testcase execution (hoping that it will be understandable...)
MAIN__ ()
{
struct __class_foo_mod_Foo_p a;
struct foo b;
static struct s_bar c = {};
static struct a_bar d = {};
try
{
c.a = 0B;
d.a.data = 0B;
(struct __vtype_foo_mod_Foo *) a._vptr = __vtab_foo_mod_Foo;
a._data = b;
a._vptr-doit (a);
if (a._vptr-getit (a) != 1)
{
_gfortran_abort ();
}
L.1:;
(struct __vtype_foo_mod_Foo *) a._vptr = (struct
__vtype_foo_mod_Foo *) __vtab_s_bar_mod_S_bar;
a._data = (struct foo *) c;
a._vptr-doit (a); IT REALLY WANTS TO CALL THE DOIT FUNCTION!
if (a._vptr-getit (a) != 2)
{
_gfortran_abort ();
}
L.2:;
(struct __vtype_foo_mod_Foo *) a._vptr = (struct
__vtype_foo_mod_Foo *) __vtab_a_bar_mod_A_bar;
a._data = (struct foo *) d;
a._vptr-doit (a);
if (a._vptr-getit (a) != 3)
{
_gfortran_abort ();
}
L.3:;
}
finally
{
if (d.a.data != 0B)
{
__builtin_free ((void *) d.a.data);
}
d.a.data = 0B;
if (c.a != 0B)
{
__builtin_free ((void *) c.a);
}
c.a = 0B;
}
}
An now the testcase execution with gdb:
Breakpoint 1, MAIN__ () at dynamic_dispatch_4.f03:82
82type(s_bar), target :: c
(gdb) next
83type(a_bar), target :: d
(gdb)
85a = b
(gdb)
86call a%doit
(gdb)
87if (a%getit () .ne. 1) call abort
(gdb)
88a = c
(gdb) step
89call a%doit
(gdb)
s_bar_mod::__free_s_bar_mod_S_bar (tofree=...) at dynamic_dispatch_4.f03:43
43 class(s_bar) :: a
I don't know if I got it across...
The patch actually gives a few warnings:
Ok, thanks. I always use bootstrap and it works but I never look at
the compile result (unless it doesn't compile...)
Re: [Fortran, DRAFT patch] PR 46321 - [OOP] Polymorphic deallocation
Hi, Sorry, I don't understand the last sentence. Why should it call some __free... instead of doit? And why is that test case even affected by your patch (you said it would only work with explicit DEALLOCATE, which does not appear in that test case)? Yes, it is as I said... In http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986#c4 the doit() call produces a segfault because r26 is 0 instead of the address of __s_bar_mod_MOD_doit. With my patched version, the doit call is in reality a _free __free_s_bar_mod_S_bar call. huh, this is strange, indeed. I guess it means that something is messed up in the vtable (some sort of offset?). We try to call one virtual function, but we get another. Since this problem was already seen in PR43986, it is probably a case of your patch uncovering an existing bug. I'll try to look into this problem soon ... Cheers, Janus
Re: [google] Add options to pattern match function name for hotness attributes
On Sat, Jun 2, 2012 at 3:06 AM, Jan Hubicka hubi...@ucw.cz wrote: On Sat, Jun 2, 2012 at 2:36 AM, Jan Hubicka hubi...@ucw.cz wrote: Hi, This patch adds 4 flags to enable user to type in a list of name patterns. Compiler will match the function name with the given patterns, and add hot, cold, likely_hot, likely_cold attributes to function declaration. The static branch prediction checks if a basic block contains call to a annotated function, and set the branch probability accordingly. Bootstrapped and passed gcc testsuites. Ok for google branches? Just out of curiosity, what is main advantage of this over annotating your source? This is to avoid too much annotation at source level. Some applications have good per application knowledge of library functions (that are compiled and statically linked in). Another example of its -- coarse grain (function level) profile data collected from data center can be used to guide branch prediction/estimation. Well, perhaps the feature would be more useful with command line option allowing to add an attribute instead of having special case command line options for individual cases. I guess the problem would be also solvable with header included after the library adding the attributes to the declarations I think this is a good idea. typeof (printf) printf __attribute__ ((cold)); Actually Dehao also plans to teach the static predictor to understand standard library functions more (e.g IO functions) and add more naming based heuristics such as 'error, success, failure, fatal etc). thanks, David Honza thanks, David Honza
Re: [Fortran, DRAFT patch] PR 46321 - [OOP] Polymorphic deallocation
Janus Weil wrote: The patch actually gives a few warnings: Looking at those warnings, they seem to be valid C++ but invalid C89. As Stages 2 and 3 are, by default, compiled by C++, I assume that Alessandro does not see those. By contrast, I assume that you (Janus) build GCC with the C compiler, i.e. you configure with --disable-build-poststage1-with-cxx. Thus, a default boot strap, shouldn't fail. Nonetheless, it is useful to keep compatibility with C and bootstrapping with --disable-build-poststage1-with-cxx.Hence, the warnings should be fixed. (Bootstrapping implies -Werror.) Tobias /home/jweil/gcc48/trunk/gcc/fortran/class.c: In function ‘gfc_find_derived_vtab’: /home/jweil/gcc48/trunk/gcc/fortran/class.c:912:8: warning: ISO C90 forbids mixed declarations and code [-pedantic] /home/jweil/gcc48/trunk/gcc/fortran/class.c:932:7: warning: C++ style comments are not allowed in ISO C90 [enabled by default] /home/jweil/gcc48/trunk/gcc/fortran/class.c:932:7: warning: (this will be reported only once per input file) [enabled by default] (and similar things in trans-stmt.c). You should definitely fix those. Although a non-buildstrap build still works with those warnings, a full bootstrap will fail.
Re: [google] Add options to pattern match function name for hotness attributes
Based on Honza's feedback, I think it is bettre to add command line interface such as this: -ffunction-attribute-list=attribute_name:function_pattern_list or -ffunction-attribute-filelist=attribute_name:function_pattern_list_filename e.g, -ffunction-attribute-list=code:foo1,foo2,bar_*,blah It probably needs to be processed as deferred option to allow other option to be translated into this form -- for instance extracted from some global profile data. thanks, David On Sat, Jun 2, 2012 at 7:16 AM, Dehao Chen de...@google.com wrote: On Sat, Jun 2, 2012 at 9:17 PM, Jan Hubicka hubi...@ucw.cz wrote: Well, perhaps the feature would be more useful with command line option allowing to add an attribute instead of having special case command line options for individual cases. Hi, Honza, I'm not sure what you mean by command line option allowing to add an attribution. But this seems what this patch does: it adds attributes to functions with specified name patterns. I mean that if we want to go this route, we may want to allow this interface to i.e. add always_inline attrbute or noinline or such. I can imagine this to be useful especially for languages that has no attributes. This annotation is mainly for static branch prediction. Some functions may be very cold, but it may still be good to inline it. I guess the problem would be also solvable with header included after the library adding the attributes to the declarations typeof (printf) printf __attribute__ ((cold)); Do you mean that for each specific application, we extract a common header file to include all function annotations, and all source files will include this header file? Yes, something like that... Where do you use the likely_hot/likely_cold logic? For really cold functions, we predict the branch to be 0.04% taken. However, some callee functions are not that extremely cold, and predicting them as 0.04% is too aggressive. Likely_cold is for such functions, and we predict them as 25% taken (at least we can predict the direction right). Vise versa for likely_hot annotation. Thanks, Dehao Honza Thanks, Dehao Honza thanks, David Honza
Re: [google] Add options to pattern match function name for hotness attributes
Actually Dehao also plans to teach the static predictor to understand standard library functions more (e.g IO functions) and add more naming How this differ from annotating the library? There are indeed quite some possibilities to do about library calls One thing I always wondered about is how to tell predictor that paths containing heavy IO functions don't need to be really opimized to death, since their execution time is dominated by the IO... based heuristics such as 'error, success, failure, fatal etc). yeah, this is also mentioned by some branch prediction papers. It is bit kludgy in nature (i.e. it won't understand programs written in Czech language) but it is an heuristics after all. Honza thanks, David Honza thanks, David Honza
Re: [Fortran, DRAFT patch] PR 46321 - [OOP] Polymorphic deallocation
Alessandro Fanfarillo wrote: The gfortran.dg/dynamic_dispatch_4.f03 had this problem in the past (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986); currently it calls the __free_s_bar_mod_S_bar function instead of the proper doit(). That kind of makes sense: foo has no allocatable components while s_bar has. Seemingly, foo has no _free component - and thus, the first entry in vtab after _hash, _size, _extends, _def_init and _copy is doit. However, s_bar has at that position not doit but _free. My impression is that you do not add a _free = null() (EXPR_NULL) in the case that there are no allocatable components in the type or its parents. Side note: In class.c, please update the comment at the top by mentioning _free after the description of _copy. Tobias
Re: [Fortran, DRAFT patch] PR 46321 - [OOP] Polymorphic deallocation
Hi, By contrast, I assume that you (Janus) build GCC with the C compiler, i.e. you configure with --disable-build-poststage1-with-cxx. actually I used --disable-bootstrap, which also has the effect that gfortran is built with the C compiler. Thus, a default boot strap, shouldn't fail. Nonetheless, it is useful to keep compatibility with C and bootstrapping with --disable-build-poststage1-with-cxx.Hence, the warnings should be fixed. (Bootstrapping implies -Werror.) Right. I'm not sure what the further plans are for GCC regarding the C vs C++ issue, but as long as GCC can still be built with a C compiler, one should probably avoid unnecessary C++isms. Cheers, Janus /home/jweil/gcc48/trunk/gcc/fortran/class.c: In function ‘gfc_find_derived_vtab’: /home/jweil/gcc48/trunk/gcc/fortran/class.c:912:8: warning: ISO C90 forbids mixed declarations and code [-pedantic] /home/jweil/gcc48/trunk/gcc/fortran/class.c:932:7: warning: C++ style comments are not allowed in ISO C90 [enabled by default] /home/jweil/gcc48/trunk/gcc/fortran/class.c:932:7: warning: (this will be reported only once per input file) [enabled by default] (and similar things in trans-stmt.c). You should definitely fix those. Although a non-buildstrap build still works with those warnings, a full bootstrap will fail.
Re: [Fortran, DRAFT patch] PR 46321 - [OOP] Polymorphic deallocation
2012/6/2 Tobias Burnus bur...@net-b.de: Alessandro Fanfarillo wrote: The gfortran.dg/dynamic_dispatch_4.f03 had this problem in the past (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986); currently it calls the __free_s_bar_mod_S_bar function instead of the proper doit(). That kind of makes sense: foo has no allocatable components while s_bar has. Seemingly, foo has no _free component - and thus, the first entry in vtab after _hash, _size, _extends, _def_init and _copy is doit. However, s_bar has at that position not doit but _free. Right, the problem is that the _free component is missing. Just as the _copy component, _free should be present for *every* vtype, no matter if there are allocatable components or not. If the _free component is not needed, it should be initialized to EXPR_NULL. Cheers, Janus
Re: [PATCH 2/2] Better system header location detection for built-in macro tokens
On 06/02/2012 12:40 PM, Paolo Carlini wrote:
That said, the tricks we are playing with the global input_location vs the loc
we are passing around still confuse me quite a lot. Actually any *assignment*
to input_location makes me a bit more nervous than I was already ;) Do you have
any idea whether just passing down to build_x_modify_expr a different value for
loc instead of assigning to input_location would also work for you? Maybe
together with more throughly forwarding the loc from build_x_modify_expr itself
to the build_min* functions (ie the project I mentioned above)??
We already pass to build_x_modify_expr the location that he is assigning
to input_location. I would guess that the issue in this case is with
the in_system_header macro, which uses input_location.
I think the input_location hack here is OK until we improve our use of
explicit locations to make it unnecessary.
- s = s; // { dg-message synthesized|deleted }
+ s = s;
Why do we lose this error?
Jason
Re: [SH] PR 53512 - Allow fsca and fsrra for non-SH4A
Oleg Endo oleg.e...@t-online.de wrote: The attached patch should fix the issue, by folding the existing sinsf2 and cossf2 expanders into a single sincossf3. I ran the test cases again with TARGET_HAS_SINCOS set to '1' and to '0' and they pass. OK for trunk. Regards, kaz
Re: [google] Add options to pattern match function name for hotness attributes
On Sat, Jun 2, 2012 at 11:11 AM, Jan Hubicka hubi...@ucw.cz wrote: Actually Dehao also plans to teach the static predictor to understand standard library functions more (e.g IO functions) and add more naming How this differ from annotating the library? I find them more suitable to be compiler heuristic than being function's attribute -- attribute is a much stronger assertion. There are indeed quite some possibilities to do about library calls One thing I always wondered about is how to tell predictor that paths containing heavy IO functions don't need to be really opimized to death, since their execution time is dominated by the IO... Yes -- if branch predictor does the right thing and if function splitter is powerful enough, the IO code can be outlined and optimized for size :) based heuristics such as 'error, success, failure, fatal etc). yeah, this is also mentioned by some branch prediction papers. It is bit kludgy in nature (i.e. it won't understand programs written in Czech language) but it is an heuristics after all. right. thanks, David Honza thanks, David Honza thanks, David Honza
Re: [C++ Patch] for c++/51214
On 05/24/2012 09:18 AM, Jason Merrill wrote: OK, thanks. I notice you haven't checked the patch in yet, is there a problem? Jason
Re: [gcov] a few improvements
On Fri, Dec 30, 2011 at 10:25 AM, Nathan Sidwell nat...@acm.org wrote: I've committed this patch to fix and improve coverage reporting: 1) the time stamp local_tick will be -1 if the user overrides the random seed. In such cases the gcov data file should be deleted, just as it would if the time cannot be determined. The end result is that after a the profile data is used in the compilation (with option -fprofile-use -frandom-seed=), it is then deleted. Is this intended? This basically makes FDO very hard to use when -frandom-seed is used. David 2) there was a typo in gcov_dump when dumping function data 3) when processing coverage data files, it's informative for gcov to emit the overall line coverage -- in addition to the individual line coverage. built tested on i686-pc-linux-gnu nathan
