On Wed, Oct 22, 2014 at 02:30:44AM +0400, Ilya Verbin wrote:
> > I don't see anything restricting this program to being built for GNU
> > *hosts*. Thus, it needs to be portable (to different hosts; obviously
> > it's target-architecture-specific) rather than relying on glibc
> > interfaces. (Providing appropriate functions in libiberty is of course an
> > option; thus, freely using obstacks is fine because they're in libiberty.)
>
> This mkoffload is expected to be built only with the offload compiler,
> which is expected to be configured with
> '--enable-as-accelerator-for=... --host=x86_64-*-linux-gnu
> --target=x86_64-*-linux-gnu'.
> Without $enable_as_accelerator it wouldn't be built. I will add more
> restrictions to config.gcc.
But why the --host=x86_64-*-linux-gnu restriction?
mkoffload looks to me like a typical host tool, but I don't understand
why it would require native compilation, it is a tool that arranges that
the offloading target compiler is invoked, and results linked back, but it
doesn't need to execute anything on the target, you don't need access to the
acceleration device for that and I don't see any reason why it couldn't be
run on s390-linux, or say mingw.
Both the primary compiler and offloading target compilers obviously have to
be configured for the same (or similar?) host, the target (for what they
generate code for) is given for both too (unless we start supporting say
powerpc64-linux primary compiler offloading to Intel MIC etc.) and build
irrelevant (e.g. you could build offloading compiler using canadian cross
with --enable-as-accelerator-for=x86_64-pc-linux --build=aarch64-linux \
--host=s390-linux --target=x86_64-intelmicemul-linux
and primary compiler with
--enable-offload-targets=x86_64-intelmicemul-linux-gnu=/some/path/ \
--build=armv7tel-linux-gnueabi --host=s390-linux --target=x86_64-pc-linux
). Or do you see any substantial reasons why this can't work?
> >> + nextval = strchrnul (curval, ':');
> >
> > I don't think strchrnul is portable (unless added to libiberty).
>
> It seems that there is no need to make this mkoffload so portable.
I disagree, see above. I think this isn't so performance critical code
that you can't just use portable:
nextval = strchr (curval, ':');
if (nextval == NULL)
nextval = strchr (curval, '\0');
Jakub
