Re: November 5th is Clang-Day
On 11/04/12 08:29, Dimitry Andric wrote: On 2012-11-04 14:18, Konstantin Belousov wrote: On Sun, Nov 04, 2012 at 02:42:13PM +0200, David Naylor wrote: ... I tried building (using gcc) wine with your patch and now (at least) winecfg and regedit work with a clang built lib32. I'll email Gerald (wine's maintainer) about including your patch in wine. The wine is the wrong place to fix. If system libraries suddenly started requiring 16-byte stack alignment on i386, it is unacceptable breakage of the ABI. So we really must use 4 byte stack alignment on i386 by default? I have attached a diff to llvm for this, but I would like to verify that it is really correct. Apparently Darwin, Linux and Solaris all use 16 byte alignment. The Sys V ABI seems to say only: "The stack is word aligned. Although the architecture does not require any alignment of the stack, software convention and the operating system requires that the stack be aligned on a word boundary". This is an ugly business. The stack is really 4 bytes aligned on Linux and Solaris too, but GCC decided to unilaterally change the ABI a few years ago (also on FreeBSD). You can find a chunk of the sordid story of this in a number of GCC bugs marked WONTFIX (e.g. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496). To pacify the people who were yelling about it, they added some __attribute__(()) foo and compiler flags to change what it uses for specific programs and add magic to realign the stack at boundaries. So much water has passed under the bridge at this point as to reach flood stage, so I think the correct solution here is to add the same __attribute__(()) and flags to clang rather than changing the default alignment back to 4. Changing it only on FreeBSD is especially wrong. -Nathan ___ 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
On Sun, Nov 04, 2012 at 03:29:42PM +0100, Dimitry Andric wrote: > On 2012-11-04 14:18, Konstantin Belousov wrote: > > On Sun, Nov 04, 2012 at 02:42:13PM +0200, David Naylor wrote: > ... > >> I tried building (using gcc) wine with your patch and now (at least) > >> winecfg > >> and regedit work with a clang built lib32. I'll email Gerald (wine's > >> maintainer) about including your patch in wine. > > > > The wine is the wrong place to fix. If system libraries suddenly started > > requiring 16-byte stack alignment on i386, it is unacceptable breakage > > of the ABI. > > So we really must use 4 byte stack alignment on i386 by default? I have > attached a diff to llvm for this, but I would like to verify that it is > really correct. Apparently Darwin, Linux and Solaris all use 16 byte > alignment. No, this is a misunderstanding. We must provide libraries that tolerate the 4-byte aligned stack. Also, to be compatible with broken compilers (both older versions of gcc and some versions of clang) we must provide the libraries which preserve the %esp mod 0x10 across the functions entry/leave points. The crt ensures that the stack is 16-byte aligned on entry to main. > > The Sys V ABI seems to say only: "The stack is word aligned. Although > the architecture does not require any alignment of the stack, software > convention and the operating system requires that the stack be aligned > on a word boundary". Right, this is ABI which some binaries follow. There are some other binaries, generated by arguably broken compilers, which require 16-byte alignment. The system shall support both. > Index: contrib/llvm/lib/Target/X86/X86Subtarget.cpp > === > --- contrib/llvm/lib/Target/X86/X86Subtarget.cpp (revision 242480) > +++ contrib/llvm/lib/Target/X86/X86Subtarget.cpp (working copy) > @@ -416,12 +416,12 @@ X86Subtarget::X86Subtarget(const std::string &TT, >assert((!In64BitMode || HasX86_64) && > "64-bit code requested on a subtarget that doesn't support it!"); > > - // Stack alignment is 16 bytes on Darwin, FreeBSD, Linux and Solaris (both > - // 32 and 64 bit) and for all 64-bit targets. > + // Stack alignment is 16 bytes on Darwin, Linux and Solaris (both 32 and 64 > + // bit) and for all 64-bit targets. >if (StackAlignOverride) > -stackAlignment = StackAlignOverride; > - else if (isTargetDarwin() || isTargetFreeBSD() || isTargetLinux() || > - isTargetSolaris() || In64BitMode) > + stackAlignment = StackAlignOverride; > + else if (isTargetDarwin() || isTargetLinux() || isTargetSolaris() || > + In64BitMode) > stackAlignment = 16; > } > pgpT25Yuwri50.pgp Description: PGP signature
Re: November 5th is Clang-Day
On 2012-11-04 14:18, Konstantin Belousov wrote: On Sun, Nov 04, 2012 at 02:42:13PM +0200, David Naylor wrote: ... I tried building (using gcc) wine with your patch and now (at least) winecfg and regedit work with a clang built lib32. I'll email Gerald (wine's maintainer) about including your patch in wine. The wine is the wrong place to fix. If system libraries suddenly started requiring 16-byte stack alignment on i386, it is unacceptable breakage of the ABI. So we really must use 4 byte stack alignment on i386 by default? I have attached a diff to llvm for this, but I would like to verify that it is really correct. Apparently Darwin, Linux and Solaris all use 16 byte alignment. The Sys V ABI seems to say only: "The stack is word aligned. Although the architecture does not require any alignment of the stack, software convention and the operating system requires that the stack be aligned on a word boundary". Index: contrib/llvm/lib/Target/X86/X86Subtarget.cpp === --- contrib/llvm/lib/Target/X86/X86Subtarget.cpp (revision 242480) +++ contrib/llvm/lib/Target/X86/X86Subtarget.cpp (working copy) @@ -416,12 +416,12 @@ X86Subtarget::X86Subtarget(const std::string &TT, assert((!In64BitMode || HasX86_64) && "64-bit code requested on a subtarget that doesn't support it!"); - // Stack alignment is 16 bytes on Darwin, FreeBSD, Linux and Solaris (both - // 32 and 64 bit) and for all 64-bit targets. + // Stack alignment is 16 bytes on Darwin, Linux and Solaris (both 32 and 64 + // bit) and for all 64-bit targets. if (StackAlignOverride) -stackAlignment = StackAlignOverride; - else if (isTargetDarwin() || isTargetFreeBSD() || isTargetLinux() || - isTargetSolaris() || In64BitMode) + stackAlignment = StackAlignOverride; + else if (isTargetDarwin() || isTargetLinux() || isTargetSolaris() || + In64BitMode) stackAlignment = 16; } ___ 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
On Sun, Nov 04, 2012 at 02:42:13PM +0200, David Naylor wrote: > On Saturday, 3 November 2012 23:47:54 Jan Beich wrote: > > David Naylor writes: > > > There are two issues here: 1) wine compiled with clang, and 2) wine > > > (compiled with gcc) running on clang compiled base. > > > > > > Regarding 1), according to the wiki [1], wine does have stack alignment > > > issues and some wine programs do not run when compiled with clang [2][3] > > > and other bugs with clang cause freezing within wine [4][5]. The > > > impression I get is that, using the work-a-round of stack realignment, > > > wine does work to some extent when compiled by clang. > > > > Took me some time but now I can confirm that clang-built wine-1.5.16 > > works fine for me with gcc-built lib32 (i.e. ld-elf32.so.1 + /usr/lib32). > > > > > Regarding 2) (which I believe Jan was referring to), when I have a gcc > > > built world and just replace lib32 with clang built libraries I have > > > winecfg and regedit launching but displaying black screens. Switching > > > back to gcc built lib32 I get a working winecfg and regedit. This, to > > > me, indicates a clang error somewhere. > > > > My experience varies between clang-built and gcc-built wine. > > > > # clang, quick crash > > > > # gcc, black rectangle > > > > So, why not switch stack alignment in wine (upstream)? This would make > > /stable/9 wine package continue to work on /head. > > > > Here's my wine package built with and without the patch. > > > > # sha256: cef5e543a5c534acb7237634224561863122ab3c256df319c6428856266d79fd > > http://ompldr.org/vZzR0bw/4byte-clang-wine-fbsd64-1.5.16,1.txz > > # sha256: 68e402bf7cb39ea48b9bef7772422cf476e89b214fd3b98ced37e0068f588c6c > > http://ompldr.org/vZzR0ZA/16byte-clang-wine-fbsd64-1.5.16,1.txz > > I tried building (using gcc) wine with your patch and now (at least) winecfg > and regedit work with a clang built lib32. I'll email Gerald (wine's > maintainer) about including your patch in wine. The wine is the wrong place to fix. If system libraries suddenly started requiring 16-byte stack alignment on i386, it is unacceptable breakage of the ABI. I tried to gather the evidence for the case, but apparent submitter of the bug stopped replying to the requests. pgp5HBA7jVYvc.pgp Description: PGP signature
Re: November 5th is Clang-Day
On Saturday, 3 November 2012 23:47:54 Jan Beich wrote: > David Naylor writes: > > There are two issues here: 1) wine compiled with clang, and 2) wine > > (compiled with gcc) running on clang compiled base. > > > > Regarding 1), according to the wiki [1], wine does have stack alignment > > issues and some wine programs do not run when compiled with clang [2][3] > > and other bugs with clang cause freezing within wine [4][5]. The > > impression I get is that, using the work-a-round of stack realignment, > > wine does work to some extent when compiled by clang. > > Took me some time but now I can confirm that clang-built wine-1.5.16 > works fine for me with gcc-built lib32 (i.e. ld-elf32.so.1 + /usr/lib32). > > > Regarding 2) (which I believe Jan was referring to), when I have a gcc > > built world and just replace lib32 with clang built libraries I have > > winecfg and regedit launching but displaying black screens. Switching > > back to gcc built lib32 I get a working winecfg and regedit. This, to > > me, indicates a clang error somewhere. > > My experience varies between clang-built and gcc-built wine. > > # clang, quick crash > > # gcc, black rectangle > > So, why not switch stack alignment in wine (upstream)? This would make > /stable/9 wine package continue to work on /head. > > Here's my wine package built with and without the patch. > > # sha256: cef5e543a5c534acb7237634224561863122ab3c256df319c6428856266d79fd > http://ompldr.org/vZzR0bw/4byte-clang-wine-fbsd64-1.5.16,1.txz > # sha256: 68e402bf7cb39ea48b9bef7772422cf476e89b214fd3b98ced37e0068f588c6c > http://ompldr.org/vZzR0ZA/16byte-clang-wine-fbsd64-1.5.16,1.txz I tried building (using gcc) wine with your patch and now (at least) winecfg and regedit work with a clang built lib32. I'll email Gerald (wine's maintainer) about including your patch in wine. regards signature.asc Description: This is a digitally signed message part.
Re: November 5th is Clang-Day
David Naylor writes:
> On Friday, 2 November 2012 10:13:30 David Chisnall wrote:
>
>> On 2 Nov 2012, at 05:24, Jan Beich wrote:
>> >> Known Issues
>> >
>> > emulators/wine doesn't work with lib32 built by clang, probably due to
>> > wine bugs.
>>
>> Is this still the case? There was an issue preventing WINE from working
>> because it required stricter stack alignment than clang provided by
>> default, but I thought it was fixed. Does WINE work if compiled with the
>> flag that forces stack realignment? If not, then it's some other issue...
>
> There are two issues here: 1) wine compiled with clang, and 2) wine (compiled
> with gcc) running on clang compiled base.
>
> Regarding 1), according to the wiki [1], wine does have stack alignment
> issues
> and some wine programs do not run when compiled with clang [2][3] and other
> bugs with clang cause freezing within wine [4][5]. The impression I get is
> that, using the work-a-round of stack realignment, wine does work to some
> extent when compiled by clang.
Took me some time but now I can confirm that clang-built wine-1.5.16
works fine for me with gcc-built lib32 (i.e. ld-elf32.so.1 + /usr/lib32).
> Regarding 2) (which I believe Jan was referring to), when I have a gcc built
> world and just replace lib32 with clang built libraries I have winecfg and
> regedit launching but displaying black screens. Switching back to gcc built
> lib32 I get a working winecfg and regedit. This, to me, indicates a clang
> error somewhere.
My experience varies between clang-built and gcc-built wine.
# clang, quick crash
$ winecfg
err:seh:raise_exception Unhandled exception code c005 flags 0 addr
0x622975ab
err:seh:raise_exception Unhandled exception code c005 flags 0 addr
0x622975ab
err:seh:raise_exception Unhandled exception code c005 flags 0 addr
0x622975ab
Exit 5
# gcc, black rectangle
$ winecfg
err:seh:raise_exception Unhandled exception code c005 flags 0 addr
0x622995ab
err:service:service_send_start_message service L"MountMgr" failed to start
fixme:service:scmdatabase_autostart_services Auto-start service L"MountMgr"
failed to start: 1053
err:seh:raise_exception Unhandled exception code c005 flags 0 addr
0x622995ab
err:service:service_send_start_message service L"PlugPlay" failed to start
fixme:service:scmdatabase_autostart_services Auto-start service L"PlugPlay"
failed to start: 1053
err:seh:raise_exception Unhandled exception code c005 flags 0 addr
0x622995ab
err:seh:raise_exception Unhandled exception code c005 flags 0 addr
0x622995ab
load: 0.89 cmd: wine 14626 [piperd] 7.49r 0.03u 0.01s 0% 8932k
So, why not switch stack alignment in wine (upstream)? This would make
/stable/9 wine package continue to work on /head.
Here's my wine package built with and without the patch.
# sha256: cef5e543a5c534acb7237634224561863122ab3c256df319c6428856266d79fd
http://ompldr.org/vZzR0bw/4byte-clang-wine-fbsd64-1.5.16,1.txz
# sha256: 68e402bf7cb39ea48b9bef7772422cf476e89b214fd3b98ced37e0068f588c6c
http://ompldr.org/vZzR0ZA/16byte-clang-wine-fbsd64-1.5.16,1.txz
# include, winegcc: Switch to 16-byte aligned stack on FreeBSD.
#
# We cannot use __clang__ or __FreeBSD_version in order to stay
# compatible where a package built for FreeBSD X also works on
# FreeBSD X+1.
--- include/windef.h~
+++ include/windef.h
@@ -53,7 +53,8 @@ extern "C" {
#ifndef __stdcall
# ifdef __i386__
# ifdef __GNUC__
-# ifdef __APPLE__ /* Mac OS X uses a 16-byte aligned stack and not a 4-byte one */
+/* Mac OS X and FreeBSD 10 use a 16-byte aligned stack and not a 4-byte one */
+# if defined(__APPLE__) || defined(__FreeBSD__)
#define __stdcall __attribute__((__stdcall__)) __attribute__((__force_align_arg_pointer__))
# else
#define __stdcall __attribute__((__stdcall__))
--- include/msvcrt/crtdefs.h~
+++ include/msvcrt/crtdefs.h
@@ -44,7 +44,8 @@
#ifndef __stdcall
# ifdef __i386__
# ifdef __GNUC__
-# ifdef __APPLE__ /* Mac OS X uses a 16-byte aligned stack and not a 4-byte one */
+/* Mac OS X and FreeBSD 10 use a 16-byte aligned stack and not a 4-byte one */
+# if defined(__APPLE__) || defined(__FreeBSD__)
#define __stdcall __attribute__((__stdcall__)) __attribute__((__force_align_arg_pointer__))
# else
#define __stdcall __attribute__((__stdcall__))
--- tools/winegcc/utils.h~
+++ tools/winegcc/utils.h
@@ -42,7 +42,7 @@ enum target_cpu
enum target_platform
{
-PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_SOLARIS, PLATFORM_WINDOWS, PLATFORM_CYGWIN
+PLATFORM_UNSPECIFIED, PLATFORM_APPLE, PLATFORM_FREEBSD, PLATFORM_SOLARIS, PLATFORM_WINDOWS, PLATFORM_CYGWIN
};
void error(const char* s, ...) DECLSPEC_NORETURN;
--- tools/winegcc/winegcc.c~
+++ tools/winegcc/winegcc.c
@@ -171,6 +171,7 @@ static const struct
{
{ "macos", PLATFORM_APPLE },
{ "darwin", PLATFORM_APPLE },
+{ "freebsd", PLATFORM_FREEBSD },
{ "solaris", PLATFORM_SOLARIS },
{ "
Re: November 5th is Clang-Day
On Friday, 2 November 2012 10:13:30 David Chisnall wrote: > On 2 Nov 2012, at 05:24, Jan Beich wrote: > >> Known Issues > > > > emulators/wine doesn't work with lib32 built by clang, probably due to > > wine bugs. > > Is this still the case? There was an issue preventing WINE from working > because it required stricter stack alignment than clang provided by > default, but I thought it was fixed. Does WINE work if compiled with the > flag that forces stack realignment? If not, then it's some other issue... There are two issues here: 1) wine compiled with clang, and 2) wine (compiled with gcc) running on clang compiled base. Regarding 1), according to the wiki [1], wine does have stack alignment issues and some wine programs do not run when compiled with clang [2][3] and other bugs with clang cause freezing within wine [4][5]. The impression I get is that, using the work-a-round of stack realignment, wine does work to some extent when compiled by clang. Regarding 2) (which I believe Jan was referring to), when I have a gcc built world and just replace lib32 with clang built libraries I have winecfg and regedit launching but displaying black screens. Switching back to gcc built lib32 I get a working winecfg and regedit. This, to me, indicates a clang error somewhere. The test was done on FreeBSD 9-Stable with: # clang --version FreeBSD clang version 3.1 (branches/release_31 156863) 20120523 Target: x86_64-unknown-freebsd9.0 Thread model: posix Regards [1] wiki.winehq.org/Clang [2] (regedit) http://llvm.org/bugs/show_bug.cgi?id=9830 [3] (wineboot) http://llvm.org/bugs/show_bug.cgi?id=9844 [4] http://llvm.org/bugs/show_bug.cgi?id=9704 [5] http://llvm.org/bugs/show_bug.cgi?id=9707 signature.asc Description: This is a digitally signed message part.
Re: November 5th is Clang-Day
On Thu, Nov 1, 2012 at 10:05 PM, Garrett Cooper wrote: > On Thu, Nov 1, 2012 at 9:59 PM, Steve Kargl > wrote: > > On Thu, Nov 01, 2012 at 10:29:45PM -0500, Brooks Davis wrote: > >> - 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. > > > > Is there a knob to continue to use GCC as the default compiler? > > Just specify CLANG_IS_CC=no in /etc/src.conf . > Correcting myself for the posterity's sake: WITHOUT_CLANG_IS_CC=, not CLANG_IS_CC=no Thanks, -Garrett ___ 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
On 2 November 2012 12:23, Brooks Davis wrote: > On Fri, Nov 02, 2012 at 04:30:50PM +0100, Roman Divacky wrote: >> Nice :) >> >> Does this deserve mentioning in UPDATING and/or version bump? > > It certainly does deserve mention in UPDATING. A version bump is > probably useful if we end up wanting to make USE_GCC=any the default > post the switch so I will do both. Thank you. -- Eitan Adler ___ 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
On Fri, Nov 02, 2012 at 04:30:50PM +0100, Roman Divacky wrote:
> Nice :)
>
> Does this deserve mentioning in UPDATING and/or version bump?
It certainly does deserve mention in UPDATING. A version bump is
probably useful if we end up wanting to make USE_GCC=any the default
post the switch so I will do both.
-- Brooks
>
> 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
>
>
pgpScvg2EgAHy.pgp
Description: PGP signature
Re: November 5th is Clang-Day
On Thu, Nov 01, 2012 at 09:59:17PM -0700, Steve Kargl wrote: > On Thu, Nov 01, 2012 at 10:29:45PM -0500, Brooks Davis wrote: > > - 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. > > Is there a knob to continue to use GCC as the default compiler? As someone else stated, WITHOUT_CLANG_IS_CC will do it. > The above statement is somewhat troubling to those of us > who use FreeBSD as computational nodes. I really need reduced test cases. I'll I've been able to find so far has been issues with exception states when NaNs are used and I've not had time to reduce them to something small. Unfortunately the design decision to use asserts in the test suite makes it a pain to dig to assess more than one failure at once. > BTW, the name of the language is "Fortran". It's been "Fortran" > for the last 30-something years. Tell that to aspell's dictionary. :) I'd capitalized it correctly and it wanted to change it. -- Brooks pgpRqt1mrBnCN.pgp Description: PGP signature
Re: November 5th is Clang-Day
On 11/2/2012 8:30 AM, Roman Divacky wrote: Nice :) Does this deserve mentioning in UPDATING and/or version bump? I would think so. ___ 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: November 5th is Clang-Day
Den 02/11/2012 kl. 04.29 skrev Brooks Davis : > 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. Congratulations! I know that you and others of the Clang BSD have worked hard for years on this, so it's nice to see the work finally paying off. Erik ___ 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
On 11/02/12 04:29, 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. > [...] Then the hell break loose ... ;-) signature.asc Description: OpenPGP digital signature
Re: November 5th is Clang-Day
On 2 Nov 2012, at 05:24, Jan Beich wrote: >> Known Issues > > emulators/wine doesn't work with lib32 built by clang, probably due to > wine bugs. Is this still the case? There was an issue preventing WINE from working because it required stricter stack alignment than clang provided by default, but I thought it was fixed. Does WINE work if compiled with the flag that forces stack realignment? If not, then it's some other issue... David ___ 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
On Thu, Nov 01, 2012 at 10:31:26PM -0700, Garrett Cooper wrote: > On Thu, Nov 1, 2012 at 10:24 PM, Jan Beich wrote: > > emulators/wine doesn't work with lib32 built by clang, probably due to > > wine bugs. > > All of these items should be catalogued in a common place, like the > wiki. I've added http://wiki.freebsd.org/PortsAndClang#Runtime_failures . I'll be happy to add entries for anyone who does not have wiki edit credentials. (Please email me off-list.) mcl ___ 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
On Fri, Nov 02, 2012 at 12:21:03PM +0700, Erich Dollansky wrote: > Hi, > > On Thu, 1 Nov 2012 21:59:17 -0700 > Steve Kargl wrote: > > > On Thu, Nov 01, 2012 at 10:29:45PM -0500, Brooks Davis wrote: > > > - 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. > > > > Is there a knob to continue to use GCC as the default compiler? > > > > The above statement is somewhat troubling to those of us > > who use FreeBSD as computational nodes. > > > > BTW, the name of the language is "Fortran". It's been "Fortran" > > for the last 30-something years. > > I never realised the name change. It seems that I am not alone with > this. > Many people, who see the word Fortran or FORTRAN, think of Fortran 77 (X3J3/90.4, ISO 1539:1980). Since then there have been several revisions to the language. The revisions are Fortran 90, ISO/IEC 1539:1991 Fortran 95, ISO/IEC 1539-1:1997 Fortran 2003, ISO/IEC 1539-1:2004(E) Fortran 2008, ISO/IEC 1539-1:2010 and J3 is currently working on the next revision. You can find committee drafts of these standards via the gfortran wiki. -- 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"
Re: November 5th is Clang-Day
On Thu, Nov 1, 2012 at 10:24 PM, Jan Beich wrote: > Brooks Davis writes: > >> Known Issues > > emulators/wine doesn't work with lib32 built by clang, probably due to > wine bugs. All of these items should be catalogued in a common place, like the wiki. Most of the problems will become apparent once tinderbox gets going with the new code, but it doesn't hurt to spearhead this effort. -Garrett ___ 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
Brooks Davis writes: > Known Issues emulators/wine doesn't work with lib32 built by clang, probably due to wine bugs. ___ 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
Hi, On Thu, 1 Nov 2012 21:59:17 -0700 Steve Kargl wrote: > On Thu, Nov 01, 2012 at 10:29:45PM -0500, Brooks Davis wrote: > > - 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. > > Is there a knob to continue to use GCC as the default compiler? > > The above statement is somewhat troubling to those of us > who use FreeBSD as computational nodes. > > BTW, the name of the language is "Fortran". It's been "Fortran" > for the last 30-something years. I never realised the name change. It seems that I am not alone with this. Erich ___ 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
On Thu, Nov 1, 2012 at 9:59 PM, Steve Kargl wrote: > On Thu, Nov 01, 2012 at 10:29:45PM -0500, Brooks Davis wrote: >> - 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. > > Is there a knob to continue to use GCC as the default compiler? Just specify CLANG_IS_CC=no in /etc/src.conf . HTH, -Garrett ___ 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
On Thu, Nov 01, 2012 at 10:29:45PM -0500, Brooks Davis wrote: > - 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. Is there a knob to continue to use GCC as the default compiler? The above statement is somewhat troubling to those of us who use FreeBSD as computational nodes. BTW, the name of the language is "Fortran". It's been "Fortran" for the last 30-something years. -- 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"
