Re: [PATCH] Fix AVR fallout
2012/8/18 Jan-Benedict Glaw jbg...@lug-owl.de: Hi! I see these warnings/errors right now: g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include -I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber-I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include -I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber ../../../../gcc/gcc/config/avr/avr-log.c cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option ‘-Wold-style-definition’ is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option ‘-Wc++-compat’ is valid for C/ObjC but not for C++ [enabled by default] ../../../../gcc/gcc/config/avr/avr-log.c: In function ‘void avr_log_vadump(FILE*, const char*, va_list)’: ../../../../gcc/gcc/config/avr/avr-log.c:287:22: warning: ‘machine_mode’ is promoted to ‘int’ when passed through ‘...’ [enabled by default] ../../../../gcc/gcc/config/avr/avr-log.c:287:22: note: (so you should pass ‘int’ not ‘machine_mode’ to ‘va_arg’) ../../../../gcc/gcc/config/avr/avr-log.c:287:22: note: if this code is reached, the program will abort ../../../../gcc/gcc/config/avr/avr-log.c:291:31: warning: ‘rtx_code’ is promoted to ‘int’ when passed through ‘...’ [enabled by default] ../../../../gcc/gcc/config/avr/avr-log.c:291:31: note: if this code is reached, the program will abort ../../../../gcc/gcc/config/avr/avr-log.c:295:38: warning: ‘reg_class’ is promoted to ‘int’ when passed through ‘...’ [enabled by default] ../../../../gcc/gcc/config/avr/avr-log.c:295:38: note: if this code is reached, the program will abort [...] g++ -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include -I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber-I. -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/. -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include -I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber ../../../../gcc/gcc/config/avr/gen-avr-mmcu-texi.c -o gen-avr-mmcu-texi cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option ‘-Wold-style-definition’ is valid for C/ObjC but not for C++ [enabled by default] cc1plus: warning: command line option ‘-Wc++-compat’ is valid for C/ObjC but not for C++ [enabled by default] ../../../../gcc/gcc/config/avr/gen-avr-mmcu-texi.c: In function ‘int main()’: ../../../../gcc/gcc/config/avr/gen-avr-mmcu-texi.c:53:24: error: invalid conversion from ‘int’ to ‘avr_arch’ [-fpermissive] ../../../../gcc/gcc/config/avr/gen-avr-mmcu-texi.c:75:23: error: invalid conversion from ‘int’ to ‘avr_arch’ [-fpermissive] make[3]: *** [gen-avr-mmcu-texi] Error 1 make[3]: Leaving directory `/mnt/devel/src/linux/build/avr/gcc-stage1/gcc' make[2]: *** [all-gcc] Error 2 make[2]: Leaving directory `/mnt/devel/src/linux/build/avr/gcc-stage1' I suggest this patch. Okay? 2012-08-17 Jan-Benedict Glaw jbg...@lug-owl.de 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. Denis.
[PATCH, Committed] Fix ChangeLog (was: [PATCH] Fix AVR fallout)
On Sun, 2012-08-19 10:19:37 +0400, Denis Chertykov cherty...@gmail.com wrote: 2012/8/18 Jan-Benedict Glaw jbg...@lug-owl.de: [...] 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 jbg...@lug-owl.de * ChangeLog: Fix whitespace. Index: ChangeLog === --- ChangeLog (revision 190511) +++ ChangeLog (working copy) @@ -5,11 +5,11 @@ 2012-08-18 Jan-Benedict Glaw jbg...@lug-owl.de -* 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 j...@suse.cz -- 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 mik...@gcc.gnu.org + + * Make-lang.in: Fix typo. + 2012-08-17 Jakub Jelinek ja...@redhat.com * 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 tkoe...@gcc.gnu.org
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 tkoe...@gcc.gnu.org
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;
+
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 ebotca...@adacore.com
* gcc-interface/decl.c (gnat_to_gnu_entity) E_Record_Type: 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 ebotca...@adacore.com
* 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 bur...@net-b.de
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 bur...@net-b.de
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 Warning
Warn when a left-hand-side variable is
Re: [graphds.h] Allocate graph from obstack
On Sat, Aug 18, 2012 at 8:10 PM, Dimitrios Apostolou ji...@gmx.net 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 andrew.pin...@caviumnetworks.com 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 *insvmode_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, MODEmode);
+ operands[2] = GEN_INT (pos);
+ operands[4] = GEN_INT (len);
+ return dins\t%0,%3,%2,%4;
+}
+ [(set_attr type arith)
+ (set_attr mode 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 === +liThe default alignment settings have been reduced to be less aggresive. aggressive + liMinor tweaks for code around software atomic sequences that are + enabled by code-msoft-atomic/code./li code for? Not sure... + liA new option code-menable-tas/code will make the compiler + generate the codetas.b/code instruction for the + code__atomic_test_and_set/code built-in function./li A naive question: Why is this not on by default? Or is it under certain circumstances? +liThe codefmac/code instruction will now be emitted by the +codefmaf/code standard and built-in function./li built-in standard function, perhaps? +liThe code-mfused-madd/code option has been depricated in favor of deprecated +liAdded new options code-mfsrra/code and code-mfsca/code to allow +the compiler using the codefsrra/code and codefsca/code +instructions on CPUs other than SH4A./li 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 san...@codesourcery.com 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 san...@codesourcery.com Julian Brown jul...@codesourcery.com 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 fanfarillo@gmail.com
Tobias Burnus bur...@net-b.de
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 fanfarillo@gmail.com
Tobias Burnus bur...@net-b.de
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
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 === +liThe default alignment settings have been reduced to be less aggresive. aggressive Fixed. + liMinor tweaks for code around software atomic sequences that are + enabled by code-msoft-atomic/code./li code for? Not sure... Rephrased. + liA new option code-menable-tas/code will make the compiler + generate the codetas.b/code instruction for the + code__atomic_test_and_set/code built-in function./li 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. +liThe codefmac/code instruction will now be emitted by the +codefmaf/code standard and built-in function./li built-in standard function, perhaps? Clarified. +liThe code-mfused-madd/code option has been depricated in favor of deprecated Fixed. +liAdded new options code-mfsrra/code and code-mfsca/code to allow +the compiler using the codefsrra/code and codefsca/code +instructions on CPUs other than SH4A./li 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 @@ h3SH/h3 ul -liThe default alignment settings have been reduced to be less aggresive. +liThe default alignment settings have been reduced to be less aggressive. This results in more compact code for optimization levels other than code-Os/code./li liImproved support for the code__atomic/code built-in functions: ul - liMinor tweaks for code around software atomic sequences that are - enabled by code-msoft-atomic/code./li + liMinor improvements to code generated for software atomic sequences + that are enabled by code-msoft-atomic/code./li liA new option code-menable-tas/code will make the compiler generate the codetas.b/code instruction for the @@ -197,9 +197,10 @@ code__builtin_prefetch/code built-in function for SH3./li liThe codefmac/code instruction will now be emitted by the -codefmaf/code standard and built-in function./li +codefmaf/code standard function and the code__builtin_fmaf/code +built-in function./li -liThe code-mfused-madd/code option has been depricated in favor of +liThe code-mfused-madd/code option has been deprecated in favor of the machine-independent code-ffp-contract/code option. Notice that the codefmac/code instruction will now be generated by default for expressions like codea * b + c/code. This is due to the compiler @@ -207,7 +208,8 @@ liAdded new options code-mfsrra/code and code-mfsca/code to allow the compiler using the codefsrra/code and codefsca/code -instructions on CPUs other than SH4A./li +instructions on CPUs other than SH4A (where they are already enabled by +default)./li liAdded support for the code__builtin_bswap32/code built-in function. It is now expanded as a sequence of codeswap.b/code 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 ji...@gmx.net
* 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 ji...@gmx.net
* 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
alloc_pool for tree-ssa-pre.c:phi_translate_table
2012-08-19 Dimitrios Apostolou ji...@gmx.net
* 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 ji...@gmx.net
* 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_removeexpr_pred_trans_d
+typedef struct expr_pred_trans_d : typed_noop_removeexpr_pred_trans_d
{
/* 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 ji...@gmx.net
* 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 ji...@gmx.net
* 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 rguent...@suse.de 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 rguent...@suse.de
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 jbg...@lug-owl.de wrote: I fixed ChangeLog's whitespace (probably cut'n'paste error), committed as obvious. 2012-08-19 Jan-Benedict Glaw jbg...@lug-owl.de * 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 i...@google.com wrote: On Sun, Aug 19, 2012 at 1:34 AM, Jan-Benedict Glaw jbg...@lug-owl.de wrote: I fixed ChangeLog's whitespace (probably cut'n'paste error), committed as obvious. 2012-08-19 Jan-Benedict Glaw jbg...@lug-owl.de * 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 ji...@gmx.net wrote:
Hello,
2012-08-19 Dimitrios Apostolou ji...@gmx.net
* 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 (match_operand:DI 0 arith_reg_dest =r)
(ashiftrt:DI (match_operand:DI 1 arith_reg_operand 0)
Re: [PATCH][3/n] into-SSA TLC
On Fri, Jul 27, 2012 at 5:16 AM, Richard Guenther rguent...@suse.de 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 rguent...@suse.de * 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 de...@google.com 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 de...@google.com
* 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;
+ if (locus == 0 data == NULL)
+return 0;
+ lb.locus = locus;
+ lb.data = data;
+ slot = (struct
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 ji...@gmx.net wrote: Hello, 2012-08-19 Dimitrios Apostolou ji...@gmx.net * 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
richard.guent...@gmail.com wrote:
On Tue, Jul 24, 2012 at 5:50 PM, Andrew Pinski
andrew.pin...@caviumnetworks.com 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 hubi...@ucw.cz 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 merge, you could assume something like 2 counters with a new
cumulative value (Y +
Re: [PATCH] Add working-set size and hotness information to fdo summary (issue6465057)
On Sun, Aug 19, 2012 at 9:59 PM, Teresa Johnson tejohn...@google.com wrote:
On Sat, Aug 18, 2012 at 1:19 AM, Jan Hubicka hubi...@ucw.cz 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 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
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 bur...@net-b.de
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 bur...@net-b.de
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_option.warn_target_lifetime = 0;
