static bool
rs6000_option_override_internal (bool global_init_p)
{
...
  if (main_target_opt)
    {
      if (main_target_opt->x_rs6000_single_float != rs6000_single_float)
        error ("target attribute or pragma changes single precision floating "
               "point");
      if (main_target_opt->x_rs6000_double_float != rs6000_double_float)
        error ("target attribute or pragma changes double precision floating "
               "point");
    }


it looks like -mcpu=... is not allowed to differ from global defaults.  Note
that LTO now passes all "Save" options in function attributes and no longer
passes along -mcpu= to the link-time transparently.

mcpu=
Target RejectNegative Joined Var(rs6000_cpu_index) Init(-1) Enum(rs6000_cpu_opt_value) Save
-mcpu=  Use features of and schedule code for given CPU

so -mcpu= is 'Save' but appearantly switches additional flags?

Hi Richard,

 You mean to say that there is no issue with LTO, the error is only due to addition flags for particular -mcpu.

I am only getting this issue when I passs -flto option with -mcpu=e6500. Without -flto there is no issue as

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

It means with particular -mcpu with -flto option switches additional flags which is resulting in this error during compilation. While those additional flags came into picture after gcc-5.1.0 release.

$ ./powerpc-windriver-linux-gcc test.c -mcpu=e6500 -flto
In function âmainâ:
lto1: warning: compilation : main_target_opt = 1
lto1: error: target attribute or pragma changes single precision floating point
lto1: error: target attribute or pragma changes double precision floating point
lto-wrapper: fatal error: ./powerpc-windriver-linux-gcc returned 1 exit status
compilation terminated.
/opt/2cross/lib/gcc/powerpc-windriver-linux/5.2.0/../../../../powerpc-windriver-linux/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status

Can you guide me further.

Thanks,
Martin

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.

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

does that work? (without LTO?)

Yes, It works without -flto.

Hi Richard,

There are the changes came after gcc-4.9.3 because of that I am getting above issue, but if I comment these 2 line in file (tree-streamer-in.c & tree-streamer-out.c) then it resolves the issue I am facing in gcc-5.2.0.

Because of these changes,  the gcc-5.2.0 fails but gcc-4.9.3 sources are working fine.
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=73527b1dbb74fb8a2fcb92627292c1c0334c8364


Index: 
===================================================================
--- a/gcc/tree-streamer-in.c	2015-03-27 12:28:59.000000000 +0530
+++ b/gcc/tree-streamer-in.c	2015-10-23 03:09:08.758332929 +0530
@@ -802,7 +802,7 @@ lto_input_ts_function_decl_tree_pointers
   /* DECL_STRUCT_FUNCTION is loaded on demand by cgraph_get_body.  */
   DECL_FUNCTION_PERSONALITY (expr) = stream_read_tree (ib, data_in);
 #ifndef ACCEL_COMPILER
-  DECL_FUNCTION_SPECIFIC_TARGET (expr) = stream_read_tree (ib, data_in);
+/*  DECL_FUNCTION_SPECIFIC_TARGET (expr) = stream_read_tree (ib, data_in);*/
 #endif
   DECL_FUNCTION_SPECIFIC_OPTIMIZATION (expr) = stream_read_tree (ib, data_in);


===================================================================
--- a/gcc/tree-streamer-out.c	2015-02-26 17:56:11.000000000 +0530
+++ b/gcc/tree-streamer-out.c	2015-10-23 03:09:13.542332646 +0530
@@ -708,7 +708,7 @@ write_ts_function_decl_tree_pointers (st
   stream_write_tree (ob, DECL_FUNCTION_PERSONALITY (expr), ref_p);
   /* Don't stream these when passing things to a different target.  */
   if (!lto_stream_offload_p)
-    stream_write_tree (ob, DECL_FUNCTION_SPECIFIC_TARGET (expr), ref_p);
+  /*  stream_write_tree (ob, DECL_FUNCTION_SPECIFIC_TARGET (expr), ref_p);*/
   stream_write_tree (ob, DECL_FUNCTION_SPECIFIC_OPTIMIZATION (expr), ref_p);
 }



Thanks,
Martin

On Fri, 30 Oct 2015, ranjan.amit8 at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68028
> 
> --- Comment #5 from martin <ranjan.amit8 at gmail dot com> ---
> Hi Richard,
> 
> There are the changes came after gcc-4.9.3 because of that I am getting above
> issue, but if I comment these 2 line in file (tree-streamer-in.c &
> tree-streamer-out.c) then it resolves the issue I am facing in gcc-5.2.0.
> 
> Because of these changes,  the gcc-5.2.0 fails but gcc-4.9.3 sources are
> working fine.
> https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=73527b1dbb74fb8a2fcb92627292c1c0334c8364
>
> 
> Index: 
> ===================================================================
> --- a/gcc/tree-streamer-in.c    2015-03-27 12:28:59.000000000 +0530
> +++ b/gcc/tree-streamer-in.c    2015-10-23 03:09:08.758332929 +0530
> @@ -802,7 +802,7 @@ lto_input_ts_function_decl_tree_pointers
>    /* DECL_STRUCT_FUNCTION is loaded on demand by cgraph_get_body.  */
>    DECL_FUNCTION_PERSONALITY (expr) = stream_read_tree (ib, data_in);
>  #ifndef ACCEL_COMPILER
> -  DECL_FUNCTION_SPECIFIC_TARGET (expr) = stream_read_tree (ib, data_in);
> +/*  DECL_FUNCTION_SPECIFIC_TARGET (expr) = stream_read_tree (ib, data_in);*/
>  #endif
>    DECL_FUNCTION_SPECIFIC_OPTIMIZATION (expr) = stream_read_tree (ib, data_in);
> 
> 
> ===================================================================
> --- a/gcc/tree-streamer-out.c   2015-02-26 17:56:11.000000000 +0530
> +++ b/gcc/tree-streamer-out.c   2015-10-23 03:09:13.542332646 +0530
> @@ -708,7 +708,7 @@ write_ts_function_decl_tree_pointers (st
>    stream_write_tree (ob, DECL_FUNCTION_PERSONALITY (expr), ref_p);
>    /* Don't stream these when passing things to a different target.  */
>    if (!lto_stream_offload_p)
> -    stream_write_tree (ob, DECL_FUNCTION_SPECIFIC_TARGET (expr), ref_p);
> +  /*  stream_write_tree (ob, DECL_FUNCTION_SPECIFIC_TARGET (expr), ref_p);*/
>    stream_write_tree (ob, DECL_FUNCTION_SPECIFIC_OPTIMIZATION (expr), ref_p);
>  }

Yes, those are used to implement the feature I was talking about.

But the issue lies somewhere in the rs6000 backend and thus needs
deeper investigation by one of its maintainers.

We have it too.

GCC 5 branch is being closed

Created attachment 43318 [details]
Proposed patch

Hi Guys,

Richard was right - there is code that sets extra flags based upon the setting of -mcpu.  In fact it is just before the code he mentioned:

 /* For the E500 family of cores, reset the single/double FP flags to let us
     check that they remain constant across attributes or pragmas.  */

  switch (rs6000_cpu)
    {
    case PROCESSOR_PPC8540:
    case PROCESSOR_PPC8548:
    case PROCESSOR_PPCE500MC:
    case PROCESSOR_PPCE500MC64:
    case PROCESSOR_PPCE5500:
    case PROCESSOR_PPCE6500:
      rs6000_single_float = 0;
      rs6000_double_float = 0;
      break;

    default:
      break;
    }

This has lead me to propose the attached patch.  Basically what it does is to
tell the rs6000 backend that when it is operating in LTO mode, it should trust
the function attributes and not the command line. 

My assumption here is that if there are any discrepancies between real 
function attributes (ie not ones generated for LTO) and the command line,
then these will have been detected and reported during the original 
compilation.

What do people think ?  Is the patch OK ?

Cheers
  Nick

(In reply to Nick Clifton from comment #9)
> Created attachment 43318 [details]
> Proposed patch
> 
> Hi Guys,
> 
> Richard was right - there is code that sets extra flags based upon the
> setting of -mcpu.  In fact it is just before the code he mentioned:
> 
>  /* For the E500 family of cores, reset the single/double FP flags to let us
>      check that they remain constant across attributes or pragmas.  */
> 
>   switch (rs6000_cpu)
>     {
>     case PROCESSOR_PPC8540:
>     case PROCESSOR_PPC8548:
>     case PROCESSOR_PPCE500MC:
>     case PROCESSOR_PPCE500MC64:
>     case PROCESSOR_PPCE5500:
>     case PROCESSOR_PPCE6500:
>       rs6000_single_float = 0;
>       rs6000_double_float = 0;
>       break;
> 
>     default:
>       break;
>     }
> 
> This has lead me to propose the attached patch.  Basically what it does is to
> tell the rs6000 backend that when it is operating in LTO mode, it should
> trust
> the function attributes and not the command line. 
> 
> My assumption here is that if there are any discrepancies between real 
> function attributes (ie not ones generated for LTO) and the command line,
> then these will have been detected and reported during the original 
> compilation.
> 
> What do people think ?  Is the patch OK ?

If the backend doesn't support mixing of -msingle-float/-mno-single-float within
a compilation unit then this will only work if the user didn't mix TUs
with conflicting setting at link-time.  So the following will not be diagnosed
but will instead have conflicting IL accepted silently with your
patch (with unknown effect):

> gcc -c t1.c -flto -msingle-float
> gcc -c t2.c -flto -mdouble-float
> gcc t1.o t2.o -flto

so I think it's better to have rs6000_single_float/rs6000_double_float
initialized to for example -1 and allow changing that a _single_ time,
verifying all following uses will match.

But I don't see why mixing shouldn't be possible?  Maybe the target wants
to instead limit inlining of functions with differing settings instead?
If the caller/callee uses FP? (see i386.c:ix86_can_inline_p use of
cgraph_node::get (callee))->fp_expressions to guard similar things).

Hi Richard,

> If the backend doesn't support mixing of -msingle-float/-mno-single-float
> within a compilation unit then this will only work if the user didn't mix TUs
> with conflicting setting at link-time.  So the following will not be diagnosed
> but will instead have conflicting IL accepted silently with your
> patch (with unknown effect):
> 
>> gcc -c t1.c -flto -msingle-float
>> gcc -c t2.c -flto -mdouble-float
>> gcc t1.o t2.o -flto

But even without the patch, if the user does the above, but leaves out
the final -flto then the problem will still not be diagnosed:

 gcc -c t1.c -flto -msingle-float
 gcc -c t2.c -flto -mdouble-float
 gcc t1.o t2.o 

That is, unless the linker detects and reports this problem.  Which it does.
There are tags recorded in the build notes which specify the precision of
floating point used, and the linker will complain if these do not match.

So, since the linker will report conflicts there is no need for the LTO 
compiler to do so.   Especially when, as this bug report shows, it gets
the warning wrong under some circumstances.

So I still think that my patch is viable.  Comments ?

Cheers
  Nick

On Mon, 5 Feb 2018, nickc at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68028
> 
> --- Comment #11 from Nick Clifton <nickc at redhat dot com> ---
> Hi Richard,
> 
> > If the backend doesn't support mixing of -msingle-float/-mno-single-float
> > within a compilation unit then this will only work if the user didn't mix TUs
> > with conflicting setting at link-time.  So the following will not be diagnosed
> > but will instead have conflicting IL accepted silently with your
> > patch (with unknown effect):
> > 
> >> gcc -c t1.c -flto -msingle-float
> >> gcc -c t2.c -flto -mdouble-float
> >> gcc t1.o t2.o -flto
> 
> But even without the patch, if the user does the above, but leaves out
> the final -flto then the problem will still not be diagnosed:
> 
>  gcc -c t1.c -flto -msingle-float
>  gcc -c t2.c -flto -mdouble-float
>  gcc t1.o t2.o 
> 
> That is, unless the linker detects and reports this problem.  Which it does.
> There are tags recorded in the build notes which specify the precision of
> floating point used, and the linker will complain if these do not match.
> 
> So, since the linker will report conflicts there is no need for the LTO 
> compiler to do so.   Especially when, as this bug report shows, it gets
> the warning wrong under some circumstances.
> 
> So I still think that my patch is viable.  Comments ?

I'll leave that to the target maintainers to decide -- just wanted to
note that the flags can get mixed by the user via different TUs.  Note
that with your patch what you likely get then is simply forcing
a random -m{single,double}-float on the LTO TU.  You might be lucky
enough for WPA to order ltrans units in just a way that the linker
will not complain in the end but the flags are not in effect in a way
the user intended.

So I think the UNKNOWN initialized variant would be safer, overriding
exactly once and only diagnosing mismatches.

GCC 6 branch is being closed

The GCC 7 branch is being closed, re-targeting to GCC 8.4.

GCC 8.4.0 has been released, adjusting target milestone.

I just tried this on gcc trunk, 10, 9, and even 8 and could not get it to fail.  I tried on a powerpc 8 BE and a different powerpc 8 LE machine.

seurer@genoa:~/tests/gcc$ ~/gcc/git/install/gcc-test/bin/gcc -flto test.c -mcpu=e6500
seurer@genoa:~/tests/gcc$ ~/gcc/git/install/gcc-10/bin/gcc -flto test.c -mcpu=e6500
seurer@genoa:~/tests/gcc$ ~/gcc/git/install/gcc-9/bin/gcc -flto test.c -mcpu=e6500
seurer@genoa:~/tests/gcc$ ~/gcc/git/install/gcc-8/bin/gcc -flto test.c -mcpu=e6500
seurer@genoa:~/tests/gcc$ cat test.c
	#include<stdio.h>
	int main()
	{
		printf("Good\n");
		return 0;
	}

GCC 8 branch is being closed.

GCC 9.4 is being released, retargeting bugs to GCC 9.5.

GCC 9 branch is being closed

GCC 10.4 is being released, retargeting bugs to GCC 10.5.

GCC 10 branch is being closed.