On powerpc-apple-darwin9 at revision 164592, most (all?) the tests with -flto of -fwhopr fail with lto1: fatal error: target specific builtin not available (see http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg02251.html ). Last known working revision is r164531 (see http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg02113.html ).
This pr seems to be due to revision 164591: Author: rguenth Date: Fri Sep 24 13:21:30 2010 UTC (2 days, 19 hours ago) Changed paths: 5 Log Message: 2010-09-24 Richard Guenther <rguenther@suse.de> * c-decl.c (pop_scope): Always set file-scope DECL_CONTEXT. Make sure to not call set_type_context with error_mark_node. * langhooks.c (lhd_set_decl_assembler_name): Use DECL_FILE_SCOPE_P. * gcc.dg/lto/20091006-2_0.c: Prune warnings. Changed paths: Path Details trunk/gcc/ChangeLog modified , text changed trunk/gcc/c-decl.c modified , text changed trunk/gcc/langhooks.c modified , text changed trunk/gcc/testsuite/ChangeLog modified , text changed trunk/gcc/testsuite/gcc.dg/lto/20091006-2_0.c modified , text changed If I revert it at revision 164604, the failures are gone.
The same issue was found on arm-none-eabi: http://gcc.gnu.org/ml/gcc-patches/2010-09/msg02004.html
On powerpc64-unknown-linux-gnu, this problem seems to only affect the gcc.dg/vmx/* tests (see http://gcc.gnu.org/ml/gcc-testresults/2010-09/msg02397.html ).
>lto1: fatal error: target specific builtin not available PowerPC has the hook implemented, why is it failing for powerpc-darwin then?
rs6000_builtin_decl should be working correctly.
(In reply to comment #5) > rs6000_builtin_decl should be working correctly. Indeed, I suspect it is because we patch the builtin names to append $LDBL128 for the case that we have 128bit long doubles. However, I've not had a chance to investigate why that patching process does not result in a correctly emitted builtin (or maybe the target needs to get to opportunity to do so in lto).
(In reply to comment #6) > (In reply to comment #5) > > rs6000_builtin_decl should be working correctly. > > Indeed, > I suspect it is because we patch the builtin names to append $LDBL128 for the > case that we have 128bit long doubles. However, I've not had a chance to > investigate why that patching process does not result in a correctly emitted > builtin (or maybe the target needs to get to opportunity to do so in lto). You might also look at the definition of TARGET_OS_CPP_BUILTINS() in gcc/config/rs6000/darwin.h. The arm-none-eabi target which is also regressed has that redefined as well.
On Wed, 29 Sep 2010, pinskia at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45790 > > Andrew Pinski <pinskia at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Component|lto |target > Host|powerpc-apple-darwin9 | > Build|powerpc-apple-darwin9 | > > --- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> 2010-09-29 17:08:53 UTC --- > >lto1: fatal error: target specific builtin not available > > PowerPC has the hook implemented, why is it failing for powerpc-darwin then? Because else if (fclass == BUILT_IN_MD) { result = targetm.builtin_decl (fcode, true); if (!result || result == error_mark_node) fatal_error ("target specific builtin not available"); appearantly the ppc backends lazy construction doesn't work? Or target specific flags are not properly set (or recorded and re-instantiated at link time). Sth to investigate.
This pr has vanished between revisions 165163 and 165193 (see http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00634.html and http://gcc.gnu.org/ml/gcc-testresults/2010-10/msg00646.html ). Revision 165191 seems to be the best candidate.
On IRC Richard Guenther told me that he understand why r165191 fixed this pr. Closing as fixed.