On Sun, Jul 15, 2007 at 09:52:02PM +0200, Richard Guenther wrote: > On 7/14/07, H.J. Lu <[EMAIL PROTECTED]> wrote: > >This patch > > > >http://gcc.gnu.org/ml/gcc-patches/2007-07/msg00165.html > > > >causes the regression: > > > >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32748 > > > >The only relevant change is > > > >Index: gcc/fortran/trans-decl.c > >=================================================================== > >--- gcc/fortran/trans-decl.c (revision 126214) > >+++ gcc/fortran/trans-decl.c (working copy) > >@@ -2276,6 +2276,7 @@ gfc_build_builtin_function_decls (void) > > (PREFIX("internal_realloc")), > > pvoid_type_node, 2, pvoid_type_node, > > gfc_index_int_type_node); > >+ DECL_IS_MALLOC (gfor_fndecl_internal_realloc) = 1; > > > > gfor_fndecl_allocate = > > gfc_build_library_function_decl (get_identifier (PREFIX("allocate")), > > > >In calls.c, there are comments: > > > > /* The return value from a malloc-like function can not alias > > anything else. */ > > > >It looks like gcc assumes a functon marked with DECL_IS_MALLOC won't > >return an address which can alias something else. But it isn't true > >for realloc. Now, the qestions are > > > >1. Can gcc make such an assumption? > > No, it can't. The returned memory may alias the original memory. > > >2. Can realloc be marked as DECL_IS_MALLOC. > > ... with DECL_IS_MALLOC the following > > int *p; > p = malloc (4); > *p = 0; > p = realloc (p, 4); > *p = 1; > > will have VOPs that do not prevent re-ordering of the two stores. > > >BTW, glibc also marks realloc with __attribute_malloc__. > > Which is wrong as well.
I opened 2 bugs: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32771 http://sourceware.org/bugzilla/show_bug.cgi?id=4792 H.J.