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
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
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
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
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
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
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
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
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
-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
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
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
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
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
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
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
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
#
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
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
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
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
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
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
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
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
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
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
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
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
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
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
31 matches
Mail list logo
