Re: svn commit: r325320 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs [breaks lld on zfs: lld uses fallocate]
On 04/11/2017 13:58, Ed Maste wrote: > I have no idea how they decided EINVAL was a reasonable errno for this case. I completely agree. That's a weird choice that I have not seen for any other API. -- Andriy Gapon ___ 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: svn commit: r325320 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs [breaks lld on zfs: lld uses fallocate]
On 04/11/2017 13:41, Andriy Gapon wrote:
> On 04/11/2017 12:32, Mark Millard wrote:
>> if (int Err = ::posix_fallocate(FD, 0, Size)) {
>> if (Err != EOPNOTSUPP)
>> return std::error_code(Err, std::generic_category());
>> }
>
> The commit message that you didn't include into your reply contains some
> useful
> information that authors / maintainers of this code should probably take into
> account:
>
>> Please note that EINVAL is used to report that the underlying file system
>> does not support the operation (POSIX.1-2008).
>
> Here is a link for that:
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_fallocate.html
>
My response above is quite dry, so I want to add this.
Thank you very much for the deep analysis.
I am sorry for the trouble that my change caused, but I think that its root
cause lies elsewhere (lld, posix).
--
Andriy Gapon
___
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: svn commit: r325320 - head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs [breaks lld on zfs: lld uses fallocate]
On 04/11/2017 12:32, Mark Millard wrote:
> if (int Err = ::posix_fallocate(FD, 0, Size)) {
> if (Err != EOPNOTSUPP)
> return std::error_code(Err, std::generic_category());
> }
The commit message that you didn't include into your reply contains some useful
information that authors / maintainers of this code should probably take into
account:
> Please note that EINVAL is used to report that the underlying file system
> does not support the operation (POSIX.1-2008).
Here is a link for that:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_fallocate.html
--
Andriy Gapon
___
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"
kernel-toolchain fails in stable/9 build on head
$ make kernel-toolchain ... ===> gnu/usr.bin/cc/cc_tools (depend) make[4]: "/usr/devel/svn/stable/9/share/mk/bsd.own.mk" line 233: warning: unsetting WITH_CTF cc -O2 -pipe -O2 -fno-strict-aliasing -pipe -fno-omit-frame-pointer -I. -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/obj/usr/devel/svn/stable/9/tmp/usr\" -I/usr/obj/usr/devel/svn/stable/9/tmp/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -g -std=gnu89 -I/usr/obj/usr/devel/svn/stable/9/tmp/legacy/usr/include -static -L/usr/obj/usr/devel/svn/stable/9/tmp/legacy/usr/lib -o genattrtab genattrtab.o rtl.o read-rtl.o ggc-none.o vec.o min-insn-modes.o gensupport.o print-rtl.o errors.o libiberty.a -lm print-rtl.o: In function `print_rtx': /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:287: undefined reference to `dump_addr' /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:533: undefined reference to `bitmap_print' /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:268: undefined reference to `print_node_brief' /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:540: undefined reference to `dump_addr' /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:415: undefined reference to `insn_file' /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:416: undefined reference to `insn_file' /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:416: undefined reference to `insn_line' /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:434: undefined reference to `reg_names' /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:588: undefined reference to `real_to_decimal' /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:592: undefined reference to `real_to_hexadecimal' /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:573: undefined reference to `mode_size' /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:575: undefined reference to `mode_size' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 -- Andriy Gapon ___ 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: kernel-toolchain fails in stable/9 build on head
[sorry for top-posting *again*] Just for the records, doing `make make` and then using the resulting make binary seems to have solved the problems. On 23/10/2015 13:27, Andriy Gapon wrote: > > Oh, hrrm: > > --- libbackend.a --- > building static backend library > nm: 'print-rtl.o': No such file or directory > nm: 'rtl.o': No such file or directory > nm: 'vec.o': No such file or directory > ar: warning: can't open file: vec.o: No such file or directory > ar: warning: can't open file: rtl.o: No such file or directory > ar: warning: can't open file: print-rtl.o: No such file or directory > ranlib libbackend.a > > That's with -j4 during another attempt to build the same target. > > On 23/10/2015 12:46, Andriy Gapon wrote: >> >> $ make kernel-toolchain >> ... >> ===> gnu/usr.bin/cc/cc_tools (depend) >> make[4]: "/usr/devel/svn/stable/9/share/mk/bsd.own.mk" line 233: warning: >> unsetting WITH_CTF >> cc -O2 -pipe -O2 -fno-strict-aliasing -pipe -fno-omit-frame-pointer -I. >> -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H >> -DPREFIX=\"/usr/obj/usr/devel/svn/stable/9/tmp/usr\" >> -I/usr/obj/usr/devel/svn/stable/9/tmp/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../cc_tools >> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../cc_tools >> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc >> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config >> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include >> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include >> -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber >> -g -DGENERATOR_FILE -DHAVE_CONFIG_H -g -std=gnu89 >> -I/usr/obj/usr/devel/svn/stable/9/tmp/legacy/usr/include -static >> -L/usr/obj/usr/devel/svn/stable/9/tmp/legacy/usr/lib -o genattrtab >> genattrtab.o >> rtl.o read-rtl.o ggc-none.o vec.o min-insn-modes.o gensupport.o print-rtl.o >> errors.o libiberty.a -lm >> print-rtl.o: In function `print_rtx': >> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:287: >> undefined reference to `dump_addr' >> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:533: >> undefined reference to `bitmap_print' >> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:268: >> undefined reference to `print_node_brief' >> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:540: >> undefined reference to `dump_addr' >> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:415: >> undefined reference to `insn_file' >> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:416: >> undefined reference to `insn_file' >> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:416: >> undefined reference to `insn_line' >> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:434: >> undefined reference to `reg_names' >> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:588: >> undefined reference to `real_to_decimal' >> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:592: >> undefined reference to `real_to_hexadecimal' >> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:573: >> undefined reference to `mode_size' >> /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:575: >> undefined reference to `mode_size' >> cc: error: linker command failed with exit code 1 (use -v to see invocation) >> *** Error code 1 >> > > -- Andriy Gapon ___ 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: kernel-toolchain fails in stable/9 build on head
Oh, hrrm: --- libbackend.a --- building static backend library nm: 'print-rtl.o': No such file or directory nm: 'rtl.o': No such file or directory nm: 'vec.o': No such file or directory ar: warning: can't open file: vec.o: No such file or directory ar: warning: can't open file: rtl.o: No such file or directory ar: warning: can't open file: print-rtl.o: No such file or directory ranlib libbackend.a That's with -j4 during another attempt to build the same target. On 23/10/2015 12:46, Andriy Gapon wrote: > > $ make kernel-toolchain > ... > ===> gnu/usr.bin/cc/cc_tools (depend) > make[4]: "/usr/devel/svn/stable/9/share/mk/bsd.own.mk" line 233: warning: > unsetting WITH_CTF > cc -O2 -pipe -O2 -fno-strict-aliasing -pipe -fno-omit-frame-pointer -I. > -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H > -DPREFIX=\"/usr/obj/usr/devel/svn/stable/9/tmp/usr\" > -I/usr/obj/usr/devel/svn/stable/9/tmp/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../cc_tools > -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../cc_tools > -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc > -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config > -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include > -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include > -I/usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber > -g -DGENERATOR_FILE -DHAVE_CONFIG_H -g -std=gnu89 > -I/usr/obj/usr/devel/svn/stable/9/tmp/legacy/usr/include -static > -L/usr/obj/usr/devel/svn/stable/9/tmp/legacy/usr/lib -o genattrtab > genattrtab.o > rtl.o read-rtl.o ggc-none.o vec.o min-insn-modes.o gensupport.o print-rtl.o > errors.o libiberty.a -lm > print-rtl.o: In function `print_rtx': > /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:287: > undefined reference to `dump_addr' > /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:533: > undefined reference to `bitmap_print' > /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:268: > undefined reference to `print_node_brief' > /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:540: > undefined reference to `dump_addr' > /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:415: > undefined reference to `insn_file' > /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:416: > undefined reference to `insn_file' > /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:416: > undefined reference to `insn_line' > /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:434: > undefined reference to `reg_names' > /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:588: > undefined reference to `real_to_decimal' > /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:592: > undefined reference to `real_to_hexadecimal' > /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:573: > undefined reference to `mode_size' > /usr/devel/svn/stable/9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:575: > undefined reference to `mode_size' > cc: error: linker command failed with exit code 1 (use -v to see invocation) > *** Error code 1 > -- Andriy Gapon ___ 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"
clang confuses kgdb on static symbols
I see exactly the same behavior both kgdb and kgdb710 (devel/gdb with KGDB option): (kgdb) p/x intr_cpus No symbol "intr_cpus" in current context. (kgdb) p/x 'intr_cpus.0' $1 = 0xf Not sure if clang should try to not produce that '.0' suffix (especially given that there are no other intr_cpus symbols) or if kgdb should somehow figure out the suffix. -- Andriy Gapon ___ 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: WITH_CTF vs -g
On 26/09/2014 01:51, Mark Johnston wrote:
On Wed, Sep 10, 2014 at 08:23:21PM +0300, Andriy Gapon wrote:
In my opinion WITH_CTF should imply -g in CFLAGS otherwise, as far as I can
see,
there is nothing to generate CTF data from. Forcing an end-user to remember
to
additionally pass -g is not nice.
Also, I think that we can always have -g in CTFFLAGS, because the stripping
step
takes care of the original DWARF data in any case. But I am not 100% sure
about
this.
What do you think?
Thanks!
Hi Andriy,
Are you planning to go through with this? I was just about to post this
exact question, but then I remembered that you already have. :)
FWIW, the diff I have in mind is below. It also removes some checks that
I think are unnecessary from bsd.{lib,prog}.mk. It is not fully tested,
but seems to work for me. I'm also not sure about unconditionally
passing -g to ctfconvert and ctfmerge.
Mark,
your change looks like what I was thinking of.
I will it a whirl here.
Thank you!
diff --git a/share/mk/bsd.lib.mk b/share/mk/bsd.lib.mk
index f0acf16..c6b689d 100644
--- a/share/mk/bsd.lib.mk
+++ b/share/mk/bsd.lib.mk
@@ -36,7 +36,7 @@ NO_WERROR=
.if defined(DEBUG_FLAGS)
CFLAGS+= ${DEBUG_FLAGS}
-.if ${MK_CTF} != no ${DEBUG_FLAGS:M-g} !=
+.if ${MK_CTF} != no
CTFFLAGS+= -g
.endif
.else
diff --git a/share/mk/bsd.own.mk b/share/mk/bsd.own.mk
index 486914b..32556a1 100644
--- a/share/mk/bsd.own.mk
+++ b/share/mk/bsd.own.mk
@@ -128,6 +128,7 @@ __bsd.own.mk__:
.if ${MK_CTF} != no
CTFCONVERT_CMD= ${CTFCONVERT} ${CTFFLAGS} ${.TARGET}
+DEBUG_FLAGS?=-g
.elif defined(.PARSEDIR) || (defined(MAKE_VERSION) ${MAKE_VERSION} =
520300)
CTFCONVERT_CMD=
.else
diff --git a/share/mk/bsd.prog.mk b/share/mk/bsd.prog.mk
index 340950a..e4f7104 100644
--- a/share/mk/bsd.prog.mk
+++ b/share/mk/bsd.prog.mk
@@ -20,7 +20,7 @@ NO_WERROR=
CFLAGS+=${DEBUG_FLAGS}
CXXFLAGS+=${DEBUG_FLAGS}
-.if ${MK_CTF} != no ${DEBUG_FLAGS:M-g} !=
+.if ${MK_CTF} != no
CTFFLAGS+= -g
.endif
.endif
--
Andriy Gapon
___
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: Is this a compiler bug?
On 22/09/2014 05:20, Rui Paulo wrote:
On Sep 21, 2014, at 18:48, Steve Kargl s...@troutmask.apl.washington.edu
wrote:
On Sun, Sep 21, 2014 at 06:38:48PM -0700, Rui Paulo wrote:
On Sep 21, 2014, at 18:19, Steve Kargl s...@troutmask.apl.washington.edu
wrote:
#include stdio.h
#include stdint.h
int
main(void)
{
uint16_t i;
i = 0x3ff0+63; printf(%x\n, i);
i = 0x3ff1+63; printf(%x\n, i);
i = 0x3ff2+63; printf(%x\n, i);
i = 0x3ff3+63; printf(%x\n, i);
i = 0x3ff4+63; printf(%x\n, i);
i = 0x3ff4+63; printf(%x\n, i);
i = 0x3ff6+63; printf(%x\n, i);
i = 0x3ff7+63; printf(%x\n, i);
i = 0x3ff8+63; printf(%x\n, i);
i = 0x3ff9+63; printf(%x\n, i);
i = 0x3ffa+63; printf(%x\n, i);
i = 0x3ffb+63; printf(%x\n, i);
i = 0x3ffc+63; printf(%x\n, i);
i = 0x3ffd+63; printf(%x\n, i);
i = 0x3ffe+63; printf(%x\n, i);
i = 0x3fff+63; printf(%x\n, i);
return 0;
}
Looks like it. Please file a bug report with LLVM.
Unfortunately, llvm requires an account to report bugs.
I think I know what's happening: e is being parsed as scientific notation.
Interesting! One of the cases where the whitespace matters?
--
Andriy Gapon
___
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
stable/8 kernel-toolchain fails with clang on head
$ /usr/obj/usr/devel/svn/base/stable/8/make.amd64/make kernel-toolchain WITHOUT_CLANG=1 __MAKE_CONF=/dev/null SRCCONF=/dev/null ... cc -O2 -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr/obj/usr/devel/svn/base/stable/8/tmp/usr\ -I/usr/obj/usr/devel/svn/base/stable/8/tmp/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/config -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/include -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libcpp/include -I/usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcclibs/libdecnumber -I/usr/obj/usr/devel/svn/base/stable/8/tmp/legacy/usr/include -DTARGET_NAME=\amd64-undermydesk-freebsd\ -c /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.c In file included from /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.c:58: /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/output.h:123:6: warning: 'format' attribute argument not supported: __asm_fprintf__ [-Wignored-attributes] ATTRIBUTE_ASM_FPRINTF(2, 3); ^ /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/output.h:113:53: note: expanded from macro 'ATTRIBUTE_ASM_FPRINTF' #define ATTRIBUTE_ASM_FPRINTF(m, n) __attribute__ ((__format__ (__asm_fprintf__, m, n))) ATTRIBUTE_NONNULL(m) ^ /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.c:542:1: error: redefinition of a 'extern inline' function 'floor_log2' is not supported in C99 mode floor_log2 (unsigned HOST_WIDE_INT x) ^ /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.h:174:1: note: previous definition is here floor_log2 (unsigned HOST_WIDE_INT x) ^ /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.c:577:1: error: redefinition of a 'extern inline' function 'exact_log2' is not supported in C99 mode exact_log2 (unsigned HOST_WIDE_INT x) ^ /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/toplev.h:180:1: note: previous definition is here exact_log2 (unsigned HOST_WIDE_INT x) ^ 1 warning and 2 errors generated. *** Error code 1 Stop in /usr/devel/svn/base/stable/8/gnu/usr.bin/cc/cc_int. It seems that the problem is specific to stable/8 and is caused by missing -std=gnu89. And that seems to be caused by -DNO_WARNS that is used for toolchain target. Dependency between NO_WARNS and CSTD was removed in r198335 + r198365, but those were never MFC-ed. What do you think? -- Andriy Gapon ___ 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: patch to add AES intrinsics to gcc
on 23/08/2013 14:06 David Chisnall said the following: Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its atomic generation so you can't use it sensibly without lots of inline assembly (which it doesn't support for newer architectures) for multithreaded things. Our libstdc++ is ancient and doesn't work with modern C++ codebases. On the other hand these tools are perfect for building FreeBSD kernel and base. Extrapolating my experience with base GCC I am very confident in it as a FreeBSD development tool. Extrapolating my experience with Clang I am not yet confident in it as a FreeBSD development tool. I do not care about C11, C++11 and modern C++ codebases. I care about what's in /usr/src and what gets compiled by buildkernel/buildworld. That's just me, of course. But, OTOH, those who care modern C++ codebases should be perfectly capable to install a compiler from ports or switch to clang as their default compiler. -- Andriy Gapon ___ 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: patch to add AES intrinsics to gcc
on 23/08/2013 15:34 Nathan Whitehorn said the following: On 08/23/13 07:26, Andriy Gapon wrote: on 23/08/2013 14:06 David Chisnall said the following: Our gcc is from 2007. It has no C11, no C++11 support. It has bugs in its atomic generation so you can't use it sensibly without lots of inline assembly (which it doesn't support for newer architectures) for multithreaded things. Our libstdc++ is ancient and doesn't work with modern C++ codebases. On the other hand these tools are perfect for building FreeBSD kernel and base. Extrapolating my experience with base GCC I am very confident in it as a FreeBSD development tool. Extrapolating my experience with Clang I am not yet confident in it as a FreeBSD development tool. This isn't even true. It's been true for me. As CPUs gain new features, the set of available intrinsics gets more and more ancient, requiring ever more patching, workarounds, and #ifdef. Just look at the original subject of this thread! Yes. I am more comfortable with incremental changes. Bugs in those can be pinpointed quite easily and I do not affect those who don't use the new features. We're just talking about the default of a make.conf setting here. Switching to clang is a long-term goal of the project for good reason. I agree. Other vendors (Apple, for instance) have made the plunge first. This seems like as good a time as any to do it. And if it goes wrong somehow, we have lots of BETAs and it is trivial to change back at any time. I am totally comfortable with clang being default in head. I am also comfortable with gcc not being built by default in head. I am not yet comfortable with clang being default in a release. Even .0 one. JIMHO, it needs to age a little bit more. -- Andriy Gapon ___ 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: strange stable/9 buildworld failure
on 11/07/2013 23:07 Dimitry Andric said the following: On Jul 11, 2013, at 19:19, Andriy Gapon a...@freebsd.org wrote: on 11/07/2013 19:43 Andriy Gapon said the following: buildword was run as make -j8 buildworld and the it mysteriously failed like this: sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 liblwres.so.80 /usr/obj/usr/src/tmp/usr/lib sh /usr/src/tools/install.sh -l s liblwres.so.80 /usr/obj/usr/src/tmp/usr/lib/liblwres.so 1 error *** [libraries] Error code 2 I could not find any actual error message in the build log. /usr/obj was cleaned out before the build. I was able to reproduce this exact failure 3 times in a row. Running buildworld without -j allowed the build to proceed further. Please note that my current userland is at (quite old) r248369, also stable/9. Hi Andriy, Can you please post the complete build log somewhere? Maybe there is something unexpected going wrong which does not show a clear error message? Sorry for the noise, all, it was a pilot error indeed. -- Andriy Gapon ___ 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
strange stable/9 buildworld failure
buildword was run as make -j8 buildworld and the it mysteriously failed like this: sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 liblwres.so.80 /usr/obj/usr/src/tmp/usr/lib sh /usr/src/tools/install.sh -l s liblwres.so.80 /usr/obj/usr/src/tmp/usr/lib/liblwres.so 1 error *** [libraries] Error code 2 I could not find any actual error message in the build log. /usr/obj was cleaned out before the build. -- Andriy Gapon ___ 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: new make vs security/vpnc
on 09/07/2013 10:25 Tijl Coosemans said the following: On 2013-07-09 00:05, Andriy Gapon wrote: Seems like the problem boils down to this: $ make -V MAKEFILE /usr/ports/security/vpnc/Makefile $ fmake -V MAKEFILE Makefile The only explicit assignments of MAKEFILE that I could find in ports infrastructure are these: /usr/ports/Mk/bsd.port.mk:MAKEFILE?= Makefile /usr/ports/Mk/bsd.gnustep.mk:MAKEFILE= GNUmakefile The problem is probably that .OBJDIR (/usr/obj/usr/ports/security/vpnc) exists. Bmake assigns an absolute path to MAKEFILE in that case. Bingo! I use WRKDIRPREFIX=/usr/obj/*ports*, so i am not sure how /usr/obj/usr/ports/security/vpnc came to exist. A timestamp on it is 1 year old, so I won't be able to recall now. Thank you! MAKEFILE is an internal variable of make and bsd.port.mk uses it for another purpose. It should use another name like MAKE_FILE imho. I agree. -- Andriy Gapon ___ 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: new make vs security/vpnc
Seems like the problem boils down to this: $ make -V MAKEFILE /usr/ports/security/vpnc/Makefile $ fmake -V MAKEFILE Makefile The only explicit assignments of MAKEFILE that I could find in ports infrastructure are these: /usr/ports/Mk/bsd.port.mk:MAKEFILE?=Makefile /usr/ports/Mk/bsd.gnustep.mk:MAKEFILE= GNUmakefile -- Andriy Gapon ___ 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: [CFT] gcc: support for barcelona
on 28/05/2013 21:10 David Chisnall said the following: On 28 May 2013, at 18:40, Warner Losh i...@bsdimp.com wrote: That's not going to happen soon. While it works OK for amd64, there's still many bugs in its ARM support and even more in its MIPS support. There's 0 chance it will be gone in 10... I disagree. There is a significant chance that gcc in base will be gone for all Tier 1 platforms in 10.0. There are still some reasons to want gcc installed, but there are no compelling reasons to want an ancient version of gcc installed on x86[-64] or ARM. For people who need gcc, the ports collection provides a selection of recent versions. I will try to veto any attempt to do so until at least this bug is fixed: http://llvm.org/bugs/show_bug.cgi?id=15662 I am sure that other developers have their favorite bugs too. In fact, I am of opinion that while such bugs exist gcc should be crowned back as a default compiler. -- Andriy Gapon ___ 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: -mno-omit-leaf-frame-pointer
It seems that, unlike gcc, for clang -fno-omit-frame-pointer does not imply
-mno-omit-leaf-frame-pointer. This is probably a bug.
Meanwhile I would like to propose the following amd64-specific patch. Perhaps
the same type of change would be useful for powerpc as well.
I would like this change primarily for DTrace (fbt), but other
debugging/profiling code may benefit from it as well.
I chose to make -mno-omit-leaf-frame-pointer not conditional on clang, because
with gcc it is just a nop (i.e. it doesn't hurt anything).
--- a/sys/conf/Makefile.amd64
+++ b/sys/conf/Makefile.amd64
@@ -32,7 +32,7 @@ S=../../..
.include $S/conf/kern.pre.mk
.if !empty(DDB_ENABLED) || !empty(DTR_ENABLED) || !empty(HWPMC_ENABLED)
-CFLAGS+= -fno-omit-frame-pointer
+CFLAGS+= -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
.endif
MKMODULESENV+= MACHINE=amd64
diff --git a/sys/conf/kmod.mk b/sys/conf/kmod.mk
index f0d3d4d..7eaba85 100644
--- a/sys/conf/kmod.mk
+++ b/sys/conf/kmod.mk
@@ -122,7 +122,7 @@ LDFLAGS+= -d -warn-common
CFLAGS+= ${DEBUG_FLAGS}
.if ${MACHINE_CPUARCH} == amd64
-CFLAGS+= -fno-omit-frame-pointer
+CFLAGS+= -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer
.endif
.if ${MACHINE_CPUARCH} == powerpc
--
Andriy Gapon
___
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
libdwarf
It seems that our in-tree libdwarf is not used for anything besides ctf manipulation tools (for dtrace support). I just would like to double-check that this is so. Thank you. -- Andriy Gapon ___ 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: base gcc and _GLIBCXX_USE_C99
[ping] on 28/01/2013 17:11 Andriy Gapon said the following: Guys, I wonder why the following is the case for the base gcc. /usr/include/c++/4.2/bits/c++config.h: /* Define if C99 functions or macros from wchar.h, math.h, complex.h, stdio.h, and stdlib.h can be used or exposed. */ /* #undef _GLIBCXX_USE_C99 */ Because of this undef there is no e.g. std::strtoll(). Ditto for other things in stdlib.h. -- Andriy Gapon ___ 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: base gcc and _GLIBCXX_USE_C99
on 01/02/2013 15:08 Dimitry Andric said the following: On 2013-02-01 14:01, Andriy Gapon wrote: on 28/01/2013 17:11 Andriy Gapon said the following: I wonder why the following is the case for the base gcc. /usr/include/c++/4.2/bits/c++config.h: /* Define if C99 functions or macros from wchar.h, math.h, complex.h, stdio.h, and stdlib.h can be used or exposed. */ /* #undef _GLIBCXX_USE_C99 */ Because of this undef there is no e.g. std::strtoll(). Ditto for other things in stdlib.h. Maybe this support can't be enabled, because we don't expose all the required functions yet? Or maybe it is just something that was committed years ago, and then forgotten. If we are sure that all the C99 functions libstdc++ requires are now available and working, I see no problem in turning on _GLIBCXX_USE_C99. Having looked into the source code of a recent GCC I get an impression that this is a silliness on GCC's part (plus incompleteness of FreeBSD C99 support, it seems). cstdlib would provide e.g. std::strtoull only when _GLIBCXX_USE_C99 is defined. Now looking at libstdc++-v3/acinclude.m4 we can see that there is a dedicated check for ISO C99 support in stdlib.h. That check sets variable glibcxx_cv_c99_stdlib. But, _GLIBCXX_USE_C99 is set only if all of glibcxx_cv_c99_math, glibcxx_cv_c99_complex, glibcxx_cv_c99_stdio, glibcxx_cv_c99_stdlib and glibcxx_cv_c99_wchar are set. So if glibcxx_cv_c99_stdlib is yes, but something like glibcxx_cv_c99_complex is no, then no std::strtoull for me. Not sure why GCC couldn't have a dedicated macro _GLIBCXX_USE_C99_STDLIB like e.g. _GLIBCXX_USE_C99_MATH that it does have. -- Andriy Gapon ___ 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: Removing default build of gcc
on 25/01/2013 21:35 Warner Losh said the following: This has been talked about in a vague way for years. Warner, just a nitpick, couldn't resist - sorry, so for years we talked about the magic 10.x release to become GPL-free? Or was it just a goal for 'some day'? -- Andriy Gapon ___ 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: gcc46 header search path
on 06/07/2012 18:10 Warner Losh said the following:
I think it shouldn't be there. It is non-standard behavior both in the gcc
world and in the freebsd world. It does save a little on makefiles on some
ports, but most ports already grok things are in /usr/local or opt/local and
cope.
Please define the non-standard behavior. Just curious if you opened the link.
On Jul 6, 2012, at 6:34 AM, Andriy Gapon wrote:
Inviting wider audience to the discussion.
Original Message
Date: Fri, 06 Jul 2012 00:43:58 +0300
From: Andriy Gapon a...@freebsd.org
Subject: Re: gcc46 header search path
on 05/07/2012 17:15 Andriy Gapon said the following:
Gerald,
while thinking what to reply in our other conversation I ran into another
issue
with gcc46:
$ echo | cpp46 -v
[trim]
#include ... search starts here:
#include ... search starts here:
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd10.0/4.6.3/include
/usr/local/include
/usr/local/lib/gcc46/gcc/x86_64-portbld-freebsd10.0/4.6.3/include-fixed
/usr/include
End of search list.
[trim]
I don't think that /usr/local/include should automagically appear in the
search
list. Base gcc doesn't have it and there doesn't seem to be a good reason
to
include arbitrary non-system directory into the default search path.
On the other hand the above seems to match the default upstream behavior as
described here: http://gcc.gnu.org/onlinedocs/cpp/Search-Path.html
It's understandable that such a difference between the base gcc compiler and
gcc
compilers from ports introduces subtle issues to ports.
I am now confused and torn as to which behavior should be preferable.
On one hand it's easier to patch the port gcc-s to match the base one.
On the other hand the default gcc behavior would save many lines in port
makefiles that explicitly add -I ${LOCALBASE}/include or some such to CFLAGS.
buildworld and buildkernel (and etc) could be spared from any interference
from
/usr/local by using -nostdinc and explicitly setting all necessary include
paths.
Adding more people to conversation in hope that it could become fruitful.
--
Andriy Gapon
___
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
--
Andriy Gapon
___
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: gcc46 header search path
on 06/07/2012 19:21 Warner Losh said the following: I didn't, because I know the standard behavior. Turns out, I don't know today's standard behavior, just the historical behavior of gcc, which has changed over the life of FreeBSD. FreeBSD's standard compiler has never included it. There was talk about 10 years ago about adding it, but it was shouted down as a stupid idea. I tend to agree, but I can't articulate good reasons. Yeah. Honestly speaking I myself was not aware of what is written in that link and I thought that our gcc ports (from ports) added /usr/local/include to the default search path by some mistake. And if somebody asked me what I thought about the idea of adding /usr/local/include to the default path, I'd say that it was a stupid idea. But then I discovered that information. And verified that even Linux distributions that have zero files under /usr/local still keep the upstream behavior. So now I am thinking in opposite direction: do we have a strong enough reason to deviate from the default upstream behavior in this case. My main motivation is to keep behavior of base gcc and gcc-s from ports as close as possible (but no closer) to avoid such hidden gems when using the compilers interchangeably to build our ports tree. -- Andriy Gapon ___ 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: gcc46 header search path
on 06/07/2012 22:11 David Chisnall said the following: On 6 Jul 2012, at 17:54, Andriy Gapon wrote: Yeah. Honestly speaking I myself was not aware of what is written in that link and I thought that our gcc ports (from ports) added /usr/local/include to the default search path by some mistake. And if somebody asked me what I thought about the idea of adding /usr/local/include to the default path, I'd say that it was a stupid idea. Why? The number one question I get from developers new FreeBSD is 'I wanted to use libfoo from ports, I stalled it, and now [gcc,clang] doesn't find the headers, why not?' No one has yet provided me with a sane reason why our system compiler would not look in the standard locations where we install headers and libraries. Running configure scripts on FreeBSD is a colossal pain because of this - you often need to explicitly say -with-foo-include=/usr/local/include -with-foo-lib=/usr/local/lib for an arbitrary number of values of foo, depending on the library. Please, please, please, can we put our standard library and header paths in the compiler standard header or library paths, or can someone give me a good reason other than 'it's a stupid idea' why we should force every single program that anyone compiles on FreeBSD to do CFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib? I think that this is a dummy argument. One could easily want his LOCALBASE to be /opt and the real ports system should support that. So what ports currently do, they really have to do (assuming $LOCALBASE as opposed to /usr/local). So, repeating myself for Nth time, the real question is whether we have any good reason to deviate from upstream's default behavior. Nothing less, nothing more, IMO. -- Andriy Gapon ___ 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
