This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH] Re: Why Ada always seems to want to devolve from ZCX back to SJLJ: the mystery explained [was Re: GNAT mysterious "missing stub for subunit" error. ]
- From: Dave Korn <dave dot korn dot cygwin at googlemail dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: Dave Korn <dave dot korn dot cygwin at googlemail dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Laurent GUERBY <laurent at guerby dot net>
- Date: Thu, 24 Sep 2009 11:49:47 +0100
- Subject: [PATCH] Re: Why Ada always seems to want to devolve from ZCX back to SJLJ: the mystery explained [was Re: GNAT mysterious "missing stub for subunit" error. ]
- References: <4AA5F7F4.1070201@gmail.com> <4AA676D9.2030403@gmail.com> <4ABA7C9A.1050601@gmail.com> <200909232307.56745.ebotcazou@adacore.com>
[ Maintainers: re: http://gcc.gnu.org/ml/gcc/2009-09/threads.html#00477 ]
Eric Botcazou wrote:
>> Is it just a bug for me to generate LIBGNAT_TARGET_PAIRS in a way that
>> has superfluous spaces (whether leading, trailing or embedded), or shall I
>> send a patch to add a $(strip) to the right-hand side of the ifeq
>> comparison? Or perhaps we should do
>>
>> LIBGNAT_TARGET_PAIRS:=$(strip $(LIBGNAT_TARGET_PAIRS))
>>
>> right at the top-level, just after the per-target chunks, to ensure the
>> string is properly normalised before any further tests and comparisons we
>> might want to make?
>
> That indeed seems to be a good idea (with a little comment).
In the end I decided not to, because the definition of LIBGNAT_TARGET_PAIRS
explicitly states that it may contain redundant whitespace:
> # LIBGNAT_TARGET_PAIRS is a list of pairs of filenames.
> # The members of each pair must be separated by a '<' and no whitespace.
> # Each pair must be separated by some amount of whitespace from the following
> # pair.
... so I decided it was the test that was in the wrong. All other uses of
LIBGNAT_TARGET_PAIRS are already in a context where that's no issue
(specifically, in $(foreach) constructs), and although I can't imagine a
situation where changing LIBGNAT_TARGET_PAIRS from its current state of
deferred-expansion to immediately-expanded would cause a problem, I'd rather
not change the semantics of the variable any if I don't need to. Thanks to
you both for helping me with tracking down this weirdness!
gcc/ada/ChangeLog:
* gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS): Simplify test for
a-except% in target pairs list; don't (implicitly) compare whitespace.
Tested by bootstrapping on i686-pc-cygwin, over on the cygwin-improvements
branch in the presence of changes that tickled the bug. OK for HEAD?
cheers,
DaveK
* gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS): Simplify test for
a-except% in target pairs list; don't (implicitly) compare whitespace.
Index: gcc-interface/Makefile.in
===================================================================
--- gcc-interface/Makefile.in (revision 152052)
+++ gcc-interface/Makefile.in (working copy)
@@ -2147,7 +2147,7 @@ endif
# These base versions lack Ada 2005 additions which would cause bootstrap
# problems if included in the compiler and other basic tools.
-ifeq ($(filter-out a-except%,$(LIBGNAT_TARGET_PAIRS)),$(LIBGNAT_TARGET_PAIRS))
+ifeq ($(filter a-except%,$(LIBGNAT_TARGET_PAIRS)),)
LIBGNAT_TARGET_PAIRS += \
a-except.ads<a-except-2005.ads \
a-except.adb<a-except-2005.adb