On Tue, May 29, 2018 at 1:12 PM, Richard Purdie <[email protected]> wrote: > On Tue, 2018-05-29 at 12:13 -0700, Khem Raj wrote: >> On Tue, May 29, 2018 at 11:41 AM, Andre McCurdy <[email protected]> >> wrote: >> > >> > This change looks wrong (or at least incomplete and lacking a >> > decent >> > explanation): >> why do you think it is wrong ? I would be happy to make the >> explanation more decent >> if you have ideas please share. >> >> > >> > >> > http://git.openembedded.org/openembedded-core/commit/?h=master-ne >> > xt&id=fbec01f01fdad23d95271db063ee0a4d0ab44568 >> > >> > It was never posted to the list but seems to have made it as far as >> > master-next. > > I don't know where Ross got the patches from but I've taken over and he > told me the patches in mut were ready. I didn't take this one however.
Thats right. since Ross has been testing gcc8 patchset and reducing the number of patches needed for enabling gcc8 and this one seems more benign, to go in independent of rest of gcc8 patches. > > My concern is the use of "remove" which I really prefer not to use in > OE-Core. In core, its a sign that we have the overall structure wrong > as we should never need to do this. Yes and its a valid one. A better way would be to not use -mcpu for recipes which are not compiled for machine specifically, our tunes however are using this extensively and changing that probably should not be clubbed together with gcc upgrade. the warning emitted with gcc8 is just highlighting the problem that has been latent. -mcpu is not consistent across different architecture, x86 has removed it for arm it means sum of march+mtune etc. on arm mcpu backfills either of march or mtune if not supplied on cmdline, and in case there are conflicts the rightmost setting wins, however this precedence can then conflict with builtin defaults, thats what we are seeing here. I thought about proposing a separate series for removing -mtunes atleast for arm. However such a change would need very careful testing, since this can have runtime performance impacts and other optimization bugs etc. So regardless we should do it where we only use -march and -mtune combination which will let it target more broader spectrum of cpus and users will be able to generate pre-compiled binaries for larger base ISA so there are a few advantages leaving compiler do its job always results in best performing code in my experience, adding too many fine-tuning at global level are overkill anyway. apps ask for specific opt flags themselves where needed, and if we have empirical data where it proves helpful we can always do that at recipe level via cflags. > > I'd like to understand why gcc-runtime needs this special treatment and > whether there are other arm tunes which have the same issue? Should we > be tweaking the main tune files in some way instead? > Yes we should be re-looking at how arm tune flles stagger various compiler options especially march/mtune/mcpu, but I would think that is a separate topic. > Cheers, > > Richard > > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
