[Bug target/24913] New: undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting

[Bug target/24913] New: undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting

[gcc-bugzilla at gcc dot gnu dot org]

        The G4 PowerPC processor does not support the (full) GPOPT instruction
set that can be activated with -mpowerpc-gpopt. The documentation is not
explicitly clear on which (current) processors support this instruction set -
or any of the other additional/extended/optional sets like those selected with
-mpowerpc-gfxopt, -mstrings, -mmultiple, etc.

Earlier versions of gcc (until at least 4.0.0 4061) used to ignore
-mpowerpc-gpopt on the G4, judging from the assembly they produce (a simple
y=sqrt(x) statement is enough). Gcc 4.0.1 5301 has a new, undocumented
behaviour: it changes the target cpu to ppc970. The resulting code crashes on a
G4, of course. This happens even when the compiler was instructed to compile
for a G4, i.e. when invoked with -mcpu=G4 -mpowerpc-gpopt (the order is
irrelevant).

Environment:
System: Darwin Zygiella.local 7.9.0 Darwin Kernel Version 7.9.0: Wed Mar 30
20:11:17 PST 2005; root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC Power Macintosh
powerpc


        <machine, os, target, libraries (multiple lines)>
host: powerpc-apple-darwin7
build: powerpc-apple-darwin7
target: powerpc-apple-darwin7
configured with: /Volumes/Debian/gcc/gcc401build/../gcc-401-5301/configure
--prefix=/usr/local/gnu/gcc/4.0.1 --enable-languages=c,c++,objc,obj-c++,f95
--build=powerpc-apple-darwin7 --host=powerpc-apple-darwin7
--target=powerpc-apple-darwin7

How-To-Repeat:
        Invoked the compiler with -mpowerpc-gpopt on a simple source file like
the example below. On a G4, the resulting fsqrt instruction that is generated
for the sqrt expression will crash. This also happens when compiled with
-mcpu=G4 -mpowerpc-gpopt .

###########
#include <stdio.h>
#include <math.h>
#include <stdlib.h>

main( int argc, char *argv[] )
{ double x, y, z;
  long long a, b;
        if( argc>= 2 ){
                sscanf( argv[1], "%lf", &x );
                sscanf( argv[2], "%lf", &y );
        }
        else{
                x= drand48() * 10.0;
                y= drand48() * 5.0;
        }
        if( y== 0.5 ){
                z= sqrt(x);
        }
        else{
                z= pow( x, y );
        }
        printf( "pow(%g,%g)=%g\n", x, y, z );
        a= x;
        b= y;
        printf( "(long long)(%lld * %lld) = %lld\n", a, b, a*b );
        exit(0);
}
###########


------- Comment #1 from vsxo at hotmail dot com  2005-11-17 16:47 -------
Fix:
        The workaround is not to give the instruction. There are several
solutions. The documentation should be made up to date in this aspect; *also*
for -mpowerpc-gfxopt -mnew-mnemonics -mstring -mmultiple -misel). A good
additional solution would be to output a warning or error when selecting
incompatible instruction sets and target cpus. (Rationale: -mcpu=G4 -mmmx also
gives an abortive error...)
        Ideally, a warning would also be given when an option is selected that
cause the resulting code to (potentially) crash on the host CPU (this used to
be the case under Irix), (even) in the absence of a specific cpu selector.


-- 
           Summary: undocumented new CPU upgrade by -mpowerpc-gpopt
                    overrides user-selected -mcpu= setting
           Product: gcc
           Version: 4.0.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: vsxo at hotmail dot com
 GCC build triplet: powerpc-apple-darwin7
  GCC host triplet: powerpc-apple-darwin7
GCC target triplet: powerpc-apple-darwin7


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

[Bug target/24913] undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2005-11-17 16:56 -------
This is not an undocemented behavior.  First it is documented that later
options should override the earlier ones.  Second this is an expected change.
Third you should have reported this to Apple first since you are using their
compiler and their build numbers prove it.  Thrid the reason for this change
was to allow -mcpu=G4 -mno-altivec.

Fourth it is not incompatible at all as -mcpu=G4 -mpowerpc-gpopt works as
expected as -mpowerpc-gpopt adds to -mcpu=G4.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug target/24913] undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting

[vsxo at hotmail dot com]

------- Comment #3 from vsxo at hotmail dot com  2005-11-17 21:06 -------
> This is not an undocemented behavior.

   The documentation did not change since 4.0.0, yet the behaviour did. I
wonder if the previous behaviour also was not undocumented?

> First it is documented that later options should override the earlier ones.  

  Exactly. Which is why I added explicitly that the order does not make a
difference: this is in contradiction of the general behaviour. -mpowerpc-gpopt
-mcpu=G4 also generates code that crashes  on a G4.

> Second this is an expected change.

  And your second argument by authority.

> Third you should have reported this to Apple first since you are using their

  Possibly. I contacted an Apple gcc-team member off-list because of this, and
he told me to submit a bug report against the documentation. He didn't tell me
to use the radarweb. I was planning to submit the report there too.

>  Thrid the reason for this change was to allow -mcpu=G4 -mno-altivec.

  ??

> Fourth it is not incompatible at all as -mcpu=G4 -mpowerpc-gpopt works as expected as -mpowerpc-gpopt adds to -mcpu=G4.

  No, *unless* you mean by this that current FSF releases do not generate
crashing code with this combination.
It changes the specified CPU to a different one because the G4 does not have
the GPOPT.  A G5 is not a G4 with some stuff added, it is a very different
processor that happens to be backwards binary compatible. G5-specific code can
and will crash on a G4. Try it if you don't believe it with the code I
included, and I'm almost certain this will happen in FSF 4.0.1 (or even 4.0.2)
too. 
You can compare this with -mpowerpc64 . Would you maintain that -mcpu=G4
-mpowerpc64 adds 64bit support for some hypothetical G4++ cpu? The manpage
clearly states that the -mpowerpc64  is a part of the full PowerPC64
architecture. Most people will be aware that the G4 is not.

I took time to report this, after being asked to do so by someone who must have
seen this report too. I'm not pleased by the tone of your reaction, so I'm
taking the liberty to reopen the bug to be sure this counter-reaction does not
go unnoticed.


-- 

vsxo at hotmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |


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

[Bug target/24913] undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2005-11-17 21:08 -------
And this is documented already:
 If you wish to set an individual option to a particular value, you may specify
it after the -mcpu option, like `-mcpu=970 -mno-altivec'. 


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


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

[Bug target/24913] undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2005-11-17 21:10 -------
That was from:
http://gcc.gnu.org/onlinedocs/gcc/RS_002f6000-and-PowerPC-Options.html#RS_002f6000-and-PowerPC-Options

And:
http://gcc.gnu.org/onlinedocs/gcc-4.0.2/gcc/RS_002f6000-and-PowerPC-Options.html#RS_002f6000-and-PowerPC-Options

And:
http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gcc/RS_002f6000-and-PowerPC-Options.html

And:
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/RS_002f6000-and-PowerPC-Options.html

Which means before we had a bug in that the behavior did not match the
documented behavior.


-- 


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

[Bug target/24913] undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting

[vsxo at hotmail dot com]

------- Comment #6 from vsxo at hotmail dot com  2005-11-17 21:26 -------
Sure, sure. But -mcpu=970 -mno-altivec makes sense: it just causes the SIMD
unit to be unused. -mcpu=G3 -maltivec does not make sense. I don't agree that
it should be possible to override the explicitly selected architecture, WITHOUT
WARNING or error. Imagine a compiler configured for a cross-compiling
environment, as Apple's fat binaries. What do you do with -mcpu=pentium-m
-mpowerpc-gpopt ? Output code for the G5 knowing full well the user just asked
for pentium-m code? Ignore the incompatible specifier? The most sensical thing
to do in this case is to give an error and abort.

In reaction to the references: I don't see the bug. That is, I don't see how
the earlier behaviour is incompatible with the documentation you refer to
(which is given in the manpage too). To me it makes more sense to ignore an
unsupported option than to 'upgrade' the selected target cpu and generate code
that crashes. -mpowerpc64 is a bit different in this in that the manpage
clearly mentions that is belongs to ppc64: a G4 clearly doesn't. There, I can't
criticise (though a warning would still be preferrable).

And I see this:
"Specifying the -mcpu=cpu_type overrides the specification of these options. "

This suggests rather explicitly that -mpowerpc-gpopt -mcpu=G4 should undo the
selection of the GPOPT instruction set.

The documentation is vague in that the G4 nor the G5 are mentioned among the
Motorola and IBM processors listed in the description of these arguments.


-- 


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

[Bug target/24913] undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2005-11-17 21:43 -------
(In reply to comment #6)
> The documentation is vague in that the G4 nor the G5 are mentioned among the
> Motorola and IBM processors listed in the description of these arguments.

That is because G4 and G5 are marketing names from Apple and nobody else.

Think of -mcpu=XXX as a meta flag for -mtune=XXX and all the options implied
it.  And order does not matter where it comes.  


-- 


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

[Bug target/24913] undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting

[vsxo at hotmail dot com]

------- Comment #8 from vsxo at hotmail dot com  2005-11-17 21:52 -------
Of course, G4 and G5 are marketing names for *FreeScale* 74xx and IBM ppc970xx
cpus respectively. These are listed under the values that can be given to -mcpu
et al, but I can't find them in the list of cpus given under -mpowerpc-gpopt et
al.

> And order does not matter where it comes.

I give up. Are you contradicting what you just said earlier? In that case the
phrase I cited in #6 is wrong!

Gcc has so many convenience/t options that warn the programmer for doing unwise
things. Why not add a warning (or error) when requesting impossible cpu
features, or ones that are not available on the current host cpu?


-- 


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