| Summary: | undocumented new CPU upgrade by -mpowerpc-gpopt overrides user-selected -mcpu= setting | ||
|---|---|---|---|
| Product: | gcc | Reporter: | vsxo <vsxo> |
| Component: | target | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | gcc-bugs |
| Priority: | P3 | ||
| Version: | 4.0.1 | ||
| Target Milestone: | --- | ||
| Host: | powerpc-apple-darwin7 | Target: | powerpc-apple-darwin7 |
| Build: | powerpc-apple-darwin7 | Known to work: | |
| Known to fail: | Last reconfirmed: | ||
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. 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. > 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. 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'. 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. 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. (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. 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?
|
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); } ###########