Why isn't ``-milp32'' accepted?

Why isn't ``-milp32'' accepted?

[Bruce Korb]

Hi,

The command:

> $ gcc -v --help | more

yields (in part):

>  -milp32|-milp64|-mlp64|-mp64  select data model (default -mlp64)

Yet:

> $ gcc -mlp64 -o cfg cfg.c   
> cc1: error: invalid option `lp64'

Oops!!

Re: Why isn't ``-milp32'' accepted?

[Zack Weinberg]

Bruce Korb <bkorb@veritas.com> writes:

> Hi,
>
> The command:
>
>> $ gcc -v --help | more
>
> yields (in part):
>
>>  -milp32|-milp64|-mlp64|-mp64  select data model (default -mlp64)
>
> Yet:
>
>> $ gcc -mlp64 -o cfg cfg.c   
>> cc1: error: invalid option `lp64'
>
> Oops!!

Which target?

zw

Re: Why isn't ``-milp32'' accepted?

[Bruce Korb]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

Zack Weinberg wrote:
> > yields (in part):
> >
> >>  -milp32|-milp64|-mlp64|-mp64  select data model (default -mlp64)
> >
> > Yet:
> >
> >> $ gcc -mlp64 -o cfg cfg.c
> >> cc1: error: invalid option `lp64'
> >
> > Oops!!
> 
> Which target?

> $ uname -a
> Linux blackbird 2.6.5-7.97-default #1 SMP Fri Jul 2 14:21:59 UTC 2004 \
>   ia64 ia64 ia64 GNU/Linux
> 
> $ ksh config/config.guess
> ia64-unknown-linux-gnu
> 
> $ gcc --version
> gcc (GCC) 3.3.3 (SuSE Linux)
> Copyright (C) 2003 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Anything else?  :-)

Cheers - Bruce

[-- Attachment #2: gcc.specs --]
[-- Type: text/plain, Size: 3069 bytes --]

*asm:
-x %{mconstant-gp} %{mauto-pic} %(asm_extra)

*asm_debug:
%{g*:--gdwarf2}

*asm_final:
%|

*asm_options:
%a %Y %{c:%W{o*}%{!o*:-o %w%b%O}}%{!c:-o %d%w%u%O}

*invoke_as:
%{!S:-o %{|!pipe:%g.s} |
 as %(asm_options) %{!pipe:%g.s} %A }

*cpp:


*cpp_options:
%(cpp_unique_options) %1 %{m*} %{std*} %{ansi} %{W*&pedantic*} %{w} %{f*} %{O*} %{undef}

*cpp_debug_options:
%{d*}

*cpp_unique_options:
%{C:%{!E:%eGNU C does not support -C without using -E}} %{CC:%{!E:%eGNU C does not support -CC without using -E}} %{!Q:-quiet} %{nostdinc*} %{C} %{CC} %{v} %{I*} %{P} %I %{MD:-MD %{!o:%b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %{MP} %{MQ*} %{MT*} %{!E:%{!M:%{!MM:%{MD|MMD:%{o*:-MQ %*}}}}} %{!no-gcc:-D__GNUC__=%v1 -D__GNUC_MINOR__=%v2 -D__GNUC_PATCHLEVEL__=%v3} %{!undef:%{!ansi:%{!std=*:%p}%{std=gnu*:%p}} %P} %{trigraphs} %{remap} %{g3:-dD} %{H} %C %{D*&U*&A*} %{i*} %Z %i %{E|M|MM:%W{o*}}

*trad_capable_cpp:
cc1 -E %{traditional|ftraditional|traditional-cpp:-traditional-cpp}

*cc1:
%{profile:-p} %{G*}

*cc1_options:
%{pg:%{fomit-frame-pointer:%e-pg and -fomit-frame-pointer are incompatible}} %1 %{!Q:-quiet} -dumpbase %B %{d*} %{m*} %{a*} -auxbase%{c|S:%{o*:-strip %*}%{!o*: %b}}%{!c:%{!S: %b}} %{g*} %{O*} %{W*&pedantic*} %{w} %{std*} %{ansi} %{v:-version} %{pg:-p} %{p} %{f*} %{undef} %{Qn:-fno-ident} %{--help:--help} %{--target-help:--target-help} %{!fsyntax-only:%{S:%W{o*}%{!o*:-o %b.s}}} %{fsyntax-only:-o %j} %{-param*}

*cc1plus:


*link_gcc_c_sequence:
%{static:--start-group} %G %L %{static:--end-group}%{!static:%G}

*endfile:
%{ffast-math|funsafe-math-optimizations:crtfastmath.o%s}    %{!shared:crtend.o%s} %{shared:crtendS.o%s} crtn.o%s

*link:
  %{shared:-shared}   %{!shared:     %{!static:       %{rdynamic:-export-dynamic}       %{!dynamic-linker:-dynamic-linker /lib/ld-linux-ia64.so.2}}       %{static:-static}}

*lib:
%{pthread:-lpthread}    %{shared:-lc}    %{!shared:%{mieee-fp:-lieee} %{profile:-lc_p}%{!profile:-lc}}

*libgcc:
%{static|static-libgcc:-lgcc -lgcc_eh}%{!static:%{!static-libgcc:%{!shared:%{!shared-libgcc:-lgcc -lgcc_eh}%{shared-libgcc:-lgcc_s%M -lgcc}}%{shared:%{shared-libgcc:-lgcc_s%M}%{!shared-libgcc:-lgcc}}}}

*startfile:
%{!shared:      %{pg:gcrt1.o%s} %{!pg:%{p:gcrt1.o%s} 		       %{!p:%{profile:gcrt1.o%s} 			 %{!profile:crt1.o%s}}}}    crti.o%s %{!shared:crtbegin.o%s} %{shared:crtbeginS.o%s}

*switches_need_spaces:


*predefines:


*cross_compile:
0

*version:
3.3.3

*multilib:
. ;

*multilib_defaults:


*multilib_extra:


*multilib_matches:


*multilib_exclusions:


*multilib_options:


*linker:
collect2

*link_libgcc:
%D

*md_exec_prefix:


*md_startfile_prefix:


*md_startfile_prefix_1:


*startfile_prefix_spec:


*asm_extra:


*link_command:
%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:    %(linker) %l %X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n} %{r} %{s} %{t}    %{u*} %{x} %{z} %{Z} %{!A:%{!nostdlib:%{!nostartfiles:%S}}}    %{static:} %{L*} %(link_libgcc) %o %{!nostdlib:%{!nodefaultlibs:%(link_gcc_c_sequence)}}    %{!A:%{!nostdlib:%{!nostartfiles:%E}}} %{T*} }}}}}}

Re: Why isn't ``-milp32'' accepted?

[Zack Weinberg]

Bruce Korb <bkorb@veritas.com> writes:

> Zack Weinberg wrote:
>> > yields (in part):
>> >
>> >>  -milp32|-milp64|-mlp64|-mp64  select data model (default -mlp64)
>> >
>> > Yet:
>> >
>> >> $ gcc -mlp64 -o cfg cfg.c
>> >> cc1: error: invalid option `lp64'
>> >
>> > Oops!!
>> 
>> Which target?
>
>> $ uname -a
>> Linux blackbird 2.6.5-7.97-default #1 SMP Fri Jul 2 14:21:59 UTC 2004 \
>>   ia64 ia64 ia64 GNU/Linux
>> 
>> $ ksh config/config.guess ia64-unknown-linux-gnu

Thanks.  I don't have time to fix this bug, or access to the relevant
system, but now at least someone has a chance.

zw

Re: Why isn't ``-milp32'' accepted on ia64-linux?

[Andrew Pinski]

On Dec 14, 2004, at 3:32 PM, Zack Weinberg wrote:

> Bruce Korb <bkorb@veritas.com> writes:
>
> Thanks.  I don't have time to fix this bug, or access to the relevant
> system, but now at least someone has a chance.

I don't think this effects 3.4.0 or 4.0.0 at all.

Thanks,
Andrew Pinski

Re: Why isn't ``-milp32'' accepted on ia64-linux?

[Andrew Pinski]

On Dec 14, 2004, at 3:36 PM, Andrew Pinski wrote:

>
> On Dec 14, 2004, at 3:32 PM, Zack Weinberg wrote:
>
>> Bruce Korb <bkorb@veritas.com> writes:
>>
>> Thanks.  I don't have time to fix this bug, or access to the relevant
>> system, but now at least someone has a chance.
>
> I don't think this effects 3.4.0 or 4.0.0 at all.

What I mean is that -milp32 is not referenced any more in the --help
output.

-- Pinski 

Re: Why isn't ``-milp32'' accepted on ia64-linux?

[Bruce Korb]

Andrew Pinski wrote:
> 
> On Dec 14, 2004, at 3:32 PM, Zack Weinberg wrote:
> 
> > Bruce Korb <bkorb@veritas.com> writes:
> >
> > Thanks.  I don't have time to fix this bug, or access to the relevant
> > system, but now at least someone has a chance.
> 
> I don't think this effects 3.4.0 or 4.0.0 at all.

Hi Andrew,

Obviously, at some point it was possible for the "help" to emit option
information that was not really accepted by the option processing logic.
That ought to be completely impossible, regardless of the specific platform.
Do you know of something that has changed between 3.3.3 and 3.4 that
would make such a thing no longer possible?  Thanks - Bruce

Re: Why isn't ``-milp32'' accepted on ia64-linux?

[Andrew Pinski]

On Dec 14, 2004, at 3:41 PM, Bruce Korb wrote:

> Andrew Pinski wrote:
>>
>> On Dec 14, 2004, at 3:32 PM, Zack Weinberg wrote:
>>
>>> Bruce Korb <bkorb@veritas.com> writes:
>>>
>>> Thanks.  I don't have time to fix this bug, or access to the relevant
>>> system, but now at least someone has a chance.
>>
>> I don't think this effects 3.4.0 or 4.0.0 at all.
>
> Hi Andrew,
>
> Obviously, at some point it was possible for the "help" to emit option
> information that was not really accepted by the option processing 
> logic.
> That ought to be completely impossible, regardless of the specific 
> platform.
> Do you know of something that has changed between 3.3.3 and 3.4 that
> would make such a thing no longer possible?  Thanks - Bruce

Are you sure that this is not the assembler or linker which is
outputting this message:
 >  -milp32|-milp64|-mlp64|-mp64  select data model (default -mlp64)

Because I don't see anything in gcc which could even remotely output
something like this. aka we always out put options with different names
on different lines.

Thanks,
Andrew Pinski

Re: Why isn't ``-milp32'' accepted on ia64-linux?

[Bruce Korb]

Andrew Pinski wrote:
> 
> On Dec 14, 2004, at 3:36 PM, Andrew Pinski wrote:
> 
> >
> > On Dec 14, 2004, at 3:32 PM, Zack Weinberg wrote:
> >
> >> Bruce Korb <bkorb@veritas.com> writes:
> >>
> >> Thanks.  I don't have time to fix this bug, or access to the relevant
> >> system, but now at least someone has a chance.
> >
> > I don't think this effects 3.4.0 or 4.0.0 at all.
> 
> What I mean is that -milp32 is not referenced any more in the --help
> output.

Hi Andrew,

That would be Truely Awful.  How does one specify the model?
Even if ``-milp32'' were the default, it ought to be supported
simply for completeness.  Unless there is a "new" way that is
not documented with ``-v --help''.  (I would hope not!)

Thanks - Bruce

Re: Why isn't ``-milp32'' accepted on ia64-linux?

[Andrew Pinski]

On Dec 14, 2004, at 3:46 PM, Bruce Korb wrote:

> Andrew Pinski wrote:
> Hi Andrew,
>
> That would be Truely Awful.  How does one specify the model?
> Even if ``-milp32'' were the default, it ought to be supported
> simply for completeness.  Unless there is a "new" way that is
> not documented with ``-v --help''.  (I would hope not!)

Actually for linux there was no way to specify the model for linux.


-- Pinski

Re: Why isn't ``-milp32'' accepted on ia64-linux?

[Bruce Korb]

Andrew Pinski wrote:

> Are you sure that this is not the assembler or linker which is
> outputting this message:
>  >  -milp32|-milp64|-mlp64|-mp64  select data model (default -mlp64)
> 
> Because I don't see anything in gcc which could

"sure" as in "certain"?  No.  It appeared in a "section" of the output
that was titled "IA-64 options:".  Paging back up the output gets me
to an invocation that leads me now to suspect it was the assembler:

> Usage: /usr/lib/gcc-lib/ia64-suse-linux/3.3.3/../../../../ia64-suse-linux/bin/as
>  [option...] [asmfile...]
> Options:
> .....

It wasn't obvious that the section break did not take me back to gcc help.
Now I see that that must be the case and '-milp32' is really spelled '-Wa,-milp32',
except that:

> Assembler messages:
> FATAL: can't create /home/bkorb/tmp/cc2CaGr1.o: Invalid bfd target

but at least the option is accepted.....

Thank you.  :)  - Bruce

Re: Why isn't ``-milp32'' accepted on ia64-linux?

[Zack Weinberg]

Andrew Pinski <pinskia@physics.uc.edu> writes:

> On Dec 14, 2004, at 3:46 PM, Bruce Korb wrote:
>
>> Andrew Pinski wrote:
>> Hi Andrew,
>>
>> That would be Truely Awful.  How does one specify the model?
>> Even if ``-milp32'' were the default, it ought to be supported
>> simply for completeness.  Unless there is a "new" way that is
>> not documented with ``-v --help''.  (I would hope not!)
>
> Actually for linux there was no way to specify the model for linux.

To be marginally clearer, ia64-linux does not support ILP32 mode at
all; it is (as far as I know) purely an HPUX-ism.

zw

Re: Why isn't ``-milp32'' accepted on ia64-linux?

[Bruce Korb]

Zack Weinberg wrote:

> > Actually for linux there was no way to specify the model for linux.
> 
> To be marginally clearer, ia64-linux does not support ILP32 mode at
> all; it is (as far as I know) purely an HPUX-ism.

And AIX and Solaris and even x86-linux, for that matter (except that
x86-linux doesn't support LP64).  I haven't played much with Sol 10
yet, but I am certain that it supports 32 bit user environments
even though the kernel is 64 bit only.  Thanks! - Bruce

Re: mem model defines for various platforms

[Bruce Korb]

Bruce Korb wrote:
> 
> Zack Weinberg wrote:
> 
> > > Actually for linux there was no way to specify the model for linux.
> >
> > To be marginally clearer, ia64-linux does not support ILP32 mode at
> > all; it is (as far as I know) purely an HPUX-ism.
> 
> And AIX and Solaris and even x86-linux, for that matter (except that
> x86-linux doesn't support LP64).  I haven't played much with Sol 10
> yet, but I am certain that it supports 32 bit user environments
> even though the kernel is 64 bit only.  Thanks! - Bruce

In fact, for kicks, using native compilers, I checked the following:

emit_def_check()
{
  cat >&4 <<- _EOF_
	#ifdef _${1}
	  fputs( "/* DEFINED:  _${1}   */\n", stdout );
	#endif
	#ifdef __${1}
	  fputs( "/* DEFINED: __${1}   */\n", stdout );
	#endif
	#ifdef __${1}__
	  fputs( "/* DEFINED: __${1}__ */\n", stdout );
	#endif
	_EOF_
}

for f in ILP32 LP64 I32LPx 64BIT 32BIT IxLP64
do
  emit_def_check $f
done

================================
 *  Sizes and offsets on SunOS sun4u platform
 *  using CC=/net/megami/opt/apps/forte62/SUNWspro/bin/cc
 */
.....
/* DEFINED:  _ILP32   */

w/ -xarch=v9 -xregs=no%appl,no%float:

/* DEFINED:  _LP64   */
/* DEFINED:  _I32LPx   */
================================
 *  Sizes and offsets on HP-UX 9000/800 platform
 *  using CC=/usr/bin/cc
 */
.......
/* DEFINED:  _ILP32   */

w/ +DA2.0W +M2 : */
/* DEFINED:  _LP64   */
/* DEFINED: __LP64__ */
================================
 *  Sizes and offsets on HP-UX ia64 platform
 *  using CC=/usr/bin/cc
/* DEFINED:  _ILP32   */

#else /* __LP64__ is defined w/ +DD64: */
/* DEFINED:  _LP64   */
/* DEFINED: __LP64__ */
================================
 *  Sizes and offsets on AIX 0000D99F4C00 platform
 *  using CC=/usr/bin/cc
/* DEFINED:  _ILP32   */

w/ -q64:
<<<fails -- I don't have a 64 bit user environment>>>>

================================
 *  Sizes and offsets on Linux i686 platform
 *  using CC=/usr/bin/cc
<<<NONE OF THEM ARE DEFINED!!>>>

================================
 *  Sizes and offsets on Linux ia64 SLES9 platform
 *  using CC=/usr/bin/cc
/* DEFINED:  _LP64   */
/* DEFINED: __LP64__ */

Re: mem model defines for various platforms

[Kai Henningsen]

bkorb@veritas.com (Bruce Korb)  wrote on 14.12.04 in <41BF5EC3.EBA42370@veritas.com>:

> Bruce Korb wrote:
> >
> > Zack Weinberg wrote:
> >
> > > > Actually for linux there was no way to specify the model for linux.
> > >
> > > To be marginally clearer, ia64-linux does not support ILP32 mode at
> > > all; it is (as far as I know) purely an HPUX-ism.
> >
> > And AIX and Solaris and even x86-linux, for that matter (except that
> > x86-linux doesn't support LP64).  I haven't played much with Sol 10
> > yet, but I am certain that it supports 32 bit user environments
> > even though the kernel is 64 bit only.  Thanks! - Bruce
>
> In fact, for kicks, using native compilers, I checked the following:
>
> emit_def_check()

Try:

        gcc -E -x c -dM /dev/null

... that might be easier.

MfG Kai