On Thu, Sep 01, 2022 at 05:05:44PM +0800, Kewen.Lin wrote: > > On Wed, Aug 31, 2022 at 05:33:28PM +0800, Kewen.Lin wrote: > > *Should* -mpowerpc64 be disabled by -m32? > > I think the reason to disable -mpowerpc64 at -m32 is that we have > -mpowerpc64 explicitly specified at -m64 (equivalent behavior).
*Im*plicitly. Explicit means the user has it on the command line. > In the current implementation, when -m64 is specified, we set the > bit OPTION_MASK_POWERPC64 in both opts and opts_set. Since we > set OPTION_MASK_POWERPC64 in opts_set for -m64, when we find the > OPTION_MASK_POWERPC64 is ON in opts_set, we don't know if there > is one actual cmd-line option -mpowerpc64 or just -m64. Yes. That is what _explicit is for :-) > 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. > To make -m32/-m64 and -mpowerpc64 orthogonal, IMHO we should not > set bit OPTION_MASK_POWERPC64 in opts_set for -m64. No. Instead, we should not touch it if the user has explicitly set it or unset it. Just like with all other flags :-) > I'm not sure > if there is some particular reason why we set OPTION_MASK_POWERPC64 > in opts_set, I hope no. :) One possible reason I can imagine is > that we want to get the cmd-line options "-mno-powerpc64 -m64" not > raise error, but I think having it to error makes more senses. Agreed. > btw, I guess the option compatibility isn't an blocking issue > here, right? We have survived for years with the status quo, nothing changed recently that makes it more urgent to fix this. Segher
