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
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
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 bsd.kmod.mk
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 bsd.kmod.mk
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
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 arun...@freebsd.org 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: '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 arun...@freebsd.org 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: -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: 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
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, 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 - /dev/null
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 stdin
# 1 built-in
# 1 command-line
# 1 stdin
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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
[1.00]
Features2=0xe39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM
[1.00] AMD Features=0x20100800SYSCALL,NX,LM
[1.00] AMD Features2=0x1LAHF
[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 09:23:52PM +, 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 - /dev/null), 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: 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 d...@freebsd.org 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, 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 e...@80386.nl 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, 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
[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 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: 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 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_LPR=true WITHOUT_NDIS=true WITHOUT_NETCAT=true WITHOUT_NIS=true WITHOUT_NLS=true WITHOUT_NLS_CATALOGS=true WITHOUT_NS_CACHING=true WITHOUT_PAM_SUPPORT=true WITHOUT_PF=true WITHOUT_PMC=true WITHOUT_PPP=true WITHOUT_PROFILE=true# for using gprof(1) WITHOUT_QUOTAS=true WITHOUT_RCMDS=true
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:
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: SAMSUNG SP2504C VT100-50 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: SAMSUNG HD103SJ 1AJ10001 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: HL-DT-ST DVDRAM GH24NS50 XP02 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] 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
${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: 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/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:114:20: note: previous definition is here
typedef __va_list __gnuc_va_list; /* compatibility w/GNU headers*/
^
In file included from /usr/subversion-src/usr.bin/make
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: 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.eof 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 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 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=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF 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 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 copypasted 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 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 copypasted 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: 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
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
