on 2022/9/3 01:44, Segher Boessenkool wrote: > On Fri, Sep 02, 2022 at 08:51:01AM +0800, Kewen.Lin wrote: >> on 2022/9/1 23:04, Segher Boessenkool wrote: >>> On Thu, Sep 01, 2022 at 05:05:44PM +0800, Kewen.Lin wrote: >>>> Without any explicit -mpowerpc64 (and -mno-), I think we all agree >>>> that -m64 should set OPTION_MASK_POWERPC64 in opts, conversely -m32 >>>> should unset OPTION_MASK_POWERPC64 in opts. >>> >>> The latter only for OSes that do not handle -mpowerpc64 correctly. >> >> I think it's the same for the OSes that handle -mpowerpc64 correctly. > > No. -m32 should not set or unset POWERPC64. The two options are > independent. > > -m64 on the other hand forces POWERPC64 to on. -m64 -mno-powerpc64 is > invalid (and we do indeed error on that). But we do allow > -m32 -mno-powerpc64 -m64 > (silently enabling it again), urgh.
I just realized the discussion here depends on how we implemented it, I can understand what you mean now. Yes, if we implemented it like the other option supports in rs6000_option_override_internal, we only get -m32 or -m64 eventually, we don't need to do anything for -m32 but need to forces POWERPC64 for -m64 if it's not set in opts_set. The current implementation by setting and unsetting in command line option handling is bad, it makes us have to set/unset on the way. > >> >> Note that it's for the context without any explicit -mpowerpc64 (and >> -mno-), assuming we don't "unset OPTION_MASK_POWERPC64 in opts" for >> -m32, then the command line "-m64 -m32" would not be the same as >> "-m32", since the previous "-m64" sets OPTION_MASK_POWERPC64 in opts >> and it's still kept, it's unexpected. > > No. -m64 -m32 does not set POWERPC64! Or it shouldn't, in any case :-( > Yeah, (... does not set/unset), thanks again for your clarification. :) BR, Kewen
