[Gc] bug#18711: Numerous unknown attribute '__alloc_size_

Discussion:

[Gc] bug#18711: Numerous unknown attribute '__alloc_size__' warnings when using clang

Mark H Weaver

2014-10-14 03:53:57 UTC

A simple
#include <libguile.h>
/usr/local/Cellar/bdw-gc/7.4.2/include/gc/gc.h:411:23: warning: unknown attribute '__alloc_size__' ignored [-Wattributes]
GC_API GC_ATTR_MALLOC GC_ATTR_ALLOC_SIZE(1) void * GC_CALL
^
/usr/local/Cellar/bdw-gc/7.4.2/include/gc/gc_config_macros.h:249:54: note: expanded from macro 'GC_ATTR_ALLOC_SIZE'
# define GC_ATTR_ALLOC_SIZE(argnum) __attribute__((__alloc_size__(argnum)))
^

This is clearly an issue with bdwgc on clang, and possibly only on
Apple's version of clang. Here's the relevant section of
gc/gc_config_macros.h from bdwgc 7.4.2:

--8<---------------cut here---------------start------------->8---
#ifndef GC_ATTR_ALLOC_SIZE
/* 'alloc_size' attribute improves __builtin_object_size correctness. */
/* Only single-argument form of 'alloc_size' attribute is used. */
# if defined(__GNUC__) && (__GNUC__ > 4 \
|| (__GNUC__ == 4 && __GNUC_MINOR__ >= 3 && !defined(__ICC)) \
|| __clang_major__ > 3 \
|| (__clang_major__ == 3 && __clang_minor__ >= 2))
# define GC_ATTR_ALLOC_SIZE(argnum) __attribute__((__alloc_size__(argnum)))
# else
# define GC_ATTR_ALLOC_SIZE(argnum)
# endif
#endif
--8<---------------cut here---------------end--------------->8---

You can see that the bdwgc developers have made an effort to check both
GCC and clang version numbers before using the __alloc_size__ attribute.
The code above seems to suggest that they believed clang 3.2 or later
supported this attribute, whereas your version of clang seems to be
based on upstream clang 3.5. Perhaps Apple removed support for this
attribute from their clang?

In any case, this needs to be taken up with the bdwgc developers.

Regards,
Mark

$ guile --version | head -n 1
guile (GNU Guile) 2.0.11
$ clang --version
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
$ xcodebuild -version -sdk | head -n 2
MacOSX10.9.sdk - OS X 10.9 (macosx10.9)
SDKVersion: 10.9
$ sw_vers
ProductName: Mac OS X
ProductVersion: 10.9.5
BuildVersion: 13F34
$ uname -a
Darwin itako16071.miso 13.4.0 Darwin Kernel Version 13.4.0: Sun Aug 17
19:50:11 PDT 2014; root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64

Ludovic Courtès

2014-10-14 10:09:37 UTC

Permalink

Post by Mark H Weaver
This is clearly an issue with bdwgc on clang, and possibly only on
Apple's version of clang. Here's the relevant section of
#ifndef GC_ATTR_ALLOC_SIZE
/* 'alloc_size' attribute improves __builtin_object_size correctness. */
/* Only single-argument form of 'alloc_size' attribute is used. */
# if defined(__GNUC__) && (__GNUC__ > 4 \
|| (__GNUC__ == 4 && __GNUC_MINOR__ >= 3 && !defined(__ICC)) \
|| __clang_major__ > 3 \
|| (__clang_major__ == 3 && __clang_minor__ >= 2))
# define GC_ATTR_ALLOC_SIZE(argnum) __attribute__((__alloc_size__(argnum)))
# else
# define GC_ATTR_ALLOC_SIZE(argnum)
# endif
#endif

AFAIK, Clang and ICC define __GNUC__ by default, even though they don’t
implement all the features of the corresponding GCC, which may explain
why the above doesn’t work as expected.

Post by Mark H Weaver
You can see that the bdwgc developers have made an effort to check both
GCC and clang version numbers before using the __alloc_size__ attribute.
The code above seems to suggest that they believed clang 3.2 or later
supported this attribute, whereas your version of clang seems to be
based on upstream clang 3.5. Perhaps Apple removed support for this
attribute from their clang?

I think for Clang the right way would be to use the ‘__has_attribute’
magic macro:

http://clang.llvm.org/docs/LanguageExtensions.html#has-attribute

Ludo’.

William S Fulton

2014-10-14 07:10:45 UTC

Permalink

Thanks for analysing and pointing in the right direction Mark. With this
info I found
https://github.com/ivmai/bdwgc/commit/8fc1f3b61b02320848b035ccccd59e04e77d3f6b#diff-b3f85dde7694cbd1268ea9ed20db1b1aR244
which looks like it fixes it in the next release of bdwgc (7.5).

Unfortunately this warning fails our tests as the build log is too big
(this warning leads to > 4GByte build logs as the header is used in
hundreds of our tests), so I'll suppress it some other way until 7.5 is
released.

William

Post by Mark H Weaver

This is clearly an issue with bdwgc on clang, and possibly only on
Apple's version of clang. Here's the relevant section of
--8<---------------cut here---------------start------------->8---
#ifndef GC_ATTR_ALLOC_SIZE
/* 'alloc_size' attribute improves __builtin_object_size correctness. */
/* Only single-argument form of 'alloc_size' attribute is used. */
# if defined(__GNUC__) && (__GNUC__ > 4 \
|| (__GNUC__ == 4 && __GNUC_MINOR__ >= 3 && !defined(__ICC)) \
|| __clang_major__ > 3 \
|| (__clang_major__ == 3 && __clang_minor__ >= 2))
# define GC_ATTR_ALLOC_SIZE(argnum) __attribute__((__alloc_size__(argnum)))
# else
# define GC_ATTR_ALLOC_SIZE(argnum)
# endif
#endif
--8<---------------cut here---------------end--------------->8---
You can see that the bdwgc developers have made an effort to check both
GCC and clang version numbers before using the __alloc_size__ attribute.
The code above seems to suggest that they believed clang 3.2 or later
supported this attribute, whereas your version of clang seems to be
based on upstream clang 3.5. Perhaps Apple removed support for this
attribute from their clang?
In any case, this needs to be taken up with the bdwgc developers.
Regards,
Mark

Ivan Maidanski

2014-10-16 22:07:58 UTC

Permalink

Hi William,

I merged the fix to master: https://github.com/ivmai/bdwgc/commit/b725923951d77f5c6792c2797f89179267c58c9c

Regards,
Ivan

Post by William S Fulton
Thanks for analysing and pointing in the right direction Mark. With this
info I found
https://github.com/ivmai/bdwgc/commit/8fc1f3b61b02320848b035ccccd59e04e77d3f6b#diff-b3f85dde7694cbd1268ea9ed20db1b1aR244
which looks like it fixes it in the next release of bdwgc (7.5).
Unfortunately this warning fails our tests as the build log is too big
(this warning leads to > 4GByte build logs as the header is used in
hundreds of our tests), so I'll suppress it some other way until 7.5 is
released.
William

Post by Mark H Weaver

_______________________________________________
bdwgc mailing list
https://lists.opendylan.org/mailman/listinfo/bdwgc

Mark H Weaver

2014-10-17 20:52:21 UTC

Permalink

Hi Ivan,

Post by Ivan Maidanski
https://github.com/ivmai/bdwgc/commit/b725923951d77f5c6792c2797f89179267c58c9c

Did you intentionally remove the "defined(__GNUC__)" check? Unless
there's some relevant context I'm missing, I guess this will break the
build on any compiler that doesn't implement GNU C.

Mark

Bruce Hoult

2014-10-17 23:33:26 UTC

Permalink

How so? If __GNUC__ is not defined then any use of it will evaluate to 0,
which will produce the same results as guarding the other tests with
defined(__GNUC__).

Post by Mark H Weaver
Hi Ivan,
https://github.com/ivmai/bdwgc/commit/b725923951d77f5c6792c2797f89179267c58c9c
Did you intentionally remove the "defined(__GNUC__)" check? Unless
there's some relevant context I'm missing, I guess this will break the
build on any compiler that doesn't implement GNU C.
Mark
_______________________________________________
bdwgc mailing list
https://lists.opendylan.org/mailman/listinfo/bdwgc
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Mark H Weaver

2014-10-17 23:46:54 UTC

Permalink

Post by Bruce Hoult
How so? If __GNUC__ is not defined then any use of it will evaluate to 0

Embarrassingly, I didn't know that. Sorry for the noise.

Mark

Bruce Hoult

2014-10-17 23:55:16 UTC

Permalink

Neither did the person who wrote the code originally, clearly. In fact it
appears to be quite uncommon knowledge in the C community as a whole.

Post by Mark H Weaver

Post by Bruce Hoult
How so? If __GNUC__ is not defined then any use of it will evaluate to 0

Embarrassingly, I didn't know that. Sorry for the noise.
Mark
_______________________________________________
bdwgc mailing list
https://lists.opendylan.org/mailman/listinfo/bdwgc
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.