* Blair Sadewitz:
> There is an [undocumented] 'x86-64' architecture type in gcc 4.1 which
> _apparently_ generates instructions common to AMD64 and EMT64.  I'm
> looking into this further to make sure that this is indeed the case.
> If it is, then it is my position that:
>
> -- we should patch the gcc(1) manual page to reflect this

If it's undocumented (And it's probably undocumented for a good reason, 
see below), I don't think it should be *our* job to document it; it's not
our code, we don't know what's going to happen with it, and we're not
in the position to make any promises. In fact, we don't even know what
to document it with; we don't even know what the flag *does*.

> -- NetBSD/amd64 builds should use this by default.

Does it? Since it's not documented, we're completely in the dark what it
is going to do. If you extrapolate what it would be doing, judging by
other -march= usage, you might conclude that it enables usage of
"x86-64-specific instructions". However, with "x86-64" being the base
archtecture for *ANYTHING* that is capable of running amd64, it is my belief
that this would be a no-op. It's like doing "-march=i386" on an i386. The
features you're "unlocking" by using -march=x86-64 are exactly those that
are common to the platform. This is probably the reason it's undocumented
to begin with. It makes sense for the i386-port, but it's probably stale
code in the x86-64 port of gcc. 

In fact, for all we know, this triggers all kind of undocumented features
and (possibly undesired) behaviour, since it's an undocumented option and
all, including crashing horribly and generating broken code.

-- 
Martijn van Buul - pino@dohd.org