Hi Sandra,
On Mon, 26 Jan 2015, Sandra Loosemore wrote:
OK, here is a patch that attempts to implement that convention. I'd
appreciate review from a target maintainer to check that I've correctly
disambiguated places where "i386" was referring to both 32- and 64-bit
variants vs 32-bit only. I'
On 01/27/2015 10:17 AM, Uros Bizjak wrote:
-@node i386 and x86-64 Options
-@subsection Intel 386 and AMD x86-64 Options
+@node x86 Options
+@subsection x86 Options
@cindex i386 Options
-@cindex x86-64 Options
+@cindex x86 Options
+@cindex IA-32 Options
@cindex Intel 386 Options
@cindex AMD
On Tue, Jan 27, 2015 at 2:56 AM, Sandra Loosemore
wrote:
> On 01/20/2015 12:02 PM, H.J. Lu wrote:
>>
>> On Tue, Jan 20, 2015 at 10:51 AM, Eric Botcazou
>> wrote:
Ping? Any thoughts?
>>>
>>>
>>> x86 for the family and x86-32/x86-64 for the 2 architectures?
>>>
>>
>> Works for me.
>
>
>
On 01/20/2015 12:02 PM, H.J. Lu wrote:
On Tue, Jan 20, 2015 at 10:51 AM, Eric Botcazou wrote:
Ping? Any thoughts?
x86 for the family and x86-32/x86-64 for the 2 architectures?
Works for me.
[redirecting from gcc@ to gcc-patches@]
OK, here is a patch that attempts to implement that conv
I've noticed that the GCC user documentation is quite inconsistent about
the name(s) it uses for i386/x86-64/etc targets. invoke.texi has a
section for "i386 and x86-64 Options", but in other places the manual
uses x86, X86, i?86, i[34567]86, x86_64 (underscore instead of a dash), etc.
I'd be
