[m-dev.] MSVC and --no-smart-indexing

Julien Fischer jfischer at opturion.com
Mon Feb 16 15:56:08 AEDT 2015

On Mon, 16 Feb 2015, Zoltan Somogyi wrote:

> On Mon, 9 Feb 2015 10:32:12 +1100, Paul Bone <paul at bone.id.au> wrote:
>>> I don't have any convenient way to test cross-compilation between
>>> 32 and 64 bit systems, but if someone does, I could generate diffs
>>> for them to test.
>> I can test this.
> I have had a look at the code that does smart indexing for both
> the LLDS and MLDS backends, and the only things I could find
> that depended on word size were (a) string hash switches,
> where the hash function would use the full word size of the host
> machine, and (b) bit vector checks, which used the configured
> word size, i.e. the value of the bits_per_word compiler option.
> I fixed (a) last week, and as far as I can tell, (b) has been
> handled properly for a while, if only for the special case of creating
> the source distribution, by the code in handle_options.m
> that handles the pregenerated_dist option. Therefore I think
> we can now remove the workaround of specifying --no-smart-indexing
> in tools/build_srcdirst.
> Paul, will you please try this out?
> As for non-pregen applications of cross-compilation, I can change
> the indexing methods that use bit vectors to use 32 bit words
> even on platforms with bigger words, but I don't think that would
> solve the bigger problem.

For non-pregen applications of cross-compilation we typically set
a bunch of other configure options anyway (see
tools/configure_mingw_cross).  One of those options is --bits-per-word.
Do the indexing methods that use bit vectors not check the value
of that option?

> The bigger problem is shown by these
> scenarios:
> machine A: 64 bit
> machine B: 32 bit
> machine C: 64 bit
> a program has two modules: mod1 and mod2.
> scenario (i)
> on machine A: generate mod1.c with --cross-compiling
> on machine B: generate mod2.c natively
> on machine B: generate mod1.o, mod2.o and the executable
> scenario (Ii)
> on machine A: generate mod1.c with --cross-compiling
> on machine C: generate mod2.c natively
> on machine C: generate mod1.o, mod2.o and the executable
> The $64k question: how many tag bits does machine A use
> when creating mod1.c? Scenario (i) requires the answer to be 2;
> scenario (ii) requires it to be 3.
> (The pregen grade solves the problem by requiring the use
> of 2 tag bits on all machines, even 64 bit, even *without*
> --cross-compiling.)
> Can anyone see a flaw in my reasoning?

--cross-compiling has never implied anything about the number of
tag bits.  It's less general than its name would suggest.


More information about the developers mailing list