Re: [Patch, AVR]: PR42240 - Fix epilogue of naked functions
Weddington, Eric schrieb: -Original Message- From: Georg-Johann Lay [mailto:a...@gjlay.de] Sent: Thursday, March 03, 2011 11:01 AM To: Denis Chertykov Cc: gcc-patches@gcc.gnu.org; Anatoly Sokolov; Weddington, Eric Subject: Re: [Patch, AVR]: PR42240 - Fix epilogue of naked functions Denis. I don't know what the policy concerning the depth of backporting bugfixes actually is. At least the check-in rule is documentation and bug fixes only so I though (backport of) bugfix is all right. My intention was to go deep enough to have PR42240 resolved/fixed, i.e. in all versions that are still supported. Or what backports must be done in order to have it resolved/fixed? Most public distributions of avr-gcc have the 4.4 series. I think fixing this to 4.5 should be fine. So gcc 4.4/4.3 users are not interested in bugs being fixed? Astonished, Johann
Re: libiberty/cplus-dem.c, ada-demangle: plug memory leak.
On Mar 3, 2011, at 10:59 PM, Michael Snyder wrote: Jakub Jelinek wrote: On Thu, Mar 03, 2011 at 01:20:28PM -0800, Michael Snyder wrote: 2011-03-03 Michael Snyder msny...@vmware.com * libiberty/cplus-dem.c (ada_demangle): Stop memory leak. Also fix a one line indent problem. No libiberty/ in libiberty/ChangeLog. @@ -1129,10 +1129,11 @@ ada_demangle (const char *mangled, int o unknown: len0 = strlen (mangled); + xfree (demangled); demangled = XNEWVEC (char, len0 + 3); xfree isn't ever used in libiberty/*, use either free, or XDELETE/XDELETEVEC. In fact, it seems to be defined only in gdb, making cplus-dem.c dependent on gdb is obviously a wrong thing. Thanks for the review. How's this? + if (demangled != NULL) +free (demangled); No need to check that demangled is not NULL. (Nice catches!) Tristan.
Re: build_function_call and TREE_ADDRESSABLE
On Fri, Mar 4, 2011 at 5:58 AM, Alan Modra amo...@gmail.com wrote: Warn off anyone trying to do as I did, and the bit about inlines is no longer relevant. OK to apply? * tree.h (TREE_ADDRESSABLE): Note that direct calls set the flag on FUNCTION_DECLs. Index: gcc/tree.h === --- gcc/tree.h (revision 170665) +++ gcc/tree.h (working copy) @@ -1106,8 +1106,8 @@ extern void omp_clause_range_check_faile /* In VAR_DECL, PARM_DECL and RESULT_DECL nodes, nonzero means address of this is needed. So it cannot be in a register. - In a FUNCTION_DECL, nonzero means its address is needed. - So it must be compiled even if it is an inline function. + In a FUNCTION_DECL, nonzero means its address is needed. This even + happens on a direct call, making the flag fairly useless. In CONSTRUCTOR nodes, it means object constructed must be in memory. In LABEL_DECL nodes, it means a goto for this label has been seen from a place outside all binding contours that restore stack levels. Rather 'In a FUNCTION_DECL, it has no meaning.' Ok with that change. Richard. -- Alan Modra Australia Development Lab, IBM
Re: [doc, PATCH] Remove redundant word See before @xref
On Thu, 3 Mar 2011, Mingjie Xing wrote: 2011-03-03 Mingjie Xing mingjie.x...@gmail.com * doc/cfg.texi: Remove See before @ref. * doc/invoke.texi: Likewise. This is fine, thank you. If you want to apply this to the GCC 4.5 branch as well, that's fine, too. Gerald
Re: [Patch, libfortran] PR 47802 Update documentation for CTIME and FDATE
On 03/01/2011 10:26 PM, Janne Blomqvist wrote:
Ok for trunk?
@code{CTIME} converts a system time value, such as returned by
-@code{TIME8}, to a string of the form @samp{Sat Aug 19 18:13:14 1995}.
+@code{TIME8}, to a localized string. Unless the application has called
+@code{setlocale}, the output will be in the default locale, of length
+24 and of the form @samp{Sat Aug 19 18:13:14 1995}. In other locales,
+a longer string may result.
I would suggest to remove the first localized - it gives too much
focus on the localization, which is usually not happening. (Side remark:
As it is a kind=1 string, certain localizations are not really possible
or in UTF-8 cause string-length issues.)
You should mention that - in case of the subroutine version - the RESULT
will be blank if the string does not fit.
+default kind. It is an @code{INTENT(OUT)} argument. If the length of
+this variable is too short for the localized date and time string to
+fit completely, it will be empty on procedure return.
I think you should scratch the localized here and use the wording from
ctime. Additionally, empty is not really a concept of a string. I
think you should use the word blank. (The word empty fits better
for the result variable which would be is a string of length 0.)
(The repetition of the ctime wording might sound superfluous, but most
readers directly jump to the function, not knowing the ctime wording
when looking for ftime.)
@item @emph{Return value}:
-The current date as a string.
+The current date and time as a localized string. If the
+@code{CHARACTER} variable to which the result is assigned is too
+short, the result is truncated.
Again, I would leave out the localized here - and only mention it
together with setlocale in the Description. I am also not sure one needs
the words about truncation as this is a general concept of string
assignment. (Additionally, it is not quite true: Instead of truncation
also a reallocation with the right size could happen - for allocatable
len=: strings.)
With the nits fixed - or at least considered, the patch is OK. Thanks
for working on thread safety.
Tobias
2011-03-01 Janne Blomqvistj...@gcc.gnu.org
PR libfortran/47802
* gcc/fortran/intrinsics.texi: Update CTIME and FDATE
documentation.
Re: ivopts improvement
On 03/04/2011 08:37 AM, Paolo Bonzini wrote: On 03/03/2011 03:28 PM, Tom de Vries wrote: reg-tested on x86_64. Better? Yes, very much so Great. Thanks for the review. (talking about patch 6.5; the other one is an optimization but not essential based on the new comments). Just one question: what happens if the COND_EXPR is indeed turned into a MAX_EXPR? Is it a missed optimization? It is. It will take some effort to get cost calculation for MAX_EXPR ok. One additional problem (beside costs) that I observed also might need fixing: a new bound (containing a MAX_EXPR) is generated for an inner loop. The new bound is outer loop invariant. The MAX_EXPR however expands into control flow, and is not hoisted out of the outer loop, while the rest of the bound calculation is. Is it because of overflow that you aren't _always_ creating a MAX_EXPR directly? Indeed. The COND_EXPR created for my example is: ... (i + 1 = n) ? (~i + n) : 0 ... where i and n are unsigned int. simplified: ... (i + 1 = n) ? (n - (i + 1)) : 0 ... The condition i + 1 = n precisely states the cases when n - (i + 1) does not underflow. Thanks, - Tom
Re: ivopts improvement
On 03/04/2011 02:57 PM, Tom de Vries wrote:
The MAX_EXPR however
expands into control flow, and is not hoisted out of the outer loop,
while the rest of the bound calculation is.
That looks like a pass-ordering problem too (both on the tree level, for
ivopts versus invariant motion, and on the RTL level where predicated
instructions are created after invariant motion).
I just noticed that ARM doesn't have named {s,u}{min,max} patterns.
Perhaps adding those helps hoisting the control-flow out of the loop in
your case.
Paolo
Re: [2/2] Reducing the overhead of dwarf2 location tracking
Richard Guenther richard.guent...@gmail.com writes:
On Fri, Mar 4, 2011 at 2:56 PM, Richard Sandiford
richard.sandif...@linaro.org wrote:
Suppose we have a function F that is inlined several times. Suppose too
that F has a local variable X, and that no real (as opposed to debug)
references to X remain after pre-inlining optimisations. In this case,
we will add X to BLOCK_NONLOCALIZED_VARS rather than duplicate it each
time F is inlined. Location notes for each inlining of F will then
refer to the same non-localised X decl. This in turn means that each
inlining of F has the same location list for X, with the list specifying
the location of X for all inlinings of F.
Jakub confirms that this indeed the intended behaviour, and I haven't
seen any problem with the output.
Hm, but isn't it incorrect debug info? I would have expected this
non-localized var to be the abstract origin of a copy for location
list purposes.
Well, for
static inline int foo (int p) { int q = p; return q; }
int bar1 (int i)
{
return foo (i);
}
int bar2 (int j)
{
return foo (j);
}
I don't even see location lists for q, but maybe I'm blind ;)
Yeah, it does seem to be a bit selective.
FWIW, I used the attached while writing the patch. The count* variables
are affected. I was using a ulimit of 1GB (IIRC): without the patch,
the OOM_BEFORE definition of A2 caused an OOM, whereas after it,
the longer definition was OK.
Richard
volatile int g;
static inline __attribute__((always_inline)) int
f (int x)
{
#define C0(X, Y) X = Y
#define C1(X, Y) C0 (X##0, Y), C0 (X##1, Y | X##0), C0 (X##2, Y + X##0), C0
(X##3, Y X##0)
#define C2(X, Y) C1 (X##0, Y), C1 (X##1, Y), C1 (X##2, Y), C1 (X##3, Y)
#define C3(X, Y) C2 (X##0, Y), C2 (X##1, Y), C2 (X##2, Y), C2 (X##3, Y)
#define A0 C3 (count, 1), x += g, C3 (count, x), x += g
#define A1 A0, A0, A0, A0, A0, A0, A0, A0
#ifdef OOM_BEFORE
#define A2 A1, A1, A1, A1
#else
#define A2 A1, A1, A1, A1, A1
#endif
int C3 (count, 0);
A2;
return x;
}
int
b (int *ptr)
{
#define B0 x = f (x)
#define B1 B0, B0, B0, B0, B0, B0, B0, B0
#define B2 B1, B1, B1
int x = 0;
B2;
return x;
}
Re: [2/2] Reducing the overhead of dwarf2 location tracking
On Fri, Mar 4, 2011 at 4:10 PM, Jakub Jelinek ja...@redhat.com wrote: On Fri, Mar 04, 2011 at 04:00:06PM +0100, Richard Guenther wrote: But then location lists for those variables depend on the function context and cannot be shared for different callers. Am I missing something? Sure, they can't be shared between different functions. If Richard's patch does that, it is wrong. Likewise I don't see how they could be shared for multiple inline instances in the same function. But there is no reason why it can't be shared within one function, across many inline instances. There is just a single nonlocalized decl in all those cases you cache, and even if it appears in multiple BLOCKs BLOCK_NONLOCALIZED_VARS, VAR_LOCATION notes referencing it are still all queued for that DECL_UID from the whole function and any time you want to create a location list from what has been queued in the VAR_LOCATION notes, you will get the same list. Ah, ok - that makes sense. We have a single location list covering all BLOCKs where the decl appears in BLOCK_NONLOCALIZED_VARS. Somehow I thought this would already happen. Richard. Jakub
Re: [ping] Re: [patch, powerpc] #undef LINK_EH_SPEC before defining it
On Fri, 4 Mar 2011, Alan Modra wrote: On Fri, Mar 04, 2011 at 08:38:18AM +0100, Jakub Jelinek wrote: We see it because we add --no-add-needed to linux LINK_EH_SPECs. OK. Adding the #undef is then required.. Including freebsd-spec.h in a Linux configuration is certainly very questionable and undefining LINK_EH_SPEC and other macros before defining them would be certainly cleaner if the freebsd-spec.h include can't be just killed. It's there for -mcall-freebsd. Take that away and you won't need freebsd-spec.h in powerpc-linux configs. I'd certainly like to see the -mcall-* code that pretends to support linking for one target using another target's compiler removed. That way non-FreeBSD targets wouldn't need freebsd-spec.h, rs6000/sysv4.h wouldn't need loads of specs that are really irrelevant to all but one target, and you could probably make powerpc*-linux* use the toplevel gnu-user.h and linux.h like almost all other Linux kernel targets. That these powerpc* targets are doing things differently from all other architectures is a nuisance when making changes across all targets (and I don't think what they are doing is a useful intermediate step towards a multi-target compiler). -- Joseph S. Myers jos...@codesourcery.com
Re: [Patch, libfortran] PR 47802 Update documentation for CTIME and FDATE
On Fri, Mar 4, 2011 at 15:56, Tobias Burnus bur...@net-b.de wrote:
On 03/01/2011 10:26 PM, Janne Blomqvist wrote:
Ok for trunk?
@code{CTIME} converts a system time value, such as returned by
-@code{TIME8}, to a string of the form @samp{Sat Aug 19 18:13:14 1995}.
+@code{TIME8}, to a localized string. Unless the application has called
+@code{setlocale}, the output will be in the default locale, of length
+24 and of the form @samp{Sat Aug 19 18:13:14 1995}. In other locales,
+a longer string may result.
I would suggest to remove the first localized - it gives too much focus on
the localization, which is usually not happening.
Ok.
(Side remark: As it is a
kind=1 string, certain localizations are not really possible or in UTF-8
cause string-length issues.)
Well, depends on what one means with string length? :) Gfortran
will get the number of bytes used right, yes, but this might not be
the same as the number of characters which might not be the same as
the column width of the string (e.g. consider the character 'ä'
represented as whatever unicode symbol corresponds to 'ä' vs. the
unicode symbol 'a' followed by the diacritic for the two dots; both
are valid UTF-8). Anyway, this part of the documentation is probably
not the right place to launch into an extended discussion of i18n and
unicode issues.
You should mention that - in case of the subroutine version - the RESULT
will be blank if the string does not fit.
I believe my patch already does that, see the Arguments paragraph.
+default kind. It is an @code{INTENT(OUT)} argument. If the length of
+this variable is too short for the localized date and time string to
+fit completely, it will be empty on procedure return.
I think you should scratch the localized here and use the wording from
ctime. Additionally, empty is not really a concept of a string. I think
you should use the word blank. (The word empty fits better for the
result variable which would be is a string of length 0.)
Ah, yes. I was searching for a suitable word myself, as empty sounded
a bit ambiguous.
(The repetition of the ctime wording might sound superfluous, but most
readers directly jump to the function, not knowing the ctime wording when
looking for ftime.)
@item @emph{Return value}:
-The current date as a string.
+The current date and time as a localized string. If the
+@code{CHARACTER} variable to which the result is assigned is too
+short, the result is truncated.
Again, I would leave out the localized here - and only mention it together
with setlocale in the Description. I am also not sure one needs the words
about truncation as this is a general concept of string assignment.
(Additionally, it is not quite true: Instead of truncation also a
reallocation with the right size could happen - for allocatable len=:
strings.)
Good point; I removed the notice about truncation.
With the nits fixed - or at least considered, the patch is OK. Thanks for
working on thread safety.
Thanks for the review and suggestions. The patch I ultimately
committed is attached.
--
Janne Blomqvist
diff --git a/gcc/fortran/intrinsic.texi b/gcc/fortran/intrinsic.texi
index 1ff4db3..28b5fe8 100644
--- a/gcc/fortran/intrinsic.texi
+++ b/gcc/fortran/intrinsic.texi
@@ -3218,7 +3218,10 @@ end program test_cshift
@table @asis
@item @emph{Description}:
@code{CTIME} converts a system time value, such as returned by
-@code{TIME8}, to a string of the form @samp{Sat Aug 19 18:13:14 1995}.
+@code{TIME8}, to a string. Unless the application has called
+@code{setlocale}, the output will be in the default locale, of length
+24 and of the form @samp{Sat Aug 19 18:13:14 1995}. In other locales,
+a longer string may result.
This intrinsic is provided in both subroutine and function forms; however,
only one form can be used in any given program unit.
@@ -3232,18 +3235,20 @@ Subroutine, function
@item @emph{Syntax}:
@multitable @columnfractions .80
@item @code{CALL CTIME(TIME, RESULT)}.
-@item @code{RESULT = CTIME(TIME)}, (not recommended).
+@item @code{RESULT = CTIME(TIME)}.
@end multitable
@item @emph{Arguments}:
@multitable @columnfractions .15 .70
-@item @var{TIME}@tab The type shall be of type @code{INTEGER(KIND=8)}.
+@item @var{TIME}@tab The type shall be of type @code{INTEGER}.
@item @var{RESULT} @tab The type shall be of type @code{CHARACTER} and
-of default kind.
+of default kind. It is an @code{INTENT(OUT)} argument. If the length
+of this variable is too short for the time and date string to fit
+completely, it will be blank on procedure return.
@end multitable
@item @emph{Return value}:
-The converted date and time as a string.
+The converted date and time as a string.
@item @emph{Example}:
@smallexample
@@ -3260,7 +3265,7 @@ end program test_ctime
@end smallexample
@item @emph{See Also}:
-@ref{GMTIME}, @ref{LTIME}, @ref{TIME}, @ref{TIME8}
+@ref{DATE_AND_TIME}, @ref{GMTIME}, @ref{LTIME}, @ref{TIME}, @ref{TIME8}
@end
Re: libiberty/cplus-dem.c, ada-demangle: plug memory leak.
Michael How come 'xfree' in gdb/utils.c still checks for null? I don't know, but I assume just because nobody has bothered to remove the check. I think we also still have code doing `if (x) xfree (x);', which is kind of doubly wrong :) Tom
Re: ObjC/ObjC++: Fix property encoding on Apple
On 4 Mar 2011, at 16:41, Dominique Dhumieres wrote:
Nicola,
obj-c++.dg/property/property-encoding-1.mm fails to compile with:
[...]
You need to use the right C++ incantations, [...]
Apologies. I now did the obvious changes that should make it work in
both the ObjC
and ObjC++ testsuites, and committed them as obvious.
Please let me know if it still doesn't work!
Thanks
Index: ChangeLog
===
--- ChangeLog (revision 170682)
+++ ChangeLog (working copy)
@@ -1,5 +1,10 @@
2011-03-04 Nicola Pero nicola.p...@meta-innovation.com
+ * objc.dg/property/property-encoding-1.m: Tidied up testcase.
+ * obj-c++.dg/property/property-encoding-1.mm: Likewise.
+
+2011-03-04 Nicola Pero nicola.p...@meta-innovation.com
+
* objc.dg/gnu-api-2-property.m: Added tests for
property_getName()
and property_getAttributes() if __OBJC2__.
* obj-c++.dg/gnu-api-2-property.mm: Likewise.
Index: objc.dg/property/property-encoding-1.m
===
--- objc.dg/property/property-encoding-1.m (revision 170682)
+++ objc.dg/property/property-encoding-1.m (working copy)
@@ -89,22 +89,21 @@ void error (objc_property_t p)
}
/* Concatenate 3 strings and return the result. */
-char *concat (char *a, char *b, char *c)
+char *concat (const char *a, const char *b, const char *c)
{
/* We happily leak memory here. This is a test. */
- char *x = malloc (sizeof (char) * 128);
+ char *x = (char *)malloc (sizeof (char) * 128);
snprintf (x, 128, %s%s%s, a, b, c);
return x;
}
#endif
-int main(int argc, void **args)
+int main (void)
{
#ifdef __OBJC2__
Class c = objc_getClass (MySubClass);
objc_property_t p;
- const char *expected_result;
p = class_getProperty (c, char_property);
/* Usually we expect Tc,Vchar_property, but if a char is of
Index: obj-c++.dg/property/property-encoding-1.mm
===
--- obj-c++.dg/property/property-encoding-1.mm (revision 170682)
+++ obj-c++.dg/property/property-encoding-1.mm (working copy)
@@ -89,22 +89,21 @@ void error (objc_property_t p)
}
/* Concatenate 3 strings and return the result. */
-char *concat (char *a, char *b, char *c)
+char *concat (const char *a, const char *b, const char *c)
{
/* We happily leak memory here. This is a test. */
- char *x = malloc (sizeof (char) * 128);
+ char *x = (char *)malloc (sizeof (char) * 128);
snprintf (x, 128, %s%s%s, a, b, c);
return x;
}
#endif
-int main(int argc, char **args)
+int main (void)
{
#ifdef __OBJC2__
Class c = objc_getClass (MySubClass);
objc_property_t p;
- const char *expected_result;
p = class_getProperty (c, char_property);
/* Usually we expect Tc,Vchar_property, but if a char is of
[Committed] S/390: Fix problems with literal pools refs
Hi,
the attached patch fixes a problem with literal pool relative
references. Only if these themself reference literal pool slots using
these values as displacement in addresses is valid. CSE sometimes
tries to pull such values out of the literal pool. This patch rejects
non-literal pool references as addresses in order to prevent that.
Bootstrapped on s390 and s390x.
This together with
[PATCH] recog.c: Fix RTX unsharing in change groups
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00187.html
fixes 54 testcases on s390.
Committed to mainline.
Bye,
-Andreas-
2011-03-04 Andreas Krebbel andreas.kreb...@de.ibm.com
* config/s390/s390.c (s390_decompose_address): Reject non-literal
pool references in UNSPEC_LTREL_OFFSET.
Index: gcc/config/s390/s390.c
===
*** gcc/config/s390/s390.c.orig
--- gcc/config/s390/s390.c
*** s390_decompose_address (rtx addr, struct
*** 2065,2070
--- 2065,2080
else if (GET_CODE (disp) == UNSPEC
XINT (disp, 1) == UNSPEC_LTREL_OFFSET)
{
+ /* In case CSE pulled a non literal pool reference out of
+the pool we have to reject the address. This is
+especially important when loading the GOT pointer on non
+zarch CPUs. In this case the literal pool contains an lt
+relative offset to the _GLOBAL_OFFSET_TABLE_ label which
+will most likely exceed the displacement. */
+ if (GET_CODE (XVECEXP (disp, 0, 0)) != SYMBOL_REF
+ || !CONSTANT_POOL_ADDRESS_P (XVECEXP (disp, 0, 0)))
+ return false;
+
orig_disp = gen_rtx_CONST (Pmode, disp);
if (offset)
{
[PATCH] Avoid IPA-CP versioning if type mismatch prevents it (PR tree-optimization/47967)
Hi!
If conversion between parameter type and passed argument is not useless,
is not fold convertible and has different size, then even VCE is not
appropriate, but for something so undefined we shouldn't be IMHO
trying to optimize anything.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2011-03-04 Jakub Jelinek ja...@redhat.com
PR tree-optimization/47967
* ipa-cp.c (build_const_val): Return NULL instead of creating
VIEW_CONVERT_EXPR for mismatching sizes.
(ipcp_create_replace_map): Return NULL if build_const_val failed.
(ipcp_insert_stage): If ipcp_create_replace_map returns NULL,
give up on versioning.
* gcc.c-torture/compile/pr47967.c: New test.
--- gcc/ipa-cp.c.jj 2011-02-15 15:34:33.0 +0100
+++ gcc/ipa-cp.c2011-03-04 14:29:23.0 +0100
@@ -587,8 +587,9 @@ ipcp_initialize_node_lattices (struct cg
}
}
-/* build INTEGER_CST tree with type TREE_TYPE and value according to LAT.
- Return the tree. */
+/* Build a constant tree with type TREE_TYPE and value according to LAT.
+ Return the tree, or, if it is not possible to convert such value
+ to TREE_TYPE, NULL. */
static tree
build_const_val (struct ipcp_lattice *lat, tree tree_type)
{
@@ -601,8 +602,10 @@ build_const_val (struct ipcp_lattice *la
{
if (fold_convertible_p (tree_type, val))
return fold_build1 (NOP_EXPR, tree_type, val);
- else
+ else if (TYPE_SIZE (tree_type) == TYPE_SIZE (TREE_TYPE (val)))
return fold_build1 (VIEW_CONVERT_EXPR, tree_type, val);
+ else
+ return NULL;
}
return val;
}
@@ -976,8 +979,20 @@ ipcp_create_replace_map (tree parm_tree,
struct ipa_replace_map *replace_map;
tree const_val;
- replace_map = ggc_alloc_ipa_replace_map ();
const_val = build_const_val (lat, TREE_TYPE (parm_tree));
+ if (const_val == NULL_TREE)
+{
+ if (dump_file)
+ {
+ fprintf (dump_file, const );
+ print_generic_expr (dump_file, lat-constant, 0);
+ fprintf (dump_file, can't be converted to param );
+ print_generic_expr (dump_file, parm_tree, 0);
+ fprintf (dump_file, \n);
+ }
+ return NULL;
+}
+ replace_map = ggc_alloc_ipa_replace_map ();
if (dump_file)
{
fprintf (dump_file, replacing param );
@@ -1378,15 +1393,6 @@ ipcp_insert_stage (void)
continue;
}
- new_size += growth;
-
- /* Look if original function becomes dead after cloning. */
- for (cs = node-callers; cs != NULL; cs = cs-next_caller)
- if (cs-caller == node || ipcp_need_redirect_p (cs))
- break;
- if (!cs cgraph_will_be_removed_from_program_if_no_direct_calls (node))
- bitmap_set_bit (dead_nodes, node-uid);
-
info = IPA_NODE_REF (node);
count = ipa_get_param_count (info);
@@ -1413,11 +1419,28 @@ ipcp_insert_stage (void)
{
replace_param =
ipcp_create_replace_map (parm_tree, lat);
+ if (replace_param == NULL)
+ break;
VEC_safe_push (ipa_replace_map_p, gc, replace_trees,
replace_param);
if (args_to_skip)
bitmap_set_bit (args_to_skip, i);
}
}
+ if (i count)
+ {
+ if (dump_file)
+ fprintf (dump_file, Not versioning, some parameters couldn't be
replaced);
+ continue;
+ }
+
+ new_size += growth;
+
+ /* Look if original function becomes dead after cloning. */
+ for (cs = node-callers; cs != NULL; cs = cs-next_caller)
+ if (cs-caller == node || ipcp_need_redirect_p (cs))
+ break;
+ if (!cs cgraph_will_be_removed_from_program_if_no_direct_calls (node))
+ bitmap_set_bit (dead_nodes, node-uid);
/* Compute how many callers node has. */
node_callers = 0;
--- gcc/testsuite/gcc.c-torture/compile/pr47967.c.jj2011-03-04
14:31:29.0 +0100
+++ gcc/testsuite/gcc.c-torture/compile/pr47967.c 2011-03-04
14:31:12.0 +0100
@@ -0,0 +1,17 @@
+/* PR tree-optimization/47967 */
+
+extern void abort (void);
+static void bar ();
+
+void
+foo ()
+{
+ bar (1);
+}
+
+static void
+bar (double i)
+{
+ if (i)
+abort ();
+}
Jakub
[PATCH] Teach var-tracking about some targets setmem/movmem patterns (PR debug/47991)
Hi!
s390 uses (set (mem:BLK ...) (reg:DI ...)) pattern for setmem,
but even i?86 uses (set (mem:BLK ...) (const_int ...)).
Telling var-tracking in that case that (mem:BLK) has the (reg:DI)
resp. (const_int) value is wrong and leads to mode mismatches.
So, the following patch fixes it by returning NULL from find_use_val
in that case (cselib_lookup on BLKmode MEM always returns NULL,
but in this routine we are returning cselib_lookup result of the SET_SRC
which in this case has a different mode).
Bootstrapped/regtested on x86_64-linux and i686-linux and tested on
the provided testcase in s390x-linux cross. Ok for trunk?
2011-03-04 Jakub Jelinek ja...@redhat.com
PR debug/47991
* var-tracking.c (find_use_val): Return NULL for
cui-sets cui-store_p BLKmode MEMs.
* gcc.dg/pr47991.c: New test.
--- gcc/var-tracking.c.jj 2011-02-15 15:42:27.0 +0100
+++ gcc/var-tracking.c 2011-03-04 19:08:15.0 +0100
@@ -4784,12 +4784,19 @@ find_use_val (rtx x, enum machine_mode m
if (cui-sets)
{
/* This is called after uses are set up and before stores are
-processed bycselib, so it's safe to look up srcs, but not
+processed by cselib, so it's safe to look up srcs, but not
dsts. So we look up expressions that appear in srcs or in
dest expressions, but we search the sets array for dests of
stores. */
if (cui-store_p)
{
+ /* Some targets represent memset and memcpy patterns
+by (set (mem:BLK ...) (reg:[QHSD]I ...)) or
+(set (mem:BLK ...) (const_int ...)) or
+(set (mem:BLK ...) (mem:BLK ...)). Don't return anything
+in that case, otherwise we end up with mode mismatches. */
+ if (mode == BLKmode MEM_P (x))
+ return NULL;
for (i = 0; i cui-n_sets; i++)
if (cui-sets[i].dest == x)
return cui-sets[i].src_elt;
--- gcc/testsuite/gcc.dg/pr47991.c.jj 2011-03-04 19:23:06.0 +0100
+++ gcc/testsuite/gcc.dg/pr47991.c 2011-03-04 19:25:26.0 +0100
@@ -0,0 +1,25 @@
+/* PR debug/47991 */
+/* { dg-do compile } */
+/* { dg-options -g -Os } */
+
+typedef __SIZE_TYPE__ size_t;
+extern inline __attribute__ ((__always_inline__))
+void *
+memset (void *x, int y, size_t z)
+{
+ return __builtin___memset_chk (x, y, z, __builtin_object_size (x, 0));
+}
+
+void
+foo (unsigned char *x, unsigned char *y, unsigned char *z,
+ unsigned char *w, unsigned int v, int u, int t)
+{
+ int i;
+ for (i = 0; i t; i++)
+{
+ memset (z, x[0], v);
+ memset (w, y[0], v);
+ x += u;
+}
+ __builtin_memcpy (z, x, u);
+}
Jakub
Re: ivopts improvement
Hi,
/* Whether the loop body includes any function calls. */
bool body_includes_call;
+
+ /* Whether the loop body includes any function calls that possibly have
side
+ effects. */
+ bool body_includes_side_effect_call;
};
/* An assignment of iv candidates to uses. */
@@ -456,6 +460,20 @@
return exit;
}
+/* Returns true if single_exit (DATA-current_loop) is the only possible
exit.
+ Uses the same logic as loop_only_exit_p. */
why are you duplicating the functionality, instead of simply caching the result
of loop_only_exit_p?
+/* Tries to detect
+ NIT == (use_iv_max USE-iv-base)
+? 0
+: (use_iv_max - USE-iv-base)
+ where
+ use_iv_real_base == (USE-iv-base - USE-iv-step)
+ CAND-iv-base == base_ptr + use_iv_real_base
+ and returns the exclusive upper bound for CAND-var_after:
+ base_ptr + use_iv_max. */
+
+static tree
+get_lt_bound (struct iv_use *use, struct iv_cand *cand, tree nit)
+{
...
+ /* use_iv_real_base == use-iv-base - use-iv-step. */
+ use_iv_real_base = fold_build_plus (MINUS_EXPR, use-iv-base,
use-iv-step);
+
+ /* cand_iv_base. */
+
+ /* cand-iv-base == base_ptr + use_iv_real_base. */
...
+ /* 0. */
...
This function seriously needs better comments. All that are currently present
just
give relations between variables that can be as easily seen from the code (but
do not at all explain what the variables are supposed to mean), or make no sense
(what does the 0. comment mean?)
Otherwise the patch looks ok (but I would still like to see get_lt_bound with
proper
comments, currently I don't really understand what happens there),
Zdenek
[PATCH] Fix gcc.dg/torture/pr47968.c testcase on i?86
Hi!
This testcase fails on i686-linux, because of:
gcc.dg/torture/pr47968.c:6:7: note: The ABI for passing parameters with 16-byte
alignment has changed in GCC 4.6
gcc.dg/torture/pr47968.c:6:7: warning: SSE vector argument without SSE enabled
changes the ABI [enabled by default]
This patch fixes it by disabling warnings. Ok?
2011-03-04 Jakub Jelinek ja...@redhat.com
* gcc.dg/torture/pr47968.c: Ignore warnings.
--- gcc/testsuite/gcc.dg/torture/pr47968.c.jj 2011-03-04 19:39:16.092421074
+0100
+++ gcc/testsuite/gcc.dg/torture/pr47968.c 2011-03-04 22:02:14.980388635
+0100
@@ -1,4 +1,5 @@
/* { dg-do compile } */
+/* { dg-options -w -Wno-psabi } */
typedef __attribute__ ((vector_size (16))) float float4;
typedef __attribute__ ((vector_size (16))) double double2;
@@ -8,4 +9,3 @@ float foo (double2 d2)
float4 f4 = (float4) d2;
return *(float *) f4;
}
-
Jakub
Re: [pph] Add preprocessor validation
On 03/04/2011 05:46 PM, Lawrence Crowl wrote: Add preprocessor symbol verification to PPH. Write the used symbol table instead of a dummy PPH file. Reuse PTH code for verifying these symbols are correct. Modify verification to allow a preprocessor symbol to match the PPH file's after value as well as its before value. Stop storing the macro name redundantly within its value. Mark three tests as expected failures as a result. There are 2 unexpected failures and 2 unexpected passes to be fixed. Add three different PPH output formats, the regular object file, the pretty printed form, and the full dump form. These formats are more stubs than anything else. Make pretty printing closer to compilable code. Add new flag TDF_VISDEF to request display of visible definitions. For now, they are most particularly struct definitions. Turn off visible definitions for bases of arrays and pointers. OK. Diego.
