[m-dev.] MSVC and --no-smart-indexing
Peter Wang
novalazy at gmail.com
Tue Feb 17 10:56:57 AEDT 2015
On Mon, 16 Feb 2015 17:54:36 +1100 (EST), "Zoltan Somogyi" <zoltan.somogyi at runbox.com> wrote:
>
>
> On Mon, 16 Feb 2015 15:56:08 +1100 (AEDT), Julien Fischer <jfischer at opturion.com> wrote:
> > > 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?
>
> They do, which is why having the pregen grade component imply
> bits_per_word=32 solves the problem for pregen grades. I was wondering
> whether having cross_compiling imply bits_per_word=32 would be useful,
> since it would not solve the problem illustrated by my example; it would
> merely move the symptom, making it appear in *different* circumstances.
It would also preclude targeting a 64-bit machine from a 32-bit host.
> > --cross-compiling has never implied anything about the number of
> > tag bits. It's less general than its name would suggest.
>
> The problem I am pointing out is that the documentation of that option
> does not do anything *other than suggestion*, via a longer rephrasing
> of the option name. It does not say what *specifically* a user is guaranteed
> to be able to do with the output of an invocation of mmc --cross-compiling.
I agree that it is insufficiently documented.
Ideally it would not be necessary. For current uses, the compiler knows
the host and target word widths so it can disable compile-time
evaluation of builtins dependent on the word-width or, better, emulate
the result that WOULD be obtained on the target. I think we can do that
now. There may be other cases in future which are not easily so easily
detected or emulated.
Peter
More information about the developers
mailing list