It turns out that tomorrow happened 12 minutes after this email...
The attached diff lets it build with -Werror for me with FreeBSD clang and gcc
(with -fblocks and -fno-blocks) and with ports gcc 4.7.3 and doesn't clutter
the code. Please can you test it with Juniper's gcc?
David
Index: stdlib/atexit.c
===================================================================
--- stdlib/atexit.c (revision 264068)
+++ stdlib/atexit.c (working copy)
@@ -80,6 +80,7 @@
};
static struct atexit *__atexit; /* points to head of LIFO stack
*/
+typedef DECLARE_BLOCK(void, atexit_block, void);
/*
* Register the function described by 'fptr' to be called at application
@@ -141,7 +142,7 @@
* Register a block to be performed at exit.
*/
int
-atexit_b(DECLARE_BLOCK(void, func, void))
+atexit_b(atexit_block func)
{
struct atexit_fn fn;
int error;
Index: stdlib/heapsort.c
===================================================================
--- stdlib/heapsort.c (revision 264068)
+++ stdlib/heapsort.c (working copy)
@@ -45,6 +45,7 @@
#ifdef I_AM_HEAPSORT_B
#include "block_abi.h"
#define COMPAR(x, y) CALL_BLOCK(compar, x, y)
+typedef DECLARE_BLOCK(int, heapsort_block, const void *, const void *);
#else
#define COMPAR(x, y) compar(x, y)
#endif
@@ -149,7 +150,7 @@
heapsort_b(vbase, nmemb, size, compar)
void *vbase;
size_t nmemb, size;
- DECLARE_BLOCK(int, compar, const void *, const void *);
+ heapsort_block compar;
#else
int
heapsort(vbase, nmemb, size, compar)
Index: stdlib/qsort_r.c
===================================================================
--- stdlib/qsort_r.c (revision 264068)
+++ stdlib/qsort_r.c (working copy)
@@ -8,9 +8,10 @@
#define I_AM_QSORT_R
#include "qsort.c"
+typedef DECLARE_BLOCK(int, qsort_block, const void *, const void *);
+
void
-qsort_b(void *base, size_t nel, size_t width,
- DECLARE_BLOCK(int, compar, const void *, const void *))
+qsort_b(void *base, size_t nel, size_t width, qsort_block compar)
{
qsort_r(base, nel, width, compar,
(int (*)(void *, const void *, const void *))
On 4 Apr 2014, at 23:48, David Chisnall <[email protected]> wrote:
> Hi Marcel,
>
> This error is a warning for me with gcc 4.7.3 when I try. With 4.2.1 in the
> tree, it appears to be silenced by something (or possibly we're using the
> native blocks code path with gcc and clang doesn't emit that warning in
> non-blocks mode). We could pull out the structure definitions - this is what
> I've done in the GNUstep versions of these macros, which provide separate
> macros for declaring the type. It will clutter the code a bit, but if it's
> not possible to silence the warnings with your compiler then I can make that
> change.
>
> Unfortunately, the warning actually is spurious here - the structure really
> is expected to be only for the scope of the function, because any compiler
> that can actually generate those structure in a useful way will give the type
> a different internal name.
>
> I'll try to send you a patch to test tomorrow - in the meantime, removing the
> -Werror should make it build. Unfortunately, gcc (especially 4.2) doesn't
> provide very fine-grained control over warnings and it doesn't seem to be
> possible (or, at least, not documented) to disable the ones that are part of
> their default set.
>
> David
>
> On 4 Apr 2014, at 18:42, Marcel Moolenaar <[email protected]> wrote:
>
>> David,
>>
>> The definition of DECLARE_BLOCK seems to trip over GCC 4.2.1 here
>> at Juniper. This is how we run the compiler:
>>
>> /volume/fwtools/gcc/jnpr/4.2.1/amd64-juniper-junos.5/bin/amd64-juniper-junos-gcc
>> -O2 -pipe -I/b/marcelm/fbsd-head/src/lib/libc/include
>> -I/b/marcelm/fbsd-head/src/lib/libc/../../include
>> -I/b/marcelm/fbsd-head/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE
>> -I/b/marcelm/fbsd-head/src/lib/libc/../../contrib/gdtoa
>> -I/b/marcelm/fbsd-head/src/lib/libc/../../contrib/libc-vis -DINET6
>> -I/b/marcelm/fbsd-head/obj/amd64/lib/libc
>> -I/b/marcelm/fbsd-head/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE
>> -I/b/marcelm/fbsd-head/src/lib/libc/../../contrib/jemalloc/include
>> -I/b/marcelm/fbsd-head/src/lib/libc/../../contrib/tzcode/stdtime
>> -I/b/marcelm/fbsd-head/src/lib/libc/stdtime
>> -I/b/marcelm/fbsd-head/src/lib/libc/locale -DBROKEN_DES -DPORTMAP
>> -DDES_BUILTIN -I/b/marcelm/fbsd-head/src/lib/libc/rpc -DNS_CACHING
>> -DSYMBOL_VERSIONING -D__ELF__ -Dunix -D__unix -D__unix__
>> -D__FreeBSD__=9 --sysroot
>> /volume/sisyphus/occam/sysroot/projects_tp5/20131031.611483/amd64
>> -fno-builtin-printf -g -no
s
> tdinc -isystem/b/marcelm/fbsd-head/obj/stage/amd64/usr/include
> -isystem/b/marcelm/fbsd-head/obj/stage/amd64/include -std=gnu99
> -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized
> -Wno-pointer-sign -I/b/marcelm/fbsd-head/src/lib/libutil
> -I/b/marcelm/fbsd-head/src/lib/msun/src
> -I/b/marcelm/fbsd-head/src/lib/msun/x86 -c
> /b/marcelm/fbsd-head/src/lib/libc/stdlib/atexit.c -o atexit.o
>> whatever set of flags we use here at Juniper:
>>
>> This is the error:
>>
>> Building /b/marcelm/fbsd-head/obj/amd64/lib/libc/atexit.o
>> cc1: warnings being treated as errors
>> /b/marcelm/fbsd-head/src/lib/libc/stdlib/atexit.c:144: warning: anonymous
>> struct declared inside parameter list
>> /b/marcelm/fbsd-head/src/lib/libc/stdlib/atexit.c:144: warning: its scope is
>> only this definition or declaration, which is probably not what you want
>> *** Error code 1
>>
>> This hurdle is a bit higher than the hurdles I normally run into
>> when syncing with ^/head, so I could use your expertise.
>>
>> We need to continue to be able to build the sources with compilers
>> outside of the tree as much as possible and I haven't found a way
>> yet (one I don't dislike to be precise) to get this blocks stuff
>> to compile. It's a huge blocker right now.
>>
>> Thanks,
>>
>> --
>> Marcel Moolenaar
>> [email protected]
>>
>>
>
> _______________________________________________
> [email protected] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "[email protected]"
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[email protected]"