Re: gcc compilation broken with SVN r264042
On 3 Apr 2014, at 00:23, Warner Losh i...@bsdimp.com wrote: So less carping and more fixing is needed here. Should be fixed in r264069 - I'm sure Jenkins / Tinderbox will tell me if it isn't... libc now builds for me with gcc and clang. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gcc compilation broken with SVN r264042
On Apr 3, 2014, at 2:11 AM, David Chisnall thera...@freebsd.org wrote: On 3 Apr 2014, at 00:23, Warner Losh i...@bsdimp.com wrote: So less carping and more fixing is needed here. Should be fixed in r264069 - I'm sure Jenkins / Tinderbox will tell me if it isn't... libc now builds for me with gcc and clang. thanks David… I’d planned a universe run later today to test some of my changes, so this will help… Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gcc compilation broken with SVN r264042
On 3 Apr 2014, at 14:26, Warner Losh i...@bsdimp.com wrote: On Apr 3, 2014, at 2:11 AM, David Chisnall thera...@freebsd.org wrote: On 3 Apr 2014, at 00:23, Warner Losh i...@bsdimp.com wrote: So less carping and more fixing is needed here. Should be fixed in r264069 - I'm sure Jenkins / Tinderbox will tell me if it isn't... libc now builds for me with gcc and clang. thanks David… I’d planned a universe run later today to test some of my changes, so this will help… Let me know if you encounter any issues. I've built libc now with: - clang 3.4 (FreeBSD edition) - clang 3.4 (FreeBSD edition) -fblocks - gcc 4.2.1 FreeBSD edition - gcc 4.2.1 FreeBSD edition -fblocks - gcc 4.7.3 (from ports) All of these seem to work, and all produce a libc with _b functions that work with my clang-compiled test program. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gcc compilation broken with SVN r264042
On Apr 3, 2014, at 7:35 AM, David Chisnall thera...@freebsd.org wrote: On 3 Apr 2014, at 14:26, Warner Losh i...@bsdimp.com wrote: On Apr 3, 2014, at 2:11 AM, David Chisnall thera...@freebsd.org wrote: On 3 Apr 2014, at 00:23, Warner Losh i...@bsdimp.com wrote: So less carping and more fixing is needed here. Should be fixed in r264069 - I'm sure Jenkins / Tinderbox will tell me if it isn't... libc now builds for me with gcc and clang. thanks David… I’d planned a universe run later today to test some of my changes, so this will help… Let me know if you encounter any issues. I've built libc now with: - clang 3.4 (FreeBSD edition) - clang 3.4 (FreeBSD edition) -fblocks - gcc 4.2.1 FreeBSD edition - gcc 4.2.1 FreeBSD edition -fblocks - gcc 4.7.3 (from ports) All of these seem to work, and all produce a libc with _b functions that work with my clang-compiled test program. Cool. In the background, I’m also testing patches against gcc48 and gcc49 ports to allow them to compile FreeBSD, though I’m not through all the bootstrapping issues for cross builds… Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
gcc compilation broken with SVN r264042
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Seems that GCC doesn't like/understand the cast .. imb@mail:/usr/src/lib/libc sudo make cc -O2 -pipe -march=pentium4 -I/usr/src/lib/libc/include - -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS - -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa - -I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 - -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE - -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/jemalloc/include - -DMALLOC_PRODUCTION -I/usr/src/lib/libc/../../contrib/tzcode/stdtime - -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES - -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING - -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers - -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/stdlib/atexit.c -o atexit.o /usr/src/lib/libc/stdlib/atexit.c: In function 'atexit_b': /usr/src/lib/libc/stdlib/atexit.c:157: error: cannot convert to a pointer type *** Error code 1 Stop. make: stopped in /usr/src/lib/libc -BEGIN PGP SIGNATURE- Version: GnuPG v1 iEYEARECAAYFAlM8YbcACgkQQv9rrgRC1JIucgCfRPm79qcKX9XpAfazKfGRsOry lOAAnRiHdpdRzLS5MtC7YPOsNeWZtiBS =2y7B -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gcc compilation broken with SVN r264042
Hi,
I'm trying to reproduce this, but I don't seem to be able to get the same error
as you. I do get a warning with GCC about a cast to an anonymous struct, which
the attached patch fixes, but even without this I'm able to build both with the
gcc in 9 and the gcc in ports. Can you let me know your gcc version?
Unfortunately, the gcc error reporting isn't very helpful, so I don't know what
it thinks it can't convert to a pointer type. It would be great if you could
try this patch, and if that doesn't fix it then try splitting the casts and
dereferences into separate lines and see which part of this it is the gcc
doesn't like.
David
Index: include/block_abi.h
===
--- include/block_abi.h (revision 264042)
+++ include/block_abi.h (working copy)
@@ -50,14 +50,16 @@
} *name
#define CALL_BLOCK(name, ...) (name)-invoke(name, __VA_ARGS__)
#endif // __BLOCKS__
+struct generic_block
+{
+ void *isa;
+ int flags;
+ int reserved;
+ void (*invoke)(void *, ...);
+};
/**
* Returns the pointer to the block-invoke function. This is used for passing
* blocks to functions that want a function pointer and a data pointer.
*/
#define GET_BLOCK_FUNCTION(x) \
- (((struct {\
- void *isa;\
- int flags;\
- int reserved;\
- void (*invoke)(void *, ...);\
- }*)x)-invoke)
+ (((struct generic_block*)x)-invoke)
On 2 Apr 2014, at 20:15, Michael Butler i...@protected-networks.net wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Seems that GCC doesn't like/understand the cast ..
imb@mail:/usr/src/lib/libc sudo make
cc -O2 -pipe -march=pentium4 -I/usr/src/lib/libc/include
- -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS
- -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa
- -I/usr/src/lib/libc/../../contrib/libc-vis -DINET6
- -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE
- -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/jemalloc/include
- -DMALLOC_PRODUCTION -I/usr/src/lib/libc/../../contrib/tzcode/stdtime
- -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES
- -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING
- -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers
- -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c
/usr/src/lib/libc/stdlib/atexit.c -o atexit.o
/usr/src/lib/libc/stdlib/atexit.c: In function 'atexit_b':
/usr/src/lib/libc/stdlib/atexit.c:157: error: cannot convert to a
pointer type
*** Error code 1
Stop.
make: stopped in /usr/src/lib/libc
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iEYEARECAAYFAlM8YbcACgkQQv9rrgRC1JIucgCfRPm79qcKX9XpAfazKfGRsOry
lOAAnRiHdpdRzLS5MtC7YPOsNeWZtiBS
=2y7B
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gcc compilation broken with SVN r264042
On 04/02/14 15:30, David Chisnall wrote: I'm trying to reproduce this, but I don't seem to be able to get the same error as you. I do get a warning with GCC about a cast to an anonymous struct, which the attached patch fixes, but even without this I'm able to build both with the gcc in 9 and the gcc in ports. Can you let me know your gcc version? Unfortunately, the gcc error reporting isn't very helpful, so I don't know what it thinks it can't convert to a pointer type. It would be great if you could try this patch, and if that doesn't fix it then try splitting the casts and dereferences into separate lines and see which part of this it is the gcc doesn't like. This is .. cc (GCC) 4.2.1 20070831 patched [FreeBSD] .. on .. FreeBSD 11.0-CURRENT #22 r263969: Mon Mar 31 10:45:56 EDT 2014 Splitting it like .. - fn.fn_ptr.cxa_func = (void(*)(void*))GET_BLOCK_FUNCTION(func); + fn.fn_ptr.cxa_func = + (void(*)(void*)) + GET_BLOCK_FUNCTION(func); .. causes the reported error to point at the GET_BLOCK_FUNCTION. I guess it's time for me to migrate that box to clang :-) imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gcc compilation broken with SVN r264042
On 2 Apr 2014, at 20:53, Michael Butler i...@protected-networks.net wrote: cc (GCC) 4.2.1 20070831 patched [FreeBSD] .. on .. FreeBSD 11.0-CURRENT #22 r263969: Mon Mar 31 10:45:56 EDT 2014 Splitting it like .. - fn.fn_ptr.cxa_func = (void(*)(void*))GET_BLOCK_FUNCTION(func); + fn.fn_ptr.cxa_func = + (void(*)(void*)) + GET_BLOCK_FUNCTION(func); .. causes the reported error to point at the GET_BLOCK_FUNCTION. Sorry, I meant split it into different statements. Along the lines of: struct generic_block *b = (struct generic_block*)func; void (*fn)(void*,...) = b-invoke; fn.fn_ptr.cxa_func = (void (*)(void*))fn; I guess it's time for me to migrate that box to clang :-) Well, I wouldn't object to that, but it would be good to fix this - we still want to be able to build the base system with gcc (or another compiler), even if we don't encourage it... David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gcc compilation broken with SVN r264042
On Wed, Apr 02, 2014 at 08:58:21PM +0100, David Chisnall wrote: Well, I wouldn't object to that, but it would be good to fix this - we still want to be able to build the base system with gcc (or another compiler), even if we don't encourage it... Who is we in even if we don't encourage it...? In fact, this is a fairly dumb idea, and *we* should encourage building the base system with as many different compilers as possible. It's called portability and allows one to find bugs that the annointed compiler might miss or actually cause. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gcc compilation broken with SVN r264042
On 2 Apr 2014, at 21:21, Steve Kargl s...@troutmask.apl.washington.edu wrote: Who is we in even if we don't encourage it...? We is the FreeBSD project, collectively. For a larger list of things that we recommend, look at the src.conf man page, which contains a long list of things that we encourage, codified as the defaults for a build. Building FreeBSD-HEAD/i386 with gcc is just one of a long list of things that we don't encourage. In fact, this is a fairly dumb idea, Having a recommended compiler is a dumb idea? and *we* should encourage building the base system with as many different compilers as possible. I didn't say otherwise, which is why I'm working to fix this. I'd love to have the Jenkins jobs set up with external toolchain support and be able to plug in compilers from ports to try to build / boot / test the base system on a regular basis. If you're developing FreeBSD or testing, then please compile with as many other compilers as you have and contribute patches (or even just detailed reports) if they find bugs in the code. If, however, you want to run FreeBSD in production... well, there's a reason for those defaults. Building the base system with a compiler that can't build the C++ stack that ports expects for FreeBSD 10 or 11 on i386, for example, is going to make your life exciting... It's called portability and allows one to find bugs that the annointed compiler might miss or actually cause. And, more importantly, it helps determine whether bugs are bugs in the compiler or in the code that they're compiling. Being able to say that a bug goes away with one compiler gives you a good hint that it's a compiler bug. Or something in the source code that relies on undefined behaviour... But all of that is irrelevant to this bug report, so perhaps we can end this digression. Unless, of course, you can reproduce this failure and would like to help fix it, in which case I'd be very grateful for your assistance. David ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gcc compilation broken with SVN r264042
On Wed, Apr 02, 2014 at 09:46:19PM +0100, David Chisnall wrote: On 2 Apr 2014, at 21:21, Steve Kargl s...@troutmask.apl.washington.edu wrote: Who is we in even if we don't encourage it...? We is the FreeBSD project, collectively. For a larger list of things that we recommend, There is a significant difference between we recommend and we don't encourage. In fact, this is a fairly dumb idea, Having a recommended compiler is a dumb idea? Having a recommended compiler is fine. Actively discouraging the use of other compilers is a dumb idea. and *we* should encourage building the base system with as many different compilers as possible. I didn't say otherwise, Ah, yes you did. Here's the complete quote (with context): butler I guess it's time for me to migrate that box to clang :-) you Well, I wouldn't object to that, but it would be good to fix this - we still want to be able to build the base system with gcc (or another compiler), even if we don't encourage it... You are actively discouraging the use of gcc (or another compiler). How else is one to interpret the last 5 word + 1 contraction in your above quote? If you're developing FreeBSD or testing, then please compile with as many other compilers as you have and contribute patches I do development on libm (as you know!). I test with clang and base system gcc on i386, amd64, and sparc64. In the past, I also used pcc and newer versions of gcc to do some libm testing. (or even just detailed reports) if they find bugs in the code. I do report problems with the compilers, but they are typically ignored. http://lists.freebsd.org/pipermail/freebsd-toolchain/2014-March/001147.html You can also read some follow-up analysis here: http://lists.freebsd.org/pipermail/freebsd-numerics/2014-March/000549.html -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gcc compilation broken with SVN r264042
On Apr 2, 2014, at 1:15 PM, Michael Butler i...@protected-networks.net wrote: /usr/src/lib/libc/stdlib/atexit.c: In function 'atexit_b': /usr/src/lib/libc/stdlib/atexit.c:157: error: cannot convert to a pointer type *** Error code 1 This also breaks mips*, sparc64, armeb and ia64. I’ve seen the carping about discouraging using gcc on i386, but this isn’t even an edge case. Our simple, default build is broken for many platforms. Sure looks like a universe wasn’t done before it was committed. So less carping and more fixing is needed here. Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
