[Bug tree-optimization/33383] [4.3 Regression] Revision 128092 miscompiles 400.perlbench

["jh at suse dot cz" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #14 from jh at suse dot cz  2007-10-15 11:39 -------
Subject: Re:  [4.3 Regression]  Revision 128092 miscompiles 400.perlbench

> 
> when sv.c is compiled with -O2 -fstrict-aliasing, then the
> *(IV**)xiv = PL_xiv_root; write isn't considered aliased with the
> iv = ((XPVIV*) (sv)->sv_any)->xiv_iv;, because the former accesses the object

Duh, thanks and congratulations for finding this!
> 
> It seems perl is aware of this, but doesn't care to fix it - Configure has
> instead:

It also might be that perl developers figured out by experimentation
that -fno-strict-aliasing helps, we probably could try to let them know.
>         case "$gccversion" in
>         1*) ;;
>         2.[0-8]*) ;;
>         ?*)     echo " "
>                 echo "Checking if your compiler accepts -fno-strict-aliasing" 2
> >&1
>                 echo 'int main(void) { return 0; }' > gcctest.c
>                 if $cc -O2 -fno-strict-aliasing -o gcctest gcctest.c; then
>                         echo "Yes, it does." 2>&1
>                         case "$ccflags" in
>                         *strict-aliasing*)
>                                 echo "Leaving current flags $ccflags alone." 2>
> &1
>                                 ;;
>                         *) dflt="$dflt -fno-strict-aliasing" ;;
>                         esac
>                 else
>                         echo "Nope, it doesn't, but that's ok." 2>&1
>                 fi
>                 ;;
>         esac
> 
> Not sure what is the best way forward with CPU2006 and GCC though (and what are
> other compilers doing to pass 400.perlbench).  Is it acceptable to add
> -fno-strict-aliasing just for this test?

This should not be that dificult to fix. Ideally we can convince SPEC to
produce official patch as they did with similar problems with CPU2000?

Honza


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33383