This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
whither specs?
- From: Geoff Keating <geoffk at geoffk dot org>
- To: gcc at gcc dot gnu dot org
- Date: Mon, 10 Jun 2002 10:29:14 -0700
- Subject: whither specs?
- Reply-to: Geoff Keating <geoffk at redhat dot com>
My recent patch to the driver allowed it to include target-dependent
code. Now that we no longer need to encapsulate all the
target-dependent argument passing in a separate file, I think this is
a good time to sit back and ask ourselves:
- Do we still want to have the 'specs' file in $(gcc_tooldir)? It's
now redundant unless the user edits it, since the driver generated
it in the first place. I guess the real question is, "do we want
to support the user changing this file?" Is there a better way we
could support the functionality that people try to get by changing
this file?
- Do we want to keep supporting the -specs= command-line switch? If
we could come up with another mechanism for the things that people
usually use this for, we could mark it as `obsolete' for GCC 3.2.
- Do we like to use specs internally? I'm going to spend some time
this week designing a way to have the backends provide C code to
pass flags to the assembler, which should help with some of the more
horrible problems in this area; see, for instance, asm_cpu_spec in
rs6000.h. Should this sort of thing be encouraged, or kept for
those situations where the alternative is too terrible to contemplate?
--
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>