Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #614 - Failure

[Craig Rodrigues]

On Tue, Oct 6, 2015 at 3:17 PM,  wrote:

>
> --- Module.o ---
> /usr/local/bin/x86_64-portbld-freebsd10.1-g++ -isystem
> /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include
> -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/lib
> --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp
> -B/usr/local/x86_64-freebsd/bin/
> -I/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1
> -std=gnu++11
> -L/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/../lib/libc++
> --sysroot=/builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp
> -B/usr/local/x86_64-freebsd/bin/  -O2 -pipe
> -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/include
> -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include
> -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic
> -I.
> -I/builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../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=\"x86_64-unknown-freebsd11.0\"
> -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"\"
> -fstack-protector-strong  -std=c++11 -fno-exceptions -fno-rtti  -c
> /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Module.cpp
> -o Module.o
> In file included from
> /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/SourceLocation.h:22:0,
>  from
> /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/include/clang/Basic/Module.h:18,
>  from
> /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic/../../../contrib/llvm/tools/clang/lib/Basic/Module.cpp:15:
> /builds/FreeBSD_HEAD_amd64_gcc4.9/obj/builds/FreeBSD_HEAD_amd64_gcc4.9/tmp/usr/include/c++/v1/functional:1322:17:
> error: '_Rp std::__1::__function::__base<_Rp(_ArgTypes
> ...)>::operator()(_ArgTypes&& ...) [with _Rp = void; _ArgTypes =
> {clang::VisibleModuleSet::setVisible(clang::Module*, clang::SourceLocation,
> clang::VisibleModuleSet::VisibleCallback,
> clang::VisibleModuleSet::ConflictCallback)::Visiting}]', declared using
> local type 'clang::VisibleModuleSet::setVisible(clang::Module*,
> clang::SourceLocation, clang::VisibleModuleSet::VisibleCallback,
> clang::VisibleModuleSet::ConflictCallback)::Visiting', is used but never
> defined [-fpermissive]
>  virtual _Rp operator()(_ArgTypes&& ...) = 0;
>  ^
> *** [Module.o] Error code 1
>
> make[6]: stopped in
> /builds/FreeBSD_HEAD_amd64_gcc4.9/lib/clang/libclangbasic
> 1 error
>
>
Hi,

I took a look at this, and was also able to reproduce this with gcc 5.0.

I was able to eliminate this error with gcc by moving  the definition of
"struct Visiting"
from outside the function by doing:

Index: llvm/tools/clang/lib/Basic/Module.cpp
===
--- llvm/tools/clang/lib/Basic/Module.cpp   (revision 288962)
+++ llvm/tools/clang/lib/Basic/Module.cpp   (working copy)
@@ -480,6 +480,12 @@
   print(llvm::errs());
 }

+struct Visiting {
+Module *M;
+Visiting *ExportedBy;
+};
+
+
 void VisibleModuleSet::setVisible(Module *M, SourceLocation Loc,
   VisibleCallback Vis, ConflictCallback
Cb) {
   if (isVisible(M))
@@ -487,11 +493,6 @@

   ++Generation;

-  struct Visiting {
-Module *M;
-Visiting *ExportedBy;
-  };
-
   std::function VisitModule = [&](Visiting V) {
 // Modules that aren't available cannot be made visible.
 if (!V.M->isAvailable())


I am not C++11 savvy enough to know if this is a gcc bug, or
a problem in the clang code.

Can we have something like this as a local patch in our FreeBSD tree until
we can get a better fix from LLVM?

--
Craig
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD_HEAD_amd64_gcc4.9 - Build #614 - Failure

[jenkins-admin]

FreeBSD_HEAD_amd64_gcc4.9 - Build #614 - Failure:

Build information: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/614/
Full change log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/614/changes
Full build log: 
https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_amd64_gcc4.9/614/console

Change summaries:

288957 by bdrewery:
truss: Add support for utrace(2).

This uses the kdump(1) utrace support code directly until a common library
is created.

This allows malloc(3) tracing with MALLOC_CONF=utrace:true and rtld tracing
with LD_UTRACE=1.  Unknown utrace(2) data is just printed as hex.

PR: 43819 [inspired by]
Reviewed by:jhb
MFC after:  2 weeks
Relnotes:   yes
Differential Revision:  https://reviews.freebsd.org/D3819

288954 by jhb:
Move td_oncpu and td_lastcpu out of the "zero'd on fork" section of
struct thread since they are always explicitly initialized during fork
and thread creation after r286256.

Suggested by:   kib

288953 by dim:
Stop linking libc++.so verbosely, there is no need to.

MFC after:  3 days

288952 by adrian:
Remove gen3 check introduced in r286653.

kib spotted this and noticed it's not correct.

Submitted by:   kib
Reviewed by:dumbbell

288951 by dim:
For llvm/clang libraries, skip including tablegen-produced .d files when
the target is "make depend".  This works around errors during
incremental make depend of some clang libraries, for example "don't know
how to make contrib/llvm/include/llvm/IR/IntrinsicsR600.td".

Reported by:emaste

288950 by jhb:
Group the decoded system calls by ABI and sort the calls within each ABI.

Reviewed by:bdrewery
Glanced at by:  kib
Differential Revision:  https://reviews.freebsd.org/D3823

288949 by jhb:
Fix various edge cases related to system call tracing.
- Always set td_dbg_sc_* when P_TRACED is set on system call entry
  even if the debugger is not tracing system call entries.  This
  ensures the fields are valid when reporting other stops that
  occur at system call boundaries such as for PT_FOLLOW_FORKS or
  when only tracing system call exits.
- Set TDB_SCX when reporting the stop for a new child process in
  fork_return().  This causes the event to be reported as a system
  call exit.
- Report a system call exit event in fork_return() for new threads in
  a traced process.
- Copy td_dbg_sc_* to new threads instead of zeroing.  This ensures
  that td_dbg_sc_code in particular will report the system call that
  created the new thread or process when it reports a system call
  exit event in fork_return().
- Add new ptrace tests to verify that new child processes and threads
  report system call exit events with a valid pl_syscall_code via
  PT_LWPINFO.

Reviewed by:kib
Differential Revision:  https://reviews.freebsd.org/D3822

288948 by gjb:
Update the last check revision marker.

Sponsored by:   The FreeBSD Foundation

288947 by gjb:
Document r288943, clang, llvm, etc. updated to upstream 3.7.0.

Sponsored by:   The FreeBSD Foundation

288944 by cem:
Fix core corruption caused by race in note_procstat_vmmap

This fix is spiritually similar to r287442 and was discovered thanks to
the KASSERT added in that revision.

NT_PROCSTAT_VMMAP output length, when packing kinfo structs, is tied to
the length of filenames corresponding to vnodes in the process' vm map
via vn_fullpath.  As vnodes may move during coredump, this is racy.

We do not remove the race, only prevent it from causing coredump
corruption.

- Add a sysctl, kern.coredump_pack_vmmapinfo, to allow users to disable
  kinfo packing for PROCSTAT_VMMAP notes.  This avoids VMMAP corruption
  and truncation, even if names change, at the cost of up to PATH_MAX
  bytes per mapped object.  The new sysctl is documented in core.5.

- Fix note_procstat_vmmap to self-limit in the second pass.  This
  addresses corruption, at the cost of sometimes producing a truncated
  result.

- Fix PROCSTAT_VMMAP consumers libutil (and libprocstat, via copy-paste)
  to grok the new zero padding.

Reported by:pho (https://people.freebsd.org/~pho/stress/log/datamove4-2.txt)
Relnotes:   yes
Sponsored by:   EMC / Isilon Storage Division
Differential Revision:  https://reviews.freebsd.org/D3824

288943 by dim:
Upgrade our copies of clang, llvm, lldb, compiler-rt and libc++ to 3.7.0
release.

Please note that from 3.5.0 onwards, clang, llvm and lldb require C++11
support to build; see UPDATING for more information.

Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.7.0/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.7.0/tools/clang/docs/ReleaseNotes.html>

Thanks to Ed Maste, Andrew Turner and Antoine Brodin for their help.

Exp-run:antoine
Relnotes:   yes

288937 by gjb:
Document r288669, stack protector "strong" level.

Help from:  pfg
Sponsored by:   The FreeBSD Foundation

288936 by gjb:
Document r288654, lagg(4) fec removal.

Sponsor