[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15807: guile-2.0.9 doesn't handle Apple clang < 5 or llvm.org clang

From: Mark H Weaver
Subject: bug#15807: guile-2.0.9 doesn't handle Apple clang < 5 or llvm.org clang < 3.3 properly
Date: Mon, 04 Nov 2013 22:00:36 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Jack Howarth <address@hidden> writes:

>     The guile 2.0.9 sources incorrectly assumes that sll clang compilers 
> support
> the noreturn attribute which was only added in llvm.org clang 3.3 and Apple 
> clang 5.0.
> In fink, we have fixed this with the following patch...
> --- guile-2.0.9/libguile/__scm.h.orig   2013-11-01 22:57:06.000000000 -0400
> +++ guile-2.0.9/libguile/__scm.h        2013-11-01 23:07:03.000000000 -0400
> @@ -76,7 +76,10 @@
>   * Examples:
>   *   1) int foo (char arg) SCM_NORETURN;
>   */
> -#ifdef __GNUC__
> +
> +#if (defined(__apple_build_version__) && (__clang_major__ < 5)) || 
> ((__clang_major__ < 3) && (__clang_minor__ < 3))

The logic of these comparisons is incorrect.  Presumably you wanted the
test to be true for clang < 3.3.  However, it will be false for clang
versions 3.2 and 2.3.

Anyway, I don't want to include this complex version comparison logic
into __scm.h.  If we need to add something, it should be via an autoconf

> +#define SCM_NORETURN
> +#elif defined(__GNUC__) 
>  #define SCM_NORETURN __attribute__ ((noreturn))
>  #else
>  #define SCM_NORETURN

So clang is pretending to be GCC (by defining __GNUC__), and then breaks
if we use the noreturn attribute which has been supported in GCC since
version 2.5 (released in 1993) ?  If so, I consider that a bug in clang.

For now, I've changed "__attribute__ ((noreturn))" to "__attribute__
((__noreturn__))", on the theory that the actual problem here is that
'noreturn' is being defined to _Noreturn by stdnoreturn.h.

Can you please try it and see if it fixes the problem?  Just because
clang doesn't support the ((noreturn)) attribute doesn't mean that it
necessarily aborts compilation if it sees it.

Please let us know how it goes.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]