Jenkins build is still unstable: FreeBSD_HEAD #96

[jenkins-admin]

See 

___
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"

Jenkins build is still unstable: FreeBSD_HEAD #95

[jenkins-admin]

See 

___
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"

Jenkins build is unstable: FreeBSD_HEAD #94

[jenkins-admin]

See 

___
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"

Re: ZFSROOT UEFI boot

[Steven Hartland]

Thanks for doing that it was very helpful, and I know transcribing from 
video would have been quite a time consuming task.


I noticed a few interesting facts:
1. It looks like when you boot from ada0 and ada1 its still picking the 
same device (according to device order).
Its not 100% clear as your devices are sata which Diff 6 didn't have 
decoding for. I've added that now so hopefully we can confirm, also 
added output of boot1 imgpath: so we can see what the EFI thinks the 
boot device is.
2. Your usb device path has two message path entries which means 
msg_paths_match would result in a false positive for usb devices, this 
is now fixed by matching until we see a media path.


If you can now re-test the following two cases:
2) Boot from ada0 without USB memstick attached (2 drives).
3) Boot from ada1 without USB memstick attached (2 drives).

I'm interested to confirm two things:
1. If the boot1 imgpath lines do indeed vary
2. If the "load: '/boot/loader.efi'" line devpath matches the boot1 imgpath.

The changes from Diff 7 shouldn't effect the outcome of the other tests, 
but confirming that too wouldn't hurt but no need for the output.


Regards
Steve
On 31/01/2016 11:43, Tomoaki AOKI wrote:

I found Diff6 you uploaded to PHABRICATOR. So my report below is based
on it.

The patched boot1.efi runs as expected (== as you wrote) for me.
   *boot1.efi without -DEFI_DEBUG isn't tested. Needed?

As I mentioned in my previous post, I have no serial console
environment. So I took movie of limited tests and typed it.

Which of the tests are typed:

   1) Boot from ada0 removing ada1, no USB memstick attached, ZFS in
  ada0 has loader.efi. (Single drive config.)

   2) Boot from ada0, no USB memstick attached, ZFS in ada0 has
  loader.efi.

   3) Boot from ada1, no USB memstick attached, ZFS in ada1 has
  loader.efi.

   4) Boot from ada1, no USB memstick attached, only UFS in ada0 has
  loader.efi.

   5) Boot from da0 (USB memstick with memstick.img of head).
  UFS in da0 has loader.efi and ZFS isn't present in da0.
  (3 drives [2 drives + USB memstick] config.)

Please see attached text for detail. Are more outputs needed?

Thanks in advance! I'm looking forward to see this MFC'ed before
releng/10.3 is branched. (Relies on imp@'s test?)

  *Will need to be in conjunction with changes after r294265 in head, as
   currently Diff6 doesn't apply to stable/10.

Regards.


On Sat, 30 Jan 2016 19:12:34 +
Steven Hartland  wrote:


I believe, based on testing, that the from Diff 5 onwards of
https://reviews.freebsd.org/D5108 this should work as you expect it i.e.

If boot1 is loaded from a device which has either a UFS or ZFS bootable
install then this is the device that will be used to boot.

If said device has both then the ZFS setup will still be tried first.

If you can test in your setup and confirm either way that would be most
appreciated.

  Regards
  Steve

On 30/01/2016 06:57, Tomoaki AOKI wrote:

Thanks for your quick support!
I tried your patch [Diff1] (built with head r295032 world/kernel) and
now have good and bad news.

Good news is that without USB memstick boot1.efi runs as expected.
Great!

Bad news is that when booting from USB memstick (the one I used my
previous test, boot1.efi [bootx64.efi] and loader.efi is replaced) and
whichever of internal disk (ada[01]) have loader.efi in its ZFS pool,
ada[01] is booted instead of da0 (USB memstick).

*If ada0 has loader.efi, always booted from ada0 (stable/10).
*If ada0 doesn't have loader.efi and ada1 has, booted from ada1
 (head).
*If both ada0 and ada1 don't have loader.efi, da0 (USB memstick) is
 booted (head, installer is invoked).

   *Whichever ada[01] has loader.efi in their UFS or not didn't matter.

These behaviour would be because ZFS thoughout all disks is tried
before trying UFS throughout all disks, if I understood correctly.

Changing boot order (ZFS to UFS per each disk, instead of each
ZFS to each UFS) would help.
But providing ZFS-disabled boot1.efi (boot1ufs.efi?) for installation
media (memstick, dvd, ...) helps, too. I built ZFS-disabled boot1.efi
and it worked fine for USB memstick for me.

   *`make clean && make -DMK_ZFS=no` in sys/boot/efi/boot1 didn't disabled
 ZFS module, so I must edit the definition of *boot_modules[] in
 boot1.c. I'd have been missing something.

Regards.


On Fri, 29 Jan 2016 02:58:26 +
Steven Hartland  wrote:


On 28/01/2016 16:22, Doug Rabson wrote:

On 28 January 2016 at 15:03, Tomoaki AOKI  wrote:


It's exactly the NO GOOD point. The disk where boot1 is read from
should be where loader.efi and loader.conf are first read.


I just wanted to note that gptzfsboot and zfsboot behaves this way. Boot1
looks for loader in the pool which contains the disk that the BIOS booted.
It passes through the ID of that pool to loader which uses that pool as the
default for loading kernel and modules. I believe this is the correct
behaviour. For

Re: ZFSROOT UEFI boot

[Tomoaki AOKI]

Sorry. I just noticed this mail is not a duplicate of which I just
responded to. :-(

I built boot1.efi that is applied Diff6 with -DEFI_DEBUG, but not with
-DDEBUG.
Was it sufficient? Or does some info be missed with above option I set?


On Sat, 30 Jan 2016 12:43:31 +
Steven Hartland  wrote:

> I did some more work on the review last night, if you could apply the
> latest patch set diff4 to see if that helps.
> 
> If not compile with debugging using -DEFI_DEBUG on your make line then you
> will get a lot more information about which disk is being used to load from
> as well as info about the probe order.
> 
> What you should see is that the disk you boot from (where boot1 is loaded
> from) should be probed first and hence get flagged as successful
> (preferred).
> 
> This also shows up as * instead of + in the non-debug boot process.
> 
> If this happens you should see loader.efi loaded from this disk and then
> the kernel.
> 
> The debug output is verbose so you may need a serial console to be able to
> capture the output easily.
> 
> Thanks for testing so far hopefully we can nail this soon 〓
> On Saturday, 30 January 2016, Tomoaki AOKI 
> wrote:
> 
> > Thanks for your quick support!
> > I tried your patch [Diff1] (built with head r295032 world/kernel) and
> > now have good and bad news.
> >
> > Good news is that without USB memstick boot1.efi runs as expected.
> > Great!
> >
> > Bad news is that when booting from USB memstick (the one I used my
> > previous test, boot1.efi [bootx64.efi] and loader.efi is replaced) and
> > whichever of internal disk (ada[01]) have loader.efi in its ZFS pool,
> > ada[01] is booted instead of da0 (USB memstick).
> >
> >   *If ada0 has loader.efi, always booted from ada0 (stable/10).
> >   *If ada0 doesn't have loader.efi and ada1 has, booted from ada1
> >(head).
> >   *If both ada0 and ada1 don't have loader.efi, da0 (USB memstick) is
> >booted (head, installer is invoked).
> >
> >  *Whichever ada[01] has loader.efi in their UFS or not didn't matter.
> >
> > These behaviour would be because ZFS thoughout all disks is tried
> > before trying UFS throughout all disks, if I understood correctly.
> >
> > Changing boot order (ZFS to UFS per each disk, instead of each
> > ZFS to each UFS) would help.
> > But providing ZFS-disabled boot1.efi (boot1ufs.efi?) for installation
> > media (memstick, dvd, ...) helps, too. I built ZFS-disabled boot1.efi
> > and it worked fine for USB memstick for me.
> >
> >  *`make clean && make -DMK_ZFS=no` in sys/boot/efi/boot1 didn't disabled
> >ZFS module, so I must edit the definition of *boot_modules[] in
> >boot1.c. I'd have been missing something.
> >
> > Regards.
> >
> >
> > On Fri, 29 Jan 2016 02:58:26 +
> > Steven Hartland > wrote:
> >
> > > On 28/01/2016 16:22, Doug Rabson wrote:
> > > > On 28 January 2016 at 15:03, Tomoaki AOKI  > > wrote:
> > > >
> > > >> It's exactly the NO GOOD point. The disk where boot1 is read from
> > > >> should be where loader.efi and loader.conf are first read.
> > > >>
> > > > I just wanted to note that gptzfsboot and zfsboot behaves this way.
> > Boot1
> > > > looks for loader in the pool which contains the disk that the BIOS
> > booted.
> > > > It passes through the ID of that pool to loader which uses that pool
> > as the
> > > > default for loading kernel and modules. I believe this is the correct
> > > > behaviour. For gptzfsboot and zfsboot, it is possible to override by
> > > > pressing space at the point where it is about to load loader.
> > >
> > > I believe I understand at least some of your issue now, could you please
> > > test the code on the following review to see if it fixes your issue
> > please:
> > > https://reviews.freebsd.org/D5108
> > >
> > >  Regards
> > >  Steve
> > > ___
> > > 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 "
> > >
> >
> >
> > --
> > 青木 知明  [Tomoaki AOKI]
> > junch...@dec.sakura.ne.jp 
> > mxe02...@nifty.com 
> > ___
> > 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
> > "
> >


-- 
青木 知明  [Tomoaki AOKI]
junch...@dec.sakura.ne.jp
mxe02...@nifty.com
___
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"

Re: ZFSROOT UEFI boot

[Tomoaki AOKI]

I found Diff6 you uploaded to PHABRICATOR. So my report below is based
on it.

The patched boot1.efi runs as expected (== as you wrote) for me.
  *boot1.efi without -DEFI_DEBUG isn't tested. Needed?

As I mentioned in my previous post, I have no serial console
environment. So I took movie of limited tests and typed it.

Which of the tests are typed:

  1) Boot from ada0 removing ada1, no USB memstick attached, ZFS in
 ada0 has loader.efi. (Single drive config.)

  2) Boot from ada0, no USB memstick attached, ZFS in ada0 has
 loader.efi.

  3) Boot from ada1, no USB memstick attached, ZFS in ada1 has
 loader.efi.

  4) Boot from ada1, no USB memstick attached, only UFS in ada0 has
 loader.efi.

  5) Boot from da0 (USB memstick with memstick.img of head).
 UFS in da0 has loader.efi and ZFS isn't present in da0.
 (3 drives [2 drives + USB memstick] config.)

Please see attached text for detail. Are more outputs needed?

Thanks in advance! I'm looking forward to see this MFC'ed before
releng/10.3 is branched. (Relies on imp@'s test?)

 *Will need to be in conjunction with changes after r294265 in head, as
  currently Diff6 doesn't apply to stable/10.

Regards.


On Sat, 30 Jan 2016 19:12:34 +
Steven Hartland  wrote:

> I believe, based on testing, that the from Diff 5 onwards of 
> https://reviews.freebsd.org/D5108 this should work as you expect it i.e.
> 
> If boot1 is loaded from a device which has either a UFS or ZFS bootable 
> install then this is the device that will be used to boot.
> 
> If said device has both then the ZFS setup will still be tried first.
> 
> If you can test in your setup and confirm either way that would be most 
> appreciated.
> 
>  Regards
>  Steve
> 
> On 30/01/2016 06:57, Tomoaki AOKI wrote:
> > Thanks for your quick support!
> > I tried your patch [Diff1] (built with head r295032 world/kernel) and
> > now have good and bad news.
> >
> > Good news is that without USB memstick boot1.efi runs as expected.
> > Great!
> >
> > Bad news is that when booting from USB memstick (the one I used my
> > previous test, boot1.efi [bootx64.efi] and loader.efi is replaced) and
> > whichever of internal disk (ada[01]) have loader.efi in its ZFS pool,
> > ada[01] is booted instead of da0 (USB memstick).
> >
> >*If ada0 has loader.efi, always booted from ada0 (stable/10).
> >*If ada0 doesn't have loader.efi and ada1 has, booted from ada1
> > (head).
> >*If both ada0 and ada1 don't have loader.efi, da0 (USB memstick) is
> > booted (head, installer is invoked).
> >
> >   *Whichever ada[01] has loader.efi in their UFS or not didn't matter.
> >
> > These behaviour would be because ZFS thoughout all disks is tried
> > before trying UFS throughout all disks, if I understood correctly.
> >
> > Changing boot order (ZFS to UFS per each disk, instead of each
> > ZFS to each UFS) would help.
> > But providing ZFS-disabled boot1.efi (boot1ufs.efi?) for installation
> > media (memstick, dvd, ...) helps, too. I built ZFS-disabled boot1.efi
> > and it worked fine for USB memstick for me.
> >
> >   *`make clean && make -DMK_ZFS=no` in sys/boot/efi/boot1 didn't disabled
> > ZFS module, so I must edit the definition of *boot_modules[] in
> > boot1.c. I'd have been missing something.
> >
> > Regards.
> >
> >
> > On Fri, 29 Jan 2016 02:58:26 +
> > Steven Hartland  wrote:
> >
> >> On 28/01/2016 16:22, Doug Rabson wrote:
> >>> On 28 January 2016 at 15:03, Tomoaki AOKI  
> >>> wrote:
> >>>
>  It's exactly the NO GOOD point. The disk where boot1 is read from
>  should be where loader.efi and loader.conf are first read.
> 
> >>> I just wanted to note that gptzfsboot and zfsboot behaves this way. Boot1
> >>> looks for loader in the pool which contains the disk that the BIOS booted.
> >>> It passes through the ID of that pool to loader which uses that pool as 
> >>> the
> >>> default for loading kernel and modules. I believe this is the correct
> >>> behaviour. For gptzfsboot and zfsboot, it is possible to override by
> >>> pressing space at the point where it is about to load loader.
> >> I believe I understand at least some of your issue now, could you please
> >> test the code on the following review to see if it fixes your issue please:
> >> https://reviews.freebsd.org/D5108
> >>
> >>   Regards
> >>   Steve
> >> ___
> >> 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-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 


-- 
Tomoaki AOKIjunch...@dec.sakura.ne.jp
For internal disks, ZFS only have loader.efi [Except 4)].
USB memstick has no ZFS and has loader.efi i

Re: thread-unsafety problems as spl*() ones are NOP

[Slawa Olhovchenkov]

On Sun, Jan 31, 2016 at 10:00:51AM +0330, mokhi wrote:

> @imp:
> i exactly mean (Okay not so exact but very near ;D) what you said.
> after analyzing kbd.c functions (eg, kbd_realloc_array()) i concluded
> there are race conditions (and at  result in some places there are
> un-protected data too)
> 
> i don't mean to blindly replace splXXX() with locks, but the places i
> see race-conds.
> Also i should say there are manythings i dunno well or i dont have
> deep understanding of them and that's why im here to ask (ie what
> special condition Giant-Lock makes here [i should care about] and what
> is MPSAFE basically)
> i'd happy if you answer me those question too :D

I think god explainig can be found in VMS Device Support Manual,
Section 3 (for example
http://odl.sysworks.biz/disk$cddoc04mar21/decw$book/d32va114.p63.decw$book#186).

splXXX is analouge of VMS IPL 1-15 and have same purpose.

Or The Design and Implementation of the 4.3BSD UNIX Operating System
(Chapter 3.3).

Also you can look in FreeBSD repo, stable/2.2 branch, sys/i386/include/spl.h
___
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 #1046 - Fixed

[jenkins-admin]

FreeBSD_HEAD_amd64_gcc4.9 - Build #1046 - Fixed:

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

Change summaries:

295091 by mmel:
ARM: Rename ARM specific VM_MEMATTR_WT memory attribute to standard one.

295090 by mmel:
ARM: Convert spaces to tabs, fix formatting.
Not a functional change.

295089 by mmel:
ARM: Next round of cleanup in swtch-v*.S.
 - remove now useless #if __ARM_ARCH conditional
 - use macro for accessing CP15 registers
 - remove unused PCPU_SIZE

Pointed by: kib

295087 by imp:
Implement power command to list all power modes, find out the power
mode we're in and to set the power mode.

295086 by ian:
Make pfctl(8) work on strict-alignment platforms, by copying a pair of
embedded structures out of a packed, unaligned struct into local copies
on the stack which are aligned.

The original patch to do this was submitted by Guy Yur ,
and this is conceptually the same change, but restructured with the
#ifndef __NO_STRICT_ALIGNMENT wrapper, similar to how the same issue is
handled in the kernel pf code.

PR: 185617
PR: 206658

295085 by jilles:
sh: Don't allocate a redirtab if there are no redirections.

Builtins (including variable assignments without command word), function
calls and redirected compound commands need to restore file descriptors
to their original state after execution. This is handled by allocating a
redirtab structure. These mallocs and frees show up heavily in pmcstat.

Only allocate a redirtab if there are actually redirections and maintain a
count of how many levels of REDIR_PUSH there are without redirtabs.

A simple loop without external programs like

sh -c 'i=0; w=$(printf %0100d 7); while [ "$i" -lt 100 ]; do
i=$((i+1)); done'

is over 25% faster on an amd64 bhyve VM.

295083 by jilles:
sh(1): Document 'cd -'.

This reflects the changes in r294649 and can therefore not be MFCed by
itself.

295082 by jilles:
test: Optimize operator lookup.

The linear search using strcmp() shows up in pmcstat for several percent.

Split the operators into lengths and whether they start with '-' and compare
bytes using == instead of strcmp().

A simple test

sh -c 'i=0; w=$(printf %0100d 7); while [ "$i" -lt 100 ]; do
v=$(printf %sx%s "$w" "$w"); i=$((i+1)); done'

is over 4% faster on an amd64 bhyve VM.

295080 by ngie:
Use the correct type for i when iterating over `buf` to avoid unlikely
negative array indexing in iicrdwr(..)

Differential Revision: https://reviews.freebsd.org/D5132
Obtained from: HardenedBSD
PR: 206754
Reported by: CTurt 
Submitted by: Madhi Moktari 
Sponsored by: EMC / Isilon Storage Division

295079 by ngie:
Fix the type for hw.ncpu, so sysctlbyname doesn't consistently fail on
64-bit architectures where sizeof(int) != sizeof(size_t).

MFC after: 1 week
PR: 206758
Reported by: Christoph Schönweiler 
Submitted by: kib
Sponsored by: EMC / Isilon Storage Division

295077 by tuexen:
Add missing parentheses. This was reported by ccaughie via GitHub
for the userland stack.

MFC after: 3 days

295076 by ngie:
Revert r295062 to unbreak buildworld

Some of the structures referenced in power.c (in particular
struct nvme_power_state) are missing from sbin/nvmecontrol/

Pointyhat to: imp
Reported by: Jenkins [*], O. Hartmann , Outback 
Dingo 

295075 by tuexen:
Update the path mtu when turning on/off UDP encapsulation for SCTP.

MFC after: 3 days

295074 by allanjude:
The zfsboot automated part of bsdinstall now supports UEFI

MFC after:  3 days
Sponsored by:   ScaleEngine Inc.
Differential Revision:  https://reviews.freebsd.org/D4960

295073 by mmel:
ARM: Remove TLB IPI.
We don't support SMP on ARMv6. All ARMv7 multicore cpus already uses
hardware broadcast for TLB and cache operations.

295072 by tuexen:
Don't allow a remote encapsulation port change during the
SCTP restart procedure.

MFC after: 3 days

295071 by mmel:
ARM: Cleanup mp_machdep.c. SMP is supported only on ARMv6 and later.

295070 by tuexen:
Don't change the remote UDP encapsulation port for SCTP packets
containing an INIT chunk.

MFC after: 3 days

295069 by tuexen:
Ignore peer addresses in a consistent way also when checking for
new addresses during restart. If this is not done, restart doesn't
work when the local socket is IPv4 only and the peer uses
IPv4 and IPv6 addresses.

MFC after: 3 days.

295068 by mmel:
ARM: Don't misuse ARM_TP_ADDRESS as ARMv4 / ARMv6 selector.

___
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"

Build failed in Jenkins: FreeBSD_HEAD #87

[jenkins-admin]

See 

--
[...truncated 58358 lines...]
c++  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/tools/clang/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis
 -I. 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DDEFAULT_SYSROOT=\"/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp\"
 -Qunused-arguments 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
  -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -c 
/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib
 /llvm/lib/Analysis/ScopedNoAliasAA.cpp -o ScopedNoAliasAA.o
--- SparsePropagation.o ---
c++  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/tools/clang/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis
 -I. 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DDEFAULT_SYSROOT=\"/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp\"
 -Qunused-arguments 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
  -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -c 
/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib
 /llvm/lib/Analysis/SparsePropagation.cpp -o SparsePropagation.o
--- TargetLibraryInfo.o ---
c++  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/tools/clang/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis
 -I. 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DDEFAULT_SYSROOT=\"/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp\"
 -Qunused-arguments 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
  -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -c 
/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib
 /llvm/lib/Analysis/TargetLibraryInfo.cpp -o TargetLibraryInfo.o
--- TargetTransformInfo.o ---
c++  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/tools/clang/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis
 -I. 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/../../lib/clang/include
 -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS 
-D__STDC_CONSTANT_MACROS -fno-strict-aliasing 
-DLLVM_DEFAULT_TARGET_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" 
-DDEFAULT_SYSROOT=\"/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp\"
 -Qunused-arguments 
-I/builds/workspace/FreeBSD_HEAD/obj/builds/workspace/FreeBSD_HEAD/src/tmp/legacy/usr/include
  -std=c++11 -fno-exceptions -fno-rtti -stdlib=libc++ -Wno-c++11-extensions -c 
/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib
 /llvm/lib/Analysis/TargetTransformInfo.cpp -o TargetTransformInfo.o
--- TypeBasedAliasAnalysis.o ---
c++  -O2 -pipe 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/tools/clang/include
 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis
 -I. 
-I/builds/workspace/FreeBSD_HEAD/src/lib/clang/libllvmanalysis/../../../contrib/llvm/../../lib/clang/include