This is the mail archive of the
mailing list for the GCC project.
Re: Frontend access to target-related options
I've found the code for the target hooks for both the C-family and D
frontends (or at least their implementation for the i386 platform). The
C-family ones seem like they probably are too tied to the preprocessor to
be usable for other languages (which I assume is the reason that the D
frontend created their own target hooks). I'm not sure if functions like
"cpp_assert" and "cpp_define" are actually directly defined or if they have
a macro indirection layer (like lang hooks have macro indirection layers
with LANG_HOOKS_INIT), but I suspect that they're defined, and so the
one-definition rule of C++ prevents any overloading from any other
frontend. As such, the C-family target hooks appear to be unusable for my
On the other hand, the D frontend target hooks don't appear to provide
enough information relating to the target system to be useful (e.g. they
seem to be missing features like SSE support and whatever).
As such, I think it looks like I'd have to add a new target hook. How would
I go about doing this? Is there any documentation on doing so?
On Tue, Jan 7, 2020 at 9:16 PM Richard Biener <firstname.lastname@example.org>
> On Thu, Jan 2, 2020 at 5:54 PM Nathan Sidwell <email@example.com> wrote:
> > On 1/1/20 4:31 AM, The Other wrote:
> > > Hi,
> > > I'm currently working on a Rust frontend for GCC. Rust has some
> > > language-level conditional compilation features based on the presence
> > > lack of features in the target architecture (e.g. SSE, AVX, a static C
> > > runtime) as well as the target CPU architecture itself, target OS, and
> > > various other target-related information (such as pointer width and
> > > endianness).
> > >
> > > As such, the frontend parser requires this target-related option
> > > information to be available to it. I was wondering if there was an
> > > architecture-neutral way of accessing this data (if it is even stored).
> > > I've looked into options.h but I cannot figure out how to use it in an
> > > architecture-neutral way.
> > Um, AVX and such are arch-specific. It sounds like you need some kind
> > of (new?) langhook that targets can register?
> You mean target hook. Depending on the actual piece of info such hook
> might already exist though.
> > nathan
> > --
> > Nathan Sidwell