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

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

[Jack Howarth]

    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))
+#define SCM_NORETURN
+#elif defined(__GNUC__) 
 #define SCM_NORETURN __attribute__ ((noreturn))
 #else
 #define SCM_NORETURN

Since the environmentals for __clang__, __clang_major__ and __clang_minor are common to both Apple and llvm.org
clang, the (defined(__apple_build_version__) is used to limit the first test on (__clang_major__ < 5) to Apple
clang. the second test for ((__clang_major__ < 3) && (__clang_minor__ < 3)) requires no additional restriction
since it is valid for both Apple and llvm clang in that version range. Without this patch, builds on Xcode 4.6.3,
which uses Apple clang 4.2 that lacks noreturn attribute support will fail.
          Jack

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

[Mark H Weaver]

Jack Howarth <howarth@bromo.med.uc.edu> 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
test.

> +#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.

    Thanks,
      Mark

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

[Ludovic Courtès]

Mark H Weaver <mhw@netris.org> skribis:

> 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.

Agreed.  As long as Clang defines __GNUC__, we should ignore any such problem.

Ludo’.

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

[Mark H Weaver]

ludo@gnu.org (Ludovic Courtès) writes:

> Mark H Weaver <mhw@netris.org> skribis:
>
>> 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.
>
> Agreed.  As long as Clang defines __GNUC__, we should ignore any such problem.

I'm closing this bug now, since we've not heard from the original
reporter since he filed the bug, and I believe the problem is already
now fixed (by changing "noreturn" to "__noreturn__" in Guile).

     Mark