Re: setting CC/CXX/CPP unconditionally in src.conf
On Tue Feb 28 12, Alexander Best wrote: > On Tue Feb 28 12, Dimitry Andric wrote: > > On 2012-02-26 22:37, Alexander Best wrote: > > > any chance support for setting CC/CXX/CPP unconditionally in src.conf > > > could be > > > added before the release of freebsd 10.0? the way it is done atm is > > > really not > > > intuitive. the rule should really be: > > > > > > - make.conf = applies globally > > > - src.conf = applies only to /usr/src > > > ( maybe a ports.conf or port.conf could be introduced at some point, too) > > > > > > ... the current situation, where only certain variables can be set in > > > src.conf > > > is not ideal. > > > > I just committed r232263 to head, which should allow setting CC/CXX/CPP > > in src.conf. Please try it out. > > it seems the latest libarchive import broke world with clang and without > NO_WERROR=. i'm now trying with NO_WERROR= set. with NO_WERROR= set buildworld succeeded. cheers. alex > > cheers. > alex ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: setting CC/CXX/CPP unconditionally in src.conf
On Tue Feb 28 12, Dimitry Andric wrote: > On 2012-02-26 22:37, Alexander Best wrote: > > any chance support for setting CC/CXX/CPP unconditionally in src.conf could > > be > > added before the release of freebsd 10.0? the way it is done atm is really > > not > > intuitive. the rule should really be: > > > > - make.conf = applies globally > > - src.conf = applies only to /usr/src > > ( maybe a ports.conf or port.conf could be introduced at some point, too) > > > > ... the current situation, where only certain variables can be set in > > src.conf > > is not ideal. > > I just committed r232263 to head, which should allow setting CC/CXX/CPP > in src.conf. Please try it out. any chance we can have a CFLAGS.gcc and CFLAGS.clang in the future? that would make certain things a lot easier. dealing with gcc specific options, such as -mpreferred-stack-boundary=2 would simply work by setting CFLAGS.gcc=-mpreferred-stack-boundary=2 e.g. cheers. alex ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: setting CC/CXX/CPP unconditionally in src.conf
On Tue Feb 28 12, Dimitry Andric wrote: > On 2012-02-26 22:37, Alexander Best wrote: > > any chance support for setting CC/CXX/CPP unconditionally in src.conf could > > be > > added before the release of freebsd 10.0? the way it is done atm is really > > not > > intuitive. the rule should really be: > > > > - make.conf = applies globally > > - src.conf = applies only to /usr/src > > ( maybe a ports.conf or port.conf could be introduced at some point, too) > > > > ... the current situation, where only certain variables can be set in > > src.conf > > is not ideal. > > I just committed r232263 to head, which should allow setting CC/CXX/CPP > in src.conf. Please try it out. it seems the latest libarchive import broke world with clang and without NO_WERROR=. i'm now trying with NO_WERROR= set. cheers. alex ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
setting CC/CXX/CPP unconditionally in src.conf
hi there, any chance support for setting CC/CXX/CPP unconditionally in src.conf could be added before the release of freebsd 10.0? the way it is done atm is really not intuitive. the rule should really be: - make.conf = applies globally - src.conf = applies only to /usr/src ( maybe a ports.conf or port.conf could be introduced at some point, too) ... the current situation, where only certain variables can be set in src.conf is not ideal. cheers. alex ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[rfc] removing/conditionalising WERROR= in Makefiles
hi there,
i grep'ed through src/sys and found several places where WERROR= was set in
order to get rid of the default -Werror setting. i tried to remove those
WERROR= overrides from any Makefile, where doing so did not break tinderbox.
in those cases, where it couldn't be completely removed, i added conditions to
only set WERROR= for the particular achitecture or compiler, where tinderbox
did not suceed without the WERROR=.
i talked to dim@ on #freebsd-clang@OFTC and he was against enclosing WERROR=
in a architecture or compiler condition. his statement was:
"
dim : I'm not going to riddle all those makefiles with endless comments, people
have to learn to look in the commit history for a file.
"
however the problem is that most of the time the commit message by the person
who added WERROR= to a Makefile doesn't state *why* the person did it and most
importantly it doesn't state in *which* case tinderbox failed without the
WERROR= (see *).
so my suggestion would be that instead of setting WERROR= unconditionally in
Makefiles, it should be enclosed in a condition to only set it in a particular
case, where tinderbox *will* fail.
an example is r228861. here dim@ set WERROR= in sys/modules/nve/Makefile
unconditionally. however tinderbox will only fail when
A) clang is used as compiler
B) when building for i386
these facts aren't clear from the commit message. so i'd suggest (please see
the attached patch) to conditionalise such settings.
another point i'd like to make is that WERROR= might have been set in a
Makefile in the past to unbreak tinderbox for a certain arch that is no longer
supported. since most of the time the commit logs simply state something like:
*)
"...remove -Werror for now to unbreak tinderbox..."
nobody will notice that after support for a certain arch was removed, the
WERROR= line can be removed from that particular Makefile.
that's why i'd like to propose the following patch. i ran a full tinderbox run
against r228878 and it suceeded.
cheers.
alex
Index: sys/modules/xfs/Makefile
===
--- sys/modules/xfs/Makefile(revision 228878)
+++ sys/modules/xfs/Makefile(working copy)
@@ -6,8 +6,6 @@
KMOD= xfs
-WERROR=
-
SRCS = vnode_if.h \
xfs_alloc.c \
xfs_alloc_btree.c \
Index: sys/modules/sound/driver/maestro/Makefile
===
--- sys/modules/sound/driver/maestro/Makefile (revision 228878)
+++ sys/modules/sound/driver/maestro/Makefile (working copy)
@@ -5,6 +5,5 @@
KMOD= snd_maestro
SRCS= device_if.h bus_if.h pci_if.h
SRCS+= maestro.c
-WERROR=
.include
Index: sys/modules/aic7xxx/ahd/Makefile
===
--- sys/modules/aic7xxx/ahd/Makefile(revision 228878)
+++ sys/modules/aic7xxx/ahd/Makefile(working copy)
@@ -4,7 +4,6 @@
.PATH: ${.CURDIR}/../../../dev/aic7xxx
KMOD= ahd
-WERROR=
GENSRCS= aic79xx_seq.h aic79xx_reg.h
REG_PRINT_OPT=
AHD_REG_PRETTY_PRINT=1
Index: sys/modules/ie/Makefile
===
--- sys/modules/ie/Makefile (revision 228878)
+++ sys/modules/ie/Makefile (working copy)
@@ -6,6 +6,8 @@
KMOD= if_ie
SRCS= if_ie.c if_ie_isa.c \
isa_if.h bus_if.h device_if.h
+.if ${MACHINE_CPUARCH} == "i386"
WERROR=
+.endif
.include
Index: sys/modules/agp/Makefile
===
--- sys/modules/agp/Makefile(revision 228878)
+++ sys/modules/agp/Makefile(working copy)
@@ -20,7 +20,6 @@
SRCS+= device_if.h bus_if.h agp_if.h pci_if.h
SRCS+= opt_agp.h opt_bus.h
MFILES=kern/device_if.m kern/bus_if.m dev/agp/agp_if.m dev/pci/pci_if.m
-WERROR=
EXPORT_SYMS= agp_find_device \
agp_state \
Index: sys/modules/bios/smapi/Makefile
===
--- sys/modules/bios/smapi/Makefile (revision 228878)
+++ sys/modules/bios/smapi/Makefile (working copy)
@@ -6,7 +6,6 @@
KMOD= smapi
SRCS= smapi.c smapi_bios.S \
bus_if.h device_if.h
-WERROR=
.if ${CC:T:Mclang} == "clang"
# XXX: clang integrated-as doesn't grok 16-bit assembly yet
CFLAGS+= ${.IMPSRC:T:Msmapi_bios.S:C/^.+$/-no-integrated-as/}
Index: sys/modules/nve/Makefile
===
--- sys/modules/nve/Makefile(revision 228878)
+++ sys/modules/nve/Makefile(working copy)
@@ -7,7 +7,9 @@
device_if.h bus_if.h pci_if.h miibus_if.h \
os+%DIKED-nve.h
OBJS+= nvenetlib.o
+.if ${MACHINE_CPUARCH} == "i386" && ${CC:T:Mclang} == "clang"
WERROR=
+.endif
CLEANFILES+= nvenetlib.o os+%DIKED-nve.h
nvenetlib.o: ${.CURDIR}/../../contrib/dev/nve/${MACHINE}/${.TARGET}.bz2.uu
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.o
Re: buildworld broken with _WITHOUT_SRCCONF=
On Wed Dec 21 11, Dimitry Andric wrote:
> On 2011-12-21 13:54, Alexander Best wrote:
> >i just ran into some issues while trying to make buildworld:
> >
> >otaku% make buildworld
> >
> >--
> >>>>Building an up-to-date make(1)
> >--
> >"/usr/share/mk/bsd.prog.mk", line 13: Malformed conditional
> >(${MK_ASSERT_DEBUG} == "no")
> >"/usr/share/mk/bsd.prog.mk", line 16: if-less endif
> >"/usr/share/mk/bsd.prog.mk", line 58: Malformed conditional (${MK_CTF} !=
> >"no")
> >"/usr/share/mk/bsd.prog.mk", line 99: Malformed conditional (${MK_MAN} !=
> >"no"&& !defined(MAN)&& !defined(MAN1)&& !defined(MAN2)&&
> >!defined(MAN3)&& !defined(MAN4)&& !defined(MAN5)&& !defined(MAN6)&&
> >!defined(MAN7)&& !defined(MAN8)&& !defined(MAN9)&& !defined(MAN1aout))
> >"/usr/share/mk/bsd.prog.mk", line 102: if-less endif
> >"/usr/share/mk/bsd.prog.mk", line 103: if-less endif
> >"/usr/share/mk/bsd.prog.mk", line 106: Malformed conditional (${MK_MAN} !=
> >"no")
> >"/usr/share/mk/bsd.prog.mk", line 108: if-less endif
> >"/usr/share/mk/bsd.libnames.mk", line 20: Malformed conditional
> >(${MK_BIND_LIBS} != "no")
> >"/usr/share/mk/bsd.libnames.mk", line 23: if-less endif
> >"/usr/share/mk/bsd.libnames.mk", line 66: Malformed conditional (${MK_IPX}
> >!= "no")
> >"/usr/share/mk/bsd.libnames.mk", line 68: if-less endif
> >"/usr/share/mk/bsd.libnames.mk", line 69: Malformed conditional
> >(${MK_BIND_LIBS} != "no")
> >"/usr/share/mk/bsd.libnames.mk", line 73: if-less endif
> >"/usr/share/mk/bsd.libnames.mk", line 84: Malformed conditional
> >(${MK_BIND} != "no")
> >"/usr/share/mk/bsd.libnames.mk", line 86: if-less endif
> >"/usr/share/mk/bsd.libnames.mk", line 93: Malformed conditional
> >(${MK_SENDMAIL} != "no")
> >"/usr/share/mk/bsd.libnames.mk", line 95: if-less endif
> >"/usr/share/mk/bsd.libnames.mk", line 97: Malformed conditional (${MK_NCP}
> >!= "no")
> >"/usr/share/mk/bsd.libnames.mk", line 99: if-less endif
> >"/usr/share/mk/bsd.libnames.mk", line 112: Malformed conditional
> >(${MK_KERBEROS} != "no")
> >"/usr/share/mk/bsd.libnames.mk", line 121: Malformed conditional
> >(${MK_OPENSSH} != "no")
> >"/usr/share/mk/bsd.libnames.mk", line 124: if-less endif
> >"/usr/share/mk/bsd.libnames.mk", line 125: Malformed conditional
> >(${MK_NIS} != "no")
> >"/usr/share/mk/bsd.libnames.mk", line 128: if-less endif
> >"/usr/share/mk/bsd.libnames.mk", line 129: if-less endif
> >"/usr/share/mk/bsd.incs.mk", line 7: Malformed conditional
> >(!defined(NO_INCS)&& ${MK_TOOLCHAIN} != "no")
> >"/usr/share/mk/bsd.prog.mk", line 198: Malformed conditional (${MK_MAN} !=
> >"no")
> >"/usr/share/mk/bsd.prog.mk", line 201: if-less endif
> >"/usr/share/mk/bsd.prog.mk", line 203: if-less endif
> >"/usr/share/mk/bsd.prog.mk", line 212: Malformed conditional (${MK_MAN} !=
> >"no")
> >"/usr/share/mk/bsd.prog.mk", line 214: if-less endif
> >"/usr/share/mk/bsd.sys.mk", line 102: Malformed conditional (${MK_SSP} !=
> >"no"&& ${MACHINE_CPUARCH} != "ia64"&& ${MACHINE_CPUARCH} != "arm"&&
> >${MACHINE_CPUARCH} != "mips")
> >"/usr/share/mk/bsd.sys.mk", line 106: if-less endif
> >make: fatal errors encountered -- cannot continue
> >*** Error code 1
> >
> >Stop in /usr/subversion-src.
> >*** Error code 1
> >
> >Stop in /usr/subversion-src.
> >
> >... it seems _WITHOUT_SRCCONF= is causing this error. basically i thought
> >defining _WITHOUT_SRCCONF was equal to setting SRCCONF=/dev/null, but that
> >doesn't seem to be the case.
>
> Why would you want to do this? The documented way in src.conf(5), is to
> set SRCCONF to /dev/null.
>
> It looks like _WITHOUT_SRCCONF is for ports-internal use only, see
> http://svnweb.freebsd.org/base?view=revision&revision=164411
thanks for the info. i wasn't aware that _WITHOUT_SRCCONF is a ports thing.
cheers.
alex
>
> If you define _WITHOUT_SRCCONF, none of the MK_XXX variables gets
> defined, causing all the errors later on. So "Don't Do That"(TM) :)
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
buildworld broken with _WITHOUT_SRCCONF=
hi there,
i just ran into some issues while trying to make buildworld:
otaku% make buildworld
--
>>> Building an up-to-date make(1)
--
"/usr/share/mk/bsd.prog.mk", line 13: Malformed conditional (${MK_ASSERT_DEBUG}
== "no")
"/usr/share/mk/bsd.prog.mk", line 16: if-less endif
"/usr/share/mk/bsd.prog.mk", line 58: Malformed conditional (${MK_CTF} != "no")
"/usr/share/mk/bsd.prog.mk", line 99: Malformed conditional (${MK_MAN} != "no"
&& !defined(MAN) && !defined(MAN1) && !defined(MAN2) && !defined(MAN3) &&
!defined(MAN4) && !defined(MAN5) && !defined(MAN6) && !defined(MAN7) &&
!defined(MAN8) && !defined(MAN9) && !defined(MAN1aout))
"/usr/share/mk/bsd.prog.mk", line 102: if-less endif
"/usr/share/mk/bsd.prog.mk", line 103: if-less endif
"/usr/share/mk/bsd.prog.mk", line 106: Malformed conditional (${MK_MAN} != "no")
"/usr/share/mk/bsd.prog.mk", line 108: if-less endif
"/usr/share/mk/bsd.libnames.mk", line 20: Malformed conditional
(${MK_BIND_LIBS} != "no")
"/usr/share/mk/bsd.libnames.mk", line 23: if-less endif
"/usr/share/mk/bsd.libnames.mk", line 66: Malformed conditional (${MK_IPX} !=
"no")
"/usr/share/mk/bsd.libnames.mk", line 68: if-less endif
"/usr/share/mk/bsd.libnames.mk", line 69: Malformed conditional
(${MK_BIND_LIBS} != "no")
"/usr/share/mk/bsd.libnames.mk", line 73: if-less endif
"/usr/share/mk/bsd.libnames.mk", line 84: Malformed conditional (${MK_BIND} !=
"no")
"/usr/share/mk/bsd.libnames.mk", line 86: if-less endif
"/usr/share/mk/bsd.libnames.mk", line 93: Malformed conditional (${MK_SENDMAIL}
!= "no")
"/usr/share/mk/bsd.libnames.mk", line 95: if-less endif
"/usr/share/mk/bsd.libnames.mk", line 97: Malformed conditional (${MK_NCP} !=
"no")
"/usr/share/mk/bsd.libnames.mk", line 99: if-less endif
"/usr/share/mk/bsd.libnames.mk", line 112: Malformed conditional
(${MK_KERBEROS} != "no")
"/usr/share/mk/bsd.libnames.mk", line 121: Malformed conditional (${MK_OPENSSH}
!= "no")
"/usr/share/mk/bsd.libnames.mk", line 124: if-less endif
"/usr/share/mk/bsd.libnames.mk", line 125: Malformed conditional (${MK_NIS} !=
"no")
"/usr/share/mk/bsd.libnames.mk", line 128: if-less endif
"/usr/share/mk/bsd.libnames.mk", line 129: if-less endif
"/usr/share/mk/bsd.incs.mk", line 7: Malformed conditional (!defined(NO_INCS)
&& ${MK_TOOLCHAIN} != "no")
"/usr/share/mk/bsd.prog.mk", line 198: Malformed conditional (${MK_MAN} != "no")
"/usr/share/mk/bsd.prog.mk", line 201: if-less endif
"/usr/share/mk/bsd.prog.mk", line 203: if-less endif
"/usr/share/mk/bsd.prog.mk", line 212: Malformed conditional (${MK_MAN} != "no")
"/usr/share/mk/bsd.prog.mk", line 214: if-less endif
"/usr/share/mk/bsd.sys.mk", line 102: Malformed conditional (${MK_SSP} != "no"
&& ${MACHINE_CPUARCH} != "ia64" && ${MACHINE_CPUARCH} != "arm" &&
${MACHINE_CPUARCH} != "mips")
"/usr/share/mk/bsd.sys.mk", line 106: if-less endif
make: fatal errors encountered -- cannot continue
*** Error code 1
Stop in /usr/subversion-src.
*** Error code 1
Stop in /usr/subversion-src.
... it seems _WITHOUT_SRCCONF= is causing this error. basically i thought
defining _WITHOUT_SRCCONF was equal to setting SRCCONF=/dev/null, but that
doesn't seem to be the case.
cheers.
alex
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: -fstack-protector vs. -fstack-protector-all
On Sat Nov 19 11, Dimitry Andric wrote:
> On 2011-11-18 15:37, Alexander Best wrote:
> > what are the reasons for using -fstack-protector instead of
> > -fstack-protector-all in sys/conf/kern.mk?
>
> My guess would be one or more of the following:
>
> - The price in performance is too high
> - The gain in security is too low
> - Some routines in the kernel are run before the whole stack protection
> infrastructure is in place, ergo they can't have stack protection
> - There might be other problems with -fstack-protector-all,
> lib/libc/Makefile says:
>
> # XXX For now, we don't allow libc to be compiled with
> # -fstack-protector-all because it breaks rtld. We may want to make a
> librtld
> # in the future to circumvent this.
> SSP_CFLAGS:=
> ${SSP_CFLAGS:S/^-fstack-protector-all$/-fstack-protector/}
defining -fstack-protector-all in sys/conf/kern.mk will only apply it to the
kernel and its components and not to world, i believe.
i've been running a kernel compiled with -fstack-protector-all and haven't
experienced any issues with it, so far.
cheers.
alex
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: 'make installkernel' succeeding on read-only fs?
On Sun Nov 20 11, Alexander Best wrote: > On Sun Nov 20 11, Denise H. G. wrote: > > > > On 2011/11/19 at 19:24, Alexander Best wrote: > > > > > > hi there, > > > just stumbled upon this little detail: > > > > > > 1) have "/" mounted read-only > > > 2) 'make buildkernel' > > > 3) 'make installkernel && echo "success"' > > >-> this will fail > > > 4) 'mount -uw /' > > > 5) 'make installkernel && echo "success"' > > >-> this will succeed > > > 6) 'mount -ur /' > > > 7) 'make installkernel && echo "success"' > > >-> this will succeed. why? > > > > According to mount(8), 'mount -ur /' will fail if / is already mounted > > read-write with any files currently opened by some processes. I think > > this might be your case. > > i'd don't think so: > > otaku% sudo mount -uw / > otaku% echo $? > 0 > otaku% sudo mount -ur / > otaku% echo $? > 0 > > ...also 'mount -p' reports "/" to be read-only again. > > ...also during 7), mkdir(1) returns an error that "/" isn't writable. it's > install(1) that claims the kernel was successfully installed into > /boot/kernel, > although installation of the kernel didn't succeed. > > i don't think this is an install(1) issue, since in 3), install(1) returns an > error. i think in 7), install(1)'s output gets somehow redirected to > /dev/null, > and its return value isn't being preserved. > > i'll try to use 'mount -ufr /' in 6) and see, if that has any impact. also > after 6) i'll try to run install(1) manually to see, whether it actually > reports an error (then the build(7) facility is to blame) or not (in which > case > there's a problem with install(1) itself). MYSTERY SOLVED! ;) install gets executed with the -p option, which implies the -C option. this means that install will do a comparison of the installed kernel in /boot/kernel and the one in /usr/obj, before actually executing. during the first installkernel invocation, the files differ, so install complains. during the second invocation the files don't differ. that's why install succeeds, although "/" is mounted read-only. ;) cheers. alex > > cheers. > alex > > > > > > > > > cheers. > > > alex > > > > > > > > > > > -- > > If you've got them by the balls, > > their hearts and minds will follow. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: 'make installkernel' succeeding on read-only fs?
On Sun Nov 20 11, Denise H. G. wrote: > > On 2011/11/19 at 19:24, Alexander Best wrote: > > > > hi there, > > just stumbled upon this little detail: > > > > 1) have "/" mounted read-only > > 2) 'make buildkernel' > > 3) 'make installkernel && echo "success"' > >-> this will fail > > 4) 'mount -uw /' > > 5) 'make installkernel && echo "success"' > >-> this will succeed > > 6) 'mount -ur /' > > 7) 'make installkernel && echo "success"' > >-> this will succeed. why? > > According to mount(8), 'mount -ur /' will fail if / is already mounted > read-write with any files currently opened by some processes. I think > this might be your case. i'd don't think so: otaku% sudo mount -uw / otaku% echo $? 0 otaku% sudo mount -ur / otaku% echo $? 0 ...also 'mount -p' reports "/" to be read-only again. ...also during 7), mkdir(1) returns an error that "/" isn't writable. it's install(1) that claims the kernel was successfully installed into /boot/kernel, although installation of the kernel didn't succeed. i don't think this is an install(1) issue, since in 3), install(1) returns an error. i think in 7), install(1)'s output gets somehow redirected to /dev/null, and its return value isn't being preserved. i'll try to use 'mount -ufr /' in 6) and see, if that has any impact. also after 6) i'll try to run install(1) manually to see, whether it actually reports an error (then the build(7) facility is to blame) or not (in which case there's a problem with install(1) itself). cheers. alex > > > > > cheers. > > alex > > > > > > -- > If you've got them by the balls, > their hearts and minds will follow. ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CPUTYPE=native handling
On Tue Nov 8 11, Dimitry Andric wrote:
> On 2011-11-08 01:25, Alexander Best wrote:
> > i've seen dozens of issues, where people set CPUTYPE=native. although this
> > works in a lot of cases, it doesn't in others. why don't we simply add
> > something like
> >
> > . if ${CPUTYPE} == "native"
> > . error "bla"
> > . endif
> >
> > in share/mk/bsd.cpu.mk for now? or at least for the archs, where "native" is
> > known to cause problems.
>
> What does this solve? Don't you think it is better to try to fix the
> actual problems? Some people like being able to optimize for their
> specific CPU, however much you can shoot yourself in the foot with it.
just wanted to report that i found an issue with CPUTYPE "native". simply do
the following on amd64 (i tested this on ref9-amd64.freebsd.org):
make.conf:
CPUTYPE ?= native
CFLAGS = -O2 -pipe -fno-strict-aliasing -funroll-loops -fno-builtin
KERNCONF = GENERIC
now 'make buildworld' and enjoy the signal 11. ;)
setting CPUTYPE to nocona or commenting it out lets 'mak buildworld' succeed.
cheers.
alex
there's a problem report for this already:
http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/149712
>
> I haven't seen any consistent bug reports yet, just a lot of complaints
> that indicate a rather high probability of PEBKAC.
>
> And just to counter the nay-saying, I compiled a number of boxes with
> clang -march=native (mostly of the Xeon/i7 variant) and I haven't seen
> any problems at all.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
'make installkernel' succeeding on read-only fs?
hi there, just stumbled upon this little detail: 1) have "/" mounted read-only 2) 'make buildkernel' 3) 'make installkernel && echo "success"' -> this will fail 4) 'mount -uw /' 5) 'make installkernel && echo "success"' -> this will succeed 6) 'mount -ur /' 7) 'make installkernel && echo "success"' -> this will succeed. why? cheers. alex ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
-fstack-protector vs. -fstack-protector-all
hi there, what are the reasons for using -fstack-protector instead of -fstack-protector-all in sys/conf/kern.mk? cheers. alex ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
format string is not a string literal (potentially insecure) [-Wformat-security]
hi there, clang outputs the following warning during 'make buildkernel': clang -c -O3 -pipe -fno-inline-functions -fno-strict-aliasing -march=core2 -std=c99 -fdiagnostics-show-option -fformat-extensions -Wall -Wcast-qual -Winline -Wmissing-include-dirs -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wredundant-decls -Wstrict-prototypes -Wundef -Wno-pointer-sign -nostdinc -I. -I/usr/git-freebsd-head/sys -I/usr/git-freebsd-head/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector-all /usr/git-freebsd-head/sys/kern/kern_conf.c /usr/git-freebsd-head/sys/kern/kern_conf.c:1019:45: warning: format string is not a string literal (potentially insecure) [-Wformat-security] ret = make_dev_alias_p(flags, cdev, pdev, devfspath); ^ does this indicate a security risk, which should be fixed or rather a bugus warning? cheers. alex ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CPUTYPE=native handling
On Tue Nov 8 11, Dimitry Andric wrote:
> On 2011-11-08 22:04, Alexander Best wrote:
> ...
> > for me -march=native reports:
> >
> > otaku% gcc -march=native -E -v - > Using built-in specs.
> > Target: amd64-undermydesk-freebsd
> > Configured with: FreeBSD/amd64 system compiler
> > Thread model: posix
> > gcc version 4.2.2 20070831 prerelease [FreeBSD]
> > /usr/libexec/cc1 -E -quiet -v -D_LONGLONG - -march=nocona -mtune=generic
> > #include "..." search starts here:
> > #include <...> search starts here:
> > /usr/include/gcc/4.2
> > /usr/include
> > End of search list.
> > # 1 ""
> > # 1 ""
> > # 1 ""
> > # 1 ""
> >
> > where instead of nocona, core2 would have been the better choice:
> >
> > [1.00] CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz
> > (1800.00-MHz K8-class CPU)
> > [1.00] Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f
> > Stepping = 13
> > [1.00]
> > Features=0xbfebfbff
> > [1.00]
> > Features2=0xe39d
> > [1.00] AMD Features=0x20100800
> > [1.00] AMD Features2=0x1
> > [1.00] TSC: P-state invariant, performance statistics
>
> That's weird, the logic in gcc goes:
>
> cpuid (1, eax, ebx, ecx, edx);
> ...
> has_ssse3 = !!(ecx & bit_SSSE3);
> ...
> if (arch)
> {
> if (has_ssse3)
> cpu = "core2";
> else if (has_sse3)
> {
> if (has_longmode)
> cpu = "nocona";
> else
> cpu = "prescott";
> }
> else if (has_sse2)
> cpu = "pentium4";
> else if (has_cmov)
> cpu = "pentiumpro";
> else if (has_mmx)
> cpu = "pentium-mmx";
> else if (has_cmpxchg8b)
> cpu = "pentium";
> else
> cpu = "i386";
> }
> else
> cpu = "generic";
> goto done;
>
> E.g. it seems to conclude your cpu *doesn't* have SSSE3, but does have
> long mode, and thus jumps to nocona.
>
> You might be able to debug this, by putting some printfs in this
> function. :)
same on ref9-amd64.freebsd.org:
ref9-amd64% clang -march=native -### blabla.c
FreeBSD clang version 3.0 (trunk 135360) 20110717
Target: x86_64-unknown-freebsd9.0
Thread model: posix
"/usr/bin/clang" "-cc1" "-triple" "x86_64-unknown-freebsd9.0" "-emit-obj"
"-mrelax-all" "-disable-free" "-main-file-name" "tower.c" "-mrelocation-model"
"static" "-mdisable-fp-elim" "-masm-verbose" "-mconstructor-aliases"
"-munwind-tables" "-target-cpu" "core2" "-momit-leaf-frame-pointer"
"-resource-dir" "/usr/bin/../lib/clang/3.0" "-ferror-limit" "19"
"-fmessage-length" "275" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-o"
"/tmp/cc-ImChyq.o" "-x" "c" "tower.c"
"/usr/bin/ld" "--eh-frame-hdr" "-dynamic-linker" "/libexec/ld-elf.so.1" "-o"
"tower" "/usr/lib/crt1.o" "/usr/lib/crti.o" "/usr/lib/crtbegin.o" "-L/usr/lib"
"/tmp/cc-ImChyq.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc"
"-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "/usr/lib/crtend.o"
"/usr/lib/crtn.o"
BUT
ref9-amd64% gcc -march=native -E -v - search starts here:
/usr/include/gcc/4.2
/usr/include
End of search list.
# 1 ""
# 1 ""
# 1 ""
# 1 ""
cheers.
alex
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: make cleanworld
On Tue Nov 8 11, Alexander Best wrote:
> On Tue Nov 8 11, Warner Losh wrote:
> >
> > On Nov 8, 2011, at 2:55 PM, Alexander Best wrote:
> > > find -flags +XXX /usr/obj/usr/git-freebsd-head -exec chflags -R 0 {} +
> > > rm/obj/usr/git-freebsd-head/*
> > >
> > > that should only execute chflags(1) on those files with flags set.
> >
> > THat's only faster if the entire directory tree says in the directory
> > cache. It isn't so much about chflags being called N times, but having to
> > look at N files twice.
>
> i think i got it now. ;) sorry for beeing so slow. i'll try to come up with a
> patch for Makefile, which mentions this in the comment.
thoughts?
diff --git a/Makefile b/Makefile
index 61e678b..5d053c2 100644
--- a/Makefile
+++ b/Makefile
@@ -185,7 +185,10 @@ buildworld: upgrade_checks
# files with chflags set, so this unsets them and tries the 'rm' a
# second time. There are situations where this target will be cleaning
# some directories via more than one method, but that duplication is
-# needed to correctly handle all the possible situations.
+# needed to correctly handle all the possible situations. Getting rid
+# of all files without chflags set in the first 'rm' instance saves us
+# time, because now 'chflags' only needs to take the remaining files
+# (those with chflags set) into account.
#
BW_CANONICALOBJDIR:=${MAKEOBJDIRPREFIX}${.CURDIR}
cleanworld:
>
> cheers.
> alex
>
> >
> > Warner
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: make cleanworld
On Tue Nov 8 11, Warner Losh wrote:
>
> On Nov 8, 2011, at 2:55 PM, Alexander Best wrote:
> > find -flags +XXX /usr/obj/usr/git-freebsd-head -exec chflags -R 0 {} +
> > rm/obj/usr/git-freebsd-head/*
> >
> > that should only execute chflags(1) on those files with flags set.
>
> THat's only faster if the entire directory tree says in the directory cache.
> It isn't so much about chflags being called N times, but having to look at N
> files twice.
i think i got it now. ;) sorry for beeing so slow. i'll try to come up with a
patch for Makefile, which mentions this in the comment.
cheers.
alex
>
> Warner
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: make cleanworld
On Tue Nov 8 11, Dimitry Andric wrote:
> On 2011-11-08 21:49, Alexander Best wrote:
> > any reason 'make cleanworld' does
> >
> > otaku% make cleanworld
> > rm -rf /usr/obj/usr/git-freebsd-head/*
> > chflags -R 0 /usr/obj/usr/git-freebsd-head
> > rm -rf /usr/obj/usr/git-freebsd-head/*
> >
> > where
> >
> > otaku% make cleanworld
> > chflags -R 0 /usr/obj/usr/git-freebsd-head
> > rm -rf /usr/obj/usr/git-freebsd-head/*
> >
> > should be sufficient?
>
> The first method is more efficient, because there are usually just a few
> files with schg flags set on them (zero even, if you build as a regular
> user).
>
> Suppose you have 30,000 files in /usr/obj, of which 20 have schg flags.
>
> The first method will unlink 29,980 files, failing on 20 of them. Then
> it will change flags on just 20 files, and lastly unlink those 20 files.
> Total number of 'operations' is 30,000 + 20 + 20 = 30,040.
>
> The second method will change flags on all 30,000 files, then unlink all
> 30,000 files. Total number of 'operations' is now 30,000 + 30,000 =
> 60,000.
maybe the comment in /usr/src/Makefile could be updated to mention the
efficiency aspect? right now it only says:
#
# This 'cleanworld' target is not included in TGTS, because it is not a
# recursive target. All of the work for it is done right here. It is
# expected that BW_CANONICALOBJDIR == the CANONICALOBJDIR as would be
# created by bsd.obj.mk, except that we don't want to .include that file
# in this makefile.
#
# In the following, the first 'rm' in a series will usually remove all
# files and directories. If it does not, then there are probably some
# files with chflags set, so this unsets them and tries the 'rm' a
# second time. There are situations where this target will be cleaning
# some directories via more than one method, but that duplication is
# needed to correctly handle all the possible situations. Also this
#
another tought would be to do the following:
find -flags +XXX /usr/obj/usr/git-freebsd-head -exec chflags -R 0 {} +
rm/obj/usr/git-freebsd-head/*
that should only execute chflags(1) on those files with flags set.
cheers.
alex
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: make cleanworld
On Tue Nov 8 11, Warner Losh wrote: > > On Nov 8, 2011, at 1:49 PM, Alexander Best wrote: > > > hi there, > > > > any reason 'make cleanworld' does > > > > otaku% make cleanworld > > rm -rf /usr/obj/usr/git-freebsd-head/* > > chflags -R 0 /usr/obj/usr/git-freebsd-head > > rm -rf /usr/obj/usr/git-freebsd-head/* > > > > where > > > > otaku% make cleanworld > > chflags -R 0 /usr/obj/usr/git-freebsd-head > > rm -rf /usr/obj/usr/git-freebsd-head/* > > > > should be sufficient? > > chflags is a lot slower when it has to do an entire tree, rather than just a > few files. So this winds up being faster. Or did across a wide swath of > FreeBSD version 4-7. ahh thanks. haven't thought about that. :) > > Warner ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CPUTYPE=native handling
On Tue Nov 8 11, Roman Divacky wrote: > On Tue, Nov 08, 2011 at 09:23:52PM +0000, Alexander Best wrote: > > On Tue Nov 8 11, Roman Divacky wrote: > > > clang will use "core2" for family=6 and model=15 > > > > > > check llvm/lib/Support/Host.cpp > > > > > > what is the problem? The fact that our gcc from the middle-ages > > > does not recognize that? > > > > actually a few months ago quite a lot of gcc commits happend to add newer > > optimisations (such as core2) to gcc and some commits aimed at modifying > > gcc, > > so it would make the best -march=native choice there is. > > > > what's the clang command (similar to gcc -march=native -E -v - > one can use to check what actual optimisation clang turns "native" into? > > clang -### -march=native will show something like otaku% clang -### -march=native FreeBSD clang version 3.0 (trunk 135360) 20110717 Target: x86_64-unknown-freebsd9.0 Thread model: posix ? > > "-target-cpu" "k8-sse3" > > > > also there seem to be cross-compilation issues. when people are running i386 > > and want to cross-compile for amd64 and put CPUTYPE=core2 (or any other > > amd64 > > cpu) into their make.conf, this gets downgraded by bsd.cpu.mk to prescott. > > > > see http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/84800 > > and > > http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg161451.html > > If gcc supports nocona now, the conf/84800 patch is ok. The same goes > with downgrading core2 -> prescott. > > I have no idea what gcc supports these days. I think we should just skip > the downgrading completely for clang as it either supports everything or > can be made easily to support what it doesnt. > > roman ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CPUTYPE=native handling
On Tue Nov 8 11, Roman Divacky wrote:
> clang will use "core2" for family=6 and model=15
>
> check llvm/lib/Support/Host.cpp
>
> what is the problem? The fact that our gcc from the middle-ages
> does not recognize that?
actually a few months ago quite a lot of gcc commits happend to add newer
optimisations (such as core2) to gcc and some commits aimed at modifying gcc,
so it would make the best -march=native choice there is.
what's the clang command (similar to gcc -march=native -E -v - http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/84800
and
http://www.mail-archive.com/freebsd-hackers@freebsd.org/msg161451.html
cheers.
alex
>
> On Tue, Nov 08, 2011 at 09:04:20PM +, Alexander Best wrote:
> > On Tue Nov 8 11, Roman Divacky wrote:
> > > On Tue, Nov 08, 2011 at 08:55:39AM +0100, Dimitry Andric wrote:
> > > > On 2011-11-08 01:25, Alexander Best wrote:
> > > > > i've seen dozens of issues, where people set CPUTYPE=native. although
> > > > > this
> > > > > works in a lot of cases, it doesn't in others. why don't we simply add
> > > > > something like
> > > > >
> > > > > . if ${CPUTYPE} == "native"
> > > > > . error "bla"
> > > > > . endif
> > > > >
> > > > > in share/mk/bsd.cpu.mk for now? or at least for the archs, where
> > > > > "native" is
> > > > > known to cause problems.
> > > >
> > > > What does this solve? Don't you think it is better to try to fix the
> > > > actual problems? Some people like being able to optimize for their
> > >
> > > Yes, we definitely should aim for fixing the problems instead of working
> > > around them.
> > >
> > > This way both clang and freebsd benefits.
> >
> > for me -march=native reports:
> >
> > otaku% gcc -march=native -E -v - > Using built-in specs.
> > Target: amd64-undermydesk-freebsd
> > Configured with: FreeBSD/amd64 system compiler
> > Thread model: posix
> > gcc version 4.2.2 20070831 prerelease [FreeBSD]
> > /usr/libexec/cc1 -E -quiet -v -D_LONGLONG - -march=nocona -mtune=generic
> > #include "..." search starts here:
> > #include <...> search starts here:
> > /usr/include/gcc/4.2
> > /usr/include
> > End of search list.
> > # 1 ""
> > # 1 ""
> > # 1 ""
> > # 1 ""
> >
> > where instead of nocona, core2 would have been the better choice:
> >
> > [1.00] CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz
> > (1800.00-MHz K8-class CPU)
> > [1.00] Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f
> > Stepping = 13
> > [1.00]
> > Features=0xbfebfbff
> > [1.00]
> > Features2=0xe39d
> > [1.00] AMD Features=0x20100800
> > [1.00] AMD Features2=0x1
> > [1.00] TSC: P-state invariant, performance statistics
> >
> > cheers.
> > alex
> >
> > >
> > > roman
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: CPUTYPE=native handling
On Tue Nov 8 11, Roman Divacky wrote:
> On Tue, Nov 08, 2011 at 08:55:39AM +0100, Dimitry Andric wrote:
> > On 2011-11-08 01:25, Alexander Best wrote:
> > > i've seen dozens of issues, where people set CPUTYPE=native. although this
> > > works in a lot of cases, it doesn't in others. why don't we simply add
> > > something like
> > >
> > > . if ${CPUTYPE} == "native"
> > > . error "bla"
> > > . endif
> > >
> > > in share/mk/bsd.cpu.mk for now? or at least for the archs, where "native"
> > > is
> > > known to cause problems.
> >
> > What does this solve? Don't you think it is better to try to fix the
> > actual problems? Some people like being able to optimize for their
>
> Yes, we definitely should aim for fixing the problems instead of working
> around them.
>
> This way both clang and freebsd benefits.
for me -march=native reports:
otaku% gcc -march=native -E -v - search starts here:
/usr/include/gcc/4.2
/usr/include
End of search list.
# 1 ""
# 1 ""
# 1 ""
# 1 ""
where instead of nocona, core2 would have been the better choice:
[1.00] CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1800.00-MHz
K8-class CPU)
[1.00] Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f
Stepping = 13
[1.00]
Features=0xbfebfbff
[1.00]
Features2=0xe39d
[1.00] AMD Features=0x20100800
[1.00] AMD Features2=0x1
[1.00] TSC: P-state invariant, performance statistics
cheers.
alex
>
> roman
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
make cleanworld
hi there, any reason 'make cleanworld' does otaku% make cleanworld rm -rf /usr/obj/usr/git-freebsd-head/* chflags -R 0 /usr/obj/usr/git-freebsd-head rm -rf /usr/obj/usr/git-freebsd-head/* where otaku% make cleanworld chflags -R 0 /usr/obj/usr/git-freebsd-head rm -rf /usr/obj/usr/git-freebsd-head/* should be sufficient? cheers. alex ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
CPUTYPE=native handling
hi there,
i've seen dozens of issues, where people set CPUTYPE=native. although this
works in a lot of cases, it doesn't in others. why don't we simply add
something like
. if ${CPUTYPE} == "native"
. error "bla"
. endif
in share/mk/bsd.cpu.mk for now? or at least for the archs, where "native" is
known to cause problems.
cheers.
alex
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: state of clang(1)'s -Wshift-count-negative and -Wshift-overflow warnings
On Thu Nov 3 11, Adrian Chadd wrote:
> Hi,
>
> Please submit a PR and I'll fix the AR5210 code. I'll have to find an
> AR5210 though to test it against though...
filed under kern/162366 and assigned to you. ;)
cheers.
alex
>
>
> Adrian
>
> On 3 November 2011 13:08, Dimitry Andric wrote:
> > On 2011-11-03 20:03, Alexander Best wrote:
> >> On Thu Nov  3 11, Dimitry Andric wrote:
> >>> On 2011-11-03 11:45, Alexander Best wrote:
> >>> ...
> >>>> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ar5210/ar5210_power.c:36:3:
> >>>> warning: signed shift result (0x2) requires 35 bits to
> >>>> represent, but 'int' only has 32 bits [-Wshift-overflow]
> >>>> Â Â Â Â Â Â Â Â OS_REG_RMW_FIELD(ah, AR_SCR, AR_SCR_SLE,
> >>>> AR_SCR_SLE_ALLOW);
> >>>> Â Â Â Â Â Â Â Â
> >>>> ^~
> >>>> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_internal.h:471:42: note:
> >>>> expanded from macro 'OS_REG_RMW_FIELD'
> >>>> Â Â Â Â Â Â Â Â (OS_REG_READ(_a, _r) &~ (_f)) | (((_v) << _f##_S) &
> >>>> (_f)))
> >>>> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ^
> >>>> /usr/git-freebsd-head/sys/dev/ath/ah_osdep.h:127:49: note: expanded from
> >>>> macro 'OS_REG_WRITE'
> >>>> Â Â Â Â Â Â (bus_space_handle_t)(_ah)->ah_sh, (_reg), (_val))
> > ...
> >>> Those warnings are bogus, and due to this bug:
> >
> > Actually, I was too quick with this one, since it isn't bogus. Â The
> > macro invocation:
> >
> > Â OS_REG_RMW_FIELD(ah, AR_SCR, AR_SCR_SLE, AR_SCR_SLE_ALLOW);
> >
> > ultimately expands to:
> >
> > Â bus_space_write_4((bus_space_tag_t)(ah)->ah_st,
> > (bus_space_handle_t)(ah)->ah_sh, (0x4004),
> > ((bus_space_read_4((bus_space_tag_t)(ah)->ah_st,
> > (bus_space_handle_t)(ah)->ah_sh, (0x4004)) &~ (0x0003)) |
> > (((0x0002) << 16) & (0x0003;
> >
> > The problem part is ((0x0002) << 16), which is an overflow. Â I'm not
> > sure how clang concludes that the result (0x2) needs 35 bits to
> > represent, as it seems to use 34 bits to me. Â But that it doesn't fit
> > into a signed integer is crystal-clear.
> >
> > E.g. this is a real bug! Â Probably something in the macro needs to
> > explicitly cast to 64 integers, or another workaround must be found.
> >
> > The other warning:
> >
> >> In file included from
> >> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain.c:99:
> >> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:69:15:
> >> warning: shift count is negative [-Wshift-count-negative]
> >>      .chan11a        = BM4(F1_4950_4980,
> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ^
> >> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:41:4:
> >> note: expanded from macro 'BM4'
> >> Â Â Â Â Â W1(_fa) | W1(_fb) | W1(_fc) | W1(_fd) }
> >> Â Â Â Â Â ^
> >> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:34:45:
> >> note: expanded from macro 'W1'
> >> Â Â Â Â (((_a) > 63 && (_a) < 128 ? (((uint64_t) 1)<<((_a)-64)) :
> >> (uint64_t) 0))
> >> Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â ^ ~
> >
> > is indeed bogus, since the macro makes sure the shift count never
> > becomes negative. Â (N.B.: This only happens for global initializations,
> > *not* if you would use the same macro in a function.)
> >
> >
> >>> Â http://llvm.org/bugs/show_bug.cgi?id=10030
> >>>
> >>> Unfortunately, it is still not fixed for the 3.0 release branch, and I
> >>> don't expect it will be fixed for the actual release.
> >>
> >> thanks for the info. so how about something like
> >>
> >> diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk
> >> index a0a595f..3cb13de 100644
> >> --- a/sys/conf/kern.mk
> >> +++ b/sys/conf/kern.mk
> >> @@ -1,12 +1,28 @@
> >> Â # $FreeBSD$
> >>
> >> Â #
> >> -# Warning flags for compiling the kernel and components of the kernel:
> >> +# XXX Disable bogus llvm warnings, complaining about perfectly valid
> >> shifts.
> >> +# See http://llvm.org/bugs/show_bug.cgi?id=10030 for more details.
> >> +#
> >> +.if ${CC:T:Mclang} == "clang"
> >> +NOSHIFTWARNS= Â -Wno-shift-count-negative -Wno-shift-count-overflow \
> >> + Â Â Â Â Â Â Â -Wno-shift-overflow
> >> +.endif
> >> +
> >>
> >> ...and then add ${NOSHIFTWARNS} to the end of CWARNFLAGS?
> >
> > No, this is a way too big hammer, because it eliminates the useful
> > warnings together with the false positives.
> >
> > It would be better to only apply this band-aid for the specific source
> > files that need it, and even then, I would rather wait for the proper
> > fix from upstream.
> >
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [poc] buildkernel + clang + -Werror
On Sun Nov 6 11, Dimitry Andric wrote: > On 2011-11-06 21:33, Alexander Best wrote: > ... > > the problem is, something like > > > > uint x; > > > > if (x < 0) ... > > > > clang will warn about this, yet it is 100% valid code so my vote would be to > > make such an error into a warning. > > Sorry, but checking something unsigned to be smaller than zero is bogus, > or at the least superfluous, and it's perfectly sane to warn about this, > especially since the compiler is not going to emit code for it at all. there was a discussion with the topic "disable -Wtautological-compare for clang" on freebsd-toolchain@ and most of the devs considered this code *not* to be bogus. ;) > > The only time when this sort of check could be relevant, is when you are > using a typedef'd type, and you have no way to be sure if the type is > signed or unsigned. But then you will be in for trouble anyway... > > > ... > > the same with > > > > int x; > > > > x = x; > > > > i believe in both cases clang is too picky. > > This is a often-used idiom for attempting to 'shut up' a compiler when > it (quite legitimately) complains about unused variables or arguments. > > However, a better idiom is: > > (void) x; > > but even this can lead some compilers or analysis tools to complain > about "statements that don't do anything". A better way is to provide > UNUSED_VARIABLE and UNUSED_ARGUMENT macros, and handle shutting up the > compiler in its specific way there. > > Of course, the best solution is to just eliminate the unused variables > or arguments. If that is not possible, for example due to a function > signature that cannot be changed because of API considerations, you can > always use __unused attributes. i see. does PR #162321 fall into this category, or can the assignment be removed? cheers. alex ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [poc] buildkernel + clang + -Werror
On Sun Nov 6 11, Alexander Best wrote: > On Sun Nov 6 11, Ed Schouten wrote: > > Hello Alexander! > > > > Even though that I agree that Clang is sometimes a bit picky, we'd > > better spend the time fixing the actual bugs in the code. I am more than > > willing to commit patches that fix actual warnings/errors in code. however it would be nice, if you could take a look at PR 162321. cheers. alex > > the problem is, something like > > uint x; > > if (x < 0) ... > > clang will warn about this, yet it is 100% valid code so my vote would be to > make such an error into a warning. > > the same with > > int x; > > x = x; > > i believe in both cases clang is too picky. > > cheers. > alex > > > > > -- > > Ed Schouten > > WWW: http://80386.nl/ > > ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [poc] buildkernel + clang + -Werror
On Sun Nov 6 11, Ed Schouten wrote: > Hello Alexander! > > Even though that I agree that Clang is sometimes a bit picky, we'd > better spend the time fixing the actual bugs in the code. I am more than > willing to commit patches that fix actual warnings/errors in code. the problem is, something like uint x; if (x < 0) ... clang will warn about this, yet it is 100% valid code so my vote would be to make such an error into a warning. the same with int x; x = x; i believe in both cases clang is too picky. cheers. alex > > -- > Ed Schouten > WWW: http://80386.nl/ ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [poc] buildkernel + clang + -Werror
On Sat Nov 5 11, Dimitry Andric wrote: > On 2011-11-05 11:21, Alexander Best wrote: > > i'm sending this mail to the mailinglist simply to prevent my work being > > list. > > i've experimented with the -Werror and -Wno-error= options and got to the > > point > > where i was able to compile GENERIC on amd64 with clang: > ... > > Why don't you just use NO_WERROR? If you are aiming to simply suppress > warnings, that is a way simpler solution. because setting NO_WERROR to certain -Wno-error= options will complain about broken code, which gets committed. that way clang might be used for tinderbox, whereas with NO_WERROR simply defined to nothing, broken or unclean commits will not make tinderbox fail. if we could set NO_WERROR to bogus -Wno-error= options, clang will then only error out with *real* bugs. > > The code that causes the warnings should simply be fixed, unless it is > the contrib area, and would make merging harder, or if the warnings are > false positives. but lets take the follwing case: uint x; if (x < 0 | x > 256) this is correct code, yet clang will complain. so i think it's safe to set -Wno-error=tautological-compare on the other hand /usr/git-freebsd-head/sys/dev/ath/ath_hal/ar5212/ar5212_misc.c:577:24: warning: implicit conversion from enumeration type 'HAL_STATUS' to different enumeration type 'HAL_BOOL' [-Wconversion] return HAL_EINVAL; ~~ ^~ 1 warning generated. might be a problem, so -Wno-error=conversion should not be set and the case should be fixed inside the code. > > Only in the latter case, and only if clang cannot be fixed right now > (such as with the ?: operator problem), there should be a workaround. > And even then as local as possible, so share/mk/*.mk is not the right > place to add a fix. > > > > 1) this will only work with clang tot, since the clang version that ships > > with > >HEAD atm doesn't understand 'shift-count-negative'; it is being implied > > by > >-Werror and cannot be turned off seperately. > > 2) there is a bug in the clang version that ships with HEAD, where > > -Wno-error=X > >implies -WX. this is not correct (see gcc(1) man page) and was fixed in > >clang tot. > > I'll have a look if it's possible to import these. Since head now has > clang from the 3.0 release branch, and the idea is to ship FreeBSD 9.0 > with the 3.0 release, or something as close as possible to it, I don't > plan on importing clang trunk anytime soon. unfortunately latest clang tot is broken again. :( i got /usr/git-freebsd-head/sys/dev/sound/pcm/sound.c:85:2: error: invalid conversion specifier 'b' [-Werror,-Wformat-invalid-specifier] SNDSTAT_PREPARE_PCM_END(); ^~~~ although -Wno-error=format-invalid-specifier was specified. cheers. alex ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[poc] buildkernel + clang + -Werror
i'm sending this mail to the mailinglist simply to prevent my work being list.
i've experimented with the -Werror and -Wno-error= options and got to the point
where i was able to compile GENERIC on amd64 with clang:
#
# XXX The following options might indicate real problems and need to be
# investigated:
# array-bounds, conversion, format, format-security, shift-count-overflow,
# and shift-overflow.
#
.if ${CC:T:Mclang} == "clang"
WERROR?= -Werror -Wno-error=array-bounds -Wno-error=conversion \
-Wno-error=empty-body -Wno-error=format -Wno-error=format-extra-args \
-Wno-error=format-invalid-specifier -Wno-error=format-security \
-Wno-error=shift-count-negative -Wno-error=shift-count-overflow \
-Wno-error=shift-overflow -Wno-error=tautological-compare
.else
WERROR?= -Werror
.endif
a few drawbacks...
1) this will only work with clang tot, since the clang version that ships with
HEAD atm doesn't understand 'shift-count-negative'; it is being implied by
-Werror and cannot be turned off seperately.
2) there is a bug in the clang version that ships with HEAD, where -Wno-error=X
implies -WX. this is not correct (see gcc(1) man page) and was fixed in
clang tot.
3) the 'format-*' options are only necessary for clang tot, since it doesn't
understand '-fformat-extensions'. if 1) and 2) can be fixed and the clang
release that ships with HEAD can be used for compilation, the 'format-*'
options can probably be removed.
4) as noted in the comment, a few flags might indicate *real* issues in the
code. i've merely enabled these to prove that clang can in fact compile the
src with -Werror being set. however these options probably shouldn't be set,
but rather investigated.
cheers.
alex
ps: maybe the vendor commits that fixed 1) and 2) could be imported into the
the clang version in HEAD.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: state of clang(1)'s -Wshift-count-negative and -Wshift-overflow warnings
On Fri Nov 4 11, Alexander Best wrote:
> On Thu Nov 3 11, Dimitry Andric wrote:
> > On 2011-11-03 20:03, Alexander Best wrote:
> > > On Thu Nov 3 11, Dimitry Andric wrote:
> > >> On 2011-11-03 11:45, Alexander Best wrote:
> > >> ...
> > >>> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ar5210/ar5210_power.c:36:3:
> > >>> warning: signed shift result (0x2) requires 35 bits to
> > >>> represent, but 'int' only has 32 bits [-Wshift-overflow]
> > >>> OS_REG_RMW_FIELD(ah, AR_SCR, AR_SCR_SLE,
> > >>> AR_SCR_SLE_ALLOW);
> > >>>
> > >>> ^~
> > >>> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_internal.h:471:42: note:
> > >>> expanded from macro 'OS_REG_RMW_FIELD'
> > >>> (OS_REG_READ(_a, _r) &~ (_f)) | (((_v) << _f##_S) &
> > >>> (_f)))
> > >>>^
> > >>> /usr/git-freebsd-head/sys/dev/ath/ah_osdep.h:127:49: note: expanded
> > >>> from macro 'OS_REG_WRITE'
> > >>> (bus_space_handle_t)(_ah)->ah_sh, (_reg), (_val))
> > ...
> > >> Those warnings are bogus, and due to this bug:
> >
> > Actually, I was too quick with this one, since it isn't bogus. The
> > macro invocation:
> >
> > OS_REG_RMW_FIELD(ah, AR_SCR, AR_SCR_SLE, AR_SCR_SLE_ALLOW);
> >
> > ultimately expands to:
> >
> > bus_space_write_4((bus_space_tag_t)(ah)->ah_st,
> > (bus_space_handle_t)(ah)->ah_sh, (0x4004),
> > ((bus_space_read_4((bus_space_tag_t)(ah)->ah_st,
> > (bus_space_handle_t)(ah)->ah_sh, (0x4004)) &~ (0x0003)) |
> > (((0x0002) << 16) & (0x0003;
> >
> > The problem part is ((0x0002) << 16), which is an overflow. I'm not
> > sure how clang concludes that the result (0x2) needs 35 bits to
> > represent, as it seems to use 34 bits to me. But that it doesn't fit
> > into a signed integer is crystal-clear.
> >
> > E.g. this is a real bug! Probably something in the macro needs to
> > explicitly cast to 64 integers, or another workaround must be found.
> >
> > The other warning:
> >
> > > In file included from
> > > /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain.c:99:
> > > /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:69:15:
> > > warning: shift count is negative [-Wshift-count-negative]
> > > .chan11a = BM4(F1_4950_4980,
> > > ^
> > > /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:41:4:
> > > note: expanded from macro 'BM4'
> > > W1(_fa) | W1(_fb) | W1(_fc) | W1(_fd) }
> > > ^
> > > /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:34:45:
> > > note: expanded from macro 'W1'
> > > (((_a) > 63 && (_a) < 128 ? (((uint64_t) 1)<<((_a)-64)) :
> > > (uint64_t) 0))
> > >^ ~
> >
> > is indeed bogus, since the macro makes sure the shift count never
> > becomes negative. (N.B.: This only happens for global initializations,
> > *not* if you would use the same macro in a function.)
> >
> >
> > >> http://llvm.org/bugs/show_bug.cgi?id=10030
> > >>
> > >> Unfortunately, it is still not fixed for the 3.0 release branch, and I
> > >> don't expect it will be fixed for the actual release.
> > >
> > > thanks for the info. so how about something like
> > >
> > > diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk
> > > index a0a595f..3cb13de 100644
> > > --- a/sys/conf/kern.mk
> > > +++ b/sys/conf/kern.mk
> > > @@ -1,12 +1,28 @@
> > > # $FreeBSD$
> > >
> > > #
> > > -# Warning flags for compiling the kernel and components of the kernel:
> > > +# XXX Disable bogus llvm warnings, complaining about perfectly valid
> > > shifts.
> > > +# See http://llvm.org/bugs/show_bug.cgi?id=10030 for more details.
> > > +#
> > > +.if ${CC:T:Mclang} == "clang"
> > > +NOSHIFTWARNS= -Wno-shift-count-negative -Wno-shift-count-overflow \
> > > + -Wno-s
Re: state of clang(1)'s -Wshift-count-negative and -Wshift-overflow warnings
On Thu Nov 3 11, Dimitry Andric wrote:
> On 2011-11-03 20:03, Alexander Best wrote:
> > On Thu Nov 3 11, Dimitry Andric wrote:
> >> On 2011-11-03 11:45, Alexander Best wrote:
> >> ...
> >>> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ar5210/ar5210_power.c:36:3:
> >>> warning: signed shift result (0x2) requires 35 bits to represent,
> >>> but 'int' only has 32 bits [-Wshift-overflow]
> >>> OS_REG_RMW_FIELD(ah, AR_SCR, AR_SCR_SLE,
> >>> AR_SCR_SLE_ALLOW);
> >>> ^~
> >>> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_internal.h:471:42: note:
> >>> expanded from macro 'OS_REG_RMW_FIELD'
> >>> (OS_REG_READ(_a, _r) &~ (_f)) | (((_v) << _f##_S) & (_f)))
> >>>^
> >>> /usr/git-freebsd-head/sys/dev/ath/ah_osdep.h:127:49: note: expanded from
> >>> macro 'OS_REG_WRITE'
> >>> (bus_space_handle_t)(_ah)->ah_sh, (_reg), (_val))
> ...
> >> Those warnings are bogus, and due to this bug:
>
> Actually, I was too quick with this one, since it isn't bogus. The
> macro invocation:
>
> OS_REG_RMW_FIELD(ah, AR_SCR, AR_SCR_SLE, AR_SCR_SLE_ALLOW);
>
> ultimately expands to:
>
> bus_space_write_4((bus_space_tag_t)(ah)->ah_st,
> (bus_space_handle_t)(ah)->ah_sh, (0x4004),
> ((bus_space_read_4((bus_space_tag_t)(ah)->ah_st,
> (bus_space_handle_t)(ah)->ah_sh, (0x4004)) &~ (0x0003)) | (((0x0002)
> << 16) & (0x0003;
>
> The problem part is ((0x0002) << 16), which is an overflow. I'm not
> sure how clang concludes that the result (0x2) needs 35 bits to
> represent, as it seems to use 34 bits to me. But that it doesn't fit
> into a signed integer is crystal-clear.
>
> E.g. this is a real bug! Probably something in the macro needs to
> explicitly cast to 64 integers, or another workaround must be found.
>
> The other warning:
>
> > In file included from
> > /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain.c:99:
> > /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:69:15:
> > warning: shift count is negative [-Wshift-count-negative]
> > .chan11a = BM4(F1_4950_4980,
> > ^
> > /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:41:4:
> > note: expanded from macro 'BM4'
> > W1(_fa) | W1(_fb) | W1(_fc) | W1(_fd) }
> > ^
> > /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:34:45:
> > note: expanded from macro 'W1'
> > (((_a) > 63 && (_a) < 128 ? (((uint64_t) 1)<<((_a)-64)) :
> > (uint64_t) 0))
> >^ ~
>
> is indeed bogus, since the macro makes sure the shift count never
> becomes negative. (N.B.: This only happens for global initializations,
> *not* if you would use the same macro in a function.)
and what about this one?
/usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:629:15:
error: shift count >= width of type [-Werror,-Wshift-count-overflow]
.chan11a = BM4(W2_5260_5320,
^
/usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:40:34:
note: expanded from macro 'BM4'
{ W0(_fa) | W0(_fb) | W0(_fc) | W0(_fd),\
^
/usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:32:44:
note: expanded from macro 'W0'
(((_a) >= 0 && (_a) < 64 ? (((uint64_t) 1)<<(_a)) : (uint64_t) 0))
^
this is being reported by -Wshift-count-overflow and not
-Wshift-count-negative, like the other ones.
cheers.
alex
>
>
> >> http://llvm.org/bugs/show_bug.cgi?id=10030
> >>
> >> Unfortunately, it is still not fixed for the 3.0 release branch, and I
> >> don't expect it will be fixed for the actual release.
> >
> > thanks for the info. so how about something like
> >
> > diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk
> > index a0a595f..3cb13de 100644
> > --- a/sys/conf/kern.mk
> > +++ b/sys/conf/kern.mk
> > @@ -1,12 +1,28 @@
> > # $FreeBSD$
> >
> > #
> > -# Warning flags for compiling the kernel and
Re: state of clang(1)'s -Wshift-count-negative and -Wshift-overflow warnings
On Thu Nov 3 11, Dimitry Andric wrote:
> On 2011-11-03 20:03, Alexander Best wrote:
> > On Thu Nov 3 11, Dimitry Andric wrote:
> >> On 2011-11-03 11:45, Alexander Best wrote:
> >> ...
> >>> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ar5210/ar5210_power.c:36:3:
> >>> warning: signed shift result (0x2) requires 35 bits to represent,
> >>> but 'int' only has 32 bits [-Wshift-overflow]
> >>> OS_REG_RMW_FIELD(ah, AR_SCR, AR_SCR_SLE,
> >>> AR_SCR_SLE_ALLOW);
> >>> ^~
> >>> /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_internal.h:471:42: note:
> >>> expanded from macro 'OS_REG_RMW_FIELD'
> >>> (OS_REG_READ(_a, _r) &~ (_f)) | (((_v) << _f##_S) & (_f)))
> >>>^
> >>> /usr/git-freebsd-head/sys/dev/ath/ah_osdep.h:127:49: note: expanded from
> >>> macro 'OS_REG_WRITE'
> >>> (bus_space_handle_t)(_ah)->ah_sh, (_reg), (_val))
> ...
> >> Those warnings are bogus, and due to this bug:
>
> Actually, I was too quick with this one, since it isn't bogus. The
> macro invocation:
>
> OS_REG_RMW_FIELD(ah, AR_SCR, AR_SCR_SLE, AR_SCR_SLE_ALLOW);
>
> ultimately expands to:
>
> bus_space_write_4((bus_space_tag_t)(ah)->ah_st,
> (bus_space_handle_t)(ah)->ah_sh, (0x4004),
> ((bus_space_read_4((bus_space_tag_t)(ah)->ah_st,
> (bus_space_handle_t)(ah)->ah_sh, (0x4004)) &~ (0x0003)) | (((0x0002)
> << 16) & (0x0003;
>
> The problem part is ((0x0002) << 16), which is an overflow. I'm not
> sure how clang concludes that the result (0x2) needs 35 bits to
> represent, as it seems to use 34 bits to me. But that it doesn't fit
> into a signed integer is crystal-clear.
>
> E.g. this is a real bug! Probably something in the macro needs to
> explicitly cast to 64 integers, or another workaround must be found.
>
> The other warning:
>
> > In file included from
> > /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain.c:99:
> > /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:69:15:
> > warning: shift count is negative [-Wshift-count-negative]
> > .chan11a = BM4(F1_4950_4980,
> > ^
> > /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:41:4:
> > note: expanded from macro 'BM4'
> > W1(_fa) | W1(_fb) | W1(_fc) | W1(_fd) }
> > ^
> > /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:34:45:
> > note: expanded from macro 'W1'
> > (((_a) > 63 && (_a) < 128 ? (((uint64_t) 1)<<((_a)-64)) :
> > (uint64_t) 0))
> >^ ~
>
> is indeed bogus, since the macro makes sure the shift count never
> becomes negative. (N.B.: This only happens for global initializations,
> *not* if you would use the same macro in a function.)
>
>
> >> http://llvm.org/bugs/show_bug.cgi?id=10030
> >>
> >> Unfortunately, it is still not fixed for the 3.0 release branch, and I
> >> don't expect it will be fixed for the actual release.
> >
> > thanks for the info. so how about something like
> >
> > diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk
> > index a0a595f..3cb13de 100644
> > --- a/sys/conf/kern.mk
> > +++ b/sys/conf/kern.mk
> > @@ -1,12 +1,28 @@
> > # $FreeBSD$
> >
> > #
> > -# Warning flags for compiling the kernel and components of the kernel:
> > +# XXX Disable bogus llvm warnings, complaining about perfectly valid
> > shifts.
> > +# See http://llvm.org/bugs/show_bug.cgi?id=10030 for more details.
> > +#
> > +.if ${CC:T:Mclang} == "clang"
> > +NOSHIFTWARNS= -Wno-shift-count-negative -Wno-shift-count-overflow \
> > + -Wno-shift-overflow
> > +.endif
> > +
> >
> > ...and then add ${NOSHIFTWARNS} to the end of CWARNFLAGS?
>
> No, this is a way too big hammer, because it eliminates the useful
> warnings together with the false positives.
maybe we could do the following for clang:
.if ${CC:T:Mclang} == "clang"
WERROR?= -Werror -Wno-error=shift-count-negative ...
.else
WERROR?= -Werror
.endif
that way we could keep the warnings, but don't turn them into errors. the same
could be done for warnings such as -Wtautological-compare.
cheers.
alex
ps: could you submit the PR? i'm not really familar with how llvm expands
certain expressions.
>
> It would be better to only apply this band-aid for the specific source
> files that need it, and even then, I would rather wait for the proper
> fix from upstream.
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: state of clang(1)'s -Wshift-count-negative and -Wshift-overflow warnings
On Thu Nov 3 11, Dimitry Andric wrote:
> On 2011-11-03 11:45, Alexander Best wrote:
> ...
> > /usr/git-freebsd-head/sys/dev/ath/ath_hal/ar5210/ar5210_power.c:36:3:
> > warning: signed shift result (0x2) requires 35 bits to represent,
> > but 'int' only has 32 bits [-Wshift-overflow]
> > OS_REG_RMW_FIELD(ah, AR_SCR, AR_SCR_SLE, AR_SCR_SLE_ALLOW);
> > ^~
> > /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_internal.h:471:42: note:
> > expanded from macro 'OS_REG_RMW_FIELD'
> > (OS_REG_READ(_a, _r) &~ (_f)) | (((_v) << _f##_S) & (_f)))
> >^
> > /usr/git-freebsd-head/sys/dev/ath/ah_osdep.h:127:49: note: expanded from
> > macro 'OS_REG_WRITE'
> > (bus_space_handle_t)(_ah)->ah_sh, (_reg), (_val))
> >
> > iirc, back then, it was labeled as a clang bug. however testing with clang
> > tot,
> > i still get those warnings. so i just wanted to ask again, whether the
> > warnings
> > are really bogus, or if these warnings actually indicate issues during
> > shifting?
>
> Those warnings are bogus, and due to this bug:
>
> http://llvm.org/bugs/show_bug.cgi?id=10030
>
> Unfortunately, it is still not fixed for the 3.0 release branch, and I
> don't expect it will be fixed for the actual release.
thanks for the info. so how about something like
diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk
index a0a595f..3cb13de 100644
--- a/sys/conf/kern.mk
+++ b/sys/conf/kern.mk
@@ -1,12 +1,28 @@
# $FreeBSD$
#
-# Warning flags for compiling the kernel and components of the kernel:
+# XXX Disable bogus llvm warnings, complaining about perfectly valid shifts.
+# See http://llvm.org/bugs/show_bug.cgi?id=10030 for more details.
+#
+.if ${CC:T:Mclang} == "clang"
+NOSHIFTWARNS= -Wno-shift-count-negative -Wno-shift-count-overflow \
+ -Wno-shift-overflow
+.endif
+
...and then add ${NOSHIFTWARNS} to the end of CWARNFLAGS?
cheers.
alex
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [toolchain] disable -Wtautological-compare for clang
On Mon Oct 17 11, Warner Losh wrote: > I'm all for leaving it on because things like char are signed on some > architectures and unsigned on others. This leads to bugs that only appear on > one architecture. This warning will, at least, flag those usages. -funsigned-char / -fsigned-char could be used in that case. cheers. alex > > On Oct 17, 2011, at 10:56 AM, Gerald Pfeifer wrote: > > > On Mon, 17 Oct 2011, Alexander Best wrote: > >> any chance we could disable -Wtautological-compare for clang? i don't > >> think comparing an unsigned int against < 0 is worth a warning. actually > >> it's always nice to have such a seatbelt, in case somebody changes the > >> type to int and forgets to introduce such a check. > > > > I am on the fence on this one, for when I used the equivalent warning > > in GCC this did found a number of real issues that I then addressed for > > Wine (as an example). > > > > Gerald > > ___ > > freebsd-toolchain@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" > > > > > ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [toolchain] disable -Wtautological-compare for clang
On Mon Oct 17 11, Gerald Pfeifer wrote: > On Tue, 18 Oct 2011, Matthias Andree wrote: > >> any chance we could disable -Wtautological-compare for clang? i don't > >> think comparing an unsigned int against < 0 is worth a warning. > >> actually it's always nice to have such a seatbelt, in case somebody > >> changes the type to int and forgets to introduce such a check. > > If your code must be unclean in such a way that it uses deliberately > > dead code "just in case someone breaks the semantics", can you not use > > -Wno-tautological-compare in that situation? > > It's not as straightforward, sadly, which is why I mentioned I am > on the fence somehow. > > if (TYPE_MIN <= var && var <= TYPE_MAX) > > or > > if (var < TYPE_MIN || var > TYPE_MAX) > > are not that uncommon, in well written application, and if TYPE_MIN > then evaluates to 0, we'll get a warning. > > > Unless someone goes to paranoia mode and sprays unneeded checks like you > > suggest all over the code like an ugly graffity, all such warnings are > > worth investigating. In code I've hand my eyes and/or hands on, the > > better part of these warnings were pointing to true bugs. > > In my experience some were, while others were of the class above. however keeping these checks means that for gcc we can never turn on -Wextra, since it enables these checks. while, running clang they can be turned off via "-Wno-tautological-compare", there's no way of turning them off under gcc, except for removing the -Wextra flag again. cheers. alex > > Gerald ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
state of clang(1)'s -Wshift-count-negative and -Wshift-overflow warnings
hi there, i think the following warnings were discussed once before: In file included from /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain.c:99: /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:69:15: warning: shift count is negative [-Wshift-count-negative] .chan11a = BM4(F1_4950_4980, ^ /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:41:4: note: expanded from macro 'BM4' W1(_fa) | W1(_fb) | W1(_fc) | W1(_fd) } ^ /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_regdomain/ah_rd_domains.h:34:45: note: expanded from macro 'W1' (((_a) > 63 && (_a) < 128 ? (((uint64_t) 1)<<((_a)-64)) : (uint64_t) 0)) and /usr/git-freebsd-head/sys/dev/ath/ath_hal/ar5210/ar5210_power.c:36:3: warning: signed shift result (0x2) requires 35 bits to represent, but 'int' only has 32 bits [-Wshift-overflow] OS_REG_RMW_FIELD(ah, AR_SCR, AR_SCR_SLE, AR_SCR_SLE_ALLOW); ^~ /usr/git-freebsd-head/sys/dev/ath/ath_hal/ah_internal.h:471:42: note: expanded from macro 'OS_REG_RMW_FIELD' (OS_REG_READ(_a, _r) &~ (_f)) | (((_v) << _f##_S) & (_f))) ^ /usr/git-freebsd-head/sys/dev/ath/ah_osdep.h:127:49: note: expanded from macro 'OS_REG_WRITE' (bus_space_handle_t)(_ah)->ah_sh, (_reg), (_val)) iirc, back then, it was labeled as a clang bug. however testing with clang tot, i still get those warnings. so i just wanted to ask again, whether the warnings are really bogus, or if these warnings actually indicate issues during shifting? cheers. alex ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
disable -Wtautological-compare for clang
hi there, any chance we could disable -Wtautological-compare for clang? i don't think comparing an unsigned int against < 0 is worth a warning. actually it's always nice to have such a seatbelt, in case somebody changes the type to int and forgets to introduce such a check. cheers. alex ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
small patch to get rid of -frename-registers when using clang
hi there,
any thoughts regarding this patch? it makes sure -frename-registers doesn't get
used, when the compiler is clang. nothing spectacular, but it cleans up stdout
a bit.
it also makes sure that when debugging was enabled, amd64 gets compiled with
-O instead of -O2, just like all the other archs. i'm not sure, if this is
really the right thing to do, but i don't really understand the current
behavior. why should -O2 be set, when the users indicated that he wants to
compile a kernel for debugging? sure amd64 supports debugging with -O2, as
noted in the svn history of kern.pre.mk. however even on amd64 a -O2 kernel
and a -O kernel aren't the same when it comes to debugging capabilities.
however, i'm not really sure about this. bde@ probably has an opinion regarding
this matter.
cheers.
alex
diff --git a/sys/conf/kern.pre.mk b/sys/conf/kern.pre.mk
index 2320b89..badf7ef 100644
--- a/sys/conf/kern.pre.mk
+++ b/sys/conf/kern.pre.mk
@@ -33,8 +33,8 @@ _MINUS_O= -O # gcc miscompiles some code at -O2
_MINUS_O= -O2
.endif
.endif
-.if ${MACHINE_CPUARCH} == "amd64"
-COPTFLAGS?=-O2 -frename-registers -pipe
+.if ${MACHINE_CPUARCH} == "amd64" && ${CC:T:Mclang} != "clang"
+COPTFLAGS?=${_MINUS_O} -frename-registers -pipe
.else
COPTFLAGS?=${_MINUS_O} -pipe
.endif
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported
On Sun Aug 21 11, Dimitry Andric wrote:
> On 2011-08-19 10:01, Alexander Best wrote:
> >On Thu Aug 18 11, Dimitry Andric wrote:
> ...
> >>Please use the following fragment instead, which is recommended on
> >><http://wiki.freebsd.org/BuildingFreeBSDWithClang>:
> >thanks. that fixed the issue. seeing forward to simply setting CC/CXX/CPP
> >to
> >clang or gcc directly and also to using "/", so one can use absolute paths.
>
> Please try the attached patch, which makes it possible to set CC and CXX
> in make.conf, while allowing the build32 stage to still override them.
>
> Explanation:
> 1) The build32 stage sets environment variables CC, CXX, AS and LD for
>its sub-make, to add 32-bit specific flags (-m32 and such).
> 2) The sub-make reads sys.mk, encounters CC?= and CXX?= assignments, so
>does not alter them.
> 3) After some other stuff, sys.mk reads /etc/make.conf. When you have
>"CC=xxx" and "CXX=yyy" statements in there, they will *override* the
>build32-supplied CC/CXX values, nullifying the 32-bit specific flags.
> 4) Thus all objects get built as 64-bit anyway, and since LD is usually
>not set in make.conf, it still has the 32-bit flags!
> 5) Now, whenever something is linked, you will get a "ld: Relocatable
>linking with relocations from format elf64-x86-64-freebsd (foo.o) to
>format elf32-i386-freebsd (bar.o) is not supported" error.
>
> The patch fixes this by adding "-ECC -ECXX -EAS -ELD" to the build32
> sub-make invocation, which forces those environment variables to always
> override any assignment in makefiles.
>
> It makes it possible to simply do:
>
> CC=clang
> CXX=clang++
>
> in your make.conf, or specify a path, even:
>
> CC=/usr/local/bin/gcc46
> CXX=/usr/local/bin/g++46
>
> Note this was already possible on i386, but not yet on amd64. Also,
> strange things might happen if you set CC but not CXX, or vice versa...
any chance this patch can be committed?
cheers.
alex
> Index: Makefile.inc1
> ===
> --- Makefile.inc1 (revision 224934)
> +++ Makefile.inc1 (working copy)
> @@ -313,7 +313,8 @@
>
> LIB32WMAKE= ${LIB32WMAKEENV} ${MAKE} -DNO_CPU_CFLAGS -DCOMPAT_32BIT \
> -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO \
> - -DWITHOUT_HTML -DNO_CTF -DNO_LINT DESTDIR=${LIB32TMP}
> + -DWITHOUT_HTML -DNO_CTF -DNO_LINT -ECC -ECXX -EAS -ELD \
> + DESTDIR=${LIB32TMP}
> LIB32IMAKE= ${LIB32WMAKE:NINSTALL=*:NDESTDIR=*} -DNO_INCS
> .endif
>
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported
On Sun Aug 21 11, Dimitry Andric wrote:
> On 2011-08-19 10:01, Alexander Best wrote:
> >On Thu Aug 18 11, Dimitry Andric wrote:
> ...
> >>Please use the following fragment instead, which is recommended on
> >><http://wiki.freebsd.org/BuildingFreeBSDWithClang>:
> >thanks. that fixed the issue. seeing forward to simply setting CC/CXX/CPP
> >to
> >clang or gcc directly and also to using "/", so one can use absolute paths.
>
> Please try the attached patch, which makes it possible to set CC and CXX
> in make.conf, while allowing the build32 stage to still override them.
>
> Explanation:
> 1) The build32 stage sets environment variables CC, CXX, AS and LD for
>its sub-make, to add 32-bit specific flags (-m32 and such).
> 2) The sub-make reads sys.mk, encounters CC?= and CXX?= assignments, so
>does not alter them.
> 3) After some other stuff, sys.mk reads /etc/make.conf. When you have
>"CC=xxx" and "CXX=yyy" statements in there, they will *override* the
>build32-supplied CC/CXX values, nullifying the 32-bit specific flags.
> 4) Thus all objects get built as 64-bit anyway, and since LD is usually
>not set in make.conf, it still has the 32-bit flags!
> 5) Now, whenever something is linked, you will get a "ld: Relocatable
>linking with relocations from format elf64-x86-64-freebsd (foo.o) to
>format elf32-i386-freebsd (bar.o) is not supported" error.
>
> The patch fixes this by adding "-ECC -ECXX -EAS -ELD" to the build32
> sub-make invocation, which forces those environment variables to always
> override any assignment in makefiles.
>
> It makes it possible to simply do:
>
> CC=clang
> CXX=clang++
>
> in your make.conf, or specify a path, even:
>
> CC=/usr/local/bin/gcc46
> CXX=/usr/local/bin/g++46
>
> Note this was already possible on i386, but not yet on amd64. Also,
> strange things might happen if you set CC but not CXX, or vice versa...
thanks a bunch. both buildworld and buildkernel succeeded with CC, CXX and
CPP set explicitly to the absolute clang location. :)
cheers.
alex
> Index: Makefile.inc1
> ===
> --- Makefile.inc1 (revision 224934)
> +++ Makefile.inc1 (working copy)
> @@ -313,7 +313,8 @@
>
> LIB32WMAKE= ${LIB32WMAKEENV} ${MAKE} -DNO_CPU_CFLAGS -DCOMPAT_32BIT \
> -DWITHOUT_BIND -DWITHOUT_MAN -DWITHOUT_INFO \
> - -DWITHOUT_HTML -DNO_CTF -DNO_LINT DESTDIR=${LIB32TMP}
> + -DWITHOUT_HTML -DNO_CTF -DNO_LINT -ECC -ECXX -EAS -ELD \
> + DESTDIR=${LIB32TMP}
> LIB32IMAKE= ${LIB32WMAKE:NINSTALL=*:NDESTDIR=*} -DNO_INCS
> .endif
>
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported
On Thu Aug 18 11, Dimitry Andric wrote:
> On 2011-08-18 19:35, Alexander Best wrote:
> ...
> >>>ld: Relocatable linking with relocations from format elf64-x86-64-freebsd
> >>>(crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported
> >>Most likely, this is because you are forcing CC=clang, which does not
> >>work as expected. Can you please post your /etc/make.conf and
> >>/etc/src.conf files, and show us any environment variables related to
> >>buildworld? Also, how exactly are you running make buildworld?
> >
> >i've attached my src.conf, my make.conf and the output of 'env'. nothing
> >special, i'm using a simple 'make buildworld'.
>
> The problem is in your make.conf. Effectively, you are doing:
>
> CC = clang
> CXX = clang++
>
> which will not work, at least not for the 32-bit compat stage on amd64.
> Please use the following fragment instead, which is recommended on
> <http://wiki.freebsd.org/BuildingFreeBSDWithClang>:
>
> .if !defined(CC) || ${CC} == "cc"
> CC=clang
> .endif
> .if !defined(CXX) || ${CXX} == "c++"
> CXX=clang++
> .endif
> .if !defined(CPP) || ${CPP} == "cpp"
> CPP=clang -E
> .endif
thanks. that fixed the issue. seeing forward to simply setting CC/CXX/CPP to
clang or gcc directly and also to using "/", so one can use absolute paths.
cheers.
alex
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported
On Thu Aug 18 11, Dimitry Andric wrote: > On 2011-08-18 07:01, Alexander Best wrote: > >i'm getting this error, when trying to make target buildwork with clang. > > You mean with "make target buildwork", that you are running "make > buildworld TARGET=whatever", right? > > ... > >this is the error i'm getting: > > > >===> lib/csu/i386-elf (obj,depend,all,install) > ... > >clang -O2 -pipe -fno-strict-aliasing -fno-omit-frame-pointer > >-frename-registers -I/usr/git-freebsd-head/lib/csu/i386-elf/../common > >-I/usr/git-freebsd-head/lib/csu/i386-elf/../../libc/include -DSTRIP_FBSDID > >-std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -Wextra > >-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > >-Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch > >-Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline > >-Wnested-externs -Wredundant-decls -Wold-style-definition > >-Wno-pointer-sign -c /usr/git-freebsd-head/lib/csu/i386-elf/crt1_s.S > >clang: warning: argument unused during compilation: '-frename-registers' > >ld -m elf_i386_fbsd -Y P,/usr/obj/usr/git-freebsd-head/lib32/usr/lib32 -o > >gcrt1.o -r crt1_s.o gcrt1_c.o > >ld: Relocatable linking with relocations from format elf64-x86-64-freebsd > >(crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported > > Most likely, this is because you are forcing CC=clang, which does not > work as expected. Can you please post your /etc/make.conf and > /etc/src.conf files, and show us any environment variables related to > buildworld? Also, how exactly are you running make buildworld? i've attached my src.conf, my make.conf and the output of 'env'. nothing special, i'm using a simple 'make buildworld'. i'm now trying to reproduce the issue with a fresh src snapshot cheers. alex # WORLD/KERNEL options KERNCONF = ARUNDEL #KERNCONF = GENERIC #MODULES_OVERRIDE = \ #netgraph/netgraph netgraph/socket netgraph/bluetooth/bluetooth \ #netgraph/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket \ #netgraph/bluetooth/ubt tmpfs sound/sound sound/driver/hda usb/uhid \ #procfs pseudofs linux linprocfs linsysfs lindev usb/quirk geom \ #MODULES_OVERRIDE = MODULES_WITH_WORLD = yes #opensolaris dtrace cyclic nfsclient krpc nfs_common nfslock usb/quirk geom #CC = /usr/local/bin/clang# -B/usr/bin CC = clang #CC = /usr/bin/clang #CC= /usr/local/bin/pcc #CXX = /usr/local/bin/clang++# -B/usr/bin CXX = clang++ #CC=/usr/bin/cc #CXX=/usr/bin/c++ #CPP=/usr/bin/cpp # compiler flags CPUTYPE ?= core2 #COPTFLAGS = -O2 -pipe -fno-builtin -frename-registers -fno-strict-aliasing #COPTFLAGS = -O3 -pipe -fno-inline-functions# -frename-registers# -fno-builtin -fno-strict-aliasing CFLAGS = -O2 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -frename-registers# -fno-builtin #CFLAGS = -O3 -pipe -fno-inline-functions -fno-omit-frame-pointer -fno-strict-aliasing -fno-builtin -frename-registers # SENDMAIL options SENDMAIL_MC = /etc/mail/freebsd.mc SENDMAIL_SUBMIT_MC = /etc/mail/freebsd.submit.mc # PORTS options OVERRIDE_LINUX_BASE_PORT = f10 OVERRIDE_LINUX_NONBASE_PORTS = f10 DA4 = yes WITH_BSDEL = yes WITH_256_COLOR = yes WITH_LCD_FILTERING = yes GENTOO_OPTIMIZED = i686 # added by use.perl 2011-08-15 19:48:33 PERL_VERSION=5.12.4 # Don't die on warnings NO_WERROR= WERROR= # Don't forget this when using Jails! #NO_FSCHG= #CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes\ # -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual\ # -Wundef -Wmissing-include-dirs # Enable debugging symbols for world CFLAGS += -DSTRIP_FBSDID BURN_BRIDGES=yes # BUILDWORLD options BOOT2_UFS=UFS2_ONLY # don't need UFS1 support anymore GPTBOOT_UFS=UFS2_ONLY # don't need UFS1 support anymore WITHOUT_ACCT=true #WITHOUT_ACPI=true # needed by VirtualBox WITHOUT_AMD=true WITHOUT_APM=true #WITHOUT_ASSERT_DEBUG=true # broken WITHOUT_AT=true WITHOUT_ATM=true WITHOUT_AUDIT=true WITHOUT_BIND=true WITHOUT_GPIO=true WITH_BSD_GREP=true WITHOUT_BSNMP=true WITHOUT_CALENDAR=true #WITHOUT_CDDL=true # needed for dtrace WITHOUT_CTM=true WITHOUT_CVS=true WITHOUT_FLOPPY=true #WITHOUT_FORTH=true # needed for bootloader WITHOUT_FREEBSD_UPDATE=true WITHOUT_GAMES=true #WITHOUT_GNU=true # no effect WITHOUT_GPIB=true #WITHOUT_GSSAPI=true# needed for md2() WITHOUT_HTML=true WITH_IDEA=true WITHOUT_INET6=true #WITHOUT_INFO=true # needed by ports (`install-info`) #WITHOUT_INSTALLLIB=yes # DON'T USE WITHOUT_IPFILTER=true WITHOUT_IPFW=true WITHOUT_IPX=true WITHOUT_JAIL=true WITHOUT_KERBEROS=true # possible? WITHOUT_KERBEROS_SUPPORT=true WITHOUT_LP
Relocatable linking with relocations from format elf64-x86-64-freebsd (crt1_s.o) to format elf32-i386-freebsd (gcrt1.o) is not supported
hi there, i'm getting this error, when trying to make target buildwork with clang. i think this issue was discussed beforehand, but i can't seem to find the old thread. this is the error i'm getting: ===> lib/csu/i386-elf (obj,depend,all,install) rm -f .depend CC='clang' mkdep -f .depend -a -I/usr/git-freebsd-head/lib/csu/i386-elf/../common -I/usr/git-freebsd-head/lib/csu/i386-elf/../../libc/include -DSTRIP_FBSDID /usr/git-freebsd-head/lib/csu/i386-elf/crti.S /usr/git-freebsd-head/lib/csu/i386-elf/crtn.S clang -O2 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -frename-registers -I/usr/git-freebsd-head/lib/csu/i386-elf/../common -I/usr/git-freebsd-head/lib/csu/i386-elf/../../libc/include -DSTRIP_FBSDID -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -Wextra -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/git-freebsd-head/lib/csu/i386-elf/crti.S clang: warning: argument unused during compilation: '-frename-registers' clang -O2 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -frename-registers -I/usr/git-freebsd-head/lib/csu/i386-elf/../common -I/usr/git-freebsd-head/lib/csu/i386-elf/../../libc/include -DSTRIP_FBSDID -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -Wextra -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /usr/git-freebsd-head/lib/csu/i386-elf/crtn.S clang: warning: argument unused during compilation: '-frename-registers' clang -O2 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -frename-registers -I/usr/git-freebsd-head/lib/csu/i386-elf/../common -I/usr/git-freebsd-head/lib/csu/i386-elf/../../libc/include -DSTRIP_FBSDID -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -Wextra -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -DGCRT -S -o gcrt1_c.s /usr/git-freebsd-head/lib/csu/i386-elf/crt1_c.c clang: warning: argument unused during compilation: '-frename-registers' sed -i "" -e '/\.note\.ABI-tag/s/progbits/note/' gcrt1_c.s clang -O2 -pipe -fno-strict-aliasing -fno-omit-frame-pointer -frename-registers -I/usr/git-freebsd-head/lib/csu/i386-elf/../common -I/usr/git-freebsd-head/lib/csu/i386-elf/../../libc/include -DSTRIP_FBSDID -std=gnu99 -Wsystem-headers -Wall -Wno-format-y2k -Wextra -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c -o gcrt1_c.o gcrt1_c.s clang: warning: argument unused during compilation: '-fno-strict-aliasing' clang: warning: argument unused during compilation: '-fno-omit-frame-pointer' clang: warning: argument unused during compilation: '-frename-registers' clang: warning: argument unused during compilation: '-I /usr/git-freebsd-head/lib/csu/i386-elf/../common' clang: warning: argument unused during compilation: '-I /usr/git-freebsd-head/lib/csu/i386-elf/../../libc/include' clang: warning: argument unused during compilation: '-D STRIP_FBSDID' clang: warning: argument unused during compilation: '-std=gnu99' clang: warning: argument unused during compilation: '-Wsystem-headers' clang: warning: argument unused during compilation: '-Wall' clang: warning: argument unused during compilation: '-Wno-format-y2k' clang: warning: argument unused during compilation: '-Wextra' clang: warning: argument unused during compilation: '-Wno-unused-parameter' clang: warning: argument unused during compilation: '-Wstrict-prototypes' clang: warning: argument unused during compilation: '-Wmissing-prototypes' clang: warning: argument unused during compilation: '-Wpointer-arith' clang: warning: argument unused during compilation: '-Wreturn-type' clang: warning: argument unused during compilation: '-Wcast-qual' clang: warning: argument unused during compilation: '-Wwrite-strings' clang: warning: argument unused during compilation: '-Wswitch' clang: warning: argument unused during compilation: '-Wshadow' clang: warning: argument unused during compilation: '-Wunused-parameter' clang: warning: argument unused during compilation: '-Wcast-align' clang: warning: argument unused during compilation: '-Wchar-subscripts' clang: warning: argument unused during compilation: '-Winline' clang: warning: argument unused during compilation: '-Wnested-exter
Re: -128 errors after compiling kernel with clang tot (was: two issues after upgrading to a more up-to-date HEAD)
On Sat Jun 25 11, Alexander Best wrote: > On Fri Jun 17 11, Alexander Best wrote: > > On Thu Jun 16 11, Alexander Best wrote: > > > hi there, > > > > i reverted my kernel back to r222890. everything works fine now and both > > issues > > i mentioned below dissapeared. > > the previous issues (xpt_action_default and DIOCSKERNELDUMP) have been fixed. > however this one, where a lot of apps fail with errno -128 when accessing the > disk, still exists. this really needs to be fixed before 9.0! > > ...again...reverting to r222890 solves this completely. so it's not a problem > with the disk or anything. > > ..i'm guessing this is ahci related, but i'm not sure. i was able to solve the issue. it seems clang tot was responsible for the problem. i reverted back to compiling the kernel with gcc and the issue dissapeared. i haven't tried with the clang revision that ships with world. i think this problem only occurs with a more recent version of clang though. cheers. alex ps: i've added freebsd-toolchain to CC. maybe some of the freebsd clang people could confirm the issues with clang tot i was seeing. > > cheers. > alex > > > > > i also discovered another issue with the more recent kernel: > > > > i was getting errno -128 with a lot of apps. but only the first time i ran > > them. e.g. with git: > > > > 1) -128 > > 2) OK > > 3) -128 > > 4) OK > > 5) ... > > > > the same with stuff like ./configure or ee(1). first time failures while > > running or saving; second time it works. > > > > this as well was fixed by reverting back to r222890. > > > > cheers. > > alex > > > > > > > > i'm running HEAD on amd64. yesterday i updated my kernel to r223109. i'm > > > now > > > seeing two issues, which weren't there beforehand: > > > > > > 1) > > > ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 > > > ada0: ATA-7 SATA 2.x device > > > ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > > > ada0: Command Queueing enabled > > > ada0: 238474MB (488395055 512 byte sectors: 16H 63S/T 16383C) > > > ada1 at ahcich1 bus 0 scbus1 target 0 lun 0 > > > ada1: ATA-8 SATA 2.x device > > > ada1: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) > > > ada1: Command Queueing enabled > > > ada1: 953869MB (1953525168 512 byte sectors: 16H 63S/T 16383C) > > > xpt_action_default: CCB type 0xe not supported > > > xpt_action_default: CCB type 0xe not supported > > > xpt_action_default: CCB type 0xe not supported > > > cd0 at ahcich2 bus 0 scbus2 target 0 lun 0 > > > cd0: Removable CD-ROM SCSI-0 device > > > SMP: AP CPU #1 Launched! > > > cd0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes) > > > cd0: cd present [2291664 x 2048 byte records] > > > > > > ^^ i suspect the xpt_action_default messages have been introduced by the > > > recent > > > CAM changes. they appear to be harmless though. > > > > > > 2) > > > dumpon: ioctl(DIOCSKERNELDUMP): Device not configured > > > /etc/rc: WARNING: unable to specify /dev/label/swapfs as a dump device > > > > > > /dev/label/swapfs is a perfect swap partition and worked without any > > > problems > > > beforehand. specifying the device node instead of the label makes no > > > difference: > > > > > > taku% dumpon /dev/ada1p1 > > > dumpon: ioctl(DIOCSKERNELDUMP): Device not configured > > > otaku% gpart show > > > => 34 488394988 ada0 GPT (232G) > > > 34128 1 freebsd-boot (64k) > > > 162 16777216- free - (8.0G) > > >16777378 471617644 3 freebsd-ufs (224G) > > > > > > =>34 1953525101 ada1 GPT (931G) > > > 3420971520 1 freebsd-swap (10G) > > > 20971554 4194304 2 freebsd-ufs (2.0G) > > > 25165858 1928359277 3 freebsd-ufs (919G) > > > > > > otaku% glabel status > > > Name Status Components > > > label/boot N/A ada0p1 > > > gptid/e52df583-e446-11de-bb92-000fb58207c8 N/A ada0p1 > > > ufs/rootfs N/A ada0p3 > > > label/swapfs N/A ada1p1 > > > ufs/varfs N/A ada1p2 > > > ufs/usrfs N/A ada1p3 > > > iso9660/Futurama Season 6 Ep 1-8 720p N/A cd0 > > > > > > cheers. > > > alex > > > > > > -- > > > a13x > > > > -- > > a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [rfc] a few kern.mk and bsd.sys.mk related changes
On Tue May 31 11, Dimitry Andric wrote:
> On 2011-05-31 16:39, Alexander Best wrote:
> ...
> >...which leads me to the conclusion that -O should be set when DEBUG was
> >defined: an all ARCHS.
> >
> >right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the
> >kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior?
> >shouldn't
> >-fno-omit-frame-pointer be set uncondtitionally on all archs?
>
> No, not unconditionally on all archs. Some arches have no problem
> debugging when gcc's frame pointer is turned off, namely arm, ia64,
> mips, powerpc and sparc, if I read the source correctly.
>
> On these arches, even -O already sets -fomit-frame-pointer.
>
> So, for all arches, if DEBUG is enabled, we could just use -O (as
> default only, if the user wants to override this for whatever reason, it
> should be honoured).
>
>
> >just like
> >-fno-strict-aliasing?
>
> That should only be needed in combination with -O2, if that is the
> default optimization (e.g. if DEBUG is not enabled). IMHO this option
> should not be forced, if users specify their own CFLAGS/COPTFLAGS.
>
> Summarizing, I would suggest:
>
> - If DEBUG is enabled, use plain -O by default, on all arches
> - If DEBUG is disabled, use -O2 -fno-strict-aliasing by default, on all
> arches.
thanks for your suggestions. i've incorporated them into the patch.
one thing i'm unsure is: what should be done when the user *doesn't* define
DEBUG, but has DDB, KDTRACE_FRAME or HWPMC in his kernel config?
the current behavior is to set -fno-omit-frame-pointer on amd64 and powerpc.
i think this behavior shouldn't be change. even though the user didn't specify
DEBUG, the fact that he has those kernel options indicates that he wants to do
some kind of debugging imho.
cheers.
alex
ps: sorry for the extra whitespace changes!
--
a13x
diff --git a/sys/conf/kern.pre.mk b/sys/conf/kern.pre.mk
index e9aa6e2..e6beda8 100644
--- a/sys/conf/kern.pre.mk
+++ b/sys/conf/kern.pre.mk
@@ -24,18 +24,12 @@ OBJCOPY?= objcopy
SIZE?= size
.if defined(DEBUG)
-_MINUS_O= -O
+COPTFLAGS?=-O -pipe
CTFFLAGS+= -g
+.elif ${MACHINE_CPUARCH} == "amd64" && ${CC:T:Mclang} != "clang"
+COPTFLAGS?=-O2 -fno-strict-aliasing -frename-registers -pipe
.else
-_MINUS_O= -O2
-.endif
-.if ${MACHINE_CPUARCH} == "amd64"
-COPTFLAGS?=-O2 -frename-registers -pipe
-.else
-COPTFLAGS?=${_MINUS_O} -pipe
-.endif
-.if !empty(COPTFLAGS:M-O[23s]) && empty(COPTFLAGS:M-fno-strict-aliasing)
-COPTFLAGS+= -fno-strict-aliasing
+COPTFLAGS?=-O2 -fno-strict-aliasing -pipe
.endif
.if !defined(NO_CPU_COPTFLAGS)
COPTFLAGS+= ${_CPUCFLAGS}
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [rfc] a few kern.mk and bsd.sys.mk related changes
On Tue May 31 11, Alexander Best wrote:
> On Tue May 31 11, Garrett Cooper wrote:
> > On May 31, 2011, at 3:46 AM, Alexander Best wrote:
> >
> > > On Tue May 31 11, Dimitry Andric wrote:
> > >> On 2011-05-31 11:57, Alexander Best wrote:
> > >> ...
> > >>>>> however i've often read messages - mostly by bruce evans - claiming
> > >>>>> that
> > >>>>> anything greater than -O will in fact decrease a kernel's ability to
> > >>>>> be
> > >>>>> debugged just as well as a kernel with -O.
> > >>>> The critical option when -O2 is used is -fno-omit-frame-pointers,
> > >>>> since
> > >>>> removing
> > >>>> frame pointers makes debugging impossible (on i386). With -O2 code is
> > >>>> moved around and
> > >>>> removed, so debugging is more difficult, but can still provide useful
> > >>>> information.
> > >>> any reason we cannot use -O2 -fno-omit-frame-pointers
> > >>> -fno-strict-aliasing
> > >>> as
> > >>> standard COPTFLAGS with debugging enabled for *all* archs?
> > >>
> > >> Most likely, the performance gain from -O2 is rather small, except for
> > >> special cases, but the pain during debugging is increased a great deal.
> > >>
> > >> Even if you add frame pointers, with -O2 large pieces of code can be
> > >> transformed, variables or even entire functions can be completely
> > >> eliminated, and so on, making debugging much more difficult.
> > >
> > > *lol* we're moving in circles. so back to the beginning: why not use -O
> > > for all archs, if debugging was enabled? for amd64 -O2 is always set, no
> > > matter, if debugging is enabled or disabled.
> >
> > I don't know, but I've run into cases where gcc has inlined or shuffled
> > around code on amd64 with -O2 -fno-strict-aliasing, so I changed my
> > make.conf to use -O0 when DEBUG_FLAGS was defined.
>
> ...which leads me to the conclusion that -O should be set when DEBUG was
> defined: an all ARCHS.
>
> right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the
> kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior?
> shouldn't
> -fno-omit-frame-pointer be set uncondtitionally on all archs? just like
> -fno-strict-aliasing?
so how about the following patch?
cheers.
alex
>
> cheers.
> alex
>
> > Thanks,
> > -Garrett
> --
> a13x
--
a13x
diff --git a/sys/conf/Makefile.amd64 b/sys/conf/Makefile.amd64
index 5096829..f70f3de 100644
--- a/sys/conf/Makefile.amd64
+++ b/sys/conf/Makefile.amd64
@@ -31,13 +31,6 @@ S= ../../..
.endif
.include "$S/conf/kern.pre.mk"
-DDB_ENABLED!= grep DDB opt_ddb.h || true
-DTR_ENABLED!= grep KDTRACE_FRAME opt_kdtrace.h || true
-HWPMC_ENABLED!=grep HWPMC opt_hwpmc_hooks.h || true
-.if !empty(DDB_ENABLED) || !empty(DTR_ENABLED) || !empty(HWPMC_ENABLED)
-CFLAGS+= -fno-omit-frame-pointer
-.endif
-
MKMODULESENV+= MACHINE=amd64
.if ${CC:T:Mclang} == "clang"
diff --git a/sys/conf/Makefile.powerpc b/sys/conf/Makefile.powerpc
index e4cd85f..04bc66b 100644
--- a/sys/conf/Makefile.powerpc
+++ b/sys/conf/Makefile.powerpc
@@ -37,11 +37,6 @@ INCLUDES+= -I$S/contrib/libfdt
CFLAGS+= -msoft-float
-DDB_ENABLED!= grep DDB opt_ddb.h || true
-.if !empty(DDB_ENABLED)
-CFLAGS+= -fno-omit-frame-pointer
-.endif
-
%BEFORE_DEPEND
%OBJS
diff --git a/sys/conf/kern.pre.mk b/sys/conf/kern.pre.mk
index e9aa6e2..0314ada 100644
--- a/sys/conf/kern.pre.mk
+++ b/sys/conf/kern.pre.mk
@@ -24,26 +24,28 @@ OBJCOPY?= objcopy
SIZE?= size
.if defined(DEBUG)
-_MINUS_O= -O
+COPTFLAGS?=-O -pipe
CTFFLAGS+= -g
+.elif ${MACHINE_CPUARCH} == "amd64" && ${CC:T:Mclang} != "clang"
+COPTFLAGS?=-O2 -frename-registers -pipe
.else
-_MINUS_O= -O2
+COPTFLAGS?=-O2 -pipe
.endif
-.if ${MACHINE_CPUARCH} == "amd64"
-COPTFLAGS?=-O2 -frename-registers -pipe
-.else
-COPTFLAGS?=${_MINUS_O} -pipe
+
+.if !empty(COPTFLAGS:M-O[234sz]) && empty(COPTFLAGS:M-fno-strict-aliasing)
+COPTFLAGS+=-fno-strict-aliasing
.endif
-.if !empty(COPTFLAGS:M-O[23s]) && empty(COPTFLAGS:M-fno-strict-aliasing)
-COPTFLAGS+= -fno-strict-aliasing
+
+.if empty(COPTFLAGS:M-O0) && empty(COPTFLAGS:M-fno-omit-frame-pointer)
+COPTFLAGS+=-fno-omit-frame-pointer
.endif
+
.if !defined(NO_CPU_COPTFLAGS)
-COPTFLAGS+= ${_CPUCFLAGS}
+COPTFLAGS+=${_CPUCFLAGS}
.endif
-C_DIALECT= -std=c99
-NOSTDINC= -nostdinc
-INCLUDES= ${NOST
Re: [rfc] a few kern.mk and bsd.sys.mk related changes
On Tue May 31 11, Garrett Cooper wrote: > On May 31, 2011, at 3:46 AM, Alexander Best wrote: > > > On Tue May 31 11, Dimitry Andric wrote: > >> On 2011-05-31 11:57, Alexander Best wrote: > >> ... > >>>>> however i've often read messages - mostly by bruce evans - claiming that > >>>>> anything greater than -O will in fact decrease a kernel's ability to be > >>>>> debugged just as well as a kernel with -O. > >>>> The critical option when -O2 is used is -fno-omit-frame-pointers, since > >>>> removing > >>>> frame pointers makes debugging impossible (on i386). With -O2 code is > >>>> moved around and > >>>> removed, so debugging is more difficult, but can still provide useful > >>>> information. > >>> any reason we cannot use -O2 -fno-omit-frame-pointers > >>> -fno-strict-aliasing > >>> as > >>> standard COPTFLAGS with debugging enabled for *all* archs? > >> > >> Most likely, the performance gain from -O2 is rather small, except for > >> special cases, but the pain during debugging is increased a great deal. > >> > >> Even if you add frame pointers, with -O2 large pieces of code can be > >> transformed, variables or even entire functions can be completely > >> eliminated, and so on, making debugging much more difficult. > > > > *lol* we're moving in circles. so back to the beginning: why not use -O > > for all archs, if debugging was enabled? for amd64 -O2 is always set, no > > matter, if debugging is enabled or disabled. > > I don't know, but I've run into cases where gcc has inlined or shuffled > around code on amd64 with -O2 -fno-strict-aliasing, so I changed my make.conf > to use -O0 when DEBUG_FLAGS was defined. ...which leads me to the conclusion that -O should be set when DEBUG was defined: an all ARCHS. right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior? shouldn't -fno-omit-frame-pointer be set uncondtitionally on all archs? just like -fno-strict-aliasing? cheers. alex > Thanks, > -Garrett -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes)
On Mon May 30 11, Dieter BSD wrote: > Chris writes: > >> Ports need attention. The warnings I get there are frightening. > > > > I find it comforting that they're just that: warnings. > > > > How do they frighten you? > > High quality code does not have any warnings. > > The most frightening thing is the attitute that "They're just warnings, > so I'll ignore them." Â Most compiler warnings should be fatal errors. > And a lot of the warnings that require a -Wwhatever should be on by > default. please keep in mind that -Wfoo does reflect the ideas of the GNU people regarding *proper* code. the warnings themselves are sometimes wrong, because they complain about perfectly correct code. so -Wfoo should not be considered a code verifier, but in fact what it is: a warning flag. sometimes it's correct and indeed reports wrong code, sometimes it is completely wrong. cheers. alex > > Code that doesn't compile cleanly often has other problems, like assuming > that all CPUs are ILP32 little endian, like not checking return codes, etc. > > But hey, the next time the weather service issues a tornado warning, > feel free to go outside and fly a kite. Â After all it's just a warning. > > a13x writes: > > -Wcoercion seems to have only been a SoC project in 2006 [1]. i checked gcc > > trunk and it's not in the gcc(1) manual. > > > > [1] http://gcc.gnu.org/wiki/Wcoercion > > And yet someone marked the bug fixed. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072 -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [rfc] a few kern.mk and bsd.sys.mk related changes
On Tue May 31 11, Dimitry Andric wrote: > On 2011-05-31 11:57, Alexander Best wrote: > ... > >>>however i've often read messages - mostly by bruce evans - claiming that > >>>anything greater than -O will in fact decrease a kernel's ability to be > >>>debugged just as well as a kernel with -O. > >>The critical option when -O2 is used is -fno-omit-frame-pointers, since > >>removing > >>frame pointers makes debugging impossible (on i386). With -O2 code is > >>moved around and > >>removed, so debugging is more difficult, but can still provide useful > >>information. > >any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing > >as > >standard COPTFLAGS with debugging enabled for *all* archs? > > Most likely, the performance gain from -O2 is rather small, except for > special cases, but the pain during debugging is increased a great deal. > > Even if you add frame pointers, with -O2 large pieces of code can be > transformed, variables or even entire functions can be completely > eliminated, and so on, making debugging much more difficult. *lol* we're moving in circles. so back to the beginning: why not use -O for all archs, if debugging was enabled? for amd64 -O2 is always set, no matter, if debugging is enabled or disabled. cheers. alex -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [rfc] a few kern.mk and bsd.sys.mk related changes
On Sat May 28 11, Bruce Cran wrote: > On Sat, May 28, 2011 at 06:23:26PM +0000, Alexander Best wrote: > > > > well i'm not an expert on this. but are we 100% sure that a kernel on amd64 > > compiled with -O2 frename-registers can be debugged the same way as one with > > -O? if that is the case: sure...-O2 is fine. ;) > > > > however i've often read messages - mostly by bruce evans - claiming that > > anything greater than -O will in fact decrease a kernel's ability to be > > debugged just as well as a kernel with -O. > > > > The critical option when -O2 is used is -fno-omit-frame-pointers, since > removing > frame pointers makes debugging impossible (on i386). With -O2 code is moved > around and > removed, so debugging is more difficult, but can still provide useful > information. any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing as standard COPTFLAGS with debugging enabled for *all* archs? > > -- > Bruce Cran -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes)
On Mon May 30 11, Dieter BSD wrote: > > maybe we find some nice -Wwarning options which are reasonable > > to have > > -Wmissing-declarations > -Wimplicit > > FreeBSD's gcc doesn't seem to have  -Wcoercion  ??? > Bugzilla indicates that it was added years ago (2006?). -Wcoercion seems to have only been a SoC project in 2006 [1]. i checked gcc trunk and it's not in the gcc(1) manual. [1] http://gcc.gnu.org/wiki/Wcoercion > > It would be really really nice if -static worked on (nearly) everything. > > > and - most importantly - don't break tinderbox > > That's a matter of fixing the bugs before adding the warning flags > to tinderbox. > > Ports need attention.  The warnings I get there are frightening. -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [rfc] a few kern.mk and bsd.sys.mk related changes
On Sat May 28 11, Alexander Best wrote: > On Sat May 28 11, Bruce Cran wrote: > > On Sat, May 28, 2011 at 06:23:26PM +, Alexander Best wrote: > > > > > > well i'm not an expert on this. but are we 100% sure that a kernel on > > > amd64 > > > compiled with -O2 frename-registers can be debugged the same way as one > > > with > > > -O? if that is the case: sure...-O2 is fine. ;) > > > > > > however i've often read messages - mostly by bruce evans - claiming that > > > anything greater than -O will in fact decrease a kernel's ability to be > > > debugged just as well as a kernel with -O. > > > > > > > The critical option when -O2 is used is -fno-omit-frame-pointers, since > > removing > > frame pointers makes debugging impossible (on i386). With -O2 code is moved > > around and > > removed, so debugging is more difficult, but can still provide useful > > information. > > how about making -fno-omit-frame-pointers mandatory for all builds with an > optimisation level higher than -O? man this is confusing. why must the freebsd make skeleton be so complicated. :( it seems -fno-omit-frame-pointers gets set in sys/conf/Makefile.amd64 and sys/conf/Makefile.powerpc already. also for modules in sys/conf/kmod.mk. i guess somebody with a better in deth knowledge should investigate this matter. this is a bit too complicated for me. cheers. alex > > something like > > .if !empty(COPTFLAGS:M-O[234sz]) && empty(COPTFLAGS:M-fno-omit-frame-pointers) > COPTFLAGS+= -fno-omit-frame-pointers > .endif > > (-O4 and -Oz are clang specific, but it won't hurt having them in there) > > cheers. > alex > > > > > -- > > Bruce Cran > > -- > a13x -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [rfc] a few kern.mk and bsd.sys.mk related changes
On Sat May 28 11, Bruce Cran wrote: > On Sat, May 28, 2011 at 06:23:26PM +0000, Alexander Best wrote: > > > > well i'm not an expert on this. but are we 100% sure that a kernel on amd64 > > compiled with -O2 frename-registers can be debugged the same way as one with > > -O? if that is the case: sure...-O2 is fine. ;) > > > > however i've often read messages - mostly by bruce evans - claiming that > > anything greater than -O will in fact decrease a kernel's ability to be > > debugged just as well as a kernel with -O. > > > > The critical option when -O2 is used is -fno-omit-frame-pointers, since > removing > frame pointers makes debugging impossible (on i386). With -O2 code is moved > around and > removed, so debugging is more difficult, but can still provide useful > information. how about making -fno-omit-frame-pointers mandatory for all builds with an optimisation level higher than -O? something like .if !empty(COPTFLAGS:M-O[234sz]) && empty(COPTFLAGS:M-fno-omit-frame-pointers) COPTFLAGS+= -fno-omit-frame-pointers .endif (-O4 and -Oz are clang specific, but it won't hurt having them in there) cheers. alex > > -- > Bruce Cran -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [rfc] a few kern.mk and bsd.sys.mk related changes
On Sat May 28 11, Alexander Best wrote: > On Sat May 28 11, Pan Tsu wrote: > > Alexander Best writes: > > > > > On Fri May 27 11, Alexander Best wrote: > > >> On Fri May 27 11, Warner Losh wrote: > > >> > These look generally good. Just one thing I had a question on: > > >> > > > >> > # > > >> > +# Enable FreeBSD kernel-specific printf format specifiers. Also > > >> > instruct gcc to > > >> > +# enable some diagnostics, which make it easier to pinpoint tinderbox > > >> > failures. > > >> > +CFLAGS+= -fformat-extensions -fdiagnostics-show-option > > >> > + > > >> > > > >> > Does this put sand in the gears of clang support? > > > > > > i've improved the above comment so as to note that clang won't be > > > affected by > > > -fdiagnostics-show-option. the new patch is available here: > > > > > > http://people.freebsd.org/~arundel/patches/kern.mk-bsy.sys.mk.patch > > > > > > another "issue" i've come across is the fact that on amd64, -O2 is always > > > being > > > set, no matter, if debugging is enabled or disabled. i think amd64 should > > > also > > > (just like all the other archs) be using -O, when debugging was enabled. > > > > Any reason a kernel with symbols (DEBUG) *must* be pessimized to -O1 level? > > Looking at r140606 it's not clear how symbols are related to a bump > > from -O1 to -O2 for non-amd64 archs. And -RELEASE kernels since at least > > 6.0R have `makeoptions DEBUG=-g' uncommented in GENERIC. > > well i'm not an expert on this. but are we 100% sure that a kernel on amd64 > compiled with -O2 frename-registers can be debugged the same way as one with > -O? if that is the case: sure...-O2 is fine. ;) > > however i've often read messages - mostly by bruce evans - claiming that > anything greater than -O will in fact decrease a kernel's ability to be > debugged just as well as a kernel with -O. ok. so here are two seperate patches: http://people.freebsd.org/~arundel/patches/kern.mk-bsd.sys.mk.patch ^^ this one will trigger -O on amd64, when debugging was enabled. http://people.freebsd.org/~arundel/patches/kern.mk-bsd.sys.mk-O2.patch ^^ this one will leave the semantics as they are, so even when debugging was enabled, -O2 gets set under amd64. cheers. alex > > cheers. > alex > > > > > > changing this is quite easy. so if people think this is something worth > > > changing i can integrate it into my existing patch. > > -- > a13x -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [rfc] a few kern.mk and bsd.sys.mk related changes
On Sat May 28 11, Pan Tsu wrote: > Alexander Best writes: > > > On Fri May 27 11, Alexander Best wrote: > >> On Fri May 27 11, Warner Losh wrote: > >> > These look generally good. Just one thing I had a question on: > >> > > >> > # > >> > +# Enable FreeBSD kernel-specific printf format specifiers. Also > >> > instruct gcc to > >> > +# enable some diagnostics, which make it easier to pinpoint tinderbox > >> > failures. > >> > +CFLAGS+=-fformat-extensions -fdiagnostics-show-option > >> > + > >> > > >> > Does this put sand in the gears of clang support? > > > > i've improved the above comment so as to note that clang won't be affected > > by > > -fdiagnostics-show-option. the new patch is available here: > > > > http://people.freebsd.org/~arundel/patches/kern.mk-bsy.sys.mk.patch > > > > another "issue" i've come across is the fact that on amd64, -O2 is always > > being > > set, no matter, if debugging is enabled or disabled. i think amd64 should > > also > > (just like all the other archs) be using -O, when debugging was enabled. > > Any reason a kernel with symbols (DEBUG) *must* be pessimized to -O1 level? > Looking at r140606 it's not clear how symbols are related to a bump > from -O1 to -O2 for non-amd64 archs. And -RELEASE kernels since at least > 6.0R have `makeoptions DEBUG=-g' uncommented in GENERIC. well i'm not an expert on this. but are we 100% sure that a kernel on amd64 compiled with -O2 frename-registers can be debugged the same way as one with -O? if that is the case: sure...-O2 is fine. ;) however i've often read messages - mostly by bruce evans - claiming that anything greater than -O will in fact decrease a kernel's ability to be debugged just as well as a kernel with -O. cheers. alex > > > changing this is quite easy. so if people think this is something worth > > changing i can integrate it into my existing patch. -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [rfc] a few kern.mk and bsd.sys.mk related changes
On Fri May 27 11, Warner Losh wrote: > > On May 27, 2011, at 12:14 PM, Alexander Best wrote: > > > On Fri May 27 11, Warner Losh wrote: > >> These look generally good. Just one thing I had a question on: > >> > >> # > >> +# Enable FreeBSD kernel-specific printf format specifiers. Also instruct > >> gcc to > >> +# enable some diagnostics, which make it easier to pinpoint tinderbox > >> failures. > >> +CFLAGS+= -fformat-extensions -fdiagnostics-show-option > >> + > >> > >> Does this put sand in the gears of clang support? > > > > i don't think so. the code that features -fformat-extensions support is > > freebsd > > specific and gets plugged into the vendor code during every new import. dim@ > > and rdivacky@ have been discussing the possibility of getting this committed > > upstream as something like -ffreebsd-extensions, but they haven't decided, > > yet. > > OK. I have a bunch of uncommitted changes to support external toolchains, > and this sort of thing might bite me when them... But I'll fight with that > when I get there. well the main problem imho is -fformat-extensions. the code that supports this flag has not been pushed upstream neither to clang, nor to gcc. so compiling the freebsd kernel with anything external, like clang tot or gcc 4.6 will fail to recognise the special printf formatting. personally i think getting this committed upsteam to clang as -ffreebsd-extensions would be a nice thing to have. however it's not my decision to make. ;) the -fdiagnostics-show-option flag is a standard clang and gcc flag and won't cause any problems. the only difference between gcc and clang is: gcc has it disabled by default; clang has it enabled by default. i've reworked my patch yet again. it now features these changes: 1) -W is now called -Wextra 2) move -fformat-extensions and -fdiagnostics-show-option out of CWARNFLAGS, since they aren't really warnings. this will now let anybody use custom CWARNFLAGS without having to remember to add -fformat-extensions in order not to break buildworld. 3) rearrange "\" characters, as to avoid double spaces 4) when building kernel modules, -fstack-protector was added to CFLAGS twice. this should now be solved. 5) only enable -frename-registers, when gcc is used, since clang doesn't understand this flag 6) when debugging is enabled, also use the -O flag for amd64 and not -O2. when people enable debugging they don't really want optimisations such as -O2 turned on. the patch is available here: http://people.freebsd.org/~arundel/patches/kern.mk-bsd.sys.mk.patch NB: regarding point 2), i'd like to encurrage people to play around with CWARNFLAGS a bit. maybe we find some nice -Wwarning options which are reasonable to have and - most importantly - don't break tinderbox. for far i've played around with the following flags and can verify that they break tinderbox: -Wshadow, -Wwrite-strings, -Wextra, -Wbad-function-cast and -Wmissing-declarations -Wmissing-declarations almost works, but there are ~ 20 undeclared functions in the dtrace code. if those could be fixed it would be possible to add that flag to CWARNFLAGS. cheers. alex > > > regarding -fdiagnostics-show-option: this is intended purely for gcc, since > > it > > is disabled per default. under clang the flag exists, too, but it is > > enabled by > > default. so specifying it under clang is pretty much a nop. > > Cool. This is less of a concern, since it will be present in most external > toolchains I care about. > > Warner > > > cheers. > > alex > > > >> > >> Warner > >> > >> > >> On May 27, 2011, at 5:51 AM, Alexander Best wrote: > >> > >>> hi there, > >>> > >>> i would like to hear people's opinion regarding the following patch. it > >>> features the following semantic changes: > >>> > >>> 1) -W is now called -Wextra > >>> 2) move -fformat-extensions and -fdiagnostics-show-option out of > >>> CWARNFLAGS, > >>> since they aren't really warnings. this will now let anybody use custom > >>> CWARNFLAGS without having to remember to add -fformat-extensions in order > >>> not to break buildworld. > >>> 3) rearrange "\" characters, as to avoid double spaces > >>> 4) when building kernel modules, -fstack-protector was added to CFLAGS > >>> twice. > >>> this should now be solved. > >>> > >>> cheers. > >>> alex > >>> > >>> -- > >>> a13x > >>> ___ > >>> freebsd-toolchain@freebsd.org mailing list > >>> http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > >>> To unsubscribe, send any mail to > >>> "freebsd-toolchain-unsubscr...@freebsd.org" > > > > -- > > a13x > > > > -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [rfc] a few kern.mk and bsd.sys.mk related changes
On Fri May 27 11, Alexander Best wrote: > On Fri May 27 11, Warner Losh wrote: > > These look generally good. Just one thing I had a question on: > > > > # > > +# Enable FreeBSD kernel-specific printf format specifiers. Also instruct > > gcc to > > +# enable some diagnostics, which make it easier to pinpoint tinderbox > > failures. > > +CFLAGS+= -fformat-extensions -fdiagnostics-show-option > > + > > > > Does this put sand in the gears of clang support? i've improved the above comment so as to note that clang won't be affected by -fdiagnostics-show-option. the new patch is available here: http://people.freebsd.org/~arundel/patches/kern.mk-bsy.sys.mk.patch another "issue" i've come across is the fact that on amd64, -O2 is always being set, no matter, if debugging is enabled or disabled. i think amd64 should also (just like all the other archs) be using -O, when debugging was enabled. changing this is quite easy. so if people think this is something worth changing i can integrate it into my existing patch. cheers. alex > > i don't think so. the code that features -fformat-extensions support is > freebsd > specific and gets plugged into the vendor code during every new import. dim@ > and rdivacky@ have been discussing the possibility of getting this committed > upstream as something like -ffreebsd-extensions, but they haven't decided, > yet. > > regarding -fdiagnostics-show-option: this is intended purely for gcc, since it > is disabled per default. under clang the flag exists, too, but it is enabled > by > default. so specifying it under clang is pretty much a nop. > > cheers. > alex > > > > > Warner > > > > > > On May 27, 2011, at 5:51 AM, Alexander Best wrote: > > > > > hi there, > > > > > > i would like to hear people's opinion regarding the following patch. it > > > features the following semantic changes: > > > > > > 1) -W is now called -Wextra > > > 2) move -fformat-extensions and -fdiagnostics-show-option out of > > > CWARNFLAGS, > > > since they aren't really warnings. this will now let anybody use custom > > > CWARNFLAGS without having to remember to add -fformat-extensions in > > > order > > > not to break buildworld. > > > 3) rearrange "\" characters, as to avoid double spaces > > > 4) when building kernel modules, -fstack-protector was added to CFLAGS > > > twice. > > > this should now be solved. > > > > > > cheers. > > > alex > > > > > > -- > > > a13x > > > ___ > > > freebsd-toolchain@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > > > To unsubscribe, send any mail to > > > "freebsd-toolchain-unsubscr...@freebsd.org" > > -- > a13x -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [rfc] a few kern.mk and bsd.sys.mk related changes
On Fri May 27 11, Warner Losh wrote: > These look generally good. Just one thing I had a question on: > > # > +# Enable FreeBSD kernel-specific printf format specifiers. Also instruct gcc > to > +# enable some diagnostics, which make it easier to pinpoint tinderbox > failures. > +CFLAGS+= -fformat-extensions -fdiagnostics-show-option > + > > Does this put sand in the gears of clang support? i don't think so. the code that features -fformat-extensions support is freebsd specific and gets plugged into the vendor code during every new import. dim@ and rdivacky@ have been discussing the possibility of getting this committed upstream as something like -ffreebsd-extensions, but they haven't decided, yet. regarding -fdiagnostics-show-option: this is intended purely for gcc, since it is disabled per default. under clang the flag exists, too, but it is enabled by default. so specifying it under clang is pretty much a nop. cheers. alex > > Warner > > > On May 27, 2011, at 5:51 AM, Alexander Best wrote: > > > hi there, > > > > i would like to hear people's opinion regarding the following patch. it > > features the following semantic changes: > > > > 1) -W is now called -Wextra > > 2) move -fformat-extensions and -fdiagnostics-show-option out of CWARNFLAGS, > > since they aren't really warnings. this will now let anybody use custom > > CWARNFLAGS without having to remember to add -fformat-extensions in order > > not to break buildworld. > > 3) rearrange "\" characters, as to avoid double spaces > > 4) when building kernel modules, -fstack-protector was added to CFLAGS > > twice. > > this should now be solved. > > > > cheers. > > alex > > > > -- > > a13x > > ___ > > freebsd-toolchain@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org" -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[rfc] a few kern.mk and bsd.sys.mk related changes
hi there,
i would like to hear people's opinion regarding the following patch. it
features the following semantic changes:
1) -W is now called -Wextra
2) move -fformat-extensions and -fdiagnostics-show-option out of CWARNFLAGS,
since they aren't really warnings. this will now let anybody use custom
CWARNFLAGS without having to remember to add -fformat-extensions in order
not to break buildworld.
3) rearrange "\" characters, as to avoid double spaces
4) when building kernel modules, -fstack-protector was added to CFLAGS twice.
this should now be solved.
cheers.
alex
--
a13x
diff --git a/share/mk/bsd.sys.mk b/share/mk/bsd.sys.mk
index 796d169..eec7408 100644
--- a/share/mk/bsd.sys.mk
+++ b/share/mk/bsd.sys.mk
@@ -36,7 +36,7 @@ CWARNFLAGS+= -Werror
CWARNFLAGS += -Wall -Wno-format-y2k
. endif
. if ${WARNS} >= 3
-CWARNFLAGS += -W -Wno-unused-parameter -Wstrict-prototypes\
+CWARNFLAGS += -Wextra -Wno-unused-parameter -Wstrict-prototypes\
-Wmissing-prototypes -Wpointer-arith
. endif
. if ${WARNS} >= 4
diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk
index a0a595f..0806b0b 100644
--- a/sys/conf/kern.mk
+++ b/sys/conf/kern.mk
@@ -3,10 +3,9 @@
#
# Warning flags for compiling the kernel and components of the kernel:
#
-CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes \
- -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual \
- -Wundef -Wno-pointer-sign -fformat-extensions \
- -Wmissing-include-dirs -fdiagnostics-show-option
+CWARNFLAGS?= -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes\
+ -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual\
+ -Wundef -Wno-pointer-sign -Wmissing-include-dirs
#
# The following flags are next up for working on:
# -Wextra
@@ -83,7 +82,7 @@ CFLAGS+= -mno-sse
.else
CFLAGS+= -mno-aes -mno-avx
.endif
-CFLAGS+= -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float \
+CFLAGS+= -mcmodel=kernel -mno-red-zone -mno-mmx -msoft-float\
-fno-asynchronous-unwind-tables
INLINE_LIMIT?= 8000
.endif
@@ -120,11 +119,17 @@ INLINE_LIMIT?=8000
CFLAGS+= -ffreestanding
#
+# Enable FreeBSD kernel-specific printf format specifiers. Also instruct gcc to
+# enable some diagnostics, which make it easier to pinpoint tinderbox failures.
+CFLAGS+= -fformat-extensions -fdiagnostics-show-option
+
+#
# GCC SSP support
#
.if ${MK_SSP} != "no" && ${MACHINE_CPUARCH} != "ia64" && \
${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips"
-CFLAGS+= -fstack-protector
+SSP_CFLAGS?= -fstack-protector
+CFLAGS+= ${SSP_CFLAGS}
.endif
#
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang and 3dnow(a)
On Fri Apr 15 11, Dimitry Andric wrote:
> On 2011-04-15 01:41, Alexander Best wrote:
> >per coincidence i discovered the following contrary behavior between gcc
> >and
> >clang:
> >
> >-mno-mmx implies -mno-3dnow under gcc. under clang -mno-mmx will *not*
> >imply
> >-mno-3dnow!
> >
> >is this a clang design feature or a bug? fixing it would be trivial (see
> >attached patch).
>
> I don't think it was intentionally designed, nor that it is a bug. It
> it just arbitrary what you disable when you specify '-mno-mmx'.
>
> However, it would probably be nice if clang emulated gcc's behaviour
> here.
here's an updated patch against clang tot.
>
> Adding cfe-commits@ in the loop, to see if the clang guys think this is
> desirable.
>
>
> diff --git a/contrib/llvm/tools/clang/lib/Basic/Targets.cpp
> b/contrib/llvm/tools/clang/lib/Basic/Targets.cpp
> index 55321f2..1af7c52 100644
> --- a/contrib/llvm/tools/clang/lib/Basic/Targets.cpp
> +++ b/contrib/llvm/tools/clang/lib/Basic/Targets.cpp
> @@ -1133,8 +1133,9 @@ bool
> X86TargetInfo::setFeatureEnabled(llvm::StringMap &Features,
>Features["avx"] = true;
>} else {
> if (Name == "mmx")
> - Features["mmx"] = Features["sse"] = Features["sse2"] =
> Features["sse3"] =
> -Features["ssse3"] = Features["sse41"] = Features["sse42"] = false;
> + Features["mmx"] = Features["3dnow"] = Features["3dnowa"] =
> + Features["sse"] = Features["sse2"] = Features["sse3"] =
> + Features["ssse3"] = Features["sse41"] = Features["sse42"] = false;
> else if (Name == "sse")
>Features["sse"] = Features["sse2"] = Features["sse3"] =
> Features["ssse3"] = Features["sse41"] = Features["sse42"] = false;
--
a13x
Index: tools/clang/lib/Basic/Targets.cpp
===
--- tools/clang/lib/Basic/Targets.cpp (revision 129652)
+++ tools/clang/lib/Basic/Targets.cpp (working copy)
@@ -1146,7 +1146,8 @@
Features["avx"] = true;
} else {
if (Name == "mmx")
- Features["mmx"] = Features["sse"] = Features["sse2"] = Features["sse3"] =
+ Features["mmx"] = Features["3dnow"] = Features["3dnowa"] =
+Features["sse"] = Features["sse2"] = Features["sse3"] =
Features["ssse3"] = Features["sse41"] = Features["sse42"] = false;
else if (Name == "sse")
Features["sse"] = Features["sse2"] = Features["sse3"] =
@@ -1159,12 +1160,10 @@
Features["sse42"] = false;
else if (Name == "ssse3")
Features["ssse3"] = Features["sse41"] = Features["sse42"] = false;
-else if (Name == "sse4")
+else if (Name == "sse4" || Name == "sse4.1")
Features["sse41"] = Features["sse42"] = false;
else if (Name == "sse4.2")
Features["sse42"] = false;
-else if (Name == "sse4.1")
- Features["sse41"] = Features["sse42"] = false;
else if (Name == "3dnow")
Features["3dnow"] = Features["3dnowa"] = false;
else if (Name == "3dnowa")
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
clang and 3dnow(a)
hi there,
per coincidence i discovered the following contrary behavior between gcc and
clang:
-mno-mmx implies -mno-3dnow under gcc. under clang -mno-mmx will *not* imply
-mno-3dnow!
is this a clang design feature or a bug? fixing it would be trivial (see
attached patch).
cheers.
alex
diff --git a/contrib/llvm/tools/clang/lib/Basic/Targets.cpp
b/contrib/llvm/tools/clang/lib/Basic/Targets.cpp
index 55321f2..1af7c52 100644
--- a/contrib/llvm/tools/clang/lib/Basic/Targets.cpp
+++ b/contrib/llvm/tools/clang/lib/Basic/Targets.cpp
@@ -1133,8 +1133,9 @@ bool
X86TargetInfo::setFeatureEnabled(llvm::StringMap &Features,
Features["avx"] = true;
} else {
if (Name == "mmx")
- Features["mmx"] = Features["sse"] = Features["sse2"] = Features["sse3"] =
-Features["ssse3"] = Features["sse41"] = Features["sse42"] = false;
+ Features["mmx"] = Features["3dnow"] = Features["3dnowa"] =
+ Features["sse"] = Features["sse2"] = Features["sse3"] =
+ Features["ssse3"] = Features["sse41"] = Features["sse42"] = false;
else if (Name == "sse")
Features["sse"] = Features["sse2"] = Features["sse3"] =
Features["ssse3"] = Features["sse41"] = Features["sse42"] = false;
--
a13x
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [RFC] adding -Wmissing-include-dirs to CWARNFLAGS
On Thu Apr 7 11, Garrett Cooper wrote: > On Thu, Apr 7, 2011 at 2:22 PM, Alexander Best wrote: > > On Thu Apr  7 11, Garrett Cooper wrote: > >> On Thu, Apr 7, 2011 at 1:53 PM, Garrett Cooper wrote: > >> > On Thu, Apr 7, 2011 at 11:55 AM, Alexander Best > >> > wrote: > >> >> hi there, > >> >> > >> >> i'd like to propose adding -Wmissing-include-dirs to CWARNFLAGS. this > >> >> will let > >> >> tinderbox fail, if any new kernel code was committed with (a) broken > >> >> include > >> >> dir(s). > >> >> > >> >> i ran a test via > >> >> > >> >> make toolchains > >> >> make MAKE_JUST_KERNELS=yes tinderbox > >> >> > >> >> and nothing seemed to go wrong with the extra warning enabled. i even > >> >> found a > >> >> missing include dir, which should be fixed by the attached patch. > >> >> > >> >> opinions? > >> >> > >> >> so far i've only tested this with gcc. i think someone on > >> >> #freebsd-clang told > >> >> me that -Wmissing-include-dirs is a noop for clang (for whatever > >> >> reasons). > >> > > >> >   make -f /etc/src.conf -VMODULES_OVERRIDE and make -f /etc/src.conf > >> > -VMODULES_OVERRIDE say... (tinderbox should also really ignore these > >> > files, but it doesn't currently)? > > > > otaku% make -f /etc/src.conf -VMODULES_OVERRIDE > > netgraph/netgraph netgraph/socket netgraph/bluetooth/bluetooth  > > netgraph/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket  > > netgraph/bluetooth/ubt tmpfs sound/sound sound/driver/hda usb/uhid  procfs > > pseudofs linux linprocfs linsysfs lindev usb/quirk geom  opensolaris dtrace > > cyclic nfsclient krpc nfs_common nfslock > > otaku% make -f /etc/make.conf -VMODULES_OVERRIDE > > netgraph/netgraph netgraph/socket netgraph/bluetooth/bluetooth  > > netgraph/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket  > > netgraph/bluetooth/ubt tmpfs sound/sound sound/driver/hda usb/uhid  procfs > > pseudofs linux linprocfs linsysfs lindev usb/quirk geom  opensolaris dtrace > > cyclic nfsclient krpc nfs_common nfslock > > > > ...however i checked and tinderbox *does* ignore src.conf and make.conf. the > > _.* log files show that modules were being build which are not returned by > > the commands above. > > > > i think having this flag would be very useful, because it would force > > people to > > make sure their include dirs are correct. > > > >> > >> Sorry. Second invocation should have been make.conf, not src.conf. > > Ok then. I stand corrected for not having tested out my claim beforehand. > > Yes, I agree that adding this flag in the default set is a good idea. cool. so now we need somebody to make the commit. ;) > > Thanks, > -Garrett -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [RFC] adding -Wmissing-include-dirs to CWARNFLAGS
On Thu Apr 7 11, Garrett Cooper wrote: > On Thu, Apr 7, 2011 at 1:53 PM, Garrett Cooper wrote: > > On Thu, Apr 7, 2011 at 11:55 AM, Alexander Best wrote: > >> hi there, > >> > >> i'd like to propose adding -Wmissing-include-dirs to CWARNFLAGS. this will > >> let > >> tinderbox fail, if any new kernel code was committed with (a) broken > >> include > >> dir(s). > >> > >> i ran a test via > >> > >> make toolchains > >> make MAKE_JUST_KERNELS=yes tinderbox > >> > >> and nothing seemed to go wrong with the extra warning enabled. i even > >> found a > >> missing include dir, which should be fixed by the attached patch. > >> > >> opinions? > >> > >> so far i've only tested this with gcc. i think someone on #freebsd-clang > >> told > >> me that -Wmissing-include-dirs is a noop for clang (for whatever reasons). > > > > Â Â make -f /etc/src.conf -VMODULES_OVERRIDE and make -f /etc/src.conf > > -VMODULES_OVERRIDE say... (tinderbox should also really ignore these > > files, but it doesn't currently)? otaku% make -f /etc/src.conf -VMODULES_OVERRIDE netgraph/netgraph netgraph/socket netgraph/bluetooth/bluetooth netgraph/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket netgraph/bluetooth/ubt tmpfs sound/sound sound/driver/hda usb/uhid procfs pseudofs linux linprocfs linsysfs lindev usb/quirk geom opensolaris dtrace cyclic nfsclient krpc nfs_common nfslock otaku% make -f /etc/make.conf -VMODULES_OVERRIDE netgraph/netgraph netgraph/socket netgraph/bluetooth/bluetooth netgraph/bluetooth/hci netgraph/bluetooth/l2cap netgraph/bluetooth/socket netgraph/bluetooth/ubt tmpfs sound/sound sound/driver/hda usb/uhid procfs pseudofs linux linprocfs linsysfs lindev usb/quirk geom opensolaris dtrace cyclic nfsclient krpc nfs_common nfslock ...however i checked and tinderbox *does* ignore src.conf and make.conf. the _.* log files show that modules were being build which are not returned by the commands above. i think having this flag would be very useful, because it would force people to make sure their include dirs are correct. > > Sorry. Second invocation should have been make.conf, not src.conf. -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[RFC] adding -Wmissing-include-dirs to CWARNFLAGS
hi there,
i'd like to propose adding -Wmissing-include-dirs to CWARNFLAGS. this will let
tinderbox fail, if any new kernel code was committed with (a) broken include
dir(s).
i ran a test via
make toolchains
make MAKE_JUST_KERNELS=yes tinderbox
and nothing seemed to go wrong with the extra warning enabled. i even found a
missing include dir, which should be fixed by the attached patch.
opinions?
so far i've only tested this with gcc. i think someone on #freebsd-clang told
me that -Wmissing-include-dirs is a noop for clang (for whatever reasons).
cheers.
alex
--
a13x
diff --git a/sys/modules/netgraph/atm/ccatm/Makefile
b/sys/modules/netgraph/atm/ccatm/Makefile
index 5626536..8bf741d 100644
--- a/sys/modules/netgraph/atm/ccatm/Makefile
+++ b/sys/modules/netgraph/atm/ccatm/Makefile
@@ -12,6 +12,6 @@ KMOD= ng_ccatm
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
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [RFC] code changes/removal in boot2.c and ufsread.c so clang can compile boot2
On Tue Feb 22 11, Roman Divacky wrote:
> fwiw, this is what I have:
>
> http://lev.vlakno.cz/~rdivacky/boot2-diet.patch
>
> with some llvm changed (-mrtd implementation + earlycse at the
> end of -O2) I am still at -113 bytes short on UFS1+UFS2 boot2
i was wondering...could we get rid of all the PATH_CONFIG and PATH_KERNEL
stuff? i tried this the other day with gptboot (which is pretty much
identical to boot2) and it seems booting a kernel directly got broken a long
time ago. so since invoking the loader is mandatory we could dump the kernel
loading code and the code that looks for entries in /boot.config completely.
you should be able to verify this by hitting a key before boot2 comes up and
enter the path to your kernel directly. for me it failed loading the kernel
(that's on amd64) with some btx error.
cheers.
alex
>
> this is with latest llvm, with the one in fbsd it was at roughly -80
> (stack alignment changes)
>
> On Tue, Feb 22, 2011 at 06:30:16PM +, Alexander Best wrote:
> > On Tue Feb 22 11, Warner Losh wrote:
> > > On 02/18/2011 18:01, Alexander Best wrote:
> > > >hi everybody,
> > > >
> > > >r218745 triggered quite a discussion about dead code in boot2.c. i
> > > >talked
> > > >to
> > > >roman (rdivacky@) and we were trying to improve the situation so that
> > > >boot2
> > > >would build with clang 2.8 (base) and the latest development version of
> > > >clang (trunk). a lot of the ideas came from Bruce (bde@).
> > > >
> > > >i'd really appreciate, if somebody could have a look at this patchset.
> > > >for
> > > >me
> > > >it strips down the boot2 code so clang is able to compile it just fine.
> > > >please
> > > >bear in mind that this has to work with boot2 supporting UFS1 *and*
> > > >UFS2.
> > > >so
> > > >please be sure not to override BOOT2_UFS in your src.conf or some place
> > > >else.
> > > >
> > > >you should be able to test the (hopefully sucessfully) compiled boot2
> > > >binary
> > > >by copying it to /boot. please be sure to keep a backup of your existing
> > > >boot2
> > > >file in case something breaks.
> > > >
> > > >the patchset (against a recent HEAD) can be found here:
> > > >http://people.freebsd.org/~arundel/patches/boot2.c.diff2
> > > >
> > > >cheers.
> > > >alex
> > > >
> > >
> > > Here's some comments:
> > >
> > > @@ -88,7 +97,7 @@ static ino_t lookup(const char *);
> > > static ssize_t fsread(ino_t, void *, size_t);
> > >
> > > static int ls, dsk_meta;
> > > -static uint32_t fs_off;
> > > +static uint32_t fs_off = 0;
> > >
> > > static __inline int
> > > fsfind(const char *name, ino_t * ino)
> > > @@ -98,7 +107,6 @@ fsfind(const char *name, ino_t * ino)
> > > char *s;
> > > ssize_t n;
> > >
> > > - fs_off = 0;
> > > while ((n = fsread(*ino, buf, DEV_BSIZE))> 0)
> > > for (s = buf; s< buf + DEV_BSIZE;) {
> > > d = (void *)s;
> > >
> > > How does the first part of this diff change things? bss gets the
> > > uninitialized and the data initialized to 0.
> > >
> > > but we also have this later:
> > >
> > > @@ -238,7 +245,6 @@ fsread(ino_t inode, void *buf, size_t nbyte)
> > >
> > > #endif
> > > inomap = inode;
> > > - fs_off = 0;
> > > blkmap = indmap = 0;
> > > }
> > > s = buf;
> > >
> > >
> > > -if (N_GETMAGIC(hdr.ex) == ZMAGIC)
> > > - fmt = 0;
> > > -else if (IS_ELF(hdr.eh))
> > > +if (IS_ELF(eh))
> > > fmt = 1;
> > >
> > >
> > > Doesn't this remove a.out support?
> >
> > indeed i removed that part from the newest patch:
> >
> > http://people.freebsd.org/~arundel/patches/boot2.c.diff3
> >
> > >
> > > Warner
> >
> > --
> > a13x
> > ___
> > freebsd-toolchain@freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
> > To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
--
a13x
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [RFC] code changes/removal in boot2.c and ufsread.c so clang can compile boot2
On Tue Feb 22 11, Warner Losh wrote:
> On 02/18/2011 18:01, Alexander Best wrote:
> >hi everybody,
> >
> >r218745 triggered quite a discussion about dead code in boot2.c. i talked
> >to
> >roman (rdivacky@) and we were trying to improve the situation so that boot2
> >would build with clang 2.8 (base) and the latest development version of
> >clang (trunk). a lot of the ideas came from Bruce (bde@).
> >
> >i'd really appreciate, if somebody could have a look at this patchset. for
> >me
> >it strips down the boot2 code so clang is able to compile it just fine.
> >please
> >bear in mind that this has to work with boot2 supporting UFS1 *and* UFS2.
> >so
> >please be sure not to override BOOT2_UFS in your src.conf or some place
> >else.
> >
> >you should be able to test the (hopefully sucessfully) compiled boot2
> >binary
> >by copying it to /boot. please be sure to keep a backup of your existing
> >boot2
> >file in case something breaks.
> >
> >the patchset (against a recent HEAD) can be found here:
> >http://people.freebsd.org/~arundel/patches/boot2.c.diff2
> >
> >cheers.
> >alex
> >
>
> Here's some comments:
>
> @@ -88,7 +97,7 @@ static ino_t lookup(const char *);
> static ssize_t fsread(ino_t, void *, size_t);
>
> static int ls, dsk_meta;
> -static uint32_t fs_off;
> +static uint32_t fs_off = 0;
>
> static __inline int
> fsfind(const char *name, ino_t * ino)
> @@ -98,7 +107,6 @@ fsfind(const char *name, ino_t * ino)
> char *s;
> ssize_t n;
>
> - fs_off = 0;
> while ((n = fsread(*ino, buf, DEV_BSIZE))> 0)
> for (s = buf; s< buf + DEV_BSIZE;) {
> d = (void *)s;
>
> How does the first part of this diff change things? bss gets the
> uninitialized and the data initialized to 0.
>
> but we also have this later:
>
> @@ -238,7 +245,6 @@ fsread(ino_t inode, void *buf, size_t nbyte)
>
> #endif
> inomap = inode;
> - fs_off = 0;
> blkmap = indmap = 0;
> }
> s = buf;
>
>
> -if (N_GETMAGIC(hdr.ex) == ZMAGIC)
> - fmt = 0;
> -else if (IS_ELF(hdr.eh))
> +if (IS_ELF(eh))
> fmt = 1;
>
>
> Doesn't this remove a.out support?
indeed i removed that part from the newest patch:
http://people.freebsd.org/~arundel/patches/boot2.c.diff3
>
> Warner
--
a13x
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [RFC] code changes/removal in boot2.c and ufsread.c so clang can compile boot2
On Sat Feb 19 11, Roman Divacky wrote:
> On Sat, Feb 19, 2011 at 01:01:36AM +0000, Alexander Best wrote:
> > hi everybody,
> >
> > r218745 triggered quite a discussion about dead code in boot2.c. i talked to
> > roman (rdivacky@) and we were trying to improve the situation so that boot2
> > would build with clang 2.8 (base) and the latest development version of
> > clang (trunk). a lot of the ideas came from Bruce (bde@).
> >
> > i'd really appreciate, if somebody could have a look at this patchset. for
> > me
> > it strips down the boot2 code so clang is able to compile it just fine.
> > please
> > bear in mind that this has to work with boot2 supporting UFS1 *and* UFS2. so
> > please be sure not to override BOOT2_UFS in your src.conf or some place
> > else.
> >
> > you should be able to test the (hopefully sucessfully) compiled boot2 binary
> > by copying it to /boot. please be sure to keep a backup of your existing
> > boot2
> > file in case something breaks.
>
> no, just copying it to /boot is not enough. you have to run bsdlabel -B to
> actually install it
>
> > the patchset (against a recent HEAD) can be found here:
> > http://people.freebsd.org/~arundel/patches/boot2.c.diff2
>
> the patch is wrong - you cant remove a.out support as "loader" still uses that
>
> I like the int -> unsigned parts of the patch and also the memsize() removal
> may be interesting.
here's an updated patchset:
http://people.freebsd.org/~arundel/patches/boot2.c.diff3
maybe we could somehow get rid of the last printf() in ufsread.c:
while ((n = fsread(*ino, buf, DEV_BSIZE)) > 0)
for (s = buf; s < buf + DEV_BSIZE;) {
d = (void *)s;
if (ls)
printf("%s ", d->d_name);
else if (!strcmp(name, d->d_name)) {
*ino = d->d_ino;
return d->d_type;
}
s += d->d_reclen;
}
if (n != -1 && ls)
printf("\n");
return 0;
this would us gain another 26 bytes.
cheers.
alex
>
> roman
--
a13x
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: [RFC] code changes/removal in boot2.c and ufsread.c so clang can compile boot2
On Sat Feb 19 11, Roman Divacky wrote: > On Sat, Feb 19, 2011 at 01:01:36AM +0000, Alexander Best wrote: > > hi everybody, > > > > r218745 triggered quite a discussion about dead code in boot2.c. i talked to > > roman (rdivacky@) and we were trying to improve the situation so that boot2 > > would build with clang 2.8 (base) and the latest development version of > > clang (trunk). a lot of the ideas came from Bruce (bde@). > > > > i'd really appreciate, if somebody could have a look at this patchset. for > > me > > it strips down the boot2 code so clang is able to compile it just fine. > > please > > bear in mind that this has to work with boot2 supporting UFS1 *and* UFS2. so > > please be sure not to override BOOT2_UFS in your src.conf or some place > > else. > > > > you should be able to test the (hopefully sucessfully) compiled boot2 binary > > by copying it to /boot. please be sure to keep a backup of your existing > > boot2 > > file in case something breaks. > > no, just copying it to /boot is not enough. you have to run bsdlabel -B to > actually install it oops. didn't know that. > > > the patchset (against a recent HEAD) can be found here: > > http://people.freebsd.org/~arundel/patches/boot2.c.diff2 > > the patch is wrong - you cant remove a.out support as "loader" still uses that > > I like the int -> unsigned parts of the patch and also the memsize() removal > may be interesting. also some bootinfo.bi_* stuff can go. bde@ mentioned that all we actually need are: "Support for disk geometry fields in bootinfo was lost long ago. This leaves only the following bootinfo fields supported (by boot2) and used: bi_version, bi_size, bi_symtab, bi_esymtab, bi_kernelname." let me re-add the a.out code amd see how that works. cheers. alex > > roman -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[RFC] code changes/removal in boot2.c and ufsread.c so clang can compile boot2
hi everybody, r218745 triggered quite a discussion about dead code in boot2.c. i talked to roman (rdivacky@) and we were trying to improve the situation so that boot2 would build with clang 2.8 (base) and the latest development version of clang (trunk). a lot of the ideas came from Bruce (bde@). i'd really appreciate, if somebody could have a look at this patchset. for me it strips down the boot2 code so clang is able to compile it just fine. please bear in mind that this has to work with boot2 supporting UFS1 *and* UFS2. so please be sure not to override BOOT2_UFS in your src.conf or some place else. you should be able to test the (hopefully sucessfully) compiled boot2 binary by copying it to /boot. please be sure to keep a backup of your existing boot2 file in case something breaks. the patchset (against a recent HEAD) can be found here: http://people.freebsd.org/~arundel/patches/boot2.c.diff2 cheers. alex -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: issue with clang and CPUTYPE native
On Mon Jan 31 11, Roman Divacky wrote:
> On Mon, Jan 31, 2011 at 09:00:41PM +0000, Alexander Best wrote:
> > On Mon Jan 31 11, Roman Divacky wrote:
> > > On Mon, Jan 31, 2011 at 04:27:55PM +0000, Alexander Best wrote:
> > > > On Sat Jan 1 11, Alexander Best wrote:
> > > > > On Sat Jan 1 11, Roman Divacky wrote:
> > > > > > > > clang -O2 -pipe -march=native -fpic -fvisibility=hidden
> > > > > > > > -DVISIBILITY_HIDDEN -g -std=gnu99 -fstack-protector
> > > > > > > > -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized
> > > > > > > > -Wno-pointer-sign -c
> > > > > > > > /usr/subversion-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c
> > > > > > > > detected CPU = core2
> > > > > > > > Assertion failed: (getMinSignedBits() <= 64 && "Too many bits
> > > > > > > > for int64_t"), function getSExtValue, file
> > > > > > > > /usr/subversion-src/lib/clang/libclangcodegen/../../../contrib/llvm/include/llvm/ADT/APInt.h,
> > > > > > > > line 1149.
> > > > > > > > Stack dump:
> > > > > > > > 0. Program arguments:
> > > > > > > > /usr/obj/usr/subversion-src/tmp/usr/bin/clang -cc1 -triple
> > > > > > > > x86_64-undermydesk-freebsd9.0 -S -disable-free -main-file-name
> > > > > > > > mulvti3.c -pic-level 1 -mdisable-fp-elim -mconstructor-aliases
> > > > > > > > -munwind-tables -target-cpu core2 -g -resource-dir
> > > > > > > > /usr/obj/usr/subversion-src/tmp/usr/lib/clang/2.8 -D
> > > > > > > > VISIBILITY_HIDDEN -O2 -Wsystem-headers -Wall -Wno-format-y2k
> > > > > > > > -Wno-uninitialized -Wno-pointer-sign -std=gnu99 -ferror-limit
> > > > > > > > 19 -fmessage-length 275 -fvisibility hidden -stack-protector 1
> > > > > > > > -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o
> > > > > > > > /tmp/cc-G6mPQL.s -x c
> > > > > > > > /usr/subversion-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c
> > > > > > > >
> > > > > > > > 1. parser at end of file
> > > > > > > > 2. Code generation
> > > > > > > > clang: error: clang frontend command failed due to signal 6
> > > > > > > > (use -v to see invocation)
> > > > > > > > *** Error code 250
> > > > > >
> > > > > >
> > > > > > this is a genuine llvm bug it may have been (or may have been not)
> > > > > > fixed in recent llvm.
> > > > > >
> > > > > > if you feel like it - install llvm/clang from subversion and check
> > > > > > if it compiles this
> > > > > > ok. if it does not I think it's worth filing a bug in llvm
> > > > > > bugzilla..
> > > >
> > > > i just wanted to report that the latest clang version doesn't trigger
> > > > the
> > > > assert any longer:
> > > >
> > > > clang version 2.9 (trunk 124571)
> > > > Target: x86_64-unknown-freebsd9.0
> > > > Thread model: posix
> > > >
> > > > is there a way to have the local "-fformat-extensions" clang additions
> > > > pushed
> > > > upstream? maybe that mght be sufficient to compile the freebsd source
> > > > with
> > > > clang 2.9+.
> > >
> > > no, it makes no sense to push the printf patches upstream. it's freebsd
> > > kernel
> > > only.
> > >
> > > for compiling freebsd kernel you are supposed to use /usr/bin/clang (or
> > > just
> > > ignore the warnings from upstream clang)
> >
> > you should be able to reproduce the issue on arch=amd64 and the following in
> > /etc by doing 'make' in lib/libcompiler_rt:
> >
> > otaku% cat /etc/make.conf /etc/src.conf
> > cat: /etc/make.conf: No such file or directory
> > # CLANG options
> > .if !defined(CC) || ${CC} == "cc"
> > CC=clang
> > .endif
> > .if !defined(CXX) || ${CXX} == "c++"
> > CXX=clang++
> > .endif
> > # Don't die on warnings
> > #NO_WERROR=
> > #WERROR=
> >
> > # Enable debugging symbols for world
> > DEBUG_FLAGS = -g
> >
> > ... removing the "-g" switch from DEBUG_FLAGS solves the issue.
> >
> > using the 2.9-development branch, lib/libcompiler_rt compiles fine even with
> > the -g switch.
>
> new import of clang/llvm will happen really soon now, bringing quite a few
> improvements (mature integrated asm, some fbsd specific fixes etc.)
very nice. looking forward to it. any chance we can get "CPUTYPE = core2" being
propagated to clang, instead of reset to nocona in the near future?
cheers.
alex
>
> roman
--
a13x
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: issue with clang and CPUTYPE native
On Mon Jan 31 11, Roman Divacky wrote:
> On Mon, Jan 31, 2011 at 04:27:55PM +0000, Alexander Best wrote:
> > On Sat Jan 1 11, Alexander Best wrote:
> > > On Sat Jan 1 11, Roman Divacky wrote:
> > > > > > clang -O2 -pipe -march=native -fpic -fvisibility=hidden
> > > > > > -DVISIBILITY_HIDDEN -g -std=gnu99 -fstack-protector
> > > > > > -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized
> > > > > > -Wno-pointer-sign -c
> > > > > > /usr/subversion-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c
> > > > > > detected CPU = core2
> > > > > > Assertion failed: (getMinSignedBits() <= 64 && "Too many bits for
> > > > > > int64_t"), function getSExtValue, file
> > > > > > /usr/subversion-src/lib/clang/libclangcodegen/../../../contrib/llvm/include/llvm/ADT/APInt.h,
> > > > > > line 1149.
> > > > > > Stack dump:
> > > > > > 0. Program arguments:
> > > > > > /usr/obj/usr/subversion-src/tmp/usr/bin/clang -cc1 -triple
> > > > > > x86_64-undermydesk-freebsd9.0 -S -disable-free -main-file-name
> > > > > > mulvti3.c -pic-level 1 -mdisable-fp-elim -mconstructor-aliases
> > > > > > -munwind-tables -target-cpu core2 -g -resource-dir
> > > > > > /usr/obj/usr/subversion-src/tmp/usr/lib/clang/2.8 -D
> > > > > > VISIBILITY_HIDDEN -O2 -Wsystem-headers -Wall -Wno-format-y2k
> > > > > > -Wno-uninitialized -Wno-pointer-sign -std=gnu99 -ferror-limit 19
> > > > > > -fmessage-length 275 -fvisibility hidden -stack-protector 1
> > > > > > -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o
> > > > > > /tmp/cc-G6mPQL.s -x c
> > > > > > /usr/subversion-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c
> > > > > >
> > > > > > 1. parser at end of file
> > > > > > 2. Code generation
> > > > > > clang: error: clang frontend command failed due to signal 6 (use -v
> > > > > > to see invocation)
> > > > > > *** Error code 250
> > > >
> > > >
> > > > this is a genuine llvm bug it may have been (or may have been not)
> > > > fixed in recent llvm.
> > > >
> > > > if you feel like it - install llvm/clang from subversion and check if
> > > > it compiles this
> > > > ok. if it does not I think it's worth filing a bug in llvm bugzilla..
> >
> > i just wanted to report that the latest clang version doesn't trigger the
> > assert any longer:
> >
> > clang version 2.9 (trunk 124571)
> > Target: x86_64-unknown-freebsd9.0
> > Thread model: posix
> >
> > is there a way to have the local "-fformat-extensions" clang additions
> > pushed
> > upstream? maybe that mght be sufficient to compile the freebsd source with
> > clang 2.9+.
>
> no, it makes no sense to push the printf patches upstream. it's freebsd kernel
> only.
>
> for compiling freebsd kernel you are supposed to use /usr/bin/clang (or just
> ignore the warnings from upstream clang)
you should be able to reproduce the issue on arch=amd64 and the following in
/etc by doing 'make' in lib/libcompiler_rt:
otaku% cat /etc/make.conf /etc/src.conf
cat: /etc/make.conf: No such file or directory
# CLANG options
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
# Don't die on warnings
#NO_WERROR=
#WERROR=
# Enable debugging symbols for world
DEBUG_FLAGS = -g
... removing the "-g" switch from DEBUG_FLAGS solves the issue.
using the 2.9-development branch, lib/libcompiler_rt compiles fine even with
the -g switch.
cheers.
alex
>
>
> what are you trying to do anyway? :)
--
a13x
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: issue with clang and CPUTYPE native
On Mon Jan 31 11, Roman Divacky wrote: > On Mon, Jan 31, 2011 at 04:27:55PM +0000, Alexander Best wrote: > > On Sat Jan 1 11, Alexander Best wrote: > > > On Sat Jan 1 11, Roman Divacky wrote: > > > > > > clang -O2 -pipe -march=native -fpic -fvisibility=hidden > > > > > > -DVISIBILITY_HIDDEN -g -std=gnu99 -fstack-protector > > > > > > -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized > > > > > > -Wno-pointer-sign -c > > > > > > /usr/subversion-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c > > > > > > detected CPU = core2 > > > > > > Assertion failed: (getMinSignedBits() <= 64 && "Too many bits for > > > > > > int64_t"), function getSExtValue, file > > > > > > /usr/subversion-src/lib/clang/libclangcodegen/../../../contrib/llvm/include/llvm/ADT/APInt.h, > > > > > > line 1149. > > > > > > Stack dump: > > > > > > 0. Program arguments: > > > > > > /usr/obj/usr/subversion-src/tmp/usr/bin/clang -cc1 -triple > > > > > > x86_64-undermydesk-freebsd9.0 -S -disable-free -main-file-name > > > > > > mulvti3.c -pic-level 1 -mdisable-fp-elim -mconstructor-aliases > > > > > > -munwind-tables -target-cpu core2 -g -resource-dir > > > > > > /usr/obj/usr/subversion-src/tmp/usr/lib/clang/2.8 -D > > > > > > VISIBILITY_HIDDEN -O2 -Wsystem-headers -Wall -Wno-format-y2k > > > > > > -Wno-uninitialized -Wno-pointer-sign -std=gnu99 -ferror-limit 19 > > > > > > -fmessage-length 275 -fvisibility hidden -stack-protector 1 > > > > > > -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o > > > > > > /tmp/cc-G6mPQL.s -x c > > > > > > /usr/subversion-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c > > > > > > > > > > > > 1. parser at end of file > > > > > > 2. Code generation > > > > > > clang: error: clang frontend command failed due to signal 6 (use -v > > > > > > to see invocation) > > > > > > *** Error code 250 > > > > > > > > > > > > this is a genuine llvm bug it may have been (or may have been not) > > > > fixed in recent llvm. > > > > > > > > if you feel like it - install llvm/clang from subversion and check if > > > > it compiles this > > > > ok. if it does not I think it's worth filing a bug in llvm bugzilla.. > > > > i just wanted to report that the latest clang version doesn't trigger the > > assert any longer: > > > > clang version 2.9 (trunk 124571) > > Target: x86_64-unknown-freebsd9.0 > > Thread model: posix > > > > is there a way to have the local "-fformat-extensions" clang additions > > pushed > > upstream? maybe that mght be sufficient to compile the freebsd source with > > clang 2.9+. > > no, it makes no sense to push the printf patches upstream. it's freebsd kernel > only. > > for compiling freebsd kernel you are supposed to use /usr/bin/clang (or just > ignore the warnings from upstream clang) > > > what are you trying to do anyway? :) compile world without /usr/bin/clang dumping core due to an assert being hit in lib/libcompiler_rt. ;) right now i can only use clang to compile the kernel, but not world. cheers. alex -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: issue with clang and CPUTYPE native
On Sat Jan 1 11, Alexander Best wrote: > On Sat Jan 1 11, Roman Divacky wrote: > > > > clang -O2 -pipe -march=native -fpic -fvisibility=hidden > > > > -DVISIBILITY_HIDDEN -g -std=gnu99 -fstack-protector -Wsystem-headers > > > > -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c > > > > /usr/subversion-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c > > > > detected CPU = core2 > > > > Assertion failed: (getMinSignedBits() <= 64 && "Too many bits for > > > > int64_t"), function getSExtValue, file > > > > /usr/subversion-src/lib/clang/libclangcodegen/../../../contrib/llvm/include/llvm/ADT/APInt.h, > > > > line 1149. > > > > Stack dump: > > > > 0. Program arguments: > > > > /usr/obj/usr/subversion-src/tmp/usr/bin/clang -cc1 -triple > > > > x86_64-undermydesk-freebsd9.0 -S -disable-free -main-file-name > > > > mulvti3.c -pic-level 1 -mdisable-fp-elim -mconstructor-aliases > > > > -munwind-tables -target-cpu core2 -g -resource-dir > > > > /usr/obj/usr/subversion-src/tmp/usr/lib/clang/2.8 -D VISIBILITY_HIDDEN > > > > -O2 -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized > > > > -Wno-pointer-sign -std=gnu99 -ferror-limit 19 -fmessage-length 275 > > > > -fvisibility hidden -stack-protector 1 -fgnu-runtime > > > > -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-G6mPQL.s -x c > > > > /usr/subversion-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c > > > > > > > > 1. parser at end of file > > > > 2. Code generation > > > > clang: error: clang frontend command failed due to signal 6 (use -v to > > > > see invocation) > > > > *** Error code 250 > > > > > > this is a genuine llvm bug it may have been (or may have been not) fixed in > > recent llvm. > > > > if you feel like it - install llvm/clang from subversion and check if it > > compiles this > > ok. if it does not I think it's worth filing a bug in llvm bugzilla.. i just wanted to report that the latest clang version doesn't trigger the assert any longer: clang version 2.9 (trunk 124571) Target: x86_64-unknown-freebsd9.0 Thread model: posix is there a way to have the local "-fformat-extensions" clang additions pushed upstream? maybe that mght be sufficient to compile the freebsd source with clang 2.9+. cheers. alex > > same assert gets hit with svn clang/llvm: > > /usr/local/bin/clang -v -O2 -pipe -march=native -fpic -fvisibility=hidden > -DVISIBILITY_HIDDEN -g -std=gnu99 -fstack-protector -Wsystem-headers -Wall > -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c > /usr/gitorious-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c > clang version 2.9 (trunk 122653) > Target: x86_64-unknown-freebsd9.0 > Thread model: posix > "/usr/local/bin/clang" -cc1 -triple x86_64-unknown-freebsd9.0 -emit-obj > -disable-free -main-file-name mulvti3.c -pic-level 1 -mdisable-fp-elim > -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu core2 > -target-linker-version 2.21 -v -g -resource-dir > /usr/local/bin/../lib/clang/2.9 -D VISIBILITY_HIDDEN -O2 -Wsystem-headers > -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -std=gnu99 > -ferror-limit 19 -fmessage-length 275 -fvisibility hidden -stack-protector 1 > -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o mulvti3.o -x c > /usr/gitorious-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c > clang -cc1 version 2.9 based upon llvm 2.9svn hosted on > x86_64-unknown-freebsd9.0 > #include "..." search starts here: > #include <...> search starts here: > /usr/local/include > /usr/local/bin/../lib/clang/2.9/include > /usr/include > End of search list. > Assertion failed: (getMinSignedBits() <= 64 && "Too many bits for int64_t"), > function getSExtValue, file /usr/local/src/llvm/include/llvm/ADT/APInt.h, > line 1158. > Stack dump: > 0.Program arguments: /usr/local/bin/clang -cc1 -triple > x86_64-unknown-freebsd9.0 -emit-obj -disable-free -main-file-name mulvti3.c > -pic-level 1 -mdisable-fp-elim -masm-verbose -mconstructor-aliases > -munwind-tables -target-cpu core2 -target-linker-version 2.21 -v -g > -resource-dir /usr/local/bin/../lib/clang/2.9 -D VISIBILITY_HIDDEN -O2 > -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign > -std=gnu99 -ferror-limit 19 -fmessage-length 275 -fvisibility hidden > -stack-protector 1 -fgnu-runtime -fdiagnostics-show
Re: [toolchain] ${CC} in share/mk/bsd.cpu.mk
On Mon Jan 31 11, Gerald Pfeifer wrote:
> On Sun, 30 Jan 2011, Alexander Best wrote:
> > i might have described things a bit too complicated. basically i want to
> > have CPUTYPE ?= core2 in my make.conf. clang is capable of producing
> > core2 specific code, however core2 always gets downgraded by
> > share/mk/bsd.cpu.mk to nocona in order not to confuse gcc.
> >
> > any chance of fixing this?
>
> I guess one of those extern compilers Robert has in mind should
> be lang/gcc46 from the Ports Collection which is perfectly happy
> to generate core2 code. I agree we need good infrastructure to
> support such cases.
i just thought we could make the instructions in share/mk/bsd.cpu.mk which
downgrades the CPUTYPE to nocona gcc specific. but for some reason that doesn't
seem to work. :(
Index: bsd.cpu.mk
===
--- bsd.cpu.mk (revision 218104)
+++ bsd.cpu.mk (working copy)
@@ -55,7 +55,7 @@
. elif ${CPUTYPE} == "k7"
CPUTYPE = athlon
. endif
-. elif ${MACHINE_CPUARCH} == "amd64"
+. elif ${MACHINE_CPUARCH} == "amd64" && ${CC} != "clang"
. if ${CPUTYPE} == "prescott" || ${CPUTYPE} == "core2"
CPUTYPE = nocona
. endif
...and still with clang as compiler CPUYTEP gets reset to nocona.
cheers.
alex
>
> Gerald
--
a13x
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: ${CC} in share/mk/bsd.cpu.mk
On Sun Jan 23 11, Alexander Best wrote:
> hi there,
i might have described things a bit too complicated. basically i want to have
CPUTYPE ?= core2 in my make.conf. clang is capable of producing core2 specific
code, however core2 always gets downgraded by share/mk/bsd.cpu.mk to nocona in
order not to confuse gcc.
any chance of fixing this?
cheers.
alex
>
> i was fiddling with share/mk/bsd.cpu.mk in order to add some clang specific
> conditions. however it seems ${CC} is always set to "cc" no matter what's in
> src.conf. this is odd, since there's already some code in bsd.cpu.mk which
> checks ${CC} == icc. right now this code is a noop, since ${CC} can't be
> anything else than "cc". is it possible to somehow fix this?
>
> e.g. there's no reason to set CPUTYPE to nocona, when
> ${CC} == clang && ${CPUTYPE} == core2.
>
> cheers.
> alex
>
> --
> a13x
--
a13x
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
${CC} in share/mk/bsd.cpu.mk
hi there,
i was fiddling with share/mk/bsd.cpu.mk in order to add some clang specific
conditions. however it seems ${CC} is always set to "cc" no matter what's in
src.conf. this is odd, since there's already some code in bsd.cpu.mk which
checks ${CC} == icc. right now this code is a noop, since ${CC} can't be
anything else than "cc". is it possible to somehow fix this?
e.g. there's no reason to set CPUTYPE to nocona, when
${CC} == clang && ${CPUTYPE} == core2.
cheers.
alex
--
a13x
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: How to build an executable with profiling?
On Mon Jan 17 11, Steve Kargl wrote: > How does one build an executable for profiling with clang? > > clang -o testf -O2 -march=native -pipe -static -pg -I/usr/local/include > -I../mp testf.c -L/usr/local/lib -L../mp -lsgk -lmpfr -lgmp > -L/usr/home/kargl/work/lib -lm_clang_p > clang: warning: the clang compiler does not support '-pg' > > I suppose it will be pointless to ask, but shouldn't clang > support one of the most basic gcc compiler options if clang > is to replace gcc as the base system compiler? profiling is not yet supported by clang irrc. the same goes for cross-compiling. both features will be introduced in one of the next releases. clang is still missing a few gcc features, however i think that's obvious taking into account that gcc exists way longer than clang. however it's also obvious that in a few years gcc will be completely replaced by clang as main open source C/C++ compiler, since it offers tons of advantages and only very few disadvanteges. cheers. alex > > -- > Steve -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: searchpath for clang
On Sun Jan 9 11, Dimitry Andric wrote: > On 2011-01-09 15:31, Alexander Best wrote: > ... > >i really cannot spot the problem on my system. :( > ... > >In file included from /usr/subversion-src/usr.bin/make/parse.c:75: > >/usr/local/bin/../lib/clang/2.9/include/stdarg.h:47:9: warning: > >'__GNUC_VA_LIST' macro redefined > >#define __GNUC_VA_LIST 1 > > ^ > > From /usr/local/lib/clang/2.9/include, you must remove (or move out of > the way) all .h files that already exist in /usr/include, because they > clash with our standard includes. Normally the files to be moved are: > > float.h > iso646.h > limits.h > stdarg.h > stdbool.h > stddef.h > stdint.h > tgmath.h > varargs.h i renamed /usr/local/lib/clang/2.9/include to something else and re-ran target buildworld. what's interesting is that /usr/local/bin/clang only gets picked up in this section: >>> Building an up-to-date make(1) after the following message: >>> World build started on Sun Jan 9 15:49:53 CET 2011 /usr/bin/clang gets chosen i suspect $PATH doesn't get discarded when building make(1). cheers. alex > > It would be better if the port already did this, though... -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: searchpath for clang
On Sun Jan 9 11, Dimitry Andric wrote:
> On 2011-01-09 01:50, Alexander Best wrote:
> >i just noticed that when CC is set to clang, target buildworld will honour
> >$PATH, whereas target buildkernel doesn't. shouldn't target buildworld also
> >discarg $PATH?
>
> It does discard PATH. See the top Makefile, one of the first things it
> does is:
>
> PATH= /sbin:/bin:/usr/sbin:/usr/bin
>
> And for subsequent stages, PATH is set to various other values.
>
>
> >i have a clang 2.9 svn snapshot installed under /usr/local/bin
> >and target buildworld failed, because this version was picked up instead
> >of the
> >one under /usr/bin.
>
> Are you building world with CC=/usr/local/bin/clang? If so, that is
> most likely your problem. Specifying a full path for CC (or CXX) always
> overrides the command used during the world stage.
>
> Normally, CC is set to "cc" or "clang", so without any absolute path.
> During the various build stages, PATH is set to different values,
> causing *different* compiler and binutils executables to be used during
> those stages, e.g.:
>
> - /usr/bin/cc, /usr/bin/ld and so on, during the legacy,
> bootstrap-tools, build-tools and cross-tools stages.
> - ${WORLDTMP}/usr/bin/cc, ${WORLDTMP}/usr/bin/ld and so on, during the
> world and install stages.
>
> In your case, if you want to compile the bootstrap stages with clang
> trunk, but the world with the version of clang that is in the source
> tree, you must modify the top Makefile to have:
>
> PATH= /usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
>
> and then use CC=clang, CXX=clang++.
i really cannot spot the problem on my system. :(
otaku% /usr/bin/clang -v
FreeBSD clang version 2.8 (tags/RELEASE_28 115870) 20101007
Target: x86_64-undermydesk-freebsd9.0
Thread model: posix
otaku% /usr/local/bin/clang -v
clang version 2.9 (trunk 122855)
Target: x86_64-unknown-freebsd9.0
Thread model: posix
otaku% grep -v '^#' /etc/src.conf
.if !defined(CC) || ${CC} == "cc"
CC=clang -v
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++ -v
.endif
NO_WERROR=
WERROR=
DEBUG_FLAGS = -g
otaku% make buildworld
...
clang -v -O2 -pipe -I/usr/subversion-src/usr.bin/make
-DMAKE_VERSION=\"5200408120\" -DDEFSHELLNAME=\"sh\" -g -std=gnu99
-fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -W
-Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith
-Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter
-Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls
-Wold-style-definition -Wno-pointer-sign -c
/usr/subversion-src/usr.bin/make/parse.c
clang version 2.9 (trunk 122855)
Target: x86_64-unknown-freebsd9.0
Thread model: posix
"/usr/local/bin/clang" -cc1 -triple x86_64-unknown-freebsd9.0 -emit-obj
-disable-free -main-file-name parse.c -mrelocation-model static
-mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -target-linker-version 2.21 -v -g -resource-dir
/usr/local/bin/../lib/clang/2.9 -D MAKE_VERSION="5200408120" -D
DEFSHELLNAME="sh" -I /usr/subversion-src/usr.bin/make -O2 -Wsystem-headers
-Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign
-std=gnu99 -ferror-limit 19 -fmessage-length 275 -stack-protector 1
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o parse.o -x c
/usr/subversion-src/usr.bin/make/parse.c
clang -cc1 version 2.9 based upon llvm 2.9svn hosted on
x86_64-unknown-freebsd9.0
#include "..." search starts here:
#include <...> search starts here:
/usr/subversion-src/usr.bin/make
/usr/local/include
/usr/local/bin/../lib/clang/2.9/include
/usr/include
End of search list.
In file included from /usr/subversion-src/usr.bin/make/parse.c:75:
/usr/local/bin/../lib/clang/2.9/include/stdarg.h:47:9: warning:
'__GNUC_VA_LIST' macro redefined
#define __GNUC_VA_LIST 1
^
In file included from /usr/subversion-src/usr.bin/make/parse.c:74:
In file included from /usr/include/ctype.h:45:
In file included from /usr/include/sys/_types.h:33:
/usr/include/machine/_types.h:113:9: note: previous definition is here
#define __GNUC_VA_LIST
^
In file included from /usr/subversion-src/usr.bin/make/parse.c:75:
/usr/local/bin/../lib/clang/2.9/include/stdarg.h:48:27: error: redefinition of
typedef '__gnuc_va_list' is invalid in C [-Wtypedef-redefinition]
typedef __builtin_va_list __gnuc_va_list;
^
In file included from /usr/subve
searchpath for clang
i just noticed that when CC is set to clang, target buildworld will honour $PATH, whereas target buildkernel doesn't. shouldn't target buildworld also discarg $PATH? i have a clang 2.9 svn snapshot installed under /usr/local/bin and target buildworld failed, because this version was picked up instead of the one under /usr/bin. cheers. alex -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang fails to crossbuild world for i386 on amd64
On Tue Jan 4 11, Dimitry Andric wrote: > On 2011-01-04 21:02, Alexander Best wrote: > >just experienced this failure. the command line i used is right at the end: > ... > >/tmp/cc-dFZCvC.s: Assembler messages: > >/tmp/cc-dFZCvC.s:33: Error: suffix or operands invalid for `push' > > Crosscompiling isn't supported (yet) with clang. They're apparently > working on it... contributions welcome. :) thanks for the hint. wasn't aware clang doesn't support it yet. cheers. alex -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
clang fails to crossbuild world for i386 on amd64
hi there, just experienced this failure. the command line i used is right at the end: -- >>> stage 4.2: building libraries -- cd /usr/subversion-src; MAKEOBJDIRPREFIX=/usr/obj/i386.i386 MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/usr/obj/i386.i386/usr/subversion-src/tmp/legacy/usr/bin GROFF_FONT_PATH=/usr/obj/i386.i386/usr/subversion-src/tmp/legacy/usr/share/groff_font GROFF_TMAC cd /usr/subversion-src; /usr/obj/usr/subversion-src/make.amd64/make -f Makefile.inc1 _prereq_libs; /usr/obj/usr/subversion-src/make.amd64/make -f Makefile.inc1 _startup_libs; /usr/obj/usr/subversion-src/make.amd64/make -f Makefile.inc1 _prebuild_libs; /usr/obj/usr/subver ===> gnu/lib/libssp/libssp_nonshared (obj,depend,all,install) clang -v -O2 -pipe -DHAVE_CONFIG_H -I/usr/subversion-src/gnu/lib/libssp/libssp_nonshared/.. -I/usr/subversion-src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp -I/usr/subversion-src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include - FreeBSD clang version 2.8 (tags/RELEASE_28 115870) 20101007 Target: x86_64-undermydesk-freebsd9.0 Thread model: posix "/usr/obj/i386.i386/usr/subversion-src/tmp/usr/bin/clang" -cc1 -triple x86_64-undermydesk-freebsd9.0 -S -disable-free -main-file-name ssp-local.c -pic-level 2 -mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v -g -resource-dir /usr/obj/i386.i386/u clang -cc1 version 2.8 based upon llvm 2.8svn hosted on x86_64-undermydesk-freebsd9.0 ignoring nonexistent directory "/usr/obj/i386.i386/usr/subversion-src/tmp/usr/lib/clang/2.8/include" #include "..." search starts here: #include <...> search starts here: /usr/subversion-src/gnu/lib/libssp/libssp_nonshared/.. /usr/subversion-src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/libssp /usr/subversion-src/gnu/lib/libssp/libssp_nonshared/../../../../contrib/gcclibs/include /usr/obj/i386.i386/usr/subversion-src/tmp/usr/include/clang/2.8 /usr/obj/i386.i386/usr/subversion-src/tmp/usr/include End of search list. "/usr/obj/i386.i386/usr/subversion-src/tmp/usr/bin/as" -o ssp-local.o /tmp/cc-dFZCvC.s /tmp/cc-dFZCvC.s: Assembler messages: /tmp/cc-dFZCvC.s:33: Error: suffix or operands invalid for `push' /tmp/cc-dFZCvC.s:35: Error: suffix or operands invalid for `movq' /tmp/cc-dFZCvC.s:38: Error: suffix or operands invalid for `pop' clang: error: assembler command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop in /usr/subversion-src/gnu/lib/libssp/libssp_nonshared. *** Error code 1 Stop in /usr/subversion-src. *** Error code 1 Stop in /usr/subversion-src. *** Error code 1 Stop in /usr/subversion-src. *** Error code 1 Stop in /usr/subversion-src. make buildworld TARGET=i386 72,41s user 17,42s system 66% cpu 2:14,98 total this is on amd64 and HEAD (r216877). can anybody verify this? with gcc as compiler everything works just fine. cheers. alex -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: issue with clang and CPUTYPE native
On Sat Jan 1 11, Roman Divacky wrote: > > > clang -O2 -pipe -march=native -fpic -fvisibility=hidden > > > -DVISIBILITY_HIDDEN -g -std=gnu99 -fstack-protector -Wsystem-headers > > > -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c > > > /usr/subversion-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c > > > detected CPU = core2 > > > Assertion failed: (getMinSignedBits() <= 64 && "Too many bits for > > > int64_t"), function getSExtValue, file > > > /usr/subversion-src/lib/clang/libclangcodegen/../../../contrib/llvm/include/llvm/ADT/APInt.h, > > > line 1149. > > > Stack dump: > > > 0.Program arguments: > > > /usr/obj/usr/subversion-src/tmp/usr/bin/clang -cc1 -triple > > > x86_64-undermydesk-freebsd9.0 -S -disable-free -main-file-name mulvti3.c > > > -pic-level 1 -mdisable-fp-elim -mconstructor-aliases -munwind-tables > > > -target-cpu core2 -g -resource-dir > > > /usr/obj/usr/subversion-src/tmp/usr/lib/clang/2.8 -D VISIBILITY_HIDDEN > > > -O2 -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized > > > -Wno-pointer-sign -std=gnu99 -ferror-limit 19 -fmessage-length 275 > > > -fvisibility hidden -stack-protector 1 -fgnu-runtime > > > -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-G6mPQL.s -x c > > > /usr/subversion-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c > > > > > > 1. parser at end of file > > > 2.Code generation > > > clang: error: clang frontend command failed due to signal 6 (use -v to > > > see invocation) > > > *** Error code 250 > > > this is a genuine llvm bug it may have been (or may have been not) fixed in > recent llvm. > > if you feel like it - install llvm/clang from subversion and check if it > compiles this > ok. if it does not I think it's worth filing a bug in llvm bugzilla.. same assert gets hit with svn clang/llvm: /usr/local/bin/clang -v -O2 -pipe -march=native -fpic -fvisibility=hidden -DVISIBILITY_HIDDEN -g -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/gitorious-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c clang version 2.9 (trunk 122653) Target: x86_64-unknown-freebsd9.0 Thread model: posix "/usr/local/bin/clang" -cc1 -triple x86_64-unknown-freebsd9.0 -emit-obj -disable-free -main-file-name mulvti3.c -pic-level 1 -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu core2 -target-linker-version 2.21 -v -g -resource-dir /usr/local/bin/../lib/clang/2.9 -D VISIBILITY_HIDDEN -O2 -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -std=gnu99 -ferror-limit 19 -fmessage-length 275 -fvisibility hidden -stack-protector 1 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o mulvti3.o -x c /usr/gitorious-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c clang -cc1 version 2.9 based upon llvm 2.9svn hosted on x86_64-unknown-freebsd9.0 #include "..." search starts here: #include <...> search starts here: /usr/local/include /usr/local/bin/../lib/clang/2.9/include /usr/include End of search list. Assertion failed: (getMinSignedBits() <= 64 && "Too many bits for int64_t"), function getSExtValue, file /usr/local/src/llvm/include/llvm/ADT/APInt.h, line 1158. Stack dump: 0. Program arguments: /usr/local/bin/clang -cc1 -triple x86_64-unknown-freebsd9.0 -emit-obj -disable-free -main-file-name mulvti3.c -pic-level 1 -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu core2 -target-linker-version 2.21 -v -g -resource-dir /usr/local/bin/../lib/clang/2.9 -D VISIBILITY_HIDDEN -O2 -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -std=gnu99 -ferror-limit 19 -fmessage-length 275 -fvisibility hidden -stack-protector 1 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o mulvti3.o -x c /usr/gitorious-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c 1. parser at end of file 2. Code generation 3. Running pass 'Function Pass Manager' on module '/usr/gitorious-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c'. clang: error: unable to execute command: Abort trap: 6 (core dumped) clang: error: clang frontend command failed due to signal 1 (use -v to see invocation) *** Error code 255 Stop in /usr/gitorious-src/lib/libcompiler_rt. cheers. alex > > thank you! -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: issue with clang and CPUTYPE native
On Sat Jan 1 11, Roman Divacky wrote: > > > clang -O2 -pipe -march=native -fpic -fvisibility=hidden > > > -DVISIBILITY_HIDDEN -g -std=gnu99 -fstack-protector -Wsystem-headers > > > -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c > > > /usr/subversion-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c > > > detected CPU = core2 > > > Assertion failed: (getMinSignedBits() <= 64 && "Too many bits for > > > int64_t"), function getSExtValue, file > > > /usr/subversion-src/lib/clang/libclangcodegen/../../../contrib/llvm/include/llvm/ADT/APInt.h, > > > line 1149. > > > Stack dump: > > > 0.Program arguments: > > > /usr/obj/usr/subversion-src/tmp/usr/bin/clang -cc1 -triple > > > x86_64-undermydesk-freebsd9.0 -S -disable-free -main-file-name mulvti3.c > > > -pic-level 1 -mdisable-fp-elim -mconstructor-aliases -munwind-tables > > > -target-cpu core2 -g -resource-dir > > > /usr/obj/usr/subversion-src/tmp/usr/lib/clang/2.8 -D VISIBILITY_HIDDEN > > > -O2 -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized > > > -Wno-pointer-sign -std=gnu99 -ferror-limit 19 -fmessage-length 275 > > > -fvisibility hidden -stack-protector 1 -fgnu-runtime > > > -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-G6mPQL.s -x c > > > /usr/subversion-src/lib/libcompiler_rt/../../contrib/compiler-rt/lib/mulvti3.c > > > > > > 1. parser at end of file > > > 2.Code generation > > > clang: error: clang frontend command failed due to signal 6 (use -v to > > > see invocation) > > > *** Error code 250 > > > this is a genuine llvm bug it may have been (or may have been not) fixed in > recent llvm. > > if you feel like it - install llvm/clang from subversion and check if it > compiles this > ok. if it does not I think it's worth filing a bug in llvm bugzilla.. thanks for the hint. i'll first try lang/devel-clang. maybe that version already has the fix in it. if that doesn't work i'll grab a subversion snapshot. cheers. alex > > thank you! -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: issue with clang and CPUTYPE native
On Fri Dec 31 10, Alexander Best wrote: > On Fri Dec 31 10, Alexander Best wrote: > > On Fri Dec 31 10, Roman Divacky wrote: > > > On Fri, Dec 31, 2010 at 01:20:02AM +0000, Alexander Best wrote: > > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > > On Thu, Dec 30, 2010 at 06:46:16PM +, Alexander Best wrote: > > > > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > > > > On Thu, Dec 30, 2010 at 06:40:48PM +, Alexander Best wrote: > > > > > > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > > > > > > On Thu, Dec 30, 2010 at 12:20:33AM +, Alexander Best > > > > > > > > > wrote: > > > > > > > > > > On Tue Dec 28 10, Roman Divacky wrote: > > > > > > > > > > > -march=native in clang works by detecting CPU name > > > > > > > > > > > and passing it (if found) to llvm. if the CPU is not > > > > > > > > > > > detected nothing is passed. > > > > > > > > > > > > > > > > > > > > > > nocona is supported > > > > > > > > > > > > > > > > > > > > > > ie. leaving the CPUNAME empty or specifying it to > > > > > > > > > > > "nocona" should > > > > > > > > > > > be equivalent to setting it to "native". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > can you apply this patch: > > > > > > > > > > > > > > > > > > > > > > Index: Driver/Tools.cpp > > > > > > > > > > > === > > > > > > > > > > > --- Driver/Tools.cpp (revision 122591) > > > > > > > > > > > +++ Driver/Tools.cpp (working copy) > > > > > > > > > > > @@ -684,6 +684,7 @@ > > > > > > > > > > >// FIXME: We should also incorporate the detected > > > > > > > > > > > target features for use > > > > > > > > > > >// with -native. > > > > > > > > > > >std::string CPU = llvm::sys::getHostCPUName(); > > > > > > > > > > > + llvm::outs() << "detected CPU = " << CPU << "\n"; > > > > > > > > > > >if (!CPU.empty()) > > > > > > > > > > > CPUName = Args.MakeArgString(CPU); > > > > > > > > > > > } else > > > > > > > > > > > > > > > > > > > > thanks a lot for the patch. i've applied it, but am not > > > > > > > > > > sure how to only > > > > > > > > > > compile clang. 'make' in usr.bin/clang fails. do i have to > > > > > > > > > > run target > > > > > > > > > > buildworld or is there a way to only build clang? > > > > > > > > > > > > > > > > > > I would guess that cd lib/clang && make && cd > > > > > > > > > ../../usr.bin/clang && make > > > > > > > > > should work, if not - full buildworld is necessary I guess > > > > > > > > > > > > > > > > thanks. that worked. this is what clang detects as my cpu: > > > > > > > > > > > > > > > > -march=native > > > > > > > > > > > > > > hm? are you sure it wrote -march=native? it should have written > > > > > > > > > > > > oh sorry. i copy&pasted the wrong line. :( > > > > > > > > > > > > detected CPU = core2 > > > > > > > > > > yes, you have core2, maybe thats why using CPU=nocona is causing you > > > > > problems? > > > > > > > > CPU=nocona *isn't* causing problems. CPU=native is causing the problems. > > > > > > > > core2 is wrong imo. have a look at share/mk/bsd.cpu.mk for amd64. it > > > > sets core2 > > > > to nocona. so cla
Re: issue with clang and CPUTYPE native
On Fri Dec 31 10, Alexander Best wrote: > On Fri Dec 31 10, Roman Divacky wrote: > > On Fri, Dec 31, 2010 at 01:20:02AM +, Alexander Best wrote: > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > On Thu, Dec 30, 2010 at 06:46:16PM +, Alexander Best wrote: > > > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > > > On Thu, Dec 30, 2010 at 06:40:48PM +, Alexander Best wrote: > > > > > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > > > > > On Thu, Dec 30, 2010 at 12:20:33AM +, Alexander Best wrote: > > > > > > > > > On Tue Dec 28 10, Roman Divacky wrote: > > > > > > > > > > -march=native in clang works by detecting CPU name > > > > > > > > > > and passing it (if found) to llvm. if the CPU is not > > > > > > > > > > detected nothing is passed. > > > > > > > > > > > > > > > > > > > > nocona is supported > > > > > > > > > > > > > > > > > > > > ie. leaving the CPUNAME empty or specifying it to "nocona" > > > > > > > > > > should > > > > > > > > > > be equivalent to setting it to "native". > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > can you apply this patch: > > > > > > > > > > > > > > > > > > > > Index: Driver/Tools.cpp > > > > > > > > > > === > > > > > > > > > > --- Driver/Tools.cpp(revision 122591) > > > > > > > > > > +++ Driver/Tools.cpp(working copy) > > > > > > > > > > @@ -684,6 +684,7 @@ > > > > > > > > > >// FIXME: We should also incorporate the detected > > > > > > > > > > target features for use > > > > > > > > > >// with -native. > > > > > > > > > >std::string CPU = llvm::sys::getHostCPUName(); > > > > > > > > > > + llvm::outs() << "detected CPU = " << CPU << "\n"; > > > > > > > > > >if (!CPU.empty()) > > > > > > > > > > CPUName = Args.MakeArgString(CPU); > > > > > > > > > > } else > > > > > > > > > > > > > > > > > > thanks a lot for the patch. i've applied it, but am not sure > > > > > > > > > how to only > > > > > > > > > compile clang. 'make' in usr.bin/clang fails. do i have to > > > > > > > > > run target > > > > > > > > > buildworld or is there a way to only build clang? > > > > > > > > > > > > > > > > I would guess that cd lib/clang && make && cd > > > > > > > > ../../usr.bin/clang && make > > > > > > > > should work, if not - full buildworld is necessary I guess > > > > > > > > > > > > > > thanks. that worked. this is what clang detects as my cpu: > > > > > > > > > > > > > > -march=native > > > > > > > > > > > > hm? are you sure it wrote -march=native? it should have written > > > > > > > > > > oh sorry. i copy&pasted the wrong line. :( > > > > > > > > > > detected CPU = core2 > > > > > > > > yes, you have core2, maybe thats why using CPU=nocona is causing you > > > > problems? > > > > > > CPU=nocona *isn't* causing problems. CPU=native is causing the problems. > > > > > > core2 is wrong imo. have a look at share/mk/bsd.cpu.mk for amd64. it sets > > > core2 > > > to nocona. so clang should detect nocona for CPU=native and *not* core2. > > > > no, your cpu is core2 so clang is correct to detect is as such. it's imho > > irrelevant > > that we (freebsd mk framework) reset core2 to nocona. > > i'm sorry. you're of course right. looking at the manual page of a newer gcc > release reveals that core2 is in fact the correct cpu. > &g
Re: issue with clang and CPUTYPE native
On Fri Dec 31 10, Roman Divacky wrote: > On Fri, Dec 31, 2010 at 01:20:02AM +0000, Alexander Best wrote: > > On Thu Dec 30 10, Roman Divacky wrote: > > > On Thu, Dec 30, 2010 at 06:46:16PM +0000, Alexander Best wrote: > > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > > On Thu, Dec 30, 2010 at 06:40:48PM +, Alexander Best wrote: > > > > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > > > > On Thu, Dec 30, 2010 at 12:20:33AM +, Alexander Best wrote: > > > > > > > > On Tue Dec 28 10, Roman Divacky wrote: > > > > > > > > > -march=native in clang works by detecting CPU name > > > > > > > > > and passing it (if found) to llvm. if the CPU is not > > > > > > > > > detected nothing is passed. > > > > > > > > > > > > > > > > > > nocona is supported > > > > > > > > > > > > > > > > > > ie. leaving the CPUNAME empty or specifying it to "nocona" > > > > > > > > > should > > > > > > > > > be equivalent to setting it to "native". > > > > > > > > > > > > > > > > > > > > > > > > > > > can you apply this patch: > > > > > > > > > > > > > > > > > > Index: Driver/Tools.cpp > > > > > > > > > === > > > > > > > > > --- Driver/Tools.cpp (revision 122591) > > > > > > > > > +++ Driver/Tools.cpp (working copy) > > > > > > > > > @@ -684,6 +684,7 @@ > > > > > > > > >// FIXME: We should also incorporate the detected > > > > > > > > > target features for use > > > > > > > > >// with -native. > > > > > > > > >std::string CPU = llvm::sys::getHostCPUName(); > > > > > > > > > + llvm::outs() << "detected CPU = " << CPU << "\n"; > > > > > > > > >if (!CPU.empty()) > > > > > > > > > CPUName = Args.MakeArgString(CPU); > > > > > > > > > } else > > > > > > > > > > > > > > > > thanks a lot for the patch. i've applied it, but am not sure > > > > > > > > how to only > > > > > > > > compile clang. 'make' in usr.bin/clang fails. do i have to run > > > > > > > > target > > > > > > > > buildworld or is there a way to only build clang? > > > > > > > > > > > > > > I would guess that cd lib/clang && make && cd ../../usr.bin/clang > > > > > > > && make > > > > > > > should work, if not - full buildworld is necessary I guess > > > > > > > > > > > > thanks. that worked. this is what clang detects as my cpu: > > > > > > > > > > > > -march=native > > > > > > > > > > hm? are you sure it wrote -march=native? it should have written > > > > > > > > oh sorry. i copy&pasted the wrong line. :( > > > > > > > > detected CPU = core2 > > > > > > yes, you have core2, maybe thats why using CPU=nocona is causing you > > > problems? > > > > CPU=nocona *isn't* causing problems. CPU=native is causing the problems. > > > > core2 is wrong imo. have a look at share/mk/bsd.cpu.mk for amd64. it sets > > core2 > > to nocona. so clang should detect nocona for CPU=native and *not* core2. > > no, your cpu is core2 so clang is correct to detect is as such. it's imho > irrelevant > that we (freebsd mk framework) reset core2 to nocona. i'm sorry. you're of course right. looking at the manual page of a newer gcc release reveals that core2 is in fact the correct cpu. what i did now was to clean out my src.conf and make.conf and run buildworld with gcc and with clang. you can see the results in the attached file in addition to the contents of my src.conf and make.conf right now i'm trying to repeat the tests with cpu set to core2 and nocona. cheers. alex > > the reason for that is imho that gcc 4.2.1 does not support core2 so we > "downgrade" >
Re: issue with clang and CPUTYPE native
On Thu Dec 30 10, Roman Divacky wrote: > On Thu, Dec 30, 2010 at 06:46:16PM +0000, Alexander Best wrote: > > On Thu Dec 30 10, Roman Divacky wrote: > > > On Thu, Dec 30, 2010 at 06:40:48PM +0000, Alexander Best wrote: > > > > On Thu Dec 30 10, Roman Divacky wrote: > > > > > On Thu, Dec 30, 2010 at 12:20:33AM +, Alexander Best wrote: > > > > > > On Tue Dec 28 10, Roman Divacky wrote: > > > > > > > -march=native in clang works by detecting CPU name > > > > > > > and passing it (if found) to llvm. if the CPU is not > > > > > > > detected nothing is passed. > > > > > > > > > > > > > > nocona is supported > > > > > > > > > > > > > > ie. leaving the CPUNAME empty or specifying it to "nocona" should > > > > > > > be equivalent to setting it to "native". > > > > > > > > > > > > > > > > > > > > > can you apply this patch: > > > > > > > > > > > > > > Index: Driver/Tools.cpp > > > > > > > === > > > > > > > --- Driver/Tools.cpp (revision 122591) > > > > > > > +++ Driver/Tools.cpp (working copy) > > > > > > > @@ -684,6 +684,7 @@ > > > > > > >// FIXME: We should also incorporate the detected target > > > > > > > features for use > > > > > > >// with -native. > > > > > > >std::string CPU = llvm::sys::getHostCPUName(); > > > > > > > + llvm::outs() << "detected CPU = " << CPU << "\n"; > > > > > > >if (!CPU.empty()) > > > > > > > CPUName = Args.MakeArgString(CPU); > > > > > > > } else > > > > > > > > > > > > thanks a lot for the patch. i've applied it, but am not sure how to > > > > > > only > > > > > > compile clang. 'make' in usr.bin/clang fails. do i have to run > > > > > > target > > > > > > buildworld or is there a way to only build clang? > > > > > > > > > > I would guess that cd lib/clang && make && cd ../../usr.bin/clang && > > > > > make > > > > > should work, if not - full buildworld is necessary I guess > > > > > > > > thanks. that worked. this is what clang detects as my cpu: > > > > > > > > -march=native > > > > > > hm? are you sure it wrote -march=native? it should have written > > > > oh sorry. i copy&pasted the wrong line. :( > > > > detected CPU = core2 > > yes, you have core2, maybe thats why using CPU=nocona is causing you problems? CPU=nocona *isn't* causing problems. CPU=native is causing the problems. core2 is wrong imo. have a look at share/mk/bsd.cpu.mk for amd64. it sets core2 to nocona. so clang should detect nocona for CPU=native and *not* core2. however i'll try to run buildworld again with the patched clang to completely pinpoint the problem. cheers. alex -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: issue with clang and CPUTYPE native
On Thu Dec 30 10, Roman Divacky wrote: > On Thu, Dec 30, 2010 at 06:40:48PM +0000, Alexander Best wrote: > > On Thu Dec 30 10, Roman Divacky wrote: > > > On Thu, Dec 30, 2010 at 12:20:33AM +0000, Alexander Best wrote: > > > > On Tue Dec 28 10, Roman Divacky wrote: > > > > > -march=native in clang works by detecting CPU name > > > > > and passing it (if found) to llvm. if the CPU is not > > > > > detected nothing is passed. > > > > > > > > > > nocona is supported > > > > > > > > > > ie. leaving the CPUNAME empty or specifying it to "nocona" should > > > > > be equivalent to setting it to "native". > > > > > > > > > > > > > > > can you apply this patch: > > > > > > > > > > Index: Driver/Tools.cpp > > > > > === > > > > > --- Driver/Tools.cpp (revision 122591) > > > > > +++ Driver/Tools.cpp (working copy) > > > > > @@ -684,6 +684,7 @@ > > > > >// FIXME: We should also incorporate the detected target > > > > > features for use > > > > >// with -native. > > > > >std::string CPU = llvm::sys::getHostCPUName(); > > > > > + llvm::outs() << "detected CPU = " << CPU << "\n"; > > > > >if (!CPU.empty()) > > > > > CPUName = Args.MakeArgString(CPU); > > > > > } else > > > > > > > > thanks a lot for the patch. i've applied it, but am not sure how to only > > > > compile clang. 'make' in usr.bin/clang fails. do i have to run target > > > > buildworld or is there a way to only build clang? > > > > > > I would guess that cd lib/clang && make && cd ../../usr.bin/clang && make > > > should work, if not - full buildworld is necessary I guess > > > > thanks. that worked. this is what clang detects as my cpu: > > > > -march=native > > hm? are you sure it wrote -march=native? it should have written oh sorry. i copy&pasted the wrong line. :( detected CPU = core2 > > "detected CPU = something" -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: issue with clang and CPUTYPE native
On Thu Dec 30 10, Roman Divacky wrote: > On Thu, Dec 30, 2010 at 12:20:33AM +0000, Alexander Best wrote: > > On Tue Dec 28 10, Roman Divacky wrote: > > > -march=native in clang works by detecting CPU name > > > and passing it (if found) to llvm. if the CPU is not > > > detected nothing is passed. > > > > > > nocona is supported > > > > > > ie. leaving the CPUNAME empty or specifying it to "nocona" should > > > be equivalent to setting it to "native". > > > > > > > > > can you apply this patch: > > > > > > Index: Driver/Tools.cpp > > > === > > > --- Driver/Tools.cpp (revision 122591) > > > +++ Driver/Tools.cpp (working copy) > > > @@ -684,6 +684,7 @@ > > >// FIXME: We should also incorporate the detected target features > > > for use > > >// with -native. > > >std::string CPU = llvm::sys::getHostCPUName(); > > > + llvm::outs() << "detected CPU = " << CPU << "\n"; > > >if (!CPU.empty()) > > > CPUName = Args.MakeArgString(CPU); > > > } else > > > > thanks a lot for the patch. i've applied it, but am not sure how to only > > compile clang. 'make' in usr.bin/clang fails. do i have to run target > > buildworld or is there a way to only build clang? > > I would guess that cd lib/clang && make && cd ../../usr.bin/clang && make > should work, if not - full buildworld is necessary I guess thanks. that worked. this is what clang detects as my cpu: -march=native this the dmesg output: CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (2394.05-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fd Family = 6 Model = f Stepping = 13 Features=0xbfebfbff Features2=0xe39d AMD Features=0x20100800 AMD Features2=0x1 TSC: P-state invariant cheers. alex -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: issue with clang and CPUTYPE native
On Tue Dec 28 10, Roman Divacky wrote: > -march=native in clang works by detecting CPU name > and passing it (if found) to llvm. if the CPU is not > detected nothing is passed. > > nocona is supported > > ie. leaving the CPUNAME empty or specifying it to "nocona" should > be equivalent to setting it to "native". > > > can you apply this patch: > > Index: Driver/Tools.cpp > === > --- Driver/Tools.cpp (revision 122591) > +++ Driver/Tools.cpp (working copy) > @@ -684,6 +684,7 @@ >// FIXME: We should also incorporate the detected target features for > use >// with -native. >std::string CPU = llvm::sys::getHostCPUName(); > + llvm::outs() << "detected CPU = " << CPU << "\n"; >if (!CPU.empty()) > CPUName = Args.MakeArgString(CPU); > } else thanks a lot for the patch. i've applied it, but am not sure how to only compile clang. 'make' in usr.bin/clang fails. do i have to run target buildworld or is there a way to only build clang? cheers. alex > > > and try to > > clang -march=native hello_world.c > > ? I wonder what cpu (if any) is detected. > > > On Mon, Dec 27, 2010 at 09:35:59PM +, Alexander Best wrote: > > hi there, > > > > i've been experiencing the following problems with clang during TARGET > > buildworld for quite a while now: > > > > CODE > > clang++ -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H > > -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include > > -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ > > -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc > > -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. > > -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -fstack-protector > > -fno-implicit-templates -ffunction-sections -fdata-sections -c > > /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc > > clang++: warning: argument unused during compilation: > > '-fno-implicit-templates' > > clang++ -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H > > -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include > > -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ > > -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc > > -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. > > -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -fstack-protector > > -fno-implicit-templates -ffunction-sections -fdata-sections -c > > /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vec.cc > > clang++: warning: argument unused during compilation: > > '-fno-implicit-templates' > > clang++ -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H > > -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include > > -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ > > -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc > > -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. > > -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -fstack-protector > > -fno-implicit-templates -ffunction-sections -fdata-sections -c > > /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vterminate.cc > > clang++: warning: argument unused during compilation: > > '-fno-implicit-templates' > > clang -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H > > -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include > > -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ > > -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc > > -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. > > -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -std=gnu99 > > -fstack-protector -c > > /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/libiberty/cp-demangle.c > > building static supc++ library > > ranlib libsupc++.a > > ===> gnu/lib/libobjc (all) > > gcc -O2 -pipe -march=native -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS > > -I. -I/usr/subversion-src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools > > -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/libobjc/objc > > -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/libobjc > > -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/gcc/config > > -I/us
Re: clang and -mfpmath=387 on ARCH=amd64
On Mon Dec 27 10, Ade Lovett wrote: > > On Dec 26, 2010, at 15:00 , Alexander Best wrote: > > it seems this issue is one of the cases where everybody is too afraid to > > make > > the actual commit. :( > > More likely, it's a case of let's get 7.4/8.2 out the door, with the usual > rush of MFCs. > > I have a feeling that 9.0 (perhaps the entire 9.x tree) is going to be pretty > brutal. Whether it's with gcc and clang side by side, or just clang. A > change of this magnitude is going to _hurt_. if i understood the previous comments correctly this change will have *no* impact whatsoever appart from keeping stdout/stderr a bit cleaner. well...of course rushing changes is not a good idea but the opposide is just as bad. there are hundreds of very techie discussions where developers aggree on a certain item, but after the discussions ends nothing happens. e.g.: - switching the source for pciconf - mfc'ing the latest awk release to stable/7 - fixing some serious data corruption in the mailinglist archives - revising BDECFLAGS - ... plus numerous PRs which contain *correct* patches, now outdated due to their age. also this is very discouraging. a lot of people stop their community support, since their work (e.g. patches) dye of old age in some problem report. personally i write far less patches than i used too, simply because most of the time nobody will help you get the patches committed, even if they fix trivial spelling mistakes in manual pages. just my 0.02$. cheers. alex > > -aDe > -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
issue with clang and CPUTYPE native
hi there, i've been experiencing the following problems with clang during TARGET buildworld for quite a while now: CODE clang++ -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/tinfo2.cc clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang++ -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vec.cc clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang++ -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -fstack-protector -fno-implicit-templates -ffunction-sections -fdata-sections -c /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++/vterminate.cc clang++: warning: argument unused during compilation: '-fno-implicit-templates' clang -O2 -pipe -march=native -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/include -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/libstdc++/libsupc++ -I/usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libsupc++/../libstdc++ -I. -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -std=gnu99 -fstack-protector -c /usr/subversion-src/gnu/lib/libsupc++/../../../contrib/gcclibs/libiberty/cp-demangle.c building static supc++ library ranlib libsupc++.a ===> gnu/lib/libobjc (all) gcc -O2 -pipe -march=native -DHAVE_GTHR_DEFAULT -DIN_GCC -DIN_TARGET_LIBS -I. -I/usr/subversion-src/gnu/lib/libobjc/../../usr.bin/cc/cc_tools -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/libobjc/objc -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/libobjc -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/gcc/config -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/gcc -I/usr/subversion-src/gnu/lib/libobjc/../../../contrib/gcclibs/include -fexceptions -frandom-seed=RepeatabilityConsideredGood -DNDEBUG -g -std=gnu99 -fstack-protector -c /usr/subversion-src/gnu/lib/libobjc/../../../contrib/libobjc/archive.c *** Signal 11 Stop in /usr/subversion-src/gnu/lib/libobjc. *** Error code 1 Stop in /usr/subversion-src/gnu/lib. *** Error code 1 Stop in /usr/subversion-src. *** Error code 1 Stop in /usr/subversion-src. *** Error code 1 Stop in /usr/subversion-src. *** Error code 1 Stop in /usr/subversion-src. CODE i've finally figured out that the following line in make.conf is causing the problem: CPUTYPE ?= native if i remove it or change it to CPUTYPE ?= nocona everything works fine. if i'm using gcc as compiler, having CPUTYPE ?= native in my make.conf causes no harm. this is on amd64 and a very recent HEAD snapshot. can somebody verify this issue? cheers. alex -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang and -mfpmath=387 on ARCH=amd64
On Sat Dec 18 10, Alexander Best wrote: > [snip] > > maybe sorting the options just like in the i386 section is a better to have > more consistency. it seems this issue is one of the cases where everybody is too afraid to make the actual commit. :( cheers. alex [snip] -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang and -mfpmath=387 on ARCH=amd64
On Sat Dec 18 10, Alexander Best wrote:
> On Fri Dec 17 10, Dimitry Andric wrote:
> > On 2010-12-14 21:40, Alexander Best wrote:
> > >On Sun Dec 12 10, Dimitry Andric wrote:
> > ...
> > >>I have compiled two GENERIC kernels on amd64 with and without the
> > >>-mfpmath=386 option, and those resulted in exactly the same binaries
> > >>(apart from the compilation timestamp).
> > >>
> > >>So I think the whole -mfpmath=387 option is nonsensical anyway. The
> > >>comment just above those CFLAGS in sys/conf/kern.mk says:
> > >
> > >i think for i386 the case is clear: -mfpmath=387 *is* the default. for
> > >amd64 it
> > >depends.
> >
> > On amd64 -mfpmath=sse is the default. However, floating point is not
> > allowed at all in the kernel, and even if it were used, it would result
> > in a compile error, because -mno-sse is also used. You can verify this
> > by compiling a small program on amd64 that uses floating point, and
> > passing the -mno-sse option.
> >
> >
> > >if we can be sure that the -mno-sse[2-3]? options will set
> > >-mfpmath=387 there is no need to set -mfpmath=387. it seems from your
> > >tests and
> > >also from a logical sense of point that this is the case. however the gcc
> > >manual doesn't really state this matter. so it could in fact be possible
> > >that
> > >even with -mno-sse[2-3]? set, -mfpmath=sse remains the default setting for
> > >amd64.
> >
> > Yes it is the default; but as I said, it makes no difference. Neither
> > i387 nor sse hardware FP instructions should ever be generated in the
> > kernel.
>
> so this patch should keep clang from complaing while compiling the kernel and
> in addition to that won't have any impact on gcc.
maybe sorting the options just like in the i386 section is a better to have
more consistency.
cheers.
alex
>
> cheers.
> alex
>
> >
> > It would be nice if gcc/clang had an option "-mdie-on-any-fp", but they
> > don't, unfortunately. :)
>
> --
> a13x
> diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk
> index 4d8636c..e277b74 100644
> --- a/sys/conf/kern.mk
> +++ b/sys/conf/kern.mk
> @@ -66,7 +66,7 @@ INLINE_LIMIT?= 15000
> #
> .if ${MACHINE_CPUARCH} == "amd64"
> CFLAGS+= -mcmodel=kernel -mno-red-zone \
> - -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow \
> + -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow \
> -msoft-float -fno-asynchronous-unwind-tables
> INLINE_LIMIT?= 8000
> .endif
--
a13x
diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk
index 4d8636c..baed1b2 100644
--- a/sys/conf/kern.mk
+++ b/sys/conf/kern.mk
@@ -66,7 +66,7 @@ INLINE_LIMIT?=15000
#
.if ${MACHINE_CPUARCH} == "amd64"
CFLAGS+= -mcmodel=kernel -mno-red-zone \
- -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow \
+ -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 \
-msoft-float -fno-asynchronous-unwind-tables
INLINE_LIMIT?= 8000
.endif
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang and -mfpmath=387 on ARCH=amd64
On Fri Dec 17 10, Dimitry Andric wrote:
> On 2010-12-14 21:40, Alexander Best wrote:
> >On Sun Dec 12 10, Dimitry Andric wrote:
> ...
> >>I have compiled two GENERIC kernels on amd64 with and without the
> >>-mfpmath=386 option, and those resulted in exactly the same binaries
> >>(apart from the compilation timestamp).
> >>
> >>So I think the whole -mfpmath=387 option is nonsensical anyway. The
> >>comment just above those CFLAGS in sys/conf/kern.mk says:
> >
> >i think for i386 the case is clear: -mfpmath=387 *is* the default. for
> >amd64 it
> >depends.
>
> On amd64 -mfpmath=sse is the default. However, floating point is not
> allowed at all in the kernel, and even if it were used, it would result
> in a compile error, because -mno-sse is also used. You can verify this
> by compiling a small program on amd64 that uses floating point, and
> passing the -mno-sse option.
>
>
> >if we can be sure that the -mno-sse[2-3]? options will set
> >-mfpmath=387 there is no need to set -mfpmath=387. it seems from your
> >tests and
> >also from a logical sense of point that this is the case. however the gcc
> >manual doesn't really state this matter. so it could in fact be possible
> >that
> >even with -mno-sse[2-3]? set, -mfpmath=sse remains the default setting for
> >amd64.
>
> Yes it is the default; but as I said, it makes no difference. Neither
> i387 nor sse hardware FP instructions should ever be generated in the
> kernel.
so this patch should keep clang from complaing while compiling the kernel and
in addition to that won't have any impact on gcc.
cheers.
alex
>
> It would be nice if gcc/clang had an option "-mdie-on-any-fp", but they
> don't, unfortunately. :)
--
a13x
diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk
index 4d8636c..e277b74 100644
--- a/sys/conf/kern.mk
+++ b/sys/conf/kern.mk
@@ -66,7 +66,7 @@ INLINE_LIMIT?=15000
#
.if ${MACHINE_CPUARCH} == "amd64"
CFLAGS+= -mcmodel=kernel -mno-red-zone \
- -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow \
+ -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow \
-msoft-float -fno-asynchronous-unwind-tables
INLINE_LIMIT?= 8000
.endif
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang and -mfpmath=387 on ARCH=amd64
On Tue Dec 14 10, Alexander Best wrote: > On Sun Dec 12 10, Dimitry Andric wrote: > > On 2010-12-11 12:47, Alexander Best wrote: > > >clang doesn't seem to make use of -mfpmath=387 on ARCH=amd64 and complains > > >about it (e.g. during TARGET=buildkernel). > > > > > >any thoughts about the attached patch? > > > > I have compiled two GENERIC kernels on amd64 with and without the > > -mfpmath=386 option, and those resulted in exactly the same binaries > > (apart from the compilation timestamp). > > > > So I think the whole -mfpmath=387 option is nonsensical anyway. The > > comment just above those CFLAGS in sys/conf/kern.mk says: > > i think for i386 the case is clear: -mfpmath=387 *is* the default. for amd64 > it > depends. if we can be sure that the -mno-sse[2-3]? options will set > -mfpmath=387 there is no need to set -mfpmath=387. it seems from your tests > and > also from a logical sense of point that this is the case. however the gcc > manual doesn't really state this matter. so it could in fact be possible that > even with -mno-sse[2-3]? set, -mfpmath=sse remains the default setting for > amd64. any update on this issue? anybody voting against removing -mfpmath=387 entirely? cheers. alex > > cheers. > alex > > > > > # For AMD64, we explicitly prohibit the use of FPU, SSE and other SIMD > > # operations inside the kernel itself. These operations are exclusively > > # reserved for user applications. > > > > However, according to the gcc manual, the -mfpmath option does *not* > > disable FPU instructions at all, but simply switches the default (for > > amd64) from SSE to 387 instructions: > > > > http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/i386-and-x86_002d64-Options.html#index-march-1052 > > > > Since -mno-sse is already specified, this flag may actually be worse > > than not specifying it at all! :) > > > > I suggest to just remove the entire -mfpmath=387 option unconditionally. > > -- > a13x -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: clang and -mfpmath=387 on ARCH=amd64
On Sun Dec 12 10, Dimitry Andric wrote: > On 2010-12-11 12:47, Alexander Best wrote: > >clang doesn't seem to make use of -mfpmath=387 on ARCH=amd64 and complains > >about it (e.g. during TARGET=buildkernel). > > > >any thoughts about the attached patch? > > I have compiled two GENERIC kernels on amd64 with and without the > -mfpmath=386 option, and those resulted in exactly the same binaries > (apart from the compilation timestamp). > > So I think the whole -mfpmath=387 option is nonsensical anyway. The > comment just above those CFLAGS in sys/conf/kern.mk says: i think for i386 the case is clear: -mfpmath=387 *is* the default. for amd64 it depends. if we can be sure that the -mno-sse[2-3]? options will set -mfpmath=387 there is no need to set -mfpmath=387. it seems from your tests and also from a logical sense of point that this is the case. however the gcc manual doesn't really state this matter. so it could in fact be possible that even with -mno-sse[2-3]? set, -mfpmath=sse remains the default setting for amd64. cheers. alex > > # For AMD64, we explicitly prohibit the use of FPU, SSE and other SIMD > # operations inside the kernel itself. These operations are exclusively > # reserved for user applications. > > However, according to the gcc manual, the -mfpmath option does *not* > disable FPU instructions at all, but simply switches the default (for > amd64) from SSE to 387 instructions: > > http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/i386-and-x86_002d64-Options.html#index-march-1052 > > Since -mno-sse is already specified, this flag may actually be worse > than not specifying it at all! :) > > I suggest to just remove the entire -mfpmath=387 option unconditionally. -- a13x ___ freebsd-toolchain@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
clang and -mfpmath=387 on ARCH=amd64
hi there,
clang doesn't seem to make use of -mfpmath=387 on ARCH=amd64 and complains
about it (e.g. during TARGET=buildkernel).
any thoughts about the attached patch?
cheers.
alex
--
a13x
diff --git a/sys/conf/kern.mk b/sys/conf/kern.mk
index 4d8636c..d5077ea 100644
--- a/sys/conf/kern.mk
+++ b/sys/conf/kern.mk
@@ -65,8 +65,11 @@ INLINE_LIMIT?= 15000
# reserved for user applications.
#
.if ${MACHINE_CPUARCH} == "amd64"
+.if ${CC:T:Mclang} != "clang"
+CFLAGS+= -mfpmath=387
+.endif
CFLAGS+= -mcmodel=kernel -mno-red-zone \
- -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow \
+ -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow \
-msoft-float -fno-asynchronous-unwind-tables
INLINE_LIMIT?= 8000
.endif
___
freebsd-toolchain@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain
To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
