[Bug target/68028] Compilation error "lto1: error: target attribute or pragma changes single precision floating point", with "-flto" on different variant of powerpc like -mcpu=e6500, 8540, 8548, e500mc, e500mc64, e5500. With gcc-5.2.0 while with 4.9.3 it is working fine.

rguenth at gcc dot gnu.org gcc-bugzilla@gcc.gnu.org
Wed Oct 21 14:28:00 GMT 2015


https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68028

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
I was saying that LTO now makes it appear like it uses target attributes to
change this kind of property and this is because the rs6000.opt file tells
it that it can do this.  But then when it does things fail.

I think the code still passes on -mcpu=e6500 to the link stage thus you
get

int __attribute__((target("cpu=e6500"))) main()
{
}

compiled by

$ ./powerpc-pc-linux-gcc test.c -mcpu=e6500

does that work? (without LTO?)


Note I have in my local tree

Index: gcc/lto-opts.c
===================================================================
--- gcc/lto-opts.c      (revision 229119)
+++ gcc/lto-opts.c      (working copy)
@@ -201,6 +201,12 @@ lto_write_options (void)
          && lto_stream_offload_p)
        continue;

+      /* Do not store target-specific options if we target a
+         SWITCHABLE_TARGET target.  */
+      if ((cl_options[option->opt_index].flags & CL_TARGET)
+         && SWITCHABLE_TARGET)
+       continue;
+
       /* Drop options created from the gcc driver that will be rejected
         when passed on to the driver again.  */
       if (cl_options[option->opt_index].cl_reject_driver)

which would stop us from passing the target options seen at compile-time
as the "default global state" to the link command.



More information about the Gcc-bugs mailing list