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"
