Re: C++ in jemalloc
Answers inline.
On Sat, Oct 07, 2017 at 03:13:43AM -0700, Mark Millard wrote:
> Just a short top-post as this does not fit well with the
> other material:
>
> I believe Roman only built his example program
> with clang, not the world that the program was
> being run under.
I used a machine with gcc built world and compiled the test program using
clang -stdlib=libstdc++
> The gcc 4.2.1 based code that is analogous to
> __cxa_begin_catch (scratch register initialization)
> in a clang based build world has the scratch
> register CFI material and the same clang produced
> a.out file works fine under such a system (simply
> copied over and run).
>
> And that is why Roman's context did not SIGSEGV but
> mine did: I used clang for the buildworld for
> the world that was being used and so
> __cxa_begin_catch was missing CFI information in
> my build.
>
> In fact the a.out built by gcc 4.2.1 fails under
> the clang based buildworld with the bad
> __cxa_begin_catch .
>
> The only thing that matters is the system library
> code involved, not which a.out (from which compiler).
Ah. I see... Is it possible to isolate a small example
that shows the missing CFI info from clang so that I can
try to fix it without having to build world etc. ?
It should be reasonably simple.
> On 2017-Oct-7, at 2:54 AM, Mark Millard wrote:
>
> [The last part of my note has a dumb mistake, not
> that it messes up the other evidence. I should have
> dwarfdump'd not a.out but the code in the libraries,
> such as __cxa_begin_catch in /lib/libcxxrt.so.1 . I
> made the same mistake initially back when Roman and
> I were dealing with this long ago. Correcting it
> again. . .]
>
> On 2017-Oct-7, at 2:18 AM, Mark Millard wrote:
>
> > [I'm separately listing backtrace information and related
> > information from one of core dumps and going back through
> > the details to see if they seem to be as they were back
> > then. Read only if you care. It does look the same as I
> > found back then if I remember right. I reach the same
> > conclusion I reached back then anyway. I give evidence
> > in the below.]
> >
> > On 2017-Oct-7, at 1:10 AM, Mark Millard wrote:
> >
> >> [I'm adding examples with output from clang -v since it explicitly shows
> >> the path used for ld and such.]
> >>
> >> On 2017-Oct-7, at 12:58 AM, Mark Millard wrote:
> >>
> >>> On 2017-Oct-6, at 11:42 PM, Roman Divacky wrote:
> >>>
> >>>> Just to clarify my not agreeing with Mark regarding EH on ppc64.
> >>>>
> >>>> Last time I tried to fix ppc64 exceptions handling as generated by clang
> >>>> it turned out that simply using gnu ld from ports fixes the issue.
> >>>>
> >>>> For details see:
> >>>> https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html
> >>>
> >>> Unfortunately my experiments failed to confirm this. Repeating
> >>> them now under head -r324071 and ports -r450478 :
> >>>
> >>> # more exception_test.cpp
> >>> #include
> >>>
> >>> int main(void)
> >>> {
> >>> try { throw std::exception(); }
> >>> catch (std::exception& e) {}
> >>> return 0;
> >>> }
> >>>
> >>> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=c++14 -g -O2
> >>> exception_test.cpp
> >>>
> >>> # ./a.out
> >>> Segmentation fault (core dumped)
> >>>
> >>> # clang++ -B /usr/local/powerpc64-freebsd/bin -std=c++11 -g
> >>> exception_test.cpp
> >>>
> >>> # ./a.out
> >>> Segmentation fault (core dumped)
> >>
> >> # clang++ -v -B /usr/local/powerpc64-freebsd/bin -std=c++11 -g
> >> exception_test.cpp
> >> FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM
> >> 5.0.0svn)
> >> Target: powerpc64-unknown-freebsd12.0
> >> Thread model: posix
> >> InstalledDir: /usr/bin
> >> "/usr/bin/clang++" -cc1 -triple powerpc64-unknown-freebsd12.0 -emit-obj
> >> -mrelax-all -disable-free -main-file-name exception_test.cpp
> >> -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim
> >> -masm-verbose -mconstructor-aliases -target-cpu ppc64 -mfloat-abi hard -v
> >> -dwarf-column-info -debug-info-kind=standalone -dwarf-version=2
> >> -debugger-tuning=gdb -resource-dir /usr/lib/clang/5.0.0 -internal-isystem
> >> /usr/include/c++/v1 -std=c
Re: C++ in jemalloc
Just to clarify my not agreeing with Mark regarding EH on ppc64.
Last time I tried to fix ppc64 exceptions handling as generated by clang
it turned out that simply using gnu ld from ports fixes the issue.
For details see:
https://lists.freebsd.org/pipermail/freebsd-toolchain/2017-May/002961.html
Roman
On Fri, Oct 06, 2017 at 09:28:37AM -0700, Mark Millard wrote:
> On 2017-Oct-6, at 7:15 AM, Justin Hibbits wrote:
>
> > Hi Mark,
> >
> > On Thu, Oct 5, 2017 at 11:58 PM, Mark Millard <mar...@dsl-only.net> wrote:
> >> Warner Losh imp at bsdimp.com wrote on
> >> Thu Oct 5 21:01:26 UTC 2017 :
> >>
> >>> Starting in FreeBSD 11, arm and powerpc are supported by clang,
> >>> but not super well. For FreeBSD 12, we're getting close for everything
> >>> except sparc64 (whose fate has not yet been finally decided).
> >>
> >> My understanding of the powerpc and powerpc64 status
> >> follows. This is based on my use of head via clang
> >> as much as I can for them.
> >>
> >> For TARGET_ARCH=powerpc64 and TARGET_ARCH=powerpc :
> >>
> >> lld is far from working last I knew. (I've focused
> >> more on the compilers for testing, using other
> >> linkers and such.) [lldb may be in a similar state
> >> for powerpc64. It does not build for powerpc.]
> >>
> >> clang 5 (and 4) generated code crashes on any thrown
> >> C++ exception. For example:
> >>
> >> #include
> >>
> >> int main(void)
> >> {
> >>try { throw std::exception(); }
> >>catch (std::exception& e) {}
> >>return 0;
> >> }
> >>
> >> crashes.
> >>
> >> Luckily most kernel and world code that I actively use
> >> does not throw C++ exceptions in my use.
> >
> > Do you see this problem using libstdc++, et al, from base gcc 4.2.1?
> > Or using libc++?
>
> gcc 4.2.1 buildkernel buildworld work fine for anything that I've
> tried. They are libstdc++ based.
>
> I've not tried clang with libstdc++, just libc++. (Note: clang 3.8,
> 3.9, 4.0, and 5.0 all have had the problem. My llvm bug submittals
> tend to be from the earlier time frame. Many of my submittals for
> other types of issues have been addressed. )
>
> But my llvm bugzilla submittals for C++ exceptions indicate
> errors/incompletenesses in the DW_CFA_ generation, such as
> for scratch register handling. (Warning: I've not been through
> the details in some time so this is from a vague memory.) 26844
> and 26856 are the relevant ones if I remember right. 31590 might
> be relevant depending on what linunwind is to be used.
>
> Be warned that I do not believe Roman Divacky agrees with my
> interpretation and I'd never studied the exception handling
> techniques prior to these investigations. Still I think that
> I was correct about there being problems in the DW_CFA_
> sequences generated.
>
> For a separate issue llvm 31716 is relevant for .plt and the
> function descriptor layout. I use Roman Divacky's patch listing in
> Comment 1. Included below as well.
>
> The llvm patches that I have are both from Roman as I remember:
>
> Index: /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
> ===
> --- /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
> (revision 324071)
> +++ /usr/src/contrib/llvm/lib/Target/PowerPC/PPCFrameLowering.cpp
> (working copy)
> @@ -1178,7 +1178,7 @@
>// For SVR4, don't emit a move for the CR spill slot if we haven't
>// spilled CRs.
>if (isSVR4ABI && (PPC::CR2 <= Reg && Reg <= PPC::CR4)
> - && !MustSaveCR)
> + && (!MustSaveCR && isPPC64))
> continue;
>
>// For 64-bit SVR4 when we have spilled CRs, the spill location
> Index: /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp
> ===
> --- /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp (revision 324071)
> +++ /usr/src/contrib/llvm/tools/lld/ELF/Arch/PPC64.cpp (working copy)
> @@ -60,7 +60,8 @@
> static uint16_t applyPPCHighesta(uint64_t V) { return (V + 0x8000) >> 48; }
>
> PPC64::PPC64() {
> - PltRel = GotRel = R_PPC64_GLOB_DAT;
> + GotRel = R_PPC64_GLOB_DAT;
> + PltRel = R_PPC64_JMP_SLOT;
>RelativeRel = R_PPC64_RELATIVE;
>GotEntrySize = 8;
>GotPltEntrySize = 8;
>
>
>
> > I don't have the time right now to look into it, but if no one else is
> > able to in the nex
Re: HEADS UP: sparc64 backend for llvm/clang imported
On Wed, Aug 26, 2015 at 11:14:51PM +0200, Marius Strobl wrote: On Wed, Aug 19, 2015 at 04:19:03PM -0400, Kurt Lidl wrote: Dimitry Andric wrote this message on Fri, Feb 28, 2014 at 20:22 +0100: In r262613 I have merged the clang-sparc64 branch back to head. This imports an updated sparc64 backend for llvm and clang, allowing clang to bootstrap itself on sparc64, and to completely build world. To be able to build the GENERIC kernel, there is still one patch to be finalized, see below. If you have any sparc64 hardware, and are not afraid to encounter rough edges, please try out building and running your system with clang. To do so, update to at least r262613, and enable the following options in e.g. src.conf, or in your build environment: WITH_CLANG=y WITH_CLANG_IS_CC=y WITH_LIBCPLUSPLUS=y (optional) Alternatively, if you would rather keep gcc as /usr/bin/cc for the moment, build world using just WITH_CLANG, enabling clang to be built (by gcc) and installed. After installworld, you can then set CC=clang, CXX=clang++ and CPP=clang-cpp for building another world. For building the sparc64 kernel, there is one open issue left, which is that sys/sparc64/include/pcpu.h uses global register variables, and this is not supported by clang. A preliminary patch for this is attached, but it may or may not blow up your system, please beware! The patch changes the pcpu and curpcb global register variables into inline functions, similar to what is done on other architectures. However, the current approach is not optimal, and the emitted code is slightly different from what gcc outputs. Any improvements to this patch are greatly appreciated! Last but not least, thanks go out to Roman Divacky for his work with llvm/clang upstream in getting the sparc64 backend into shape. Ok, I have a new pcpu patch to try. I have only compile tested it. It is available here: https://www.funkthat.com/~jmg/sparc64.pcpu.patch I've also attached it. Craig, do you mind testing it? This patch also removes curpcb as it appears to not be used by any sparc64 C code. A GENERIC kernel compiles fine, and fxr only turns up curpcb used in machdep code, and no references to it under sparc64. This is not a proper solution in that it can mean counters/stats can be copied/moved to other cpus overwriting the previous values if a race happens... We use PCPU_SET(mem, PCPU_GET(mem) + val) for PCPU_ADD, not great, but it's no worse than what we were previously using.. Until we get a proper fix which involves mapping all the cpu's PCPU data on all CPUs, this will have to sufice.. This patch is based upon, I believe, a patch from Marius and possibly modified by rdivacky. Thanks for testing.. The above message was posted a while ago, and I decided that I would give the patch a test run on a spare sparc that I have, now that the instability problem with multiprocessor sparc64 machines has been resolved. So, I have an up-to-date stable/10 V240 (2x1.5Ghz cpus, 8GB of memory), running a completely stock r286861. That all seems to work just fine. I applied the patch referenced in the email: https://www.funkthat.com/~jmg/sparc64.pcpu.patch (it applied cleanly), and then rebuilt the kernel on the machine, using the stock gcc 4.2.1 compiler. When rebooting with that kernel, the machine panics pretty early in the boot: FreeBSD 10.2-STABLE #3 r286861M: Wed Aug 19 14:28:45 EDT 2015 l...@spork.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64 gcc version 4.2.1 20070831 patched [FreeBSD] real memory = 8589934592 (8192 MB) avail memory = 8379719680 (7991 MB) cpu0: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) cpu1: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs random device not loaded; using insecure entropy panic: trap: illegal instruction (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc05750e0 at panic+0x20 #1 0xc08db9f8 at trap+0x558 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... timeout shutting down CPUs. So, the patch to get rid of the pcpu usage (as a prereq to poking at the clang compiler issues) does not work properly. As I pointed out when that patch was posted, the approach taken by it assumes a CPU can access foreign PCPU data, which currently isn't true on sparc64. So the patch is at least incomplete but also may have further issues. Such a patch is no longer a prerequisite for compiling a sparc64 kernel with clang, though, as clang meanwhile has been told to grok at least the global registers used by the PCPU code. Besides some default options like the choice of code model not being appropriate for FreeBSD, clang-compiled loader and kernel don't
[PATCH]: further shrinking of boot2
Hi all! In an effort to help import clang3.5 I looked at squeezing a few more bytes from boot2. http://rys.vlakno.cz/~rdivacky/boot2.diet.patch Please test and review the patch. It survived my qemu boot attempt so it's not completely broken. But I would like to have some more testing and review comments before I move forward with this. Fwiw, it shrinks boot2 by 16 bytes when compiled with clang34 and by 28 bytes when compiled with clang35. Thanks! Roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH]: further shrinking of boot2
Sure thing. Reload the patch from the same url. http://rys.vlakno.cz/~rdivacky/boot2.diet.patch On Fri, Nov 21, 2014 at 10:16:58AM -0500, John Baldwin wrote: On Friday, November 21, 2014 01:56:32 PM Roman Divacky wrote: Hi all! In an effort to help import clang3.5 I looked at squeezing a few more bytes from boot2. http://rys.vlakno.cz/~rdivacky/boot2.diet.patch Please test and review the patch. It survived my qemu boot attempt so it's not completely broken. But I would like to have some more testing and review comments before I move forward with this. Fwiw, it shrinks boot2 by 16 bytes when compiled with clang34 and by 28 bytes when compiled with clang35. I would prefer 'int k' over 'int i2/j2'. Also, do you really have to move the variable definitions to get the size change? I'd prefer to leave the variable declarations where they are if possible (and just add 'int k' or 'size_t k' in the existing variable blocks). -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH]: further shrinking of boot2
On Fri, Nov 21, 2014 at 04:00:35PM -0500, John Baldwin wrote: On Friday, November 21, 2014 08:39:17 PM Roman Divacky wrote: Sure thing. Reload the patch from the same url. http://rys.vlakno.cz/~rdivacky/boot2.diet.patch Thanks. I haven't run tested it, but I'm ok with it otherwise. Thanks for the review. I'll wait a couple of days, hopefully someone will test the patch in a different way I did. Unless someone reports a breakage I'll commit this sometime next week. Thanks! Roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: GCC withdraw
On Sat, Aug 24, 2013 at 09:35:12AM +0800, Julian Elischer wrote: On 8/24/13 3:23 AM, Mark Felder wrote: On Fri, Aug 23, 2013, at 13:20, Julian Elischer wrote: On 8/23/13 7:55 PM, Poul-Henning Kamp wrote: In message 52174d51.2050...@digsys.bg, Daniel Kalchev writes: - 9.x gcc default and clang in base; - 10.x clang default and gcc in ports; I believe this is the best idea so far. As long as these ports work with gcc in ports, that is. +1 well as I was forced to go back to gcc to get a compiling running kernel on my VPS (xen) I'm not convinced that clang is there yet. I'd be really grumpy if I had to go through al the ports hoopla to recompile my kernel. Curious which Xen version. I'd like to try to replicate this issue. I've seen FreeBSD 10 run just fine on XenServer 6.0 and 6.2. I don't know.. whatever RootBSD run, but the fact that I needed gcc for anything suggests that we should keep it around for a while. Why do you need to use gcc for everything? What happens if you use clang? Be specific, without details this is just FUD. Roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Linux epoll(7) patch
On Mon, Aug 05, 2013 at 08:22:05AM -0700, Alfred Perlstein wrote: On 8/5/13 2:36 AM, Yuri wrote: There is the patch, suggested by Roman Divacky, implementing Linux epoll(7) functionality: http://rys.vlakno.cz/~rdivacky/patches/linux_epoll.patch This patch was suggested 5 years ago and was discussed on emulation@: http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004409.html http://lists.freebsd.org/pipermail/freebsd-emulation/2008-March/004428.html Discussion stalled back then, and epoll is still unimplemented. Anybody can identify any issues with this patch? Are there any alternatives? Yuri The patch is small. I too am wondering why it's not committed, was there any push back? iirc the main problem with the patch is that it doesnt work over fork, I never got to implement that feature. Nevertheless it looks like the patch is useful even without that feature so maybe it should just be commited? Roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: protoc crash in libstdc++
On Tue, Dec 18, 2012 at 01:21:42PM +0100, Ren? Ladan wrote: Hi, the following backtrace is from a crash that happened when building www/chromium with clang. The chromium port builds a binary protoc which crashes when built with clang. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 802006400 (LWP 100869)] 0x000800996506 in std::ostream::sentry::sentry(std::ostream) () from /usr/lib/libstdc++.so.6 (gdb) bt #0 0x000800996506 in std::ostream::sentry::sentry(std::ostream) () from /usr/lib/libstdc++.so.6 #1 0x0008009964cd in std::basic_ostreamchar::sentry::sentry (this=0x7fffcf88, __os=...) at /usr/include/c++/4.2/ostream:62 #2 0x000800998a4b in std::__ostream_insertchar, std::char_traitschar (__out=..., __s=0x485df0 Missing input file., __n=19) at /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include/bits/ostream_insert.h:83 #3 0x0040592c in operatorstd::char_traitschar (this=optimized out, __out=..., __out=..., __s=optimized out) at /usr/include/c++/4.2/ostream:517 #4 google::protobuf::compiler::CommandLineInterface::ParseArguments (this=optimized out, argc=1, argv=0x7fffd640) at third_party/protobuf/src/google/protobuf/compiler/command_line_interface.cc:790 #5 0x004048b0 in google::protobuf::compiler::CommandLineInterface::Run (this=0x7fffd4d0, argc=-12408, argv=0x7fffcf88) at third_party/protobuf/src/google/protobuf/compiler/command_line_interface.cc:588 #6 0x00432957 in main (argc=-12408, argv=0x7fffcf88) at ^^ wow :) Can you run this under valgrind? Roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on amd64/amd64
The XNB_ASSERT is defined as a statement expression, but it's result is
not used anywhere (not in a single place).
Ken, can this be just rewritten as do { ... } while(0) ? Or is there a special
reason why it is a statement expression?
Roman
On Sat, Nov 10, 2012 at 05:49:35PM +, FreeBSD Tinderbox wrote:
TB --- 2012-11-10 11:20:00 - tinderbox 2.9 running on
freebsd-current.sentex.ca
TB --- 2012-11-10 11:20:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE
FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012
d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64
TB --- 2012-11-10 11:20:00 - starting HEAD tinderbox run for amd64/amd64
TB --- 2012-11-10 11:20:00 - cleaning the object tree
TB --- 2012-11-10 11:27:18 - checking out /src from
svn://svn.freebsd.org/base/head
TB --- 2012-11-10 11:27:18 - cd /tinderbox/HEAD/amd64/amd64
TB --- 2012-11-10 11:27:18 - /usr/local/bin/svn cleanup /src
TB --- 2012-11-10 11:27:59 - /usr/local/bin/svn update /src
TB --- 2012-11-10 11:28:05 - At svn revision 242854
TB --- 2012-11-10 11:28:06 - building world
TB --- 2012-11-10 11:28:06 - CROSS_BUILD_TESTING=YES
TB --- 2012-11-10 11:28:06 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-11-10 11:28:06 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-11-10 11:28:06 - SRCCONF=/dev/null
TB --- 2012-11-10 11:28:06 - TARGET=amd64
TB --- 2012-11-10 11:28:06 - TARGET_ARCH=amd64
TB --- 2012-11-10 11:28:06 - TZ=UTC
TB --- 2012-11-10 11:28:06 - __MAKE_CONF=/dev/null
TB --- 2012-11-10 11:28:06 - cd /src
TB --- 2012-11-10 11:28:06 - /usr/bin/make -B buildworld
Building an up-to-date make(1)
World build started on Sat Nov 10 11:28:13 UTC 2012
Rebuilding the temporary build tree
stage 1.1: legacy release compatibility shims
stage 1.2: bootstrap tools
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3: cross tools
stage 4.1: building includes
stage 4.2: building libraries
stage 4.3: make dependencies
stage 4.4: building everything
stage 5.1: building 32 bit shim libraries
World build completed on Sat Nov 10 15:03:20 UTC 2012
TB --- 2012-11-10 15:03:20 - generating LINT kernel config
TB --- 2012-11-10 15:03:20 - cd /src/sys/amd64/conf
TB --- 2012-11-10 15:03:20 - /usr/bin/make -B LINT
TB --- 2012-11-10 15:03:20 - cd /src/sys/amd64/conf
TB --- 2012-11-10 15:03:20 - /usr/sbin/config -m LINT
TB --- 2012-11-10 15:03:20 - building LINT kernel
TB --- 2012-11-10 15:03:20 - CROSS_BUILD_TESTING=YES
TB --- 2012-11-10 15:03:20 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-11-10 15:03:20 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-11-10 15:03:20 - SRCCONF=/dev/null
TB --- 2012-11-10 15:03:20 - TARGET=amd64
TB --- 2012-11-10 15:03:20 - TARGET_ARCH=amd64
TB --- 2012-11-10 15:03:20 - TZ=UTC
TB --- 2012-11-10 15:03:20 - __MAKE_CONF=/dev/null
TB --- 2012-11-10 15:03:20 - cd /src
TB --- 2012-11-10 15:03:20 - /usr/bin/make -B buildkernel KERNCONF=LINT
Kernel build for LINT started on Sat Nov 10 15:03:20 UTC 2012
stage 1: configuring the kernel
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3.1: making dependencies
stage 3.2: building everything
Kernel build for LINT completed on Sat Nov 10 15:33:26 UTC 2012
TB --- 2012-11-10 15:33:26 - cd /src/sys/amd64/conf
TB --- 2012-11-10 15:33:26 - /usr/sbin/config -m LINT-NOINET
TB --- 2012-11-10 15:33:26 - building LINT-NOINET kernel
TB --- 2012-11-10 15:33:26 - CROSS_BUILD_TESTING=YES
TB --- 2012-11-10 15:33:26 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-11-10 15:33:26 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-11-10 15:33:26 - SRCCONF=/dev/null
TB --- 2012-11-10 15:33:26 - TARGET=amd64
TB --- 2012-11-10 15:33:26 - TARGET_ARCH=amd64
TB --- 2012-11-10 15:33:26 - TZ=UTC
TB --- 2012-11-10 15:33:26 - __MAKE_CONF=/dev/null
TB --- 2012-11-10 15:33:26 - cd /src
TB --- 2012-11-10 15:33:26 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET
Kernel build for LINT-NOINET started on Sat Nov 10 15:33:26 UTC 2012
stage 1: configuring the kernel
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3.1: making dependencies
stage 3.2: building everything
Kernel build for LINT-NOINET completed on Sat Nov 10 15:58:49 UTC 2012
TB --- 2012-11-10 15:58:49 - cd /src/sys/amd64/conf
TB --- 2012-11-10 15:58:49 - /usr/sbin/config -m LINT-NOINET6
TB --- 2012-11-10 15:58:49 - building LINT-NOINET6 kernel
TB --- 2012-11-10 15:58:49 - CROSS_BUILD_TESTING=YES
TB --- 2012-11-10 15:58:49 - MAKEOBJDIRPREFIX=/obj
TB --- 2012-11-10 15:58:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2012-11-10 15:58:49 - SRCCONF=/dev/null
TB --- 2012-11-10 15:58:49 - TARGET=amd64
TB --- 2012-11-10 15:58:49 - TARGET_ARCH=amd64
TB --- 2012-11-10 15:58:49 - TZ=UTC
TB --- 2012-11-10 15:58:49 - __MAKE_CONF=/dev/null
TB --- 2012-11-10 15:58:49 - cd /src
TB --- 2012-11-10
Re: clang and static linking?
On Fri, Nov 09, 2012 at 02:00:12PM +0200, Konstantin Belousov wrote:
On Thu, Nov 08, 2012 at 03:49:32PM -0800, Steve Kargl wrote:
On Thu, Nov 08, 2012 at 03:13:49PM -0800, Steve Kargl wrote:
Upgraded my amd64 system, yesterday. Needed to rebuild one
of my projects, and hit
/usr/local/openmpi-1.6.3/bin/mpif90 -static -O2 -pipe -march=native
-mtune=native -funroll-loops -ftree-vectorize -Wall -rpath
/usr/local/lib/gcc46 -I/home/kargl/modules -o sasmp sasmp.f90
-L/home/kargl/lib -L. -L/usr/local/lib -L. -loa -lm90 -llapack -lblas
//usr/lib/libc.a(isnan.o): In function `isnanf':
/usr/src/lib/libc/gen/isnan.c:(.text+0x40): multiple definition of
`__isnanf'
//usr/lib/libm.a(s_isnan.o):/usr/src/lib/msun/src/s_isnan.c:(.text+0x0):
first defined here
collect2: ld returned 1 exit status
*** [sasmp] Error code 1
Stop in /usr/home/kargl/trunk/oa.
Can't rebuild gcc46 due to clang issue.
Rebuilding openmpi does not help as openmpi uses gfortran46.
Maybe there's a library problem.
Error clangbase/gcc
yeslibc,libm
yeslibm libc
no libc libm
no libc,libm
libm.a compiled with clang
% nm /usr/lib/libm.a | grep isnan
U __isnanl
U __isnanf
U __isnanl
U isnan
U __isnanf
U isnan
U isnanf
s_isnan.o:
T __isnanf
0030 T __isnanl
W isnanf
U isnan
libm.a compiled with /usr/lib/gcc
troutmask:fvwm:kargl[232] nm /usr/lib/libm.a | grep isnan
U __isnanl
U __isnanf
U __isnanl
U __isnanf
s_isnan.o:
T __isnanf
0030 T __isnanl
W isnanf
This appears to fix the problem. Don't know if this is
th right way to handle it.
Index: src/s_isnan.c
===
--- src/s_isnan.c (revision 242701)
+++ src/s_isnan.c (working copy)
@@ -40,7 +40,6 @@
u.d = d;
return (u.bits.exp == 2047 (u.bits.manl != 0 || u.bits.manh != 0));
}
-#endif
int
__isnanf(float f)
@@ -51,6 +50,9 @@
return (u.bits.exp == 255 u.bits.man != 0);
}
+__weak_reference(__isnanf, isnanf);
+#endif
+
int
__isnanl(long double e)
{
@@ -60,5 +62,3 @@
mask_nbit_l(u);
return (u.bits.exp == 32767 (u.bits.manl != 0 || u.bits.manh != 0));
}
-
-__weak_reference(__isnanf, isnanf);
Is this patch against src/msun ?
This is only a workaround, which break ABI and older binaries.
The bug is apparently in clang, which inserts the undef reference
into the resulting object file, when weak alias references undefined
symbol. Gnu as does not have the bug.
There is some magic switch to reduce amount of clang bugs, like
-fno-integrated-as. Please try to compile the problematic .o with the
switch.
This is what I am seeing here:
pes msun$ touch src/s_isnan.c
pes msun$ make
Warning: Object directory not changed from original
/usr/home/rdivacky/freebsd-head/lib/msun
clang -O2 -pipe -I/usr/home/rdivacky/freebsd-head/lib/msun/ld80
-I/usr/home/rdivacky/freebsd-head/lib/msun/src
-I/usr/home/rdivacky/freebsd-head/lib/msun/../libc/include
-I/usr/home/rdivacky/freebsd-head/lib/msun/../libc/amd64 -std=gnu99
-Wsystem-headers -Wno-pointer-sign -c
/usr/home/rdivacky/freebsd-head/lib/msun/src/s_isnan.c
building static m library
ranlib libm.a
clang -pg -O2 -pipe -I/usr/home/rdivacky/freebsd-head/lib/msun/ld80
-I/usr/home/rdivacky/freebsd-head/lib/msun/src
-I/usr/home/rdivacky/freebsd-head/lib/msun/../libc/include
-I/usr/home/rdivacky/freebsd-head/lib/msun/../libc/amd64 -std=gnu99
-Wsystem-headers -Wno-pointer-sign -c
/usr/home/rdivacky/freebsd-head/lib/msun/src/s_isnan.c -o s_isnan.po
building profiled m library
ranlib libm_p.a
clang -fpic -DPIC -O2 -pipe -I/usr/home/rdivacky/freebsd-head/lib/msun/ld80
-I/usr/home/rdivacky/freebsd-head/lib/msun/src
-I/usr/home/rdivacky/freebsd-head/lib/msun/../libc/include
-I/usr/home/rdivacky/freebsd-head/lib/msun/../libc/amd64 -std=gnu99
-Wsystem-headers -Wno-pointer-sign -c
/usr/home/rdivacky/freebsd-head/lib/msun/src/s_isnan.c -o s_isnan.So
building shared library libm.so.5
pes msun$ nm s_isnan.o
T __isnanf
0030 T __isnanl
W isnanf
pes msun$
ie. no U for isnan. This is with todays clang not the one in base. So either
this bug is already gone in clang trunk (and will get fixed when we import
new clang). Or something else is going on...
Roman
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
Re: clang and static linking?
On Fri, Nov 09, 2012 at 08:43:04AM -0800, Steve Kargl wrote: On Fri, Nov 09, 2012 at 02:00:12PM +0200, Konstantin Belousov wrote: On Thu, Nov 08, 2012 at 03:49:32PM -0800, Steve Kargl wrote: This appears to fix the problem. Don't know if this is th right way to handle it. Index: src/s_isnan.c === --- src/s_isnan.c (revision 242701) +++ src/s_isnan.c (working copy) @@ -40,7 +40,6 @@ Is this patch against src/msun ? Yes. This is only a workaround, which break ABI and older binaries. Which leads to an interest question. With the major upheavel of switching to clang, are there any ABI breaking changes that would be desirable to commit? This would entail a major library version bump. For starters, libc/gen/isnan.c could be removed. The bug is apparently in clang, which inserts the undef reference into the resulting object file, when weak alias references undefined symbol. Gnu as does not have the bug. There is some magic switch to reduce amount of clang bugs, like -fno-integrated-as. Please try to compile the problematic .o with the switch. I'll try this shortly. Does this mean that we need to build all *.a libraries where a weak reference may occur with this switch? No, this has nothing to do with llvm integrated asm. So far it looks like gcc always inline isnan even at O0 while clang does not. We are trying to figure out the solution. Maybe use __builtin_isnan instead of isnan in the isnan macro expansion? Roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: November 5th is Clang-Day
Nice :)
Does this deserve mentioning in UPDATING and/or version bump?
On Thu, Nov 01, 2012 at 10:29:45PM -0500, Brooks Davis wrote:
On Monday, November 5th I plan to commit the following patch to make
clang the default compiler on i386 and amd64. Many people have worked
long and hard to make this a reality and we're finally close enough to
throw the switch. For many users the transition should be transparent.
Others will likely hit some bumps, but I think we've addresses most
major issues at this point and the LLVM community has demonstrated it's
ability and willingness to help given actionable bug reports.
Known Issues
- Not all ports compile with clang. This can be worked around in
individual ports by setting USE_GCC=any which will cause the base gcc
to be used. Depending how things shake out we may end up making
USE_GCC=any the default for a period. [0]
- Not all libm tests pass. More work by subject matter experts is
required to create tests cases for LLVM developers. Most problems are
not expected to be major in practice given that LLVM is being used for
scientific computing in a number of products including Cray's FORTRAN
compiler, most OpenCL compilers, and the Julia language.
- Small but noticeable slowdown in some benchmarks. For example
sysbench against mysql was found to run about 1% slower on top of a
clang compiled world+kernel. http://people.freebsd.org/~flo/perf.pdf
Known Non-Issues
- make buildenv works fine with clang.
-- Brooks
[0] Work is underway to switch to building ports with a ports specific
compiler version. Likely this will be gcc-4.6 initially. This would
help insulate ports from the base compiler. That being said, there are
significant advantages to getting as many ports as possible to build
with clang. Among other things, cross building for embedded systems is
much easier with clang.
Index: share/mk/bsd.own.mk
===
--- share/mk/bsd.own.mk (revision 242464)
+++ share/mk/bsd.own.mk (working copy)
@@ -426,7 +426,6 @@
BIND_XML \
BSDCONFIG \
CLANG_EXTRAS \
-CLANG_IS_CC \
CTF \
HESIOD \
ICONV \
@@ -455,6 +454,12 @@
.else
__DEFAULT_NO_OPTIONS+=CLANG
.endif
+# Clang the default system compiler only on x86.
+.if ${__T} == amd64 || ${__T} == i386
+__DEFAULT_YES_OPTIONS+=CLANG_IS_CC
+.else
+__DEFAULT_NO_OPTIONS+=CLANG_IS_CC
+.endif
# FDT is needed only for arm, mips and powerpc
.if ${__T:Marm*} || ${__T:Mpowerpc*} || ${__T:Mmips*}
__DEFAULT_YES_OPTIONS+=FDT
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] FYI: patch to ports that do not build with clang has been committed
Can we arrange exp builds with FORCE_BASE_CC_FOR_TESTING=clang that will report all ports with USE_GCC=* but build with clang? Lets say every three months or so? On Tue, Oct 09, 2012 at 07:45:23PM -0500, Mark Linimon wrote: The commit mail hasn't gone through yet, so I guess I need to post this first and reference the commit mail later. Sometime in the near future, the default CC on -current will be switched to clang. The patch I have committed is a workaround -- an interim measure -- to get ready for this transition. I have made changes to ports/Mk/bsd.gcc.mk that allow the addition of USE_GCC=any to a port's Makefile, and then committed that change to various ports. In most (but not all!) cases this will tell the port build with gcc instead of clang (*) . For those users with CC installed as gcc (including -stable), this patch should have no effect. Variations of combinations have been heavily tested on pointyhat-west. If there are any regressions, please contact me. You can see the difference in the errorlogs here: With USE_GCC=any: http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp-clang.20121007231359.pointyhat-west/index-category.html Without USE_GCC=any: http://pointyhat-west.isc.freebsd.org/errorlogs/amd64-errorlogs/e.9-exp-clang.20121005165436.pointyhat-west/index-category.html While the absolute number of errors is not that much different, that is a false indication: over 2500 more packages are built with than without. For those who wish to build *only* with clang, and thus defeat the workaround, simply set FORCE_BASE_CC_FOR_TESTING=anything, either in the Makefile line, or, if you are adventurous, in your /etc/make.conf. We appreciate all the testing that we can get (it is too much for any small group of people, much less one person.) In the long run, I would like to see as many ports built natively with clang as possible, and I appreciate the work that people have been doing to move us towards that goal. However, once the switch is made, it would have been a burden to everyone tracking -current to have suddenly found themselves enlisted in that effort :-) So, for the medium-term, this workaround should reduce the POLA violation. *Note* that due to the high number (over a thousand!) ports that do not build with clang, I arbitrarily decided to apply the workaround only to ports that block 2 or more other ports from building union important ports. This does not mean that the workaround shouldn't be applied to other ports that are too hard to fix. This is part 1 of a set of patches that are being proposed to deal with the switchover. As I merge and test them some more, I will put them out for further review. Thanks. mcl * several ports are very, very, clever, and detect clang anyways; others build with gcc if CC is unset, but don't with CC=gcc. These ports are broken, and need to be fixed as we continue the process of switching over. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
Fwiw, I commited the dont use long nops on amd geode thing into llvm a few minutes ago. So this issue doesnt exist anymore. On Wed, Sep 12, 2012 at 07:19:07PM +0400, Lev Serebryakov wrote: Hello, Patrick. You wrote 12 2012 ?., 1:22:44: PL Well, I will not be able to run FreeBSD from scratch on my soekris :-) Thank you for warning, I've missed this. -- // Black Lion AKA Lev Serebryakov l...@freebsd.org ___ freebsd-toolch...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to freebsd-toolchain-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
LLVM by default turns these: case LibFunc::copysign: case LibFunc::copysignf: case LibFunc::copysignl: case LibFunc::fabs: case LibFunc::fabsf: case LibFunc::fabsl: case LibFunc::sin: case LibFunc::sinf: case LibFunc::sinl: case LibFunc::cos: case LibFunc::cosf: case LibFunc::cosl: case LibFunc::sqrt: case LibFunc::sqrtf: case LibFunc::sqrtl: case LibFunc::floor: case LibFunc::floorf: case LibFunc::floorl: case LibFunc::nearbyint: case LibFunc::nearbyintf: case LibFunc::nearbyintl: case LibFunc::ceil: case LibFunc::ceilf: case LibFunc::ceill: case LibFunc::rint: case LibFunc::rintf: case LibFunc::rintl: case LibFunc::trunc: case LibFunc::truncf: case LibFunc::truncl: case LibFunc::log2: case LibFunc::log2f: case LibFunc::log2l: case LibFunc::exp2: case LibFunc::exp2f: case LibFunc::exp2l: from lib calls to direct code (ie. instruction or sequence of). This is not a bug but feature ;) I am not sure what the rules for the transformation should be. Allow it only with -ffast-math ? Disallow it on i386? Really, no idea. Steve, you tested on i386? Can you test on amd64? Do you guys have any opinion what to do here? On Fri, Sep 14, 2012 at 06:06:00PM -0700, Steve Kargl wrote: On Fri, Sep 14, 2012 at 05:18:08PM -0700, Steve Kargl wrote: A third class of failure appears to be that clang emits i387 fpu instructions for at least sinf and cosf instead of calls to the library routines. AFAIK, the library routines are faster and more accurate. Yep. Clang has problems with at least sinf on i386 FreeBSD. % pwd /usr/home/kargl/trunk/math/sine % make clean make CC=cc testf cc -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \ -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm % ./testf -m 0 -M 1e20 -r ULP Range | ---+- [0.0:0.6] | 1006424(100.00%) (0.6:0.7] | 0 ( 0.00%) (0.7:0.8] | 0 ( 0.00%) (0.8:0.9] | 0 ( 0.00%) (0.9:1.0] | 0 ( 0.00%) (1.0:2.0] | 0 ( 0.00%) (2.0:3.0] | 0 ( 0.00%) 3.0 ULP | 0 ( 0.00%) ---+- Count | 1006424 Max ULP | 0.50084 Max ULP x | 53462490661259313152.00 0x1.72f876p+65 % make clean make CC=clang testf clang -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \ -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm % ./testf -m 0 -M 1e20 -r ULP Range | ---+- [0.0:0.6] | 1 ( 0.00%) (0.6:0.7] | 0 ( 0.00%) (0.7:0.8] | 0 ( 0.00%) (0.8:0.9] | 0 ( 0.00%) (0.9:1.0] | 0 ( 0.00%) (1.0:2.0] | 0 ( 0.00%) (2.0:3.0] | 0 ( 0.00%) 3.0 ULP | 98 (100.00%) ---+- Count | 99 Max ULP | 1328505256679420125050194353979392.0 Max ULP x | 75516780764213542912.00 0x1.06006p+66 -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
Fwiw, this seems to have been fixed as of a few minutes ago. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120910/150720.html Steve, can you please test llvm/clang from (their) svn and report back? We can import a newer snapshot if all is ok. Thank you. On Fri, Sep 14, 2012 at 06:06:00PM -0700, Steve Kargl wrote: On Fri, Sep 14, 2012 at 05:18:08PM -0700, Steve Kargl wrote: A third class of failure appears to be that clang emits i387 fpu instructions for at least sinf and cosf instead of calls to the library routines. AFAIK, the library routines are faster and more accurate. Yep. Clang has problems with at least sinf on i386 FreeBSD. % pwd /usr/home/kargl/trunk/math/sine % make clean make CC=cc testf cc -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \ -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm % ./testf -m 0 -M 1e20 -r ULP Range | ---+- [0.0:0.6] | 1006424(100.00%) (0.6:0.7] | 0 ( 0.00%) (0.7:0.8] | 0 ( 0.00%) (0.8:0.9] | 0 ( 0.00%) (0.9:1.0] | 0 ( 0.00%) (1.0:2.0] | 0 ( 0.00%) (2.0:3.0] | 0 ( 0.00%) 3.0 ULP | 0 ( 0.00%) ---+- Count | 1006424 Max ULP | 0.50084 Max ULP x | 53462490661259313152.00 0x1.72f876p+65 % make clean make CC=clang testf clang -o testf -O2 -pipe -static -I/usr/local/include -I../mp testf.c \ -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp -lm % ./testf -m 0 -M 1e20 -r ULP Range | ---+- [0.0:0.6] | 1 ( 0.00%) (0.6:0.7] | 0 ( 0.00%) (0.7:0.8] | 0 ( 0.00%) (0.8:0.9] | 0 ( 0.00%) (0.9:1.0] | 0 ( 0.00%) (1.0:2.0] | 0 ( 0.00%) (2.0:3.0] | 0 ( 0.00%) 3.0 ULP | 98 (100.00%) ---+- Count | 99 Max ULP | 1328505256679420125050194353979392.0 Max ULP x | 75516780764213542912.00 0x1.06006p+66 -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
Is this correct?
lev ~$ ./cos 1.23456789e20
6.031937e-01
-9.629173e-02
2.814722e-01
If so I believe the issue is fixed.
On Sat, Sep 15, 2012 at 03:48:38PM +0200, Tijl Coosemans wrote:
On 15-09-2012 14:48, Roman Divacky wrote:
Fwiw, this seems to have been fixed as of a few minutes ago.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120910/150720.html
Steve, can you please test llvm/clang from (their) svn and report
back? We can import a newer snapshot if all is ok.
Here's a small test program. You're probably better equipped to test
clang svn.
#include math.h
#include stdio.h
#include stdlib.h
int
main( int argc, char **argv ) {
double d = strtod( argv[ 1 ], NULL );
printf( %e\n, ( double ) cos( d ));
printf( %e\n, ( double ) cosf( d ));
printf( %e\n, ( double ) cosl( d ));
return( 0 );
}
This is the current output of clang:
% clang -o cos cos.c -lm
% ./cos 1.23456789e20
6.031937e-01
1.234568e+20
2.814722e-01
The second number (cosf) is wrong. It should be a value between -1 and 1.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
Fwiw, I plan to fix this issue, but even if I didnt. This isnt a problem in clang rather than in llvm asm. So it can be easily worked around by CFLAGS+=-no-integrated-as. Roman On Tue, Sep 11, 2012 at 11:22:44PM +0200, Patrick Lamaiziere wrote: Le Mon, 10 Sep 2012 16:12:07 -0500, Brooks Davis bro...@freebsd.org a ?crit : Hello, For the past several years we've been working towards migrating from GCC to Clang/LLVM as our default compiler. We intend to ship FreeBSD 10.0 with Clang as the default compiler on i386 and amd64 platforms. To this end, we will make WITH_CLANG_IS_CC the default on i386 and amd64 platforms on November 4th. Last time I've checked on 9.X [mid August, FreeBSD clang version 3.1 (branches/release_31 156863) 20120523], Clang still produces invalid code (some nopl (%eax)) for the AMD Geode LX (i586 CPU found on some ALIX board or Soekris NET5501). I don't know if this is also a concern with older CPU (Pentium 2/1) ? http://llvm.org/bugs/show_bug.cgi?id=11212 http://lists.freebsd.org/pipermail/freebsd-current/2011-October/028588.html http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/168253 What does the mean to you? Well, I will not be able to run FreeBSD from scratch on my soekris :-) Best regards. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
tl;dr: Clang will become the default compiler for x86 architectures on 2012-11-04 There was a chorus of voices talking about ports already. My POV is that suggesting to 'fix remaining ports to work with clang' is just a nonsense. You are proposing to fork the development of all the programs which do not compile with clang. Often, upstream developers do not care about clang at all since it not being default compiler in Debian/Fedora/Whatever Linux. The project simply do not have resources to maintain the fork of 20K programs. We currently dont compile 4680 ports (out of 23857). Top 10 ports that prevent the most other ports from compiling together prevent ports from compilation. So if we fixed those 10 ports we could be at around 2500 ports not compiling. Thats quite far from your claim of forking 20k programs. Looking from less amiable angle, you propose to knowingly break significant and important piece of the project work. My belief is that switch cannot be done before ports switch to the port-provided compiler. I believe majority of the broken ports is broken because their maintainer never saw them being broken with clang just because it's not the default compiler. Thus by making it the default majority of the problems would just go away. Note that the work needed to make ports compiling with clang is largely shared with the work to make them compiliable with newer GCCs (as they are stricter etc.) Another issue with the switch, which seems to be not only not addressed, but even not talked about, is the performance impact of the change. I do not remember any measurements, whatever silly they could be, of the performance change by the compiler switch. We often have serious and argumented push-back for kernel changes that give as low as 2-3% of the speed hit. What are the numbers for clang change, any numbers ? Agreed. We should provide numbers. At least how buildworld times change with clang compiled kernel/workd and gcc compiler kernel/world. And, some small but annoying things left with clang, like ABI change requiring 16-byte stack alignment on i386, but lets ignore this until two big issues are resolved. Thank you for pointing this out. This is, in my opinion, one of the strongest reasons to switch to clang. We can go, fix issues or report we find upstream and then import newer clang. Unlike with gcc. Thank you, Roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Tue, Sep 11, 2012 at 03:21:22PM +0300, Konstantin Belousov wrote: On Tue, Sep 11, 2012 at 02:06:49PM +0200, Roman Divacky wrote: tl;dr: Clang will become the default compiler for x86 architectures on 2012-11-04 There was a chorus of voices talking about ports already. My POV is that suggesting to 'fix remaining ports to work with clang' is just a nonsense. You are proposing to fork the development of all the programs which do not compile with clang. Often, upstream developers do not care about clang at all since it not being default compiler in Debian/Fedora/Whatever Linux. The project simply do not have resources to maintain the fork of 20K programs. We currently dont compile 4680 ports (out of 23857). Top 10 ports that prevent the most other ports from compiling together prevent ports from compilation. So if we fixed those 10 ports we could be at around 2500 ports not compiling. Thats quite far from your claim of forking 20k programs. Sorry, I cannot buy the argument. How many patches there are already in the ports tree to cope with clang incompatibility with gcc ? You may declare that all of them are application bugs, but it completely misses the point. Looking from less amiable angle, you propose to knowingly break significant and important piece of the project work. My belief is that switch cannot be done before ports switch to the port-provided compiler. I believe majority of the broken ports is broken because their maintainer never saw them being broken with clang just because it's not the default compiler. Thus by making it the default majority of the problems would just go away. Can you, please, read what I wrote ? Fixing _ports_ to compile with clang is plain wrong. Upstream developers use gcc almost always for development and testing. Establishing another constant cost on the porting work puts burden on the ports submitters, maintainers and even ports users. Upstream developers almost never use gcc4.2.1 as we do. So right now the ports maintainer must check whats wrong in the case the (upgraded) port doesnt compile with our in-tree gcc. It can be trivial USE_GCC=4.something but the burden is exactly the same as with clang. I do strongly oppose the attempt to drain the freebsd resources by forcing porters to port third-party code to other compiler. We dont force anyone. Any port maintainer can decide to USE_GCC=4.2. We are not advocating removing gcc but making clang default. The possibility of fallback to gcc is still there. And, some small but annoying things left with clang, like ABI change requiring 16-byte stack alignment on i386, but lets ignore this until two big issues are resolved. Thank you for pointing this out. This is, in my opinion, one of the strongest reasons to switch to clang. We can go, fix issues or report we find upstream and then import newer clang. Unlike with gcc. We do not want to hunt for the compiler bugs at all, goal of FreeBSD is to develop the OS and not a compiler. By the nature of developing the OS we are forced to use compilers and toolchains. Recently I saw you submitting/committing patches with .byte sequences because our default assembler cant handle the instructions. I saw jhb@ updating binutils to support invept/invvpid. In my eyes, switching to clang by default lowers the compiler/toolchain maintenance burden we have. Thank you, Roman. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Tue, Sep 11, 2012 at 08:12:30AM -0700, Steve Kargl wrote: On Tue, Sep 11, 2012 at 04:27:55PM +0200, Tijl Coosemans wrote: On 11-09-2012 16:10, Dimitry Andric wrote: On 2012-09-11 15:24, Steve Kargl wrote: What is important is whether software built with clang functions correctly. See for example, http://math-atlas.sourceforge.net/errata.html#WhatComp Yes, maths support, specifically precision, is admittedly still one of clang's (really llvm's) weaker points. It is currently not really a high priority item for upstream. This is obviously something that a certain part of our userbase will care a lot about, while most of the time they won't care so much about licensing or politics. So those people are probably better off using gcc for the time being. Does it affect the accuracy of libm functions? I'm not sure if anyone has done any extensive testing. I've started to run some of my test codes to compare certain functions in a clang-compiled libm, gcc-compiled libm, and reference solutions generated from math/mpfr. For a locally patched j0f, I found that clang gave much worse accuracy. If I revert the local patch, clang and gcc are to give the same results. Unfortnately, an unpatched j0f gives 50 ULP errors. Steve, Can you please provide a small self contained test case that shows that clang is doing worse on accuracy than gcc? So that we can analyze it and decide if it's a bug in the code or in the compiler. So far we know absolutely nothing. Thank you, Roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Compiler performance tests on FreeBSD 10.0-CURRENT
On Wed, Sep 05, 2012 at 03:13:11PM -0700, Steve Kargl wrote: On Wed, Sep 05, 2012 at 11:31:26AM +0200, Dimitry Andric wrote: On 2012-09-05 01:40, Garrett Cooper wrote: ... Steve does have a point. Posting the results of CFLAGS/CPPFLAGS/LDFLAGS/etc for config.log (and maybe poking through the code to figure out what *FLAGS were used elsewhere) is more valuable than the data is in its current state (unfortunately.. autoconf makes things more complicated). 1) For building the FreeBSD in-tree version of clang 3.2: -O2 -pipe -fno-strict-aliasing 2) For building the FreeBSD in-tree version of gcc 4.2.1: -O2 -pipe 3) For building Boost 1.50.0: -ftemplate-depth-128 -O3 -finline-functions Dimitry thanks for the follow-up. I performed an unscientific (micro)benchmark of /usr/bin/cc vs /usr/bin/clang where cc is the base system's gcc 4.2.1. Here's what I found/feared. Compiling libm on CPU: AMD Opteron(tm) Processor 248 (2192.01-MHz K8-class CPU) Origin = AuthenticAMD Id = 0xf5a Family = f Model = 5 Stepping = 10 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,\ MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 AMD Features=0xe0500800SYSCALL,NX,MMX+,LM,3DNow!+,3DNow! with default CFLAGS (ie., -O2 -pipe) and -march=opteron. Was this compiled as amd64 or i386? Also, can you send me the test case? So that we can explore the difference. The working theory now is SSE vs FPU mathematics, but it would be nice to see the testcase. Thank you, roman Using 'setenv CC /usr/bin/cc' with 3 runs of make clean time make -DNO_MAN yields 69.39 real52.00 user38.55 sys 69.57 real52.35 user38.37 sys 69.48 real52.25 user38.38 sys Now, repeating with 'setenv CC /usr/bin/clang' yields 39.65 real21.86 user17.37 sys 40.91 real21.48 user17.91 sys 39.77 real21.65 user17.64 sys So, clang does appear to be faster in this particular compiling speed benchmark. However, if I know build my test program for libm's j0f() function where the only difference is whether libm was built with /usr/bin/cc or /usr/bin/clang, I observe the following results. 1234567 x values in the interval [0:25] gcc libm| clang libm |- ULP = 0.6 -- 565515 (45.81%) | 513763 (41.61%) 0.6 ULP = 0.7 -- 74148 ( 6.01%) | 67221 ( 5.44%) 0.7 ULP = 0.8 -- 69112 ( 5.60%) | 62846 ( 5.09%) 0.8 ULP = 0.9 -- 63798 ( 5.17%) | 58217 ( 4.72%) 0.9 ULP = 1.0 -- 58679 ( 4.75%) | 53834 ( 4.36%) 1.0 ULP = 2.0 -- 328221 (26.59%) | 306728 (24.84%) 2.0 ULP = 3.0 -- 65323 ( 5.29%) | 63452 ( 5.14%) 3.0 ULP-- 9771 ( 0.79%) | 108506 ( 8.79%) gcc libm | clang libm ---| MAX ULP: 12152.27637| 1129606938624.0 x at MAX ULP: 5.520077 0x1.6148f2p+2 | 2.404833 0x1.33d19p+1 Speed test with gcc libm. 1234567 j0f calls in 0.193427 seconds. 1234567 j0f calls in 0.193410 seconds. 1234567 j0f calls in 0.194158 seconds. Speed test with clang libm. 1234567 j0f calls in 0.180260 seconds. 1234567 j0f calls in 0.180130 seconds. 1234567 j0f calls in 0.179739 seconds. So, although the clang built j0f() appears to be faster than the gcc built j0f(), the clang built j0f() has much worse accuracy issues. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Compiler performance tests on FreeBSD 10.0-CURRENT
What makes you think it's a bug in llvm code and not a plain gcc miscompile? Other people seem to compile llvm on PPC64 with gcc and -fstrict-aliasing just fine. They just dont happen to use gcc4.2.1. Ie. gcc47 is reported to not have this problem. I personally can confirm that fbsd+gcc48 is ok to On Wed, Sep 05, 2012 at 09:11:22AM -0400, Justin Hibbits wrote: On Wed, Sep 5, 2012 at 6:56 AM, Dimitry Andric dimi...@andric.com wrote: On 2012-09-05 11:36, David Chisnall wrote: On 5 Sep 2012, at 10:31, Dimitry Andric wrote: TThe -fno-strict-aliasing is not really my choice, but it was introduced in the past by Nathan Whitehorn, who apparently saw problems without it. It will hopefully disappear in the future. Clang currently defaults to no strict aliasing on FreeBSD. Yes, but upstream has never used -fno-strict-aliasing, just plain -O2. I run regular separate builds of pristine upstream clang on FreeBSD, and I haven't seen any failures due aliasing problems in all the regression tests. That doesn't guarantee there are no problems, of course... Aliasing problems are seen much more frequently on PowerPC than any other platform for Clang. I found this a while back when doing some Clang testing, and I still see problems with upstream unless I explicitly set -fno-strict-aliasing. Nathan had mentioned wanting to get upstream to use -fno-strict-aliasing by default on all platforms, but I don't think that ever made it beyond his suggesting. I filed this bug to track it: http://llvm.org/bugs/show_bug.cgi?id=11955 In my experience, most C programmers misunderstand the aliasing rules of C and even people on the C++ standards committee often get them wrong for C++, so trading a 1-10% performance increase for a significant chance of generating non-working code seems like a poor gain. If people are certain that they do understand the rules, then they can add -fstrict-aliasing to their own CFLAGS. I'm actually quite interested in the performance difference; I think I will run a few tests. :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Compiler performance tests on FreeBSD 10.0-CURRENT
I've been compiling clang with itself on PPC64 for a while now. Works quite good :) On Wed, Sep 05, 2012 at 01:44:00PM -0400, Justin Hibbits wrote: Actually, Nathan does say it's gcc's fault in a comment on that bug. However, I do all my clang work compiling it with gcc4.2.1, so run into this constantly when I forget to add the flag. - Justin On Wed, Sep 5, 2012 at 1:37 PM, Roman Divacky rdiva...@freebsd.org wrote: What makes you think it's a bug in llvm code and not a plain gcc miscompile? Other people seem to compile llvm on PPC64 with gcc and -fstrict-aliasing just fine. They just dont happen to use gcc4.2.1. Ie. gcc47 is reported to not have this problem. I personally can confirm that fbsd+gcc48 is ok to On Wed, Sep 05, 2012 at 09:11:22AM -0400, Justin Hibbits wrote: On Wed, Sep 5, 2012 at 6:56 AM, Dimitry Andric dimi...@andric.com wrote: On 2012-09-05 11:36, David Chisnall wrote: On 5 Sep 2012, at 10:31, Dimitry Andric wrote: TThe -fno-strict-aliasing is not really my choice, but it was introduced in the past by Nathan Whitehorn, who apparently saw problems without it. It will hopefully disappear in the future. Clang currently defaults to no strict aliasing on FreeBSD. Yes, but upstream has never used -fno-strict-aliasing, just plain -O2. I run regular separate builds of pristine upstream clang on FreeBSD, and I haven't seen any failures due aliasing problems in all the regression tests. That doesn't guarantee there are no problems, of course... Aliasing problems are seen much more frequently on PowerPC than any other platform for Clang. I found this a while back when doing some Clang testing, and I still see problems with upstream unless I explicitly set -fno-strict-aliasing. Nathan had mentioned wanting to get upstream to use -fno-strict-aliasing by default on all platforms, but I don't think that ever made it beyond his suggesting. I filed this bug to track it: http://llvm.org/bugs/show_bug.cgi?id=11955 In my experience, most C programmers misunderstand the aliasing rules of C and even people on the C++ standards committee often get them wrong for C++, so trading a 1-10% performance increase for a significant chance of generating non-working code seems like a poor gain. If people are certain that they do understand the rules, then they can add -fstrict-aliasing to their own CFLAGS. I'm actually quite interested in the performance difference; I think I will run a few tests. :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Does anyone regularly build HEAD with clang?
Yes, we do have a buildbots, ie.: http://llvm-amd64.freebsd.your.org:8010/builders/freebsd-clang-amd64/ On Sun, Feb 12, 2012 at 09:42:47PM -0800, Jordan K. Hubbard wrote: I've noticed that it's been broken for about a week as a result of: --- /usr/src/lib/libc/../../include/rpc/rpcb_clnt.h.orig 2012-02-12 22:42:29.0 -0800 +++ /usr/src/lib/libc/../../include/rpc/rpcb_clnt.h 2012-02-12 22:41:27.0 -0800 @@ -66,7 +66,7 @@ const struct netconfig *, const struct netbuf *); extern bool_t rpcb_unset(const rpcprog_t, const rpcvers_t, const struct netconfig *); -extern rpcblist *rpcb_getmaps(const struct netconfig *, const char *); +extern struct rpcblist *rpcb_getmaps(const struct netconfig *, const char *); extern enum clnt_stat rpcb_rmtcall(const struct netconfig *, const char *, const rpcprog_t, const rpcvers_t, const rpcproc_t, Easy fix (I don't have a commit bit anymore or I'd just check it in), but it makes me wonder if anyone is building with clang on a regular basis or they'd have caught this one quickly. Thanks, - Jordan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: WITH_LIBCPLUSPLUS on FreeBSD 10.0-CURRENT/amd64 fails with CLANG:
what makes you think you're using clang? On Thu, Jan 05, 2012 at 11:20:34PM +0100, O. Hartmann wrote: When compiling most recent CURRENT on amd64 platform, using CLANG and enabled WITH_LIBCPLUSPLUS, I receive the follwing error since two days now. Build shown below was made avoiding -jX when doing buildworld. [SNIP] rpcgen -C -c /usr/src/lib/librpcsvc/../../include/rpcsvc/ypupdate_prot.x -o ypupdate_prot_xdr.c rm -f .depend CC='cc -m32 -march=native -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32' mkdep -f .depend -a-DYP -I/usr/obj/usr/src/lib32/usr/include/rpcsvc -std=gnu99 klm_prot_xdr.c mount_xdr.c nfs_prot_xdr.c nlm_prot_xdr.c rex_xdr.c rnusers_xdr.c rquota_xdr.c rstat_xdr.c rwall_xdr.c sm_inter_xdr.c spray_xdr.c yppasswd_xdr.c ypxfrd_xdr.c ypupdate_prot_xdr.c /usr/src/lib/librpcsvc/rnusers.c /usr/src/lib/librpcsvc/rstat.c /usr/src/lib/librpcsvc/rwall.c /usr/src/lib/librpcsvc/yp_passwd.c /usr/src/lib/librpcsvc/yp_update.c /usr/src/lib/librpcsvc/secretkey.c /usr/src/lib/librpcsvc/xcrypt.c === lib/libsbuf (depend) === lib/libtacplus (depend) === lib/libutil (depend) === lib/libypclnt (depend) === lib/libcxxrt (depend) === lib/libc++ (depend) rm -f .depend CC='cc -m32 -march=native -DCOMPAT_32BIT -isystem /usr/obj/usr/src/lib32/usr/include/ -L/usr/obj/usr/src/lib32/usr/lib32 -B/usr/obj/usr/src/lib32/usr/lib32' mkdep -f .depend -a -I/usr/src/lib/libc++/../../contrib/libc++/include -I/usr/src/lib/libc++/../../contrib/libcxxrt -DLIBCXXRT -std=c++0x /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp /usr/src/lib/libc++/../../contrib/libc++/src/bind.cpp /usr/src/lib/libc++/../../contrib/libc++/src/chrono.cpp /usr/src/lib/libc++/../../contrib/libc++/src/condition_variable.cpp /usr/src/lib/libc++/../../contrib/libc++/src/debug.cpp /usr/src/lib/libc++/../../contrib/libc++/src/exception.cpp /usr/src/lib/libc++/../../contrib/libc++/src/future.cpp /usr/src/lib/libc++/../../contrib/libc++/src/hash.cpp /usr/src/lib/libc++/../../contrib/libc++/src/ios.cpp /usr/src/lib/libc++/../../contrib/libc++/src/iostream.cpp /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp /usr/src/lib/libc++/../../contrib/libc++/src/memory.cpp /usr/src/lib/libc++/../../contrib/libc++/src/mutex.cpp /usr/src/lib/libc++/../../contrib/libc++/src/new.cpp /usr/src/lib/libc++/../../contrib/libc++/src/random.cpp /usr/src/lib/libc++/../../contrib/libc++/src/regex.cpp /usr/src/lib/libc++/../../contrib/libc++/src/stdexcept.cpp /usr/src/lib/libc++/../../contrib/libc++/src/string.cpp /usr/src/lib/libc++/../../contrib/libc++/src/strstream.cpp /usr/src/lib/libc++/../../contrib/libc++/src/system_error.cpp /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp /usr/src/lib/libc++/../../contrib/libc++/src/typeinfo.cpp /usr/src/lib/libc++/../../contrib/libc++/src/utility.cpp /usr/src/lib/libc++/../../contrib/libc++/src/valarray.cpp cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x mkdep: compile failed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports: clang: error: unsupported option '-dumpspecs'
-dumpspecs is a gcc internal thing that clang will never support (it doesnt use specs). It's wrong for ports to mess with the internals of the compiler and this should be fixed in a clean way. Ie. we have to replace the -dumpspec | grep something with a saner check. On Wed, Dec 14, 2011 at 08:07:43PM +0100, O. Hartmann wrote: Since a couple of days now I see this happen on FreeBSD 10.0-CURRENT/amd64 (CLANG) (most recent buildworld and potstree) and also on FreeBSD 9.0-RC[2|3]/amd64 (also CLANG built, most recent portstree): Building new INDEX files... DESCRIBE.7 INDEX-8 not provided by portsnap server; INDEX-7 not being generated. done. === Gathering distinfo list for installed ports === Starting check of installed ports for available updates clang: error: unsupported option '-dumpspecs' clang: error: no input files === All ports are up to date Regards, Oliver ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Buildworld broken with clang on current
this was broken by the xlocale import, David, can you fix this please? I guess that just removing the typedef from strcasecmp.c should do it On Mon, Nov 21, 2011 at 12:59:38PM -0800, Manfred Antar wrote: make buildworld is broken iif using clang on current i386 (libc)5027}make clang -O2 -pipe -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/i386 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/string/strcasecmp.c /usr/src/lib/libc/string/strcasecmp.c:45:23: error: redefinition of typedef 'u_char' is invalid in C [-Wtypedef-redefinition] typedef unsigned char u_char; ^ /usr/include/sys/types.h:50:23: note: previous definition is here typedef unsigned char u_char; ^ 1 error generated. *** Error code 1 Stop in /usr/src/lib/libc. || n...@pozo.com || || Ph. (415) 681-6235 || -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 9.0-RC1/FreeBSD 10.0-CURRENT (amd64, CLANG): in some clients hitting backspace or arrow keys results in crashing client
Can you run the crashing app under gdb and show me where it crashes? What is the cause of the crash? SIGILL or something like that? What instruction does it crash on? Thank you, roman On Sat, Nov 05, 2011 at 09:46:37AM +0100, O. Hartmann wrote: Operating systems in question: FreeBSD 9.0-RC1/amd64 and FreeBSD 10.0-CURRENT/amd64, both compiled with CLANG. It happens that when using clients with requester for pathnames (like evim, thunderbird, mozilla and others) that typing some attributes into the requester-inputline and then hitting backspace or the arrow keys for editing a possibly wrong entry, the client crashes. I realized that this very often occur with locales set to non C. Such a weird behaviour occured also on a Dell Latitude E6510 with FreeBSD 9.0-CURRENT earlier this year compiled with CLANG and compiler option -march=native or -march=corei7 (this laptop does have a Lynnfield dualCore i5 CPU). Whenever I hit backspave in the console of such a compiled system, the console exited and I found myself back at the login prompter again. This vanished after setting explicitely -march=core2. The boxes now in question are both older CoreDuo architectures (Q6600 and E8400 CPUs). The backspace/arrow-key weirdness occures not on the consoles anymore, but it happens that clients with files requester or entry fields for some data input exiting, when hitting backspace or, say, the back-arrow key. Today I realized this in evim when being asked for a file to open and I made a typo. It seems, that the error occurs more often if the locale is set to non-C standard (in my case, its partially set either to de_DE.UTF-8 or de_DE.ISO8859-1 or en_US.UTF-8). Regards, Oliver ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Strange warning with clang and 9RC1 (ntohs)
It doesnt warn here. Can you check with clang -E what the ntohs()
is being expanded to and what the real prototype is?
On Mon, Oct 31, 2011 at 06:35:18PM -0600, Axel Gonzalez wrote:
I'm getting an strange warning whem compiling with clang (from base) on RC1.
This warning doesn't appear with 8.X and clang from ports.
The warning is strange because ntohs is not int:
uint16_t
ntohs(uint16_t netshort);
Any insight would be appreciated, thanks in advance!
A
% gcc -Wall -o ntohs ntohs.c
% clang -Wall -o ntohs ntohs.c
ntohs.c:8:12: warning: conversion specifies type 'unsigned short' but the
argument has type
'int' [-Wformat]
printf(%hu\n, ntohs(x));
~~^
%d
1 warning generated.
#include stdio.h
#include netinet/in.h
int main()
{
uint16_t x = htons(80);
printf(%hu\n, (uint16_t)ntohs(x));
printf(%hu\n, ntohs(x));
return (0);
}
--
Mon Oct 31 18:02:13 2011 GMT
**
*
**
**
*
** 5.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [9.0-RC1 FreeBSD] [amd64] buildworld fails on building lib/libss with CLANG
This is a bug in clang, llvm supports amdfam10 but the clang counterpart wasnt updated. Thank you for the report! On Sat, Oct 29, 2011 at 03:44:30PM +0200, David Marec wrote: hi list, Running FreebSD 9.0 RC-1, the make buildworld processing failed on the following error on its attempt to build 'lib/libssp': === gnu/lib/libssp/libssp_nonshared (obj,depend,all,install) rm -f .depend CC='clang' mkdep -f .depend -a-DHAVE_CONFIG_H -I/usr/src/gnu/lib/libssp/libs sp_nonshared/.. -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/g cclibs/libssp -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcc libs/include -DPIC /usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/ gcclibs/libssp/ssp-local.c clang -O2 -pipe -march=native -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libssp/libssp_n onshared/.. -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gccl ibs/libssp -I/usr/src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gccli bs/include -fPIC -DPIC -fvisibility=hidden -std=gnu99 -fstack-protector -c /usr /src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp/ssp-loca l.c error: unknown target CPU 'amdfam10' *** Error code 1 Stop in /usr/src/gnu/lib/libssp/libssp_nonshared. *** Error code 1 The sources files were updated yesterday evening. I did not try to process this with gcc yet. -- David Marec, mailto:david.ma...@davenulle.org http://user.lamaiziere.net/david/Site http://www.diablotins.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [9.0-RC1 FreeBSD] [amd64] buildworld fails on building lib/libss with CLANG
On Sun, Oct 30, 2011 at 08:28:42AM +0100, Roman Divacky wrote: This is a bug in clang, llvm supports amdfam10 but the clang counterpart wasnt updated. Thank you for the report! fwiw, I fixed it in clang r143305, so in the next import this will work just fine :) roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0 RC1/Clang / illegal instruction (Signal 4) in gengtype while building cc_tools on i586.
Program received signal SIGILL, Illegal instruction.
0x08048b24 in do_typedef (s=0x80532bf CUMULATIVE_ARGS, pos=0x805e1a4)
at /usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtype.c:103
103 {
(gdb) disas 0x08048b24
Dump of assembler code for function do_typedef:
0x08048b10 do_typedef+0: push %ebp
0x08048b11 do_typedef+1: mov%esp,%ebp
0x08048b13 do_typedef+3: push %ebx
0x08048b14 do_typedef+4: push %edi
0x08048b15 do_typedef+5: push %esi
0x08048b16 do_typedef+6: sub$0xc,%esp
0x08048b19 do_typedef+9: mov$0x805e1d4,%edi
0x08048b1e do_typedef+14: mov0x10(%ebp),%esi
0x08048b21 do_typedef+17: mov0x8(%ebp),%ebx
0x08048b24 do_typedef+20: nopw %cs:0x0(%eax,%eax,1)
LLVM attempts to use an optimal nop sequence when writing N-byte nop,
by using these nop instructions
static const uint8_t Nops[10][10] = {
// nop
{0x90},
// xchg %ax,%ax
{0x66, 0x90},
// nopl (%[re]ax)
{0x0f, 0x1f, 0x00},
// nopl 0(%[re]ax)
{0x0f, 0x1f, 0x40, 0x00},
// nopl 0(%[re]ax,%[re]ax,1)
{0x0f, 0x1f, 0x44, 0x00, 0x00},
// nopw 0(%[re]ax,%[re]ax,1)
{0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00},
// nopl 0L(%[re]ax)
{0x0f, 0x1f, 0x80, 0x00, 0x00, 0x00, 0x00},
// nopl 0L(%[re]ax,%[re]ax,1)
{0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00},
// nopw 0L(%[re]ax,%[re]ax,1)
{0x66, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00},
// nopw %cs:0L(%[re]ax,%[re]ax,1)
{0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00},
};
There's no checking for a supported CPU, is it so that AMD geode doesnt support
any of these?
Any other cpu that doesnt support these? If this is CPU dependant, I suggest to
open a bug
report upstream as it's a bug.
roman
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0 RC1/Clang / illegal instruction (Signal 4) in gengtype while building cc_tools on i586.
On Sun, Oct 23, 2011 at 11:43:30AM +0300, Kostik Belousov wrote:
On Sun, Oct 23, 2011 at 10:24:12AM +0200, Roman Divacky wrote:
Program received signal SIGILL, Illegal instruction.
0x08048b24 in do_typedef (s=0x80532bf CUMULATIVE_ARGS, pos=0x805e1a4)
at
/usr/src/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtype.c:103
103 {
(gdb) disas 0x08048b24
Dump of assembler code for function do_typedef:
0x08048b10 do_typedef+0: push %ebp
0x08048b11 do_typedef+1: mov%esp,%ebp
0x08048b13 do_typedef+3: push %ebx
0x08048b14 do_typedef+4: push %edi
0x08048b15 do_typedef+5: push %esi
0x08048b16 do_typedef+6: sub$0xc,%esp
0x08048b19 do_typedef+9: mov$0x805e1d4,%edi
0x08048b1e do_typedef+14: mov0x10(%ebp),%esi
0x08048b21 do_typedef+17: mov0x8(%ebp),%ebx
0x08048b24 do_typedef+20: nopw %cs:0x0(%eax,%eax,1)
LLVM attempts to use an optimal nop sequence when writing N-byte nop,
by using these nop instructions
static const uint8_t Nops[10][10] = {
// nop
{0x90},
// xchg %ax,%ax
{0x66, 0x90},
// nopl (%[re]ax)
{0x0f, 0x1f, 0x00},
// nopl 0(%[re]ax)
{0x0f, 0x1f, 0x40, 0x00},
// nopl 0(%[re]ax,%[re]ax,1)
{0x0f, 0x1f, 0x44, 0x00, 0x00},
// nopw 0(%[re]ax,%[re]ax,1)
{0x66, 0x0f, 0x1f, 0x44, 0x00, 0x00},
// nopl 0L(%[re]ax)
{0x0f, 0x1f, 0x80, 0x00, 0x00, 0x00, 0x00},
// nopl 0L(%[re]ax,%[re]ax,1)
{0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00},
// nopw 0L(%[re]ax,%[re]ax,1)
{0x66, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00},
// nopw %cs:0L(%[re]ax,%[re]ax,1)
{0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00},
};
There's no checking for a supported CPU, is it so that AMD geode doesnt
support any of these?
Any other cpu that doesnt support these? If this is CPU dependant, I
suggest to open a bug
report upstream as it's a bug.
Long nops are supported only on specific CPUs. Unconditional use of them
is a plain bug, like unconditional use of cmovXX.
Yes, it's a bug, I filed http://llvm.org/bugs/show_bug.cgi?id=11212 upstream.
Patric, as a temporary workaround please add -no-integrated-as to your
CFLAGS, that will make clang use gnu as instead of its own intergrated
assembler, thus avoiding this problem.
Thanks for the great analysis!
roman
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Crashes in world built w/ clang: FP registers?
On Mon, Sep 19, 2011 at 05:46:54PM +0200, Roman Divacky wrote: On Sun, Sep 18, 2011 at 11:05:55AM -0500, Jason Harmening wrote: Can you try building just tcsh ? I wonder if -O0 makes any difference... in either case, can you give me preprocessed (clang -E) source that exhibits this bug (check with objdump -d that the unaligned sse read is there) and show me how to reproduce that... I'll try that here. To be honest, I am not sure why others are not seeing this behaviour :( roman Building w/ -O0 eliminated the crash in csh at least. In that case, tw_collect() isn't even using the SSE registers. I've attached the objdump output for csh for both the -O2 and -O0 cases, along w/ the preprocessor output for tw.parse.c. it doesnt build for me.. with tons of errors like pes ~$ clang tw.parse.cpp In file included from ../../contrib/tcsh/tw.parse.c:1: In file included from ../../contrib/tcsh/tw.parse.c:36: In file included from ../../contrib/tcsh/sh.h:38: /usr/include/stddef.h:57:19: error: cannot combine with previous 'type-name' declaration specifier typedef __wchar_t wchar_t; ^ how did you get the preprocessed file? and/or how do you compile it? Nevermind... I managed to save the file as a .cpp file :) But I am not seeing any misaligned SSE reads/writes: pes ~$ clang -O2 -c tw.parse.c objdump -d tw.parse.o | grep movaps 23: 0f 29 85 60 ff ff ffmovaps %xmm0,0xff60(%rbp) 3f6: 0f 29 85 10 ff ff ffmovaps %xmm0,0xff10(%rbp) 6b6: 0f 29 85 f0 fe ff ffmovaps %xmm0,0xfef0(%rbp) 85b: 0f 29 45 c0 movaps %xmm0,0xffc0(%rbp) 867: 0f 29 45 a0 movaps %xmm0,0xffa0(%rbp) 873: 0f 29 45 80 movaps %xmm0,0xff80(%rbp) b37: 0f 29 85 d0 fe ff ffmovaps %xmm0,0xfed0(%rbp) e2c: 0f 29 85 c0 fe ff ffmovaps %xmm0,0xfec0(%rbp) e3e: 0f 29 85 a0 fe ff ffmovaps %xmm0,0xfea0(%rbp) e50: 0f 29 85 80 fe ff ffmovaps %xmm0,0xfe80(%rbp) 1a4b: 0f 29 45 c0 movaps %xmm0,0xffc0(%rbp) 21e3: 0f 29 45 d0 movaps %xmm0,0xffd0(%rbp) 2647: 0f 29 85 50 fe ff ffmovaps %xmm0,0xfe50(%rbp) 2659: 0f 29 85 30 fe ff ffmovaps %xmm0,0xfe30(%rbp) How exactly are you compiling it? roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Crashes in world built w/ clang: FP registers?
On Sun, Sep 18, 2011 at 11:05:55AM -0500, Jason Harmening wrote: Can you try building just tcsh ? I wonder if -O0 makes any difference... in either case, can you give me preprocessed (clang -E) source that exhibits this bug (check with objdump -d that the unaligned sse read is there) and show me how to reproduce that... I'll try that here. To be honest, I am not sure why others are not seeing this behaviour :( roman Building w/ -O0 eliminated the crash in csh at least. In that case, tw_collect() isn't even using the SSE registers. I've attached the objdump output for csh for both the -O2 and -O0 cases, along w/ the preprocessor output for tw.parse.c. it doesnt build for me.. with tons of errors like pes ~$ clang tw.parse.cpp In file included from ../../contrib/tcsh/tw.parse.c:1: In file included from ../../contrib/tcsh/tw.parse.c:36: In file included from ../../contrib/tcsh/sh.h:38: /usr/include/stddef.h:57:19: error: cannot combine with previous 'type-name' declaration specifier typedef __wchar_t wchar_t; ^ how did you get the preprocessed file? and/or how do you compile it? roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Status of clang/llvm cross-compiling for ARM
On Mon, Jul 04, 2011 at 05:11:07PM +0200, Damjan Marion wrote: Hi, Just to briefly share with wider audience progress on cross-compiling for ARM using llvm/clang. I managed to cross-compile kernel with clang for Marvel SoC and run world compiled with gcc in multiuser. It works stable and I didn't notice any issues so far. Cross compiling even works from MacOS. Caveat is that it still requires binutils as integrated assembler is not stable enough. To make it absolutely clear - Damjan booted kernel built with clang and reports that it's even running stable. I think it's a very nice milestone. Congrats! roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: LLVM: llvm-as, llvm-ld and so on not contained in FreeBSD core contrib?
On Sat, Jun 25, 2011 at 09:57:52AM +0200, Hartmann, O. wrote:
Hello.
Just for my couriosity: I'm missing llvm-as, llvm-ld and other binutils
from LLVM and was wondering why they are contained in the port's llvm
collection but not in FreeBSD's source contribution.
There's no use for these utilities in FreeBSD base system.
I build FreeBSD 9 with CLANG. But as a missing llvm-as and llvm-ld (or
llvm-ar) would imply, the binaries are generated via binutils from
theGNU suite, aren't they?
llvm-{as,ld,ar} are not replacements for those from binutils. llvm-*
work on the llvm bitcode only and are of no use for normal object
files.
dim@ made a patch that adds those utilities if you really need them
http://lists.freebsd.org/pipermail/freebsd-toolchain/2011-June/000216.html
By default when you compile things with clang it uses its own assembler
(ie. it goes directly from C - .o) so typically only gnu ld is used
in the compilation chain.
roman
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang error make buildworld
Because with clang, -march=native often breaks buildworld, while -march=core2 is ok. Can you be more specific about this claim? On what CPU are seeing this breakage? Anyway, can you compile and run on that machine this: http://lev.vlakno.cz/~rdivacky/Host.cpp It's the LLVM CPU autodetection code, it will print the name of your CPU. I wonder whats the difference to core2. Thank you. roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang error make buildworld
clang -O2 -pipe -march=native -fomit-frame-pointer -DATJOB_DIR=\/var/at/jobs/\ -DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/libexec/atrun/gloadavg.c clang -O2 -pipe -march=native -fomit-frame-pointer -DATJOB_DIR=\/var/at/jobs/\ -DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o gloadavg.o -lpam -lutil clang: warning: argument unused during compilation: '-std=gnu99' /usr/obj/usr/src/tmp/usr/lib/crt1.o: In function `_start': /usr/src/lib/csu/amd64/crt1.c:(.text+0x5d): undefined reference to `atexit' Can you invoke this very same command (ie. linking) with -### and show me? Does it work when you try to link the same .o files without specifying -march=native ? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang error make buildworld
# /usr/obj/usr/src/tmp/usr/bin/clang -O2 -pipe -march=native -fomit-frame-pointer -DATJOB_DIR=\/var/at/jobs/\ -DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o gloadavg.o -lpam -lutil FAIL (clang: error: linker command failed with exit code 1 (use -v to see invocation)) Can you run this in gdb and show me backtrace? Also, what version is your binutils? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: webcamd-0.1.26: does not build with clang
This is a bug in llvm integrated assembler. I filed a bug for it http://llvm.org/bugs/show_bug.cgi?id=9822 webcamd compiles/links just fine with clang + gnu as. On Sat, Apr 30, 2011 at 11:53:30AM +0200, Hans Petter Selasky wrote: On Saturday 30 April 2011 11:46:28 Hans Petter Selasky wrote: linux_init_mod/linux_exit_mod. These two symbols are so-called sections. At least the GCC will resolve these, I.E. when there is an __attribute__((__section__(linux_init_mod))), then also extern linux_init_mod resolves. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: webcamd-0.1.26: does not build with clang
I just tested with new llvm/clang and it compiles ok. I hope there's going to be a new llvm/clang import in a few days so please try again after the import.. The port does not link though, because of some problems with linux_init_mod/linux_exit_mod. I didnt analyze it but I suspect this may be a bug in the code itself (C99 vs C89?) On Sat, Apr 30, 2011 at 11:13:25AM +0200, Hans Petter Selasky wrote: On Friday 29 April 2011 13:04:52 Boris Samorodov wrote: Hi! The port builds with the system compiler but not with clang: ftp://ftp.bsam.ru/pub/tmp/webcamd.log.txt Hi, Edit the webcamd's port Makefile so that only one file is compiled at a time. MAKE_JOBS_SAFE= yes The following error code indicates a bug in the C-frontend of clang? Instruction does not dominate all uses! %tmp164 = add i32 %i.0162, %tmp %conv24 = trunc i32 %tmp164 to i16 Instruction does not dominate all uses! %conv24 = trunc i32 %tmp164 to i16 %call28 = call fastcc i32 @dw210x_op_rw(%struct.usb_device* %tmp26, i8 zeroext -75, i16 zeroext %conv24, i16 zeroext 0, i8* %1, i16 zeroext 2, i32 0) Broken module found, compilation aborted! Stack dump: 0. Program arguments: /usr/bin/clang -cc1 -triple i386-undermydesk- freebsd9.0 -emit-obj -disable-free -main-file-name dw2102.c -mrelocation-model static -mdisable-fp-elim -relaxed-aliasing -masm-verbose -mconstructor-aliases -target-cpu i486 -momit-leaf-frame-pointer -resource-dir /usr/bin/../lib/clang/2.9 -include webcamd_global.h -D _GNU_SOURCE -D CURR_FILE_NAME=dw2102 -D CONFIG_USB_GSPCA -D CONFIG_USB_GSPCA_SONIXB -D CONFIG_USB_GSPCA_SONIXJ -D CONFIG_USB_GSPCA_ZC3XX -D CONFIG_DVB_AF9013 -D CONFIG_MEDIA_TUNER_MXL5005S -D CONFIG_DVB_STV0288 -D CONFIG_DVB_MT312 -D CONFIG_DVB_DS3000 -D CONFIG_DVB_STB0899 -D CONFIG_DVB_STB6100 -D CONFIG_DVB_LNBP22 -D CONFIG_DVB_TUNER_DIB0070 -D CONFIG_DVB_DIB7000P -D CONFIG_MEDIA_TUNER_MT2060 -D BITS_PER_LONG=32 -D LINUX -D CONFIG_INPUT -D CONFIG_VIDEO_V4L1_COMPAT -D CONFIG_DVB_DIB3000MC -D CONFIG_VIDEO_PVRUSB2_DVB - D CONFIG_I2C -D CONFIG_DVB_CORE -D CONFIG_AS102_USB -D CONFIG_FW_LOADER -D HAVE_WEBCAMD -D DBUS_API_SUBJECT_TO_CHANGE -D HAVE_HAL -D CONFIG_DVB_AT76C651 -D CONFIG_DVB_ATBM8830 -D CONFIG_DVB_AU8522 -D CONFIG_DVB_BCM3510 -D CONFIG_DVB_CX22700 -D CONFIG_DVB_CX22702 -D CONFIG_DVB_CX24110 -D CONFIG_DVB_CX24116 -D CONFIG_DVB_CX24123 -D CONFIG_DVB_DIB3000MB -D CONFIG_DVB_DIB3000MC -D CONFIG_DVB_DIB3000MC -D CONFIG_DVB_DIB7000M -D CONFIG_DVB_DIB7000P -D CONFIG_DVB_DIB8000 -D CONFIG_DVB_DRX397XD -D CONFIG_DVB_EC100 -D CONFIG_DVB_ISL6405 -D CONFIG_DVB_ISL6421 -D CONFIG_DVB_ISL6423 -D CONFIG_DVB_L64781 -D CONFIG_DVB_LGDT3304 -D CONFIG_DVB_LGDT3305 -D CONFIG_DVB_LGDT330X -D CONFIG_DVB_LGS8GL5 -D CONFIG_DVB_LGS8GXX -D CONFIG_DVB_LNBP21 -D CONFIG_DVB_LNBP22 -D CONFIG_DVB_MB86A16 -D CONFIG_DVB_MT312 -D CONFIG_DVB_MT352 -D CONFIG_DVB_NXT200X -D CONFIG_DVB_NXT6000 -D CONFIG_DVB_OR51132 -D CONFIG_DVB_OR51211 -D CONFIG_DVB_PLL -D CONFIG_DVB_S5H1409 -D CONFIG_DVB_S5H1411 -D CONFIG_DVB_S5H1420 -D CONFIG_DVB_S921 -D CONFIG_DVB_SI21XX -D CONFIG_DVB_SP8870 -D CONFIG_DVB_SP887X -D CONFIG_DVB_STB0899 -D CONFIG_DVB_STB6000 -D CONFIG_DVB_STB6100 -D CONFIG_DVB_STV0288 -D CONFIG_DVB_STV0297 -D CONFIG_DVB_STV0299 -D CONFIG_DVB_STV0900 -D CONFIG_DVB_STV090x -D CONFIG_DVB_STV6110 -D CONFIG_DVB_STV6110x -D CONFIG_DVB_TDA10021 -D CONFIG_DVB_TDA10023 -D CONFIG_DVB_TDA10048 -D CONFIG_DVB_TDA1004X -D CONFIG_DVB_TDA10086 -D CONFIG_DVB_TDA665x -D CONFIG_DVB_TDA8083 -D CONFIG_DVB_TDA80XX -D CONFIG_DVB_TDA8261 -D CONFIG_DVB_TDA826X -D CONFIG_DVB_TUA6100 -D CONFIG_DVB_TUNER_CX24113 -D CONFIG_DVB_TUNER_DIB0090 -D CONFIG_DVB_TUNER_ITD1000 -D CONFIG_DVB_VES1820 -D CONFIG_DVB_VES1X93 -D CONFIG_DVB_ZL10036 -D CONFIG_DVB_ZL10039 -D CONFIG_DVB_ZL10353 -D CONFIG_MEDIA_TUNER_MAX2165 -D CONFIG_MEDIA_TUNER_MC44S803 -D CONFIG_MEDIA_TUNER_MC44S803 -D CONFIG_MEDIA_TUNER_MT2060 -D CONFIG_MEDIA_TUNER_MT20XX -D CONFIG_MEDIA_TUNER_MT2131 -D CONFIG_MEDIA_TUNER_MT2266 -D CONFIG_MEDIA_TUNER_MXL5005S -D CONFIG_MEDIA_TUNER_MXL5007T -D CONFIG_MEDIA_TUNER_QT1010 -D CONFIG_MEDIA_TUNER_SIMPLE -D CONFIG_MEDIA_TUNER_TDA18271 -D CONFIG_MEDIA_TUNER_TDA18218 -D CONFIG_MEDIA_TUNER_TDA827X -D CONFIG_MEDIA_TUNER_TDA8290 -D CONFIG_MEDIA_TUNER_TDA9887 -D CONFIG_MEDIA_TUNER_TEA5761 -D CONFIG_MEDIA_TUNER_TEA5767 -D CONFIG_MEDIA_TUNER_XC2028 -D CONFIG_MEDIA_TUNER_XC5000 -D CONFIG_VIDEO_EM28XX_DVB -D CONFIG_VIDEO_SAA7134_DVB_MODULE -D CONFIG_IR_CORE - D CONFIG_VIDEO_IR -I /usr/ports/multimedia/webcamd/work/webcamd-0.1.26/dummy - I /usr/ports/multimedia/webcamd/work/webcamd-0.1.26/headers -I /usr/ports/multimedia/webcamd/work/webcamd-0.1.26/v4l- dvb/linux/drivers/media/video/gspca -I /usr/ports/multimedia/webcamd/work/webcamd-0.1.26/v4l- dvb/linux/drivers/media/video/hdpvr -I /usr/ports/multimedia/webcamd/work/webcamd-0.1.26/v4l- dvb/linux/drivers/media/common/tuners -I
Re: [TESTING]: boot2 compilation with -mregparm=3
On Sun, Mar 20, 2011 at 08:41:04PM +0100, Fabian Keil wrote:
Roman Divacky rdiva...@freebsd.org wrote:
This patch:
http://lev.vlakno.cz/~rdivacky/boot2-mregparm.patch
makes boot2 to be compiled with -mregparm=3 (which shrinks it
some). It changes CFLAGS to include -mregparm=3 and also
rewrites sio.S to use register passing.
This survived my testing in qemu and jhb@s review.
Works for me on amd64 with gcc, but I don't use either
a serial console or gptboot/zfsboot.
thank you for testing, although I really need someone to test
this on serial console {gpt,zfs}boot
it seems to work for me and fail for the other tester so I
really dont know what to think
roman
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[TESTING]: boot2 compilation with -mregparm=3
Hi, This patch: http://lev.vlakno.cz/~rdivacky/boot2-mregparm.patch makes boot2 to be compiled with -mregparm=3 (which shrinks it some). It changes CFLAGS to include -mregparm=3 and also rewrites sio.S to use register passing. This survived my testing in qemu and jhb@s review. Please test this patch with boot2 booting via serial console, and with gptboot/zfsboot using serial console. Thank you! This is the last FreeBSD patch in the clang-boot2 saga so please help. roman pgpt6a7b28BAA.pgp Description: PGP signature
Re: [TESTING]: one more boot2 shrinking patch
On Thu, Mar 10, 2011 at 09:20:58AM -0500, John Baldwin wrote: On Wednesday, March 09, 2011 6:24:36 pm Dimitry Andric wrote: On 2011-03-09 14:23, John Baldwin wrote: gcc nor clang emits any code to initialize static type foo = 0; because it's expected that BSS is zeroed, which is not the case in boot2 so we have to initialize that explicitly It used to be that if you explicitly initialized a variable to 0, it was initialized to 0 in .data, but now gcc and clang recognize it is set to 0 and move it to .bss. There appears to be no way to turn this feature off, Yes, there is; both gcc and clang have this option to turn it off: -fno-zero-initialized-in-bss If the target supports a BSS section, GCC by default puts variables that are initialized to zero into BSS. This can save space in the resulting code. This option turns off this behavior because some programs explicitly rely on variables going to the data section. E.g., so that the resulting executable can find the beginning of that section and/or make assumptions based on that. The default is -fzero-initialized-in-bss. Hah, that is better then. Thanks! I should have searched about this more myself. :( Roman, can you try reverting the kname changes and adding this to CFLAGS instead for both compilers? when I put -fno-zero-initialized-in-bss clang does not fit by 1.7K and gcc by 0.5K, we dont want this :) roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[TESTING]: one more boot2 shrinking patch
hi, this diet patch http://lev.vlakno.cz/~rdivacky/boot2-final-diet.patch includes these changes: o bunch of variables are turned into uint8_t o initial setting of namep[] in lookup() is removed as it's only overwritten a few lines down o kname is explicitly initialized in main() as BSS in boot2 is not zeroed o the fmt dance in load() is removed o buf in printf() is made static to save space Please test/review this patch. John Baldwin already looked and I booted it so it should be quite safe. I plan to commit this in a few days unless problems are found.. thank you! roman p.s. for those interested - with a few other changes (to llvm, not freebsd) we do fit within boot2 limit :) pgpHQAOl1ks9t.pgp Description: PGP signature
Re: [TESTING]: one more boot2 shrinking patch
On Tue, Mar 08, 2011 at 09:19:31PM +0100, Fabian Keil wrote: Roman Divacky rdiva...@freebsd.org wrote: this diet patch http://lev.vlakno.cz/~rdivacky/boot2-final-diet.patch includes these changes: o bunch of variables are turned into uint8_t o initial setting of namep[] in lookup() is removed as it's only overwritten a few lines down o kname is explicitly initialized in main() as BSS in boot2 is not zeroed Are you saying the previous: static const char *kname = NULL; didn't work, or is this the explanation why the initialization hasn't simply been removed? gcc nor clang emits any code to initialize static type foo = 0; because it's expected that BSS is zeroed, which is not the case in boot2 so we have to initialize that explicitly o the fmt dance in load() is removed o buf in printf() is made static to save space Please test/review this patch. John Baldwin already looked and I booted it so it should be quite safe. I plan to commit this in a few days unless problems are found.. Works for me with gcc from base on amd64. I noticed an unrelated warning about an unused variable, though. /usr/src/sys/boot/i386/boot2/boot2.c: In function 'load': /usr/src/sys/boot/i386/boot2/boot2.c:310: warning: unused variable 'x' It seems to be left over from: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/boot/i386/boot2/boot2.c.diff?r1=1.91;r2=1.92;f=h The attached (only compile-tested) patch removes it. oh, I'll commit that with the rest thanks for the testing! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: boot2 changes
On Wed, Mar 02, 2011 at 02:28:54AM +, Alexander Best wrote: On Mon Feb 28 11, Roman Divacky wrote: hi there, I have a patch that shrinks boot2 some: 1) it switches kname to be just a pointer instead of an array thus avoiding a couple of memcpy()s 2) it changes ioctl to unsigned from uint8_t 3) it changes the first keyhit limit to 5 seconds from 3 so that constant propagation can take place 4) it changes the ticks overflow computation as suggested by bde@ 5) it removes bi_basemem/bi_extmem/bi_memsizes_valid setting from bootinfo as it is unused the patch: http://lev.vlakno.cz/~rdivacky/boot2-almost-there-diet.patch It works for me and I'd like you to review/test this patch did you also take a look at the code in sys/boot/i386/common? many functions in sys/boot/i386/boot2/boot2.c are also defined there and some seem to contain improved code. e.g. was the return type of xputc() changed from int to void, i think that's quite a resonable change and might reduce the boot2 binary size further. I have some more experimental changes locally, and I am working on that, dont worry :) roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: boot2 changes
On Tue, Mar 01, 2011 at 07:54:14AM -0500, John Baldwin wrote: On Monday, February 28, 2011 3:39:28 pm Roman Divacky wrote: 3) it changes the first keyhit limit to 5 seconds from 3 so that constant propagation can take place Does this make booting take 2 seconds longer as a result? I'm curious as to why '3*FOO' isn't a constant but '5*FOO' is? I worded it wrong, the point being that if the argument is the same in all callsites the compiler can turn it into a constant and propagate that to the function. I will remove this as it saves just 8 bytes... thank you for the review! roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[TESTING]: boot2 changes
hi there, I have a patch that shrinks boot2 some: 1) it switches kname to be just a pointer instead of an array thus avoiding a couple of memcpy()s 2) it changes ioctl to unsigned from uint8_t 3) it changes the first keyhit limit to 5 seconds from 3 so that constant propagation can take place 4) it changes the ticks overflow computation as suggested by bde@ 5) it removes bi_basemem/bi_extmem/bi_memsizes_valid setting from bootinfo as it is unused the patch: http://lev.vlakno.cz/~rdivacky/boot2-almost-there-diet.patch It works for me and I'd like you to review/test this patch thank you! roman pgpJ8XlLqHNgI.pgp Description: PGP signature
Re: [RFC] removing broken includes
I see it crashes very early on ;) can you report: Assertion failed: (isValid()), function getSpellingLoc, file SourceLocation.cpp, line 84. this stuff to the developers? the tool looks pretty useful On Tue, Feb 08, 2011 at 11:58:27AM +, Alexander Best wrote: On Fri Feb 4 11, Garrett Cooper wrote: On Fri, Feb 4, 2011 at 10:53 PM, Roman Divacky rdiva...@freebsd.org wrote: alex, I think you are the kind of person to try out http://code.google.com/p/include-what-you-use/ with fbsd :) Please be careful with this tool though. There's header pollution in them thar c files (refer to the FreeBSD and/or POSIX manpages for the source of truth), e.g. time.h vs sys/time.h ! HTH, here's my first attempt running [1] make -k CXX=/usr/local/src/llvm/Debug+Asserts/bin/include-what-you-use CC=/usr/local/src/llvm/Debug+Asserts/bin/include-what-you-use buildkernel cheers. alex [1] http://people.freebsd.org/~arundel/misc/include-what-you-use-buildkernel-output -Garrett -- a13x ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [RFC] removing broken includes
alex,
I think you are the kind of person to try out
http://code.google.com/p/include-what-you-use/
with fbsd :)
On Thu, Feb 03, 2011 at 10:12:57PM +, Alexander Best wrote:
hi everybody,
i've started to check the source for broken includes, such as the one fixed in
r218189. so far i've run through arch=amd64 and found only two broken
includes,
which should be fixed by the attached patch. the commands i'm using are:
for target=buildkernel:
make SRCCONF=/dev/null __MAKE_CONF=/dev/null NO_WARNS= CWARNFLAGS=-w -Werror
-Wmissing-include-dirs buildkernel
for target=buildworld:[*]
make SRCCONF=/dev/null __MAKE_CONF=/dev/null WITHOUT_CDDL=true NO_WARNS=
CWARNFLAGS=-w -Wmissing-include-dirs buildworld
next up are the other archs. also i'll try to run both buildworld and
installworld with CC=clang -v and CXX=clang++ -v. although clang turns
-Wmissing-include-dirs into a noop, using the -v flag one can still detect
broken (and even duplicate) includes. thanks to pluknet@ for the info.
cheers.
alex
[*] the reason i'm setting WITHOUT_CDDL=true is that my installed world was
compiled with that option. trying to buildworld with CDDL support thus fails.
also at first i was trying to use the same command for buildworld, as i used
for buildkernel. however it seems CWARNFLAGS gets set in some places, so
gcc(1)
will also treat non -Wmissing-include-dirs warnings as errors.
--
a13x
Index: sys/conf/files
===
--- sys/conf/files(revision 218217)
+++ sys/conf/files(working copy)
@@ -960,7 +960,7 @@
dev/e1000/e1000_82571.c optional em | igb \
compile-with ${NORMAL_C} -I$S/dev/e1000
dev/e1000/e1000_82575.c optional em | igb \
- compile-with ${NORMAL_C} -I$S/dev/igb
+ compile-with ${NORMAL_C} -I$S/dev/e1000
dev/e1000/e1000_ich8lan.coptional em | igb \
compile-with ${NORMAL_C} -I$S/dev/e1000
dev/e1000/e1000_api.coptional em | igb \
Index: sys/modules/netgraph/atm/ccatm/Makefile
===
--- sys/modules/netgraph/atm/ccatm/Makefile (revision 218217)
+++ sys/modules/netgraph/atm/ccatm/Makefile (working copy)
@@ -12,6 +12,6 @@
SRCS=ng_ccatm.c cc_conn.c cc_data.c cc_dump.c cc_port.c cc_sig.c
\
cc_user.c unisap.c
-CFLAGS+= -I${LIBBASE} -I${LIBBASE}/netnatm/ccatm -DCCATM_DEBUG
+CFLAGS+= -I${LIBBASE} -DCCATM_DEBUG
.include bsd.kmod.mk
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[RFC]: tautological compares in amd64 GENERIC
hi,
clang found these problems in our amd64 GENERIC:
some of these may be real bugs lurking in our code - can the respective owners
of the subsystems take a look? The bugs cover all areas from ufs/vm to
net*/security.
Thank you!
roman
cam/cam_periph.c:530:28: warning: comparison of unsigned expression 0 is
always false [-Wtautological-compare]
else if (periph-refcount 0)
^ ~
kern/uipc_syscalls.c:347:16: warning: comparison of unsigned expression 0 is
always false [-Wtautological-compare]
if (*namelen 0)
^ ~
kern/uipc_syscalls.c:1472:12: warning: comparison of unsigned expression 0 is
always false [-Wtautological-compare]
if (*alen 0)
~ ^ ~
kern/uipc_syscalls.c:1572:12: warning: comparison of unsigned expression 0 is
always false [-Wtautological-compare]
if (*alen 0)
~ ^ ~
ufs/ffs/ffs_inode.c:538:24: warning: comparison of unsigned expression 0 is
always false [-Wtautological-compare]
if (DIP(ip, i_blocks) 0) /* sanity */
~ ^ ~
ufs/ufs/ufs_quota.c:329:44: warning: comparison of unsigned expression = 0 is
always true [-Wtautological-compare]
if (dq-dq_curinodes != 0 ncurinodes = 0)
~~ ^ ~
ufs/ufs/ufs_quota.c:367:21: warning: comparison of unsigned expression = 0 is
always true [-Wtautological-compare]
ncurinodes = 0)
~~ ^ ~
vm/vm_pageout.c:1701:14: warning: comparison of unsigned expression = 0 is
always true [-Wtautological-compare]
if (limit = 0 size = limit) {
~ ^ ~
amd64/amd64/sys_machdep.c:562:16: warning: comparison of unsigned expression
0 is always false [-Wtautological-compare]
uap-num 0 || largest_ld max_ldt_segment)
^ ~
netinet6/in6_mcast.c:1849:30: warning: comparison of unsigned expression 0 is
always false [-Wtautological-compare]
if (mreq.ipv6mr_interface 0 ||
~ ^ ~
netinet6/in6_mcast.c:2196:15: warning: comparison of unsigned expression 0 is
always false [-Wtautological-compare]
if (ifindex 0 || V_if_index ifindex)
~~~ ^ ~
netinet6/in6_mcast.c:2354:14: warning: comparison of unsigned expression 0 is
always false [-Wtautological-compare]
if (ifindex 0 || V_if_index ifindex)
~~~ ^ ~
netinet6/ip6_output.c:2542:29: warning: comparison of unsigned expression 0
is always false [-Wtautological-compare]
pktinfo-ipi6_ifindex 0) {
~ ^ ~
netinet6/scope6.c:391:15: warning: comparison of unsigned expression 0 is
always false [-Wtautological-compare]
if (zoneid 0 || V_if_index zoneid)
~~ ^ ~
security/audit/audit_syscalls.c:306:39: warning: comparison of unsigned
expression 0 is always false [-Wtautological-compare]
(udata.au_qctrl64.aq64_minfree 0) ||
security/mac/mac_framework.c:589:20: warning: comparison of unsigned expression
0 is always false [-Wtautological-compare]
if (mac-m_buflen 0 ||
~ ^ ~
dev/acpica/acpi_pci.c:284:24: warning: comparison of unsigned expression 0 is
always false [-Wtautological-compare]
if (pcib_get_bus(dev) 0)
~ ^ ~
dev/buslogic/bt.c:978:16: warning: comparison of unsigned enum expression = 0
is always true [-Wtautological-compare]
if (bio_index = 0 bio_index BT_NUM_ISAPORTS)
~ ^ ~
dev/cs/if_cs.c:367:12: warning: comparison of unsigned expression = 0 is
always true [-Wtautological-compare]
if (irq = 0 || irq 16)
~~~ ^ ~
dev/sym/sym_hipd.c:3449:10: warning: comparison of unsigned expression 0 is
always false [-Wtautological-compare]
if (fak 0){fak = 0; ret = -1;}
~~~ ^ ~
dev/usb/serial/usb_serial.c:1056:18: warning: comparison of unsigned expression
0 is always false [-Wtautological-compare]
if (t-c_ospeed 0) {
~~~ ^ ~
pgpbJzfo5NIRN.pgp
Description: PGP signature
Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/
On Thu, Jan 06, 2011 at 11:59:07PM +0100, Erik Cederstrand wrote: Den 06/01/2011 kl. 20.56 skrev Tijl Coosemans: On Thursday 06 January 2011 09:01:09 Erik Cederstrand wrote: Den 05/01/2011 kl. 20.36 skrev Jilles Tjoelker: On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Sp?rlein wrote: - get IPA to work with clang, or at least file a bug - mark functions as __dead2 (please don't do that) Why not? Because the analyzer is supposed to find bugs. Only the function that really doesn't return should be marked as such. If we begin spewing __dead2's everywhere, it's bound to silence a valid bug somewhere down the line when e.g. a conditional in a print_help() function is changed subtly so it doesn't always reach exit(). On the other hand you can't really expect the compiler/analyser to know what a procedure in another file does, so in that case you need __dead2 anyway. [...] I have high expectations of LLVM :-) LLVM already has some knowledge of what's going on in other files (see LTO) so why shouldn't it be able to detect the __noreturn__ ? All the necessary information should be readily available. the static analyzer has nothing to do with LLVM. it's a clang component and uses only the info that clang knows. and clang (ie. the C frontend) does not perform any analysis of this kind, thus it does not know that stuff is dead. fwiw - my trivial (but working) patch brought down the number of reports by mere 5% so the bulk is probably somewhere else... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/
On Wed, Jan 05, 2011 at 05:55:45PM +0100, Ulrich Sp??rlein wrote: On Wed, 05.01.2011 at 09:34:49 -0500, John Baldwin wrote: On Wednesday, January 05, 2011 9:11:50 am Erik Cederstrand wrote: Den 05/01/2011 kl. 14.56 skrev Erik Cederstrand: Ignoring contrib code for the moment, I decided to look at usr.sbin.pw from 2011-01-05. There's one report (http://scan.freebsd.your.org/freebsd-head/usr.sbin.pw/2011-01-05-amd64/report-KkilQ3.html#EndPath) which turns out to be a false positive: * Step 6 calls cmdhelp() on line 168; * cmdhelp() ends with exit(EXIT_FAILURE); on line 432 which I assume is exit(3) from libc * The analyzer doesn't know that this function never returns and continues to flag a null dereference in step 8 The same is true of err(), verr(), errc(), verrc(), errx(), and verrx() which is also causing false positive reports. They ultimately call exit(3). These are all marked as __dead2, so the compiler should know that these do not return. And clang did the right thing here in the past. Beware that it does no inter-procedural analysis yet, so it will usually miss that usage() calls exit unconditionally. *But*, it should grok that for err(3) and exit(3). Now there are some possible remedies: - get IPA to work with clang, or at least file a bug - mark functions as __dead2 (please don't do that) - come up with a way to mark the false positives (kinda impossible with the way scan-build currently works) The problem is that while exit() is __dead2 the actual cmdhelp() is not. At least clang does not see it as such. Thus the static analyzer just sees a call to a normal function (it does not recurse into it) and produces this false positive... I wonder how how hard would it to be to add some trivial IPA that analyzes cases like this.. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FYI: clang static analyzer page has moved to http://scan.freebsd.your.org/freebsd-head/
On Wed, Jan 05, 2011 at 09:22:42PM +0100, Erik Cederstrand wrote: Den 05/01/2011 kl. 17.55 skrev Ulrich Sp?rlein: And clang did the right thing here in the past. Beware that it does no inter-procedural analysis yet, so it will usually miss that usage() calls exit unconditionally. *But*, it should grok that for err(3) and exit(3). Now there are some possible remedies: - get IPA to work with clang, or at least file a bug I filed a bug with LLVM (http://llvm.org/bugs/show_bug.cgi?id=8914) but it seems IPA bugs filed on the analyzer have been rejected in the past. I have a dumb patch that may help here... can someone test it? http://lev.vlakno.cz/~rdivacky/clang-checker-no-return.patch it may slow down the analysis a lot, if it does please add a recursion limit there... roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[RFC]: unnecessary padding in various kernel structures
hi, clang (svn version) has ability to detect unnecessary padding in structures. I ran this on kernel build on i386 (stripped GENERIC) and amd64 (full GENERIC), preprocessed this and posted on web. The lists contain the file of the definition, name of the structure, size of the unnecessary padding and reason for the alignment. The last field is how many times this was hit during the build of the kernel. The lists are sorted by the size of the padding. Examples (i386): dev/usb/controller/ohci.h:64:8: 2 times padding size of 'struct ohci_hcca' with 120 bytes to alignment boundary sys/pcpu.h:156:8: 58 times padding size of 'struct pcpu' with 108 bytes to alignment boundary sys/pcpu.h:199:2: 58 times padding struct 'struct pcpu' with 84 bytes to align 'pc_monitorbuf' dev/usb/controller/ehci.h:170:8:1 times padding size of 'struct ehci_qtd' with 58 bytes to alignment boundary kern/sched_ule.c:206:8: 1 times padding size of 'struct tdq' with 41 bytes to alignment boundary Examples(amd64): net/flowtable.c:179:11: 1 times padding struct 'struct flowtable' with 124 bytes to align 'ft_udp_idle' dev/usb/controller/ohci.h:64:8: 2 times padding size of 'struct ohci_hcca' with 120 bytes to alignment boundary net/flowtable.c:160:8: 1 times padding size of 'struct flowtable' with 108 bytes to alignment boundary vm/uma_int.h:184:8: 6 times padding size of 'struct uma_cache' with 96 bytes to alignment boundary vm/uma_int.h:338:19:5 times padding struct 'struct uma_zone' with 92 bytes to align 'uz_cpu' net/flowtable.c:149:8: 1 times padding size of 'struct flowtable_stats' with 64 bytes to alignment boundary Full lists can be found here: http://lev.vlakno.cz/~rdivacky/kernel-unecessary-padding-i386.txt http://lev.vlakno.cz/~rdivacky/kernel-unecessary-padding-amd64.txt Instances of some of these structures can be in memory many times. And thus we can be losing a lot of memory without noticing it. Can you guys look at the biggest offenders or some other interesting structures in the lists and do something about it? Maybe be simple reshuffling we can improve things a lot! Thank you Roman pgp6ttntmSgRd.pgp Description: PGP signature
Re: libcompiler_rt now part of FreeBSD's base system
On Thu, Nov 11, 2010 at 04:52:43PM +0100, Ed Schouten wrote: Hello all, I just committed libcompiler_rt.a to HEAD. Even though I don't expect serious issues -- especially not on the tier 1 architectures -- be sure to contact me in case something goes wrong. I hooked it up to the build in a separate commit, so if your system starts to act weird, just revert r215127. great! can you share some more info about: -what is the plan for the unwinder etc? I know there's something from apple (not opensourced yet?) and others (tm) (not announced publicly yet I think) -how often(ever?) do you plan to update? while there's not much going on in compiler-rt repo it's not dead -do you plan to tackle libc++ now? :-P roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[PATCH]: boot2 optimizations to shrink it
Hi, can you guys review this patch: http://lev.vlakno.cz/~rdivacky/boot2.safe.patch It shrinks boot2 by 52 bytes by: eliminating memcpy() calls buffer shrinking as we are only ever called with argument 256 for the %u modifier constifying write-only variable Rui Paulo tested this, is this patch ok? May I commit this? thank you, roman pgpUQGv7xZWqw.pgp Description: PGP signature
Re: Removal of libobjc
On Fri, Oct 15, 2010 at 08:15:52PM +0100, Rui Paulo wrote: Hi, I was hoping we could remove libobjc from the base system as it's seriously outdated and it's not used by anything on the base system. If there are any objections, please speak up. please wait until the ports are converted to use libobjc2 (already in progress).. it should be a few days/weeks at most now I think roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Another clang problem
On Sun, Oct 03, 2010 at 05:21:15PM +0200, Dimitry Andric wrote: On 2010-10-03 15:41, Derek Tattersall wrote: In updating gnash to 8.8 the build failed while linking with libvgl.so. My current system was built last week, with both kernel and world built with clang. The linkage failure was due to an inlined function, set4pixels which is only referred to, as far as I can tell, within the source file simple.c which contains the function definition. The problem is that set4pixels() and another function set2lines() are defined as 'inline' functions in simple.c, but it is compiled with -std=gnu99. This means that these definitions cannot be called from another object file. So, either libvgl should be compiled with -std=gnu89, or somebody who knows about libvgl's official API should decide whether these functions must be externally accessible or not. Since libvgl looks very old (it was imported 8 years ago, and the last functional change was 6 years ago), the former is probably the easiest fix. we compile world with -std=gnu99 even with gcc, why isnt this problem with gcc? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Examining the VM splay tree effectiveness
are you aware of Summer of Code 2008 project by Mayur Shardul? quoting: http://www.freebsd.org/projects/summerofcode-2008.html Project: VM Algorithm Improvement Student: Mayur Shardul Mentor: Jeff Roberson Summary: A new data structure, viz. radix tree, was implemented and used for management of the resident pages. The objective is efficient use of memory and faster performance. The biggest challenge was to service insert requests on the data structure without blocking. Because of this constraint the memory allocation failures were not acceptable, to solve the problem the required memory was allocated at the boot time. Both the data structures were used in parallel to check the correctness and we also benchmarked the data structures and found that radix trees gave much better performance over splay trees. Ready to enter CVS/SVN: We will investigate some more approaches to handle allocation failures before the new data structure goes in CVS. On Thu, Sep 30, 2010 at 06:37:38PM +0200, Andre Oppermann wrote: Just for the kick of it I decided to take a closer look at the use of splay trees (inherited from Mach if I read the history correctly) in the FreeBSD VM system suspecting an interesting journey. The VM system has two major structures: 1) the VM map which is per process and manages its address space by tracking all regions that are allocated and their permissions. 2) the VM page table which is per VM map and provides the backing memory pages to the regions and interfaces with the pmap layer (virtual-physical). Both of these are very frequently accessed through memory allocations from userspace and page faults from the pmap layer. Their efficiency and SMP scalability is crucial for many operations beginning with fork/ exec, going through malloc/mmap and ending with free/exit of a process. Both the vmmap and page table make use of splay trees to manage the entries and to speed up lookups compared to long to traverse linked lists or more memory expensive hash tables. Some structures though do have an additional linked list to simplify ordered traversals. A splay tree is an interesting binary search tree with insertion, lookup and removal performed in O(log n) *amortized* time. With the *amortized* time being the crucial difference to other binary trees. On every access *including* lookup it rotates the tree to make the just found element the new root node. For all gory details see: http://en.wikipedia.org/wiki/Splay_tree This behavior has a few important implications: 1) the root node and constant rotation works like a cache with least recent looked up node at the top and less recently ones close to the top; 2) every lookup that doesn't match the root node, ie. a cache miss, causes a rotation of the tree to make the newly found node the new root; 3) during the rotate it has to re-arrange and touch possibly a large number of other nodes; 4) in worst case the tree may resemble a linked list. A splay tree makes no guarantee that it is balanced. For the kernel and the splay tree usage in the VM map and page table some more implications come up: a) the amortization effect/cost only balance if the majority of lookups are root node (cache) hits, otherwise the cost of rebalancing destroys any advantage and quickly turns into a large overhead. b) the overhead becomes even worse due to touching many nodes and causing a lot of CPU cache line dirtying. For processes with shared memory or threads across CPU's this overhead becomes almost excessive because the CPU's stomp on each others cached nodes and get their own caches invalidated. The penalty is a high-latency memory refetch not only for the root node lookup but every hop in the following rebalancing operation = thrashing. To quantify the positive and negative effects of the splay tree I instrumented the code and added counters to track the behavior of the splay tree in the vmmap and page table. The test case is an AMD64 kernel build to get a first overview. Other system usages may have different results depending on their fork and memory usage patters. The results are very interesting: The page table shows a *very* poor root node hit rate and an excessive amount of rotational node modifications representing almost the worst case for splay trees. http://chart.apis.google.com/chart?chs=700x300chbh=a,23chds=0,127484769chd=t:16946915,16719791,48872230,131057,74858589,105206121cht=bvgchl=insert|remove|lookup|cachehit|rotates|rotatemodifies The vmmap shows a high root node hit rate but still a significant amount of rotational node modifications. http://chart.apis.google.com/chart?chs=700x300chbh=a,23chds=0,21881583chd=t:724293,723701,20881583,19044544,3719582,4553350cht=bvgchl=insert|remove|lookup|cachehit|rotates|rotatemodifies From these observations I come to the conclusion
Re: Examining the VM splay tree effectiveness
On Thu, Sep 30, 2010 at 07:46:32PM +0200, Andre Oppermann wrote: On 30.09.2010 19:24, Roman Divacky wrote: are you aware of Summer of Code 2008 project by Mayur Shardul? I remember that there was this project but I never saw any numbers or other outcome of it. Haven't checked p4 to look at the code though. there's a little something: http://wiki.freebsd.org/MayurShardul/VM_Algorithm_Improvement ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Examining the VM splay tree effectiveness
On Thu, Sep 30, 2010 at 07:49:00PM +0200, Roman Divacky wrote: On Thu, Sep 30, 2010 at 07:46:32PM +0200, Andre Oppermann wrote: On 30.09.2010 19:24, Roman Divacky wrote: are you aware of Summer of Code 2008 project by Mayur Shardul? I remember that there was this project but I never saw any numbers or other outcome of it. Haven't checked p4 to look at the code though. there's a little something: http://wiki.freebsd.org/MayurShardul/VM_Algorithm_Improvement and the actual patch + userspace implementation + benchmarking suite is here: http://code.google.com/p/google-summer-of-code-2008-freebsd/downloads/detail?name=Mayur_Shardul.tar.gzcan=2q= it looks like a solid work with solid results to me ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 09:40:18AM -0300, Renato Botelho wrote: On Wed, Sep 29, 2010 at 8:34 AM, Dimitry Andric d...@freebsd.org wrote: On 2010-09-29 13:23, Renato Botelho wrote: #!/usr/bin/perl use File::Temp; my ( $fh, $filename ) = File::Temp::tempfile(); print $filename\n; For me it works perfectly, though I am using perl 5.10: $ cat foo.pl #!/usr/bin/perl use File::Temp; my ( $fh, $filename ) = File::Temp::tempfile(); print $filename\n; $ perl -v This is perl, v5.10.1 (*) built for i386-freebsd-64int Copyright 1987-2009, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using man perl or perldoc perl. ?If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. $ perl foo.pl /tmp/tv25CPnWhF $ perl foo.pl /tmp/L2UJQ5_JJs $ perl foo.pl /tmp/6ynQYvWIc1 $ perl foo.pl /tmp/Tdpf7PKBMg $ perl foo.pl /tmp/76ir2i1ici $ perl foo.pl /tmp/LhfD0eZgd8 I'll try building perl 5.12 and try it again. Btw, I assume you did *not* rebuild perl with clang, so your perl is still compiled with gcc? Well, I find out where the problem is, now I have my entire system built with gcc. After install libc.so.7 built with clang the problem starts, installing same lib built with gcc the problem stops. How can I debug it to give you more information? renato, can you check if libc compiled with clang -O0 still exhibits the bug? thank you, roman ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 11:56:59AM -0400, Derek Tattersall wrote: * Dimitry Andric d...@freebsd.org [100929 08:55]: On 2010-09-29 13:23, Renato Botelho wrote: #!/usr/bin/perl use File::Temp; my ( $fh, $filename ) = File::Temp::tempfile(); print $filename\n; For me it works perfectly, though I am using perl 5.10: $ cat foo.pl #!/usr/bin/perl use File::Temp; my ( $fh, $filename ) = File::Temp::tempfile(); print $filename\n; $ perl -v This is perl, v5.10.1 (*) built for i386-freebsd-64int Copyright 1987-2009, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using man perl or perldoc perl. If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. $ perl foo.pl /tmp/tv25CPnWhF $ perl foo.pl /tmp/L2UJQ5_JJs $ perl foo.pl /tmp/6ynQYvWIc1 $ perl foo.pl /tmp/Tdpf7PKBMg $ perl foo.pl /tmp/76ir2i1ici $ perl foo.pl /tmp/LhfD0eZgd8 I'll try building perl 5.12 and try it again. Btw, I assume you did *not* rebuild perl with clang, so your perl is still compiled with gcc? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I built a test case using perl 5.12 and demonstrated that calling int(rand()) in perl returns NAN, as does calling rand() by itself. A C program that calls libc's rand() does return differing integers. The perl documentation claims that perl's rand() calls Cs rand() and srand() if necessary. I think this effectively demonstrates that the problem lies with the perl function rand() and it's interface to libc's rand() as provided by clang. On a recent stable system, perl's mktemp works fine. The only real difference is that libc on stable is built with gcc and libc on current is built with clang. what does this show with clang libc? perl -e 'print int(rand(60)) . \n foreach (1 .. 10)' I guess it returns all 0, as the $CHAR[0] is 'A', can you test that? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 29, 2010 at 02:41:17PM -0300, Renato Botelho wrote: On Wed, Sep 29, 2010 at 2:31 PM, Roman Divacky rdiva...@freebsd.org wrote: On Wed, Sep 29, 2010 at 11:56:59AM -0400, Derek Tattersall wrote: * Dimitry Andric d...@freebsd.org [100929 08:55]: On 2010-09-29 13:23, Renato Botelho wrote: #!/usr/bin/perl use File::Temp; my ( $fh, $filename ) = File::Temp::tempfile(); print $filename\n; For me it works perfectly, though I am using perl 5.10: $ cat foo.pl #!/usr/bin/perl use File::Temp; my ( $fh, $filename ) = File::Temp::tempfile(); print $filename\n; $ perl -v This is perl, v5.10.1 (*) built for i386-freebsd-64int Copyright 1987-2009, Larry Wall Perl may be copied only under the terms of either the Artistic License or the GNU General Public License, which may be found in the Perl 5 source kit. Complete documentation for Perl, including FAQ lists, should be found on this system using man perl or perldoc perl. ?If you have access to the Internet, point your browser at http://www.perl.org/, the Perl Home Page. $ perl foo.pl /tmp/tv25CPnWhF $ perl foo.pl /tmp/L2UJQ5_JJs $ perl foo.pl /tmp/6ynQYvWIc1 $ perl foo.pl /tmp/Tdpf7PKBMg $ perl foo.pl /tmp/76ir2i1ici $ perl foo.pl /tmp/LhfD0eZgd8 I'll try building perl 5.12 and try it again. Btw, I assume you did *not* rebuild perl with clang, so your perl is still compiled with gcc? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I built a test case using perl 5.12 and demonstrated that calling int(rand()) in perl returns NAN, as does calling rand() by itself. ?A C program that calls libc's rand() does return differing integers. ?The perl documentation claims that perl's rand() calls Cs rand() and srand() if necessary. ?I think this effectively demonstrates that the problem lies with the perl function rand() and it's interface to libc's rand() as provided by clang. On a recent stable system, perl's mktemp works fine. ?The only real difference is that libc on stable is built with gcc and libc on current is built with clang. what does this show with clang libc? perl -e 'print int(rand(60)) . \n foreach (1 .. 10)' I guess it returns all 0, as the $CHAR[0] is 'A', can you test that? r...@botelhor:/usr/src/lib/libc# perl -e 'print int(rand(60)) . \n foreach (1 .. 10)' nan nan nan nan nan nan nan nan nan nan heh, now I noticed that Derek already wrote that ;) is anyone able to find where in perl sources the rand function is defined? I failed that :( ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang now builds world and kernel, on i386 and amd64
On Sat, Sep 25, 2010 at 08:55:51PM +, b. f. wrote: Dmitry Andric wrote: On 2010-09-25 21:16, Paul B Mahol wrote: When to expect to get rid of GNU as and other binutils tools? Work is progressing steadily on the clang/llvm integrated assembler, which removes the need for an external assembler such as gas, and which should also reduce compile times further. This is really in alpha state right now, but Roman Divacky (who is one of the active contributors) can probably tell more about its progress. Another important component is of course the linker, but I am not aware of a similar project to replace that; excepting gold, but that is a GPLv3 project too, unfortunately. There has been another effort underway for some time: http://sourceforge.net/apps/trac/elftoolchain/ Perhaps some coordination between those working on llvm in FreeBSD, and the elftoolchain project, would be helpful? there's not that much overlap between those two - in a case elftoolchain gets to implementing linker it would be sweet if it supported the same plugin API as gold so we can use LLVM LTO plugin there... beside that I dont see much point in teaching nm to see into llvm object files etc. (we already have tools for that) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang now builds world and kernel, on i386 and amd64
On Sat, Sep 25, 2010 at 10:23:44PM +0200, Dimitry Andric wrote: On 2010-09-25 21:16, Paul B Mahol wrote: On 9/22/10, Dimitry Andricd...@freebsd.org wrote: As of r212979, you should now be able to build world and kernel on i386 and amd64 with clang, without any additional patches! ... When to expect to get rid of GNU as and other binutils tools? Work is progressing steadily on the clang/llvm integrated assembler, which removes the need for an external assembler such as gas, and which should also reduce compile times further. This is really in alpha state right now, but Roman Divacky (who is one of the active contributors) can probably tell more about its progress. yes, this will give us BSDL modern asm (ie. things like SSE4.x works etc.) on X86/arm Another important component is of course the linker, but I am not aware of a similar project to replace that; excepting gold, but that is a GPLv3 project too, unfortunately. I know of something that may happen, it's in planning stage now There is also an LLDB Debugger project in the very early stages of development, see http://lldb.llvm.org/, but this works only on Mac OS X now. Volunteers are invited to port this to FreeBSD. :) Not binutils related, but still possibly interesting to FreeBSD, are also the libc++ and compiler-rt projects, a GNU libstdc++ replacement and a GNU libgcc replacement, respectively. See http://libcxx.llvm.org/ and http://compiler-rt.llvm.org/ for more information. there's also elftoolchain: http://sourceforge.net/apps/trac/elftoolchain/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang now builds world and kernel, on i386 and amd64
On Wed, Sep 22, 2010 at 11:15:47PM +0200, Bartosz Stec wrote: On 2010-09-22 22:42, Rene Ladan wrote: Just tried it. World has been builded without any problems, but stge kernel module failed to compile: === stge (all) clang -O2 -pipe -march=athlon-xp -fno-strict-aliasing -D_KERNEL -DKLD_MODULE -nostdinc -DHAVE_KERNEL_OPTION_HEADERS -include /usr/obj/usr/src/sys/ATHLON9/opt_global.h -I. -I@ -I@/contrib/altq -fno-common -I/usr/obj/usr/src/sys/ATHLON9 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -std=iso9899:1999 -fstack-protector -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -c /usr/src/sys/modules/stge/../../dev/stge/if_stge.c /usr/src/sys/modules/stge/../../dev/stge/if_stge.c:1947:5: error: 'break' statement not in loop or switch statement break; ^ /usr/src/sys/modules/stge/../../dev/stge/if_stge.c:1953:6: error: 'break' statement not in loop or switch statement break Hmm, works for me: acer# ls -l /boot/kernel/if_stge.ko* -r-xr-xr-x 1 root wheel 39344 Sep 22 13:34 /boot/kernel/if_stge.ko -r-xr-xr-x 1 root wheel 218248 Sep 22 13:34 /boot/kernel/if_stge.ko.symbols acer# This is with the default GENERIC kernel. Rene Problem wasn't clang related, but caused by stge changes in r212973, and it has already been fixed (in r213000). I will post comparison of building times and results using gcc/clang/ccache/noccache on my box soon :) if you want to post any build-time numbers for clang please -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS #-DNDEBUG uncomment the -DNDEBUG on this line in lib/clang/clang.build.mk and rebuild it otherwise you are using Release+Asserts build of clang which is some 30% slower than the normal one... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Official request: Please make GNU grep the default
On Fri, Aug 13, 2010 at 01:43:16AM -0700, Doug Barton wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Gabor, I hope at this point it goes without saying that I have a lot of respect for the work you've done on BSD grep, and I've already told you that I think you're very courageous for taking the project on. I've been testing and evaluating it for some time now, and I think I've given it a fair trial. You've done a fairly good job of responding to bug reports, and I understand that the exposure BSD grep has received as the default in HEAD has been very valuable in exposing additional areas that need work. However, with all that in mind I am officially asking you to please change the default in HEAD to GNU grep. (Note, I am _not_ asking you to remove BSD grep from the tree, just to change the default.) My reason is simple, performance. While doing some portmaster work recently I was regression testing some changes I made to the --index* options and noticed that things were dramatically slower than the last time I tested those features. Thinking that I had made a programming mistake I dug into my code, and while the regexps that I was using could be tuned for slightly better performance the problem was not in my code. I then installed textproc/gnugrep to compare, and the differences were very dramatic using a highly pessimized test case (finding a match on the last line of INDEX). The script I used to test is at http://people.freebsd.org/~dougb/grep-time-trial.sh.txt and a typical result was: GNU grep Elapsed time: 2 seconds BSD grep Elapsed time: 47 seconds what about optimizing BSD grep instead? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[INFO]: newer clang/LLVM in HEAD
hi, ed@ just committed an update of clang/LLVM to HEAD. This update has (at least) 3 bugs fixed that were reported from FreeBSD. these are: - annoying unknown pragma warning during make depend of kernel - DWARF fix that fixes dtrace (contributed by kan@) this requires libelf fix as well - clang (the driver) execing itself (the compiler) fix regardless of PATH Beside this, clang should compile C++ better than the previous snapshot. It should be faster as well. So far a few problems in clang/LLVM and FreeBSD were fixed but many other remains, what to do about it? Test clang with your code! just cd /usr/src/my/code/ CC=clang make clang can spot problems gcc cannot and it would be nice to have those fixed. it improves the code quality and takes at most a few minutes. if you encounter something that you think is a clang bug/problem/annoyance please let us know so we can get this fixed. thank you for your help! Roman Divacky pgp6NHtWVf2Uh.pgp Description: PGP signature
Re: [TESTING]: updated clang/LLVM needs testing in ClangBSD
I updated clang/LLVM in clangbsd to a newer version which I believe will fix thas. can you rene (and everyone else) please retest with updated ClangBSD and report back? thank you! On Thu, Jul 15, 2010 at 01:33:04PM +0200, Ren? Ladan wrote: 2010/7/14 Roman Divacky rdiva...@freebsd.org: hi, ClangBSD was updated to LLVM/clang revision r108243 which we plan to merge into HEAD. We would like that revision to be tested as much as possible and therefore we ask you to test ClangBSD to assure that the revision we are updating to does not have some really embarassing bugs. How to do it (on i386 and amd64): 0) install fresh devel/llvm-devel port 1) svn co http://svn.freebsd.org/base/projects/clangbsd src 2) echo NO_WERROR= /etc/src.conf ; echo WERROR= /etc/src.conf 3) cd src make buildworld And here my buildworld fails with: === lib/clang/libclanglex (depend) tblgen -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic -gen-clang-diags-defs -clang-component=Common /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td DiagnosticCommonKinds.inc.h tblgen -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic -gen-clang-diags-defs -clang-component=Lex /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td DiagnosticLexKinds.inc.h rm -f .depend CC='clang -isysroot /usr/obj/usr/home/rene/freebsd/clangbsd/tmp -B/usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/lib/ -L/usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/lib/' mkdep -f .depend -a -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\amd64-undermydesk-freebsd9.0\ -DCLANG_VENDOR=\FreeBSD\ \ -DSVN_REVISION=\108243\ -DCLANG_VENDOR_SUFFIX=\\ 20100713\ /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/HeaderMap.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/HeaderSearch.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/LiteralSupport.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroArgs.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroInfo.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPCaching.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPDirectives.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPExpressions.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPLexerChange.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPMacroExpansion.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PTHLexer.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Pragma.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PreprocessingRecord.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Preprocessor.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PreprocessorLexer.cpp /usr/home/rene
[TESTING]: updated clang/LLVM needs testing in ClangBSD
hi,
ClangBSD was updated to LLVM/clang revision r108243 which we plan to
merge into HEAD. We would like that revision to be tested as much as possible
and therefore we ask you to test ClangBSD to assure that the revision
we are updating to does not have some really embarassing bugs.
How to do it (on i386 and amd64):
0) install fresh devel/llvm-devel port
1) svn co http://svn.freebsd.org/base/projects/clangbsd src
2) echo NO_WERROR= /etc/src.conf ; echo WERROR= /etc/src.conf
3) cd src make buildworld
4) make installworld DESTDIR=/usr/clangbsd
5) (optional) try to build kernel with clang and boot it
5.1) cd /sys/{arch}/conf
5.2) config YOUR_KERNEL
5.3) setenv CC clang in tcsh or export CC=clang in sh/bash
5.4) cd ../compile/YOUR_KERNEL
5.5) make make install
please make sure that it builds (on amd64/i386) and that the resulting world
is runnable. ie. try to chroot into it and do stuff. ie.
chroot /clangbsd /bin/tcsh
... stuff ...
there's a wiki page on this effort:
http://wiki.freebsd.org/BuildingFreeBSDWithClang
please report back any problems/success to me and/or this mailing list.0
thank you for your testing!
Roman Divacky on behalf of the ClangBSD team
pgpKnKYxby9vx.pgp
Description: PGP signature
Re: two buildworld problems
On Sun, Jun 13, 2010 at 10:28:23PM +0200, Alexander Best wrote: hi there. i'm experiencing two problems during buildworld. i'm not sure if these are the result of me doing weird stuff or a problem in the src structure: 1. i have the following in my make.conf: .if empty(.CURDIR:M/usr/src/*) empty(.CURDIR:M/usr/obj/*) exists(/usr/local/bin/gcc44) CC = gcc44 CXX = g++44 CPP = cpp44 .endif you may want to reverse the condition, ie. .if !empty(.CURDIR:M/usr/ports/*) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kernel make noise with clang suppression
On Thu, Jun 10, 2010 at 11:39:35AM -0700, Matthew Jacob wrote: Comments? (yes, I know -fformat-extensions have just been added...) yes, clang reports A LOT MORE warnings than gcc but I believe that we should not supress those atm. I'd prefer people to take a look at those and fix them instead. clang in clangbsd is complaining much less btw. (it does not complain about unknown params etc.) note that we are still in the progress of importing stuff from clangbsd and it takes time. please be patient :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang and 'make -j' problem
On Thu, Jun 10, 2010 at 10:21:36AM -0700, Steve Kargl wrote: nice make -j3 d DiagnosticCommonKinds.inc.h tblgen: not found *** Error code 127 *** Error code 127 tblgen -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 -I/usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/AST -gen-clang-stmt-nodes /usr/src/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/AST/StmtNodes.td StmtNodes.inc.h tblgen: not found *** Error code 127 3 errors *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error *** Error code 2 1 error Please fix. for some reason tblgen from bootstrap-tools target has not been built before libs. is there some sort of ordering we can use? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Import of clang/LLVM about to start
On Fri, Jun 11, 2010 at 04:00:26PM +0200, Alexander Best wrote: thanks a lot for the hints. doing buildkernel and buildworld with current src worked fine. how should i proceed if i want to try building kernel and world with clang? put CC, CXX and CPP in src.conf? or make.conf? or use envars? any of these will work :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Import of clang/LLVM about to start
Hi, The import of clang/LLVM is about to start. I'll announce when the import is finished. It would be nice if you didn't commit while the import is in progress. thank you Roman Divacky pgpy8CasgxJd6.pgp Description: PGP signature
Re: Import of clang/LLVM about to start
the import is finished. feel free to commit and enjoy clang :) On Wed, Jun 09, 2010 at 07:45:16PM +0200, Roman Divacky wrote: Hi, The import of clang/LLVM is about to start. I'll announce when the import is finished. It would be nice if you didn't commit while the import is in progress. thank you Roman Divacky pgpAfDy2Jn5Bi.pgp Description: PGP signature
Re: Import of clang/LLVM about to start
I dont see the error message but I guess you dont have tblgen built (a necessary part for building clang/LLVM) buildworld should be fine On Wed, Jun 09, 2010 at 11:30:10PM +0200, Alexander Best wrote: that's great news! :) just tried to do `make depend all` in usr.bin/clang and got: === clang (depend) tblgen -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Driver -gen-opt-parser-defs /usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Driver/CC1AsOptions.td CC1AsOptions.inc.h tblgen -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Driver -gen-opt-parser-defs /usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Driver/CC1Options.td CC1Options.inc.h tblgen -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic -gen-clang-diags-defs -clang-component=Common /usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td DiagnosticCommonKinds.inc.h tblgen -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic -gen-clang-diags-defs -clang-component=Driver /usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td DiagnosticDriverKinds.inc.h tblgen -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic -gen-clang-diags-defs -clang-component=Frontend /usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td DiagnosticFrontendKinds.inc.h tblgen -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic -gen-clang-diags-defs -clang-component=Lex /usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td DiagnosticLexKinds.inc.h tblgen -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic -gen-clang-diags-defs -clang-component=Sema /usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td DiagnosticSemaKinds.inc.h tblgen -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver -I. -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/../../lib/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Driver -gen-opt-parser-defs /usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Driver/Options.td Options.inc.h rm -f .depend mkdep -f .depend -a -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include -I/usr/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/tools/driver
Re: [INFO]: import of clang/LLVM to happen on June 9th
On Fri, Jun 04, 2010 at 01:33:10PM -0400, Justin Hibbits wrote: On Fri, Jun 4, 2010 at 11:26 AM, Roman Divacky rdiva...@freebsd.org wrote: Dear current@ On June 9th, we are importing clang/LLVM into FreeBSD HEAD. We are going to import clang/LLVM sources and put those into contrib/llvm (~45MB) and the build infrastructure for it (lib/clang and usr.bin/clang). There's also a small patch to hook it into the build. This patch is attached for review or available at (stripped from mergeinfo): http://lev.vlakno.cz/~rdivacky/clangbsd-import.patch Clang will be enabled to be built on amd64/i386/ppc by default and disabled everywhere else. The selected clang/LLVM revision is r104832. Clang will be installed as clang so it should not interfere with anything. There's a switch (WITH_CLANG and WITHOUT_CLANG) that alters whether clang will be built or not. We plan to update clang/LLVM often as bugs are being found/fixed. From the point of view of a user nothing changes except one more application will be installed after the next buildworld/installworld. The next plan is to gradually start integrating the necessary changes to enable buildworld with clang but this is pending some more discussion. Roman Divacky Does this mean the last bits of the ppc support have been fixed? no, PPC still lacks the var args implementation but Nathan Whitehorn requested clang/llvm to be enabled on PPC. Maybe he's got some patches in his sleeve ;) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[INFO]: import of clang/LLVM to happen on June 9th
Dear current@ On June 9th, we are importing clang/LLVM into FreeBSD HEAD. We are going to import clang/LLVM sources and put those into contrib/llvm (~45MB) and the build infrastructure for it (lib/clang and usr.bin/clang). There's also a small patch to hook it into the build. This patch is attached for review or available at (stripped from mergeinfo): http://lev.vlakno.cz/~rdivacky/clangbsd-import.patch Clang will be enabled to be built on amd64/i386/ppc by default and disabled everywhere else. The selected clang/LLVM revision is r104832. Clang will be installed as clang so it should not interfere with anything. There's a switch (WITH_CLANG and WITHOUT_CLANG) that alters whether clang will be built or not. We plan to update clang/LLVM often as bugs are being found/fixed. From the point of view of a user nothing changes except one more application will be installed after the next buildworld/installworld. The next plan is to gradually start integrating the necessary changes to enable buildworld with clang but this is pending some more discussion. Roman Divacky pgpsw5gZcOMit.pgp Description: PGP signature
Importing clang/LLVM into FreeBSD HEAD
Hi, I would like to propose to integrate clang/LLVM into FreeBSD HEAD in the near future (days, not weeks). clang/LLVM is a C/C++/ObjC compiler (framework) which aims to possibly replace gcc. It is BSDL-like licensed. The sources are ~45MB (the svn checkout is 97MB). Clang/LLVM is written in C++. Clang can compile all of FreeBSD on i386/amd64 including world and booting kernel. Other architectures that are close to working are MIPS, PowerPC and ARM. We have a branch (clangbsd-import) that just includes clang/LLVM sources and the build infrastructure and this is what we aim to integrate at first. The import of clang/LLVM was discussed at the toolchain summit May 10th but I would like to hear your opinion. I got approval from core@ on importing it. So please share your support or resistance to the idea of importing clang. Roman Divacky pgpHiEeWDS1oU.pgp Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 12:56:17PM +0300, Kostik Belousov wrote:
On Mon, May 31, 2010 at 12:03:17AM -0600, Scott Long wrote:
On May 30, 2010, at 7:58 AM, Kostik Belousov wrote:
On Sat, May 29, 2010 at 03:02:40PM +0200, Roman Divacky wrote:
hi,
ClangBSD was updated to LLVM/clang revision 104832 which is what we
aim to import into HEAD in roughly a week. We would like the initial
It was promised that before the import, the public discussion on
the mailing list will happen. So far, nothing appeared on either
arch@ or current@ providing argumentation why should we accept this.
Sounds like you're inviting the discussion right now. I'll start =-)
1. I hate gcc with the burning heat of a million suns. It's not a
tool, it's a political weapon wielded by the FSF and their acolytes.
It's also a crummy piece of software that has been good enough for
far too long. Its development model is a burden to work with and has
been a major liability towards FreeBSD releases in the past. Its
demise cannot happen soon enough.
2. Due to the political bent of the GPL3 and the FSF's insistence
on shoving it down everyone's throats, FreeBSD is stuck with a
dead-end version of gcc. This has already been a liability in terms
of addressing bugs in gcc itself, and it will only get worse as
technology moves forward and gcc stands still.
3. Clang/LLVM has an active development base and a clear future. It
will move forward while gcc rots. There simply is no future left in
gcc unless the FreeBSD project decides to embrace the GPL3, and that's
a move that has already been heavily discussed, debated, and decided
on. Anecdotally, I think that FreeBSD is benefiting from shunning the
GPL3; it's made it an attractive option for companies looking for an
unencumbered OS for their products.
4. While Clang is immature now, it will mature in the near future,
and FreeBSD will benefit from that process. FreeBSD will get built-in
access to upcoming technologies like GCD+Blocks and better code
editors and development tools that gcc will never support. It'll break
free of the development stranglehold that exists within gcc. Clang has
shown good agility in adapting to the needs of FreeBSD and the legacy
of gcc, thanks in large part to the efforts of people like Roman. Gcc
has been nothing but drama and headache, even with the valiant efforts
of people like Alexander Kabaev.
5. If all of this turns out to not be true and Clang/LLVM fails,
FreeBSD has lost nothing and can remove it from the base system. Gcc
remains where it is for now, at least until it's time for the remove
gcc discussion.
The future is !gcc. Putting Clang+LLVM into a position where it can
be easily embraced by FreeBSD users will greatly benefit the FreeBSD
project.
Scott
I do not object to a single point in your message. On the other hand, all
said could be labeled as distilled propaganda.
My main concern is the usefulness of HEAD for routine bug-fixing process.
The proposed merge makes it relatively easy for users to start compiling
the system with CLang. Our HEAD userbase is one of the most valuable
project asset to ensure the quality of the system. After the support for
easy compilation with clang is imported, some substantial portion of the
HEAD users definitely start experimenting with it. This immediately makes
the bug reports against HEAD almost useless, since level of demotivation
when looking at the bug is immense. When you do know that the issue can
be in the compiler, and not the OS, why looking ?
Any bug analisys now shall start with exchange to verify which compiler
was used to build the reporter system, and ask to reproduce it with gcc.
[I am talking not only about gnats, but also mailing list questions,
private pleas for help etc].
agreed. what do you propose to help identify/prevent situations when
people are reporting bugs coming from a compiler problem rather than
those from a genuine src problem?
people are already experimenting with clang installed from ports,
with gcc4.{3,4,5} from ports etc. by not importing clang we can
maybe delay this a little but it's coming anyway.
My personal opinion is that pushing the import now at the present state
of clang makes a disservice to FreeBSD, and possible clang. Why not keep
the glue on the branch as it is ? Motivated testers willing to help
definitely can checkout from the branch. Import can happen when we are
satisfied with the quality of new compiler, instead of discontent about
old one.
people have been testing stuff and identified bugs. those bugs were fixed.
there are sure some more but we need wider exposure to identify those
new bugs and also clasify them.
the amount of people who are willing and able to checkout and test external
branch is minimal. I feel we are at the point where more exposure is
necessary.
by importing we are sending a strong signal to various 3rd
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 12:54:29PM +0200, Attilio Rao wrote: 2010/5/31 Kostik Belousov kostik...@gmail.com: On Mon, May 31, 2010 at 12:03:17AM -0600, Scott Long wrote: On May 30, 2010, at 7:58 AM, Kostik Belousov wrote: On Sat, May 29, 2010 at 03:02:40PM +0200, Roman Divacky wrote: hi, ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to import into HEAD in roughly a week. We would like the initial It was promised that before the import, the public discussion on the mailing list will happen. So far, nothing appeared on either arch@ or current@ providing argumentation why should we accept this. Sounds like you're inviting the discussion right now. ??I'll start =-) 1. I hate gcc with the burning heat of a million suns. It's not a tool, it's a political weapon wielded by the FSF and their acolytes. It's also a crummy piece of software that has been good enough for far too long. Its development model is a burden to work with and has been a major liability towards FreeBSD releases in the past. Its demise cannot happen soon enough. 2. Due to the political bent of the GPL3 and the FSF's insistence on shoving it down everyone's throats, FreeBSD is stuck with a dead-end version of gcc. This has already been a liability in terms of addressing bugs in gcc itself, and it will only get worse as technology moves forward and gcc stands still. 3. Clang/LLVM has an active development base and a clear future. It will move forward while gcc rots. There simply is no future left in gcc unless the FreeBSD project decides to embrace the GPL3, and that's a move that has already been heavily discussed, debated, and decided on. Anecdotally, I think that FreeBSD is benefiting from shunning the GPL3; it's made it an attractive option for companies looking for an unencumbered OS for their products. 4. While Clang is immature now, it will mature in the near future, and FreeBSD will benefit from that process. FreeBSD will get built-in access to upcoming technologies like GCD+Blocks and better code editors and development tools that gcc will never support. It'll break free of the development stranglehold that exists within gcc. Clang has shown good agility in adapting to the needs of FreeBSD and the legacy of gcc, thanks in large part to the efforts of people like Roman. Gcc has been nothing but drama and headache, even with the valiant efforts of people like Alexander Kabaev. 5. If all of this turns out to not be true and Clang/LLVM fails, FreeBSD has lost nothing and can remove it from the base system. Gcc remains where it is for now, at least until it's time for the remove gcc discussion. The future is !gcc. Putting Clang+LLVM into a position where it can be easily embraced by FreeBSD users will greatly benefit the FreeBSD project. Scott I do not object to a single point in your message. On the other hand, all said could be labeled as distilled propaganda. My main concern is the usefulness of HEAD for routine bug-fixing process. The proposed merge makes it relatively easy for users to start compiling the system with CLang. Our HEAD userbase is one of the most valuable project asset to ensure the quality of the system. After the support for easy compilation with clang is imported, some substantial portion of the HEAD users definitely start experimenting with it. This immediately makes the bug reports against HEAD almost useless, since level of demotivation when looking at the bug is immense. When you do know that the issue can be in the compiler, and not the OS, why looking ? Any bug analisys now shall start with exchange to verify which compiler was used to build the reporter system, and ask to reproduce it with gcc. [I am talking not only about gnats, but also mailing list questions, private pleas for help etc]. My personal opinion is that pushing the import now at the present state of clang makes a disservice to FreeBSD, and possible clang. Why not keep the glue on the branch as it is ? Motivated testers willing to help definitely can checkout from the branch. Import can happen when we are satisfied with the quality of new compiler, instead of discontent about old one. FWIW, I entirely agree with Kostik here. I really would like to see CLANG more integrated with FreeBSD only when there are 0 or similar (well-known, already analyzed, listed somewhere, etc.) bugs by the compiler rather than still being in the middle of a bug storm. Besides, the 'debugging problem' is pretty much real and nobody answered with a reasonable solution for it, and being honest, I don't see the people pushing for the import concerned about that at all. Are all the bug reports collected somewhere? What's the state of their resolution? There is a description somewhere of missing support and things still to be addressed? there are no known clang bugs
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
there are no known clang bugs (at least known to me) related to FreeBSD in other words - at this point you can compile FreeBSD with clang (both in the version in clangbsd) and it works (for people who tested it) on amd64 and i386 I don't mean about FreeBSD, but about CLANG itself. It would be very depressing to loose many hours on kernel races before to discover it was a compiler deficiency, for example. thats what I mean - we are not aware of any bugs in clang itself that harm FreeBSD (on i386/amd64). btw. there are 68 open bug reports against gcc 4.2.1 in gcc bugzilla. pgpCXTd7oxwJa.pgp Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
people are already experimenting with clang installed from ports,
with gcc4.{3,4,5} from ports etc. by not importing clang we can
maybe delay this a little but it's coming anyway.
I am pretty much fine and happy with people experimenting with clang
or any other compilers from ports, custom built, whatever. This is very
different from importing some compiler into base. See below about signal.
what I wanted to say is that we can get problem reports from people using
other compilers than our stock gcc even today.
Rather, I would consider the changes to ease the use of any external
compiler, from ports or whatever, bent into shape and kept up to date
with system progress very important, much less controversial and more
useful. Then, addicts of any kool-aid-compiler can drink their potion
without starting undesired relations. Unfortunately, this is not what
happen.
this is orthogonal to this. we as a project aim for delivering complete
operating system and we just need a system compiler. gcc4.2.1 just
cant serve us anymore, we need to do something now.
Please describe why gcc in base cannot serve us anymore while served up
to the minute I got your message.
that was summarized in a beautiful way by Scott Long :)
pgpH7p7tmULGb.pgp
Description: PGP signature
Re: Importing clang/LLVM into FreeBSD HEAD
On Mon, May 31, 2010 at 07:57:49AM -0700, Steve Kargl wrote: On Mon, May 31, 2010 at 09:52:48AM +0200, Roman Divacky wrote: Hi, I would like to propose to integrate clang/LLVM into FreeBSD HEAD in the near future (days, not weeks). clang/LLVM is a C/C++/ObjC compiler (framework) which aims to possibly replace gcc. It is BSDL-like licensed. The sources are ~45MB (the svn checkout is 97MB). Clang/LLVM is written in C++. Clang can compile all of FreeBSD on i386/amd64 including world and booting kernel. Other architectures that are close to working are MIPS, PowerPC and ARM. We have a branch (clangbsd-import) that just includes clang/LLVM sources and the build infrastructure and this is what we aim to integrate at first. The import of clang/LLVM was discussed at the toolchain summit May 10th but I would like to hear your opinion. I got approval from core@ on importing it. Can clang/LLVM build the livefs and bootonly CD's? well.. it can build a slightly modified FreeBSD. I have no idea whats the difference between plain FreeBSD world and livefs and bootonly CD the modifications to the FreeBSD are mostly bug fixes that clang reveals. pgp8R2yNoCeKq.pgp Description: PGP signature
Re: Importing clang/LLVM into FreeBSD HEAD
On Mon, May 31, 2010 at 09:14:09AM -0700, Bakul Shah wrote: On Mon, 31 May 2010 09:52:48 +0200 Roman Divacky rdiva...@freebsd.org wrote: I would like to propose to integrate clang/LLVM into FreeBSD HEAD in the near future (days, not weeks). clang/LLVM is a C/C++/ObjC compiler (framework) which aims to possibly replace gcc. It is BSDL-like licensed. The sources are ~45MB (the svn checkout is 97MB). Clang/LLVM is written in C++. Clang can compile all of FreeBSD on i386/amd64 including world and booting kernel. Other architectures that are close to working are MIPS, PowerPC and ARM. We have a branch (clangbsd-import) that just includes clang/LLVM sources and the build infrastructure and this is what we aim to integrate at first. The import of clang/LLVM was discussed at the toolchain summit May 10th but I would like to hear your opinion. I got approval from core@ on importing it. So please share your support or resistance to the idea of importing clang. Roman Divacky I already use clang for some things but I think the issue here is not support/resistance but something else: * IMHO for a change of this nature the core needs to publish a set of clear acceptance criteria for importing clang. Can this be done? I asked core@ and they support the import * Since clang doesn't support all the archs, what is the plan for unsupported archs? a. Is FreeBSD going to have both compilers in the base? yes, this is what this import is about - importing clang, nothing else changes b. Is the project drop these FreeBSD ports? or no, of course not c. Do people have to import gcc from ports to build these FreeBSD ports? nothing is being changed, just one more application after a buildworld/installworld appears (that being clang) * What about ports? * Basically the core needs to lay out a roadmap. It is clear that not everyone has the same view of what the acceptance criteria might be so publishing it would help people understand what to expect. nothing changes for the ports, there's an ongoing project to enable ports to be usable with clang (or some other compiler) but thats orthogonal to this. pgp3eugjwYjdB.pgp Description: PGP signature
[TESTING]: ClangBSD branch needs testing before the import to HEAD
hi,
ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to
import
into HEAD in roughly a week. We would like the initial import to be as painless
as possible and therefore we ask you to test ClangBSD to assure that the
revision
we are importing does not have some really embarassing bugs.
How to do it (on i386 and amd64):
0) install fresh devel/llvm-devel port
1) svn co http://svn.freebsd.org/base/projects/clangbsd src
2) echo NO_WERROR= /etc/src.conf ; echo WERROR= /etc/src.conf
3) cd src make buildworld
4) make installworld DESTDIR=/usr/clangbsd
5) (optional) try to build kernel with clang and boot it
5.1) cd /sys/{arch}/conf
5.2) config YOUR_KERNEL
5.3) setenv CC clang in tcsh or export CC=clang in bash
5.4) cd ../compile/YOUR_KERNEL
5.5) make make install
please make sure that it builds (on amd64/i386) and that the resulting world
is runnable. ie. try to chroot into it and do stuff. ie.
chroot /clangbsd /bin/tcsh
... stuff ...
there's a wiki page on this effort:
http://wiki.freebsd.org/BuildingFreeBSDWithClang
please report back any problems/success to me and/or this mailing list.
thank you for your testing!
Roman Divacky on behalf of the ClangBSD team
pgpUUIeD9DJPS.pgp
Description: PGP signature
Re: clangBSD build error on r208621
On Sat, May 29, 2010 at 11:31:52PM +0900, Norikatsu Shigemura wrote: Hi rdivacky. On Sat, 29 May 2010 02:17:41 +0900 Norikatsu Shigemura n...@freebsd.org wrote: error: unknown argument: '-ferror-limit' mkdep: compile failed Do you have any idea? Of cause I set following environment: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ cat /etc/src.conf NO_WERROR= WERROR= - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - OK, I got so that clang is too old. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ /usr/bin/clang --version clang version 1.5 (trunk) Target: x86_64-undermydesk-freebsd9.0 Thread model: posix - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - So I did use latest clang by installing devel/llvm-devel. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - $ /usr/local/bin/clang --version clang version 2.0 (trunk) Target: x86_64-portbld-freebsd9.0 Thread model: posix - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - I can compile to well-known error point. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - === sys/boot/i386/boot2 (all) dd if=/dev/zero of=boot2.ldr bs=512 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.27 secs (18837576 bytes/sec) /usr/local/bin/clang -isysroot /usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/lib/ -L/usr/obj/usr/src/tmp/usr/lib/ -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/boot2/../../common -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -std=gnu99 -c /usr/src/sys/boot/i386/boot2/sio.S clang: warning: the clang compiler does not support '-fno-unit-at-a-time' clang: warning: argument unused during compilation: '-L/usr/obj/usr/src/tmp/usr/lib/' clang: warning: argument unused during compilation: '-fno-guess-branch-probability' clang: warning: argument unused during compilation: '-mno-align-long-strings' clang: warning: argument unused during compilation: '-mrtd' clang: warning: argument unused during compilation: '--param max-inline-insns-single=100' clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=2' objcopy -S -O binary boot1.out boot1 /usr/local/bin/clang -isysroot /usr/obj/usr/src/tmp -B/usr/obj/usr/src/tmp/usr/lib/ -L/usr/obj/usr/src/tmp/usr/lib/ -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/boot2/../../common -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -m32 -march=i386 -std=gnu99 -S -o boot2.s.tmp /usr/src/sys/boot/i386/boot2/boot2.c clang: warning: the clang compiler does not support '-fno-unit-at-a-time' clang: warning: argument unused during compilation: '-L/usr/obj/usr/src/tmp/usr/lib/' clang: warning: argument unused during compilation: '-fno-guess-branch-probability' clang: warning: argument unused during compilation: '-mno-align-long-strings' clang: warning: argument unused during compilation: '-mrtd' clang: warning: argument unused during compilation: '--param max-inline-insns-single=100' clang: warning: argument unused during compilation: '-mpreferred-stack-boundary=2' /usr/src/sys/boot/i386/boot2/boot2.c:234:1: warning: no previous prototype for function 'main' [-Wmissing-prototypes] main(void) ^ 1 warning generated. sed -e '/align/d' -e '/nop/d' boot2.s.tmp boot2.s rm -f boot2.s.tmp as --32 -o boot2.o boot2.s ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /usr/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr
Re: clangBSD build error
On Fri, May 21, 2010 at 07:34:22PM -0700, ambrosehuang ambrose wrote: 2010/5/21 Roman Divacky rdiva...@freebsd.org On Thu, May 20, 2010 at 10:10:23PM +0800, ambrosehuang ambrose wrote: I found my clang version is : [r...@lateaxfreebsd src]# clang --version clang version 2.0 (trunk) Target: *x86_64-portbld-freebsd8.0* Thread model: posix svn revision is r10379_1 in PORTS I think maybe you can use the llvm-devel in PORTS to reproduce this I try to update clang to the latest version with make BOOTSTRAP=1 _CKSUMFILES=, but it seems the patch file confilcts with latest code? Could you tell me how to bypass the patching step ? there's no point in upgrading to newer clang. there were no change in this.. are you sure you are compiling with llvm-devel the malloc.c in clangbsd? not some older/newer version? I'm sure the llvm-devel is version r10379 in freebsd-stable branch. I also found that the both clang from llvm-devel and clang built from clangBSD building /usr/src.svn/src/lib/libc/stdlib/malloc.c(/usr/src.svn/src is the clangBSD directory in my box) failed with same error. maybe the version of clang in llvm-devel is too low, but the clang in clangBSD itself should be OK pes ~/clangbsd$ md5 lib/libc/stdlib/malloc.c MD5 (lib/libc/stdlib/malloc.c) = 312d85c5cf51aa3fa1ef46c0832f0056 can you compare to your malloc.c ? and if it differs can you send me your malloc.c ? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clangBSD build error
On Sat, May 22, 2010 at 10:26:57AM +0200, Roman Divacky wrote: On Fri, May 21, 2010 at 07:34:22PM -0700, ambrosehuang ambrose wrote: 2010/5/21 Roman Divacky rdiva...@freebsd.org On Thu, May 20, 2010 at 10:10:23PM +0800, ambrosehuang ambrose wrote: I found my clang version is : [r...@lateaxfreebsd src]# clang --version clang version 2.0 (trunk) Target: *x86_64-portbld-freebsd8.0* Thread model: posix svn revision is r10379_1 in PORTS I think maybe you can use the llvm-devel in PORTS to reproduce this I try to update clang to the latest version with make BOOTSTRAP=1 _CKSUMFILES=, but it seems the patch file confilcts with latest code? Could you tell me how to bypass the patching step ? there's no point in upgrading to newer clang. there were no change in this.. are you sure you are compiling with llvm-devel the malloc.c in clangbsd? not some older/newer version? I'm sure the llvm-devel is version r10379 in freebsd-stable branch. I also found that the both clang from llvm-devel and clang built from clangBSD building /usr/src.svn/src/lib/libc/stdlib/malloc.c(/usr/src.svn/src is the clangBSD directory in my box) failed with same error. maybe the version of clang in llvm-devel is too low, but the clang in clangBSD itself should be OK pes ~/clangbsd$ md5 lib/libc/stdlib/malloc.c MD5 (lib/libc/stdlib/malloc.c) = 312d85c5cf51aa3fa1ef46c0832f0056 can you compare to your malloc.c ? and if it differs can you send me your malloc.c ? I just tried with llvm-devel port and malloc.c from clangbsd and it works just ok. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clangBSD build error
I tried building clangbsd yesterday with clang/llvm r104146 and it worked ok. and it still does: pes ~/clangbsd$ clang --version clang version 2.0 (trunk 104146) Target: x86_64-unknown-freebsd8.0 Thread model: posix pes ~/clangbsd$ clang -c lib/libc/stdlib/malloc.c -I lib/libc/include/ -DMAXPAGESIZES=1 echo success lib/libc/stdlib/malloc.c:5408:12: warning: implicit declaration of function 'getpagesizes' is invalid in C99 [-Wimplicit-function-declaration] nsizes = getpagesizes(pagesizes, MAXPAGESIZES); ^ 1 warning generated. success can you retry with newer version? or show me how exactly to reproduce this? On Wed, May 19, 2010 at 11:46:37PM +0800, ambrosehuang ambrose wrote: building clangBSD revision URL: http://svn.freebsd.org/base/projects/clangbsd Repository Root: http://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 208300 Node Kind: directory Schedule: normal Last Changed Author: rdivacky Last Changed Rev: 208260 Last Changed Date: 2010-05-18 18:21:49 +0800 (Tue, 18 May 2010) with llvm-devel(r103179) on freebsd 8 stable amd64 according to clangBSD wiki failed with following message: make -j4 buildworld - ... /usr/src.svn/src/lib/libc/stdlib/malloc.c:1098:38: error: 'tls_model' attribute ignored static __thread arena_t *arenas_map TLS_MODEL; ^ /usr/src.svn/src/lib/libc/stdlib/malloc.c:240:37: note: instantiated from: # define TLS_MODEL __attribute__((tls_model(initial-exec))) ^ /usr/src.svn/src/lib/libc/stdlib/malloc.c:1103:38: error: 'tls_model' attribute ignored static __thread tcache_t *tcache_tls TLS_MODEL; ^ /usr/src.svn/src/lib/libc/stdlib/malloc.c:240:37: note: instantiated from: # define TLS_MODEL __attribute__((tls_model(initial-exec))) ^ /usr/src.svn/src/lib/libc/stdlib/malloc.c:1122:37: error: 'tls_model' attribute ignored static __thread bool mmap_unaligned TLS_MODEL; ^ /usr/src.svn/src/lib/libc/stdlib/malloc.c:240:37: note: instantiated from: # define TLS_MODEL __attribute__((tls_model(initial-exec))) -- it seems that clang does NOT support tls_model attribute, I'm not sure. Does anyone meet similar error ? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clangBSD build error
On Thu, May 20, 2010 at 05:39:09PM +0800, Vanilla Hsu wrote: I got such message since 2 weeks ago. -- /home/clangbsd/lib/libc/sys/stack_protector.c:88:19: error: format string is not a string literal (potentially insecure) [-Wformat-security] syslog(LOG_CRIT, msg); ^~~ 1 error generated. *** Error code 1 you have to have NO_WERROR= WERROR= in /etc/make.conf or /etc/src.conf ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clangBSD build error
On Thu, May 20, 2010 at 10:10:23PM +0800, ambrosehuang ambrose wrote: I found my clang version is : [r...@lateaxfreebsd src]# clang --version clang version 2.0 (trunk) Target: *x86_64-portbld-freebsd8.0* Thread model: posix svn revision is r10379_1 in PORTS I think maybe you can use the llvm-devel in PORTS to reproduce this I try to update clang to the latest version with make BOOTSTRAP=1 _CKSUMFILES=, but it seems the patch file confilcts with latest code? Could you tell me how to bypass the patching step ? there's no point in upgrading to newer clang. there were no change in this.. are you sure you are compiling with llvm-devel the malloc.c in clangbsd? not some older/newer version? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT]: ClangBSD is selfhosting, we need testers now - STATUS UPDATE
fwiw, it looks like it may make sense to have 2nd round of runtime testing :) these things were fixed in clangbsd that were reported as problems: 1) static binaries (eg. make) crash 2) kernel sound module miscompilation 3) bootloader problem which prevented clangbsd from booting 4) fix building when CC/CXX were set to cc/c++ 5) kernel printf modifiers semantic checking was implemented 6) i386 default cpu setting fix I know about these problems that are still not fixed 1) i386 is being miscompiled so clang built clang crashes this is being worked on, we have a test case and I believe Dmitry Andric (big kudos to him!) is about to submit a bug report to llvm 2) mergemaster problems - I have a fix but have not commited it yet 3) ruby crashes so, if you have one of the problems I listed as being fixed I'd like you to update clangbsd sources and rebuild the world to make sure that the problem you had was indeed fixed. If it wasn't, please report back to me. New testers are welcome too of course :) I am all ears about new problems as well. Please restrict your testing to amd64 as i386 is broken. You are free to test on ARM too as I am quite sure it works reasonably well there but noone tested it. thank you! Roman Divacky On Fri, Apr 16, 2010 at 06:08:18PM +0200, Roman Divacky wrote: Hi, ClangBSD is a branch of FreeBSD that aims at integrating clang (clang.llvm.org) into FreeBSD, replacing GCC as a system compiler. Recently, we've achieved the state when clang can compile all of FreeBSD world on i386/amd64 platforms (including all the C++ apps we have and itself) and a bootable kernel. Thus we feel that the time has come to ask the FreeBSD community for wider testing on i386/amd64 (you sure can help with other platforms too :)). How to setup ClangBSD: The default configuration of ClangBSD requires clang installed so you can either install fresh llvm-devel port (portinstall devel/llvm-devel) or change CC to gcc and CXX to g++ in share/mk/sys.mk. I recommend the former. svn co http://svn.freebsd.org/base/projects/clangbsd/ clangbsd cd clangbsd make buildworld echo NO_WERROR= /etc/make.conf echo WERROR= /etc/make.conf make DESTDIR=/clangbsd-chroot/ installworld now you have ClangBSD world installed and you can chroot into it. I don't recommend installing ClangBSD into real root as it is not tested enough. You can also start using clang compiled kernel - either build the kernel in the ClangBSD chroot (set NO_WERROR=yo and WERROR=yo in /etc/src.conf) or set CC to clang and build kernel the normal way. This information (and more) is also provided on: http://wiki.freebsd.org/BuildingFreeBSDWithClang We kindly ask you to setup ClangBSD chroot and/or use clang compiled kernel and use it as you would normally use FreeBSD. Please report back Thank you, Roman Divacky on behalf of the ClangBSD team pgpv3YTq5BadA.pgp Description: PGP signature
