On Thu, 2019-11-07 at 00:12 +0200, Adrian Bunk wrote: > On Wed, Nov 06, 2019 at 10:18:18AM -0800, Alistair Francis wrote: > > ... > > +TUNE_CCARGS_riscv64 .= "${@bb.utils.contains('TUNE_FEATURES', > > 'riscv64-f', ' -mabi=lp64d', ' -mabi=lp64', d)}" > > +TUNE_CCARGS_riscv32 .= "${@bb.utils.contains('TUNE_FEATURES', > > 'riscv32-f', ' -mabi=ilp32f', ' -mabi=ilp32', d)}" > > ... > > That looks wrong, what would you put in TUNE_FEATURES > for -mabi=lp64f when -mabi=lp64d is called riscv64-f?
I am just going to add riscv32nf and riscv64nf. This will specify -mabi=ilp32 and -mabi=lp64 accordingly. I won't change the default riscv32 and riscv64. We can then deal with the single and double float at a later point. > > Also note that this is only the floating point calling convention, > whether the compiler emits floating point instructions is defined > by -march. -march is another can of worms that I was trying to avoid. I don't have a good way of handling the ISA strings at the moment without some crazy number of tune options. > > It would be good if this would start with a plan how to handle > all possible combination of RISC-V ISA extensions, ideally better > than the arm mess. Agreed. I am just going to change this to add a no float option as that fixes a large number of 32-bit link failures (seen in U-Boot, OpenSBI and SDKs) and we can re-evaluate a longer term march fix. Alistair > > cu > Adrian > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core