This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][Ada] Add option to gnatlink to fix gnat.dg on some platforms


On Thu, 2009-05-07 at 12:36 +0200, Arnaud Charlet wrote:
> > There might be better ways to solve this annoying issue, I'm open to
> > suggestions.
> 
> Introducing a --XCC switch seems really too specialized and confusing to me.
> 
> Also, your patch does not document this switch in the gnatlink usage.

Will fix.

> Wouldn't it be possible to e.g. use --GCC="... -mips32" or whatever
> option is needed here?

Unless we want to duplicate all the switch processing done by gnatlink I
don't see any other way.

> If this does not work, it might be a better approach to enhance --GCC
> rather than introducing --XCC IMO, in particular for a need internal to
> the GCC tree, and not useful to end users.

What is your proposal here?

--GCC for gnatlink already has a quite convoluted definition:

<<
@item --GCC=@var{compiler_name}
@cindex @option{--GCC=compiler_name} (@command{gnatlink})
Program used for compiling the binder file. The default is
@command{gcc}. You need to use quotes around @var{compiler_name} if
@code{compiler_name} contains spaces or other separator characters.
As an example @option{--GCC="foo -x -y"} will instruct @command{gnatlink} to
use @code{foo -x -y} as your compiler. Note that switch @option{-c} is always
inserted after your command name. Thus in the above example the compiler
command that will be used by @command{gnatlink} will be @code{foo -c -x -y}.
A limitation of this syntax is that the name and path name of the executable
itself must not include any embedded spaces. If the compiler executable is
different from the default one (gcc or <prefix>-gcc), then the back-end
switches in the ALI file are not used to compile the binder generated source.
For example, this is the case with @option{--GCC="foo -x -y"}. But the back end
switches will be used for @option{--GCC="gcc -gnatv"}. If several
@option{--GCC=compiler_name} are used, only the last @var{compiler_name}
is taken into account. However, all the additional switches are also taken
into account. Thus,
@option{--GCC="foo -x -y" --GCC="bar -z -t"} is equivalent to
@option{--GCC="bar -x -y -z -t"}.
>>

What we want if a way to turn off the following behaviour:

"If the compiler executable is different from the default one (gcc or
<prefix>-gcc), then the back-end switches in the ALI file are not used
to compile the binder generated source."

Note: I've no idea for what use case this very specific behaviour is
useful and why it was added on top of --GCC instead of with a separate
switch.

As an alternative I can add a switch, eg something like
"--from-ali" (anyone with a better name?) which when present changes the
behaviour of --GCC in the same way that --XCC from my original patch
does.

Laurent

PS: for reference I've always been opposed to in-tree testing. I wonder
how many hundred of lines of dubious stuff would go away if we just
tested what we want to test: an installed tree instead of something
the user will never see.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]