Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
November 5th is Clang-Day
6 views
Skip to first unread message
Brooks Davis
Nov 1, 2012, 11:29:45 PM11/1/12
to
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
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
Steve Kargl
Nov 2, 2012, 12:59:17 AM11/2/12
to
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?
> - 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.
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...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Garrett Cooper
Nov 2, 2012, 1:05:23 AM11/2/12
to
On Thu, Nov 1, 2012 at 9:59 PM, Steve Kargl
<s...@troutmask.apl.washington.edu> 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 .
<s...@troutmask.apl.washington.edu> 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?
HTH,
-Garrett
Erich Dollansky
Nov 2, 2012, 1:21:03 AM11/2/12
to
Hi,
On Thu, 1 Nov 2012 21:59:17 -0700
this.
Erich
On Thu, 1 Nov 2012 21:59:17 -0700
Steve Kargl <s...@troutmask.apl.washington.edu> 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?
>
> 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
> who use FreeBSD as computational nodes.
>
> BTW, the name of the language is "Fortran". It's been "Fortran"
> for the last 30-something years.
this.
Erich
Jan Beich
Nov 2, 2012, 1:24:55 AM11/2/12
to
Brooks Davis <bro...@freebsd.org> writes:
> Known Issues
emulators/wine doesn't work with lib32 built by clang, probably due to
wine bugs.
> Known Issues
emulators/wine doesn't work with lib32 built by clang, probably due to
wine bugs.
Garrett Cooper
Nov 2, 2012, 1:31:26 AM11/2/12
to
On Thu, Nov 1, 2012 at 10:24 PM, Jan Beich <jbe...@tormail.org> wrote:
> Brooks Davis <bro...@freebsd.org> 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
> Brooks Davis <bro...@freebsd.org> writes:
>
>> Known Issues
>
> emulators/wine doesn't work with lib32 built by clang, probably due to
> wine bugs.
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
Steve Kargl
Nov 2, 2012, 1:50:33 AM11/2/12
to
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 <s...@troutmask.apl.washington.edu> 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
> Hi,
>
> On Thu, 1 Nov 2012 21:59:17 -0700
> Steve Kargl <s...@troutmask.apl.washington.edu> 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.
>
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
Greg 'groggy' Lehey
Nov 2, 2012, 2:08:18 AM11/2/12
to
On Friday, 2 November 2012 at 12:21:03 +0700, Erich Dollansky wrote:
> Hi,
>
> On Thu, 1 Nov 2012 21:59:17 -0700
> Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
>>
>> 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.
Nor I. Looking at the Wikipedia page, I discover that it had been
> Hi,
>
> On Thu, 1 Nov 2012 21:59:17 -0700
> Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
>>
>> 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.
spelt "Fortran" as early as 1956, and there's even a copy of the 1956
Fortran manual online: http://www.fortran.com/FortranForTheIBM704.pdf
Interesting reading.
Greg
--
Sent from my desktop computer.
Finger gr...@FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua
Mark Linimon
Nov 2, 2012, 2:27:52 AM11/2/12
to
On Thu, Nov 01, 2012 at 10:31:26PM -0700, Garrett Cooper wrote:
> On Thu, Nov 1, 2012 at 10:24 PM, Jan Beich <jbe...@tormail.org> 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 .
> On Thu, Nov 1, 2012 at 10:24 PM, Jan Beich <jbe...@tormail.org> 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'll be happy to add entries for anyone who does not have wiki edit
credentials. (Please email me off-list.)
mcl
David Chisnall
Nov 2, 2012, 4:13:30 AM11/2/12
to
On 2 Nov 2012, at 05:24, Jan Beich wrote:
>> Known Issues
David
>> 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...
> emulators/wine doesn't work with lib32 built by clang, probably due to
> wine bugs.
David
Mehmet Erol Sanliturk
Nov 2, 2012, 4:18:23 AM11/2/12
to
remember the name of the writer , who wrote approximately :
"In 2010 , there will be Fortran , but a Fortran which may be different ."
Now , perhaps unfortunately , there is no any language better than Fortran
for the Fortran suitable problems .
Thank you very much .
Mehmet Erol Sanliturk
David Chisnall
Nov 2, 2012, 4:25:58 AM11/2/12
to
On 2 Nov 2012, at 08:18, Mehmet Erol Sanliturk wrote:
> Very many years ago , when 2010 was a very distant future , I do not
> remember the name of the writer , who wrote approximately :
>
> "In 2010 , there will be Fortran , but a Fortran which may be different ."
I remember a talk in the mid '90s by someone from Sun's HPC team where he said 'I don't know what the syntax or semantics of the language we will be using for HPC in 20 years time will be, but I do know one thing about it: it will be called Fortran'
> Very many years ago , when 2010 was a very distant future , I do not
> remember the name of the writer , who wrote approximately :
>
> "In 2010 , there will be Fortran , but a Fortran which may be different ."
Although the response to GCC's recent decision to drop support for Fortran 77 showed that that language will probably be called Fortran 77...
David
Anton Shterenlikht
Nov 2, 2012, 6:21:19 AM11/2/12
to
Date: Fri, 2 Nov 2012 17:08:18 +1100
From: "Greg 'groggy' Lehey" <gr...@freebsd.org>
To: Erich Dollansky <erichfre...@ovitrap.com>
Subject: FORTRAN vs. Fortran (was: November 5th is Clang-Day)
On Friday, 2 November 2012 at 12:21:03 +0700, Erich Dollansky wrote:
> Hi,
>
> On Thu, 1 Nov 2012 21:59:17 -0700
> Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
>>
>> 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.
Nor I. Looking at the Wikipedia page, I discover that it had been
spelt "Fortran" as early as 1956, and there's even a copy of the 1956
Fortran manual online: http://www.fortran.com/FortranForTheIBM704.pdf
Interesting reading.
come on guys, fortran is not case sensitive...
Anyway I guess it's good news that LLVM
is being used also by Cray and Nvidia.
It's a shame though that, with LLVM as the
default compiler, further development of
FreeBSD/ia64 and FreeBSD/sparc64
will probably suffer and then stop altogether.
Anton
From: "Greg 'groggy' Lehey" <gr...@freebsd.org>
To: Erich Dollansky <erichfre...@ovitrap.com>
Subject: FORTRAN vs. Fortran (was: November 5th is Clang-Day)
On Friday, 2 November 2012 at 12:21:03 +0700, Erich Dollansky wrote:
> Hi,
>
> On Thu, 1 Nov 2012 21:59:17 -0700
> Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
>>
>> 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.
Nor I. Looking at the Wikipedia page, I discover that it had been
spelt "Fortran" as early as 1956, and there's even a copy of the 1956
Fortran manual online: http://www.fortran.com/FortranForTheIBM704.pdf
Interesting reading.
Anyway I guess it's good news that LLVM
is being used also by Cray and Nvidia.
It's a shame though that, with LLVM as the
default compiler, further development of
FreeBSD/ia64 and FreeBSD/sparc64
will probably suffer and then stop altogether.
Anton
Anton Shterenlikht
Nov 2, 2012, 6:57:54 AM11/2/12
to
From ther...@theravensnest.org Fri Nov 2 10:54:08 2012
attention but would be relatively easy to get up to
production quality if anyone cared.
The IA64 back end bitrotted and died,
although there's now a bit better generic infrastructure
for VLIW architectures (contributed by Qualcomm
for the Hexagon DSP), so resurrecting it is possible,
but I doubt anyone cares because Itanium is basically dead.
Oracle seems intent on mismanaging SPARC to death too,
so I'm not sure how long it will be around either.
I'd be happy to help anyone who is interested in resurrecting either of these,
marcel@ was working on LLVM backend for ia64.
On 2 Nov 2012, at 10:21, Anton Shterenlikht wrote:
> further development of
> FreeBSD/ia64 and FreeBSD/sparc64
> will probably suffer and then stop altogether
There is a SPARC64 back end for LLVM that needs some
> further development of
> FreeBSD/ia64 and FreeBSD/sparc64
> will probably suffer and then stop altogether
attention but would be relatively easy to get up to
production quality if anyone cared.
The IA64 back end bitrotted and died,
although there's now a bit better generic infrastructure
for VLIW architectures (contributed by Qualcomm
for the Hexagon DSP), so resurrecting it is possible,
but I doubt anyone cares because Itanium is basically dead.
Oracle seems intent on mismanaging SPARC to death too,
so I'm not sure how long it will be around either.
I'd be happy to help anyone who is interested in resurrecting either of these,
marcel@ was working on LLVM backend for ia64.
O. Hartmann
Nov 2, 2012, 8:37:49 AM11/2/12
to
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.
>
[...]
> 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 ... ;-)
Stephen Montgomery-Smith
Nov 2, 2012, 8:27:44 AM11/2/12
to
On 11/02/2012 05:21 AM, Anton Shterenlikht wrote:
> Date: Fri, 2 Nov 2012 17:08:18 +1100
> From: "Greg 'groggy' Lehey" <gr...@freebsd.org>
> To: Erich Dollansky <erichfre...@ovitrap.com>
> Subject: FORTRAN vs. Fortran (was: November 5th is Clang-Day)
>
> On Friday, 2 November 2012 at 12:21:03 +0700, Erich Dollansky wrote:
> > Hi,
> >
> > On Thu, 1 Nov 2012 21:59:17 -0700
> > Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
> >>
> >> 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.
>
> Nor I. Looking at the Wikipedia page, I discover that it had been
> spelt "Fortran" as early as 1956, and there's even a copy of the 1956
> Fortran manual online: http://www.fortran.com/FortranForTheIBM704.pdf
> Interesting reading.
>
> come on guys, fortran is not case sensitive...
caNyO usti llputw hitespa cewhere ever you like in for TraN?
> Date: Fri, 2 Nov 2012 17:08:18 +1100
> From: "Greg 'groggy' Lehey" <gr...@freebsd.org>
> To: Erich Dollansky <erichfre...@ovitrap.com>
> Subject: FORTRAN vs. Fortran (was: November 5th is Clang-Day)
>
> On Friday, 2 November 2012 at 12:21:03 +0700, Erich Dollansky wrote:
> > Hi,
> >
> > On Thu, 1 Nov 2012 21:59:17 -0700
> > Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
> >>
> >> 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.
>
> Nor I. Looking at the Wikipedia page, I discover that it had been
> spelt "Fortran" as early as 1956, and there's even a copy of the 1956
> Fortran manual online: http://www.fortran.com/FortranForTheIBM704.pdf
> Interesting reading.
>
> come on guys, fortran is not case sensitive...
Steve Kargl
Nov 2, 2012, 9:07:04 AM11/2/12
to
On Fri, Nov 02, 2012 at 08:25:58AM +0000, David Chisnall wrote:
> On 2 Nov 2012, at 08:18, Mehmet Erol Sanliturk wrote:
>
> > Very many years ago , when 2010 was a very distant future , I do not
> > remember the name of the writer , who wrote approximately :
> >
> > "In 2010 , there will be Fortran , but a Fortran which may be different ."
>
> I remember a talk in the mid '90s by someone from Sun's HPC team
> where he said 'I don't know what the syntax or semantics of the
> language we will be using for HPC in 20 years time will be, but
> I do know one thing about it: it will be called Fortran'
>
> Although the response to GCC's recent decision to drop support
> for Fortran 77 showed that that language will probably be called Fortran 77...
>
GCC did not drop Fortran 77. When GCC moved from the 3.x series
> On 2 Nov 2012, at 08:18, Mehmet Erol Sanliturk wrote:
>
> > Very many years ago , when 2010 was a very distant future , I do not
> > remember the name of the writer , who wrote approximately :
> >
> > "In 2010 , there will be Fortran , but a Fortran which may be different ."
>
> I remember a talk in the mid '90s by someone from Sun's HPC team
> where he said 'I don't know what the syntax or semantics of the
> language we will be using for HPC in 20 years time will be, but
> I do know one thing about it: it will be called Fortran'
>
> Although the response to GCC's recent decision to drop support
> for Fortran 77 showed that that language will probably be called Fortran 77...
>
to the 4.x series, it introduced the use of gimple and tree-ssa.
No one ported g77 to use gimple and tree-ssa, so g77 was replaced
by a completely new frontend, which is called gfortran and started
life as a Fortran 95 compiler. One admirable objective of J3, the
Fortran standardization committee, is that it strives for backwards
compatibility to previous standards. So, if you have a valid
Fortran 77 code, it will in all likelihood be a validate Fortran
2008 program. Fortran 95 deleted 10 features from the language;
however, every compiler that I've used still supports those features.
In regards to HPC and Fortran, Fortran 2008 introduced this wonderful
feature called co-arrays. One can read about gfortran's progress with
its implementation of co-arrays at http://gcc.gnu.org/wiki/Coarray
--
Steve
Steve Kargl
Nov 2, 2012, 9:17:42 AM11/2/12
to
On Fri, Nov 02, 2012 at 07:27:44AM -0500, Stephen Montgomery-Smith wrote:
>
> caNyO usti llputw hitespa cewhere ever you like in for TraN?
>
Sigh. You can get copies of the final committee drafts of
>
> caNyO usti llputw hitespa cewhere ever you like in for TraN?
>
the Fortran 95, 2003, and 2008 standards. There you will
learn that Fortran since Fortran 90 allows two source forms:
fixed-form and free-form source code. When parsing the
the above nonsense you wrote, one form would yield one (invalid)
token, and in the other form it would yield 11 tokens.
Erik Cederstrand
Nov 2, 2012, 9:36:26 AM11/2/12
to
Den 02/11/2012 kl. 04.29 skrev Brooks Davis <bro...@freebsd.org>:
> 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.
> 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.
Erik
Roman Divacky
Nov 2, 2012, 11:30:50 AM11/2/12
to
Nice :)
Does this deserve mentioning in UPDATING and/or version bump?
On Thu, Nov 01, 2012 at 10:29:45PM -0500, Brooks Davis wrote:
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
> 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.
>
> 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 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.
> 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.
Matthew Jacob
Nov 2, 2012, 11:54:07 AM11/2/12
to
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.
> Nice :)
>
> Does this deserve mentioning in UPDATING and/or version bump?
Brooks Davis
Nov 2, 2012, 12:19:16 PM11/2/12
to
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.
>
> 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.
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.
it wanted to change it.
-- Brooks
Brooks Davis
Nov 2, 2012, 12:21:10 PM11/2/12
to
On Fri, Nov 02, 2012 at 10:21:19AM +0000, Anton Shterenlikht wrote:
> Date: Fri, 2 Nov 2012 17:08:18 +1100
> From: "Greg 'groggy' Lehey" <gr...@freebsd.org>
> To: Erich Dollansky <erichfre...@ovitrap.com>
> Subject: FORTRAN vs. Fortran (was: November 5th is Clang-Day)
>
> On Friday, 2 November 2012 at 12:21:03 +0700, Erich Dollansky wrote:
> > Hi,
> >
> > On Thu, 1 Nov 2012 21:59:17 -0700
> > Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
> >>
> Date: Fri, 2 Nov 2012 17:08:18 +1100
> From: "Greg 'groggy' Lehey" <gr...@freebsd.org>
> To: Erich Dollansky <erichfre...@ovitrap.com>
> Subject: FORTRAN vs. Fortran (was: November 5th is Clang-Day)
>
> On Friday, 2 November 2012 at 12:21:03 +0700, Erich Dollansky wrote:
> > Hi,
> >
> > On Thu, 1 Nov 2012 21:59:17 -0700
> > Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
> >>
> >> BTW, the name of the language is "Fortran". It's been "Fortran"
> >> for the last 30-something years.
> >
> >> for the last 30-something years.
> >
> > I never realised the name change. It seems that I am not alone with
> > this.
>
> Nor I. Looking at the Wikipedia page, I discover that it had been
> spelt "Fortran" as early as 1956, and there's even a copy of the 1956
> Fortran manual online: http://www.fortran.com/FortranForTheIBM704.pdf
> Interesting reading.
>
> come on guys, fortran is not case sensitive...
>
> > this.
>
> Nor I. Looking at the Wikipedia page, I discover that it had been
> spelt "Fortran" as early as 1956, and there's even a copy of the 1956
> Fortran manual online: http://www.fortran.com/FortranForTheIBM704.pdf
> Interesting reading.
>
> come on guys, fortran is not case sensitive...
>
> Anyway I guess it's good news that LLVM
> is being used also by Cray and Nvidia.
> It's a shame though that, with LLVM as the
> default compiler, further development of
> is being used also by Cray and Nvidia.
> It's a shame though that, with LLVM as the
> FreeBSD/ia64 and FreeBSD/sparc64
> will probably suffer and then stop altogether.
If you read either my annoucment or the diff closly you will note that
the default it only changing for x86 architectures.
-- Brooks
Brooks Davis
Nov 2, 2012, 12:23:47 PM11/2/12
to
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
> Nice :)
>
> Does this deserve mentioning in UPDATING and/or version bump?
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]
> > 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.
> > 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.
Eitan Adler
Nov 2, 2012, 12:37:54 PM11/2/12
to
On 2 November 2012 12:23, Brooks Davis <bro...@freebsd.org> 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.
> 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.
--
Eitan Adler
Garrett Cooper
Nov 2, 2012, 1:18:38 PM11/2/12
to
On Thu, Nov 1, 2012 at 10:05 PM, Garrett Cooper <yane...@gmail.com> wrote:
> On Thu, Nov 1, 2012 at 9:59 PM, Steve Kargl
> <s...@troutmask.apl.washington.edu> wrote:
> On Thu, Nov 1, 2012 at 9:59 PM, Steve Kargl
> <s...@troutmask.apl.washington.edu> 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.
> >
> >> - 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
David Naylor
Nov 3, 2012, 3:48:40 AM11/3/12
to
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
> 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...
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
Peter Jeremy
Nov 3, 2012, 3:50:29 AM11/3/12
to
cover the bulk of the user and developer mass) migrate to a different
toolchain, the risk of bitrot in the GNU toolchain decomes non-negligible.
And once it breaks, there may not be the critical mass to repair it.
This is basically what happened to the Alpha.
--
Peter Jeremy
Jan Beich
Nov 3, 2012, 5:47:54 PM11/3/12
to
David Naylor <naylor....@gmail.com> 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
> 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.
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.
# clang, quick crash
$ winecfg
err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0x622975ab
err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0x622975ab
err:seh:raise_exception Unhandled exception code c0000005 flags 0 addr 0x622975ab
Exit 5
# gcc, black rectangle
$ winecfg
err:seh:raise_exception Unhandled exception code c0000005 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 c0000005 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 c0000005 flags 0 addr 0x622995ab
err:seh:raise_exception Unhandled exception code c0000005 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
David Naylor
Nov 4, 2012, 7:42:13 AM11/4/12
to
On Saturday, 3 November 2012 23:47:54 Jan Beich wrote:
and regedit work with a clang built lib32. I'll email Gerald (wine's
maintainer) about including your patch in wine.
regards
> David Naylor <naylor....@gmail.com> 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
> > 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
>
>
> 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
> 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
and regedit work with a clang built lib32. I'll email Gerald (wine's
maintainer) about including your patch in wine.
regards
Konstantin Belousov
Nov 4, 2012, 8:18:30 AM11/4/12
to
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.
Dimitry Andric
Nov 4, 2012, 9:29:42 AM11/4/12
to
On 2012-11-04 14:18, Konstantin Belousov wrote:
> On Sun, Nov 04, 2012 at 02:42:13PM +0200, David Naylor 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
>> 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.
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".
Konstantin Belousov
Nov 4, 2012, 9:36:59 AM11/4/12
to
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.
> 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.
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,
> 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".
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;
> }
>
Nathan Whitehorn
Nov 4, 2012, 9:42:00 AM11/4/12
to
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.
>
> 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
> 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".
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
0 new messages