[Bug target/42994] Status of using both -m32 and -m64 on the same command line

[Bug target/42994] Status of using both -m32 and -m64 on the same command line

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42994

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|sparc64-suse-linux-gnu      |
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-07
                 CC|                            |ebotcazou at gcc dot gnu.org
               Host|sparc64-suse-linux-gnu      |
     Ever confirmed|0                           |1
              Build|sparc64-suse-linux-gnu      |

[Bug target/42994] Status of using both -m32 and -m64 on the same command line

[manu at gcc dot gnu dot org]

------- Comment #4 from manu at gcc dot gnu dot org  2010-02-21 23:21 -------
So this is confirmed, yes? no? Joseph?


-- 

manu at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |manu at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42994

[Bug target/42994] Status of using both -m32 and -m64 on the same command line

[joseph at codesourcery dot com]

------- Comment #3 from joseph at codesourcery dot com  2010-02-07 22:58 -------
Subject: Re:  Status of using both -m32 and -m64 on the
 same command line

On Sun, 7 Feb 2010, pinskia at gcc dot gnu dot org wrote:

> >I think that this behavior should be unified across gcc's supported arches, 
> 
> Why -m* means it is a target specific option?

It's a lot less confusing for people using GCC for multiple targets (and 
the wide range of target support is one of the major advantages of GCC) if 
when multiple targets do similar things, they do so the same way where 
possible.  Unfortunate inconsistencies include:

* The combination of -march, -mcpu and -mtune options available, and what 
-mcpu means where it is available (also, some targets have yet other 
options for specifying target processors).

* The options used for selecting endianness where applicable 
(-mbig-endian, -meb, -mb, -EB).

* Whether interrupt handlers use the "interrupt" or "interrupt_handler" 
attribute.

It's not that code using one of these options would do so in a 
cross-platform way; it's that having consistency would be beneficial to 
users doing similar things for multiple targets.

> x86_64 and powerpc64 both have the same behavior of having the last one being
> the used one which is like options act like.  So really this is a sparc64 issue
> only.

Yes, similar to the above there should be consistency in how options 
overriding each other work, and I describe a proposed model for this in 
<http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html> (Appendix 1) which means 
the last option specified wins in cases like this of options that are 
exact opposites.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42994

[Bug target/42994] Status of using both -m32 and -m64 on the same command line

[rguenther at suse dot de]

------- Comment #2 from rguenther at suse dot de  2010-02-07 22:09 -------
Subject: Re:   New: Status of using both -m32 and -m64 on
 the same command line

On Sun, 7 Feb 2010, jengelh at medozas dot de wrote:

> I noticed that combining -m32 and -m64 has different effects on different
> platforms.
> 
> On sparc64:
> 20:06 ares:../libhugetlbfs/libhugetlbfs-2.0 > gcc -c -m32 -m64 x.c
> gcc: may not use both -m32 and -m64
> 
> On x86_64:
> 20:11 borg:~/obs > >x.c
> 20:11 borg:~/obs > gcc -c -m32 -m64 x.c
> (no error)
> 
> I think that this behavior should be unified across gcc's supported arches, and
> I would opt for not allowing both -m32 and -m64, to detect flawed packages
> (like libhugetlbfs in this case) that manually add -m64 - perhaps even in the
> wrong place - based upon their arch detection heuristic (which is generally not
> accurate).
> 
> The particular example point in case is rpmbuilding on SUSE where RPM_OPT_FLAGS
> carries -m32 (this is correct) and libhugetlbfs's Makefile statically adds -m64
> (this is incorrect). This error has not popped up earlier since combining -m32
> and -m64 is unfortunately permitted on x86.

It's never correct for RPM_OPT_FLAGS to add either -m32 or -m64.

Richard.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42994

[Bug target/42994] Status of using both -m32 and -m64 on the same command line

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2010-02-07 19:21 -------
>I think that this behavior should be unified across gcc's supported arches, 

Why -m* means it is a target specific option?

x86_64 and powerpc64 both have the same behavior of having the last one being
the used one which is like options act like.  So really this is a sparc64 issue
only.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|driver                      |target


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42994