Re: Is it possible for freebsd 13 to update to LLVM 11.1.0?

[Dimitry Andric]

On 28 May 2021, at 08:39, YUANRUI  wrote:
> 
> Is it possible for freebsd 13 to update to LLVM 11.1.0?

There isn't much use in updating LLVM to 11.1.0, as this version only
fixes an LLVM ABI issue that is not important for us.

I am currently working on updating LLVM to 12.0.0 (and later 12.0.1 when
it comes out), but this will first land in FreeBSD 14. And maybe it will
be in 13.1.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Looking for std::map::erase_if

[Dimitry Andric]

Well, -std=c++20 even, it is that new. :)

That said, it's always hazardous to rely on experimental features, they are 
effectively unsupported.

As shown on e.g. cppreference.com, you can use an equivalent function that 
looks like:

auto old_size = c.size();
for (auto i = c.begin(), last = c.end(); i != last; ) {
  if (pred(*i)) {
i = c.erase(i);
  } else {
++i;
  }
}

-Dimitry

> On 20 Mar 2021, at 16:22, Alan Somers  wrote:
> 
> I'm just guessing, but I think you should remove the "experimental" and
> build with -std=c++17 .
> -Alan
> 
> On Sat, Mar 20, 2021 at 9:06 AM Willem Jan Withagen  wrote:
> 
>> On 20-3-2021 15:46, Alan Somers wrote:
>> 
>> It looks like it's in there.  What code are you trying that doesn't work?
>> 
>> Hi Alan,
>> 
>> I thought so too, but all tries last 2 weeks did not result into anything
>> that got it compiling...
>> But could be that I did not try hard enough, real work is pulling a lot
>> atm.
>> 
>> Code is at:
>> 
>> https://github.com/dillaman/ceph/blob/138d71fb0635682510cadda8e4ad5aaab3f39e44/src/librbd/api/Trash.cc#L299
>> 
>> Thanx,
>> --WjW
>> 
>> 
>>> grep erase_if  /usr/include/c++/v1/map
>>  void erase_if(map& c, Predicate pred);  //
>> C++20
>>  void erase_if(multimap& c, Predicate pred);
>> // C++20
>> void erase_if(map<_Key, _Tp, _Compare, _Allocator>& __c, _Predicate __pred)
>> { __libcpp_erase_if_container(__c, __pred); }
>> void erase_if(multimap<_Key, _Tp, _Compare, _Allocator>& __c, _Predicate
>> __pred)
>> { __libcpp_erase_if_container(__c, __pred); }
>> 
>> On Sat, Mar 20, 2021 at 8:39 AM Willem Jan Withagen via freebsd-hackers <
>> freebsd-hack...@freebsd.org> wrote:
>> 
>>> Hi,
>>> 
>>> [ Trying this on FBSD 12.2 ]
>>> 
>>> In the Ceph code new code uses std::map::erase_if.
>>> Which is in Linux imported from 
>>> 
>>> Anybody suggestions on libraries to get something matching??
>>> 
>>> Thanx,
>>> --WjW
>>> ___
>>> freebsd-hack...@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>>> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org
>>> "
>>> 
>> 
>> 
> ___
> 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"



signature.asc
Description: Message signed with OpenPGP

Re: clang options for load segments

[Dimitry Andric]

On 19 Feb 2021, at 15:18, Paul Floyd  wrote:
> 
> A while back when I upgraded to FreeBSD 12.2 (and thus to clang 10) I got 
> quite a new category of errors with Valgrind.
> 
> The problem is that the clang 10 toolchain produces two RW LOAD segments, for 
> instance see below. Valgrind assumes
> that there is only one, and ignores the second one which results in false 
> positives when reading PLTs. I've added a hack
> to make it seem like there is just one such segment, but it isn't 100% 
> reliable - there's at least one issue when loading
> shared libraries.

This changed in lld 9.0.0, with upstream r356226 (aka
https://github.com/llvm/llvm-project/commit/e8710ef1fbe8109eaa36143654f325dd345f8a0133
 )

commit e8710ef1fbe8109eaa36143654f325dd345f8a01
Author: Fangrui Song 
Date:   Fri Mar 15 01:29:57 2019 +

[ELF] Split RW PT_LOAD on the PT_GNU_RELRO boundary

Summary:
Based on Peter Collingbourne's suggestion in D56828.

Before D56828: PT_LOAD(.data PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) .bss)
Old:   PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro) .data .bss)
New:   PT_LOAD(PT_GNU_RELRO(.data.rel.ro .bss.rel.ro)) 
PT_LOAD(.data. .bss)

The new layout reflects the runtime memory mappings.
By having two PT_LOAD segments, we can utilize the NOBITS part of the
first PT_LOAD and save bytes for .bss.rel.ro.

.bss.rel.ro is currently small and only used by copy relocations of
symbols in read-only segments, but it can be used for other purposes in
the future, e.g. if a relro section's statically relocated data is all
zeros, we can move it to .bss.rel.ro.

Reviewers: espindola, ruiu, pcc

Reviewed By: ruiu

Subscribers: nemanjai, jvesely, nhaehnle, javed.absar, kbarton, emaste, 
arichardson, llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D58892

llvm-svn: 356226

In other words, this is shuffling the segments around a bit to achieve a
more optimal layout for relro.


> I will carry on looking for a proper solution. In the meantime, are there any 
> flags to revert to the previous behaviour
> and only generate a single RW LOAD segment?

I think valgrind should be fixed to able to cope with additional
segments, but I haven't seen valgrind working on FreeBSD for years now,
so I am not going to hold my breath. :)

That said, you can attempt to link your executables with -z norelro (or
-Wl,-z,norelro via the compiler driver). If there is no PT_GNU_RELRO
header, lld will not split the segments.

And of course, you can link with lld 8.0 if all else fails.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: devel/glib20 build issue

[Dimitry Andric]

On 9 Dec 2020, at 12:44, Kristof Provost  wrote:
> 
> On 19 Nov 2020, at 11:59, Dimitry Andric wrote:
>> On 19 Nov 2020, at 11:57, Kristof Provost  wrote:
...
> This https://reviews.llvm.org/D91784 got merged upstream. How do you feel 
> about cherry-picking that into our tree? (I can do it, or you can, I don’t 
> have feelings either way).
> 
> It’d fix building glib20 on RISC-V and unblock a bunch of ports. We’ll get it 
> eventually though the next LLVM update, but I’m impatient.

Cherry-picked in r368489. I will also MFC it, if possible.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: devel/glib20 build issue

[Dimitry Andric]

On 19 Nov 2020, at 11:57, Kristof Provost  wrote:
> 
> While trying to build assorted ports on RISC-V I found that devel/glib20 
> doesn’t build.
> It turns out to be due to a missing __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 
> define. That define is implicitly set by the toolchain. Or, at least, it is 
> on other platforms (ARM, MIPS, x86, …), but not on RISC-V.
> 
> That’s likely just been forgotten. The following toolchain patch fixes that 
> for me:
> 
>   diff --git a/contrib/llvm-project/clang/lib/Basic/Targets/RISCV.cpp 
> b/contrib/llvm-project/clang/lib/Basic/Targets/RISCV.cpp
>   index 4ba703c8dd1..73f1b5bc446 100644
>   --- a/contrib/llvm-project/clang/lib/Basic/Targets/RISCV.cpp
>   +++ b/contrib/llvm-project/clang/lib/Basic/Targets/RISCV.cpp
>   @@ -115,8 +115,14 @@ void RISCVTargetInfo::getTargetDefines(const 
> LangOptions ,
>Builder.defineMacro("__riscv_muldiv");
>  }
> 
>   -  if (HasA)
>   +  if (HasA) {
>Builder.defineMacro("__riscv_atomic");
>   +Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1");
>   +Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2");
>   +Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4");
>   +if (Is64Bit)
>   +   Builder.defineMacro("__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8");
>   +  }
> 
>  if (HasF || HasD) {
>Builder.defineMacro("__riscv_flen", HasD ? "64" : "32");

Hi Kristof,

Can you please submit this upstream? We already have way too many gratuitous 
RISC-V differences that haven't been upstreamed.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: clang miscompiles OpenLibm on i686-*-freebsd

[Dimitry Andric]

On 8 Sep 2020, at 19:47, Steve Kargl  wrote:
> 
> On Mon, Sep 07, 2020 at 07:55:13PM -0700, Steve Kargl wrote:
>> On Mon, Sep 07, 2020 at 07:10:02PM -0700, Steve Kargl wrote:
>>> 
>>> Interval tested for exp2f: [1,8]
>>>   ulp <= 0.5:  0.056% 14072 |   0.056% 14072
>>> 0.5 <  ulp <  0.6:  0.000% 8 |   0.056% 14080
>>> 3.0 <  ulp <  0.0: 99.944%  25151744 | 100.000%  25165824
>>> Max ulp: 22729.386719 at 1.00195301e+00
>>> 
>> 
>> Note, compiling s_exp2f.c with gcc9 gives the above
>> result with -O3 -march=i686 -m32. So, gcc9 is not
>> nearly as bad as clang, but both give bad results.
>> Comparing OpenLibm's s_exp2f.c and FreeBSD's s_exp2f.c,
>> one sees that the files are almost identical.
>> 
>> Note, FreeBSD's libm gives
>> 
>> % ./tlibm_libm -DEfP exp2
>> Interval tested for exp2f: [1,8]
>>   ulp <= 0.5: 99.959%  25155610 |  99.959%  25155610
>> 0.5 <  ulp <  0.6:  0.041% 10214 | 100.000%  25165824
>> Max ulp: 0.500980 at 1.97115958e+00
>> 
>> which is good, but this is compiled with CPUTYPE ?= core2
>> in /etc/make.conf.
>> 
> 
> I think I've found the problem, and it appears to be
> due to a change byt Openlibm developers to the file
> math_private.h copied from FreeBSD.  Namely, one finds
> 
> //VBS
> #define STRICT_ASSIGN(type, lval, rval) ((lval) = (rval))
> 
> /* VBS
> #ifdef FLT_EVAL_METHOD
> // Attempt to get strict C99 semantics for assignment with non-C99 compilers.
> #if FLT_EVAL_METHOD == 0 || __GNUC__ == 0
> #define STRICT_ASSIGN(type, lval, rval) ((lval) = (rval))
> #else
> #define STRICT_ASSIGN(type, lval, rval) do { \
> volatile type __lval;   \
>  \
> if (sizeof(type) >= sizeof(double)) \
>  (lval) = (rval);  \
> else { \
>  __lval = (rval);  \
>  (lval) = __lval;  \
> } \
> } while (0)
> #endif
> #endif
> */
> 
> So, STRICT_ASSIGN is broken in Openlibm.  I'll be reporting
> a bug upstream.  Apoogies for the noise.

Hi Steve,

I'm curious what their rationale was, as the commit that changed it is:

https://github.com/JuliaMath/openlibm/commit/f5fb92746715beb0441a60feca202ee16cb19fc9

with a description of just "Build with gcc"... Maybe they've assumed gcc
never needs the volatile approach?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Undefined reference to __bswapsi2/__bswapdi2

[Dimitry Andric]

On 20 Aug 2020, at 19:52, Gleb Popov  wrote:
> 
> On Wed, Aug 19, 2020 at 10:15 PM Gleb Popov  wrote:
> 
>> Hi toolchain@
>> 
>> I'm building the latest GHC on 12.1-RELEASE i386 and having almost the
>> same problem as with atomic functions. This time the error is
>> 
>> d: error: undefined symbol: __bswapsi2
> referenced by TTY.c
>  RTS.thr_p_o:(rtsSyms) in archive
>> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.2/rts/dist/build/libHSrts_thr_p.a
>> 
>> ld: error: undefined symbol: __bswapdi2
> referenced by TTY.c
>  RTS.thr_p_o:(rtsSyms) in archive
>> /wrkdirs/usr/ports/lang/ghc/work/ghc-8.10.2/rts/dist/build/libHSrts_thr_p.a
>> 
>> What's wrong with that? These functions seem to be present in our
>> compiler-rt.
>> 
> 
> Reading /usr/src/lib/libcompiler_rt/Makefile.inc, it seems that we don't
> compile these functions. What's the reason for this?

I'm not aware of any particular reason, except that nobody seems to have
run into this omission before. It looks like on x86, compilers usually
just emit bswap instructions instead of libcalls for these situations.

Apparently we have historically only added bswapdi and bswapsi for arm,
mips and riscv.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: RO Elf program headers

[Dimitry Andric]

On 2020-02-23 16:31, Paul Floyd wrote:
> I’ve been working on getting Valgrind to work again on FreeBSD.
> Probably the biggest problem at the moment is that Valgrind doesn’t (yet) 
> handle the read-only program headers.
> If I run “readelf -l libc++.so.1.0” on Linux I see two LOAD headers, the 
> first one “R E” (read-execute) and the second one “RW” (read-write). If I do 
> the same on FreeBSD then I see a third program header which is “R” 
> (read-only), before the other two.
> My questions are
> - Does anyone know when this extra header was added? (I assume that it was 
> added sometime in the past 5 years or so)

Most likely a very long time ago.


> - What is in these segments, and is it safe to assume that multiple shared 
> libraries can map the same RO content to the same address?

If you use readelf -l, you will see a "Section to Segment mapping":

$ readelf -lW /usr/lib/libc++.so.1

Elf file type is DYN (Shared object file)
Entry point 0x5c000
There are 9 program headers, starting at offset 64

Program Headers:
  Type   Offset   VirtAddr   PhysAddr   FileSiz  MemSiz 
  Flg Align
  PHDR   0x40 0x0040 0x0040 0x0001f8 
0x0001f8 R   0x8
  LOAD   0x00 0x 0x 0x05b1d4 
0x05b1d4 R   0x1000
  LOAD   0x05c000 0x0005c000 0x0005c000 0x06bbe0 
0x06bbe0 R E 0x1000
  LOAD   0x0c8000 0x000c8000 0x000c8000 0x004c78 
0x004c78 RW  0x1000
  LOAD   0x0cd000 0x000cd000 0x000cd000 0x000de0 
0x0032f8 RW  0x1000
  DYNAMIC0x0cc5c0 0x000cc5c0 0x000cc5c0 0x0001a0 
0x0001a0 RW  0x8
  GNU_RELRO  0x0c8000 0x000c8000 0x000c8000 0x004c78 
0x004c78 R   0x1
  GNU_EH_FRAME   0x046c34 0x00046c34 0x00046c34 0x003244 
0x003244 R   0x4
  GNU_STACK  0x00 0x 0x 0x00 
0x00 RW  0

 Section to Segment mapping:
  Segment Sections...
   00
   01 .dynsym .gnu.version .gnu.version_r .gnu.hash .hash .dynstr .rela.dyn 
.rela.plt .rodata .gcc_except_table .eh_frame_hdr .eh_frame
   02 .text .init .fini .plt
   03 .ctors .dtors .jcr .data.rel.ro .init_array .dynamic .got
   04 .data .got.plt .bss
   05 .dynamic
   06 .ctors .dtors .jcr .data.rel.ro .init_array .dynamic .got
   07 .eh_frame_hdr
   08

E.g, segment 01 is R, and contains things like the dynamic symbol table, 
relocations, exception handling information, and so on.  It is fairly safe to 
say that these can be shared.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

[Differential] D22061: Build toolchain components as dynamically linked executables by default

[dim (Dimitry Andric)]

dim created this revision.
dim added reviewers: emaste, imp, jhb, kib.
Herald added a subscriber: bdrewery.
Herald added a reviewer: manpages.

REVISION SUMMARY
  Historically, we have built toolchain components such as cc, ld, etc as
  statically linked executables.  One of the reasons being that you could
  sometimes save yourself from botched upgrades, by e.g. recompiling a
  "known good" libc and reinstalling it.
  
  In this day and age, we have boot environments, virtual machine
  snapshots, cloud backups, and other much more reliable methods to
  restore systems to working order.  So I think the time is ripe to flip
  this default, and link the toolchain components dynamically, just like
  almost all other executables on FreeBSD.
  
  Maybe at some point they can even become PIE executables by default! :)

REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D22061

AFFECTED FILES
  share/man/man5/src.conf.5
  share/mk/src.opts.mk
  tools/build/options/WITHOUT_SHARED_TOOLCHAIN

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: dim, emaste, imp, jhb, kib, #manpages
Cc: bdrewery, freebsd-toolchain-list
diff --git a/tools/build/options/WITHOUT_SHARED_TOOLCHAIN b/tools/build/options/WITHOUT_SHARED_TOOLCHAIN
new file mode 100644
--- /dev/null
+++ b/tools/build/options/WITHOUT_SHARED_TOOLCHAIN
@@ -0,0 +1,6 @@
+.\" $FreeBSD$
+Set to build toolchain components as statically linked executables.
+The set includes
+.Xr cc 1 ,
+.Xr make 1
+and necessary utilities like assembler, linker and library archive manager.
diff --git a/share/mk/src.opts.mk b/share/mk/src.opts.mk
--- a/share/mk/src.opts.mk
+++ b/share/mk/src.opts.mk
@@ -166,6 +166,7 @@
 SENDMAIL \
 SERVICESDB \
 SETUID_LOGIN \
+SHARED_TOOLCHAIN \
 SHAREDOCS \
 SOURCELESS \
 SOURCELESS_HOST \
@@ -210,7 +211,6 @@
 OPENLDAP \
 REPRODUCIBLE_BUILD \
 RPCBIND_WARMSTART_SUPPORT \
-SHARED_TOOLCHAIN \
 SORT_THREADS \
 SVN \
 ZONEINFO_LEAPSECONDS_SUPPORT \
diff --git a/share/man/man5/src.conf.5 b/share/man/man5/src.conf.5
--- a/share/man/man5/src.conf.5
+++ b/share/man/man5/src.conf.5
@@ -1,6 +1,6 @@
 .\" DO NOT EDIT-- this file is @generated by tools/build/options/makeman.
 .\" $FreeBSD$
-.Dd October 1, 2019
+.Dd October 16, 2019
 .Dt SRC.CONF 5
 .Os
 .Sh NAME
@@ -197,7 +197,7 @@
 of the normal system build.
 .Pp
 This is a default setting on
-amd64/amd64, arm/arm, arm/armv6, arm/armv7, i386/i386, mips/mipsel, mips/mips, mips/mips64el, mips/mips64, mips/mipsn32, mips/mipselhf, mips/mipshf, mips/mips64elhf, mips/mips64hf, powerpc/powerpc, powerpc/powerpc64, powerpc/powerpcspe and sparc64/sparc64.
+amd64/amd64, arm/arm, arm/armv6, arm/armv7, i386/i386, mips/mipsel, mips/mips, mips/mips64el, mips/mips64, mips/mipsn32, mips/mipselhf, mips/mipshf, mips/mips64elhf, mips/mips64hf and sparc64/sparc64.
 .It Va WITHOUT_BINUTILS_BOOTSTRAP
 Set to not build binutils (as, ld, and objdump)
 as part of the bootstrap process.
@@ -213,7 +213,7 @@
 as part of the bootstrap process.
 .Pp
 This is a default setting on
-amd64/amd64, arm/arm, arm/armv6, arm/armv7, i386/i386, mips/mipsel, mips/mips, mips/mips64el, mips/mips64, mips/mipsn32, mips/mipselhf, mips/mipshf, mips/mips64elhf, mips/mips64hf, powerpc/powerpc, powerpc/powerpc64, powerpc/powerpcspe and sparc64/sparc64.
+amd64/amd64, arm/arm, arm/armv6, arm/armv7, i386/i386, mips/mipsel, mips/mips, mips/mips64el, mips/mips64, mips/mipsn32, mips/mipselhf, mips/mipshf, mips/mips64elhf, mips/mips64hf and sparc64/sparc64.
 .It Va WITHOUT_BLACKLIST
 Set this if you do not want to build
 .Xr blacklistd 8
@@ -268,7 +268,7 @@
 .Pa crtend.o .
 .Pp
 This is a default setting on
-amd64/amd64, arm/arm, arm/armv6, arm/armv7, arm64/aarch64, i386/i386, mips/mipsel, mips/mips, mips/mips64el, mips/mips64, mips/mipsn32, mips/mipselhf, mips/mipshf, mips/mips64elhf, mips/mips64hf, powerpc/powerpc, powerpc/powerpc64, powerpc/powerpcspe and riscv/riscv64.
+amd64/amd64, arm/arm, arm/armv6, arm/armv7, arm64/aarch64, i386/i386, riscv/riscv64, mips/mipsel, mips/mips, mips/mips64el, mips/mips64, mips/mipsn32, mips/mipselhf, mips/mipshf, mips/mips64elhf and mips/mips64hf.
 .It Va WITH_BSD_GREP
 Install BSD-licensed grep as '[ef]grep' instead of GNU grep.
 .It Va WITHOUT_BSNMP
@@ -410,7 +410,7 @@
 Set to build the Clang C/C++ compiler during the normal phase of the build.
 .Pp
 This is a default setting on
-amd64/amd64, arm/arm, arm/armv6, arm/armv7, arm64/aarch64, i386/i386, mips/mipsel, mips/mips, mips/mips64el, mips/mips64, mips/mipsn32, mips/mipselhf, mips/mipshf, mips/mips64elhf, mips/mips64hf, powerpc/powerpc, powerpc/powerpc64 and powerpc/powerpcspe.
+amd64/amd64, arm/arm, arm/armv6, arm/armv7, arm64/aarch64, i386/i386, mips/mipsel, mips/mips, mips/mips64el, mips/mips64, mips/mipsn32, mips/mipselhf, mips/mipshf, mips/mips64elhf and mips/mips64hf.
 .It Va WITHOUT_CLANG_BOOTSTRAP
 Set to not build the Clang C/C++ compiler during 

Re: amd64 head -r351153 self-built but via devel/llvm90: 'objcopy: elf_update() failed: Layout constraint violation' for gptboot.bin

[Dimitry Andric]

On 17 Aug 2019, at 05:33, Mark Millard  wrote:
> 
> I upgraded to head -r351153 and then attempted a buildworld
> buildkernel via devel/llvm90 (rc2 via ports head -r509054),
> but that (from scratch) build attempt got:
> 
> --- gptboot.bin ---
> objcopy: elf_update() failed: Layout constraint violation
> *** [gptboot.bin] Error code 1
> make[5]: *** gptboot.bin removed


It turns out this is an lld issue with the -N option, introduced with
https://reviews.llvm.org/rLLD360593:

https://bugs.llvm.org/show_bug.cgi?id=43212

Before, -N did not do that much, but that change can cause section
offsets which do not match the stated section alignment.  Hence, objcopy
complains.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FYI: Unable to build -r501994 ports' devel/llvm60 on clang 8 based powerpc64 system: "BFD (GNU Binutils) 2.32 assertion fail elflink.c:2935"

[Dimitry Andric]

On 19 May 2019, at 16:56, Mark Millard via freebsd-toolchain 
 wrote:
> This was in a poudriere bulk build on a head -r347549 based powerpc64
> system with system clang 8 for cc and c++ and base/binutils
> for the likes of ld. (The system has the llvm libunwind patches
> for powerpc64 so throwing c++ exceptions work.)
> 
> [4397/4552] : && /usr/bin/c++ -fPIC -O2 -pipe -DNDEBUG 
> -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  
> -DNDEBUG -isystem /usr/local/include -fPIC -fvisibility-inlines-hidden 
> -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -W 
> -Wno-unused-parameter -Wwrite-strings -Wcast-qual 
> -Wmissing-field-initializers -pedantic -Wno-long-long 
> -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
> -Wstring-conversion -fcolor-diagnostics -ffunction-sections -fdata-sections 
> -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem /usr/local/include 
> -fno-strict-aliasing  -DNDEBUG -isystem /usr/local/include  
> -fstack-protector-strong   -Wl,-z,origin  -Wl,-O3 -Wl,--gc-sections  
> -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto/LTO.exports
>  -shared -Wl,-soname,libLTO.so.6 -o lib/libLTO.so.6.0.1 
> tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o 
> tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib 
> -Wl,-rpath,"\$ORIGIN/../
> lib:/usr/local/lib" lib/libLLVM-6.0.so && :
> FAILED: lib/libLTO.so.6.0.1
> : && /usr/bin/c++ -fPIC -O2 -pipe -DNDEBUG -fstack-protector-strong -isystem 
> /usr/local/include -fno-strict-aliasing  -DNDEBUG -isystem /usr/local/include 
> -fPIC -fvisibility-inlines-hidden -Werror=date-time 
> -Werror=unguarded-availability-new -std=c++11 -Wall -W -Wno-unused-parameter 
> -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic 
> -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor 
> -Wdelete-non-virtual-dtor -Wstring-conversion -fcolor-diagnostics 
> -ffunction-sections -fdata-sections -O2 -pipe -DNDEBUG 
> -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  
> -DNDEBUG -isystem /usr/local/include  -fstack-protector-strong   
> -Wl,-z,origin  -Wl,-O3 -Wl,--gc-sections  
> -Wl,--version-script,/wrkdirs/usr/ports/devel/llvm60/work/.build/tools/lto/LTO.exports
>  -shared -Wl,-soname,libLTO.so.6 -o lib/libLTO.so.6.0.1 
> tools/lto/CMakeFiles/LTO.dir/LTODisassembler.cpp.o 
> tools/lto/CMakeFiles/LTO.dir/lto.cpp.o -L/usr/local/lib 
> -Wl,-rpath,"\$ORIGIN/../lib:/usr/loc
> al/lib" lib/libLLVM-6.0.so && :
> /usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion 
> fail elflink.c:2935
> /usr/bin/powerpc64-unknown-freebsd13.0-ld: BFD (GNU Binutils) 2.32 assertion 
> fail elflink.c:2935

See .  I think this is a BFD ld bug,
but I still haven't been able to come up with a small test case.  Any
help appreciated. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: stable/11 discards const qualifiers

[Dimitry Andric]

On 25 Apr 2019, at 16:01, Dmitry Chagin  wrote:
> 
> I'm trying to merge r331056, r331057, r331060, r331356,(by emaste@) to the
> stable/11 and get the following error:
> 
> ===> linux (all)
> cc  -O2 -pipe -DCOMPAT_FREEBSD32 -DCOMPAT_LINUX32  -fno-strict-aliasing
> -Werror -D_KERNEL -DKLD_MODULE -nostdinc   -DHAVE_KERNEL_OPTION_HEADERS
> -include
> /usr/home/dchagin/tmp/obj/usr/home/dchagin/freebsd/sys/GENERIC/opt_global.h
> -I. -I/usr/home/dchagin/freebsd/sys -fno-common -g -fno-omit-frame-pointer
> -mno-omit-leaf-frame-pointer
> -I/usr/home/dchagin/tmp/obj/usr/home/dchagin/freebsd/sys/GENERIC   -MD
> -MF.depend.linux32_sysvec.o -MTlinux32_sysvec.o -mcmodel=kernel
> -mno-red-zone -mno-mmx -mno-sse -msoft-float
> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv -fstack-protector
> -gdwarf-2 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes
> -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef
> -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ -Wmissing-include-dirs
> -fdiagnostics-show-option -Wno-unknown-pragmas
> -Wno-error-tautological-compare -Wno-error-empty-body
> -Wno-error-parentheses-equality -Wno-error-unused-function
> -Wno-error-pointer-sign -Wno-error-shift-negative-value
> -Wno-error-address-of-packed-member  -mno-aes -mno-avx  -std=iso9899:1999
> -c /usr/home/dchagin/freebsd/sys/amd64/linux32/linux32_sysvec.c -o
> linux32_sysvec.o
> /usr/home/dchagin/freebsd/sys/amd64/linux32/linux32_sysvec.c:322:29:
> warning: taking address of packed member 'uc_sigmask' of class or structure
> 'l_ucontext' may result in an unaligned pointer value
> [-Waddress-of-packed-member]
>bsd_to_linux_sigset(mask, _sc.uc_sigmask);
>   ^~
> /usr/home/dchagin/freebsd/sys/amd64/linux32/linux32_sysvec.c:639:23:
> warning: taking address of packed member 'uc_sigmask' of class or structure
> 'l_ucontext' may result in an unaligned pointer value
> [-Waddress-of-packed-member]
>linux_to_bsd_sigset(_sigmask, );
> ^
> /usr/home/dchagin/freebsd/sys/amd64/linux32/linux32_sysvec.c:912:15: error:
> initializing 'int *' with an expression of type 'const int []' discards
> qualifiers [-Werror,-Wincompatible-pointer-types-discards-qualifiers]
>.sv_errtbl  = linux_errtbl,
>  ^~~~
> 2 warnings and 1 error generated.
> *** Error code 1
> 
> Is I'm missing something?

Yes, please also merge r329787:


r329787 | emaste | 2018-02-22 02:59:59 +0100 (Thu, 22 Feb 2018) | 6 lines

Use 'const int *' for sysentvec errno translation table

This allows an sv_errtbl to be read-only .rodata.

Sponsored by:   Turing Robotic Industries Inc.


Index: sys/sys/sysent.h
===
--- sys/sys/sysent.h(revision 329786)
+++ sys/sys/sysent.h(revision 329787)
@@ -94,7 +94,7 @@ struct sysentvec {
struct sysent   *sv_table;  /* pointer to sysent */
u_int   sv_mask;/* optional mask to index */
int sv_errsize; /* size of errno translation table */
-   int *sv_errtbl; /* errno translation table */
+   const int   *sv_errtbl; /* errno translation table */
int (*sv_transtrap)(int, int);
/* translate trap-to-signal mapping */
int (*sv_fixup)(register_t **, struct image_params *);



-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Is this a programming error, or a compiler error..

[Dimitry Andric]

On 13 Mar 2019, at 12:57, Willem Jan Withagen  wrote:
> 
> I'm getting a crash in a Ceph test program in the following pice of code:
> 
> struct entity_addrvec_t {
>   vector v;
> .
>   entity_addr_t legacy_addr() const {
> for (auto& a : v) {
>   if (a.type == entity_addr_t::TYPE_LEGACY) {
> return a;
>   }
> }
> return entity_addr_t();
>   }
> ..
> 
> Where the loop is taken, even if v.size() == 0
> So v content is pointing to random memory and itterating over the next 
> pointer results in a crash.

This can happen when the vector is invalidated, due to either it, or its
parent object having been moved from.  Maybe run this under valgrind or
AddressSanitizer, that should give some more clues.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: clang broken on current?

[Dimitry Andric]

On 10 Feb 2019, at 06:00, Steve Kargl  wrote:
> 
> I have
> 
> % uname -a
> FreeBSD mobile 13.0-CURRENT FreeBSD 13.0-CURRENT r343477 MOBILE  i386
> 
> % dmesg | more
> ...
> FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 
> 7.0.1)
> VT(vga): resolution 640x480
> CPU: Intel(R) Core(TM)2 Duo CPU T7250  @ 2.00GHz (1995.05-MHz 686-class 
> CPU)
>  Origin="GenuineIntel"  Id=0x6fd  Family=0x6  Model=0xf  Stepping=13
>  
> Features=0xbfebfbff
>  Features2=0xe3bd
>  AMD Features=0x2000
>  AMD Features2=0x1
>  VT-x: (disabled in BIOS) HLT,PAUSE
>  TSC: P-state invariant, performance statistics
> ...
> 
> If I add 'CFLAGS+=-march=native -mtune=native', I can build
> world and kernel without a problem.  If I try to build
> x11-toolkits/qt5-gui the build dies with
> 
> c++ -Wl,--as-needed -fstack-protector -Wl,--no-undefined
> -Wl,--version-script,QtGui.version -pthread -Wl,-rpath,/usr/local/lib/qt5
> -shared -Wl,-Bsymbolic-functions
> -Wl,--dynamic-list,/usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src-
> 5.12.0/src/gui/QtGui.dynlist -Wl,-soname,libQt5Gui.so.5 -o libQt5Gui.so.5.12.0
> 
> (long list of *.o files)
> 
> -L/usr/ports/x11-toolkits/qt5-gui/work/qtbase-everywhere-src-5.12.0/lib -L/lib
> -L/usr/local/lib/qt5 -lQt5Core -L/usr/local/lib -lGL -lpng16 -lharfbuzz -lz
> .obj/qimage.o: In function `QImage::fill(unsigned int)':
> qimage.cpp:(.text+0x2442): undefined reference to `qt_memfill32(unsigned int*,
> unsigned int, int)'
> qimage.cpp:(.text+0x2477): undefined reference to `qt_memfill16(unsigned
> short*, unsigned short, int)'

How did you arrive at the conclusion that this has anything to do with
the specific compiler?  From these errors, I think it is more likely
something in Qt5 that is erroneously convinced that those qt_memfillXY
functions exist.  Or they get referenced, but not compiled at all, for
some reason.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: svn commit: r339898 - head/lib/libc/amd64/sys

[Dimitry Andric]

On 4 Nov 2018, at 08:43, Julian Elischer  wrote:
> 
> what's an ifunc?

This is a GNU extension, an "indirect function".  It allows you to
provide multiple different implementations of the same function, for
instance optimized for specific CPU types, and choose between them at
dynamic link time (e.g. at run time).

See the following for more information:

https://sourceware.org/glibc/wiki/GNU_IFUNC
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-ifunc-function-attribute

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: On a powerpc64, system-clang crashes on audio/alsa-lib 's control.lo : "error in backend: A @@ version cannot be undefined"

[Dimitry Andric]

On 12 Oct 2018, at 15:00, Jan Beich  wrote:
> 
> Mark Millard  writes:
>> The following is on a powerpc64 machine (old PowerMac G5 so-called
>> "Quad Core") running a personal build of head -r339076 that was
>> built via devel/powerpc64-xtoolchain-gcc and such (no gcc 4.2.1).
>> The compiler for the port build is system-clang (so clang 6 as cc),
>> not used for buildworld buildkernel. [I experiment with more modern
>> compilers and toolchains for some powerpc family members.]
> [...]
>> /bin/sh ../../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H
>> -I. -I../../include -I../../include -I/usr/ports/audio/alsa-lib/files
>> -O2 -pipe -g -fno-strict-aliasing -MT control.lo -MD -MP -MF
>> .deps/control.Tpo -c -o control.lo control.c
> [...]
>> fatal error: error in backend: A @@ version cannot be undefined
...
> and can be further reduced to
> 
>  int main()
>  {
>__asm__ (".symver __foo,foo@@FOO");
>__asm__ (".symver .__foo,.foo@@FOO");
>  }

Submitted as https://bugs.llvm.org/show_bug.cgi?id=39270, though
upstream alsa-lib seems to have dropped this powerpc64 specific
workaround:

http://git.alsa-project.org/?p=alsa-lib.git;a=commit;h=3bad0a21b4d13d8d10691f382c836897fa7a7cb9

You might want to try if that also works for you.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: unknown -z value: common-page-size=4096

[Dimitry Andric]

On 29 Sep 2018, at 04:08, Shawn Webb  wrote:
> 
> On Fri, Sep 28, 2018 at 10:01:31PM -0400, Charlie Li wrote:
>> I've switched to using devel/xtoolchain-llvm70 yesterday to build amd64
>> base starting with r338990, and among other issues, ld.lld70 refuses to
>> link the kernel:
>> 
>> Building /usr/local/obj/usr/local/src/amd64.amd64/sys/ARDMORE/kernel.full
>> --- kernel.full ---
>> linking kernel.full
>> ld.lld: error: unknown -z value: common-page-size=4096
>> ld.lld: error: unknown -z value: ifunc-noplt
>> *** [kernel.full] Error code 1
>> 
>> make[2]: stopped in /usr/local/obj/usr/local/src/amd64.amd64/sys/ARDMORE
>> 
>> (ARDMORE is basically GENERIC-NODEBUG, not that it matters)
>> 
>> The ifunc-noplt is a known issue, it obviously didn't make it upstream
>> in time for LLVM 7.0.0, and thus we carry the feature downstream.
>> 
>> The crux of this link error though, emaste@ quipped in PR 230604 that
>> LLD prior to 7.0.0 accepted but ignored unknown options, but now at
>> least 7.0.0 disallows unknown options entirely. Which brings up the -z
>> common-page-size=4096: has LLD been ignoring this part the whole time,
>> and is it of any meaningful use anymore (it seemed to mean something
>> with bfd)?
> 
> I noticed the same issues. I reverted parts of recent work by upstream
> FreeBSD in HardenedBSD's Cross-DSO CFI branch since that branch uses
> clang/llvm/lld 7.0.0.

You can apply this changeset from the clang700-import branch:

https://svnweb.freebsd.org/changeset/base/337325

or just use the clang700-import branch wholesale. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Broken arm support in clang now?

[Dimitry Andric]

On 11 Aug 2018, at 19:31, Warner Losh  wrote:
> 
> On Sat, Aug 11, 2018, 10:20 AM Dimitry Andric  wrote:
> On 11 Aug 2018, at 16:55, Warner Losh  wrote:
> >
> > It looks like armv5 clang bogusly uses lld:
> >
> > From a 'make buildkernel' of the RT1310 kernel config:
> >
> > cc -target arm-gnueabi-freebsd12.0
...
> > ld: warning: lld uses extended branch encoding, no object with architecture
> > supporting feature detected.
> > ld: warning: lld may use movt/movw, no object with architecture supporting
> > feature detected.
...
> Host is amd64. Target is arm. No src.conf. Did a full buildworld TARGET=arm a 
> few days ago. /usr/bin/ld is lld.

Okay, so in the above "cc" command, can you somehow figure out which cc
executable it is using? And please add a -v to the "linking kernel.full"
command line, so it shows exactly which linker it runs?

I have the idea that it is preferring your /usr/bin/ld over
${WORLDTMP}/usr/bin/ld...

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Broken arm support in clang now?

[Dimitry Andric]

On 11 Aug 2018, at 16:55, Warner Losh  wrote:
> 
> It looks like armv5 clang bogusly uses lld:
> 
> From a 'make buildkernel' of the RT1310 kernel config:
> 
> cc -target arm-gnueabi-freebsd12.0
> --sysroot=/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp
> -B/usr/home/imp/obj/usr/home/imp/git/head/arm.arm/tmp/usr/bin -c -O -pipe
> -g -nostdinc  -I. -I/usr/home/imp/git/head/sys
> -I/usr/home/imp/git/head/sys/contrib/ck/include
> -I/usr/home/imp/git/head/sys/contrib/libfdt
> -I/usr/home/imp/git/head/sys/gnu/dts/include -D_KERNEL
> -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -march=armv5te
> -funwind-tables  -ffreestanding -fwrapv -gdwarf-2 -Wall -Wredundant-decls
> -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
> -Wcast-qual -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__
> -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas
> -Wno-error-tautological-compare -Wno-error-empty-body
> -Wno-error-parentheses-equality -Wno-error-unused-function
> -Wno-error-pointer-sign -Wno-error-shift-negative-value
> -Wno-address-of-packed-member  -mfpu=none  -std=iso9899:1999 -Werror  vers.c
> linking kernel.full
> ld: warning: lld uses extended branch encoding, no object with architecture
> supporting feature detected.
> ld: warning: lld may use movt/movw, no object with architecture supporting
> feature detected.
> text data  bss   dechex   filename
>  3448944   176776   655360   4281080   0x4152f8   kernel.full
> 
> Any clues on how I can track this down?

What does /usr/bin/ld -v output?  As far as I can see, MK_LLD_BOOTSTRAP
and MK_LLD_IS_LD are only enabled by default for aarch64 and amd64.  So
do you have any of those settings in your src.conf or environment?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Clang 6.0.[01]: UNREACHABLE executed

[Dimitry Andric]

On 13 Jul 2018, at 18:45, Dimitry Andric  wrote:
> 
> On 13 Jul 2018, at 14:30, Jonathan Anderson  wrote:
>> 
>> I recently ran into an unreachable statement execution in Clang 6, both
>> with v6.0.0 from the llvm60 package and v6.0.1 from HEAD (FreeBSD
>> r335799 / LLVM r335540). I don't see this issue in Clang 5 or in the
>> version that ships with macOS High Sierra (which they're calling 9.1.0,
>> but that's apparently more of a "marketing version" than a true version
>> number).
>> 
>> creduce managed to shrink my 2.8 MiB preprocessed sources down to a 604
>> B test case:
>> 
>> https://gist.github.com/trombonehero/2da555bd1292be973f9d14c843c56ae5
>> 
>> This isn't a valid C++ file (e.g., it cuts off after `return o` on line
>> 23), but I would expect it to cause compiler errors rather than a
>> compiler crash. You can see the output from the crash at:
>> 
>> https://gist.github.com/trombonehero/8fce4a8f39ae121a2f9f14b45b0b65a1
>> 
>> Any thoughts?
> 
> It doesn't crash for me, at least not with the command line you provided
> in the gist.

Ah, I had a clang without assertions, but with assertions enabled, it
indeed results in:

Invalid operator call kind
UNREACHABLE executed at 
/usr/src/contrib/llvm/tools/clang/lib/AST/StmtProfile.cpp:1250!
Abort trap

This looks very much like https://bugs.llvm.org/show_bug.cgi?id=28793,
which is also something about a lamdba function with an invalid or
incomplete syntax.

I will dig a bit further; if it is the same bug, and reproduces with
clang trunk, I can bump the upstream bug, and/or ping a few people that
might be able to fix it.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: aarch64-arm64 fails to build kernel 12-current raspberry pi 3

[Dimitry Andric]

On 12 Jul 2018, at 15:23, Mark Millard via freebsd-toolchain 
 wrote:
> 
> On 2018-Jul-12, at 2:44 AM, tech-lists  wrote:
> 
>> On 11/07/2018 17:21, Mark Millard wrote:
>>> It seems from the quoted material that neither kernel-toolchain nor
>>> build world was done before buildkernel . My understanding is that
>>> the intent is that one or the other be done first. (But for aarch64
>>> currently only buildworld works.)
>> 
>> Thanks for this. I'm running a buildworld now.
>> 
>> For how long has it been the case that buildworld is needed for buildkernel? 
>> Coming from amd64 and before that, i386, in situations where I've only 
>> wanted to install a custom kernel, I was firstly used to making and 
>> installing it from /sys/{i386,amd64}/conf. Then that broke a number of years 
>> ago. Then got used to making kernel in /usr/src with make buildkernel && 
>> make installkernel. And now this is broken, on aarch64-arm64. Nobody knows 
>> if it's accidental or policy.
> 
> It has been true since clang added use of stdint.h to the kernel build.
> Prior to this stdint.h was  not needed to build the kernel for any
> architecture (as far as I know).

No, it's because sys/crypto/armv8/armv8_crypto_wrap.c includes
, an intrinsics header, which in turn requires .

This was introduced in https://svnweb.freebsd.org/changeset/base/308921,
and at the time resulted in similar build failures, specifically when
one attempted to build a new kernel, without building world or a new
toolchain first.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: svn commit: r334647 - in head: . . . [this broke ci.freebsd.org's FreeBSD-head-amd64-gcc build but via an include/c++/v1/ problem]

[Dimitry Andric]

On 5 Jun 2018, at 15:03, Mark Millard via freebsd-toolchain 
 wrote:
> 
> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/5974/consoleText shows:
> 
> --- all_subdir_usr.sbin/pmc ---
> In file included from 
> /workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/ios:216:0,
> from 
> /workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/iostream:38,
> from /workspace/src/usr.sbin/pmc/cmd_pmc_filter.cc:71:
> /workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/__locale: At 
> global scope:
> /workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/__locale:1237:40:
>  error: redundant redeclaration of 'void 
> std::__1::__throw_runtime_error(const char*)' in same scope 
> [-Werror=redundant-decls]
> _LIBCPP_NORETURN _LIBCPP_FUNC_VIS void __throw_runtime_error(const char*);
>^
> In file included from 
> /workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/memory:663:0,
> from 
> /workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/algorithm:643,
> from 
> /workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/__string:56,
> from 
> /workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/string_view:176,
> from 
> /workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/string:477,
> from 
> /workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/__locale:15,
> from 
> /workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/ios:216,
> from 
> /workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/iostream:38,
> from /workspace/src/usr.sbin/pmc/cmd_pmc_filter.cc:71:
> /workspace/obj/workspace/src/amd64.amd64/tmp/usr/include/c++/v1/stdexcept:186:40:
>  note: previous declaration of 'void std::__1::__throw_runtime_error(const 
> char*)'
> _LIBCPP_NORETURN _LIBCPP_FUNC_VIS void __throw_runtime_error(const char*);
>^
> 
> 
> It looks like the new #include of iostream brings in code that gcc rejected 
> above:
> 
> --- head/usr.sbin/pmc/cmd_pmc_filter.cMon Jun  4 23:17:18 2018
> (r334645, copy source)
> +++ head/usr.sbin/pmc/cmd_pmc_filter.cc   Tue Jun  5 04:26:40 2018
> (r334647)
> @@ -68,11 +68,22 @@ __FBSDID("$FreeBSD$");
> #include 
> #include "cmd_pmc.h"
> 
> +#include 
> . . .

I don't think anybody has yet tested building libc++ headers with the
combination of recent gcc, -Wsystem-headers, and -Werror. :)

For now, try disabling -Wredundant-decls.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Compiling libc with LTO

[Dimitry Andric]

On 5 Mar 2018, at 00:11, Shawn Webb  wrote:
> 
> I'm working on Cross-DSO CFI support in HardenedBSD. I've noticed
> certain libraries do not like to be compiled with -flto, libc being
> one of them. I'm scratching my head a bit, but unsure where to go from
> here, so a little direction would be helpful.
> 
> In the hardened/current/cross-dso-cfi feature branch of the
> hardenedBSD-playground repo[1], ld.lld, llvm-ar, llvm-nm, and
> llvm-objdump are the default ld, ar/ranlib, nm, and objdump
> respectively. The first step for Cross-DSO CFI support is compiling
> all shared and static libraries with LTO.
> 
> I'm curious if this is a shortcoming of ld.lld and I should file a bug
> with the llvm project (if one's not already filed). I've heard that
> someone got FreeBSD compiled with LTO already, so I'm hoping to borrow
> some of their expertise.
> 
> Here's a log of the build (warning: large file):
> https://gist.githubusercontent.com/anonymous/f8617d629fd054479142cc4b6de3581e/raw/b94579fac987556c01ae0aab7e2943d25d27bcc4/libc.log
> 
> Essentially, the erroring lines are:
> 
> /usr/obj/scratch/src/cross-dso-cfi/amd64.amd64/tmp/usr/bin/ld: error: 
> swapcontext.pico: symbol swapcontext@@@FBSD_1.2 has undefined version 
> @FBSD_1.2
> /usr/obj/scratch/src/cross-dso-cfi/amd64.amd64/tmp/usr/bin/ld: error: 
> openat.pico: symbol openat@@@FBSD_1.2 has undefined version @FBSD_1.2
> /usr/obj/scratch/src/cross-dso-cfi/amd64.amd64/tmp/usr/bin/ld: error: 
> setcontext.pico: symbol setcontext@@@FBSD_1.2 has undefined version @FBSD_1.2

I can at least reproduce these errors, and it seems strange that the
symbols in question end up with three @ signs, e.g. the LLVM IR in
swapcontext.pico has:

module asm ".ident\09\22$FreeBSD$\22"
module asm ".weak __swapcontext"
module asm ".equ __swapcontext, __sys_swapcontext"
module asm ".symver __impl_swapcontext, swapcontext@FBSD_1.0"
module asm ".weak __impl_swapcontext"
module asm ".equ __impl_swapcontext, swapcontext"
module asm ".symver swapcontext, swapcontext@@@FBSD_1.2"

It seems the linker has special handling for @@@, as per:

https://github.com/llvm-mirror/lld/blob/master/ELF/SymbolTable.cpp#L320

but I am unsure as to why this does not appear to work with -flto.
Maybe Rafael has any ideas?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: projects/clang600-import and ld.lld

[Dimitry Andric]

On 12 Jan 2018, at 18:04, Shawn Webb <shawn.w...@hardenedbsd.org> wrote:
> 
> On Fri, Jan 12, 2018 at 10:26:59AM -0500, Shawn Webb wrote:
>> On Fri, Jan 12, 2018 at 04:17:50PM +0100, Dimitry Andric wrote:
>>> On 12 Jan 2018, at 15:38, Shawn Webb <shawn.w...@hardenedbsd.org> wrote:
>>>> 
>>>> I know it's early in the game, but I thought I'd report this anyways.
>>>> I have lld as the default linker (MK_LLD_IS_LD=yes). When lld tries to
>>>> link usr.bin/clang/llvm-extract/llvm-extract, lld errors out with some
>>>> unresolved symbols. The log is below.
>>>> 
>>>> Has anyone else run into this?
>>>> 
>>>> /usr/obj/scratch/hbsd-playground/amd64.amd64/tmp/usr/bin/ld: error: 
>>>> undefined symbol: compressBound
>>>>>>> referenced by Compression.cpp:63 
>>>>>>> (/scratch/hbsd-playground/contrib/llvm/lib/Support/Compression.cpp:63)
>>>>>>> Compression.o:(llvm::zlib::compress(llvm::StringRef, 
>>>>>>> llvm::SmallVectorImpl&, llvm::zlib::CompressionLevel)) in archive 
>>>>>>> /usr/obj/scratch/hbsd-playground/amd64.amd64
>>>> /lib/clang/libllvm/libllvm.a
...
> I've attached a patch which allows buildworld to succeed on
> HardenedBSD's retpoline branch.

Committed in r327918.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: projects/clang600-import and ld.lld

[Dimitry Andric]

On 12 Jan 2018, at 15:38, Shawn Webb  wrote:
> 
> I know it's early in the game, but I thought I'd report this anyways.
> I have lld as the default linker (MK_LLD_IS_LD=yes). When lld tries to
> link usr.bin/clang/llvm-extract/llvm-extract, lld errors out with some
> unresolved symbols. The log is below.
> 
> Has anyone else run into this?
> 
> /usr/obj/scratch/hbsd-playground/amd64.amd64/tmp/usr/bin/ld: error: undefined 
> symbol: compressBound
 referenced by Compression.cpp:63 
 (/scratch/hbsd-playground/contrib/llvm/lib/Support/Compression.cpp:63)
  Compression.o:(llvm::zlib::compress(llvm::StringRef, 
 llvm::SmallVectorImpl&, llvm::zlib::CompressionLevel)) in archive 
 /usr/obj/scratch/hbsd-playground/amd64.amd64
> /lib/clang/libllvm/libllvm.a

It links fine for me, and I haven't heard any other reports of this, but
can you please try adding a line:

LIBADD+=z

to usr.bin/clang/llvm-extract/Makefile locally, and see if that fixes it
for you?

At some point I've tried minimizing the number of libraries pulled in,
and on my systems llvm-extract didn't use any of the compression
functions.  If you compile it differently, it could end up pulling in
those functions anyway.

Do you have any non-default settings in make.conf or src.conf?

-Dimitry

P.S. The clang600-import branch should be mostly ready for general
consumption, except for a number of ports that are still problematic,
see https://bugs.freebsd.org/224669



signature.asc
Description: Message signed with OpenPGP

Re: Is -march/-mtune=native actually supported on FreeBSD arm* or aarch64?

[Dimitry Andric]

On 5 Jan 2018, at 06:52, Jan Beich  wrote:
> 
> Some ports pass -march=native and/or -mtune=native. Both are extensively
> documented by GCC for x86. For other architectures some excerpts say
> "native" is only supported on Linux (via /proc/cpuinfo). For example,
> 
>  $ uname -p
>  armv6
>  $ echo 'int main() {}' >a.c
>  $ clang -march=native a.c
>  clang: error: the clang compiler does not support '-march=native'
>  $ clang -mtune=native a.c
>  $ pkg install -qy gcc7
>  $ gcc7 -march=native a.c
>  $ gcc7 -mtune=native a.c
> 
>  $ uname -p
>  aarch64
>  $ echo 'int main() {}' >a.c
>  $ clang -march=native a.c
>  clang: error: the clang compiler does not support '-march=native'
>  $ clang -mtune=native a.c
>  clang: error: the clang compiler does not support '-mtune=native'
>  $ pkg install -qy gcc7
>  $ gcc7 -march=native a.c
>  $ gcc7 -mtune=native a.c
> 
> What's the rationale for Clang vs. GCC difference? Is it safe to run
> FreeBSD arm* -mtune=native binaries on CPUs older than build machine?

On non-x86, llvm has not implemented CPU detection, as far as I know.
And since we don't export any CPU identification sysctl or even a
/proc/cpuinfo, getting that information from userland is tricky.  (I've
seen programs that attempt to parse /var/run/dmesg.boot, but it is
very error-prone, obviously.)

It is safer to just specify the target CPU explicitly, IMO.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: ARM broken since a while

[Dimitry Andric]

On 25 Nov 2017, at 22:10, Pedro Giffuni  wrote:
> 
> On 11/25/17 15:28, Pedro Giffuni wrote:
>> 
>> ...
>> 
>> I have seen problems on arm with zstd though.
>> 
> For the record:
> arm.armv6 buildworld failed, check _.arm.armv6.buildworld for details
> 
> ===> lib/libzstd (all)
> Assertion failed: (LiveCPSR && "CPSR liveness tracking is wrong!"), function 
> UpdateCPSRUse, file 
> /usr/src/contrib/llvm/lib/Target/ARM/Thumb2SizeReduction.cpp, line 961.
> cc: error: unable to execute command: Abort trap (core dumped)

This is probably after the most recent zstd import, see also:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223072

and

https://bugs.llvm.org/show_bug.cgi?id=35023

No progress at all upstream, though. :-/

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: lib/clan/llvm.build.mk: Shouldn't BUILD_TRIPLE definition rely host 'cc -dumpmachine'?

[Dimitry Andric]

On 27 Oct 2017, at 08:23, Eddy Petrișor  wrote:
> 
> I am trying to make the FreeBSD code base build from a Linux host and
> found this bit which defines BUILD_TRIPLE in a way which to my
> untrained eyes look like overengineering.
> 
> .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} == "")
> TARGET_ABI=-gnueabihf
> .elif ${TARGET_ARCH:Marm*}
> TARGET_ABI=-gnueabi
> .else
> TARGET_ABI=
> .endif
> VENDOR=unknown
> OS_VERSION=freebsd12.0
> 
> TARGET_TRIPLE?=
> ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${TARGET_ABI}
> BUILD_TRIPLE?=
> ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}

I don't see much overengineering here? :)  We simply trust BUILD_ARCH,
as it is passed in by the top-level Makefile.inc1.  This is how most of
these down-level Makefiles work.  Running all kinds of commands to
figure out architectures and the like should be avoided in such
Makefiles.

> To support a Linux host I made these changes that is using 'cc
> -dumpmachine' to get the correct BUILD_TRIPLE,

Unfortunately, this is the wrong option to do so.  The gcc manual says:

-dumpmachine
  Print the compiler’s target machine (for example, ‘i686-pc-linux-gnu’)
  -and don’t do anything else.

E.g, it prints the *target* tripe, not the build triple.


> but I am wondering if
> it shouldn't be OK for building on a FreeBSD host
> 
> .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} == "")
> TARGET_ABI=-gnueabihf
> .elif ${TARGET_ARCH:Marm*}
> TARGET_ABI=-gnueabi
> .else
> TARGET_ABI=
> .endif
> VENDOR=unknown
> OS_VERSION=freebsd12.0
> +BUILD_OS!=uname -s
> +

Again, this should be set by the top-level Makefiles, not in this one.

> 
> TARGET_TRIPLE?=
> ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${TARGET_ABI}
> +.if ${BUILD_OS} == FreeBSD
> BUILD_TRIPLE?=
> ${BUILD_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}
> +.else
> +HOST_CC_DUMPMACHINE!=cc -dumpmachine
> +BUILD_TRIPLE?=${HOST_CC_DUMPMACHINE}
> +.endif
> 
> What do you think, should the code be instead:
> 
> .if ${TARGET_ARCH:Marmv6*} && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} == "")
> TARGET_ABI=-gnueabihf
> .elif ${TARGET_ARCH:Marm*}
> TARGET_ABI=-gnueabi
> .else
> TARGET_ABI=
> .endif
> VENDOR=unknown
> OS_VERSION=freebsd12.0
> 
> TARGET_TRIPLE?=
> ${TARGET_ARCH:C/amd64/x86_64/:C/arm64/aarch64/}-${VENDOR}-${OS_VERSION}${TARGET_ABI}
> +HOST_CC_DUMPMACHINE!=cc -dumpmachine
> +BUILD_TRIPLE?=${HOST_CC_DUMPMACHINE}

No, this is definitely incorrect, as stated above.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Buildfailures with ld.lld

[Dimitry Andric]

On 14 Aug 2017, at 19:41, Shawn Webb <shawn.w...@hardenedbsd.org> wrote:
> 
> On Mon, Aug 14, 2017 at 07:38:28PM +0200, Dimitry Andric wrote:
>> On 14 Aug 2017, at 18:40, Shawn Webb <shawn.w...@hardenedbsd.org> wrote:
>>> 
>>> On Mon, Aug 14, 2017 at 07:28:39PM +0300, Johannes Jost Meixner wrote:
>>>> I'm seeing a few `undefined references` trying to build recent base on
>>>> HardenedBSD with clang 5.0.0:
>>>> 
>>>> https://dpaste.de/FThb/raw
>>>> 
>>>> Would you know what I am missing here?
>>> 
>>> Hey Johannes,
>>> 
>>> It looks like contrib/llvm/lib/DebugInfo/DWARF/DWARFDebugPubTable.cpp
>>> isn't included in the Makefile for usr.bin/lld.
>>> 
>>> I'm wondering if the lib/DebugInfo/DWARF files should be included in
>>> usr.bin/lld/Makefile. dim@, could you verify?
>> 
>> Those files are already in lib/clang/libllvm/Makefile.  How can this
>> particular error be reproduced?  I just did a fresh clone of hardenedbsd
>> master, and it built just fine for me, with an empty make.conf and
>> src.conf.
> 
> Johannes is trying to build ports-mgmt/pkg in HardenedBSD
> 12-CURRENT/amd64, where MK_LLD_IS_LD is default to yes. If you use the
> HardenedBSD ports tree, ports-mgmt/pkg is patched to allow a configure
> argument to enable SafeStack for pkg(8) and pkg-static(8)
> (--enable-safestack).
> 
> Reproduction steps:
> 
> 1. Install HardenedBSD 12-CURRENT/amd64
> 2. Fetch HardenedBSD's ports tree
> 3. Attempt to build ports-mgmt/pkg

I don't see why pkg is trying to build lld?  It's just a package
management tool.  Or are you building some sort of jail, e.g. in
poudriere?

For me, it's easiest to have a reproduction scenario where I can build
either FreeBSD head or HardenedBSD master, with some specific src.conf
settings.  So maybe MK_LLD_IS_LD would cause this problem?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: Buildfailures with ld.lld

[Dimitry Andric]

On 14 Aug 2017, at 18:40, Shawn Webb  wrote:
> 
> On Mon, Aug 14, 2017 at 07:28:39PM +0300, Johannes Jost Meixner wrote:
>> I'm seeing a few `undefined references` trying to build recent base on
>> HardenedBSD with clang 5.0.0:
>> 
>> https://dpaste.de/FThb/raw
>> 
>> Would you know what I am missing here?
> 
> Hey Johannes,
> 
> It looks like contrib/llvm/lib/DebugInfo/DWARF/DWARFDebugPubTable.cpp
> isn't included in the Makefile for usr.bin/lld.
> 
> I'm wondering if the lib/DebugInfo/DWARF files should be included in
> usr.bin/lld/Makefile. dim@, could you verify?

Those files are already in lib/clang/libllvm/Makefile.  How can this
particular error be reproduced?  I just did a fresh clone of hardenedbsd
master, and it built just fine for me, with an empty make.conf and
src.conf.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

[Dimitry Andric]

On 29 Jul 2017, at 01:59, Tijl Coosemans <t...@freebsd.org> wrote:
> 
> On Fri, 28 Jul 2017 19:54:04 +0200 Dimitry Andric <d...@freebsd.org> wrote:
>> On 28 Jul 2017, at 13:55, Tijl Coosemans <t...@freebsd.org> wrote:
>>> 
>>> On Thu, 27 Jul 2017 21:42:01 + pkg-fall...@freebsd.org wrote:
>> ...
>>>> In file included from squirrel/squirrel/sqvm.cc:5:
>>>> In file included from /usr/include/c++/v1/math.h:310:
>>>> /usr/include/c++/v1/limits:149:85: error: expected expression
>>>>   _LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type max() _NOEXCEPT 
>>>> {return type();}
>>>>
>>>>^
>>>> squirrel/squirrel/sqobject.h:131:24: note: expanded from macro 'type'
>>>> #define type(obj) ((obj)._type)
>>>>  ^
>>> 
>>> Simutrans code defines 'type' as a macro.  Shouldn't libc++ headers use
>>> _type or __type or something?
>> 
>> No, the member name 'type' is used in many classes in the C++ standard
>> library, for example all the traits in .  Programs should
>> not attempt to redefine this, at least not as a macro.
>> 
>> Note that this also doesn't work with libstdc++, e.g.:
>> 
>> $ cat boom.cpp
>> #define type "nope, this will not work"
>> #include 
>> 
>> and then:
>> 
>> $ g++ -c boom.cpp
>> boom.cpp:1:14: error: expected unqualified-id before string constant
>> #define type "nope, this will not work"
>>  ^
>> boom.cpp:1:14: error: expected class-name before string constant
>> #define type "nope, this will not work"
>>  ^
>> boom.cpp:1:14: error: expected '{' before string constant
>> boom.cpp:1:14: error: expected class-name before string constant
>> #define type "nope, this will not work"
>>  ^
>> boom.cpp:1:14: error: expected '{' before string constant
>> boom.cpp:1:14: error: expected class-name before string constant
>> #define type "nope, this will not work"
>>  ^
>> boom.cpp:1:14: error: expected '{' before string constant
>> boom.cpp:1:14: error: expected class-name before string constant
>> #define type "nope, this will not work"
>>  ^
>> boom.cpp:1:14: error: expected '{' before string constant
>> boom.cpp:1:14: error: expected unqualified-id before string constant
>> #define type "nope, this will not work"
>>  ^
>> In file included from boom.cpp:3:0:
>> /usr/local/lib/gcc6/include/c++/type_traits:212:60: error: template argument 
>> 1 is invalid
>> : public __is_void_helper::type>::type
>>^
>> /usr/local/lib/gcc6/include/c++/type_traits:212:61: error: expected '{' 
>> before '::' token
>> : public __is_void_helper::type>::type
>> ^~
>> [...and lots more errors like this...]
> 
> The code does not include  or any of that C++11 stuff.  It
> includes .  This works with libstdc++ because it doesn't have
> , but it would also work when  was included, because
> libstdc++ uses __type everywhere (and __enable_if and __is_arithmetic,
> etc. where libc++ headers use enable_if and is_arithmetic).  The
> libstdc++ way makes more sense.  You cannot expect C++98 code to know
> about reserved identifiers in C++11 or C++11 code to know about reserved
> identifiers in later standards.

The usage of "type" as a name has been in libc++ since it was first
imported upstream about 7 years ago, and the failure you showed is the
first instance of such a name clash I have ever heard of.  Therefore, I
don't think it is too much trouble to change one older program to use a
slightly different define.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: [package - head-amd64-default][games/simutrans] Failed for simutrans-120.2.2 in build

[Dimitry Andric]

On 28 Jul 2017, at 13:55, Tijl Coosemans  wrote:
> 
> On Thu, 27 Jul 2017 21:42:01 + pkg-fall...@freebsd.org wrote:
...
>> In file included from squirrel/squirrel/sqvm.cc:5:
>> In file included from /usr/include/c++/v1/math.h:310:
>> /usr/include/c++/v1/limits:149:85: error: expected expression
>>_LIBCPP_INLINE_VISIBILITY static _LIBCPP_CONSTEXPR type max() _NOEXCEPT 
>> {return type();}
>>  
>>   ^
>> squirrel/squirrel/sqobject.h:131:24: note: expanded from macro 'type'
>> #define type(obj) ((obj)._type)
>>   ^
> 
> Simutrans code defines 'type' as a macro.  Shouldn't libc++ headers use
> _type or __type or something?

No, the member name 'type' is used in many classes in the C++ standard
library, for example all the traits in .  Programs should
not attempt to redefine this, at least not as a macro.

Note that this also doesn't work with libstdc++, e.g.:

$ cat boom.cpp
#define type "nope, this will not work"
#include 

and then:

$ g++ -c boom.cpp
boom.cpp:1:14: error: expected unqualified-id before string constant
 #define type "nope, this will not work"
  ^
boom.cpp:1:14: error: expected class-name before string constant
 #define type "nope, this will not work"
  ^
boom.cpp:1:14: error: expected '{' before string constant
boom.cpp:1:14: error: expected class-name before string constant
 #define type "nope, this will not work"
  ^
boom.cpp:1:14: error: expected '{' before string constant
boom.cpp:1:14: error: expected class-name before string constant
 #define type "nope, this will not work"
  ^
boom.cpp:1:14: error: expected '{' before string constant
boom.cpp:1:14: error: expected class-name before string constant
 #define type "nope, this will not work"
  ^
boom.cpp:1:14: error: expected '{' before string constant
boom.cpp:1:14: error: expected unqualified-id before string constant
 #define type "nope, this will not work"
  ^
In file included from boom.cpp:3:0:
/usr/local/lib/gcc6/include/c++/type_traits:212:60: error: template argument 1 
is invalid
 : public __is_void_helper::type>::type
^
/usr/local/lib/gcc6/include/c++/type_traits:212:61: error: expected '{' before 
'::' token
 : public __is_void_helper::type>::type
 ^~
[...and lots more errors like this...]

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: amd64 -r321109 -> -r321371 buildworld update failed (spans clang 5 update); error: too few arguments provided to function-like macro invocation; , METAMODE and -j8 was used

[Dimitry Andric]

On 23 Jul 2017, at 02:02, Mark Millard <mar...@dsl-only.net> wrote:
> 
> On 2017-Jul-22, at 4:50 PM, Dimitry Andric <d...@freebsd.org> wrote:
>> On 23 Jul 2017, at 01:32, Mark Millard <mar...@dsl-only.net> wrote:
>>> 
>>> My first attempt to update amd64 to a clang 5 based /usr/src
>>> failed ( -r321109 -> -r321371 ). Listing just the first
>>> error initially:
>>> 
>>> --- ToolDrivers/llvm-lib/LibDriver.o ---
>>> In file included from 
>>> /usr/src/contrib/llvm/lib/ToolDrivers/llvm-lib/LibDriver.cpp:35:
>>> /usr/obj/amd64_clang/amd64.amd64/usr/src/lib/clang/libllvm/Options.inc:27:92:
>>>  error: too few arguments provided to function-like macro invocation
>>> OPTION(prefix_0, "", INPUT, Input, INVALID, INVALID, nullptr, 0, 0, 
>>> nullptr, nullptr)
>>> 
>>> ^
>>> /usr/src/contrib/llvm/lib/ToolDrivers/llvm-lib/LibDriver.cpp:34:9: note: 
>>> macro 'OPTION' defined here
>>> #define OPTION(_1, _2, ID, _4, _5, _6, _7, _8, _9, _10, _11, _12) OPT_##ID,
>>>  ^
>> 
>> Yeah, I think this can happen with an incremental build, and if you
>> enable MK_CLANG_EXTRAS.  There was only one Options.inc file first, in
>> $WORLDTMP/usr/src/lib/clang/libllvm, but now there are two different
>> ones, under $WORLDTMP/usr/src/lib/clang/libllvm/llvm-lib and
>> $WORLDTMP/usr/src/lib/clang/libllvm/llvm-dlltool.  This is a rather
>> unfortunate change from upstream.
>> 
>> I'm unsure what to do here, maybe it is a good idea to explicitly rm
>> the incorrect file before make starts to search the directory.  Bryan,
>> any clues?  IIRC there were some other precedents where stale objects
>> could get in the way, and would have to be force-deleted before even
>> the depend stage?
> 
> I've done:
> 
> # mv /usr/obj/amd64_clang /usr/obj/amd64_clang_r321109_r321371
> 
> before starting a rebuild --in to preserve my
> failed-build context in case that record of
> the result of the attempt can help.

What you could try with the old objdir is:

rm /usr/obj/amd64_clang/amd64.amd64/usr/src/lib/clang/libllvm/Options.inc

then doing another incremental build.  I think that will work.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: amd64 -r321109 -> -r321371 buildworld update failed (spans clang 5 update); error: too few arguments provided to function-like macro invocation; , METAMODE and -j8 was used

[Dimitry Andric]

On 23 Jul 2017, at 01:32, Mark Millard  wrote:
> 
> My first attempt to update amd64 to a clang 5 based /usr/src
> failed ( -r321109 -> -r321371 ). Listing just the first
> error initially:
> 
> --- ToolDrivers/llvm-lib/LibDriver.o ---
> In file included from 
> /usr/src/contrib/llvm/lib/ToolDrivers/llvm-lib/LibDriver.cpp:35:
> /usr/obj/amd64_clang/amd64.amd64/usr/src/lib/clang/libllvm/Options.inc:27:92: 
> error: too few arguments provided to function-like macro invocation
> OPTION(prefix_0, "", INPUT, Input, INVALID, INVALID, nullptr, 0, 0, 
> nullptr, nullptr)
>   
> ^
> /usr/src/contrib/llvm/lib/ToolDrivers/llvm-lib/LibDriver.cpp:34:9: note: 
> macro 'OPTION' defined here
> #define OPTION(_1, _2, ID, _4, _5, _6, _7, _8, _9, _10, _11, _12) OPT_##ID,
>^

Yeah, I think this can happen with an incremental build, and if you
enable MK_CLANG_EXTRAS.  There was only one Options.inc file first, in
$WORLDTMP/usr/src/lib/clang/libllvm, but now there are two different
ones, under $WORLDTMP/usr/src/lib/clang/libllvm/llvm-lib and
$WORLDTMP/usr/src/lib/clang/libllvm/llvm-dlltool.  This is a rather
unfortunate change from upstream.

I'm unsure what to do here, maybe it is a good idea to explicitly rm
the incorrect file before make starts to search the directory.  Bryan,
any clues?  IIRC there were some other precedents where stale objects
could get in the way, and would have to be force-deleted before even
the depend stage?

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: head -r320458 (e.g.) amd64 -> powerpc (32-bit) cross-buildworld fails for time libc++ static_asserts and overflow/underflow of long long (system clang/clang++ 4 based build)

[Dimitry Andric]

On 29 Jun 2017, at 12:04, Mark Millard  wrote:
> 
> [The libc++ code in question appears to not be ready for
> 32-bit contexts with 64 bit times. Disable
> experimental/filesystem for now? I've submitted
> llvm bugzilla 33638 for the issue and have
> added it to llvm's 25780, the FreeBSD META for
> clang.]

Yes, this also broke earlier on arm and mips, which is why there is the
following in lib/Makefile:

.if ${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips"
_libcplusplus+= libc++experimental
.endif

I haven't yet found the time to address this issue.  Upstream should
already be aware of it, though.

One nasty problem with this is that it is not possible to figure out at
compile time what the size of time_t is.  You always need some sort of
configure-time test, and an external define.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: arm64 on head -r320059 (e.g.) fails buildkernel with only kernel-toolchain first (not buildworld) [Bugzilla 220125]

[Dimitry Andric]

On 21 Jun 2017, at 02:15, Ryan Stone <ryst...@gmail.com> wrote:
> 
> On Mon, Jun 19, 2017 at 2:57 AM, Dimitry Andric <d...@freebsd.org> wrote:
> 
>> Solution B is problematic because arm_neon.h uses stdint.h types
>> extensively.
>> 
> 
> If I manually modify the arm_neon.h file to instead say this, the problem
> is avoided and the kernel builds:
> 
> #ifdef _KERNEL
> #include 
> #else
> #include 
> #endif
> 
> Do you think that the llvm devs would be willing to take a change to
> NeonEmitter that does this on FreeBSD?
> 
> This may not be a complete solution, though, as googling seems to indicate
> that gcc also provides a arm_neon.h and it also #includes 

Indeed.  It seems this header is not really designed to be included from
kernel space.  It is probably easiest to provide a kernel wrapper for
stdint.h, maybe even just for arm.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: arm64 on head -r320059 (e.g.) fails buildkernel with only kernel-toolchain first (not buildworld) [Bugzilla 220125]

[Dimitry Andric]

On 19 Jun 2017, at 08:46, Mark Millard  wrote:
> 
> This is a variant of the wording in bugzilla 220125:
> 
> Unless buildworld (not just kernel-toolchain) is used before
> buildkernel the result for arm64 is:
> 
> --- armv8_crypto_wrap.o ---
> In file included from /usr/src/sys/crypto/armv8/armv8_crypto_wrap.c:46:
> /usr/obj/cortexA53dbg_clang/arm64.aarch64/usr/src/tmp/usr/bin/../lib/clang/4.0.0/include/arm_neon.h:31:10:
> fatal error: 'stdint.h' file not found
...
> A) kernel-toolchain needs to establish a stdint.h
>   that would be found
> vs.
> B) arm_neon.h needs to avoid needing stdint.h
>   (presumes armv8_crypto_wrap.c is correct to
>include arm_neon.h )
> 
> at least if the kernel-toolchain then buildkernel
> sequence is to be supported for arm64.

Solution A is problematic because it then would require to install
headers into ${WORLDTMP}.  This is what buildworld does.

Solution B is problematic because arm_neon.h uses stdint.h types
extensively.

Maybe the solution with the least amount of work is to provide a
kernel-specific wrapper header with the stdint.h types.

Otherwise, just use buildworld before buildkernel.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: llvm FreeBSD powerpc ABI target bug fix: Re: [Bug 26519] Clang 4.0.0's "Target: powerpc-unknown-freebsd11.0" code generation is violating the SVR4 ABI (SEGV can result)

[Dimitry Andric]

On 4 May 2017, at 21:39, Mark Millard  wrote:
> 
> I just got a report of a fix for the FreeBSD
> powerpc ABI's code generation in llvm. It should
> fix a stack handling related problem that
> currently makes clang (through 4) largely useless
> for TARGET_ARCH=powerpc .
> 
> On 2017-May-4, at 12:26 PM, bugzilla-dae...@llvm.org wrote:
> 
>> Comment # 19 on bug 26519 from Krzysztof Parzyszek
>> Committed a fix in r302183.
>> 
>> You are receiving this mail because:
>>  • You reported the bug.
> 
> This would also apply to:
> 
> powerpc-unknown-freebsd12.0
> 
> not just 11.0
> 
> Hopefully it is an easy merge into
> clang 4.

Thanks for the notice.  I have merged the upstream fix into head in
r317810, and I will MFC it after a few days.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: WITH_LLD_IS_LD vs default WITHOUT_SYSTEM_COMPILER: What are the reasons?

[Dimitry Andric]

On 14 Apr 2017, at 22:40, Mark Millard  wrote:
> 
> man src.conf (from -r315914 ) reports:
> 
> WITH_LLD_IS_LD
> Set to use LLVM's LLD as the system linker, instead of GNU
> binutils ld.
> 
> This is a default setting on arm64/aarch64.  When set, these
> options are also in effect:
> 
> WITHOUT_SYSTEM_COMPILER (unless WITH_SYSTEM_COMPILER is set
> explicitly)
> 
> I'm curious about:
> 
> A) Why there is a bias to avoid the system compiler?

These are just the defaults, detected by the script that generates
src.conf.5.  The setting of MK_SYSTEM_COMPILER is actually dependent on
the host, so it's technically incorrect to have src.conf.5 mention that
it is off by default.


> and by contrast:
> 
> B) What sort of context justifies explicitly setting
>   WITH_SYSTEM_COMPILER when WITH_LLD_IS_LD is in use?

The settings are mostly orthogonal.  MK_SYSTEM_COMPILER was created to
avoid building a bootstrap compiler, if the system (host) compiler is
new enough.

At some point you could also image a MK_SYSTEM_LINKER setting, which
would avoid building the bootstrap linker, if the system linker is new
enough.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Dimitry Andric]

On 30 Mar 2017, at 19:55, Brooks Davis <bro...@freebsd.org> wrote:
> 
> On Thu, Mar 30, 2017 at 07:26:19PM +0200, Dimitry Andric wrote:
...
>> 
>> As said, this is because of WITH_DEBUG.  Don't use that for the llvm
>> ports, for now.  It will also allow you to build them with much less RAM
>> in the machine: especially linking can take multiple GB when debuginfo
>> is enabled, and optimization is off.
> 
> I'm looking into improving WITH_DEBUG.

I stole the following method from graphics/darktable:

Index: devel/llvm40/Makefile
===
--- devel/llvm40/Makefile   (revision 436685)
+++ devel/llvm40/Makefile   (working copy)
@@ -236,6 +236,11 @@ NOT_FOR_ARCH=  ia64

 .include 

+.if defined(WITH_DEBUG)
+CMAKE_BUILD_TYPE=  RelWithDebInfo
+STRIP=
+.endif
+
 _CRTLIBDIR=
${LLVM_PREFIX:S|${PREFIX}/||}/lib/clang/${LLVM_RELEASE}/lib/freebsd
 .if ${ARCH} == "amd64"
 _COMPILER_RT_LIBS= \

This appears to work for me.


> P.S. Somewhat off topice, but related.  FAIR WARNING: the days of
> self-hosted 32-bit systems are numbered.  Switching to lld from our
> ancient BFD linker will probably buy us some time, but I'd be surprised
> if you will be able to build LLVM+CLANG with a 2GB address space in 5
> years.  The sooner people make their peace with this, the better.

Yes, with that above RelWithDebInfo change, GNU ld tends to use ~5G of
memory to link the larger llvm executables, so that is definitely beyond
i386, even if you run it in a jail on an amd64 host.

And if you would want to use link time optimization, the requirements
will increase even more...

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Dimitry Andric]

On 30 Mar 2017, at 19:06, Alexey Dokuchaev <da...@freebsd.org> wrote:
> 
> On Mon, Mar 27, 2017 at 11:41:40AM +0200, Dimitry Andric wrote:
>> On 26 Mar 2017, at 23:36, Mark Millard <mar...@dsl-only.net> wrote:
>>> ...
>>> Also interesting was:
>>> 
>>> Installed packages to be REMOVED:
>>> llvm40-4.0.0.r4
>>> 
>>> Number of packages to be removed: 1
>>> 
>>> The operation will free 49 GiB.
>> 
>> Yes, this is big.  But there is no real need to build the llvm ports
>> with debug information, unless you want to hack on llvm itself.
> 
> Cc'ing jmd@ and rezny@.
> 
> I've been watching increasing size of our LLVM packages with increasing
> worry.  This is from my tinderbox cache:
> 
>  $ % env LANG=C ls -lh llvm3*
>  -rw-r--r--  1 root  wheel17M Jan 29  2016 llvm35-3.5.2_1.txz
>  -rw-r--r--  1 root  wheel18M Mar  7  2016 llvm36-3.6.2_2.txz
>  -rw-r--r--  1 root  wheel27M Feb 28 01:05 llvm37-3.7.1_4.txz
>  -rw-r--r--  1 root  wheel   207M Jan 19 18:20 llvm38-3.8.1_5.txz
>  -rw-r--r--  1 root  wheel   244M Mar 23 16:42 llvm39-3.9.1_2.txz
> 
> Dimitry, do you know what had causes such a huge bump in 37 -> 38?

Yes, up to llvm37, the ports were split in devel/llvmXY and lang/clangXY
parts, with separate ports for e.g. compiler-rt and other LLVM projects.

For llvm38 and later, the devel/llvmXY port contains almost *all*
upstream LLVM components, which are then selectable at port configure
time.  For instance, devel/llvm40 shows:

┌─── llvm40-4.0.0 ─┐
│ ┌──┐ │
│ │ [x] CLANGBuild clang │ │
│ │ [x] COMPILER_RT  Sanitizer libraries │ │
│ │ [x] DOCS Build and/or install documentation  │ │
│ │ [x] EXTRAS   Extra clang tools   │ │
│ │ [x] GOLD Build the LLVM Gold plugin for LTO  │ │
│ │ [x] LIT  Install lit and FileCheck test tools│ │
│ │ [x] LLD  Install lld, the LLVM linker│ │
│ │ [x] LLDB Install lldb, the LLVM debugger (ignored on 9.x)│ │
│ │ [x] OPENMP   Install libomp, the LLVM OpenMP runtime library │ │
│ └──┘ │
├──┤
│   <  OK  >   │
└──┘

If you want to reduce the size of the package, only select the part(s)
you need.  I think you can get by with just the CLANG option, for most
dependent ports.



> They take lots of time to build and package.  And given that llvm
> is indirect dependency of any X11-related port, it pessimises their
> build times as well (devel/libclc now requires devel/llvm40 after
> r437268).

The previous split looks pretty hard to maintain, so that is most likely
the reason for combining all components in one port after 3.8.
Unfortunately the side effect is that it is way less granular.

If we ever get infrastructure for generating multiple packages out of
one port, the devel/llvm* ports are very good candidates. :)


> With 49 GiB llvm40, I guess I won't be able to build-test post as my
> hardware would just not be capable enough.

As said, this is because of WITH_DEBUG.  Don't use that for the llvm
ports, for now.  It will also allow you to build them with much less RAM
in the machine: especially linking can take multiple GB when debuginfo
is enabled, and optimization is off.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Dimitry Andric]

On 29 Mar 2017, at 17:53, Brooks Davis  wrote:
> 
> On Mon, Mar 27, 2017 at 03:25:04AM -0700, Mark Millard wrote:
...
>> This is extreme enough that next time I synchronize
>> /usr/ports and it has a devel/llvm40 update I'll
>> likely rebuild devel/llvm40 without using WITH_DEBUG= .
>> I'm more concerned with the time it takes than with
>> the file system space involved.
> 
> In the case of LLVM, enabling debug builds does a LOT more than adding
> symbols.  It's much more like enabling WITNESS and INVARIANTS in your
> kernel, except that the performance of the resulting binary is much
> worse than a WITNESS kernel (more like 10x slowdown).
> 
> As Dimitry points out, these builds are of questionable value in ports
> so garbage collecting the knob might be the sensable thing to do.

I suggest that for the LLVM ports, the DEBUG option should set the
RelWithDebInfo build type for CMake.  That will give you binaries which
can produce good backtraces, and a fair chance at debugging, in a pinch.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Dimitry Andric]

On 27 Mar 2017, at 23:11, Mark Millard <mar...@dsl-only.net> wrote:
> 
> On 2017-Mar-27, at 5:53 AM, Dimitry Andric  wrote:
>> On 27 Mar 2017, at 12:25, Mark Millard  wrote:
>>> 
>>> On 2017-Mar-27, at 2:41 AM, Dimitry Andric <d...@freebsd.org> wrote:
>>>> On 26 Mar 2017, at 23:36, Mark Millard <mar...@dsl-only.net> wrote:
>> ...
>>>>> Installed packages to be REMOVED:
>>>>>   llvm40-4.0.0.r4
>>>>> 
>>>>> Number of packages to be removed: 1
>>>>> 
>>>>> The operation will free 49 GiB.
>>>> 
>>>> Yes, this is big.  But there is no real need to build the llvm ports
>>>> with debug information, unless you want to hack on llvm itself.  And
>>>> in that case, you are better served by a Subversion checkout or Git
>>>> clone from upstream instead.
>> ...
>>> Historically unless something extreme like this ends up
>>> involved I build everything using WITH_DEBUG=  or explicit
>>> -g's in order to have better information on any failure.
>> 
>> The problem with the ports implementation of WITH_DEBUG is that it
>> always disables all optimizations, without a possibility to override.
>> Which bloats the resulting object files, libraries and executables, and
>> especially so for large C++ projects such as LLVM.
>> 
>> I can recommend the following workaround.  If you want to build a port
>> with optimizations disabled, you can always pass -O0 in CFLAGS.
>> 
>> -Dimitry
>> 
>> Index: Mk/bsd.port.mk
>> ===
>> --- Mk/bsd.port.mk   (revision 436685)
>> +++ Mk/bsd.port.mk   (working copy)
>> @@ -1646,7 +1646,7 @@ MAKE_ENV+= DONTSTRIP=yes
>> STRIP_CMD=   ${TRUE}
>> .endif
>> DEBUG_FLAGS?=-g
>> -CFLAGS:=${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
>> +CFLAGS:=${CFLAGS} ${DEBUG_FLAGS}
>> .if defined(INSTALL_TARGET)
>> INSTALL_TARGET:= ${INSTALL_TARGET:S/^install-strip$/install/g}
>> .endif
> 
> Interesting. WITH_DEBUG's description in the file does not
> mention that stripping of optimization flags:
> 
> # WITH_DEBUG- If set, debugging flags are added to CFLAGS and the
> # binaries don't get stripped by INSTALL_PROGRAM or
> # INSTALL_LIB. Besides, individual ports might
> # add their specific to produce binaries for debugging
> # purposes. You can override the debug flags that are
> # passed to the compiler by setting DEBUG_FLAGS. It is
> # set to "-g" at default.
> 
> I'll probably give myself an override that I can specify in
> /etc/make.conf , such as:
> 
> # svnlite diff /usr/ports/Mk/bsd.port.mk
> Index: /usr/ports/Mk/bsd.port.mk
> ===
> --- /usr/ports/Mk/bsd.port.mk (revision 436747)
> +++ /usr/ports/Mk/bsd.port.mk (working copy)
> @@ -1646,7 +1646,11 @@
> STRIP_CMD=${TRUE}
> .endif
> DEBUG_FLAGS?= -g
> +.if defined(ALLOW_OPTIMIZATIONS_FOR_WITH_DEBUG)
> +CFLAGS:= ${CFLAGS} ${DEBUG_FLAGS}
> +.else
> CFLAGS:=  ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
> +.endif
> .if defined(INSTALL_TARGET)
> INSTALL_TARGET:=  ${INSTALL_TARGET:S/^install-strip$/install/g}
> .endif

Effectively, this gives some sort of support for three of CMake's build
types, e.g:
* Debug, which disables optimization, and obviously adds debuginfo
* Release, which optimizes for speed, and does not add debuginfo
* RelWithDebInfo, similar to Release but does add debuginfo

It would be nice if there was some way of directly utilizing these.  The
RelWithDebInfo target is very useful with the LLVM projects.

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: FYI: what it takes for RAM+swap to build devel/llvm40 with 4 processors or cores and WITH__DEBUG= (powerpc64 example)

[Dimitry Andric]

On 27 Mar 2017, at 12:25, Mark Millard <mar...@dsl-only.net> wrote:
> 
> On 2017-Mar-27, at 2:41 AM, Dimitry Andric <d...@freebsd.org> wrote:
>> On 26 Mar 2017, at 23:36, Mark Millard <mar...@dsl-only.net> wrote:
...
>>> Installed packages to be REMOVED:
>>> llvm40-4.0.0.r4
>>> 
>>> Number of packages to be removed: 1
>>> 
>>> The operation will free 49 GiB.
>> 
>> Yes, this is big.  But there is no real need to build the llvm ports
>> with debug information, unless you want to hack on llvm itself.  And
>> in that case, you are better served by a Subversion checkout or Git
>> clone from upstream instead.
...
> Historically unless something extreme like this ends up
> involved I build everything using WITH_DEBUG=  or explicit
> -g's in order to have better information on any failure.

The problem with the ports implementation of WITH_DEBUG is that it
always disables all optimizations, without a possibility to override.
Which bloats the resulting object files, libraries and executables, and
especially so for large C++ projects such as LLVM.

I can recommend the following workaround.  If you want to build a port
with optimizations disabled, you can always pass -O0 in CFLAGS.

-Dimitry

Index: Mk/bsd.port.mk
===
--- Mk/bsd.port.mk  (revision 436685)
+++ Mk/bsd.port.mk  (working copy)
@@ -1646,7 +1646,7 @@ MAKE_ENV+=DONTSTRIP=yes
 STRIP_CMD= ${TRUE}
 .endif
 DEBUG_FLAGS?=  -g
-CFLAGS:=   ${CFLAGS:N-O*:N-fno-strict*} ${DEBUG_FLAGS}
+CFLAGS:=   ${CFLAGS} ${DEBUG_FLAGS}
 .if defined(INSTALL_TARGET)
 INSTALL_TARGET:=   ${INSTALL_TARGET:S/^install-strip$/install/g}
 .endif



signature.asc
Description: Message signed with OpenPGP

Re: GCC i386 stack misalignment: [package - head-i386-default][graphics/rawtherapee-devel] Failed for rawtherapee-devel-5.0 in stage

[Dimitry Andric]

On 29 Jan 2017, at 19:35, Matthias Andree  wrote:
> whenever I've traced one of the attached SIGBUS issues on gcc-compiled
> i386 code with SSE2, I found that it was using unaligned 128-bit =
> 16-byte wide SSE2 access which also needs 16-byte aligned data
> (including stacks).

See these very old bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496

PR 40838 is 8 years old and still has status NEW, PR38496 has WONTFIX.

E.g. don't count on this getting fixed upstream.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [clang/lld 4.0.0 arm64] link failure in sys/boot/efi/loader

[Dimitry Andric]

On 23 Jan 2017, at 16:27, Shawn Webb  wrote:
> 
> Here's an interesting failure I'm seeing on HardenedBSD with clang 4.0.0
> bits mixed in:
> 
>  BEGIN LOG 
> cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/tmp -B/usr 
> -O2 -pipe -DHARDENEDBSD -DSKEIN_LOOP=111 
> -I/usr/src/sys/boot/efi/loader/../../arm64/libarm64 -msoft-float 
> -mgeneral-regs-only -I/usr/src/sys/boot/efi/loader 
> -I/usr/src/sys/boot/efi/loader/arch/arm64 
> -I/usr/src/sys/boot/efi/loader/../include 
> -I/usr/src/sys/boot/efi/loader/../include/arm64 
> -I/usr/src/sys/boot/efi/loader/../../../contrib/dev/acpica/include 
> -I/usr/src/sys/boot/efi/loader/../../.. 
> -I/usr/src/sys/boot/efi/loader/../../i386/libi386 
> -I/usr/src/sys/boot/efi/loader/../../zfs 
> -I/usr/src/sys/boot/efi/loader/../../../cddl/boot/zfs 
> -I/usr/src/sys/boot/efi/loader/../../../crypto/skein -DEFI_ZFS_BOOT -DNO_PCI 
> -DEFI -DSMBIOS_SERIAL_NUMBERS -DBOOT_FORTH 
> -I/usr/src/sys/boot/efi/loader/../../ficl 
> -I/usr/src/sys/boot/efi/loader/../../ficl/aarch64 
> -I/usr/src/sys/boot/efi/loader/../../fdt 
> -I/usr/obj/usr/src/sys/boot/efi/loader/../../fdt -DLOADER_FDT_SUPPORT 
> -DLOADER_DISK_SUPPORT -DLOADER_GPT_SUPPORT -DLOADER_MBR_SUPPORT 
> -I/usr/src/sys/boot/ficl -I/usr/src/sys/boot/ficl/aarch64 
> -I/usr/src/sys/boot/ficl/../common 
> -I/usr/src/sys/boot/efi/loader/../../common -ffreestanding -Wformat 
> -msoft-float -fshort-wchar -fPIC -g -DHAVE_LIBRESSL -std=gnu99 
> -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter 
> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wno-uninitialized 
> -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int 
> -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value 
> -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion 
> -Wno-unused-local-typedef -Wno-address-of-packed-member -Qunused-arguments  
> -Wl,-T/usr/src/sys/boot/efi/loader/arch/arm64/ldscript.arm64 -Wl,-Bsymbolic 
> -shared -nostdlib -Wl,-z,relro -Wl,-z,now -o loader.sym.full autoload.o 
> bootinfo.o conf.o copy.o devicename.o main.o self_reloc.o smbios.o vers.o 
> zfs.o skein.o skein_block.o exec.o start.o cache.o boot.o commands.o 
> console.o devopen.o interp.o interp_backslash.o interp_parse.o ls.o misc.o 
> module.o panic.o load_elf64.o reloc_elf64.o disk.o part.o crc32.o bcache.o 
> interp_forth.o  /usr/obj/usr/src/sys/boot/efi/loader/../../ficl/libficl.a 
> /usr/obj/usr/src/sys/boot/efi/loader/../libefi/libefi.a 
> /usr/obj/usr/src/sys/boot/efi/loader/../../fdt/libfdt.a 
> /usr/obj/usr/src/sys/boot/efi/loader/../../efi/fdt/libefi_fdt.a 
> /usr/obj/usr/src/sys/boot/efi/loader/../../../../lib/libstand/libstand.a
> /usr/bin/ld: error: Section has flags incompatible with others with the same 
> name autoload.o:(.text)
> /usr/bin/ld: error: /usr/src/sys/boot/ficl/ficl.c:(.rodata+0x0): can't create 
> dynamic relocation R_AARCH64_ABS64 against local symbol in readonly segment 
> defined in /usr/obj/usr/src/sys/boot/efi/loader/../../ficl/libficl.a(ficl.o)
> /usr/bin/ld: error: /usr/src/sys/boot/ficl/ficl.c:(.rodata+0x8): can't create 
> dynamic relocation R_AARCH64_ABS64 against local symbol in readonly segment 
> defined in /usr/obj/usr/src/sys/boot/efi/loader/../../ficl/libficl.a(ficl.o)

Not an AArch64 expert here, but if I understand correctly AArch64's
world must be linked with a ports version of binutils?  Ed, any clues
about this?  Then again, this could also point to some real problem with
the section flags.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: status of WITH_SHARED_TOOLCHAIN

[Dimitry Andric]

On 25 Dec 2016, at 19:21, Nikolai Lifanov  wrote:
> 
> I would like to understand why WITH_SHARED_TOOLCHAIN is not the default.

This has been a long standing tradition.  Mainly, because you could
theoretically rescue yourself out of some bad situations by being able
to compile yourself out of it, since statically linked executables won't
break if e.g. libc.so or ld-elf.so is screwed up.  This is also the
reason that /sbin/init and /rescue/rescue are statically linked.

Additionally, it could give a minor performance improvement, that is if
the slowdown caused by dynamic linking is not offset by reading a larger
executable.


> My Raspberry Pi 3 is self-hosting with -j4 and doesn't run out of memory
> if the toolchain is shared. Is there a downside to this option?

I normally always use WITH_SHARED_TOOLCHAIN, and I have yet to encounter
any problem with it.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Seeking help with some Clang trouble, compiling ceph

[Dimitry Andric]

On 21 Oct 2016, at 17:07, Willem Jan Withagen  wrote:
> 
> On 21-10-2016 15:09, Willem Jan Withagen wrote:
>> Hi,
>> 
>> All this Ceph stuff finally used to compile under FreeBSD.
>> And all testss completed correctly.
>> 
>> But somewhere in the Ceph-tree there was a lot of template and trait
>> code added/replaced.
>> Problem is that this compiles under GCC, but Clang throws an error. It
>> looks like it cannot select types of automagic conversion.
>> 
>> But this template/trait stuff is too much for me to wrap my head around.
>> I'm reading up a lot, but that does not yet get me anywhere.
>> 
>> So I was wondering if anybody with more C++ knowledge would like to
>> assist and give some clues as to how to fix this.
>> 
>> The error report is at:
>> 
>> http://cephdev.digiware.nl:8180/jenkins/job/ceph-freebsd/39/consoleFull
>> 
>> And the ceph code can be found at:
>> https://github.com/ceph/ceph
> 
> Oke, the preson responsable for the change helped to figure it out, and
> it looks like the following diff helps
> 
> diff --git a/src/include/denc.h b/src/include/denc.h
> index 59f7686..caa095b 100644
> --- a/src/include/denc.h
> +++ b/src/include/denc.h
> @@ -722,7 +722,7 @@ struct denc_traits<
> template
> struct denc_traits<
>   std::vector,
> -  typename std::enable_if::type> {
> +  typename std::enable_if::type> {
>   typedef denc_traits traits;
> 
>   enum { supported = true };
> @@ -831,7 +831,7 @@ struct denc_traits<
> template
> struct denc_traits<
>   std::set,
> -  typename std::enable_if::type> {
> +  typename std::enable_if::type> {
>   typedef denc_traits traits;
> 
>   enum { supported = true };
> 
> And the conclusion is that std::enable_if<> does not always like it when
> the value is 'int'.
> the definition of supported is:
> struct denc_traits {
>  enum { supported = 0 };
>  enum { featured = false };
>  enum { bounded = false };
> };
> 
> and values can range 0..2.
> 
> So is this a GCC liberalization, or is Clang here to picky?

It's hard to say without the full source code and a reproducer, but I'd
say that enable_if has a bool as the first template argument, so it
can't match an int by default.  Maybe libstdc++ has a variant with an
int as the first template argument, but I haven't looked.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: binutils 2.27 [not working for powerpc64 (and powerpc?)]

[Dimitry Andric]

Has anyone succeeded in bisecting upstream binutils, to see where this problem 
was introduced?

-Dimitry

On 20 Sep 2016, at 22:56, Mark Millard  wrote:
> 
> The below forward from freebsd-pcc's list confirms that binutils 2.27 not 
> working for powerpc64 (& powerpc?) contexts.
> 
> Note: Krzysztof Parzyszek is one of the two people that have recently been 
> working on updating clang/llvm for fixing some of the issues that block 
> FreeBSD from using clang for powerpc and powerpc64 for buildworld and 
> buildkernel.
> 
> ===
> Mark Millard
> markmi at dsl-only.net
> 
> On 2016-Sep-20, at 11:19 AM, Krzysztof Parzyszek  
> wrote:
> 
>> I've had similar problems after building gcc-4.8.  After reverting back to 
>> binutils 2.25 and rebuilding, it worked fine.
>> 
>> -Krzysztof
>> 
>> On 9/9/2016 11:32 AM, Bill Sorenson wrote:
>>> Everything I've built with the new binutils using either GCC 4.9, 5.4 or
>>> 6.2 instantly dumps when run. This is on an Xserve G5. Is this just me or
>>> is there something genuinely broken here?
>>> 
>>> Thanks,
>>> Bill



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: From llvm: Fwd: [Bug 26856] clang 3.8.0/powerpc/powerpc64's _Unwind_RaiseException code generation has messed up r31 (frame pointer) save/restore code (SEGV's can result) [another issue reported f

[Dimitry Andric]

On 31 Aug 2016, at 03:17, Mark Millard  wrote:
> 
> The below notice from Hal Finkel [via llvm's bugzilla] indicates that at 
> least part of llvm bug 26856 for powerpc64's is expected to have been fixed 
> by r280188 (likely on trunk?).

I merged the upstream fix to projects/clang390-import:

https://svnweb.freebsd.org/changeset/base/305681

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: From llvm: Fwd: [Bug 25780] [META] Using Clang as the FreeBSD/ppc system compiler [one item fixed on trunk]

[Dimitry Andric]

On 30 Aug 2016, at 08:28, Mark Millard  wrote:
> 
> llvm bug 19098 "clang and llvm should support -mminimal-toc and -mlongcall 
> for PowerPC" has been listed as fixed on llvm's trunk.
> 
> That leaves about 5 pending bugs in the list that the META bug 25780 
> currently has.

I merged the upstream fixes to projects/clang390-import:

https://svnweb.freebsd.org/changeset/base/305680

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: name conflict after upgrade to HEAD.

[Dimitry Andric]

On 24 Aug 2016, at 16:30, Willem Jan Withagen <w...@digiware.nl> wrote:
> 
> On 24-8-2016 15:23, Dimitry Andric wrote:
...
>> Can you show the full command line used to build the offending source
>> file?  Usually this is caused by an incorrect include directory search
>> order.  And most often, that is caused by build systems inserting
>> -isystem into compile command lines.
> 
> This is the full output of the failing compile
> 
> --WjW
> 
> [  3%] Building CXX object
> src/CMakeFiles/common.dir/common/perf_counters.cc.o
> cd /home/wjw/ceph/build/src && /usr/bin/CC
> -DCEPH_LIBDIR=\"/usr/local/lib\"
> -DCEPH_PKGLIBDIR=\"/usr/local/lib/ceph\"
> -I/home/wjw/ceph/build/src/include -I/home/wjw/ceph/src
> -I/usr/local/include -I/home/wjw/ceph/build/include
> -I/home/wjw/ceph/src/xxHash  -Wall -Wtype-limits -Wignored-qualifiers
> -Winit-self -Wpointer-arith -Werror=format-security -fno-strict-aliasing
> -fsigned-char -Wno-inconsistent-missing-override -Wno-mismatched-tags
> -Wno-unused-function -Wno-unused-local-typedef
> -Wno-inconsistent-missing-override -Wno-unused-private-field
> -Wno-varargs -Wno-gnu-designator -Wno-mismatched-tags
> -Wno-missing-braces -Wno-parentheses -Wno-deprecated-register
> -ftemplate-depth-1024 -Wno-invalid-offsetof -Wnon-virtual-dtor
> -Wno-overloaded-virtual -fdiagnostics-color=auto
> -I/usr/local/include/nss/nss -I/usr/local/include/nspr
> -fno-builtin-malloc -fno-builtin-calloc -fno-builtin-realloc
> -fno-builtin-free -O0 -g -fPIC   -DHAVE_CONFIG_H -D__CEPH__ -D_REENTRANT
> -D_THREAD_SAFE -D__STDC_FORMAT_MACROS -std=c++11 -o
> CMakeFiles/common.dir/common/perf_counters.cc.o -c
> /home/wjw/ceph/src/common/perf_counters.cc
> In file included from /home/wjw/ceph/src/common/perf_counters.cc:17:
> In file included from /home/wjw/ceph/src/common/perf_counters.h:21:
> In file included from /home/wjw/ceph/src/include/utime.h:18:
> /usr/include/c++/v1/math.h:845:37: error: reference to 'log' is ambiguous
> log(_A1 __lcpp_x) _NOEXCEPT {return log((double)__lcpp_x);}
>^
> /usr/include/c++/v1/math.h:845:1: note: candidate found by name lookup
> is 'log'
> log(_A1 __lcpp_x) _NOEXCEPT {return log((double)__lcpp_x);}
> ^
> /usr/include/c++/v1/math.h:839:46: note: candidate found by name lookup
> is 'log'
> inline _LIBCPP_INLINE_VISIBILITY long double log(long double __lcpp_x)
> _NOEXCEPT {return logl(__lcpp_x);}
> ^
> /usr/include/c++/v1/math.h:838:46: note: candidate found by name lookup
> is 'log'
> inline _LIBCPP_INLINE_VISIBILITY float   log(float __lcpp_x)
> _NOEXCEPT   {return logf(__lcpp_x);}
> ^
> /usr/include/math.h:247:8: note: candidate found by name lookup is 'log'
> double  log(double);
>^
> /home/wjw/ceph/src/common/ceph_context.h:44:13: note: candidate found by
> name lookup is 'ceph::log'
>  namespace log {
>^


Okay, no -isystem options there.  So that's not it.  Now I'm assuming
this is because the original .cc file includes , which imports a
global "log" symbol.  Can you try changing that include to ?
However, this could require prefixing some math function calls with
std::.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: name conflict after upgrade to HEAD.

[Dimitry Andric]

On 24 Aug 2016, at 12:14, Willem Jan Withagen  wrote:
> 
> While compile Ceph source code I run into this conflict of the usuage of
> 'log'
> 
> Now I've fixed it by prefixing the log with ::log on line 845.
> Which works for me, but I'm pretty sure that that is not the best solution.
...
> 
> In file included from /usr/include/c++/v1/cmath:301:
> /usr/include/c++/v1/math.h:845:37: error: reference to 'log' is ambiguous
> log(_A1 __lcpp_x) _NOEXCEPT {return log((double)__lcpp_x);}

Can you show the full command line used to build the offending source
file?  Usually this is caused by an incorrect include directory search
order.  And most often, that is caused by build systems inserting
-isystem into compile command lines.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Problems with out libgcc_s.so in base

[Dimitry Andric]

On 18 Aug 2016, at 11:15, Tijl Coosemans  wrote:
> 
> On Wed, 17 Aug 2016 14:17:10 -0700 Steve Kargl 
>  wrote:
...
>> % ldconfig -r | grep libgcc
>>6:-lgcc_s.1 => /lib/libgcc_s.so.1
>>735:-lgcc_s.1 => /usr/local/lib/gcc6/libgcc_s.so.1
>> 
>> Clearly, ldd is looking for 735 but finds 6.  If the lang/gcc6 could
>> be convinced to build, install, and use libgcc_s6.so.1, then the
>> problem is solved without a wrapper.
> 
> In this case the real cause of the problem is that compilers and linkers
> search /lib and /usr/lib last and ldconfig searches them first.  Renaming
> the library is just a hack around that.

Well, even if you would adjust the compilers and linkers to look in
/usr/local/lib first, how would you solve the problem of having
multiple, possibly incompatible versions of the same library in
different directories?

For example, on one of my systems, I now have these:

/usr/local/lib/gcc47/libgcc_s.so.1
/usr/local/lib/gcc48/libgcc_s.so.1
/usr/local/lib/gcc49/libgcc_s.so.1
/usr/local/lib/gcc5/libgcc_s.so.1
/usr/local/lib/gcc6/libgcc_s.so.1
/usr/local/lib/gcc7/libgcc_s.so.1

So which one are you going to put at the front of the path?  The gcc7
version?  If you are lucky that one is backwards compatible with all the
previous ones, but still I would like it much better if a program
compiled by, say, gcc5 was linked *explicitly* against the gcc5 version
of libgcc_s.so.

Steve's proposed scheme solves that quite nicely, in my opinion.  The
problem is only in the details, as usual.  There will be many configure
scripts and libtool-like utilities out there, that assume libgcc must be
linked using -lgcc_s, not -lgcc_s$VERSION.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Duplicate OPT_ entries in gcc/options.h

[Dimitry Andric]

On 09 Jun 2016, at 00:30, Jung-uk Kim <j...@freebsd.org> wrote:
> 
> On 06/ 8/16 06:16 PM, Dimitry Andric wrote:
>> On 08 Jun 2016, at 23:54, Jung-uk Kim <j...@freebsd.org> wrote:
>>> 
>>> On 06/ 8/16 05:15 PM, Dimitry Andric wrote:
>>>> On 08 Jun 2016, at 21:11, Gerald Pfeifer <ger...@pfeifer.com> wrote:
>>>>> 
>>>>> I got a user report, and could reproduce this, that building
>>>>> GCC (lang/gcc, but also current HEAD, so probably pretty much
>>>>> any version) with FreeBSD 11 and LANG = en_US.UTF-8 we get
>>>>> conflicting entires in $BUILDDIR/gcc/options.h such as
>> ...
>>>> Note that GNU awk does *not* produce a different optionlist file when
>>>> used with either LANG=C or LANG=en_US.UTF-8.
>> ...
>>>> So I am assuming that the ARRAY[j-1] > ARRAY[j] comparison works
>>>> differently in our awk, depending on the LANG settings.  No idea when
>>>> that changed, though, if it changed at all...
>>> 
>>> This behaviour is known for very long time:
>>> 
>>> https://svnweb.freebsd.org/changeset/base/173731
>>> 
>>> and it is not our fault:
>>> 
>>> https://www.gnu.org/software/gawk/manual/html_node/POSIX-String-Comparison.html
>> 
>> 
>> Indeed, so the real question is: why does this only started coming up
>> now, if it is known since 2007?  I have been building gcc ports for
>> ages, and never ran into this problem, but I also have never actively
>> used a persistent LANG environment variable, let alone with UTF-8 in it.
>> 
>> Is this because more people started using UTF-8 recently?
> 
> We are doing more correct collation now:
> 
> https://svnweb.freebsd.org/changeset/base/290494

Indeed.  This problem has come up before on the ports mailing list,
almost immediately after that commit:

https://lists.freebsd.org/pipermail/freebsd-ports/2015-November/101034.html

Apparently some proposals were made to set LANG and LC_ALL to C globally
for port builds, but it was never implemented?

I guess more people are now noticing it, because they are trying out the
11.0-ALPHA installers.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Duplicate OPT_ entries in gcc/options.h

[Dimitry Andric]

On 08 Jun 2016, at 23:15, Dimitry Andric <d...@freebsd.org> wrote:
> 
> On 08 Jun 2016, at 21:11, Gerald Pfeifer <ger...@pfeifer.com> wrote:
...
> Note that GNU awk does *not* produce a different optionlist file when
> used with either LANG=C or LANG=en_US.UTF-8.

And that phenomenon is explained here:

http://www.gnu.org/software/gawk/manual/gawk.html#POSIX-String-Comparison

"6.3.2.3 String Comparison with POSIX Rules

The POSIX standard says that string comparison is performed based on the
locale's collating order. This is the order in which characters sort, as
defined by the locale (for more discussion, see Locales). This order is
usually very different from the results obtained when doing straight
character-by-character comparison.34

Because this behavior differs considerably from existing practice, gawk
only implements it when in POSIX mode (see Options)."

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Duplicate OPT_ entries in gcc/options.h

[Dimitry Andric]

On 08 Jun 2016, at 21:11, Gerald Pfeifer  wrote:
> 
> I got a user report, and could reproduce this, that building
> GCC (lang/gcc, but also current HEAD, so probably pretty much
> any version) with FreeBSD 11 and LANG = en_US.UTF-8 we get
> conflicting entires in $BUILDDIR/gcc/options.h such as
> 
>  OPT_d = 135,   /* -d */
>  OPT_D = 136,   /* -D */
>  OPT_d = 137,   /* -d */
>  OPT_D = 138,   /* -D */
>  OPT_d = 141,   /* -d */
>  OPT_D = 142,   /* -D */
>  OPT_d = 143,   /* -d */
> 
> Using LANG = en_US (without UTF-8), everything works fine.
> 
> Any ideas what might be going on here?  (This is done via
> AWK scripts from what I can tell, does this trigger any
> ideas?)

It is definitely something caused by our awk in base, in any case.
First opt-gather.awk is run to generate a flat list of all options:

  /usr/bin/awk -f /usr/ports/lang/gcc/work/gcc-4.8.5/gcc/opt-gather.awk 
/usr/ports/lang/gcc/work/gcc-4.8.5/gcc/ada/gcc-interface/lang.opt 
/usr/ports/lang/gcc/work/gcc-4.8.5/gcc/fortran/lang.opt 
/usr/ports/lang/gcc/work/gcc-4.8.5/gcc/go/lang.opt 
/usr/ports/lang/gcc/work/gcc-4.8.5/gcc/java/lang.opt 
/usr/ports/lang/gcc/work/gcc-4.8.5/gcc/lto/lang.opt 
/usr/ports/lang/gcc/work/gcc-4.8.5/gcc/c-family/c.opt 
/usr/ports/lang/gcc/work/gcc-4.8.5/gcc/common.opt 
/usr/ports/lang/gcc/work/gcc-4.8.5/gcc/config/fused-madd.opt 
/usr/ports/lang/gcc/work/gcc-4.8.5/gcc/config/i386/i386.opt 
/usr/ports/lang/gcc/work/gcc-4.8.5/gcc/config/rpath.opt 
/usr/ports/lang/gcc/work/gcc-4.8.5/gcc/config/freebsd.opt > tmp-optionlist

Then opt-functions.awk is run to process optionlist into options.h:

  /usr/bin/awk -f /usr/ports/lang/gcc/work/gcc-4.8.5/gcc/opt-functions.awk -f 
/usr/ports/lang/gcc/work/gcc-4.8.5/gcc/opt-read.awk -f 
/usr/ports/lang/gcc/work/gcc-4.8.5/gcc/opth-gen.awk < optionlist > options.h

If I run the first step using LANG=C, or without any LANG setting, both
optionlist and options.h are as expected.  If I run the first step using
LANG=en_US.UTF-8, the optionlist is sorted differently, for example the
"good" optionlist has the uppercase d options first, and much later the
lowercase d options:

  D^\C ObjC C++ ObjC++ Joined Separate MissingArgError(macro name missing after 
%qs)^\-D[=]   Define a  with  as its value.  If just 
 is given,  is taken to be 1
  D^\Driver Joined Separate
  D^\Fortran Joined Separate
  ... much later in the file, after all options starting with an uppercase 
letter ...
  d^\C ObjC C++ ObjC++ Joined
  d^\Common Joined^\-d   Enable dumps from specific passes of the 
compiler
  d^\Fortran Joined
  d^\Java Separate SeparateAlias Alias(foutput-class-dir=)

The "bad" optionlist has the upper and lower case d options sorted
together:

  d^\C ObjC C++ ObjC++ Joined
  D^\C ObjC C++ ObjC++ Joined Separate MissingArgError(macro name missing after 
%qs)^\-D[=]   Define a  with  as its value.  If just 
 is given,  is taken to be 1
  d^\Common Joined^\-d   Enable dumps from specific passes of the 
compiler
  D^\Driver Joined Separate
  defsym=^\Driver JoinedOrMissing
  defsym^\Driver Separate
  d^\Fortran Joined
  D^\Fortran Joined Separate
  d^\Java Separate SeparateAlias Alias(foutput-class-dir=)

Note that GNU awk does *not* produce a different optionlist file when
used with either LANG=C or LANG=en_US.UTF-8.

opt-gather.awk's sorting function looks like this:

  function sort(ARRAY, ELEMENTS)
  {
  for (i = 2; i <= ELEMENTS; ++i) {
  for (j = i; ARRAY[j-1] > ARRAY[j]; --j) {
  temp = ARRAY[j]
  ARRAY[j] = ARRAY[j-1]
  ARRAY[j-1] = temp
  }
  }
  return
  }

So I am assuming that the ARRAY[j-1] > ARRAY[j] comparison works
differently in our awk, depending on the LANG settings.  No idea when
that changed, though, if it changed at all...

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: 11.0-CURRENT -r300770 libc++ update vs. lang/powerpc64-xtoolchain-gcc: no go [self hosted powerpc64 context]

[Dimitry Andric]

On 28 May 2016, at 06:18, Mark Millard  wrote:
...
> The -r300886 powerpc64 devel/powerpc64-gcc combination with no clang build 
> included has failed:
> 
> --- all_subdir_usr.bin ---
> endian.h(111): warning: bitwise operation on signed value possibly 
> nonportable [117]
> endian.h(127): warning: extra bits set to 0 in conversion of 'unsigned int' 
> to 'unsigned long long', op & [309]
> types.h(316): warning: bitwise operation on signed value possibly nonportable 
> [117]
> types.h(317): warning: bitwise operation on signed value possibly nonportable 
> [117]
> types.h(318): warning: bitwise operation on signed value possibly nonportable 
> [117]
> types.h(319): warning: bitwise operation on signed value possibly nonportable 
> [117]
> types.h(355): warning: conversion to 'unsigned int' due to prototype, arg #1 
> [259]
> types.h(355): warning: conversion from 'unsigned long long' to 'unsigned int' 
> may lose accuracy, arg #1 [298]
> types.h(355): warning: conversion to 'unsigned int' due to prototype, arg #1 
> [259]
> types.h(355): warning: conversion from 'unsigned long long' to 'unsigned int' 
> may lose accuracy, arg #1 [298]
> stdarg.h(40): syntax error [249]
> stdarg.h(98): syntax error [249]
> llib-lposix(307): syntax error [249]
> llib-lposix(308): syntax error [249]
> llib-lposix(309): syntax error [249]
> llib-lposix(309): cannot recover from previous errors [224]
> *** [llib-lposix.ln] Error code 1

For me, r300886 didn't build at all, when I tried:

CROSS_TOOLCHAIN=powerpc64-gcc TARGET=powerpc TARGET_ARCH=powerpc64 \
__MAKE_CONF=/dev/null SRCCONF=/dev/null make buildworld

It always errors out at the very first file built for the libraries
stage:

--
>>> stage 4.2: building libraries
--
cd /usr/src;  CROSS_TOOLCHAIN="powerpc64-gcc" MAKEOBJDIRPREFIX=/usr/obj  
MACHINE_ARCH=i386  MACHINE=i386  CPUTYPE= 
GROFF_BIN_PATH=/usr/obj/usr/src/tmp/legacy/usr/bin  
GROFF_FONT_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/groff_font  
GROFF_TMAC_PATH=/usr/obj/usr/src/tmp/legacy/usr/share/tmac 
CC="/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc 
--sysroot=/usr/obj/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/" 
CXX="/usr/local/bin/powerpc64-portbld-freebsd11.0-g++  
--sysroot=/usr/obj/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/"  
CPP="/usr/local/bin/powerpc64-portbld-freebsd11.0-cpp 
--sysroot=/usr/obj/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/"  
AS="/usr/local/powerpc64-freebsd/bin/as" 
AR="/usr/local/powerpc64-freebsd/bin/ar" 
LD="/usr/local/powerpc64-freebsd/bin/ld" NM=/usr/local/powerpc64-freebsd/bin/nm 
 OBJDUMP=/usr/local/powerpc64-freebsd/bin/objdump 
OBJCOPY="/usr/local/powerpc64-freebsd/bin/objcopy"  
RANLIB=/usr/local/powerpc64-freebsd/bin/ranlib 
STRINGS=/usr/local/powerpc64-freebsd/bin/  
SIZE="/usr/local/powerpc64-freebsd/bin/size"  INSTALL="sh 
/usr/src/tools/install.sh"  
PATH=/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin
 make  -f Makefile.inc1 DESTDIR=/usr/obj/usr/src/tmp -DNO_FSCHG MK_HTML=no 
-DNO_LINT MK_MAN=no  MK_PROFILE=no MK_TESTS=no MK_TESTS_SUPPORT=yes libraries
cd /usr/src;  make -f Makefile.inc1 _prereq_libs;  make -f Makefile.inc1 
_startup_libs;  make -f Makefile.inc1 _prebuild_libs;  make -f Makefile.inc1 
_generic_libs
===> gnu/lib/libssp/libssp_nonshared (obj,all,install)
building static ssp_nonshared library
/usr/local/powerpc64-freebsd/bin/ar -crD libssp_nonshared.a 
`NM='/usr/local/powerpc64-freebsd/bin/nm' NMFLAGS='' lorder ssp-local.o  | 
tsort -q`
/usr/local/powerpc64-freebsd/bin/ranlib -D libssp_nonshared.a
sh /usr/src/tools/install.sh  -C -o root -g wheel -m 444   libssp_nonshared.a 
/usr/obj/usr/src/tmp/usr/lib/
===> gnu/lib/libgcc (obj,all,install)
LC_ALL=C awk -f /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opt-functions.awk  
-f /usr/src/gnu/lib/libgcc/../../../contrib/gcc/opth-gen.awk  < optionlist > 
options.h
/usr/local/bin/powerpc64-portbld-freebsd11.0-gcc --sysroot=/usr/obj/usr/src/tmp 
-B/usr/local/powerpc64-freebsd/bin/ -c -O2 -pipe   -DIN_GCC -DIN_LIBGCC2 
-D__GCC_FLOAT_NOT_NEEDED  -DHAVE_GTHR_DEFAULT  
-I/usr/src/gnu/lib/libgcc/../../../contrib/gcclibs/include  
-I/usr/src/gnu/lib/libgcc/../../../contrib/gcc/config 
-I/usr/src/gnu/lib/libgcc/../../../contrib/gcc -I.  
-I/usr/src/gnu/lib/libgcc/../../usr.bin/cc/cc_tools -std=gnu99 
-Wno-error=unused-function -Wno-error=enum-compare 
-Wno-error=logical-not-parentheses -Wno-error=bool-compare 
-Wno-error=uninitialized -Wno-error=array-bounds -Wno-error=clobbered 
-Wno-error=cast-align -Wno-error=extra -Wno-error=attributes -Wno-error=inline 
-Wno-error=unused-but-set-variable -Wno-error=unused-value 
-Wno-error=strict-aliasing -Wno-error=address -fvisibility=hidden 
-DHIDE_EXPORTS -fPIC -fexceptions 

Re: svn commit: r297435 - head: still problems for stage 3 when gcc 4.2.1 is avoided (powerpc64 self-hosted build)

[Dimitry Andric]

On 01 Apr 2016, at 00:44, Warner Losh  wrote:
> 
>> On Mar 31, 2016, at 4:34 PM, Bryan Drewery  wrote:
>> I didn't realize the ports compiler was defaulting /usr/local/include
>> into the search path now.  It does not have /usr/local/lib in the
>> default library path as far as I can tell.  It's also broken for its
>> -rpath (noted in its pkg-message).  So having a default
>> /usr/local/include path seems odd.
> 
> It has for a while now. It’s one of the maddening inconsistencies that abound 
> in this
> area. I took a poll a while ago and there seemed to be widespread support for 
> adding
> it to the base compiler.

This was the main reason /usr/local/include was *not* included in the
base compiler, otherwise it would unpredictably pick up headers in
/usr/local/include during builds.  You can never know which conflicting
headers a certain user has installed in /usr/local/include... :)


>> Adding -isystem /usr/include to fix this is probably possible but
>> there's a risk someone will remove it as redundant.  In this case I wish
>> /usr/include was first but I'm not sure what impact that would have on
>> consumers expecting /usr/local/include (and /usr/local/lib) overrides to
>> work, though they would need to pass a -L /usr/local/lib anyhow and
>> would likely be passing -I /usr/local/lib too.
> 
> /usr/include should be first. But it isn’t. That’s another inconsistency that 
> was found
> when we looked at /usr/local stuff. Someone recently added /usr/local/bin to 
> the path,
> if I recall correctly.

Isn't that a bit of a bikeshed?  I guess some people would just as well
prefer /usr/local/include to be first, just like some people prefer
/usr/local/bin before /usr/bin in their PATH.

In any case, if such paths are added to external compilers, we better
make sure almost everything in buildworld uses -nostdinc, and specifying
exactly the include directories we need, and no others.  Cumbersome, but
maybe for a good cause.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: warning: DWARF2 only supports one section per compilation unit

[Dimitry Andric]

On 29 Mar 2016, at 16:45, Andriy Gapon  wrote:
> 
> I've noticed many messages like the following during amd64 buildworld with 
> very
> recent head:
> 
>> warning: DWARF2 only supports one section per compilation unit
>> .section .note.GNU-stack,"",%progbits
> 
> Reported sections varied (e.g. there was .rodata).
> The messages seem to be related to .s files.
> I hope that those are harmless?

These are harmless, and have been showing up for at least a year now.
Clang is just notifying you that due to DWARF2 limitations, it will not
emit debug info for more than one code section.

All such warnings in our tree are about artificially added sections,
such as .note.GNU-stack, .reloc and __xen_guest, and it is not likely
that anybody cares that those sections will not have debug info.

Lastly, I never found an option to shut up the warnings.  Well, apart
from using -gdwarf-4. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: CXXSTD=c++11

[Dimitry Andric]

On 25 Mar 2016, at 00:18, Bryan Drewery <bdrew...@freebsd.org> wrote:
> 
> On 3/24/2016 4:16 PM, Dimitry Andric wrote:
>> On 24 Mar 2016, at 23:54, Dimitry Andric <d...@freebsd.org> wrote:
>>> 
>>> On 24 Mar 2016, at 23:51, Bryan Drewery <bdrew...@freebsd.org> wrote:
>> ...
>>>> It fails without -std=c++11 (there's more discussion in that link and in
>>>> PR 205453).
>>> 
>>> Yeah, I also commented on PR 205453 in the past, but I still don't
>>> understand where the external gcc gets its _Static_assert macro from.
>>> Or whether it gets it at all.  Maybe we should place a hack for this in
>>> sys/cdefs.h?  We shouldn't litter contrib code with #ifdef GCC_VERSION
>>> blocks.
>> 
>> Hm, hacking around in cdefs.h also doesn't really help, because gcc
>> refuses to recognize either _Static_assert or static_assert when it's
>> not in C++11 mode.  Reading back https://reviews.freebsd.org/D1390, I
>> see that I originally wanted to avoid building libcxxrt with -std=c++11.
>> This was so you could even build it with gcc 4.2.1 from base.
>> 
>> However, it really doesn't make much sense to do so, and upstream
>> libcxxrt simply uses static_assert directly, and requires -std=c++11.  I
>> will update the libcxxrt build to do so, probably tomorrow.
>> 
> 
> Sounds good.

Done in r297299 [1].  I also imported libc++ r255683 [2], which should
fix llvm-cov compilation with g++, in r297322 [3].

-Dimitry

[1] https://svnweb.freebsd.org/changeset/base/297299
[2] http://reviews.llvm.org/rL255683
[3] https://svnweb.freebsd.org/changeset/base/297322



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: boost/asio/ip/resolver_query_base.hpp:96:3: warning: all paths through this function will call itself

[Dimitry Andric]

On 25 Mar 2016, at 20:15, Willem Jan Withagen  wrote:
> Any suggestions why I'm getting this warning/error in the ceph code:
> 
> In file included from log/Log.cc:12:
> In file included from /usr/local/include/boost/asio.hpp:63:
> In file included from /usr/local/include/boost/asio/ip/basic_resolver.hpp:24:
> In file included from 
> /usr/local/include/boost/asio/ip/basic_resolver_query.hpp:21:
> /usr/local/include/boost/asio/ip/resolver_query_base.hpp:96:3: warning: all 
> paths through this function will call
>  itself [-Winfinite-recursion]
> 
> Could be a boost error, but I have not seen any upgrades to a newer version.

It's a boost bug.  You can apply this trivial upstream fix:

https://github.com/boostorg/asio/commit/9e757605709cace0fc048ad284b2d6aa3ae784ac

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: CXXSTD=c++11

[Dimitry Andric]

On 24 Mar 2016, at 23:54, Dimitry Andric <d...@freebsd.org> wrote:
> 
> On 24 Mar 2016, at 23:51, Bryan Drewery <bdrew...@freebsd.org> wrote:
...
>> It fails without -std=c++11 (there's more discussion in that link and in
>> PR 205453).
> 
> Yeah, I also commented on PR 205453 in the past, but I still don't
> understand where the external gcc gets its _Static_assert macro from.
> Or whether it gets it at all.  Maybe we should place a hack for this in
> sys/cdefs.h?  We shouldn't litter contrib code with #ifdef GCC_VERSION
> blocks.

Hm, hacking around in cdefs.h also doesn't really help, because gcc
refuses to recognize either _Static_assert or static_assert when it's
not in C++11 mode.  Reading back https://reviews.freebsd.org/D1390, I
see that I originally wanted to avoid building libcxxrt with -std=c++11.
This was so you could even build it with gcc 4.2.1 from base.

However, it really doesn't make much sense to do so, and upstream
libcxxrt simply uses static_assert directly, and requires -std=c++11.  I
will update the libcxxrt build to do so, probably tomorrow.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: CXXSTD=c++11

[Dimitry Andric]

On 24 Mar 2016, at 23:51, Bryan Drewery <bdrew...@freebsd.org> wrote:
> 
> On 3/24/2016 3:45 PM, Bryan Drewery wrote:
>> On 3/24/2016 3:44 PM, Dimitry Andric wrote:
>>> On 24 Mar 2016, at 23:36, Bryan Drewery <bdrew...@freebsd.org> wrote:
>>>> 
>>>> Is there any problem with forcing -std=c++11 for all CXX/LIB_CXX builds
>>>> now?  We do this when using an external GCC since it doesn't default to
>>>> the c++11 standard quite yet.  As far as I understand, we require c++11
>>>> to build clang/libc++.
>>> 
>>> Yes, but it already passes -std=c++11 in the correct places, as far as I
>>> know.  E.g. during the clang and libc++ builds.
>>> 
>>> 
>>>> It seems to be the problem at
>>>> https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-October/001757.html
>>>> which I've fixed in an upcoming commit to properly pass -std=c++11 to
>>>> the lib32 build in CXXFLAGS.
>>> 
>>> Hm, is this occuring during the build of libcxxrt, or of libc++?  If it
>>> is the former, then it seems that the system headers don't properly
>>> declare _Static_assert() in that case.  I have no clue as to why, though
>>> maybe it's picking something up from gcc's famously "fixed" standard
>>> headers?
>>> 
>> 
>> libcxxrt.
>> 
>> My fix also includes passing the proper -isystem =/usr/include/c++/v1 path.
>> 
>> I'll try without the -std change.
>> 
>> 
> 
> It fails without -std=c++11 (there's more discussion in that link and in
> PR 205453).

Yeah, I also commented on PR 205453 in the past, but I still don't
understand where the external gcc gets its _Static_assert macro from.
Or whether it gets it at all.  Maybe we should place a hack for this in
sys/cdefs.h?  We shouldn't litter contrib code with #ifdef GCC_VERSION
blocks.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: CXXSTD=c++11

[Dimitry Andric]

On 24 Mar 2016, at 23:36, Bryan Drewery  wrote:
> 
> Is there any problem with forcing -std=c++11 for all CXX/LIB_CXX builds
> now?  We do this when using an external GCC since it doesn't default to
> the c++11 standard quite yet.  As far as I understand, we require c++11
> to build clang/libc++.

Yes, but it already passes -std=c++11 in the correct places, as far as I
know.  E.g. during the clang and libc++ builds.


> It seems to be the problem at
> https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-October/001757.html
> which I've fixed in an upcoming commit to properly pass -std=c++11 to
> the lib32 build in CXXFLAGS.

Hm, is this occuring during the build of libcxxrt, or of libc++?  If it
is the former, then it seems that the system headers don't properly
declare _Static_assert() in that case.  I have no clue as to why, though
maybe it's picking something up from gcc's famously "fixed" standard
headers?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: c++/libc++ help needed for chromium update

[Dimitry Andric]

On 17 Mar 2016, at 12:38, Christoph Moench-Tegeder  wrote:
...
>> Last but not least, please ask about this on the Chromium mailing lists.
>> There must be lots of C++ libraries out there with non-trivial std::pair
>> copy constructors, and they must have some sort of workaround for those.
> 
> It's in the nature of chromium that it's Open Source, but the list of
> target platforms is rather short - officially supported are Windows
> (and I don't know how many people build their own chromium there),
> OS X and Linux. Chromium tends to bundle a lot of dependencies, I
> believe the default build process on Linux even brings it's own
> private clang installation if you don't stop it. The only other
> "special" build I'm aware of is OpenBSD, and they use gcc 4.9
> with it's bundled libstdc++ (their base system uses the old gcc).
> So I guess we're the odd ones with our libc++...

Not really, OSX also uses libc++ these days.  However, they use the
trivial pair copy constructor by default, as upstream libc++ does.  See
/Applications/Xcode.app/Contents//Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/__config
on a Mac with Xcode installed, which has:

   650  #ifndef _LIBCPP_TRIVIAL_PAIR_COPY_CTOR
   651  #  define _LIBCPP_TRIVIAL_PAIR_COPY_CTOR 1
   652  #endif

So not having the trivial pair copy constructor makes us the odd ones
out, but until now I didn't see any port failing because of it.  We
could enable this feature, but then we'd have to bump our libc++
version, together with all the followup hassle.

It would still be interesting to find some workaround in Chrome's code,
though.  It used to build in the previous version?  (I remember building
it successfully a few times in the past, at least.)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: c++/libc++ help needed for chromium update

[Dimitry Andric]

On 16 Mar 2016, at 22:27, Christoph Moench-Tegeder  wrote:
> 
> I'm currently working on updating www/chromium to the latest
> version (the 49 versions). Recently (that is, during development
> of version 49) the chromium developers allowed some c++11 features
> to be used.
> Included in those is std::move(), replacing their homegrown
> rvalue-reference-generating code (the .Pass() hack). That
> required me to use lang/clang36 as a compiler (with our
> clang 3.4.1 in FreeBSD 10 I got a bunch of obviously "wrong
> errors").
> 
> The following is my interpretation, grain-of-salt applies.
> 
> There's one issue remaining: this line
> https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/sync/internal_api/public/data_batch_impl.cc#15
> causes an compiler error - complaining that a copy-assignment
> operator had to be used but the operator had been deleted (error
> message attached, it's a little unwieldy).
> 
> The scoped_ptr implementation is this one:
> https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/base/memory/scoped_ptr.h
> and the magic DISALLOW_COPY_AND_ASSIGN_WITH_MOVE_FOR_BIND()
> has been defined here:
> https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/base/move.h#35
> 
> The key_data_pairs_ thing is a std::vector
> https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/sync/internal_api/public/data_batch_impl.h#41
> while KeyAndData is a std::pair<>
> https://chromium.googlesource.com/chromium/src.git/+/49.0.2623.87/sync/api/data_batch.h#18
> 
> (I think you get the hang of it...)
> 
> As clang is the "official" compiler used upstream, and after some
> research into C++ land (I'm from the plain C side), I'm suspecting
> that our libc++ is at fault (and it's behind upstream, of course,
> but there's no "simple" way of importing a new one - devel/libc++
> leaves the templates in /usr/include alone). Build results on
> FreeBSD 11 are still... building
> 
> Could anyone point me in a direction to resolve this?

While you are waiting for the FreeBSD 11 builds to complete, there are
maybe a few things you could try.

In r261801 [1], we turned off the _LIBCPP_TRIVIAL_PAIR_COPY_CTOR option
in libc++, because it made the ABI incompatible with the version of
libc++ we had shipped before that time.  However, this option makes the
std::pair copy constructor non-trivial, and this is a possible cause for
your compilation error.

The relevant part in  is:

template 
struct _LIBCPP_TYPE_VIS_ONLY pair
{
[...]
#if !defined(_LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS) && 
_LIBCPP_TRIVIAL_PAIR_COPY_CTOR
_LIBCPP_INLINE_VISIBILITY
pair(const pair& __p) = default;
#elif !defined(_LIBCPP_HAS_NO_RVALUE_REFERENCES) || 
!_LIBCPP_TRIVIAL_PAIR_COPY_CTOR
_LIBCPP_INLINE_VISIBILITY
pair(const pair& __p)
_NOEXCEPT_(is_nothrow_copy_constructible::value &&
   is_nothrow_copy_constructible::value)
: first(__p.first),
  second(__p.second)
{
}
#endif

E.g. in the case of a trivial copy constructor, it is created with "=
default", but otherwise it uses the copy constructors of the 'first' and
'second' members.  If these copy constructors are inaccessible or
deleted, as it looks like in this case, you will get an error about it.

The first thing you could try is to compile the Chromium source with
-D_LIBCPP_TRIVIAL_PAIR_COPY_CTOR=1 added to the flags.  This will
re-enable the trivial copy constructor for std::pair, but it is possibly
incompatible with precompiled libc++.so on your system.  Therefore,
things might break at runtime, in interesting ways.

Another thing you could try is to change the definition of scoped_ptr,
and comment out the deletion of its copy constructor.  However, I'm
unsure what side effects this may cause, as it is probably unwise to
copy scoped_ptrs.

Last but not least, please ask about this on the Chromium mailing lists.
There must be lots of C++ libraries out there with non-trivial std::pair
copy constructors, and they must have some sort of workaround for those.

-Dimitry

[1] http://svnweb.freebsd.org/changeset/base/261801



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: c++/libc++ help needed for chromium update

[Dimitry Andric]

On 16 Mar 2016, at 23:36, Dimitry Andric <d...@freebsd.org> wrote:
> 
> On 16 Mar 2016, at 22:27, Christoph Moench-Tegeder <c...@burggraben.net> 
> wrote:
...
>> Could anyone point me in a direction to resolve this?
...
> Last but not least, please ask about this on the Chromium mailing lists.
> There must be lots of C++ libraries out there with non-trivial std::pair
> copy constructors, and they must have some sort of workaround for those.

Yet another thing you could try is changing DataBatchImpl::Put() as follows:

--- a/data_batch_impl.cc2016-03-16 23:43:50.0 +0100
+++ b/data_batch_impl.cc2016-03-16 23:44:01.0 +0100
@@ -12,7 +12,7 @@ DataBatchImpl::~DataBatchImpl() {}

 void DataBatchImpl::Put(const std::string& client_key,
 scoped_ptr specifics) {
-  key_data_pairs_.push_back(KeyAndData(client_key, std::move(specifics)));
+  key_data_pairs_.push_back(std::move(KeyAndData(client_key, 
std::move(specifics;
 }

 bool DataBatchImpl::HasNext() const {

I'm not 100% sure this will work, but it might... :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Crash in ostream <

[Dimitry Andric]

On 15 Mar 2016, at 21:50, Willem Jan Withagen <w...@digiware.nl> wrote:
> 
> On 15-3-2016 19:52, Dimitry Andric wrote:
...
Most likely a bug in the Ceph code.  Try figuring out where the NULL
>> pointer originally came from.
> 
> I've started with compiling wit -O0 but that probably will still inline
> the pieces of code designated as such. Otherwise I'll have to resort to
> inserting asserts.
> 
> I'm now using gdb 7.1, loading lldb gives me a sort of strange
> commandline that looks like utf-8-ish???
> Would lldb give better analysis of the structures?

Maybe, but compiling at least some files with -O0 might help.  With
regards to the weird keyboard input, this was a problem (or bad side
effect) of a recent libedit import, in r296175.  Pedro Giffuni rolled it
back in r296435, after that lldb's line editor should work OK again.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Crash in ostream <

[Dimitry Andric]

On 15 Mar 2016, at 12:41, Willem Jan Withagen  wrote:
> 
> While running Ceph tools I get a crash in
> fr 10
> #10 0x016d82ca in FileStore::omap_get_values(coll_t const&, 
> ghobject_t const&, std::__1::set std::__1::char_traits, std::__1::allocator >, 
> std::__1::less std::__1::allocator > >, 
> std::__1::allocator std::__1::allocator > > > const&, 
> std::__1::map std::__1::allocator >, ceph::buffer::list, 
> std::__1::less std::__1::allocator > >, 
> std::__1::allocator std::__1::char_traits, std::__1::allocator > const, 
> ceph::buffer::list> > >*) ()
> (gdb) l
> 95  int preload_erasure_code()
> 96  {
> 97string plugins = g_conf->osd_erasure_code_plugins;
> 98stringstream ss;
> 99int r = ErasureCodePluginRegistry::instance().preload(
> 100 plugins,
> 101 g_conf->erasure_code_dir,
> 102 );
> 103   if (r)
> 104 derr << ss.str() << dendl;
> (gdb)
> 105   else
> 106 dout(10) << ss.str() << dendl;
> 107   return r;
> 108 }
> 109
> 
> All of this seems to be inlined since I'm not able to get at ss or r
> 
> 
> #8  0x00e16145 in std::__1::char_traits::length (__s=0x0) at 
> /usr/include/c++/v1/string:640
> 640 static inline size_t length(const char_type* __s) {return 
> strlen(__s);}

What happened here is that something attempted to initialize a
std::string with a NULL pointer, and that isn't allowed.  As you saw in
the debugger, the constructor just runs strlen() on the incoming string,
and that will segfault.


> Looking at the strlen implementation in
>/usr/srcs/head/src/lib/libc/string/strlen.c
> 
> shows that strlen does not take 0x0 as pointer, so when we get here with __s 
> = 0x0 all is lost.
> So I tried running it through 3.7, but since this is in the libraries with 
> the bintools/os, I'd expect
> both versions to crash on this.
> 
> Now the question I have to solve:
>   is it the compiler/toolset/libraries
>   is it a bug in the ceph code.

Most likely a bug in the Ceph code.  Try figuring out where the NULL
pointer originally came from.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: clang gets numerical underflow wrong, please fix.

[Dimitry Andric]

On 14 Mar 2016, at 02:53, Steve Kargl  wrote:
...
> #include 
> #include 
> 
> int
> main(void)
> {
>   int i;
>   float x = 1.f;
>   i = 0;
>   feclearexcept(FE_ALL_EXCEPT);
>   do {
>  x *= 2;
>  i++;
>  printf("%d %e\n", i, x);
>   } while(!fetestexcept(FE_OVERFLOW));
>   if (fetestexcept(FE_OVERFLOW)) printf("FE_UNDERFLOW: ");
>   printf("x = %e after %d iterations\n", x, i);
> 
>   return 0;
> }
> 
> You'll get a bunch of invalid output before the OVERFLOW.
> 
> % cc -O -o z b.c -lm && ./z | tail
> 1016 7.022239e+305  <-- not a valid float
> 1017 1.404448e+306  <-- not a valid float
> 1018 2.808896e+306  <-- not a valid float
> 1019 5.617791e+306  <-- not a valid float
> 1020 1.123558e+307  <-- not a valid float
> 1021 2.247116e+307  <-- not a valid float
> 1022 4.494233e+307  <-- not a valid float
> 1023 8.988466e+307  <-- not a valid float
> 1024 inf
> FE_UNDERFLOW: x = inf after 1024 iterations
> 
> Clang is broken with or without #pragma FENV_ACCESS "on".

Well, it simply doesn't support that #pragma [1], just like gcc [2]. :-(

Apparently compiler writers have trouble with this pragma, don't
implement it, and assume that it's always off.  Which then appears to
make most (or all) fenv.h functions into undefined behavior.

That said, making 'x' in your test case volatile helps, e.g. the main
loop was:

fadd%st(0), %st(0)
fstl-20(%ebp)
incl%esi
movl%esi, 4(%esp)
fstpl   8(%esp)
movl$.L.str, (%esp)
calll   printf
fnstsw  -10(%ebp)

and becomes:

flds-16(%ebp)
fadd%st(0), %st(0)
fstps   -16(%ebp)
incl%esi
flds-16(%ebp)
fstpl   8(%esp)
movl%esi, 4(%esp)
movl$.L.str, (%esp)
calll   printf
#APP
fnstsw  -10(%ebp)

So the fstps causes an overflow when 128 iterations are reached:

[...]
126 8.507059e+37
127 1.701412e+38
128 inf
FE_UNDERFLOW: x = inf after 128 iterations

Maybe this is a usable workaround for libm.

-Dimitry

[1] https://llvm.org/bugs/show_bug.cgi?id=8100
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34678



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: clang gets numerical underflow wrong, please fix.

[Dimitry Andric]

On 13 Mar 2016, at 21:10, Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
> On Sun, Mar 13, 2016 at 09:03:57PM +0100, Dimitry Andric wrote:
...
>> So it's storing the intermediate result in a double, for some reason.
>> The fnstsw will then result in zero, since there was no underflow at
>> that point.
>> 
>> I will submit a bug for this upstream, thanks for the report.

Submitted upstream as: https://llvm.org/bugs/show_bug.cgi?id=26931


> Thanks for the quick reply.  But, it must be using an 80-bit
> extended double instead of a double for storage.  This variation
> 
> #include 
> #include 
> 
> int
> main(void)
> {
>   int i;
> //   float x = 1.f;
>   double x = 1.;
>   i = 0;
>   feclearexcept(FE_ALL_EXCEPT);
>   do {
>  x /= 2;
>  i++;
>   } while(!fetestexcept(FE_UNDERFLOW));
>   if (fetestexcept(FE_UNDERFLOW)) printf("FE_UNDERFLOW: ");
>   printf("x = %e after %d iterations\n", x, i);
> 
>   return 0;
> }
> 
> yields
> 
> % cc -O -o z b.c -lm && ./z
> FE_UNDERFLOW: x = 0.00e+00 after 16435 iterations
> 
> It should be 1075 iterations.
> 
> Note, there is a similar issue with OVERFLOW.  The upshot is
> that clang on current is probably miscompiling libm.

With this example, I also get different results from gcc (4.8.5),
depending on the optimization level:

$ gcc -O underflow-iter.c -o underflow-iter-gcc -lm
$ ./underflow-iter-gcc
FE_UNDERFLOW: x = 0.00e+00 after 1075 iterations
$ gcc -O2 underflow-iter.c -o underflow-iter-gcc -lm
$ ./underflow-iter-gcc
FE_UNDERFLOW: x = 0.00e+00 after 16435 iterations

Similar for the overflow case:

$ gcc -O overflow-iter.c -o overflow-iter-gcc -lm
$ ./overflow-iter-gcc
FE_OVERFLOW: x = inf after 1024 iterations
$ gcc -O2 overflow-iter.c -o overflow-iter-gcc -lm
$ ./overflow-iter-gcc
FE_OVERFLOW: x = inf after 16384 iterations

Are we depending on some sort of subtle undefined behavior here?  With
-O, the 'main loop' becomes:

.L3:
fld1
fstpl   24(%esp)
movl$0, %ebx
.L8:
fldl24(%esp)
fld %st(0)
faddp   %st, %st(1)
fstpl   24(%esp)
addl$1, %ebx
fnstsw %ax
movl%eax, %esi
movl__has_sse, %eax
testl   %eax, %eax
je  .L4
cmpl$2, %eax
jne .L5
call__test_sse
testl   %eax, %eax
je  .L5
.L4:
stmxcsr 44(%esp)
jmp .L6
.L5:
movl$0, 44(%esp)
.L6:
orl 44(%esp), %esi
testl   $8, %esi
je  .L8

With -O2, it becomes:

.L3:
fld1
xorl%ebx, %ebx
.L12:
fadd%st(0), %st
addl$1, %ebx
fnstsw %ax
testl   %edx, %edx
movl%eax, %esi
je  .L10
cmpl$2, %edx
je  .L27
.L9:
xorl%eax, %eax
.L8:
orl %eax, %esi
andl$8, %esi
je  .L12

So it switches from using faddp and fstpl to direct fadd of %st(0) and
%st.  I assume that uses the internal 80 bit precision?  Gcc also
manages to move the __has_sse stuff out to further down in the function,
but it does not really affect the result.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Running Clang 3.7 on Current....

[Dimitry Andric]

On 11 Mar 2016, at 10:27, Willem Jan Withagen  wrote:
> 
> CURRENT has recently received the upgrade to Clang 3.8.
> 
> Now I run into the problem that some of the tests with Ceph are all of a
> sudden failing
> Mainly manifesting itself because of access errors thru pointers in
> very complex records structs. (Which is almost always in C++ :) )
> Either pointers are 0x0, or to invalid memory.
> 
> This can be attributed to a few things, some of them:
>  - changes in the Ceph code
>   Which is possible since I rebased since I started using 3.8.
>  - Subtle difference in corner cases, and overlaping structs get written
>   wrongly.
>  - A compiler bug
>  - other issues 
> 
> Ceph is run thru extensive tests while building, after which there is another
> large QA testset run by the Ceph-team in their openstack with even more and
> complexer tests. So real programming "errors" would be caught in this process.
> 
> To exclude the compiler I'd like to run a compile/build/test run with 3.7
> Can I just install the ports 3.7 version without endangering my 3.8 current
> installation. Then it'll just be set 'CC=clang37 C++=clang37++ make' and
> see what comes of it.

Yes, that should work without any problems.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: clang -pg, libm and the _end symbol

[Dimitry Andric]

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).

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Ceph compilation on inclusion of /usr/include/c++/v1/deque

[Dimitry Andric]

On 20 Feb 2016, at 16:09, Willem Jan Withagen  wrote:
> 
> I'm trying to build a port of Ceph for FreeBSD, which is sort of trying
> to shoot at a tank with a watergun :)

This is very nice, it would be good to have Ceph on FreeBSD.  Note that
if you have problems with porting, usually the freebsd-ports mailing
list is a better audience.


> I you want to reproduce it is rather labourious, but not all that complex:
> git clone https://github.com/wjwithagen/ceph.git
> cd ceph
> git checkout wip-wjw-freebsd-tests
> ./do_freebsd.sh
> 
> And wait for the error to appear.
...
> /usr/include/c++/v1/deque:912:49: error: invalid application of 'sizeof'
> to an incomplete type 'value_type' (aka 'RGWPeriod')
>static const difference_type __block_size = sizeof(value_type) < 256
> ? 4096 / sizeof(value_type) : 16;
>^~
> /usr/include/c++/v1/deque:1159:15: note: in instantiation of template
> class 'std::__1::__deque_base  std::__1::allocator >' requested here
>: private __deque_base<_Tp, _Allocator>
>  ^
> rgw/rgw_period_history.h:26:27: note: in instantiation of template class
> 'std::__1::deque> ' requested here
>std::deque periods;
>  ^
> rgw/rgw_period_history.h:16:7: note: forward declaration of 'RGWPeriod'
> class RGWPeriod;
>  ^

Without having to build anything, I see the problem already. :) The
error message is unfortunately rather confusing, but the gist of it is
that the implementation of std::deque<> requires a complete type.

Which means that you cannot do this:

#include 
class foo;
std::deque bar;

Compiling this example with clang and libc++ will result in (not all
errors shown, no need to):

In file included from deque-test.cpp:1:
/usr/include/c++/v1/deque:912:49: error: invalid application of 'sizeof' to 
an incomplete type 'value_type' (aka 'foo')
static const difference_type __block_size = sizeof(value_type) < 256 ? 
4096 / sizeof(value_type) : 16;
^~
/usr/include/c++/v1/deque:1159:15: note: in instantiation of template class 
'std::__1::__deque_base' requested here
: private __deque_base<_Tp, _Allocator>
  ^
deque-test.cpp:3:17: note: in instantiation of template class 
'std::__1::deque' requested here
std::deque bar;
^
deque-test.cpp:2:7: note: forward declaration of 'foo'
class foo;
  ^

Similarly, compiling the example with g++ and libstdc++ (6.0.0 from
ports) results in:

In file included from /usr/local/lib/gcc6/include/c++/deque:64:0,
 from deque-test.cpp:1:
/usr/local/lib/gcc6/include/c++/bits/stl_deque.h: In instantiation of 'void 
std::_Deque_base<_Tp, _Alloc>::_M_initialize_map(std::size_t) [with _Tp = foo; 
_Alloc = std::allocator; std::size_t = unsigned int]':
/usr/local/lib/gcc6/include/c++/bits/stl_deque.h:490:26:   required from 
'std::_Deque_base<_Tp, _Alloc>::_Deque_base() [with _Tp = foo; _Alloc = 
std::allocator]'
/usr/local/lib/gcc6/include/c++/bits/stl_deque.h:884:23:   required from 
'std::deque<_Tp, _Alloc>::deque() [with _Tp = foo; _Alloc = 
std::allocator]'
deque-test.cpp:3:17:   required from here
/usr/local/lib/gcc6/include/c++/bits/stl_deque.h:682:74: error: invalid 
application of 'sizeof' to incomplete type 'foo'
   const size_t __num_nodes = (__num_elements/ 
__deque_buf_size(sizeof(_Tp))
  ^
/usr/local/lib/gcc6/include/c++/bits/stl_deque.h:713:31: error: invalid 
application of 'sizeof' to incomplete type 'foo'
  % __deque_buf_size(sizeof(_Tp)));
   ^

Looking at rgw_period_history.h, it is indeed using an incomplete type:

#include 
#include 
#include 
#include 
#include "include/assert.h"
#include "include/types.h"

namespace bi = boost::intrusive;

class RGWPeriod;

/**
 * RGWPeriodHistory tracks the relative history of all inserted periods,
 * coordinates the pulling of missing intermediate periods, and provides a
 * Cursor object for traversing through the connected history.
 */
class RGWPeriodHistory final {
  /// an ordered history of consecutive periods
  struct History : public bi::avl_set_base_hook<> {
std::deque periods;

E.g at this point, all the compiler has is a forward declaration of
RGWPeriod.  If this even compiles on Linux, I am unsure how it manages
to do so. :-)  Maybe the Linux build pulls in some other header first,
getting the full definition of RGWPeriod somehow?

In any case, the easiest fix is probably to switch around the inclusions
of the headers in rgw_period_history.cc, e.g. changing:

Re: confusing messages from clang

[Dimitry Andric]

On 20 Feb 2016, at 08:33, Alex Denisov <1101.deb...@gmail.com> wrote:
>> On 20 Feb 2016, at 01:57, Steve Kargl  
>> wrote:
>> 
>> If anyone is interesting fixing FreeBSD's C compiler, it
>> would be appreciated.
...
>> foo.c:21:1: error: use of undeclared identifier 'corrupt'; did you mean 
>> 'crypt'?
>> corrupt:
>> ^~~
>> crypt
>> /usr/include/unistd.h:450:7: note: 'crypt' declared here
>> char*crypt(const char *, const char *);
>>^
>> foo.c:21:8: error: expected ';' after return statement
>> corrupt:
>>  ^
>>  ;
>> foo.c:14:12: error: use of undeclared label 'corrupt'
>> goto corrupt;
>>  ^
...
> I’ve submitted the bug to LLVM’s bugzilla: 
> https://llvm.org/bugs/show_bug.cgi?id=26678
> 
> Also, it looks like OS agnostic. At least I see the same behaviour on OSX as 
> well.

Yes, the messages could definitely be improved.  But for a compiler, it
is sometimes hard to guess the 'intent' of the code, though. :)

Note that gcc (I used 6.0 from ports) gives similarly confused messages:

foo.c: In function 'foo':
foo.c:21:1: error: 'corrupt' undeclared (first use in this function)
 corrupt:
 ^~~
foo.c:21:1: note: each undeclared identifier is reported only once for each 
function it appears in
foo.c:21:1: warning: 'return' with a value, in function returning void
foo.c:5:1: note: declared here
 foo(int i)
 ^~~
foo.c:21:8: error: expected ';' before ':' token
 corrupt:
^
foo.c:14:6: error: label 'corrupt' used but not defined
  goto corrupt;
  ^~~~

In gcc's case, it appears to read the statement as "return corrupt:",
causing it to first complain about the undeclared identifier, and then
about a missing semicolon.  Later, the label is of course still not
defined, so it complains again.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Questions about problems/errors with the include files

[Dimitry Andric]

On 20 Feb 2016, at 15:31, Willem Jan Withagen  wrote:
> 
> Before I actually dump the problem here.
> Would this be the place to ask about include files that give errors for
> code compiling under GCC but not under Clang 3.7??
> 
> gcc version 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC)
> 
> FreeBSD clang version 3.7.1 (tags/RELEASE_371/final 255217) 20151225
> Target: x86_64-unknown-freebsd11.0
> Thread model: posix

Well, posting the actual error message(s) would help. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: I've submitted 207175 for a clang 3.8.0 va_list handling problem for powerpc [fpr use also tested]

[Dimitry Andric]

On 20 Feb 2016, at 09:34, Roman Divacky  wrote:
> Fwiw, I've just committed the patch to clang in r261422. You might want
> to keep using a local modification or ask dim@ to import that patch
> to our copy of 3.8.

I've asked the LLVM release manager to consider merging this into the
3.8 branch.  The fix looks trivial enough. :)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: projects/clang380-import -r294609: arm buildworld broken by picking up -r294499's disable of clang.lib.mk -mlong-calls use

[Dimitry Andric]

On 23 Jan 2016, at 06:43, Mark Millard  wrote:
> 
> When I tried an rpi2 buildworld for clang380-import -r294609 it failed with 
> “relocation truncated” problems. (arm7-a cortex-a7 no misaligned accesses as 
> my context.)
> 
> It looks like this is from picking up base/head’s -r294499 as part of forming 
> -r294599 in clang380-import. -r294499 commented out having -mlong-calls in 
> /usr/src/lib/clang/clang.lib.mk:

Thanks for noticing this, I have undone it again in r294633.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: powerpc64-gcc unable to compile clang 3.8.0 from clang380-import -r294609 via buildworld

[Dimitry Andric]

On 23 Jan 2016, at 12:25, Mark Millard  wrote:
> 
> I tried a buildworld that included building clang and lldb based on using 
> powerpc64-xtoolchain-gcc/powerpc64-gcc as a cross compiler. It failed, see 
> below. This might indicate a more general gcc 5.x vs. clang 3.8.0 source code 
> mismatch. This was my first try. This could have been true for some time.
> 
> --- CFG.o ---
> /usr/local/bin/powerpc64-portbld-freebsd11.0-g++ -isystem 
> /usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include 
> -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/lib 
> --sysroot=/usr/obj/xtoolchain/powerpc.po
> werpc64/usr/src/tmp -B/usr/local/powerpc64-freebsd/bin/ 
> -I/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/usr/include/c++/v1 
> -std=gnu++11 
> -L/usr/obj/xtoolchain/powerpc.powerpc64/usr/src/tmp/../lib/libc++ 
> --sysroot=/usr
> /obj/xtoolchain/powerpc.powerpc64/usr/src/tmp 
> -B/usr/local/powerpc64-freebsd/bin/  -O2 -pipe 
> -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/include 
> -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm
> /tools/clang/include 
> -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis
>  -I. 
> -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/../../lib/clang/include
>  -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
> -D__STDC_CONSTANT_MACROS -DCLANG_ENABLE_ARCMT -DCLANG_ENABLE_STATIC_ANALYZER 
> -fno-strict-aliasing 
> -DLLVM_DEFAULT_TARGET_TRIPLE=\"powerpc64-unknown-freebsd11.0\" 
> -DLLVM_HOST_TRIPLE=\"powerpc64
> -unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\" -MD -MP -MF.depend.CFG.o 
> -MTCFG.o -fstack-protector-strong -Wno-error=unused-function 
> -Wno-error=enum-compare -Wno-error=logical-not-parentheses 
> -Wno-error=bool-compare -Wno-
> error=uninitialized -Wno-error=array-bounds -Wno-error=clobbered 
> -Wno-error=cast-align -Wno-error=extra -Wno-error=attributes 
> -Wno-error=inline -Wno-error=unused-but-set-variable -Wno-error=unused-value 
> -Wno-error=strict
> -aliasing -Wno-error=address  -std=c++11 -fno-exceptions -fno-rtti  -c 
> /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/CFG.cpp
>  -o CFG.o
> . . .
> --- all_subdir_libclanganalysis ---
> /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/CFG.cpp:
>  In member function 'std::__1::unique_ptr 
> {anonymous}::CFGBuilder::buildCFG(const clang::Decl*, clang::Stmt*)':
> /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/CFG.cpp:1046:45:
>  error: no matching function for call to 
> 'reverse(clang::CXXConstructorDecl::init_const_range)'
> for (auto *I : llvm::reverse(CD->inits())) {
> ^

I just tried building clang 3.8.0 with gcc 5.3.0, but that went fine.
However, by default gcc uses its own copy of libstdc++.  The above error
is most likely something caused by libc++ and gcc not playing well
together.

This kind of error is always hard to report upstream, since the gcc
maintainers obviously do not care that much about libc++, while the
libc++ maintainers do not care that much about gcc. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Bug 205663 Clang getting Bus Errors (arm SCLTR Bit[12]==1 context): Reported fixed on llvm's trunk

[Dimitry Andric]

On 09 Jan 2016, at 04:46, Mark Millard <mar...@dsl-only.net> wrote:
> 
> On 2016-Jan-7, at 2:57 PM, Dimitry Andric  wrote:
...
>> FYI, I have added a -mno-movt option for this purpose upstream, and
>> imported a newer snapshot into the clang380-import branch.  As of
>> r293384, it now uses the new option spelling for modules, if your clang
>> is 3.8.0 or higher.
>> 
>> -Dimitry
> 
> I've not been able to get to the point of running clang++ 3.8 on the rpi2 
> yet: R_ARM_CALL and R_ARM_JUMP24 relocation truncations during the cross 
> build's buildworld interfere.

Yes, this is caused by too large call distances.  In other words, the
clang executable is getting to big to link.  Apparently we need to do
some tricks with -mlongcall to fix this.  As I am no arm expert, I
welcome any patch submissions. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ongoing link issues

[Dimitry Andric]

On 09 Dec 2015, at 17:50, William A. Mahaffey III  wrote:
> 
> I am still trying to statically link my inhouse code. I switched to using 
> g++5 in the link line:
...
> g++5 -o /usr/local/bin/PreBFCGL.opteron.TEST.static 
> -Wl,-s,--allow-multiple-definition,-rpath=/usr/local/lib/gcc5 Main.o 
> -L/home/wam/V8/Cnx/test/junk/cart/unstaggered/bfc/pre/../lib/R4/opteron 
> -L/home/wam/lib/R4 -L/usr/lib64/openmotif -Wl,--start-group -lmaiPre -lPre 
> -lPrecxx -lutils -lftndmp -lftnO2pre -lftnO2 -lBC_Phi -license 
> -Wl,--end-group -lMemIO -lMotif -lStdHash -lmpi -ltet -lgomp -lMrm -lXm -lXt 
> -lGL -lGLU -lGLw -lX11 -ljpeg -lpng -lz -lm -static-libgcc -static-libstdc++ 
> -Bstatic -lgfortran -static-libgfortran && \rm -f Main.o

> [wam@kabini1, ~, 10:51:48am] 917 % PreBFCGL.TEST
> /lib/libgcc_s.so.1: version GCC_4.6.0 required by 
> /usr/local/lib/gcc48/libgfortran.so.3 not found
> [wam@kabini1, ~, 10:51:52am] 918 % PreBFCGL.TEST.static
> /lib/libgcc_s.so.1: version GCC_4.6.0 required by 
> /usr/local/lib/gcc48/libgfortran.so.3 not found
> [wam@kabini1, ~, 10:52:02am] 919 % PreBFCGL.bdver1.TEST.static
> /lib/libgcc_s.so.1: version GCC_4.6.0 required by 
> /usr/local/lib/gcc48/libgfortran.so.3 not found
> [wam@kabini1, ~, 10:52:04am] 920 % uname -a

Instead of all the complicated stuff above, can't you simply use -static
while linking?  I'm not sure why you want a half-dynamic, half-static
executable?

If you want to link *some* of the libraries statically, you must enclose
these in a -Wl,-Bstatic ... -Wl,-Bdynamic pair.  For example:

-Wl,-Bstatic -lstdc++ -lgfortran -lgcc -Wl,-Bdynamic

Also, you should probably link using gcc5 instead of g++5, otherwise the
latter might add its own -lstdc++ arguments.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: lang/ruby2* build failure on arm

[Dimitry Andric]

On 20 Nov 2015, at 23:02, Michael Moll <mm...@freebsd.org> wrote:
> 
> On Fri, Nov 20, 2015 at 06:04:53PM +0100, Dimitry Andric wrote:
>>> In r384323 (ports) swills@ fixed the build of the lang/ruby2* ports,
>>> however, on a recent CURRENT on armv6hf I'm getting:
>>> checking for setjmp type... configure: error: _setjmp is not available
>> 
>> Check the config.log file for further details.  Why does the configure
>> script conclude that _setjmp is not available?
> 
> The whole file is available as http://space.kvedulv.de/ruby_arm_config.log, 
> the output
> from the specific test is:
> 
> conftest.c:340:20: error: __builtin_longjmp is not supported for the current 
> target
>void t(void) {__builtin_longjmp((void **) jb, 1);}
>  ^~
> conftest.c:341:29: error: __builtin_setjmp is not supported for the current 
> target
>int jump(void) {(void)(__builtin_setjmp((void **) jb) ? 1 : 0); 
> return 0;}
>   ^~

Right, but that is not the real problem.  Earlier on, the configure
script is checking for the regular _setjmp():

configure:16921: checking for _setjmp
configure:16921: cc -o conftest -O -pipe  -fno-strict-aliasing 
-I/usr/local/include   -fstack-protector conftest.c -lcrypt -lm -lpthread 
-L/usr/local/lib >&5
conftest.c:228:6: warning: declaration of built-in function '_setjmp' requires 
inclusion of the header  [-Wbuiltin-requires-header]
char _setjmp ();
 ^
conftest.c:239:17: error: too few arguments to function call, expected 1, have 0
return _setjmp ();
   ~^
1 warning and 1 error generated.
configure:16921: $? = 1
configure: failed program was:

As to why GNU configure tries to call this without arguments, is beyond
me.  To work around its brokenness, I would set ac_cv_func__setjmp to
yes before calling configure.  Or attempt to unbreak autoconf, but that
is a truly Herculean task. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: clang confuses kgdb on static symbols

[Dimitry Andric]

On 20 Oct 2015, at 13:38, Andriy Gapon  wrote:
> 
> 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.

As far as I know, static symbols are candidates for shuffling around,
completely optimizing away, et cetera, as long as the program still
works according to the abstract model.  (This is of course without
taking e.g. __used attributes into account.)

It appears that intr_cpus is a struct, and I have seen before that
individual members of such static structs are sometimes assigned
individual symbols, suffixed with .0, .1 and so on.  This is likely what
is happening in this case.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

[Differential] [Accepted] D2690: In ypbind, eliminate error: dereferencing type-punned pointer will break strict-aliasing rules

[dim (Dimitry Andric)]

dim accepted this revision.
dim added a comment.
This revision has a positive review.

For the rest, LGTM.


REPOSITORY
  rS FreeBSD src repository

BRANCH
  /head

REVISION DETAIL
  https://reviews.freebsd.org/D2690

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: araujo, bapt, emaste, rodrigc, dim
Cc: imp, freebsd-toolchain-list
___
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

[Differential] [Commented On] D2690: In ypbind, eliminate error: dereferencing type-punned pointer will break strict-aliasing rules

[dim (Dimitry Andric)]

dim added inline comments.

INLINE COMMENTS
  usr.sbin/ypbind/ypbind.c:622 While we are here, can we please update this to 
a post-KR definition?  E.g.:
  
  static bool_t broadcast_result(caddr_t out, struct sockaddr_in *addr)

REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D2690

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: araujo, bapt, emaste, dim, rodrigc
Cc: imp, freebsd-toolchain-list
___
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

[Differential] [Commented On] D2690: In ypbind, eliminate error: dereferencing type-punned pointer will break strict-aliasing rules

[dim (Dimitry Andric)]

dim added inline comments.

INLINE COMMENTS
  usr.sbin/ypbind/ypbind.c:952 Missing an  here?

REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D2690

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: rodrigc, bapt, emaste, dim, araujo
Cc: imp, freebsd-toolchain
___
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

[Differential] [Commented On] D1932: Remove the non-standard CC alias for c++

[dim (Dimitry Andric)]

dim added a comment.

@imp, so are your concerns now addressed? I didn't expect many ports to fail, 
and there were just a handful, three of which were actual errors (they indended 
to run ${CC}, but somebody typo'd CC instead).


REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D1932

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: dim, emaste, theraven, imp, bdrewery
Cc: bdrewery, kib, imp, freebsd-toolchain
___
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

[Differential] [Commented On] D1932: Remove the non-standard CC alias for c++

[dim (Dimitry Andric)]

dim added a comment.

An exp-run was requested in bug 200477 https://bugs.freebsd.org/200477.  Out 
of ~25000 ports, only 5 failed, and those have been trivially fixed.
The ports tree no longer requires CC to exist.


REPOSITORY
  rS FreeBSD src repository

REVISION DETAIL
  https://reviews.freebsd.org/D1932

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: dim, emaste, theraven, imp, bdrewery
Cc: bdrewery, kib, imp, freebsd-toolchain
___
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

[Differential] [Updated, 8 lines] D1932: Remove the non-standard CC alias for c++

[dim (Dimitry Andric)]

dim updated this revision to Diff 5715.
dim added a comment.
This revision now requires review to proceed.
Herald added a subscriber: imp.

Updated for changes in ObsoleteFiles.inc.


REPOSITORY
  rS FreeBSD src repository

CHANGES SINCE LAST UPDATE
  https://reviews.freebsd.org/D1932?vs=3900id=5715

BRANCH
  /head

REVISION DETAIL
  https://reviews.freebsd.org/D1932

AFFECTED FILES
  ObsoleteFiles.inc
  gnu/usr.bin/cc/c++/Makefile
  gnu/usr.bin/cc/cc/Makefile
  usr.bin/clang/clang/Makefile

CHANGE DETAILS
  diff --git a/usr.bin/clang/clang/Makefile b/usr.bin/clang/clang/Makefile
  --- a/usr.bin/clang/clang/Makefile
  +++ b/usr.bin/clang/clang/Makefile
  @@ -20,11 +20,9 @@
   .if ${MK_CLANG_IS_CC} != no
   LINKS+=  ${BINDIR}/clang ${BINDIR}/cc \
${BINDIR}/clang ${BINDIR}/c++ \
  - ${BINDIR}/clang ${BINDIR}/CC \
${BINDIR}/clang ${BINDIR}/cpp
   MLINKS+= clang.1 cc.1 \
clang.1 c++.1 \
  - clang.1 CC.1 \
clang.1 cpp.1
   .endif
   
  diff --git a/gnu/usr.bin/cc/cc/Makefile b/gnu/usr.bin/cc/cc/Makefile
  --- a/gnu/usr.bin/cc/cc/Makefile
  +++ b/gnu/usr.bin/cc/cc/Makefile
  @@ -16,7 +16,7 @@
   MLINKS=  gcc.1 g++.1
   .if ${MK_CLANG_IS_CC} == no
   LINKS=   ${BINDIR}/gcc ${BINDIR}/cc
  -MLINKS+= gcc.1 cc.1 gcc.1 c++.1 gcc.1 CC.1
  +MLINKS+= gcc.1 cc.1 gcc.1 c++.1 gcc.1
   .endif
   
   .include bsd.prog.mk
  diff --git a/gnu/usr.bin/cc/c++/Makefile b/gnu/usr.bin/cc/c++/Makefile
  --- a/gnu/usr.bin/cc/c++/Makefile
  +++ b/gnu/usr.bin/cc/c++/Makefile
  @@ -16,7 +16,6 @@
   
   .if ${MK_CLANG_IS_CC} == no
   LINKS=   ${BINDIR}/g++ ${BINDIR}/c++
  -LINKS+=  ${BINDIR}/g++ ${BINDIR}/CC
   .endif
   
   .include bsd.prog.mk
  diff --git a/ObsoleteFiles.inc b/ObsoleteFiles.inc
  --- a/ObsoleteFiles.inc
  +++ b/ObsoleteFiles.inc
  @@ -38,6 +38,9 @@
   #   xargs -n1 | sort | uniq -d;
   # done
   
  +# 2015mmdd: Removed the non-standard CC alias for c++
  +OLD_FILES+=usr/bin/CC
  +OLD_FILES+=usr/share/man/man1/CC.1.gz
   # 20150525: new clang import which bumps version from 3.6.0 to 3.6.1.
   OLD_FILES+=usr/lib/clang/3.6.0/include/__stddef_max_align_t.h
   OLD_FILES+=usr/lib/clang/3.6.0/include/__wmmintrin_aes.h

EMAIL PREFERENCES
  https://reviews.freebsd.org/settings/panel/emailpreferences/

To: dim, emaste, theraven
Cc: imp, freebsd-toolchain
diff --git a/usr.bin/clang/clang/Makefile b/usr.bin/clang/clang/Makefile
--- a/usr.bin/clang/clang/Makefile
+++ b/usr.bin/clang/clang/Makefile
@@ -20,11 +20,9 @@
 .if ${MK_CLANG_IS_CC} != no
 LINKS+=	${BINDIR}/clang ${BINDIR}/cc \
 	${BINDIR}/clang ${BINDIR}/c++ \
-	${BINDIR}/clang ${BINDIR}/CC \
 	${BINDIR}/clang ${BINDIR}/cpp
 MLINKS+= clang.1 cc.1 \
 	clang.1 c++.1 \
-	clang.1 CC.1 \
 	clang.1 cpp.1
 .endif
 
diff --git a/gnu/usr.bin/cc/cc/Makefile b/gnu/usr.bin/cc/cc/Makefile
--- a/gnu/usr.bin/cc/cc/Makefile
+++ b/gnu/usr.bin/cc/cc/Makefile
@@ -16,7 +16,7 @@
 MLINKS=	gcc.1 g++.1
 .if ${MK_CLANG_IS_CC} == no
 LINKS=	${BINDIR}/gcc ${BINDIR}/cc
-MLINKS+= gcc.1 cc.1 gcc.1 c++.1 gcc.1 CC.1
+MLINKS+= gcc.1 cc.1 gcc.1 c++.1 gcc.1
 .endif
 
 .include bsd.prog.mk
diff --git a/gnu/usr.bin/cc/c++/Makefile b/gnu/usr.bin/cc/c++/Makefile
--- a/gnu/usr.bin/cc/c++/Makefile
+++ b/gnu/usr.bin/cc/c++/Makefile
@@ -16,7 +16,6 @@
 
 .if ${MK_CLANG_IS_CC} == no
 LINKS=	${BINDIR}/g++ ${BINDIR}/c++
-LINKS+=	${BINDIR}/g++ ${BINDIR}/CC
 .endif
 
 .include bsd.prog.mk
diff --git a/ObsoleteFiles.inc b/ObsoleteFiles.inc
--- a/ObsoleteFiles.inc
+++ b/ObsoleteFiles.inc
@@ -38,6 +38,9 @@
 #   xargs -n1 | sort | uniq -d;
 # done
 
+# 2015mmdd: Removed the non-standard CC alias for c++
+OLD_FILES+=usr/bin/CC
+OLD_FILES+=usr/share/man/man1/CC.1.gz
 # 20150525: new clang import which bumps version from 3.6.0 to 3.6.1.
 OLD_FILES+=usr/lib/clang/3.6.0/include/__stddef_max_align_t.h
 OLD_FILES+=usr/lib/clang/3.6.0/include/__wmmintrin_aes.h

___
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

[Differential] [Commented On] D2285: gcc 4.9.1 compilation fixes for aesni

[dim (Dimitry Andric)]

dim added a comment.

LGTM.

REVISION DETAIL
  https://reviews.freebsd.org/D2285

To: rodrigc, jmg
Cc: kostikbel, emaste, dim, freebsd-toolchain
___
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

[Differential] [Changed Subscribers] D2285: gcc 4.9.1 compilation fixes for aesni

[dim (Dimitry Andric)]

dim added a subscriber: dim.

INLINE COMMENTS
  sys/crypto/aesni/aesni_wrap.c:49 This part seems to be superfluous, since 
aesencdec.h, just two files above this one, already defines 
_MM_MALLOC_INCLUDED.

REVISION DETAIL
  https://reviews.freebsd.org/D2285

To: rodrigc, jmg
Cc: dim, freebsd-toolchain
___
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

[Differential] [Commented On] D2187: Ensure cross assembler, linker and objcopy are used for the build32 stage

[dim (Dimitry Andric)]

dim added inline comments.

BRANCH
  /head

INLINE COMMENTS
  Makefile.inc1:416 I just looked for the LD=${LD} assignments, and replaced 
them all. Maybe, for consistency, we should add OBJCOPY=${XOBJCOPY} for the 
powerpc case too, but I'm not sure if it's used at all in the powerpc build...

REVISION DETAIL
  https://reviews.freebsd.org/D2187

To: dim, rodrigc, bapt, emaste, imp
Cc: emaste, imp, freebsd-toolchain
___
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

[Differential] [Updated, 38 lines] D2187: Ensure cross assembler, linker and objcopy are used for the build32 stage

[dim (Dimitry Andric)]

dim updated this revision to Diff 4577.
dim added a comment.
This revision now requires review to proceed.

Add XOBJCOPY for powerpc too.

CHANGES SINCE LAST UPDATE
  https://reviews.freebsd.org/D2187?vs=4554id=4577

BRANCH
  /head

REVISION DETAIL
  https://reviews.freebsd.org/D2187

AFFECTED FILES
  Makefile.inc1
  lib/csu/i386-elf/Makefile
  sys/boot/i386/boot2/Makefile
  sys/boot/i386/gptboot/Makefile
  sys/boot/i386/gptzfsboot/Makefile
  sys/boot/i386/zfsboot/Makefile
  sys/boot/mips/beri/boot2/Makefile
  sys/boot/pc98/boot0.5/Makefile
  sys/boot/pc98/boot0/Makefile
  sys/boot/pc98/boot2/Makefile

To: dim, rodrigc, imp, emaste, bapt
Cc: emaste, imp, freebsd-toolchain
___
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

[Differential] [Commented On] D2187: Ensure cross assembler, linker and objcopy are used for the build32 stage

[dim (Dimitry Andric)]

dim added inline comments.

BRANCH
  /head

INLINE COMMENTS
  Makefile.inc1:427 Btw, I'm not sure about AS here, since it might not even be 
used in the 32 bit stage, and also I'm not sure of the syntax.  Is it -a32?

REVISION DETAIL
  https://reviews.freebsd.org/D2187

To: dim, rodrigc, imp, bapt, emaste
Cc: emaste, imp, freebsd-toolchain
___
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: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import

[Dimitry Andric]

On 31 Mar 2015, at 19:17, Craig Rodrigues rodr...@freebsd.org wrote:
 
 On Mon, Mar 23, 2015 at 12:12 AM, Dimitry Andric d...@freebsd.org wrote:
...
  Yes, this is a bug in libc++, when compiling it with newer versions of
  gcc.  I reported this upstream some time ago: https://llvm.org/PR22771
 
  Still haven't had enough time to test Eric Fiselier's patch for it.  I
  hope I see the bottom of my TODO list anytime soon...
 
  -Dimitry
 
 
 Hi,
 
 I just updated my tree to include your latest fixes such as r28064.
 
 I'm still getting this:
 
  from 
 /builds/FreeBSD_HEAD_external_toolchain_gcc/lib/clang/libclangast/../../../contrib/llvm/tools/clang/lib/AST/DeclBase.cpp:14:
 /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include/c++/v1/type_traits:845:28:
  error:   initializing argument 1 of 'char 
 std::__1::__is_convertible_imp::__test(_Tp) [with _Tp = 
 clang::StoredDeclsList]'
  template class _Tp char  __test(_Tp);
 ^
 *** [DeclBase.o] Error code 1
 
 make[6]: stopped in 
 /builds/FreeBSD_HEAD_external_toolchain_gcc/lib/clang/libclangast
 
 Any ideas?

Yes, see your log:

Started by user rodrigc
Building remotely on jenkins10a.freebsd.org (FreeBSD-10) in workspace 
/builds/FreeBSD_HEAD_external_toolchain_gcc
Updating svn://svn.freebsd.org/base/head at revision '2015-03-31T00:49:32.815 
+'
[...]
G contrib/libc++/include/type_traits
U contrib/libarchive/libarchive/archive_read_disk_posix.c
At revision 280872
[...]

but then:

+ patch
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|Index: contrib/libc++/include/type_traits
|===
|--- contrib/libc++/include/type_traits (revision 280762)
|+++ contrib/libc++/include/type_traits (working copy)
--
Patching file contrib/libc++/include/type_traits using Plan A...
Reversed (or previously applied) patch detected!  Assume -R? [y]
Hunk #1 succeeded at 842.
Hunk #2 succeeded at 877.
Hmm...  Ignoring the trailing garbage.
done

E.g., it undoes the change to type_traits that was merged in the subversion 
update.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: CROSS_TOOLCHAIN=amd64-gcc fails to build after clang 3.6.0 import

[Dimitry Andric]

On 31 Mar 2015, at 22:06, Craig Rodrigues rodr...@freebsd.org wrote:
 
 On Tue, Mar 31, 2015 at 12:48 PM, Dimitry Andric d...@freebsd.org wrote:
 On 31 Mar 2015, at 21:38, Craig Rodrigues rodr...@freebsd.org wrote:
 
  On Tue, Mar 31, 2015 at 11:20 AM, Dimitry Andric d...@freebsd.org wrote:
 
  On 31 Mar 2015, at 20:13, Dimitry Andric d...@freebsd.org wrote:
  ...
  but then:
 
  + patch
  Hmm...  Looks like a unified diff to me...
  The text leading up to this was:
  --
  |Index: contrib/libc++/include/type_traits
  |===
  |--- contrib/libc++/include/type_traits (revision 280762)
  |+++ contrib/libc++/include/type_traits (working copy)
  --
  Patching file contrib/libc++/include/type_traits using Plan A...
  Reversed (or previously applied) patch detected!  Assume -R? [y]
  Hunk #1 succeeded at 842.
  Hunk #2 succeeded at 877.
  Hmm...  Ignoring the trailing garbage.
  done
 
  E.g., it undoes the change to type_traits that was merged in the
  subversion update.
 
 
  OK, I undid the patch.  Now the clang and libc++ parts build, but I'm
  still getting problems building rescue:
 
  https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/29/console
 
 Hm, that is strange.  I have just completed a build with
 amd64-xtoolchain-gcc, and apart from boot2, everything worked...
 
 What does readelf say when you run it on the cat.lo file which is
 complained about in the log?  And what happens if you delete it, and
 restart the build?
 
 See:
 https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001545.html

I'm suspecting this might have something to do with crunchide, or least,
the copy of crunchide that is run for this:

--- cat.lo ---
/usr/local/x86_64-freebsd/bin/ld -dc -r -o cat.lo cat_stub.o 
/builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/rescue/rescue//builds/FreeBSD_HEAD_external_toolchain_gcc/bin/cat/cat.o
crunchide -k _crunched_cat_stub cat.lo

If I look at my own build logs, it seems to pick the crunchide
executable in /usr/bin, and Makefile.inc1 does *not* build it during the
cross-tools stage if ${TARGET_ARCH} is the same as ${MACHINE_ARCH}:

.if ${TARGET_ARCH} != ${MACHINE_ARCH}
.if ${MK_RESCUE} != no || defined(RELEASEDIR)
_crunchide= usr.sbin/crunch/crunchide
.endif

However, this does not explain why my /usr/bin/crunchide seems to not
screw up cat.lo, while yours does.  As far as I can see, we're both
building this on a stable/10 amd64 box...

Maybe, as a hack, you can force cross-tools to build crunchide, by
patching Makefile.inc1 to ignore the arch check, and see what that
results in?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Failed to build usr.bin/clang/clang with gcc 4.9

[Dimitry Andric]

On 29 Mar 2015, at 22:39, Craig Rodrigues rodr...@freebsd.org wrote:
 
 When building with gcc 4.9, I am getting unresolved symbols at link
 time when building usr.bin/clang/clang.  Here is one error message:
 
 /usr/obj/opt2/branches/head/usr.bin/clang/clang/../../../lib/clang/libclangcodegen/libclang
 codegen.a(ModuleBuilder.o): In function `(anonymous
 namespace)::CodeGeneratorImpl::HandleTranslationUnit(clang::ASTContext)':
 ModuleBuilder.cpp:(.text+0x113): undefined reference to
 `clang::CodeGen::CodeGenModule::clear()'
 
 There are many more errors like that in  my full build log here:
 
 https://people.freebsd.org/~rodrigc/gcc/buildworld.2015_03_29.log.txt

For some reason, many of your libraries aren't being built:

 stage 4.2: building libraries
...
=== lib/libwrap (all)
=== lib/libxo (all)
=== lib/liby (all)
=== lib/atf (all)
=== lib/atf/libatf-c (all)
=== lib/atf/libatf-c++ (all)
=== lib/clang (all)
=== lib/clang/libclanganalysis (all)
=== lib/clang/libclangarcmigrate (all)
=== lib/clang/libclangast (all)
=== lib/clang/libclangbasic (all)
=== lib/clang/libclangcodegen (all)
=== lib/clang/libclangdriver (all)
=== lib/clang/libclangedit (all)
=== lib/clang/libclangfrontend (all)

And none of these prints any compilation command lines?  Are you running
with make -s, by any chance?  If so, try removing it so we can see how
the various source files are being compiled.

Also, do any of the libclang*.a files under /usr/obj look sane?  E.g.,
do they contain any object files, and if so, why are the symbols you
showed missing?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

[Dimitry Andric]

On 22 Mar 2015, at 22:32, Craig Rodrigues rodr...@freebsd.org wrote:
 
 On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric d...@freebsd.org wrote:
 
 Ah right, that was on i386, on amd64 it does result in -2^63.  It is indeed 
 caused by reliance on signed integer wrapping.
 
 This diff should fix it, without rewriting the utility:
 
 Index: bin/expr/Makefile
 ===
 --- bin/expr/Makefile   (revision 280156)
 +++ bin/expr/Makefile   (working copy)
 @@ -6,6 +6,9 @@ PROG=   expr
  SRCS=  expr.y
  YFLAGS=
 
 +# expr relies on signed integer wrapping
 +CFLAGS+= -fwrapv
 +
  NO_WMISSING_VARIABLE_DECLARATIONS=
 
  .if ${MK_TESTS} != no
 
 
 Well, another alternative is to patch expr.y:
 
 Index: expr.y
 ===
 --- expr.y  (revision 280353)
 +++ expr.y  (working copy)
 @@ -393,7 +393,7 @@
  }
 
  void
 -assert_plus(intmax_t a, intmax_t b, intmax_t r)
 +assert_plus(intmax_t a, intmax_t b, volatile intmax_t r)
  {
 /*
  * sum of two positive numbers must be positive,
 @@ -420,7 +420,7 @@
  }
 
  void
 -assert_minus(intmax_t a, intmax_t b, intmax_t r)
 +assert_minus(intmax_t a, intmax_t b, volatile intmax_t r)
  {
 /* special case subtraction of INTMAX_MIN */
 if (b == INTMAX_MIN  a  0)
 
 
 There were already some patches previously done to this
 file to add volatile, so maybe this would be OK to do.
 
 What do you think?

Volatile is not the solution, it is completely orthogonal.  The correct
way would be to use unsigned integers, for which wrapping is defined,
then convert those back and forth when presenting the results to the
user.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

[Dimitry Andric]

On 22 Mar 2015, at 23:04, Garrett Cooper yaneurab...@gmail.com wrote:
 
 On Mar 22, 2015, at 15:01, Craig Rodrigues rodr...@freebsd.org wrote:
 
 ...
 
 OK, converting expr.y to use unsigned integers would require a bit of work.
 
 Can you commit your patch to the Makefile?  It fixes the problem for now.
 
 +1
 
 I’d still like to know why clang 3.5 doesn’t have this behavior though — 
 there might be other potential issues lurking around that need to be solved 
 (either here, in ports, or both).

Because this version optimizes better around undefined behavior.  There
are most likely many issues lurking around, and most certainly in ports.

I would recommend using UBSan to tackle this kind of thing.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail