------- Comment #2 from jh at suse dot cz 2007-09-12 12:01 -------
Subject: Re: [4.3 Regression] Revision 128239 causes libgomp failure
Hi,
I´ve just tested ia64-linux and x86_64-linux on our testers and both are
clean WRT libgomp:
=== libgomp Summary ===
# of expected passes 496
it might be some sort of race condition (I sometimes see libgomp
failures appear and go such as:
libgomp.fortran/omp_parse3.f90 -O0 execution test
One obvious difference is that we now consider functions produced by OMP
lowering inlinable. This can be avoided by:
Index: omp-low.c
===================================================================
*** omp-low.c (revision 128412)
--- omp-low.c (working copy)
*************** expand_omp_parallel (struct omp_region *
*** 2589,2594 ****
--- 2589,2595 ----
/* Inform the callgraph about the new function. */
DECL_STRUCT_FUNCTION (child_fn)->curr_properties
= cfun->curr_properties;
+ DECL_UNINLINABLE (child_fn) = true;
cgraph_add_new_function (child_fn, true);
/* Fix the callgraph edges for child_cfun. Those for cfun will be
I am not sure if the functions was uninlinable by decision or just
because someone forgot to play with DECL_INLINE, but can you test this
if it makes any difference?
I can not think of any other difference this patch sould cause
especially with -finline-functions.
Jakub, is libgomp safe wrt inlining?
Honza
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33389
