On Fri, Sep 04, 2015 at 06:04:15PM -0500, Segher Boessenkool wrote: > On Fri, Sep 04, 2015 at 04:16:40PM -0400, Rich Felker wrote: > > One thing I've noticed that's odd is that gcc -mfdpic -fPIC produces > > different (less efficient) code from just gcc -mfdpic, which seems > > wrong, but agrees with sh.c which has a number of checks for flag_pic > > not matched with a TARGET_FDPIC check. > > Generic code tests flag_pic in important places as well.
Hmm, these are probably correct: things like default TLS model, whether external functions defined in the same TU are subject to interposition, etc. So ignoring -fPIC would be incorrect, and in fact the different/less-efficient codegen might be correct. But if -fPIE is generating different code, that's probably a bug (or at least unwanted). > > I'm thinking all of these > > should either be flag_pic||TARGET_PIC or flag_pic&&!TARGET_FDPIC, > > depending on whether the code applies to all PIC or is specific to the > > non-FDPIC PIC model where r12 is call-saved. Does this sound correct? > > I think we need spurious -fPIC to work (although it could be handled > > with spec magic) and not pessimize code, since most library builds > > will use -fPIC. > > If you never want -fPIC (or -fpic) if fdpic is enabled, you can disable > it (in sh_option_override)? Even if it weren't needed for the above reasons, having it generate an error would be very problematic from a standpoint of being able to build packages unmodified. So I probably just need to have all the conditionals in sh.c right (checking either ||TARGET_FDPIC or &&!TARGET_FDPIC). Rich
