------- 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
