Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
Pasi Parviainen writes: > On 13.7.2013 13:12, David Chisnall wrote: >> On 12 Jul 2013, at 22:47, "O. Hartmann" wrote: >> >>> Obviously not really fixed, but even worse: >>> >>> if I use in C code (C99, using clang 3.3 on FreeBSD 10.0-CURRENT/amd64 >>> revision 253287) isnan(x) where x is a "const double", I receive now >>> the following error (which doesn't appear on previous versions): >> >> Thanks. This is now fixed, however the _Generic() usage that we had there >> is also present in tgmath.h, and so this file will also need to be fixed in >> the same way. >> >> I've now tested the macros with clang/c99, clang/c11, clang/c++98 and >> clang/c++11, and gcc/c89 and they all seem to work for unqualified, const, >> volatile, and const-volatile qualified types. >> >> I've added Ed to the cc: list, as he wrote this code in tgmath.h. >> >> David >> > > Instead of listing all possible type qualifier combinations (like in > r253319), how about using a comma operator to strip away type > qualifiers? Since only the result type of the expression matters and > it isn't evaluated at all. > > like: > > #define __fp_type_select(x, f, d, ld) _Generic((0,(x)), This seems to have been committed in r253321, and broke some code that was working with r253320; namely, some code in x11/kde4-workspace includes math.h and calls isnan() with a const double. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
David Chisnall writes: > On 28 Jul 2013, at 22:27, Raphael Kubo da Costa wrote: > >> This seems to have been committed in r253321, and broke some code that >> was working with r253320; namely, some code in x11/kde4-workspace >> includes math.h and calls isnan() with a const double. > > Please provide a test case. Specifically, I need to know what > language dialect this is using, because I have tested including math.h > and calling isnan(double) with c89, gnu89, c99, c11, c++03 and c++11 > on gcc (for the modes that it supports) and clang. I get the following results with and without -std=c++11 and/or -stdlib=libc++: % cat isnan.cc #include int main() { const double d = 42.0; return isnan(d) ? 1 : 0; } % clang++ isnan.cc isnan.cc:4:10: error: controlling expression type 'const double' not compatible with any generic association type return isnan(d) ? 1 : 0; ^~~~ /usr/include/math.h:109:2: note: expanded from macro 'isnan' __fp_type_select(x, __inline_isnanf, __inline_isnan, __inline_isnanl) ^ /usr/include/math.h:86:49: note: expanded from macro '__fp_type_select' #define __fp_type_select(x, f, d, ld) _Generic((0,(x)), \ ^ 1 error generated. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CURRENT: CLANG 3.3 and -stad=c++11 and -stdlib=libc++: isnan()/isninf() oddity
Raphael Kubo da Costa writes: > This seems to have been committed in r253321, and broke some code that > was working with r253320; namely, some code in x11/kde4-workspace > includes math.h and calls isnan() with a const double. For posterity, David has reverted the code back to the previous behaviour in r253766. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
clang -pg, libm and the _end symbol
I'm reviewing an update to the textproc/miller port in bug 207194, and noticed it does some ugly things in post-configure to seemingly work around the following problem (on 11-HEAD at least): % echo 'int main(void) { return 0; }' > foo.c % clang -pg foo.c -lm /usr/bin/ld: undefined reference to symbol `_end' (try adding -lc) //lib/libc.so.7: could not read symbols: Bad value cc: error: linker command failed with exit code 1 (use -v to see invocation) (FWIW, using another library such as -lz instead of -lm retuls in the same problem) Adding LDFLAGS+=-lc to the port's Makefile would've been enough, but I'm not sure if it'd be just working around an actual bug, plus libtool automatically strips -lc from the linker invocation: 7534 *-*-openbsd* | *-*-freebsd* | *-*-dragonfly* | *-*-bitrig*) 7535 # Do not include libc due to us having libc/libc_r. 7536 test X-lc = "X$arg" && continue The port builds and links fine on 9.3 without any workarounds, and if I explicitly use ld.gold to link the above file it also works on HEAD. Is clang working as expected or is this a bug? ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang -pg, libm and the _end symbol
Konstantin Belousov writes: > This is probably not a clang bug, but could be. More likely it is ld problem. > I do not want to dig into the issue, but I can provide you some points to > look at further. > > The _end symbol is magic, it is defined as the address of the last byte > + 1 of zero-initialized data section (.bss). But the symbol is not > provided by any object file participating in the linkage of the binary, > instead it is created by the linker after all sections are combined in > the segments and segments are laid out. > > The symbol is creation requested by the linker script, look at the > /usr/libdata/ldscripts for them, first line of the file contains > comment explaining which final binary format is served by the each > script. > > We are aware that binutils 2.25.1 ld for aarch64 has bug where _end is > not exported from executable, I was not able to track the bug. > > To diagnose your issue, look up which linker script is used for -pg > linking, look for the _end symbol there. If it is properly requested, > then the bug is in base linker. With and without -pg, the linker script being used is elf_x86_64_fbsd.xc ("Script for -z combreloc: combine and sort reloc sections"). It does contain an entry for _end: 182 _end = .; PROVIDE (end = .); lang/gcc with ld from devel/binutils also fails on HEAD: /usr/local/bin/ld: //usr/lib/libc_p.a(sbrk.po): undefined reference to symbol '_end' //lib/libc.so.7: error adding symbols: DSO missing from command line ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang -pg, libm and the _end symbol
Konstantin Belousov writes: > On Wed, Feb 24, 2016 at 01:54:25PM +0100, Dimitry Andric wrote: >> On 24 Feb 2016, at 12:27, Raphael Kubo da Costa wrote: >> > >> > I'm reviewing an update to the textproc/miller port in bug 207194, and >> > noticed it does some ugly things in post-configure to seemingly >> > work around the following problem (on 11-HEAD at least): >> > >> > % echo 'int main(void) { return 0; }' > foo.c >> > % clang -pg foo.c -lm >> > /usr/bin/ld: undefined reference to symbol `_end' (try adding -lc) >> > //lib/libc.so.7: could not read symbols: Bad value >> > cc: error: linker command failed with exit code 1 (use -v to see >> > invocation) >> >> Try using: clang -pg foo.c -lm_p >> >> That works for me (also with gcc). > > It probably not quite works, in the sense that it resolves _end to > something not correctly provided by libm_p.a. In other words, sbrk(), > if used for anything, would be broken. It at least "works" in the sense that clang doesn't fail; however, in addition to kib's point this doesn't look optimal from a ports perspective, as it requires giving special treatment to certain targets and possibly hacking the build system in different ports. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"