[PATCH, Committed] Fix ChangeLog (was: [PATCH] Fix AVR fallout)
On Sun, 2012-08-19 10:19:37 +0400, Denis Chertykov wrote: > 2012/8/18 Jan-Benedict Glaw : [...] > > gcc/Changelog: > > * config/avr/avr-log.c (avr_log_vadump): Properly use > > int-promoted enum values. > > * config/avr/avr.h (struct mcu_type_s): Change `arch' from > > int to enum avr_arch. > > * config/avr/gen-avr-mmcu-texi.c (main): Use correct initializer. > > Thank you for the fix. > Committed. I fixed ChangeLog's whitespace (probably cut'n'paste error), committed as obvious. 2012-08-19 Jan-Benedict Glaw * ChangeLog: Fix whitespace. Index: ChangeLog === --- ChangeLog (revision 190511) +++ ChangeLog (working copy) @@ -5,11 +5,11 @@ 2012-08-18 Jan-Benedict Glaw -* config/avr/avr-log.c (avr_log_vadump): Properly use -int-promoted enum values. -* config/avr/avr.h (struct mcu_type_s): Change `arch' from -int to enum avr_arch. -* config/avr/gen-avr-mmcu-texi.c (main): Use correct initializer. + * config/avr/avr-log.c (avr_log_vadump): Properly use + int-promoted enum values. + * config/avr/avr.h (struct mcu_type_s): Change `arch' from + int to enum avr_arch. + * config/avr/gen-avr-mmcu-texi.c (main): Use correct initializer. 2012-08-18 Jan Hubicka -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Zensur im Internet? Nein danke! the second : signature.asc Description: Digital signature
Re: [bootstrap] Tentative fix for PR 54281
[Sorry for the delay]
> So, I had failed to include Ada in my testing and my patch breaks it.
> In several ada/*.c files, we forcefully include system.h as a C header:
>
> #ifdef __cplusplus
> extern "C" {
> #endif
> ...
> #include "system.h"
> ...
> #ifdef __cplusplus
> }
> #endif
>
>
> Eric, is this really needed now? We are including gmp.h from system.h
> due to PR 54281. This is causing Ada builds to fail.
>
> Would it be OK to remove all the '#ifdef __cplusplus' conditionals from
> ada/*.c or is there something I'm missing?
The conditionals cannot be removed for the time being because the foreign
language interface of the Ada part of the compiler is hardcoded for C.
Barring a massive switch to the Ada language for the GNU project, we would need
to switch the foreign language interface to C++, which might introduce various
maintenance issues in the short term (Arno CCed).
--
Eric Botcazou
[committed] cp/Make-lang.in typo fix
Hello, this is outside my area of maintainership, but I thought it was obvious enough. Mikael Index: Make-lang.in === --- Make-lang.in (révision 190512) +++ Make-lang.in (révision 190513) @@ -337,7 +337,7 @@ cp/mangle.o: cp/mangle.c $(CXX_TREE_H) $(TM_H) $(R gt-cp-mangle.h $(TARGET_H) $(TM_P_H) $(CGRAPH_H) cp/parser.o: cp/parser.c $(CXX_TREE_H) $(TM_H) $(DIAGNOSTIC_CORE_H) \ gt-cp-parser.h $(TARGET_H) $(PLUGIN_H) intl.h \ - c-family/c-objc.h tree-pretty-print.h $(CXX_PARSER_H) $(TIMEVAR.H) + c-family/c-objc.h tree-pretty-print.h $(CXX_PARSER_H) $(TIMEVAR_H) cp/cp-gimplify.o: cp/cp-gimplify.c $(CXX_TREE_H) $(C_COMMON_H) \ $(TM_H) coretypes.h pointer-set.h tree-iterator.h $(SPLAY_TREE_H) Index: ChangeLog === --- ChangeLog (révision 190512) +++ ChangeLog (révision 190513) @@ -1,3 +1,7 @@ +2012-08-19 Mikael Morin + + * Make-lang.in: Fix typo. + 2012-08-17 Jakub Jelinek * cp-tree.def (SIZEOF_EXPR): Move to c-common.def.
[patch, fortran] Warning for feal / complex equality / inequality comparisons
Hello world,
the attached patch warns about comparisions for equality and inequality
of real and complex values if -Wcompare-reals is given. The new
compiler option is included in -Wall.
Regression-tested, tested with "make info" and "make dvi".
OK for trunk?
Thomas
2012-08-19 Thomas König
PR fortran/54298
* gfortran.h (struct gfc_option_t): Add warn_compare_reals.
* lang.opt: Add Wcompare-reals.
* invoke.texi: Document -Wcompare-reals.
* resolve.c (resolve_operator): If -Wcompare-reals is in effect,
warn about equality/inequality comparisions for REAL and COMPLEX.
* options.c (gfc_init_options): Set warn_compare_reals.
(set_Wall): Include warn_compare_reals in Wall.
(gfc_handle_option): Handle Wcompare_reals.
2012-08-19 Thomas König
PR fortran/54298
* gfortran.dg/real_compare_1.f90: New test case.
* gfortran.dg/bessel_5.f90 Add -Wno-compare-reals to options.
Index: testsuite/gfortran.dg/bessel_5.f90
===
--- testsuite/gfortran.dg/bessel_5.f90 (Revision 190442)
+++ testsuite/gfortran.dg/bessel_5.f90 (Arbeitskopie)
@@ -1,5 +1,5 @@
! { dg-do run }
-! { dg-options "-Wall -fno-range-check" }
+! { dg-options "-Wall -fno-range-check -Wno-compare-reals" }
!
! PR fortran/36158 - Transformational BESSEL_JN/YN
! PR fortran/33197 - F2008 math functions
Index: fortran/gfortran.h
===
--- fortran/gfortran.h (Revision 190442)
+++ fortran/gfortran.h (Arbeitskopie)
@@ -2225,6 +2225,7 @@ typedef struct
int warn_unused_dummy_argument;
int warn_realloc_lhs;
int warn_realloc_lhs_all;
+ int warn_compare_reals;
int max_errors;
int flag_all_intrinsics;
Index: fortran/lang.opt
===
--- fortran/lang.opt (Revision 190442)
+++ fortran/lang.opt (Arbeitskopie)
@@ -218,6 +218,10 @@ Wcharacter-truncation
Fortran Warning
Warn about truncated character expressions
+Wcompare-reals
+Fortran Warning
+Warn about equality comparisons involving REAL or COMPLEX expressions
+
Wconversion
Fortran Warning
; Documented in C
Index: fortran/invoke.texi
===
--- fortran/invoke.texi (Revision 190442)
+++ fortran/invoke.texi (Arbeitskopie)
@@ -726,10 +726,11 @@ warnings.
@cindex warnings, all
Enables commonly used warning options pertaining to usage that
we recommend avoiding and that we believe are easy to avoid.
-This currently includes @option{-Waliasing}, @option{-Wampersand},
-@option{-Wconversion}, @option{-Wsurprising}, @option{-Wintrinsics-std},
-@option{-Wno-tabs}, @option{-Wintrinsic-shadow}, @option{-Wline-truncation},
-@option{-Wreal-q-constant} and @option{-Wunused}.
+This currently includes @option{-Waliasing}, @option{-Wampersand},
+@option{-Wconversion}, @option{-Wcompare-reals}, @option{-Wsurprising},
+@option{-Wintrinsics-std}, @option{-Wno-tabs}, @option{-Wintrinsic-shadow},
+@option{-Wline-truncation}, @option{-Wreal-q-constant} and
+@option{-Wunused}.
@item -Waliasing
@opindex @code{Waliasing}
@@ -935,6 +936,11 @@ a scalar. See also @option{-frealloc-lhs}.
Warn when the compiler inserts code to for allocation or reallocation of an
allocatable variable; this includes scalars and derived types.
+@item -Wcompare-reals
+@opindex @code{Wcompare-reals}
+Warn when comparing real or complex types for equality or inequality.
+Enabled by @option{-Wall}.
+
@item -Werror
@opindex @code{Werror}
@cindex warnings, to errors
Index: fortran/resolve.c
===
--- fortran/resolve.c (Revision 190442)
+++ fortran/resolve.c (Arbeitskopie)
@@ -4034,6 +4034,27 @@ resolve_operator (gfc_expr *e)
e->ts.type = BT_LOGICAL;
e->ts.kind = gfc_default_logical_kind;
+
+ if (gfc_option.warn_compare_reals)
+ {
+ gfc_intrinsic_op op = e->value.op.op;
+
+ if ((op1->ts.type == BT_REAL || op1->ts.type == BT_COMPLEX)
+ && (op == INTRINSIC_EQ || op == INTRINSIC_EQ_OS
+ || op == INTRINSIC_NE || op == INTRINSIC_NE_OS))
+ {
+ bool equality;
+
+ equality = op == INTRINSIC_EQ || op == INTRINSIC_EQ_OS;
+
+ /* Type conversion has made sure that the types
+ of op1 and op2 agree. */
+ gfc_warning ("%s comparison for %s at %L",
+ equality ? "Equality" : "Inequality",
+ gfc_typename (&op1->ts), &op1->where);
+ }
+ }
+
break;
}
Index: fortran/options.c
===
--- fortran/options.c (Revision 190442)
+++ fortran/options.c (Arbeitskopie)
@@ -113,6 +113,7 @@ gfc_init_options (unsigned int decoded_options_cou
gfc_option.warn_unused_dummy_argument = 0;
gfc_option.warn_realloc_lhs = 0;
gfc_option.warn_realloc_lhs_all = 0;
+ gfc_option.warn_compare_rea
Re: [bootstrap] Tentative fix for PR 54281
> The conditionals cannot be removed for the time being because the foreign > language interface of the Ada part of the compiler is hardcoded for C. > > Barring a massive switch to the Ada language for the GNU project, we would > need > to switch the foreign language interface to C++, which might introduce > various > maintenance issues in the short term (Arno CCed). Yes, that would be a large hearthquake for both the compiler and the run-time, which is unwanted at this stage. I guess the solution for now is to more selectively export the various symbols as C symbols and include header files as is. Arno
Re: [patch, fortran] Warning for feal / complex equality / inequality comparisons
Thomas Koenig wrote:
the attached patch warns about comparisions for equality and inequality
of real and complex values if -Wcompare-reals is given. The new
compiler option is included in -Wall.
Regression-tested, tested with "make info" and "make dvi".
OK for trunk?
Thanks for the patch. It's okay, after fixing the nits below.
+ if (gfc_option.warn_compare_reals)
+ {
+ gfc_intrinsic_op op = e->value.op.op;
+
+ if ((op1->ts.type == BT_REAL || op1->ts.type == BT_COMPLEX)
+ && (op == INTRINSIC_EQ || op == INTRINSIC_EQ_OS
+ || op == INTRINSIC_NE || op == INTRINSIC_NE_OS))
+ {
+ bool equality;
+
+ equality = op == INTRINSIC_EQ || op == INTRINSIC_EQ_OS;
+
+ /* Type conversion has made sure that the types
+of op1 and op2 agree. */
+ gfc_warning ("%s comparison for %s at %L",
+ equality ? "Equality" : "Inequality",
+ gfc_typename (&op1->ts), &op1->where);
Can you move up the comment before the "(op1->ts.type"? When reading the
patch, I stumbled over that, before reading 8 lines later that checking
op1 is sufficient.
Additionally, your gfc_warning is rather unfriendly to translators (try
yourself to translate it, taking into account that the "Equality" string
might be re-used elsewhere). I think it is better to have two separate
strings, one for equality and one for inequality.
Tobias
[Ada] Fix temporary incorrectly-typed COMPONENT_REF
We generate a temporary incorrectly-typed COMPONENT_REF in gigi when building a
derived tagged type with discriminant. That's essentially harmless, but breaks
the invariant that the type of the first operand of COMPONENT_REF is aggregate.
Tested on x86_64-suse-linux, applied on the mainline.
2012-08-19 Eric Botcazou
* gcc-interface/decl.c (gnat_to_gnu_entity) : Use proper
dummy type for the temporary COMPONENT_REF built for a derived tagged
type with discriminant.
--
Eric Botcazou
Index: gcc-interface/decl.c
===
--- gcc-interface/decl.c (revision 190510)
+++ gcc-interface/decl.c (working copy)
@@ -2988,6 +2988,7 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
if (Present (Parent_Subtype (gnat_entity)))
{
Entity_Id gnat_parent = Parent_Subtype (gnat_entity);
+ tree gnu_dummy_parent_type = make_node (RECORD_TYPE);
tree gnu_parent;
/* A major complexity here is that the parent subtype will
@@ -2999,11 +3000,11 @@ gnat_to_gnu_entity (Entity_Id gnat_entit
each of those discriminants to a COMPONENT_REF of the above
dummy parent referencing the corresponding discriminant of the
base type of the parent subtype. */
- gnu_get_parent = build3 (COMPONENT_REF, void_type_node,
+ gnu_get_parent = build3 (COMPONENT_REF, gnu_dummy_parent_type,
build0 (PLACEHOLDER_EXPR, gnu_type),
build_decl (input_location,
FIELD_DECL, NULL_TREE,
- void_type_node),
+ gnu_dummy_parent_type),
NULL_TREE);
if (has_discr)
[Ada] Avoid unnecessarily overaligned access types
This changes the default alignment of all access types to that of access types
with standard size (Standard'Address_Size) on non-strict-alignment platforms.
This in particular means that access-to-unconstrained-array types, whose size
is twice as large as that of regular access types, are not overaligned by
default anymore and therefore don't cause unnecessary padding in record types.
The following program must run quietly on these platforms:
procedure P is
type Array_T is array (Positive range <>) of Integer;
type Access_Array_T is access Array_T;
type Thin_Access_Array_T is access Array_T;
for Thin_Access_Array_T'Size use Standard'Address_Size;
begin
if Access_Array_T'Alignment /= Thin_Access_Array_T'Alignment then
raise Program_Error;
end if;
end;
Tested on x86_64-suse-linux, applied on the mainline.
2012-08-19 Eric Botcazou
* layout.adb (Set_Elem_Alignment): Cap the alignment of access types to
that of a regular access type for non-strict-alignment platforms.
* gcc-interface/utils.c (finish_fat_pointer_type): Do not set the
alignment for non-strict-alignment platforms.
--
Eric Botcazou
Index: layout.adb
===
--- layout.adb (revision 190510)
+++ layout.adb (working copy)
@@ -3118,6 +3118,19 @@ package body Layout is
if Esize (E) / SSU > Ttypes.Maximum_Alignment then
S := Ttypes.Maximum_Alignment;
+
+ -- If this is an access type and the target doesn't have strict
+ -- alignment and we are not doing front end layout, then cap the
+ -- alignment to that of a regular access type. This will avoid
+ -- giving fat pointers twice the usual alignment for no practical
+ -- benefit since the misalignment doesn't really matter.
+
+ elsif Is_Access_Type (E)
+ and then not Target_Strict_Alignment
+ and then not Frontend_Layout_On_Target
+ then
+S := System_Address_Size / SSU;
+
else
S := UI_To_Int (Esize (E)) / SSU;
end if;
Index: gcc-interface/utils.c
===
--- gcc-interface/utils.c (revision 190510)
+++ gcc-interface/utils.c (working copy)
@@ -1369,7 +1369,8 @@ void
finish_fat_pointer_type (tree record_type, tree field_list)
{
/* Make sure we can put it into a register. */
- TYPE_ALIGN (record_type) = MIN (BIGGEST_ALIGNMENT, 2 * POINTER_SIZE);
+ if (STRICT_ALIGNMENT)
+TYPE_ALIGN (record_type) = MIN (BIGGEST_ALIGNMENT, 2 * POINTER_SIZE);
/* Show what it really is. */
TYPE_FAT_POINTER_P (record_type) = 1;
[Patch, Fortran] PR54301 - add warning for pointer might outlive its target
As suggested in the draft Fortran appendix to ISO/IEC Technical Report
24772 "Guidance for Avoiding Vulnerabilities through Language Selection
and Use"*
"Future standardization efforts should consider:"
...
"* Requiring that processors have the ability to detect and report the
occurrence within a submitted program unit of pointer assignment of
a pointer whose lifetime is known to be longer than the lifetime of the
target."
The new flag -Wtarget-lifetime implements this; it is enabled by -Wall.
(Well, at least kind of; the suggested requirement is only implementable
by a complicated run-time check. However, the attached compile-time
warning is a good approximation, which should help to find real bugs
with only few false positives.)
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
* See
http://gcc.gnu.org/wiki/GFortranStandards#ISO.2BAC8-IEC_Project_22.24772:_Guidance_for_Avoiding_Vulnerabilities_through_Language_Selection_and_Use
2012-08-19 Tobias Burnus
PR fortran/54301
* expr.c (gfc_check_pointer_assign): Warn when the pointer
might outlive its target.
* gfortran.h (struct gfc_option_t): Add warn_target_lifetime.
* options.c (gfc_init_options, set_wall, gfc_handle_option):
handle it.
* invoke.texi (-Wtarget-lifetime): Document it.
(-Wall): Implied it.
* lang.opt (-Wtarget-lifetime): New flag.
2012-08-19 Tobias Burnus
PR fortran/54301
* gfortran.dg/warn_target_lifetime_1.f90: New.
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 7d74528..d94afb7 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3659,6 +3659,37 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *rvalue)
}
}
+ /* Warn if it is the LHS pointer may lives longer than the RHS target. */
+ if (gfc_option.warn_target_lifetime
+ && rvalue->expr_type == EXPR_VARIABLE
+ && !rvalue->symtree->n.sym->attr.save
+ && !attr.pointer && !rvalue->symtree->n.sym->attr.host_assoc
+ && !rvalue->symtree->n.sym->attr.in_common
+ && !rvalue->symtree->n.sym->attr.use_assoc
+ && !rvalue->symtree->n.sym->attr.dummy)
+{
+ bool warn;
+ gfc_namespace *ns;
+
+ warn = lvalue->symtree->n.sym->attr.dummy
+ || lvalue->symtree->n.sym->attr.result
+ || lvalue->symtree->n.sym->attr.host_assoc
+ || lvalue->symtree->n.sym->attr.use_assoc
+ || lvalue->symtree->n.sym->attr.in_common;
+
+ if (rvalue->symtree->n.sym->ns->proc_name
+ && rvalue->symtree->n.sym->ns->proc_name->attr.flavor != FL_PROCEDURE)
+ for (ns = rvalue->symtree->n.sym->ns;
+ ns->proc_name && ns->proc_name->attr.flavor != FL_PROCEDURE;
+ ns = ns->parent)
+ if (ns->parent == lvalue->symtree->n.sym->ns)
+ warn = true;
+
+ if (warn)
+ gfc_warning ("Pointer at %L in pointer assignment might outlive the "
+ "pointer target", &lvalue->where);
+}
+
return SUCCESS;
}
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index 7c4c0a4..308dbc1 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
unsigned select_type_temporary:1;
@@ -2225,6 +2226,7 @@ typedef struct
int warn_unused_dummy_argument;
int warn_realloc_lhs;
int warn_realloc_lhs_all;
+ int warn_target_lifetime;
int max_errors;
int flag_all_intrinsics;
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index 658ed23..edd9183 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -147,7 +147,7 @@ and warnings}.
-Wimplicit-procedure -Wintrinsic-shadow -Wintrinsics-std @gol
-Wline-truncation -Wno-align-commons -Wno-tabs -Wreal-q-constant @gol
-Wsurprising -Wunderflow -Wunused-parameter -Wrealloc-lhs Wrealloc-lhs-all @gol
--fmax-errors=@var{n} -fsyntax-only -pedantic -pedantic-errors
+-Wtarget-lifetime -fmax-errors=@var{n} -fsyntax-only -pedantic -pedantic-errors
}
@item Debugging Options
@@ -729,7 +729,7 @@ we recommend avoiding and that we believe are easy to avoid.
This currently includes @option{-Waliasing}, @option{-Wampersand},
@option{-Wconversion}, @option{-Wsurprising}, @option{-Wintrinsics-std},
@option{-Wno-tabs}, @option{-Wintrinsic-shadow}, @option{-Wline-truncation},
-@option{-Wreal-q-constant} and @option{-Wunused}.
+@option{-Wreal-q-constant}, @option{-Wtarget-lifetime} and @option{-Wunused}.
@item -Waliasing
@opindex @code{Waliasing}
@@ -935,6 +935,11 @@ a scalar. See also @option{-frealloc-lhs}.
Warn when the compiler inserts code to for allocation or reallocation of an
allocatable variable; this includes scalars and derived types.
+@item -Wtarget-lifetime
+@opindex @code{Wtargt-lifetime}
+Warn if the pointer in a pointer assignment might be longer than the its
+target. This option is implied by @option{-Wall}.
+
@item -Werror
@opindex @code{Werror}
@cindex warnings, to errors
diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt
index 3b9d29b..a721187 100644
--- a/gcc/fortran/lang.opt
+++ b/gcc/fortran/lang.opt
@@ -258,6 +258,10 @@ Wrealloc-lhs-all
Fortran Wa
Re: [graphds.h] Allocate graph from obstack
On Sat, Aug 18, 2012 at 8:10 PM, Dimitrios Apostolou wrote: > Initially I had one obstack per struct graph, which was better than using > XNEW for every edge, but still obstack_init() called from new_graph() was > too frequent. > > So in this iteration of the patch the obstack is static global, initialised > once and never freed. Please advise on whether this is acceptable, and also > where I should initialise the obstack once, and avoid checking if it's NULL > in every use. > > Minor speed gains (couple of ms), tested with pre-C++ conversion snapshot, > I'll retest soon and post update. Either an obstack per graph or the ability to specify an obstack for allocation. A global obstack with global lifetime is bad IMHO. Richard. > > Thanks, > Dimitris
Re: [PATCH/MIPS] Use ins/dins instruction when written manually
Andrew Pinski writes:
> Right now we only produce ins when a zero_extract is used on the
> right hand side. We can do better by adding some patterns which
> combine for the ins instruction. This patch adds those patterns and a
> testcase which shows a simple example where the code is improved.
Sorry for the delay in reviewing this. Had you thought about trying to
teach combine.c about this instead? It doesn't look like any of the
patterns are really providing more information about the underlying
instruction.
At the moment the patch has things like:
> +(define_insn "*insv_internal1"
> + [(set (match_operand:GPR 0 "register_operand" "=d")
> +(ior:GPR (and:GPR (match_operand:GPR 1 "register_operand" "0")
> + (match_operand:GPR 2 "const_int_operand" "i"))
> + (and:GPR (match_operand:GPR 3 "register_operand" "d")
> + (match_operand:GPR 4 "const_int_operand" "i"]
> + "ISA_HAS_EXT_INS && mips_bottom_bitmask_p (INTVAL (operands[4]))
> + && INTVAL(operands[2]) == ~INTVAL(operands[4])"
> +{
> + int len, pos;
> + pos = mips_bitmask (INTVAL (operands[4]), &len, mode);
> + operands[2] = GEN_INT (pos);
> + operands[4] = GEN_INT (len);
> + return "ins\t%0,%3,%2,%4";
> +}
> + [(set_attr "type" "arith")
> + (set_attr "mode" "")])
but AFAIK there's nothing to guarantee that the bottom bitmask
will be operand 2 rather than operand 4, so if we really do need
do this via patterns, I think we'd need both orderrs.
But if we do it this way, I assume every backend that provides
an insv pattern will need to cut-&-paste these patterns too.
Richard
Re: [wwwdocs] SH 4.8 changes update
On Sun, 19 Aug 2012, Oleg Endo wrote: > This is what has been done so far on the SH side for 4.8. > I hope it's OK. Wow, that is quite impressive (and a nice write-up also)! I see this was already approved, but allow me to suggest some minor editorial comments... Index: htdocs/gcc-4.8/changes.html === +The default alignment settings have been reduced to be less aggresive. "aggressive" + Minor tweaks for code around software atomic sequences that are + enabled by -msoft-atomic. "code for"? Not sure... + A new option -menable-tas will make the compiler + generate the tas.b instruction for the + __atomic_test_and_set built-in function. A naive question: Why is this not on by default? Or is it under certain circumstances? +The fmac instruction will now be emitted by the +fmaf standard and built-in function. "built-in standard function", perhaps? +The -mfused-madd option has been depricated in favor of "deprecated" +Added new options -mfsrra and -mfsca to allow +the compiler using the fsrra and fsca +instructions on CPUs other than SH4A. How about adding "...SH4A (where they are already on by default)" or similar? Gerald
Re: [PATCH, MIPS] add new peephole for 74k dspr2
Sandra Loosemore writes: > This patch adds a peephole optimization to use a clever trick to > zero-initialize the two halves of an accumulator register with one > instruction instead of a mtlo/mthi pair. OK to check in? > > -Sandra > > 2012-08-16 Sandra Loosemore > Julian Brown > MIPS Technologies, Inc. > > gcc/ > * config/mips/mips-dspr2.md (UNSPEC_ACC_INIT): Declare. > (mult peephole2): Add peephole that converts > "mtlo $ac[1-3],$0; mthi $ac[1-3],$0" into > "mult $ac[1-3],$0,$0". > (*mips_acc_init): New insn for above. Not sure whether a peephole is the right choice here. In practice, I'd imagine these opportunities would only come from a DImode move of $0 into a doubleword register, so we could simply emit the pattern in mips_split_doubleword_move. That would also allow us to use it for plain HI and LO. It wasn't obvious from the patch why it was restricted to the DSP extension registers. Please also add a scan-assembler test. Richard
Re: Commit: BFIN: Fix use of VEC_last macro in bfin.c
On Fri, 17 Aug 2012, Diego Novillo wrote: > Thanks. We need a much better mechanism for documenting and advertising > the stuff in contrib/. I see that contrib/ does not even have a README file. How about starting one with your contributions at least (and of course what- ever else you'd like to mention, though I don't want to sign you up for everything already there)? And we'll take it from there? Or is it something else you have in mind? Gerald
Re: [PING][PATCH,dejagnu] Allow dg-skip-if to use compiler flags specified through set_board_info cflags
Hello
On Sat, Aug 11, 2012 at 11:09:03PM +0530, Senthil Kumar Selvaraj wrote:
> This patch allows cflags set in board config files using
> "set_board_info cflags" to be used in the selectors of
> dg-skip-if and other dejagnu commands that use the check-flags
> proc.
>
> The code merely adds cflags to compiler_flags in the check-flags proc,
> exactly the same way as multilib_flags is added.
>
> Regards
> Senthil
>
> * lib/target-supports-dg.exp (check-flags): Add cflags from board
> config to compiler_flags
>
>
> 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] "
> }
Does the patch look ok?
Regards
Senthil
Re: [Fortran] PR37336 - FIINAL patch [1/n]: Implement the finalization wrapper subroutine
Dear all,
attached is a slightly updated patch:
* Call finalizers of nonallocatable, nonpointer components
* Generate FINAL wrapper for abstract types which have a finalizer. (The
allocatable components are deallocated in the first type (abstract or
not) which has a finalizer, i.e. abstract + finalizer or first
nonabstract type.)
I had to disable some resolve warning; I did so by introducing an
attr.artificial. I used it to also fix PR 51632, where we errored out
for __def_init and __copy where there were coarray components.
Build and regtested on x86-64-linux.
OK for the trunk?
Tobias
2012-08-19 Alessandro Fanfarillo
Tobias Burnus
PR fortran/37336
* gfortran.h (symbol_attribute): Add artifical and final_comp.
* parse.c (parse_derived): Set final_comp.
* module.c (mio_symbol_attribute): Handle final.comp.
* class.c (gfc_build_class_symbol): Defer creation of the vtab
if the DT has finalizers, mark generated symbols as
attr.artificial.
(finalize_component, finalization_scalarizer,
generate_finalization_wrapper): New static functions.
(gfc_find_derived_vtab): Add _final component and call
generate_finalization_wrapper.
* dump-parse-tree.c (show_f2k_derived): Use resolved
proc_tree->n.sym rather than unresolved proc_sym.
* resolve.c (gfc_resolve_finalizers): Remove not-implemented
error and ensure that the vtab exists.
(resolve_fl_derived): Resolve finalizers before
generating the vtab.
(resolve_symbol): Also allow assumed-rank arrays with CONTIGUOUS;
skip artificial symbols.
(resolve_fl_derived0): Skip artificial symbols.
2012-08-19 Alessandro Fanfarillo
Tobias Burnus
PR fortran/51632
* gfortran.dg/coarray_class_1.f90: New.
PR fortran/37336
* gfortran.dg/coarray_poly_3.f90: Update dg-error.
* gfortran.dg/auto_dealloc_2.f90: Update scan-tree-dump-times.
* gfortran.dg/class_19.f03: Ditto.
* gfortran.dg/finalize_4.f03: Remove dg-excess-errors
for not implemented.
* gfortran.dg/finalize_5.f03: Ditto.
* gfortran.dg/finalize_7.f03: Ditto.
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 21a91ba..122cc43 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -34,7 +34,7 @@ along with GCC; see the file COPYING3. If not see
declared type of the class variable and its attributes
(pointer/allocatable/dimension/...).
* _vptr: A pointer to the vtable entry (see below) of the dynamic type.
-
+
For each derived type we set up a "vtable" entry, i.e. a structure with the
following fields:
* _hash: A hash value serving as a unique identifier for this type.
@@ -42,6 +42,9 @@ along with GCC; see the file COPYING3. If not see
* _extends: A pointer to the vtable entry of the parent derived type.
* _def_init: A pointer to a default initialized variable of this type.
* _copy: A procedure pointer to a copying procedure.
+* _final:A procedure pointer to a wrapper function, which frees
+ allocatable components and calls FINAL subroutines.
+
After these follow procedure pointer components for the specific
type-bound procedures. */
@@ -572,7 +575,9 @@ gfc_build_class_symbol (gfc_typespec *ts, symbol_attribute *attr,
if (gfc_add_component (fclass, "_vptr", &c) == FAILURE)
return FAILURE;
c->ts.type = BT_DERIVED;
- if (delayed_vtab)
+ if (delayed_vtab
+ || (ts->u.derived->f2k_derived
+ && ts->u.derived->f2k_derived->finalizers))
c->ts.u.derived = NULL;
else
{
@@ -689,6 +694,672 @@ copy_vtab_proc_comps (gfc_symbol *declared, gfc_symbol *vtype)
}
+/* Call DEALLOCATE for the passed component if it is allocatable, if it is
+ neither allocatable nor a pointer but has a finalizer, call it. If it
+ is a nonpointer component with allocatable or finalizes components, walk
+ them. Either of the is required; other nonallocatables and pointers aren't
+ handled gracefully.
+ Note: The DEALLOCATE handling takes care of finalizers, coarray
+ deregistering and allocatable components of the allocatable. */
+
+void
+finalize_component (gfc_expr *expr, gfc_symbol *derived, gfc_component *comp,
+ gfc_expr *stat, gfc_code **code)
+{
+ gfc_expr *e;
+ e = gfc_copy_expr (expr);
+ e->ref = gfc_get_ref ();
+ e->ref->type = REF_COMPONENT;
+ e->ref->u.c.sym = derived;
+ e->ref->u.c.component = comp;
+ e->ts = comp->ts;
+
+ if (comp->attr.dimension
+ || (comp->ts.type == BT_CLASS && CLASS_DATA (comp)
+ && CLASS_DATA (comp)->attr.dimension))
+{
+ e->ref->next = gfc_get_ref ();
+ e->ref->next->type = REF_ARRAY;
+ e->ref->next->u.ar.type = AR_FULL;
+ e->ref->next->u.ar.dimen = 0;
+ e->ref->next->u.ar.as = comp->ts.type == BT_CLASS ? CLASS_DATA (comp)->as
+ : comp->as;
+ e->rank = e->ref->next->u.ar.as->rank;
+}
+
+ if (comp->attr.allocatable
+ || (comp->ts.type == BT_CLASS && CLASS_DATA (comp)
+ && CLASS_DATA (comp)->attr.allocatable))
Re: Inheritance of gfc_symbol / gfc_component
On 18/08/2012 19:25, Tobias Schlüter wrote:
>>> I thought I could work around this problem without introducing a
>>> constructor by:
>>> 1) using 0 instead of -1 as value for this fake label (which is also
>>> not a valid value for a label, so it can't collide
>>> 2) setting ST_LABEL_FORMAT = 0
>>> and then
>>> 3) not initializing at all, assuming that as for a C struct
>>> format_asterisk would end up in .bss and thus be zero initialized.
Initialization doesn't seem to be that important after all as only the
address of the variable is used.
It would be safer, I think, to define the variable as a pointer with
invalid (non-NULL) value.
> The benefit over the
> STL's map or a hashtable (which is better suited) is that we can
> traverse a tree in defined order. We use this property to write
> reproducible module files.
Indeed.
>> Could you post the not-yet-finished patch?
>
> Please find it attached. Note that two void* remain:
> gfc_{insert|delete}_bbt still need it, and I don't think there's a way
> around this without templates and without significantly changing the
> code. As I said before, I think a change needs to have a benefit. I'm
> disappointed by this outcome, but think this patch fails this
> requirement mainly because of the format_asterisk issue.
I'm not so much concerned about format_asterisk (see above).
My main concern is this: the increased type safety by changing the
(void*) -> (gfc_bbt*) change is balanced by the reduced type safety for
all the types inherited from gfc_bbt as the left and right pointer have
now gfc_bbt type instead of the derived type. And we better have type
safety for gfc_symtree which is used all over the place.
After digging some information on the web about C++ and casts, I'm not
even sure the casts are correct because of the following quote from the
standard:
"The order in which the base class subobjects are allocated in the most
derived object (1.8) is unspecified."
This tells me we shouldn't rely on the gfc_symtree, pointer_info,
etc having the same address as the corresponding gfc_bbt they derive
from (unless the explicit casts add/substract the necessary offset if
needed though).
We're probably safe with single inheritance, but still...
Mikael
Re: [wwwdocs] SH 4.8 changes update
On Sun, 2012-08-19 at 19:20 +0200, Gerald Pfeifer wrote: > On Sun, 19 Aug 2012, Oleg Endo wrote: > > This is what has been done so far on the SH side for 4.8. > > I hope it's OK. > > Wow, that is quite impressive (and a nice write-up also)! Thanks. Let's hope that I can squeeze in some more stuff while stage 1 lasts. :T > I see this was already approved, but allow me to suggest some > minor editorial comments... Thanks for those! Since I've just committed the thing as it was, please find the correcting patch in the attachments. > > Index: htdocs/gcc-4.8/changes.html > === > +The default alignment settings have been reduced to be less > aggresive. > > "aggressive" Fixed. > + Minor tweaks for code around software atomic sequences that are > + enabled by -msoft-atomic. > > "code for"? Not sure... Rephrased. > + A new option -menable-tas will make the compiler > + generate the tas.b instruction for the > + __atomic_test_and_set built-in function. > > A naive question: Why is this not on by default? Or is it under > certain circumstances? SH's tas.b insn can potentially confuse caches under certain HW configurations and result in data corruption. Moreover, it flushes the operand cache line for the variable in question and then does its thing. There might be problems when it's used together with other ways of doing atomics, so maybe it's better not to surprise people by enabling it by default. But now that you mention it, maybe it would be better to rename the '-menable-tas' option to '-mtas', since other instruction related options do not have 'enabled' in the name. > +The fmac instruction will now be emitted by the > +fmaf standard and built-in function. > > "built-in standard function", perhaps? Clarified. > > +The -mfused-madd option has been depricated in favor of > > "deprecated" Fixed. > +Added new options -mfsrra and -mfsca to > allow > +the compiler using the fsrra and fsca > +instructions on CPUs other than SH4A. > > How about adding "...SH4A (where they are already on by default)" or > similar? Added. OK to install? Cheers, Oleg Index: htdocs/gcc-4.8/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v retrieving revision 1.14 diff -u -r1.14 changes.html --- htdocs/gcc-4.8/changes.html 19 Aug 2012 17:16:04 - 1.14 +++ htdocs/gcc-4.8/changes.html 19 Aug 2012 18:07:37 - @@ -159,14 +159,14 @@ SH -The default alignment settings have been reduced to be less aggresive. +The default alignment settings have been reduced to be less aggressive. This results in more compact code for optimization levels other than -Os. Improved support for the __atomic built-in functions: - Minor tweaks for code around software atomic sequences that are - enabled by -msoft-atomic. + Minor improvements to code generated for software atomic sequences + that are enabled by -msoft-atomic. A new option -menable-tas will make the compiler generate the tas.b instruction for the @@ -197,9 +197,10 @@ __builtin_prefetch built-in function for SH3. The fmac instruction will now be emitted by the -fmaf standard and built-in function. +fmaf standard function and the __builtin_fmaf +built-in function. -The -mfused-madd option has been depricated in favor of +The -mfused-madd option has been deprecated in favor of the machine-independent -ffp-contract option. Notice that the fmac instruction will now be generated by default for expressions like a * b + c. This is due to the compiler @@ -207,7 +208,8 @@ Added new options -mfsrra and -mfsca to allow the compiler using the fsrra and fsca -instructions on CPUs other than SH4A. +instructions on CPUs other than SH4A (where they are already enabled by +default). Added support for the __builtin_bswap32 built-in function. It is now expanded as a sequence of swap.b and
Re: Inheritance of gfc_symbol / gfc_component
Hi Mikael, On 2012-08-19 19:57, Mikael Morin wrote: My main concern is this: the increased type safety by changing the (void*) -> (gfc_bbt*) change is balanced by the reduced type safety for all the types inherited from gfc_bbt as the left and right pointer have now gfc_bbt type instead of the derived type. And we better have type safety for gfc_symtree which is used all over the place. An interesting and valid point. I don't think there's a way around this without using templates (or macros). In a way, inheriting from gfc_bbt is also not really the purpose of inheritance, which is meant to express an "any A is also a B" relationship. An object that can be stored in a tree is not the same as the tree itself. This distinction is not made by my patch. Since my interest was purely to get an equivalent alternative to the macro magic and void*'s, I wasn't too worried about this, but it's another wart. After digging some information on the web about C++ and casts, I'm not even sure the casts are correct because of the following quote from the standard: "The order in which the base class subobjects are allocated in the most derived object (1.8) is unspecified." This tells me we shouldn't rely on the gfc_symtree, pointer_info, etc having the same address as the corresponding gfc_bbt they derive from (unless the explicit casts add/substract the necessary offset if needed though). We're probably safe with single inheritance, but still... To my knowledge it's perfectly valid to cast from a base class to a derived class, even though 'static_cast<>' would be the preferred C++ operator for the conversion. The resulting pointer may only be dereferenced if the types of the objects in memory are correct, though. The cast can take care of the issues with different offsets, multiple inheritance and so on because the compiler knows the whole class hierarchy. Anyway, all this is academic, as the patch brings no benefit IMO. Cheers, - Tobi
obstack for equiv_class_label, more vectors on stack
2012-08-19 Dimitrios Apostolou
* gcc/tree-ssa-structalias.c: Change declaration of ce_s type
vector from heap to stack. Update all relevant functions to
VEC_alloc() such vector upfront with enough (32) slots so that
malloc() calls are mostly avoided.
(equiv_class_obstack) New global static obstack for allocating
struct equiv_class_label.
(equiv_class_add): Use the above instead of malloc().
(perform_var_substitution): Don't allow entries of
location_equiv_class_table to be freed, because they are free'd...
(free_var_substitution_info): ...here by freeing the obstack.
* gcc/vecir.h: Add declaration of stack allocated tree type vector.
* gcc/tree-ssa-sccvn.c (vn_phi_insert, print_scc, compare_ops)
(sort_scc, copy_reference, extract_and_process_scc_for_name): Use
it, instead of heap allocated vector.
Not all of these places are hot on the profiler, but since I changed a few
I had to change them all to remove complete the heap ce_s vector. Passes
tests and offers small gains (couple of ms), but expect a more thorough
report and testing against a new snapshot by next week.
Thanks,
Dimitris2012-08-19 Dimitrios Apostolou
* gcc/tree-ssa-structalias.c: Change declaration of ce_s type
vector from heap to stack. Update all relevant functions to
VEC_alloc() such vector upfront with enough (32) slots so that
malloc() calls are mostly avoided.
(equiv_class_obstack) New global static obstack for allocating
struct equiv_class_label.
(equiv_class_add): Use the above instead of malloc().
(perform_var_substitution): Don't allow entries of
location_equiv_class_table to be freed, because they are free'd...
(free_var_substitution_info): ...here by freeing the obstack.
* gcc/vecir.h: Add declaration of stack allocated tree type vector.
* gcc/tree-ssa-sccvn.c (vn_phi_insert, print_scc, compare_ops)
(sort_scc, copy_reference, extract_and_process_scc_for_name): Use
it, instead of heap allocated vector.
=== modified file 'gcc/tree-ssa-structalias.c'
--- gcc/tree-ssa-structalias.c 2012-08-16 14:27:51 +
+++ gcc/tree-ssa-structalias.c 2012-08-18 16:43:02 +
@@ -472,11 +472,14 @@ struct constraint_expr
typedef struct constraint_expr ce_s;
DEF_VEC_O(ce_s);
-DEF_VEC_ALLOC_O(ce_s, heap);
-static void get_constraint_for_1 (tree, VEC(ce_s, heap) **, bool, bool);
-static void get_constraint_for (tree, VEC(ce_s, heap) **);
-static void get_constraint_for_rhs (tree, VEC(ce_s, heap) **);
-static void do_deref (VEC (ce_s, heap) **);
+DEF_VEC_ALLOC_O_STACK(ce_s);
+#define VEC_ce_s_stack_alloc(alloc) \
+ VEC_stack_alloc (ce_s, alloc)
+
+static void get_constraint_for_1 (tree, VEC(ce_s, stack) **, bool, bool);
+static void get_constraint_for (tree, VEC(ce_s, stack) **);
+static void get_constraint_for_rhs (tree, VEC(ce_s, stack) **);
+static void do_deref (VEC (ce_s, stack) **);
/* Our set constraints are made up of two constraint expressions, one
LHS, and one RHS.
@@ -1893,6 +1896,9 @@ static htab_t pointer_equiv_class_table;
classes. */
static htab_t location_equiv_class_table;
+/* Pool of memory for storing the above */
+static struct obstack equiv_class_obstack;
+
/* Hash function for a equiv_class_label_t */
static hashval_t
@@ -1942,7 +1948,7 @@ equiv_class_add (htab_t table, unsigned
bitmap labels)
{
void **slot;
- equiv_class_label_t ecl = XNEW (struct equiv_class_label);
+ equiv_class_label_t ecl = XOBNEW (&equiv_class_obstack, struct
equiv_class_label);
ecl->labels = labels;
ecl->equivalence_class = equivalence_class;
@@ -2153,10 +2159,12 @@ perform_var_substitution (constraint_gra
struct scc_info *si = init_scc_info (size);
bitmap_obstack_initialize (&iteration_obstack);
+ gcc_obstack_init (&equiv_class_obstack);
+ /* NULL free function, we'll free the whole pool at the end of the pass. */
pointer_equiv_class_table = htab_create (511, equiv_class_label_hash,
- equiv_class_label_eq, free);
+ equiv_class_label_eq, NULL);
location_equiv_class_table = htab_create (511, equiv_class_label_hash,
- equiv_class_label_eq, free);
+ equiv_class_label_eq, NULL);
pointer_equiv_class = 1;
location_equiv_class = 1;
@@ -2263,6 +2271,7 @@ free_var_substitution_info (struct scc_i
sbitmap_free (graph->direct_nodes);
htab_delete (pointer_equiv_class_table);
htab_delete (location_equiv_class_table);
+ obstack_free (&equiv_class_obstack, NULL);
bitmap_obstack_release (&iteration_obstack);
}
@@ -2741,7 +2750,7 @@ new_scalar_tmp_constraint_exp (const cha
If address_p is true, the result will be taken its address of. */
static void
-get_constraint_
alloc_pool for tree-ssa-pre.c:phi_translate_table
2012-08-19 Dimitrios Apostolou
* gcc/tree-ssa-pre.c (phi_translate_pool): New static global
alloc_pool, used for allocating struct expr_pred_trans_d for
phi_translate_table.
(phi_trans_add, init_pre, fini_pre): Use it, avoids thousand of
malloc() and free() calls.
This avoids lots of malloc/free calls and slow iterations during numerous
htab_delete() in fini_pre(). Tested on pre C++-snapshot, will update info
as soon as a post C++ one is available.
Thanks,
Dimitris2012-08-19 Dimitrios Apostolou
* gcc/tree-ssa-pre.c (phi_translate_pool): New static global
alloc_pool, used for allocating struct expr_pred_trans_d for
phi_translate_table.
(phi_trans_add, init_pre, fini_pre): Use it, avoids thousand of
malloc() and free() calls.
=== modified file 'gcc/tree-ssa-pre.c'
--- gcc/tree-ssa-pre.c 2012-08-17 08:03:54 +
+++ gcc/tree-ssa-pre.c 2012-08-18 16:43:02 +
@@ -486,7 +486,7 @@ static bitmap need_ab_cleanup;
/* A three tuple {e, pred, v} used to cache phi translations in the
phi_translate_table. */
-typedef struct expr_pred_trans_d : typed_free_remove
+typedef struct expr_pred_trans_d : typed_noop_remove
{
/* The expression. */
pre_expr e;
@@ -508,6 +508,12 @@ typedef struct expr_pred_trans_d : typed
} *expr_pred_trans_t;
typedef const struct expr_pred_trans_d *const_expr_pred_trans_t;
+/* Pool of memory for the above */
+
+static alloc_pool phi_translate_pool;
+
+/* Return the hash value for a phi translation table entry. */
+
inline hashval_t
expr_pred_trans_d::hash (const expr_pred_trans_d *e)
{
@@ -561,7 +567,8 @@ static inline void
phi_trans_add (pre_expr e, pre_expr v, basic_block pred)
{
expr_pred_trans_t *slot;
- expr_pred_trans_t new_pair = XNEW (struct expr_pred_trans_d);
+ expr_pred_trans_t new_pair =
+(expr_pred_trans_t) pool_alloc (phi_translate_pool);
new_pair->e = e;
new_pair->pred = pred;
new_pair->v = v;
@@ -570,7 +577,8 @@ phi_trans_add (pre_expr e, pre_expr v, b
slot = phi_translate_table.find_slot_with_hash (new_pair,
new_pair->hashcode, INSERT);
- free (*slot);
+ if (*slot)
+pool_free (phi_translate_pool, *slot);
*slot = new_pair;
}
@@ -4798,6 +4806,9 @@ init_pre (bool do_fre)
calculate_dominance_info (CDI_DOMINATORS);
bitmap_obstack_initialize (&grand_bitmap_obstack);
+ phi_translate_pool = create_alloc_pool ("phi_translate_table",
+ sizeof (struct expr_pred_trans_d),
+ 512);
phi_translate_table.create (5110);
expression_to_id.create (num_ssa_names * 3);
bitmap_set_pool = create_alloc_pool ("Bitmap sets",
@@ -4832,6 +4843,7 @@ fini_pre (bool do_fre)
free_alloc_pool (bitmap_set_pool);
free_alloc_pool (pre_expr_pool);
phi_translate_table.dispose ();
+ free_alloc_pool (phi_translate_pool);
expression_to_id.dispose ();
VEC_free (unsigned, heap, name_to_id);
enlarge hot allocation pools
Hello,
2012-08-19 Dimitrios Apostolou
* gcc/cselib.c (cselib_init): Make allocation pools larger since
they are too hot and show to expand often on the profiler.
* gcc/df-problems.c (df_chain_alloc): Same.
* gcc/et-forest.c (et_new_occ, et_new_tree): Same.
* gcc/tree-ssa-pre.c (init_pre): Same
These allocation pools are the ones that I've noticed calling malloc() too
often, for expanding their size. Also I don't like the way the pools are
created in et_new_{occ,tree}() but couldn't find a single point to move
the initialisation either. Any ideas on this one?
Thanks,
Dimitris2012-08-19 Dimitrios Apostolou
* gcc/cselib.c (cselib_init): Make allocation pools larger since
they are too hot and show to expand often on the profiler.
* gcc/df-problems.c (df_chain_alloc): Same.
* gcc/et-forest.c (et_new_occ, et_new_tree): Same.
* gcc/tree-ssa-pre.c (init_pre): Same
=== modified file 'gcc/cselib.c'
--- gcc/cselib.c2012-08-02 22:39:57 +
+++ gcc/cselib.c2012-08-19 15:13:28 +
@@ -2659,12 +2659,12 @@ void
cselib_init (int record_what)
{
elt_list_pool = create_alloc_pool ("elt_list",
-sizeof (struct elt_list), 10);
+sizeof (struct elt_list), 128);
elt_loc_list_pool = create_alloc_pool ("elt_loc_list",
-sizeof (struct elt_loc_list), 10);
+sizeof (struct elt_loc_list), 128);
cselib_val_pool = create_alloc_pool ("cselib_val_list",
- sizeof (cselib_val), 10);
- value_pool = create_alloc_pool ("value", RTX_CODE_SIZE (VALUE), 100);
+ sizeof (cselib_val), 128);
+ value_pool = create_alloc_pool ("value", RTX_CODE_SIZE (VALUE), 128);
cselib_record_memory = record_what & CSELIB_RECORD_MEMORY;
cselib_preserve_constants = record_what & CSELIB_PRESERVE_CONSTANTS;
cselib_any_perm_equivs = false;
=== modified file 'gcc/df-problems.c'
--- gcc/df-problems.c 2012-08-17 09:42:06 +
+++ gcc/df-problems.c 2012-08-19 15:29:37 +
@@ -1993,7 +1993,7 @@ df_chain_alloc (bitmap all_blocks ATTRIB
{
df_chain_remove_problem ();
df_chain->block_pool = create_alloc_pool ("df_chain_block pool",
-sizeof (struct df_link), 50);
+sizeof (struct df_link), 128);
df_chain->optional_p = true;
}
=== modified file 'gcc/et-forest.c'
--- gcc/et-forest.c 2012-05-31 16:43:31 +
+++ gcc/et-forest.c 2012-08-19 15:50:25 +
@@ -444,8 +444,8 @@ et_new_occ (struct et_node *node)
{
struct et_occ *nw;
- if (!et_occurrences)
-et_occurrences = create_alloc_pool ("et_occ pool", sizeof (struct et_occ),
300);
+ if (!et_occurrences)
+et_occurrences = create_alloc_pool ("et_occ pool", sizeof (struct et_occ),
1024);
nw = (struct et_occ *) pool_alloc (et_occurrences);
nw->of = node;
@@ -467,8 +467,8 @@ et_new_tree (void *data)
{
struct et_node *nw;
- if (!et_nodes)
-et_nodes = create_alloc_pool ("et_node pool", sizeof (struct et_node),
300);
+ if (!et_nodes)
+et_nodes = create_alloc_pool ("et_node pool", sizeof (struct et_node),
512);
nw = (struct et_node *) pool_alloc (et_nodes);
nw->data = data;
=== modified file 'gcc/tree-ssa-pre.c'
--- gcc/tree-ssa-pre.c 2012-08-18 06:31:26 +
+++ gcc/tree-ssa-pre.c 2012-08-19 15:28:21 +
@@ -4812,9 +4812,9 @@ init_pre (bool do_fre)
phi_translate_table.create (5110);
expression_to_id.create (num_ssa_names * 3);
bitmap_set_pool = create_alloc_pool ("Bitmap sets",
- sizeof (struct bitmap_set), 30);
+ sizeof (struct bitmap_set), 128);
pre_expr_pool = create_alloc_pool ("pre_expr nodes",
-sizeof (struct pre_expr_d), 30);
+sizeof (struct pre_expr_d), 32);
FOR_ALL_BB (bb)
{
EXP_GEN (bb) = bitmap_set_new ();
Re: CXX conversion: min g++ version pre-requisite?
I filed two bug reports: "GCC install document does not list minimum required g++ version" http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54324 "GCC does not build with G++ version 3.4.0" http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54326 Re: the latter bug report (54326), it might be further divided into two bug reports: one documenting the failure to build with g++ 3.4.0 and the other having to do with the use of casts in genoutput.c. Let me know if you recommend that I separate the bug reports. - Gary
Re: [PATCH][RFC] Extend memset recognition
On Tue, Jun 5, 2012 at 2:21 AM, Richard Guenther wrote:
> On Thu, 31 May 2012, Richard Guenther wrote:
>
>> On Wed, 30 May 2012, Richard Guenther wrote:
>>
>> >
>> > The patch below extents memset recognition to cover a few more
>> > non-byte-size store loops and all byte-size store loops. This exposes
>> > issues with our builtins.exp testsuite which has custom memset
>> > routines like
>> >
>> > void *
>> > my_memset (void *d, int c, size_t n)
>> > {
>> > char *dst = (char *) d;
>> > while (n--)
>> > *dst++ = c;
>> > return (char *) d;
>> > }
>> >
>> > Now, for LTO we have papered over similar issues by attaching
>> > the used attribute to the functions. But the general question is - when
>> > can we be sure the function we are dealing with are not the actual
>> > implementation for the builtin call we want to generate? A few
>> > things come to my mind:
>> >
>> > 1) the function already calls the function we want to generate (well,
>> > it might be a tail-recursive memset implementation ...)
>> >
>> > 2) the function availability is AVAIL_LOCAL
>> >
>> > 3) ... ?
>> >
>> > For sure 2) would work, but it would severely restrict the transform
>> > (do we care?).
>> >
>> > We have a similar issue with sin/cos -> sincos transform and a
>> > trivial sincos implementation.
>> >
>> > Any ideas?
>> >
>> > Bootstrapped (with memset recognition enabled by default) and tested
>> > on x86_64-unknown-linux-gnu with the aforementioned issues.
>>
>> The following fixes it by simply always adding
>> -fno-tree-loop-distribute-patterns to builtins.exp.
>>
>> Bootstrapped and tested on x86_64-unknown-linux-gnu.
>>
>> If there are no further comments I'll go with the local advise from
>> Micha who says "who cares".
>
> Now done with the much simpler patch below (after all the loop
> distribution TLC).
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>
> Richard.
>
> 2012-06-05 Richard Guenther
>
> PR tree-optimization/53081
> * tree-loop-distribution.c (generate_memset_builtin): Handle all
> kinds of byte-sized stores.
> (classify_partition): Likewise.
> (tree_loop_distribution): Adjust seed statements used for
> !flag_tree_loop_distribution.
>
> * gcc.dg/tree-ssa/ldist-19.c: New testcase.
> * gcc.c-torture/execute/builtins/builtins.exp: Always pass
> -fno-tree-loop-distribute-patterns.
>
This caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54321
--
H.J.
Re: [PATCH, Committed] Fix ChangeLog (was: [PATCH] Fix AVR fallout)
On Sun, Aug 19, 2012 at 1:34 AM, Jan-Benedict Glaw wrote: > I fixed ChangeLog's whitespace (probably cut'n'paste error), committed > as obvious. > > 2012-08-19 Jan-Benedict Glaw > > * ChangeLog: Fix whitespace. Note that fixes to the ChangeLog files do not themselves get ChangeLog entries. Ian
Re: [PATCH, Committed] Fix ChangeLog (was: [PATCH] Fix AVR fallout)
On Sun, 2012-08-19 11:58:49 -0700, Ian Lance Taylor wrote: > On Sun, Aug 19, 2012 at 1:34 AM, Jan-Benedict Glaw wrote: > > I fixed ChangeLog's whitespace (probably cut'n'paste error), committed > > as obvious. > > > > 2012-08-19 Jan-Benedict Glaw > > > > * ChangeLog: Fix whitespace. > > Note that fixes to the ChangeLog files do not themselves get > ChangeLog entries. Fixed. Thanks for the notice, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: http://perl.plover.com/Questions.html the second : signature.asc Description: Digital signature
Re: [Patch, Fortran] PR54301 - add warning for pointer might outlive its target
Hi Tobias, Build and regtested on x86-64-gnu-linux. OK for the trunk? I would exclude pointers on the lhs of the pointer assignment, to make sure that warnings for code such as program main integer :: i integer, pointer :: ip block integer, pointer :: jp allocate (jp) jp = 3 ip => jp end block i = ip print *,i end program main are not emitted. Thomas
Re: [Patch, Fortran] PR54301 - add warning for pointer might outlive its target
Am 19.08.2012 21:19, schrieb Thomas Koenig: Build and regtested on x86-64-gnu-linux. OK for the trunk? I would exclude pointers on the lhs of the pointer assignment, I assume you mean RHS – excluding LHS pointers in pointer assignments is kind of difficult ;-) RHS pointers are excluded via: + if (gfc_option.warn_target_lifetime + && rvalue->expr_type == EXPR_VARIABLE + && !rvalue->symtree->n.sym->attr.save + && !attr.pointer && !rvalue->symtree->n.sym->attr.host_assoc the attr is set via: attr = gfc_expr_attr (rvalue); to make sure that warnings for code such as are not emitted. There is no warning with the patch. Tobias
Re: [wwwdocs] SH 4.8 changes update
On Sun, 19 Aug 2012, Oleg Endo wrote: > Thanks. Let's hope that I can squeeze in some more stuff while > stage 1 lasts. :T You know that for backend-specific changes (especially for "smaller" ports) you actually have some more leeway? > But now that you mention it, maybe it would be better to rename the > '-menable-tas' option to '-mtas', since other instruction related > options do not have 'enabled' in the name. Now still would be time to do so without worrying about compatibility. ;-) > OK to install? Oh, yes. Thanks! Gerald
Re: enlarge hot allocation pools
On Sun, Aug 19, 2012 at 8:31 PM, Dimitrios Apostolou wrote:
> Hello,
>
> 2012-08-19 Dimitrios Apostolou
>
> * gcc/cselib.c (cselib_init): Make allocation pools larger since
> they are too hot and show to expand often on the profiler.
> * gcc/df-problems.c (df_chain_alloc): Same.
> * gcc/et-forest.c (et_new_occ, et_new_tree): Same.
> * gcc/tree-ssa-pre.c (init_pre): Same
>
>
> These allocation pools are the ones that I've noticed calling malloc() too
> often, for expanding their size.
I don't like the way these pools are sized with a seemingly arbitrary
initial size. They're there to hold something, and they grow because
there are "more somethings" than initially guessed. I think you should
look at what the pools hold and choose an initial size based on some
representative measure. E.g. if a pool holds some kind of expressions,
then you should be able to make an initial guess of the size of the
pool based on the number of pseudos or ssa names. Ideally you'd simply
"derive" the initial pool size by a regression analysis of the final
pool size and some potential representative measures (# of regs, basic
blocks, edges, whatever).
> Also I don't like the way the pools are
> created in et_new_{occ,tree}() but couldn't find a single point to move the
> initialisation either. Any ideas on this one?
Just create a new function to initialize (destroy) the pools and call
it from calculate_dominance_info (free_dominance_info).
Ciao!
Steven
Re: [Patch, Fortran] PR54301 - add warning for pointer might outlive its target
Hi Tobias, Am 19.08.2012 21:19, schrieb Thomas Koenig: Build and regtested on x86-64-gnu-linux. OK for the trunk? I would exclude pointers on the lhs of the pointer assignment, I assume you mean RHS – excluding LHS pointers in pointer assignments is kind of difficult ;-) Sometimes I have a weak right-left weakness :-) RHS pointers are excluded via: ... There is no warning with the patch. OK for trunk then. You'll find your patch no longer applies cleanly, because I have changed the same spot(s) in invoke.texi and gfortran.h with my recent commit, but I think you'll manage :-) Thomas
[SH] PR 51244 - Use more zero displacement branches
Hello,
This adds two new patterns to undo an optimization that is done by ifcvt
and is not beneficial if zero displacement branches are available on SH.
Tested on rev 190459 with
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
and no new failures.
OK?
Cheers,
Oleg
ChangeLog:
PR target/51244
* config/sh/sh.md (*cset_zero): New insns.
testsuite/ChangeLog:
PR target/51244
* gcc.target/sh/pr51244-11.c: New.
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 190459)
+++ gcc/config/sh/sh.md (working copy)
@@ -10409,6 +10409,41 @@
operands[0] = gen_reg_rtx (SImode);
})
+;; The *cset_zero patterns convert optimizations such as
+;; "if (test) x = 0;" to "x &= -(test == 0);"
+;; back to conditional branch sequences if zero-displacement branches
+;; are enabled.
+;; FIXME: These patterns can be removed when conditional execution patterns
+;; are implemented, since ifcvt will not perform these optimizations if
+;; conditional execution is supported.
+(define_insn "*cset_zero"
+ [(set (match_operand:SI 0 "arith_reg_dest" "=r")
+ (and:SI (plus:SI (match_operand:SI 1 "t_reg_operand")
+ (const_int -1))
+ (match_operand:SI 2 "arith_reg_operand" "0")))]
+ "TARGET_SH1 && TARGET_ZDCBRANCH"
+{
+ return "bf 0f" "\n"
+ " mov #0,%0" "\n"
+ "0:";
+}
+ [(set_attr "type" "arith") ;; poor approximation
+ (set_attr "length" "4")])
+
+(define_insn "*cset_zero"
+ [(set (match_operand:SI 0 "arith_reg_dest" "=r")
+ (if_then_else:SI (match_operand:SI 1 "t_reg_operand")
+ (match_operand:SI 2 "arith_reg_operand" "0")
+ (const_int 0)))]
+ "TARGET_SH1 && TARGET_ZDCBRANCH"
+{
+ return "bt 0f" "\n"
+ " mov #0,%0" "\n"
+ "0:";
+}
+ [(set_attr "type" "arith") ;; poor approximation
+ (set_attr "length" "4")])
+
(define_expand "cstoresf4"
[(set (match_operand:SI 0 "register_operand" "=r")
(match_operator:SI 1 "sh_float_comparison_operator"
Index: gcc/testsuite/gcc.target/sh/pr51244-11.c
===
--- gcc/testsuite/gcc.target/sh/pr51244-11.c (revision 0)
+++ gcc/testsuite/gcc.target/sh/pr51244-11.c (revision 0)
@@ -0,0 +1,24 @@
+/* Check that zero-displacement branches are used instead of branch-free
+ execution patterns. */
+/* { dg-do compile { target "sh*-*-*" } } */
+/* { dg-options "-O1 -mzdcbranch" } */
+/* { dg-skip-if "" { "sh*-*-*" } { "-m5*" } { "" } } */
+/* { dg-final { scan-assembler-not "subc|and" } } */
+
+int*
+test_00 (int* s)
+{
+ if (s[0] == 0)
+if (!s[3])
+ s = 0;
+ return s;
+}
+
+int*
+test_01 (int* s)
+{
+ if (s[0] == 0)
+if (s[3])
+ s = 0;
+ return s;
+}
[SH] PR 54089 - Add support for rotcr insn
Hello,
This adds support for SH's rotcr insn.
Tested on rev 190459 with
make -k check RUNTESTFLAGS="--target_board=sh-sim
\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"
and no new failures.
OK?
Cheers,
Oleg
ChangeLog:
PR target/50489
* config/sh/sh.md (rotcr, *rotcr, shar, shlr): New insns and
splits.
(ashrdi3_k, lshrdi3_k): Rewrite as insn_and_split.
* config/sh/sh.c (sh_lshrsi_clobbers_t_reg_p): New function.
* config/sh/sh-protos.h (sh_lshrsi_clobbers_t_reg_p): Declare
it.
testsuite/ChangeLog:
PR target/50489
* gcc.target/sh/pr54089-1.c: New.
Index: gcc/config/sh/sh.md
===
--- gcc/config/sh/sh.md (revision 190459)
+++ gcc/config/sh/sh.md (working copy)
@@ -3827,6 +3827,100 @@
FAIL;
})
+;; The rotcr insn is used primarily in DImode right shifts (arithmetic
+;; and logical). It can also be used to implement things like
+;; bool t = a == b;
+;; int x = (y >> 1) | (t << 31);
+(define_insn "rotcr"
+ [(set (match_operand:SI 0 "arith_reg_dest" "=r")
+ (ior:SI (lshiftrt:SI (match_operand:SI 1 "arith_reg_operand" "0")
+ (const_int 1))
+ (ashift:SI (match_operand:SI 2 "t_reg_operand")
+ (const_int 31
+ (set (reg:SI T_REG)
+ (and:SI (match_dup 1) (const_int 1)))]
+ "TARGET_SH1"
+ "rotcr %0"
+ [(set_attr "type" "arith")])
+
+;; Simplified rotcr version for combine, which allows arbitrary shift
+;; amounts for the reg. If the shift amount is '1' rotcr can be used
+;; directly. Otherwise we have to insert a shift in between.
+(define_insn_and_split "*rotcr"
+ [(set (match_operand:SI 0 "arith_reg_dest")
+ (ior:SI (lshiftrt:SI (match_operand:SI 1 "arith_reg_operand")
+ (match_operand:SI 2 "const_int_operand"))
+ (ashift:SI (match_operand:SI 3 "t_reg_operand")
+ (const_int 31
+ (clobber (reg:SI T_REG))]
+ "TARGET_SH1"
+ "#"
+ "&& can_create_pseudo_p ()"
+ [(const_int 0)]
+{
+ if (INTVAL (operands[2]) > 1)
+{
+ /* use plus_constant function ?? */
+ const int shift_count = INTVAL (operands[2]) - 1;
+ const rtx shift_count_rtx = GEN_INT (shift_count);
+ rtx shift_res = gen_reg_rtx (SImode);
+
+ rtx prev_set_t_insn = NULL_RTX;
+ rtx tmp_t_reg = NULL_RTX;
+
+ /* If we're going to emit a shift sequence that clobbers the T_REG,
+ try to find the previous insn that sets the T_REG and emit the
+ shift insn before that insn, to remove the T_REG dependency.
+ If the insn that sets the T_REG cannot be found, store the T_REG
+ in a temporary reg and restore it after the shift. */
+ if (sh_lshrsi_clobbers_t_reg_p (shift_count_rtx)
+ && ! sh_dynamicalize_shift_p (shift_count_rtx))
+ {
+ prev_set_t_insn = prev_nonnote_insn_bb (curr_insn);
+ if (! (prev_set_t_insn != NULL_RTX
+ && reg_set_p (get_t_reg_rtx (), prev_set_t_insn)
+ && ! reg_referenced_p (get_t_reg_rtx (),
+ PATTERN (prev_set_t_insn
+ {
+ prev_set_t_insn = NULL_RTX;
+ tmp_t_reg = gen_reg_rtx (SImode);
+ emit_insn (gen_move_insn (tmp_t_reg, get_t_reg_rtx ()));
+ }
+ }
+
+ rtx shift_rtx = gen_lshrsi3 (shift_res, operands[1], shift_count_rtx);
+ operands[1] = shift_res;
+
+ /* Emit the shift insn before the insn that sets T_REG, if possible. */
+ if (prev_set_t_insn != NULL_RTX)
+ emit_insn_before (shift_rtx, prev_set_t_insn);
+ else
+ emit_insn (shift_rtx);
+
+ /* Restore T_REG if it has been saved before. */
+ if (tmp_t_reg != NULL_RTX)
+ emit_insn (gen_cmpgtsi_t (tmp_t_reg, const0_rtx));
+}
+
+ emit_insn (gen_rotcr (operands[0], operands[1], operands[3]));
+ DONE;
+})
+
+;; rotcr combine bridge pattern which will make combine try out more
+;; complex patterns.
+(define_insn_and_split "*rotcr"
+ [(set (match_operand:SI 0 "arith_reg_dest")
+ (ashift:SI (match_operand:SI 1 "t_reg_operand") (const_int 31)))]
+ "TARGET_SH1"
+ "#"
+ "&& 1"
+ [(set (match_dup 0) (match_dup 1))
+ (parallel [(set (match_dup 0)
+ (ior:SI (lshiftrt:SI (match_dup 0) (const_int 1))
+ (ashift:SI (match_dup 1) (const_int 31
+ (set (reg:SI T_REG)
+ (and:SI (match_dup 0) (const_int 1)))])])
+
;; . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
;; SImode shift left
@@ -4146,6 +4240,16 @@
FAIL;
})
+(define_insn "shar"
+ [(set (match_operand:SI 0 "arith_reg_dest" "=r")
+ (ashiftrt:SI (match_operand:SI 1 "arith_reg_operand" "0")
+ (const_int 1)))
+ (set (reg:SI T_REG)
+ (and:SI (match_dup 1) (const_int 1)))]
+ "TARGET_SH1"
+ "shar %0"
+ [(set_attr "type" "arith")])
+
(define_insn "ashrsi3_k"
[(set (match_operand:SI 0 "arith_reg_dest" "=r")
(ashiftrt:SI (match_operand:SI 1 "arith_reg_operand" "0")
@@ -4233,16 +4337,22 @@
FAIL;
})
-;; This should be a define_insn_and_split
-(define_insn "ashrdi3_k"
+(define_insn_and_split "ashrdi3_k"
[(set (mat
Re: [PATCH][3/n] into-SSA TLC
On Fri, Jul 27, 2012 at 5:16 AM, Richard Guenther wrote: > > This tries to more clearly separate per-SSA name held information > from per-DECL held information during update-ssa. We already have > a global array of SSA name informations so it is pointless to > have a hashtable mapping SSA names to yet another piece of information > (a bitmap). This patch simply puts the bitmap into that SSA name > auxiliar vector. Lifetime is managed by using a separate obstack > and the aux vector age. > > Bootstrap and regtest pending on x86_64-unknown-linux-gnu. > > Richard. > > 2012-07-27 Richard Guenther > > * tree-cfg.c (gimple_can_merge_blocks_p): Do more fine-grained > check whether SSA form is not up-to-date. > * tree-flow.h (name_mappings_registered_p): Remove. > * tree-into-ssa.c (struct repl_map_d): Remove. > (repl_tbl): Likewise. > (struct ssa_name_info): Add repl_set member. > (update_ssa_obstack): New static global. > (get_ssa_name_ann): Initialize repl_set. > (clear_ssa_name_info): Assert age did not wrap. > (repl_map_hash, repl_map_eq, repl_map_free): Remove. > (names_replaced_by): Adjust. > (add_to_repl_tbl): Likewise. > (dump_tree_ssa_stats): Likewise. > (init_update_ssa): Initialize update_ssa_obstack. > (delete_update_ssa): Free update_ssa_obstack. > (name_mappings_registered_p): Remove. > (update_ssa): Adjust. > This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54327 -- H.J.
Re: [wwwdocs] SH 4.8 changes update
On Sun, 2012-08-19 at 21:43 +0200, Gerald Pfeifer wrote: > On Sun, 19 Aug 2012, Oleg Endo wrote: > > Thanks. Let's hope that I can squeeze in some more stuff while > > stage 1 lasts. :T > > You know that for backend-specific changes (especially for "smaller" > ports) you actually have some more leeway? You mean, since SH is neither a primary nor a secondary platform, there are no particular release criteria for it? What does that actually mean? > > But now that you mention it, maybe it would be better to rename the > > '-menable-tas' option to '-mtas', since other instruction related > > options do not have 'enabled' in the name. > > Now still would be time to do so without worrying about compatibility. ;-) True. Cheers, Oleg
Re: [PATCH] Combine location with block using block_locations
ping
Thanks,
Dehao
On Tue, Aug 14, 2012 at 10:13 AM, Dehao Chen wrote:
> Hi, Dodji,
>
> Thanks for the review. I've fixed all the addressed issues. I'm
> attaching the related changes:
>
> Thanks,
> Dehao
>
> libcpp/ChangeLog:
> 2012-08-01 Dehao Chen
>
> * include/line-map.h (MAX_SOURCE_LOCATION): New value.
> (location_adhoc_data_init): New.
> (location_adhoc_data_fini): New.
> (get_combined_adhoc_loc): New.
> (get_data_from_adhoc_loc): New.
> (get_location_from_adhoc_loc): New.
> (COMBINE_LOCATION_DATA): New.
> (IS_ADHOC_LOC): New.
> (expanded_location): New field.
> * line-map.c (location_adhoc_data): New.
> (location_adhoc_data_htab): New.
> (curr_adhoc_loc): New.
> (location_adhoc_data): New.
> (allocated_location_adhoc_data): New.
> (location_adhoc_data_hash): New.
> (location_adhoc_data_eq): New.
> (location_adhoc_data_update): New.
> (get_combined_adhoc_loc): New.
> (get_data_from_adhoc_loc): New.
> (get_location_from_adhoc_loc): New.
> (location_adhoc_data_init): New.
> (location_adhoc_data_fini): New.
> (linemap_lookup): Change to use new location.
> (linemap_ordinary_map_lookup): Likewise.
> (linemap_macro_map_lookup): Likewise.
> (linemap_macro_map_loc_to_def_point): Likewise.
> (linemap_macro_map_loc_unwind_toward_spel): Likewise.
> (linemap_get_expansion_line): Likewise.
> (linemap_get_expansion_filename): Likewise.
> (linemap_location_in_system_header_p): Likewise.
> (linemap_location_from_macro_expansion_p): Likewise.
> (linemap_macro_loc_to_spelling_point): Likewise.
> (linemap_macro_loc_to_def_point): Likewise.
> (linemap_macro_loc_to_exp_point): Likewise.
> (linemap_resolve_location): Likewise.
> (linemap_unwind_toward_expansion): Likewise.
> (linemap_unwind_to_first_non_reserved_loc): Likewise.
> (linemap_expand_location): Likewise.
> (linemap_dump_location): Likewise.
>
> Index: libcpp/line-map.c
> ===
> --- libcpp/line-map.c (revision 190209)
> +++ libcpp/line-map.c (working copy)
> @@ -25,6 +25,7 @@
> #include "line-map.h"
> #include "cpplib.h"
> #include "internal.h"
> +#include "hashtab.h"
>
> static void trace_include (const struct line_maps *, const struct line_map
> *);
> static const struct line_map * linemap_ordinary_map_lookup (struct line_maps
> *,
> @@ -50,6 +51,135 @@
> extern unsigned num_expanded_macros_counter;
> extern unsigned num_macro_tokens_counter;
>
> +/* Data structure to associate an arbitrary data to a source location. */
> +struct location_adhoc_data {
> + source_location locus;
> + void *data;
> +};
> +
> +/* The following data structure encodes a location with some adhoc data
> + and maps it to a new unsigned integer (called an adhoc location)
> + that replaces the original location to represent the mapping.
> +
> + The new adhoc_loc uses the highest bit as the enabling bit, i.e. if the
> + highest bit is 1, then the number is adhoc_loc. Otherwise, it serves as
> + the original location. Once identified as the adhoc_loc, the lower 31
> + bits of the integer is used to index the location_adhoc_data array,
> + in which the locus and associated data is stored. */
> +
> +static htab_t location_adhoc_data_htab;
> +static source_location curr_adhoc_loc;
> +static struct location_adhoc_data *location_adhoc_data;
> +static unsigned int allocated_location_adhoc_data;
> +
> +/* Hash function for location_adhoc_data hashtable. */
> +
> +static hashval_t
> +location_adhoc_data_hash (const void *l)
> +{
> + const struct location_adhoc_data *lb =
> + (const struct location_adhoc_data *) l;
> + return (hashval_t) lb->locus + (size_t) &lb->data;
> +}
> +
> +/* Compare function for location_adhoc_data hashtable. */
> +
> +static int
> +location_adhoc_data_eq (const void *l1, const void *l2)
> +{
> + const struct location_adhoc_data *lb1 =
> + (const struct location_adhoc_data *) l1;
> + const struct location_adhoc_data *lb2 =
> + (const struct location_adhoc_data *) l2;
> + return lb1->locus == lb2->locus && lb1->data == lb2->data;
> +}
> +
> +/* Update the hashtable when location_adhoc_data is reallocated. */
> +
> +static int
> +location_adhoc_data_update (void **slot, void *data)
> +{
> + *((char **) slot) += ((char *) location_adhoc_data - (char *) data);
> + return 1;
> +}
> +
> +/* Combine LOCUS and DATA to a combined adhoc loc. */
> +
> +source_location
> +get_combined_adhoc_loc (source_location locus, void *data)
> +{
> + struct location_adhoc_data lb;
> + struct location_adhoc_data **slot;
> +
> + linemap_assert (data);
> +
> + if (IS_ADHOC_LOC (locus))
> +locus = location_adhoc_data[locus & MAX_SOURCE_LOCATION].locus;
> +
Re: enlarge hot allocation pools
Hi Steven, On Sun, 19 Aug 2012, Steven Bosscher wrote: On Sun, Aug 19, 2012 at 8:31 PM, Dimitrios Apostolou wrote: Hello, 2012-08-19 Dimitrios Apostolou * gcc/cselib.c (cselib_init): Make allocation pools larger since they are too hot and show to expand often on the profiler. * gcc/df-problems.c (df_chain_alloc): Same. * gcc/et-forest.c (et_new_occ, et_new_tree): Same. * gcc/tree-ssa-pre.c (init_pre): Same These allocation pools are the ones that I've noticed calling malloc() too often, for expanding their size. I don't like the way these pools are sized with a seemingly arbitrary initial size. They're there to hold something, and they grow because there are "more somethings" than initially guessed. I think you should look at what the pools hold and choose an initial size based on some representative measure. E.g. if a pool holds some kind of expressions, then you should be able to make an initial guess of the size of the pool based on the number of pseudos or ssa names. Ideally you'd simply "derive" the initial pool size by a regression analysis of the final pool size and some potential representative measures (# of regs, basic blocks, edges, whatever). Some time ago I tried changing the pool allocator growth strategy from linear to exponential, doubling the size of the pool chunk every time it needed another chunk. It was for the exact same reason, to set the pool size according to their contents. Unfortunately I remember it didn't make a difference so I dumped it and only manually changed the important pools, which made a small difference. I'll now try deducing information on the size at runtime, thanks for the tip. Dimitris
Re: [PATCH] Fix PR 52631 (VN does not use simplified expression for lookup)
On Wed, Jul 25, 2012 at 4:39 AM, Richard Guenther
wrote:
> On Tue, Jul 24, 2012 at 5:50 PM, Andrew Pinski
> wrote:
>> Hi,
>> Before tuples was introduced, VN used to lookup the simplified
>> expression to see if it was available already and use that instead of
>> the non simplified one. This patch adds the support back to VN to do
>> exactly that.
>>
>> OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
>
> I think this should be done for all RHS and SSA name LHS, not only
> for UNARY/BINARY/TERNARY - because even for SINGLE rhs we
> can end up simplifying (for REALPART_EXPR for example which we
> handle as nary, too). I think we constrain try_to_simplify enough
> so that
>
> + /* First try to lookup the simplified expression. */
> + if (simplified && valid_gimple_rhs_p (simplified))
> + {
> + tree result = vn_nary_op_lookup (simplified, NULL);
> + if (result)
> + {
> + changed = set_ssa_val_to (lhs, result);
> + goto done;
> + }
> + changed = set_ssa_val_to (lhs, lhs);
> + vn_nary_op_insert (simplified, lhs);
> + }
> switch (get_gimple_rhs_class (code))
> {
> case GIMPLE_UNARY_RHS:
> case GIMPLE_BINARY_RHS:
> ...
>
> should work. As you also insert the simplified variant I think we really
> (finally) want to have a valid_nary_op routine rather than relying on
> valid_gimple_rhs_p which is way too generic.
I don't see valid_gimple_rhs_p being that generic as it checks to make
sure the operands of the gimple are valid.
Maybe I am missing something here though.
Thanks,
Andrew Pinski
>
> Thanks,
> Richard.
>
>> Thanks,
>> Andrew Pinski
>>
>> ChangeLog:
>>
>> * tree-ssa-sccvn.c (visit_use): Look up the simplified
>> expression before visting the original one.
>>
>> * gcc.dg/tree-ssa/ssa-fre-9.c: Update the number of
>> eliminatations that happen.
Re: [PATCH] Add working-set size and hotness information to fdo summary (issue6465057)
On Sat, Aug 18, 2012 at 1:19 AM, Jan Hubicka wrote:
>
> > +{
> > + cs_prg->num = cs_tprg->num;
> > + /* Allocate the working set array for the merged
> > summary. */
> > + if (ws_cnt)
> > +{
> > + cs_prg->working_set_count = ws_cnt;
> > + cs_prg->working_sets = (gcov_ws_info_t *) malloc (
> > + ws_cnt * sizeof (gcov_ws_info_t));
> > +}
> > +}
> > + else if (cs_prg->num != cs_tprg->num
> > + || ws_cnt != cs_prg->working_set_count)
> > +goto read_mismatch;
> > + /* Copy over this run's working set information if either
> > this is
> > + the first run, the total size of the profile (sum_all) is
> > much
> > + (50%) larger for this run (need to check this before
> > updating
> > + cs_prg->sum_all below), or this run has a larger working
> > + set in the largest (99.99% of sum_all) bucket. */
> > + if (ws_cnt
> > + && (cs_prg->runs == 1
> > + || (cs_tprg->sum_all
> > + > (cs_prg->sum_all + cs_prg->sum_all / 2))
> > + || (cs_tprg->working_sets[ws_cnt - 1].num_counters
> > + > cs_prg->working_sets[ws_cnt -
> > 1].num_counters)))
> > +memcpy (cs_prg->working_sets,
> > +cs_tprg->working_sets,
> > +ws_cnt * sizeof (gcov_ws_info_t));
> > cs_prg->sum_all += cs_tprg->sum_all;
>
> Hmm, when you run i.e. gcc bootstrap where the program is run couple hundred
> times, this will end up really inaccurate, since it will probably just store
> the histogram of insn-attrtab compilation, right?
Well, it should store the largest working set in BBs, or one that came
from a much longer run. But I see the issue you are pointing out. The
num_counters (the number of hot bbs) should be reasonable, as the
total number of BBs is the same between all runs, and I want to show
the largest or more dominant working set in terms of the number of hot
bbs. But the min_bb_counter will become more and more inaccurate as
the number of runs increases, since the counter values are
accumulated.
I typed up a detailed email below on why getting this right would be
difficult, but then I realized there might be a fairly simple accurate
solution, which I'll describe first:
The only way I see to do this completely accurately is to take two
passes through the existing gcda files that we are merging into, one
to read in all the counter values and merge them into all the counter
values in the arrays from the current run (after which we can do the
histogramming/working set computation accurately from the merged
counters), and the second to rewrite them. In libgcov this doesn't
seem like it would be too difficult to do, although it is a little bit
of restructuring of the main merging loop and needs some special
handling for buffered functions (which could increase the memory
footprint a bit if there are many of these since they will all need to
be buffered across the iteration over all the gcda files).
The summary merging in coverage.c confuses me a bit as it seems to be
handling the case when there are multiple program summaries in a
single gcda file. When would this happen? It looks like the merge
handling in libgcov should always produce a single program summary per
gcda file.
>
>
> Why you don't simply write the histogram into gcov file and don't merge the
> values
> here (i.e. doing the cummulation loop in GCC instead of within libgcov)?
That doesn't completely solve the problem, unfortunately. The reason
is that you don't know which histogram entry contains a particular
block each run, and therefore you don't know how to compute the new
combined histogram value and index for that bb counter. For example, a
particular histogram index may have 5 counters (bbs) in it for one run
and 2 counters (bbs) in it for a second run, so the question is how to
compute the new entry for all of those bb counters, as the 5 bbs from
the first run may or may not be a superset of the 2 from the second
run. You could assume that the bbs have the same relative order of
hotness between runs, and combine the bb counters accordingly, but
there is still some trickiness because you have to apportion the
cumulative counter sum stored in the histogram entry between new
entries. For example, assume the highest indexed non-zero entries (the
histogram buckets containing the largest counter values) in the two
incoming histograms are:
histogram 1:
index 100: 4 counters, cumulative value X, min counter value minx
...
histogram 2:
index 100: 2 counters, cumulative value Y, min counter value miny
index 99: 3 counters, cumulative value W, min counter value minw
...
To
Re: [PATCH] Add working-set size and hotness information to fdo summary (issue6465057)
On Sun, Aug 19, 2012 at 9:59 PM, Teresa Johnson wrote:
> On Sat, Aug 18, 2012 at 1:19 AM, Jan Hubicka wrote:
>>
>> > +{
>> > + cs_prg->num = cs_tprg->num;
>> > + /* Allocate the working set array for the merged
>> > summary. */
>> > + if (ws_cnt)
>> > +{
>> > + cs_prg->working_set_count = ws_cnt;
>> > + cs_prg->working_sets = (gcov_ws_info_t *) malloc (
>> > + ws_cnt * sizeof (gcov_ws_info_t));
>> > +}
>> > +}
>> > + else if (cs_prg->num != cs_tprg->num
>> > + || ws_cnt != cs_prg->working_set_count)
>> > +goto read_mismatch;
>> > + /* Copy over this run's working set information if either
>> > this is
>> > + the first run, the total size of the profile (sum_all)
>> > is much
>> > + (50%) larger for this run (need to check this before
>> > updating
>> > + cs_prg->sum_all below), or this run has a larger working
>> > + set in the largest (99.99% of sum_all) bucket. */
>> > + if (ws_cnt
>> > + && (cs_prg->runs == 1
>> > + || (cs_tprg->sum_all
>> > + > (cs_prg->sum_all + cs_prg->sum_all / 2))
>> > + || (cs_tprg->working_sets[ws_cnt - 1].num_counters
>> > + > cs_prg->working_sets[ws_cnt -
>> > 1].num_counters)))
>> > +memcpy (cs_prg->working_sets,
>> > +cs_tprg->working_sets,
>> > +ws_cnt * sizeof (gcov_ws_info_t));
>> > cs_prg->sum_all += cs_tprg->sum_all;
>>
>> Hmm, when you run i.e. gcc bootstrap where the program is run couple hundred
>> times, this will end up really inaccurate, since it will probably just store
>> the histogram of insn-attrtab compilation, right?
>
>
> Well, it should store the largest working set in BBs, or one that came
> from a much longer run. But I see the issue you are pointing out. The
> num_counters (the number of hot bbs) should be reasonable, as the
> total number of BBs is the same between all runs, and I want to show
> the largest or more dominant working set in terms of the number of hot
> bbs. But the min_bb_counter will become more and more inaccurate as
> the number of runs increases, since the counter values are
> accumulated.
>
> I typed up a detailed email below on why getting this right would be
> difficult, but then I realized there might be a fairly simple accurate
> solution, which I'll describe first:
>
> The only way I see to do this completely accurately is to take two
> passes through the existing gcda files that we are merging into, one
> to read in all the counter values and merge them into all the counter
> values in the arrays from the current run (after which we can do the
> histogramming/working set computation accurately from the merged
> counters), and the second to rewrite them. In libgcov this doesn't
> seem like it would be too difficult to do, although it is a little bit
> of restructuring of the main merging loop and needs some special
> handling for buffered functions (which could increase the memory
> footprint a bit if there are many of these since they will all need to
> be buffered across the iteration over all the gcda files).
>
The current way of doing summary merging produces imprecise data (e.g,
sum_max). It computes current execution's summary first, and then
merge with previous run's summary data while profile counters are
merged. The right way is to merge profile counters first, and then
recompute the final summary based on the merged profile. The later
way allows merging of more advanced summary data such as the histogram
here. It is also used in LIPO mode (for dynamic callgraph build/merge
-- kind of a summary itself).
However I think changing the way summary is merged should probably be
done in a different patch.
David
> The summary merging in coverage.c confuses me a bit as it seems to be
> handling the case when there are multiple program summaries in a
> single gcda file. When would this happen? It looks like the merge
> handling in libgcov should always produce a single program summary per
> gcda file.
>
>>
>>
>> Why you don't simply write the histogram into gcov file and don't merge the
>> values
>> here (i.e. doing the cummulation loop in GCC instead of within libgcov)?
>
> That doesn't completely solve the problem, unfortunately. The reason
> is that you don't know which histogram entry contains a particular
> block each run, and therefore you don't know how to compute the new
> combined histogram value and index for that bb counter. For example, a
> particular histogram index may have 5 counters (bbs) in it for one run
> and 2 counters (bbs) in it for a second run, so the question is how to
> compute t
Re: [Patch, Fortran] PR54301 - add warning for pointer might outlive its target
Am 19.08.2012 23:59, schrieb Thomas Koenig:
OK for trunk then. You'll find your patch no longer applies
cleanly, because I have changed the same spot(s) in invoke.texi
and gfortran.h with my recent commit, but I think you'll manage :-)
Thanks for the review. I committed the re-diffed patch as Rev. 190522.
Tobias
2012-08-20 Tobias Burnus
PR fortran/54301
* expr.c (gfc_check_pointer_assign): Warn when the pointer
might outlive its target.
* gfortran.h (struct gfc_option_t): Add warn_target_lifetime.
* options.c (gfc_init_options, set_wall, gfc_handle_option):
handle it.
* invoke.texi (-Wtarget-lifetime): Document it.
(-Wall): Implied it.
* lang.opt (-Wtarget-lifetime): New flag.
2012-08-20 Tobias Burnus
PR fortran/54301
* gfortran.dg/warn_target_lifetime_1.f90: New.
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 7d74528..6f1283d 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3659,6 +3659,38 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr *rvalue)
}
}
+ /* Warn if it is the LHS pointer may lives longer than the RHS target. */
+ if (gfc_option.warn_target_lifetime
+ && rvalue->expr_type == EXPR_VARIABLE
+ && !rvalue->symtree->n.sym->attr.save
+ && !attr.pointer && !rvalue->symtree->n.sym->attr.host_assoc
+ && !rvalue->symtree->n.sym->attr.in_common
+ && !rvalue->symtree->n.sym->attr.use_assoc
+ && !rvalue->symtree->n.sym->attr.dummy)
+{
+ bool warn;
+ gfc_namespace *ns;
+
+ warn = lvalue->symtree->n.sym->attr.dummy
+ || lvalue->symtree->n.sym->attr.result
+ || lvalue->symtree->n.sym->attr.host_assoc
+ || lvalue->symtree->n.sym->attr.use_assoc
+ || lvalue->symtree->n.sym->attr.in_common;
+
+ if (rvalue->symtree->n.sym->ns->proc_name
+ && rvalue->symtree->n.sym->ns->proc_name->attr.flavor != FL_PROCEDURE
+ && rvalue->symtree->n.sym->ns->proc_name->attr.flavor != FL_PROGRAM)
+ for (ns = rvalue->symtree->n.sym->ns;
+ ns->proc_name && ns->proc_name->attr.flavor != FL_PROCEDURE;
+ ns = ns->parent)
+ if (ns->parent == lvalue->symtree->n.sym->ns)
+ warn = true;
+
+ if (warn)
+ gfc_warning ("Pointer at %L in pointer assignment might outlive the "
+ "pointer target", &lvalue->where);
+}
+
return SUCCESS;
}
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index c005151..e796ffe 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
unsigned select_type_temporary:1;
@@ -2226,6 +2231,7 @@ typedef struct
int warn_realloc_lhs;
int warn_realloc_lhs_all;
int warn_compare_reals;
+ int warn_target_lifetime;
int max_errors;
int flag_all_intrinsics;
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index d962ca0..dfd4ca7 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -147,7 +147,7 @@ and warnings}.
-Wimplicit-procedure -Wintrinsic-shadow -Wintrinsics-std @gol
-Wline-truncation -Wno-align-commons -Wno-tabs -Wreal-q-constant @gol
-Wsurprising -Wunderflow -Wunused-parameter -Wrealloc-lhs Wrealloc-lhs-all @gol
--fmax-errors=@var{n} -fsyntax-only -pedantic -pedantic-errors
+-Wtarget-lifetime -fmax-errors=@var{n} -fsyntax-only -pedantic -pedantic-errors
}
@item Debugging Options
@@ -729,8 +729,8 @@ we recommend avoiding and that we believe are easy to avoid.
This currently includes @option{-Waliasing}, @option{-Wampersand},
@option{-Wconversion}, @option{-Wcompare-reals}, @option{-Wsurprising},
@option{-Wintrinsics-std}, @option{-Wno-tabs}, @option{-Wintrinsic-shadow},
-@option{-Wline-truncation}, @option{-Wreal-q-constant} and
-@option{-Wunused}.
+@option{-Wline-truncation}, @option{-Wtarget-lifetime},
+@option{-Wreal-q-constant} and @option{-Wunused}.
@item -Waliasing
@opindex @code{Waliasing}
@@ -941,6 +941,11 @@ allocatable variable; this includes scalars and derived types.
Warn when comparing real or complex types for equality or inequality.
Enabled by @option{-Wall}.
+@item -Wtarget-lifetime
+@opindex @code{Wtargt-lifetime}
+Warn if the pointer in a pointer assignment might be longer than the its
+target. This option is implied by @option{-Wall}.
+
@item -Werror
@opindex @code{Werror}
@cindex warnings, to errors
diff --git a/gcc/fortran/lang.opt b/gcc/fortran/lang.opt
index e0c7cf7..b38b1e8 100644
--- a/gcc/fortran/lang.opt
+++ b/gcc/fortran/lang.opt
@@ -262,6 +262,10 @@ Wrealloc-lhs-all
Fortran Warning
Warn when a left-hand-side variable is reallocated
+Wtarget-lifetime
+Fortran Warning
+Warn if the pointer in a pointer assignment might outlive its target
+
Wreturn-type
Fortran Warning
; Documented in C
diff --git a/gcc/fortran/options.c b/gcc/fortran/options.c
index 3ed..cbec705 100644
--- a/gcc/fortran/options.c
+++ b/gcc/fortran/options.c
@@ -114,6 +114,7 @@ gfc_init_options (unsigned int decoded_options_count,
gfc_option.warn_realloc_lhs = 0;
gfc_option.warn_realloc_lhs_all = 0;
gfc_option.warn_compare_reals = 0;
+ gfc_o
[PATCH] Fix loop pattern distribution ICE (PR tree-optimization/54321)
Hi!
The middle-end argument of memset is signed (int), so simplify_builtin_call
correctly checks host_integerp (val2, 0), but later on used tree_low_cst
(val2, 1), so for negative values it would ICE. Fixed thusly, the memset
is supposed to cast the int to unsigned char internally anyway.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-08-20 Jakub Jelinek
PR tree-optimization/54321
* tree-ssa-forwprop.c (simplify_builtin_call): Pass 0 instead of 1
as second argument to tree_low_cst call on val2.
* gcc.c-torture/compile/pr54321.c: New test.
--- gcc/tree-ssa-forwprop.c.jj 2012-08-14 08:45:00.0 +0200
+++ gcc/tree-ssa-forwprop.c 2012-08-20 08:11:06.247936035 +0200
@@ -1554,7 +1554,7 @@ simplify_builtin_call (gimple_stmt_itera
else
src_buf[0] = tree_low_cst (src1, 0);
memset (src_buf + tree_low_cst (diff, 1),
- tree_low_cst (val2, 1), tree_low_cst (len2, 1));
+ tree_low_cst (val2, 0), tree_low_cst (len2, 1));
src_buf[src_len] = '\0';
/* Neither builtin_strncpy_read_str nor builtin_memcpy_read_str
handle embedded '\0's. */
--- gcc/testsuite/gcc.c-torture/compile/pr54321.c.jj2012-08-20
08:12:10.955630873 +0200
+++ gcc/testsuite/gcc.c-torture/compile/pr54321.c 2012-08-20
08:13:27.963398948 +0200
@@ -0,0 +1,12 @@
+/* PR tree-optimization/54321 */
+struct S { char s[0]; } *a;
+
+void
+foo (void)
+{
+ char *b = a->s;
+ int c = 0;
+ b[0] = 0;
+ while (++c < 9)
+b[c] = 255;
+}
Jakub
