Re: Internal compiler error on gcc with latest updates

On Mon, Dec 2, 2013 at 6:40 AM, Justin Hibbits wrote: > Yesterday I started a full world update for my machine (powerpc64), but > the new gcc import ICEs at emit-rtl.c:1784, when compiling zdb. I > haven't tried reverting contrib/gcc yet, but is there a good way to > debug this? > If you are ge

gdb in CURRENT cannot debug userland cores, when is kernel lldb coming?

Hi, Recently when trying to debug some coredumps in CURRENT from a userland process in the devel/libvirt port, I found that the gdb in base could not get a backtrace from the core file: http://lists.freebsd.org/pipermail/freebsd-virtualization/2014-June/002606.html I needed to add to my /etc/src

Re: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming?

On Wed, Jun 11, 2014 at 12:30 PM, Dimitry Andric wrote: > On 11 Jun 2014, at 20:53, Craig Rodrigues wrote: >> >> Recently when trying to debug some coredumps in CURRENT from >> a userland process in the devel/libvirt port, I found that the gdb in >> base could not ge

Re: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming?

On Wed, Jun 11, 2014 at 12:34 PM, Warner Losh wrote: > > Except for kgdb functionality, the gdb ports (both the 6.x and 7.x ones) work > much better than the gdb in the tree. This may be a good stop-gap until lldb > is ready. > > Warner > I installed devel/gdb which installs gdb762. When I tri

Re: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming?

On Wed, Jun 11, 2014 at 1:39 PM, Dimitry Andric wrote: > Ah sorry, your objdump prints sections in a different order than mine. > I was mainly interested in the DWARF version of debug information; maybe > the way you built libvirt has caused it to contain DWARF4 instead of > DWARF2. > > Can you po

Re: gdb in CURRENT cannot debug userland cores, when is kernel lldb coming?

gdb from base (at least in CURRENT). Thanks. -- Craig On Wed, Jun 11, 2014 at 11:53 AM, Craig Rodrigues wrote: > Hi, > > Recently when trying to debug some coredumps in CURRENT from > a userland process in the devel/libvirt port, I found that the gdb in > base could not get a bac

Jenkins and LLVM clang analyzer on FreeBSD

Hi, FYI, Li-Wen Hsu has set up this Jenkins job which builds FreeBSD with the clang analyzer ( https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-scan-build/ ): https://jenkins.freebsd.org/jenkins/job/FreeBSD_HEAD-scan-build/ This job runs once a week. Please view the results of this job, an

Re: clang and code coverage

On Thu, Nov 6, 2014 at 9:13 AM, Arthur Mesh wrote: > > /usr/bin/ld: /usr/bin/../lib/libprofile_rt.a: No such file: No such file > or directory > Prokash Sinha from Panasas asked the exact same question: https://lists.freebsd.org/pipermail/freebsd-toolchain/2014-August/001181.html but unfortuna

Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0

Hi, I just tried to build CURRENT with WITH_LLDB=yes in /etc/make.conf. I got this error: /usr/obj/opt2/branches/head/usr.bin/clang/lldb/../../../lib/clang/libllvmaarch64disassemble r/libllvmaarch64disassembler.a(AArch64Disassembler.o): In function `createAArch64ExternalSy mbolizer(llvm::StringR

Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0

On Thu, Jan 8, 2015 at 6:04 AM, Ed Maste wrote: > On 8 January 2015 at 08:45, Craig Rodrigues wrote: > > I just tried to build CURRENT with WITH_LLDB=yes > > in /etc/make.conf. I got this error: > > > > ... > > Thanks for the report Craig, I'm looking a

Dependency walker for shared libraries in FreeBSD?

Hi, On Windows, there is a tool, http://www.dependencywalker.com/ , that can take a DLL as input, and then display all the dependencies that this DLL has on other libraries. This can be used to detect unresolved symbols. Does anyone have a script that can do this on FreeBSD? Basically, this woul

clang and scanbuild

Hi, We currently have a Jenkins job which checks out llvm trunk and builds it like this: svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm cd llvm ./configure --enable-optimized --disable-assertions --disable-docs --enable-targets=host \ --with-c-include-dirs=${WORKDIR}/obj${WORKDIR}/sr

Re: clang and scanbuild

On Wed, Feb 11, 2015 at 1:43 PM, Dimitry Andric wrote: > > Yes, choose either lang/clang-devel, or lang/clangXY, where XY is the > version you are interested in. > > > > (2) is there enough llvm source in FreeBSD that we can build this in > > FreeBSD instead of checking out llvm source

Re: clang and scanbuild

On Mon, Feb 16, 2015 at 1:42 PM, Brooks Davis wrote: > On Mon, Feb 16, 2015 at 01:21:34PM -0800, Craig Rodrigues wrote: > > On Wed, Feb 11, 2015 at 1:43 PM, Dimitry Andric wrote: > > > > > > > > Yes, choose either lang/clang-devel, or lang/clangXY, wher

Failed to build with external toolchain

Hi, Based on this mail: https://lists.freebsd.org/pipermail/freebsd-current/2014-November/053577.html I created this script to build HEAD with amd64-gcc: https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh However, when I ran the script, I got this error: https://jen

Re: Failed to build with external toolchain

On Tue, Mar 3, 2015 at 9:17 AM, Dimitry Andric wrote: > On 03 Mar 2015, at 09:00, Craig Rodrigues wrote: > CXXFLAGS+= -D_LIBCPP_HAS_NO_ADVANCED_SFINAE > > to the make.conf file you use for building. > Thanks for the tip. I added that to make.conf, but now I am getting a

Re: Failed to build with external toolchain

Hi, I ran the build again and this time I am getting errors about undefined symbol utimensat(): https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/14/console Any ideas? -- Craig ___ freebsd-toolchain@freebsd.org mailing list http://li

Re: Failed to build with external toolchain

On Sat, Mar 7, 2015 at 3:48 PM, Dimitry Andric wrote: > On 07 Mar 2015, at 21:12, Craig Rodrigues wrote: > > I ran the build again and this time I am getting errors about undefined > > symbol utimensat(): > > > > > https://jenkins.freebsd.org/job/FreeBSD_HEAD_ext

External toolchain build failing due to missing --sysroot

Warner, I can't get the external toolchain build of CURRENT to work, because --sysroot seems to be missing in some places. See: https://lists.freebsd.org/pipermail/freebsd-toolchain/2015-March/001452.html gnn@ said you might know where this can be fixed. Any idea of a patch that can fix this?

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

On Sun, Mar 22, 2015 at 11:26 AM, wrote: > See > Can someone with toolchain expertise look at this? After the clang 3.6.1 import, /bin/expr behaves differently. With clang 3.5.0: # expr 4611686018427387904 + 4611686018427387904 expr: o

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

On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric 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 > ==

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

On Sun, Mar 22, 2015 at 2:36 PM, Dimitry Andric wrote: > On 22 Mar 2015, at 22:32, Craig Rodrigues wrote: > > > > On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric wrote: > > > > Ah right, that was on i386, on amd64 it does result in -2^63. It is > indeed caused

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

On Sun, Mar 22, 2015 at 3:01 PM, Craig Rodrigues wrote: > > > On Sun, Mar 22, 2015 at 2:36 PM, Dimitry Andric wrote: > >> On 22 Mar 2015, at 22:32, Craig Rodrigues wrote: >> > >> > On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric >> wrote: >> >

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

Hi, I tried to build HEAD with gcc 4.9.1 after the latest clang 3.6.0 import, and am getting new build failures related to C++ such as: /builds/FreeBSD_HEAD_external_toolchain_gcc/obj/builds/FreeBSD_HEAD_external_toolchain_gcc/tmp/usr/include/c++/v1/type_traits:881:87: error: use of deleted funct

Re: Failed to build with external toolchain

On Sat, Mar 7, 2015 at 3:48 PM, Dimitry Andric wrote: > On 07 Mar 2015, at 21:12, Craig Rodrigues wrote: > > I ran the build again and this time I am getting errors about undefined > > symbol utimensat(): > > > > > https://jenkins.freebsd.org/job/FreeBSD_HEAD_ext

Re: Failed to build with external toolchain

On Tue, Mar 24, 2015 at 8:39 PM, Warner Losh wrote: > > > No. The in-tree gcc doesn't grok --sysroot. > > We assume that version gcc 4.2.1 is special and our in-tree compiler > elsewhere, > so please add a check for that and just go ahead and duplicate those two > lines. > > Eg > > +.else if ${CO

Re: Failed to build with external toolchain

On Thu, Mar 26, 2015 at 11:47 AM, Warner Losh wrote: > > > On Mar 26, 2015, at 2:12 AM, Craig Rodrigues > wrote: > > OK. I have a bit of egg on my face... > > The test is for X_COMPILER_TYPE, so COMPILER_VERSION isn't relevant. It's > always outside the tree

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

On Mon, Mar 23, 2015 at 12:12 AM, Dimitry Andric wrote: > On 23 Mar 2015, at 01:49, Craig Rodrigues wrote: > > > > Hi, > > > > I tried to build HEAD with gcc 4.9.1 after the latest clang 3.6.0 import, > > and am getting > > new build failures re

lldb compilation problem with gcc 4.9

Hi, I had problems compiling lldb with gcc 4.9. See problem description plus patch which I submitted upstream: https://llvm.org/bugs/show_bug.cgi?id=23051 -- Craig ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinf

Re: lldb compilation problem with gcc 4.9

On Fri, Mar 27, 2015 at 10:03 PM, Craig Rodrigues wrote: > Hi, > > I had problems compiling lldb with gcc 4.9. > > See problem description plus patch which I submitted upstream: > > https://llvm.org/bugs/show_bug.cgi?id=23051 > > My patch was accepted upstream:

Failed to build rescue with gcc 4.9

Hi, The build host VM that I used was FreeBSD 10.1-RELEASE, amd64. I took this patch for libc++ and applied it to my tree: http://reviews.llvm.org/D8461 I used this script to build with gcc 4.9: https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh Building rescue fai

Re: Failed to build rescue with gcc 4.9

On Sat, Mar 28, 2015 at 2:34 PM, Craig Rodrigues wrote: > > > I double checked. cat.lo is not a truncated file. > # ls -l cat.lo ; file cat.lo > -rw-r--r-- 1 jenkins wheel 13112 Mar 28 21:17 cat.lo > cat.lo: ELF 64-bit LSB relocatable, x86-64, version 1 (FreeBSD), strippe

Fails to build sys/i386/boot2 with gcc 4.9

Hi, To work around the problems build rescue, this time I used a build host running FreeBSD-CURRENT at svn revision r280353 I took this patch for libc++ and applied it to my tree: http://reviews.llvm.org/D8461 I used this script to build with gcc 4.9: https://github.com/freebsd/freebsd-ci/blob

Re: Fails to build sys/i386/boot2 with gcc 4.9

On Sun, Mar 29, 2015 at 11:04 AM, Warner Losh wrote: > > If we built a UFS1-only boot2, that would fit in the 7.5k we have left > to play with. We could then build a UFS2-only boot2 that would easily > fit in the like 32k limit that UFS2 has. > > The only reason we went to supporting both was to

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

Hi, 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)::

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

On Sun, Mar 29, 2015 at 1:52 PM, Dimitry Andric wrote: > > > 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. I am not using make -s. If you look at t

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

On Mon, Mar 23, 2015 at 12:12 AM, Dimitry Andric wrote: > > On 23 Mar 2015, at 01:49, Craig Rodrigues wrote: > > > > Hi, > > > > I tried to build HEAD with gcc 4.9.1 after the latest clang 3.6.0 import, > > and am getting > > new build failur

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

On Tue, Mar 31, 2015 at 11:20 AM, Dimitry Andric wrote: > On 31 Mar 2015, at 20:13, Dimitry Andric wrote: > ... > > but then: > > > > + patch > > Hmm... Looks like a unified diff to me... > > The text leading up to this was: > > -- > > |Index: contrib/libc++/include/type

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

On Tue, Mar 31, 2015 at 12:48 PM, Dimitry Andric wrote: > On 31 Mar 2015, at 21:38, Craig Rodrigues wrote: > > > > On Tue, Mar 31, 2015 at 11:20 AM, Dimitry Andric > wrote: > > > >> On 31 Mar 2015, at 20:13, Dimitry Andric wrote: > >> ... >

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

On Tue, Mar 31, 2015 at 1:41 PM, Dimitry Andric wrote: > On 31 Mar 2015, at 22:06, Craig Rodrigues wrote: > > > > On Tue, Mar 31, 2015 at 12:48 PM, Dimitry Andric > wrote: > > On 31 Mar 2015, at 21:38, Craig Rodrigues wrote: > > > > > > On Tue

Kernel compilation failures with gcc 4.9

Hi, I put this in make.conf: NO_WERROR=yes WERROR= WITHOUT_BOOT=yes WITHOUT_RESCUE=yes and used this script to build: https://github.com/freebsd/freebsd-ci/blob/master/scripts/build/cross-build.sh I managed to build a lot of stuff, but then got build failures in the aesni part of the kernel bui

Re: Kernel compilation failures with gcc 4.9

On Tue, Mar 31, 2015 at 4:55 PM, Warner Losh wrote: > > > > > It shouldn't be using the stdlib when it's built with -ffreestanding or > -nostdlib. Can you make sure? > > The AES stuff breaks the rules, and this is a consequence of it :( That > stuff should be fixed. > > John-Mark, Do you have t

Re: Kernel compilation failures with gcc 4.9

On Tue, Mar 31, 2015 at 10:10 PM, John-Mark Gurney wrote: > > > This is an issue w/ gcc 4.9's headers... It is including stdlib.h, > via mm_malloc.h which is conflicting w/ sys/malloc.h's version of free.. > > kan wrapped the include of mm_malloc.h in an #if __STDC_HOSTED__ which is > why gcc 4.2

Re: FYI: Things that I've noticed for powerpc64-xtoolchain-gcc...

On Sun, Mar 29, 2015 at 1:13 AM, Mark Millard wrote: > You [Craig Rodrigues] seem to be checking some ??-xtoolchain-gcc things > officially. I've some user-experience notes from happening to use > powerpc64-xtoolchain-gcc in my exploration of FreeBSD. Hopefully some of it > mig

Re: Failed to build rescue with gcc 4.9

On Sat, Mar 28, 2015 at 2:34 PM, Craig Rodrigues wrote: > Hi, > > The build host VM that I used was FreeBSD 10.1-RELEASE, amd64. > > I took this patch for libc++ and applied it to my tree: > > http://reviews.llvm.org/D8461 > > I used this script to build with gcc 4.

Re: Failed to build rescue with gcc 4.9

On Thu, Apr 2, 2015 at 8:27 AM, Craig Rodrigues wrote: > > Actually, I am building on a 10.1-RELEASE box. > > I was able to get this successful build: > > https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/38/console > > by applying this

Re: Fails to build sys/i386/boot2 with gcc 4.9

On Sat, Mar 28, 2015 at 4:05 PM, Craig Rodrigues wrote: > Hi, > > To work around the problems build rescue, this time I used a build host > running FreeBSD-CURRENT at svn revision r280353 > > I took this patch for libc++ and applied it to my tree: > > http://reviews.l

[Request for Help] Reducing gcc 4.9 compilation warnings

Hi, After the latest commits by members of freebsd-toolchain@ , I have managed to compile latest CURRENT world and GENERIC kernel on amd64 with an gcc 4.9 external toolchain by doing: pkg install devel/amd64-xtoolchain-gcc cd /usr/src sed -i "" -e 's/boot2//' sys/boot/i386/Makefile ma

Re: [Request for Help] Reducing gcc 4.9 compilation warnings

On Sun, Apr 19, 2015 at 2:10 AM, Eitan Adler wrote: > > Perhaps it would be useful to do a second run of this, but with a > modified share/mk to silence the most useless of these warnings? > > Sure, that's fine. Can you provide a modified share/mk which you think does the right thing? We can tr

Re: External toolchain build failing due to missing --sysroot

On Mon, May 18, 2015 at 12:30 PM, Warner Losh wrote: > > > On Mar 20, 2015, at 2:10 PM, Craig Rodrigues > wrote: > > > > Warner, > > > > I can't get the external toolchain build of CURRENT to work, > > because --sysroot seems to be missing in

devel/amd64-xtoolchain-gcc out of date?

Hi, On a FreeBSD 10.1-RELEASE system I just did: pkg install devel/amd64-gcc pkg install devel/amd64-toolchain-gcc pkg info -o -g '*gcc*' amd64-gcc-4.9.2_1 devel/amd64-gcc amd64-xtoolchain-gcc-0.1 devel/amd64-xtoolchain-gcc The devel/amd64-toolchain-gcc package installs this

Re: clang and scanbuild

On Wed, Feb 11, 2015 at 1:43 PM, Dimitry Andric wrote: > Yes, choose either lang/clang-devel, or lang/clangXY, where XY is the > version you are interested in. > > It looks like scan-build was removed from lang/clang-devel in July. Would it be possible to add it back? Thanks. -- Craig _

Re: bt_split.c error: dereferencing type-punned pointer will break strict-aliasing rules (powerpc64-xtoolchain use)

On Sun, Oct 4, 2015 at 4:06 AM, Mark Millard wrote: > > /usr/src/lib/libc/db/btree/bt_split.c:548:7: error: dereferencing > type-punned pointer will break strict-aliasing rules > [-Werror=strict-aliasing] >bt_preserve(t, *(pgno_t *)bl->bytes) == RET_ERROR) > You will get many of these wa

error: your copy of LLDB does not support scripting.

Hi, In /etc/make.conf, I put WITH_LLDB="yes" and rebuilt/reinstalled the world. I then tried: (lldb) script error: your copy of LLDB does not support scripting. Is there a way to configure LLDB with script support? -- Craig ___ freebsd-toolchain@free

Re: Can we have a toolchain that works?

[Moving discussion to freebsd-toolchain] Dag, Regarding your question about a working debugger, due to your problems debugging code with the in-tree gdb on latest current, we have a few options: (1) Enable WITH_LLDB by default in the make infrastructure, and install lldb. We already hav

[Differential] [Request, 27 lines] D1722: Add -s option to config

rodrigc created this revision. rodrigc added reviewers: brooks, imp. rodrigc added a subscriber: freebsd-toolchain. REVISION SUMMARY This option allows for specifying the directory to use as the location for configuration source files. This option was ported from NetBSD. Submitted by: St

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

rodrigc accepted this revision. BRANCH /head REVISION DETAIL https://reviews.freebsd.org/D2187 To: dim, bapt, emaste, imp, rodrigc Cc: emaste, imp, freebsd-toolchain ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/li

[Differential] [Closed] D1722: Add -s option to config

rodrigc closed this revision. rodrigc added a comment. Committed under rS277904 REVISION DETAIL https://reviews.freebsd.org/D1722 To: rodrigc, brooks, imp Cc: freebsd-toolchain ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/m

[Differential] [Request, 16 lines] D2285: gcc 4.9.1 compilation fixes for aesni

rodrigc created this revision. rodrigc added a reviewer: jmg. rodrigc added a subscriber: freebsd-toolchain. REVISION SUMMARY In the version of gcc in the FreeBSD tree, this modification was made to the compiler: https://svnweb.freebsd.org/base?view=revision&revision=r242182 #if __STDC

[Differential] [Updated, 36 lines] D2285: gcc 4.9.1 compilation fixes for aesni

rodrigc updated this revision to Diff 4825. rodrigc added a comment. OK, here's an updated diff where things are separate out into a different header file. CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D2285?vs=4798&id=4825 REVISION DETAIL https://reviews.freebsd.org/D2285 AFFECTED

[Differential] [Updated, 36 lines] D2285: gcc 4.9.1 compilation fixes for aesni

rodrigc updated this revision to Diff 4840. rodrigc added a comment. Change to <> CHANGES SINCE LAST UPDATE https://reviews.freebsd.org/D2285?vs=4825&id=4840 REVISION DETAIL https://reviews.freebsd.org/D2285 AFFECTED FILES sys/crypto/aesni/aesencdec.h sys/crypto/aesni/aesni_ghash.c sy

[Differential] [Closed] D2285: gcc 4.9.1 compilation fixes for aesni

rodrigc closed this revision. rodrigc updated this revision to Diff 4852. rodrigc added a comment. Closed by commit rS281606 (authored by @rodrigc). CHANGED PRIOR TO COMMIT https://reviews.freebsd.org/D2285?vs=4840&id=4852#toc REVISION DETAIL https://reviews.freebsd.org/D2285 AFFECTED FILES

[Differential] [Request, 6 lines] D2305: Fix bootstraping of crunchide

rodrigc created this revision. rodrigc added reviewers: emaste, imp. rodrigc added a subscriber: freebsd-toolchain. REVISION SUMMARY When using an external gcc 4.9 toolchain on a FreeBSD 10.1 build host, building of the CURRENT branch failed when trying to build rescue. See this discussio

[Differential] [Abandoned] D2305: Fix bootstraping of crunchide

rodrigc abandoned this revision. rodrigc added a comment. Fixed by rS281659 REVISION DETAIL https://reviews.freebsd.org/D2305 To: rodrigc, imp, emaste Cc: freebsd-toolchain ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailm

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

rodrigc created this revision. rodrigc added reviewers: araujo, bapt, emaste, dim. rodrigc added a subscriber: freebsd-toolchain. rodrigc set the repository for this revision to rS FreeBSD src repository. Herald added a subscriber: imp. REVISION SUMMARY Without this fix, compiling ypbind with gc

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

rodrigc added a comment. Sorry for the late response. Please address @dim 's comment, if you have not addressed it already. Also, removing the type-alias punned warnings is trickier than the other types of fixes that we have done to clean up the code. For this change, I would feel more comfortab

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

rodrigc accepted this revision. This revision has a positive review. 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, dim, rodrigc