On Mon, 11 Jan 2021 at 17:18, Daniel Engel <lib...@danielengel.com> wrote: > > On Mon, Jan 11, 2021, at 8:07 AM, Christophe Lyon wrote: > > On Sat, 9 Jan 2021 at 14:09, Christophe Lyon <christophe.l...@linaro.org> > > wrote: > > > > > > On Sat, 9 Jan 2021 at 13:27, Daniel Engel <lib...@danielengel.com> wrote: > > > > > > > > On Thu, Jan 7, 2021, at 4:56 AM, Richard Earnshaw wrote: > > > > > On 07/01/2021 00:59, Daniel Engel wrote: > > > > > > --snip-- > > > > > > > > > > > > On Wed, Jan 6, 2021, at 9:05 AM, Richard Earnshaw wrote: > > > > > > --snip-- > > > > > > > > > > > >> - finally, your popcount implementations have data in the code > > > > > >> segment. > > > > > >> That's going to cause problems when we have compilation options > > > > > >> such as > > > > > >> -mpure-code. > > > > > > > > > > > > I am just following the precedent of existing lib1funcs (e.g. > > > > > > __clz2si). > > > > > > If this matters, you'll need to point in the right direction for the > > > > > > fix. I'm not sure it does matter, since these functions are PIC > > > > > > anyway. > > > > > > > > > > That might be a bug in the clz implementations - Christophe: Any > > > > > thoughts? > > > > > > > > __clzsi2() has test coverage in > > > > "gcc.c-torture/execute/builtin-bitops-1.c" > > > Thanks, I'll have a closer look at why I didn't see problems. > > > > > > > So, that's because the code goes to the .text section (as opposed to > > .text.noread) > > and does not have the PURECODE flag. The compiler takes care of this > > when generating code with -mpure-code. > > And the simulator does not complain because it only checks loads from > > the segment with the PURECODE flag set. > > > This is far out of my depth, but can something like: > > ifeq (,$(findstring __symbian__,$(shell $(gcc_compile_bare) -dM -E - > </dev/null))) > > be adapted to: > > a) detect the state of the -mpure-code switch, and > b) pass that flag to the preprocessor? > > If so, I can probably fix both the target section and the data usage. > Just have to add a few instructions to finish unrolling the loop.
I must confess I never checked libgcc's Makefile deeply before, but it looks like you can probably detect whether -mpure-code is part of $CFLAGS. However, it might be better to write pure-code-safe code unconditionally because the toolchain will probably not be rebuilt with -mpure-code as discussed before. Or that could mean adding a -mpure-code multilib.... > > > > > The 'clzs' and 'ctz' functions should never have problems. -mpure-code > > > > appears to be valid only when the 'movt' instruction is available, which > > > > means that the 'clz' instruction will also be available, so no array > > > > loads. > > > No, -mpure-code is also supported with v6m. > > > > > > > Is the -mpure-code state detectable as a preprocessor flag? While > > > No. > > > > > > > 'movw'/'movt' appears to be the canonical solution, I'm not sure it > > > > should be the default just because a processor supports Thumb-2. > > > > > > > > Do users wanting to use -mpure-code recompile the toolchain to avoid > > > > constant data in compiled C functions? I don't think this is the > > > > default for the typical toolchain scripts. > > > No, users of -mpure-code do not recompile the toolchain. > > > > > > --snip -- > > >
