Please test the binutils-2.17 project branch

[Dimitry Andric]

Hi all,

As you may know, I am working on an update of our in-tree binutils to
2.17.50, the last version that was still under version 2 of the GPL.

I have put this in a project branch, which you can checkout from:

  svn://svn.freebsd.org/base/projects/binutils-2.17

Please try building world and kernel from this tree, and if the machine
in question is expendable (!) installing them.  If you see any clearly
binutils-related issues, you can reply to this list, or mail me directly
if you prefer.

Currently, a make universe of the binutils-2.17 project tree builds to
completion for the following arches:

- amd64 run-time tested by me
- i386  run-time tested by me
- mips  needs run-time testing
- pc98  needs run-time testing
- powerpc   run-time tested by nwhitehorn
- sparc64   needs run-time testing
- sun4v needs run-time testing

The following arches still have building problems:

- arm

  There is some weird issue that causes the cross-tools ld to segfault
  during buildworld, when linking a binary blob into a .o file:

  ===> usr.sbin/uathload (all)
  cc -O -pipe  -std=gnu99 -Wsystem-headers -Werror -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 
/home/dim/src/freebsd/binutils-2.17/usr.sbin/uathload/uathload.c
  gzip -cn /home/dim/src/freebsd/binutils-2.17/usr.sbin/uathload/uathload.8 > 
uathload.8.gz
  ld -b binary -d -warn-common -r -d -o ar5523.o ar5523.bin
  Segmentation fault (core dumped)

  I am investigating this now, any hints welcome. :)

- ia64

  Something in sys/boot/ia64/efi/ldscript.ia64 makes ld complain about
  mixing ordered and unordered sections:

  ===> sys/boot/ia64/efi (all)
  ...
  /usr/obj/ia64.ia64/home/dim/src/freebsd/binutils-2.17/tmp/usr/bin/ld: .data 
has both ordered [`.IA_64.unwind' in efimd.o] and unordered 
[`.IA_64.unwind_info' in 
/usr/obj/ia64.ia64/home/dim/src/freebsd/binutils-2.17/tmp/usr/lib/libstand.a(strlen.o)]
 sections
  /usr/obj/ia64.ia64/home/dim/src/freebsd/binutils-2.17/tmp/usr/bin/ld: final 
link failed: Bad value

  I am not sure if this is a bug in binutils, or something in the linker
  script.  My ia64 knowledge is extremely limited, though...

2 bad arches against 7 good ones isn't a bad score, but I would like to
make  sure all of them at least build without any issues, before even
thinking of merging this into head.  So please help out if you can.

Last but not least, be sure to build some ports when the new binutils
are installed in the base system.  There are always some nasty ones out
there that test for specific versions of GNU tools, and die when their
expectations are not met. :)
___
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: Please test the binutils-2.17 project branch

[Dimitry Andric]

On 2010-11-02 19:47, Dimitry Andric wrote:

The following arches still have building problems:

- arm

There is some weird issue that causes the cross-tools ld to segfault
during buildworld, when linking a binary blob into a .o file:


This particular segfault was a binutils bug, PR7093, and should now be
fixed by r214751.

I can presently do a full buildworld for arm, and I also tried building
a few kernels.  Run-time testing would be appreciated.
___
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: Please test the binutils-2.17 project branch

[Dimitry Andric]

On 2010-11-02 19:47, Dimitry Andric wrote:

- ia64

Something in sys/boot/ia64/efi/ldscript.ia64 makes ld complain about
mixing ordered and unordered sections:

===>  sys/boot/ia64/efi (all)
...
/usr/obj/ia64.ia64/home/dim/src/freebsd/binutils-2.17/tmp/usr/bin/ld: .data 
has both ordered [`.IA_64.unwind' in efimd.o] and unordered 
[`.IA_64.unwind_info' in 
/usr/obj/ia64.ia64/home/dim/src/freebsd/binutils-2.17/tmp/usr/lib/libstand.a(strlen.o)]
 sections
/usr/obj/ia64.ia64/home/dim/src/freebsd/binutils-2.17/tmp/usr/bin/ld: final 
link failed: Bad value


I have committed r214850, which makes this, and sys/boot/ia64/ski link,
but I need someone to test this on real hardware, at run-time.  Does it
still boot with this loader.efi?  :)
___
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 -frandom-seed

[Dimitry Andric]

On 2010-11-14 23:29, Erik Cederstrand wrote:

I noticed that two consecutive builds of (GCC-built) Clang don't produce 
identical binaries. This is true for clang, clang++ and tblgen. I asked on the 
llvm-dev list yesterday, and it turns out it's because GCC uses a random seed 
on some symbols. Apparently, this can be controlled with the -frandom-seed 
flag. I haven't tested if this is also the case for Clang-built Clang.

I'm not sure I understand the exact implications, but I'm wondering if we could 
add the flag to the build scripts in FreeBSD in a way that both satisfies the 
randomness criteria and makes builds deterministic?


Hmm, it seems this is only used for C++ compilations, not for plain C.
The gcc manual says:

-frandom-seed=string
This option provides a seed that GCC uses when it would otherwise
use random numbers. It is used to generate certain symbol names
that have to be different in every compiled file.  It is also used
to place unique stamps in coverage data files and the object files
that produce them. You can use the -frandom-seed option to produce
reproducibly identical object files.

The string should be different for every file you compile.

The stanza "have to be different in every compiled file" is what worries
me.  There is probably a good reason that gcc needs to be able to emit
unique function names. In contrib/gcc/tree.c, there's this piece of
code:

/* Generate a name for a function unique to this translation unit.
   TYPE is some string to identify the purpose of this function to the
   linker or collect2.  */

tree
get_file_function_name_long (const char *type)
{
...
  /* We don't have anything that we know to be unique to this translation
 unit, so use what we do have and throw in some randomness.  */
...
  sprintf (q + len, "_%08X_%08X", crc32_string (0, name),
   crc32_string (0, flag_random_seed));

So this is all on purpose, and I think it would be a bad idea to disable
it, unless we fully understand the consequences.

On the other hand, the requirement "The string should be different for
every file you compile", could possibly be fulfilled.  Maybe by using
the filename, relative to $SRCDIR, that is being compiled as "seed"?

This would be unique for each compiled file, but still give the same
result for each build, and also be independent of the particular machine
you are building on.
___
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 -frandom-seed

[Dimitry Andric]

On 2010-11-15 11:10, Erik Cederstrand wrote:

I was thinking of something along the same lines. I think we agree
that it only needs to be random across files, not across builds.
Someone on llvm-dev also suggested using the path (either full or
relative to src/) as a seed.


The path should relative, to guarantee the same result for every
location you can put the source.



Where in the build scripts would I need to add this flag? Something like:

CXXFLAGS += -frandom-seed=${.TARGET}


Rather use:

CXXFLAGS+=-frandom-seed=${.IMPSRC:S/^${.CURDIR}\///}

which is rather contorted, but I see no other way to generate a relative
path. :)

Also, this generates an empty '-frandom-seed=' option for every command
that uses CXXFLAGS but isn't a compilation at all, such as most linking
commands.  It is probably not harmful, though.
___
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 -frandom-seed

[Dimitry Andric]

On 2010-11-19 16:51, Erik Cederstrand wrote:

Poking around, I decided to add this patch:

# svn diff lib/clang/clang.build.mk
Index: lib/clang/clang.build.mk
===
--- lib/clang/clang.build.mk(revision 215422)
+++ lib/clang/clang.build.mk(working copy)
@@ -28,6 +28,13 @@
  CXXFLAGS+=-fno-rtti
  .endif

+.ifdef WITH_DETERMINISTIC
+CXXFLAGS+=-frandom-seed=0
+.endif


This will probably not work as expected.  The -frandom-seed option must
be different for each source file.



and added "WITH_DETERMINISTIC=true" to /etc/src.conf. The "random-seed=0" 
should ensure that the same random elements are generated every time.

I then ran two buildworlds with the same MAKEOBJDIRPREFIX but two different 
DESTDIRs, and compared the two clang binaries. The random-seed option does show 
up un the log, so it's getting picked up, but apparently it was not enough, as 
the random elements are still different.

Any hints on where in the build infrastructure I should add the flag, or what 
to grep for in the buildworld log to find out what's wrong?

Also, how can I compile just clang? I tried "cd src/usr.bin/clang; make" but it 
dies violently:

/usr/home/erik/freebsd/head/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.h:
 At global scope:
/usr/home/erik/freebsd/head/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.h:999:
 error: expected ',' or '...' before '&' token
/usr/home/erik/freebsd/head/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.h:1000:
 error: ISO C++ forbids declaration of 'LangOptions' with no type
/usr/home/erik/freebsd/head/src/usr.bin/clang/clang/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.h:1019:
 error: expected declaration before '}' token


I don't see this error if I repeat your commands, but in any case you
must first build in lib/clang, before you can build in usr.bin/clang,
e.g.:

make -C $SRCDIR/lib/clang && make -C $SRCDIR/usr.bin/clang
___
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 -frandom-seed

[Dimitry Andric]

On 2010-11-22 15:05, Erik Cederstrand wrote:

.ifdef WITH_DETERMINISTIC
CXXFLAGS+=-frandom-seed=\"${.IMPSRC:S/^${.CURDIR}\///}\"
.endif

to lib/clang/clang.build.mk

and "WITH_DETERMINISTIC=true" to src.conf, but apparently the flag isn't being 
propagated to clang.build.mk. However it is being picked up if I pass it on the 
command-line:

make WITH_DETERMINISTIC=true buildworld

Why isn't the flag available in clang.build.mk?


Well, src.conf is only picked up if you .include , or
another bsd.*.mk file that includes bsd.own.mk in turn.

So normally, you would have a Makefile in e.g. usr.bin/clang/clang,
which includes bsd.own.mk, and then includes clang.build.mk.  Only in
that case the variables from src.conf are available.

In contrast, make.conf is read from sys.mk, so its contents are always
available.  Same if you put variables on the command line; those even
override *any* assignment in the Makefiles themselves...
___
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

[Dimitry Andric]

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:

# 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.
___
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: -integrated-as status?

[Dimitry Andric]

On 2010-12-17 15:10, Erik Cederstrand wrote:

Den 17/12/2010 kl. 15.02 skrev Roman Divacky:

On Fri, Dec 17, 2010 at 02:58:34PM +0100, Erik Cederstrand wrote:

It is my understanding that -integrated-as is supposed to work for ELF on 
FreeBSD now. Is anybody working on supporting this flag for buildworld/kernel?

-integrated-as works quite well for compiler produces .s files, it
has some problems with human written .s/.S files.
bottom line - it cant compile kernel right now but we are working on it

Cool, thanks!


Note integrated-as is now the default for clang ToT (at least for ELF on
i386/amd64) so when we import the next snapshot, we will get it
automatically.
___
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

[Dimitry Andric]

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.

It would be nice if gcc/clang had an option "-mdie-on-any-fp", but they
don't, unfortunately. :)
___
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

[Dimitry Andric]

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. :)

___
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

[Dimitry Andric]

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++.
___
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

[Dimitry Andric]

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

It would be better if the port already did this, though...
___
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)

[Dimitry Andric]

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.

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;
___
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

[Dimitry Andric]

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.
___
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

[Dimitry Andric]

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.
___
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

[Dimitry Andric]

On 2011-05-31 17:26, Alexander Best wrote:
...

so how about the following patch?


Could you please try to not mix spacing and style changes with
functional changes in this patch?  It makes it more difficult to review.
___
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: llvm-ia64 is off the ground...

[Dimitry Andric]

On 2011-06-10 17:38, Marcel Moolenaar wrote:
...

Unfortunately, the FreeBSD build doesn't give me goodies like
llc or bugpoint so there may be value in adding that to the
FreeBSD build as optional or developer-only build targets...


These programs are of little use for normal users, or even most
developers, except for people who hack on clang/llvm itself.

Also, to install them without too much overhead, we would have to start
installing llvm and clang's shared libraries, which adds a lot of
complexity.  Currently, we just link everything into one clang
executable.  (There's also a tblgen executable, but it is debatable
whether even that belongs in the base system, since it is only used for
building llvm and clang.)

That said, it is great you are working on this, but do you have any
particular reason for not just using a checkout from the upstream llvm
and clang repositories instead?  If you work inside the FreeBSD tree,
you have a version that is slightly behind the current version, and for
hacking on a new backend, it is usually better to get hints and advice
from the llvm people themselves...
___
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: Adding additional llvm/clang goodies

[Dimitry Andric]

On 2011-06-17 08:48, Roman Divacky wrote:

* llvm-rtdyld
* macho-dump


these two look extra useful on FreeBSD :-P


Well, I just took the whole list of utilities under llvm/tools that were
built during a normal (./configure && gmake) build of clang. :)

But yes, if any of these tools will be guaranteed to have no use at all,
ever, on FreeBSD, then it is maybe better to not add them at all?

They're quite cheap to build though.
___
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: Freebsd-7.4 + std gcc 4.2.1 fails to honour -march=i586

[Dimitry Andric]

On 2011-07-21 14:17, Julian H. Stacey wrote:

Summary:
   I found a problem with CFLAGS += -march=i586 on an i686 linking
   a crt.o for an i686, then not running on an i586,


IMHO this is a bit of a PEBKAC issue.  If you change CPUFLAGS to target
a specific CPU, you should really rebuild all of world with it, not just
a single program.  In fact, you should rebuild all your ports too.



I suggested
   maybe -march could be extended to also select seperate lib sub
   directories to at least trigger a link failure, rather than a silent
   apparent good compile of a bad binary.


I think this would add a whole lot of complexity for very little gain,
and still not save you from potential problems.  You would really have
to use the same approach for all system libraries, otherwise you might
link in something from e.g. libc or libcrypto that was optimized for the
wrong CPU.  And I'm not even mentioning objects and/or libraries from
ports... :)

The compiler cannot automagically determine whether any object or
library file you link into your program is fit to run on the CPU you are
targeting, unless you would add information specifying the CPU type (and
other particulars) to the object files themselves.  In the end, it is up
to you to make sure you do not mix "incompatible" object code.

Having said all this, if you are worried particularly about the crt*.o
files, then we could simply always build those with 'lowest common
denominator' flags, like we do with e.g. the dynamic linker.  I doubt
very much that the startup code gains any performance by optimizing for
higher CPU types.
___
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: [help] rebuild libc failed

[Dimitry Andric]

On 2011-08-04 10:38, majia gm wrote:

I'm building the libc code which derived from a current trunk
mirror/freebsd/head under PCBSD 8.2 which contains FreeBSD 8.2
release.
I'm trying to test the modified libc by using LD_LIBRARY_PATH. But
failed to build it.
I change the current direcotry into head/lib/libc and run make.


You cannot always do this, especially not when going from 8.2 to head,
because you need to build a toolchain first, which includes updated
headers and other components.

It's probably best to just run "make buildworld", which will take care
of everything.  Otherwise, run "make toolchain" first, followed by "make
buildenv".  In that build environment, you can just change to the
lib/libc directory and run make.

NOTE: Do *not* install the updated libc if you are running an old
kernel, or you will most likely hose your system.
___
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

[Dimitry Andric]

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?
___
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

[Dimitry Andric]

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
:

.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
___
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

[Dimitry Andric]

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...
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

[Dimitry Andric]

On 2011-08-23 11:23, Alexander Best wrote:
...

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?


I hope so, but it needs to be reviewed by one or more senior build
gurus, before it makes a chance (if any) to get into 9.0-R.

It's really just a band-aid now.  Obviously, the whole way Makefile.inc1
sets up CC to run the build32 stage should be overhauled, and as Warner
said, we really need a (SYSTEM|WORLD|PORTS)_COMPILER global switch
(instead of manually setting CC), but that kind of restructuring must be
done after the tree is unfrozen, not now.
___
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] rtld-elf/rtld.c and stack traces in gdb(1)

[Dimitry Andric]

On 2011-08-21 11:08, Test Rat wrote:

I often get corrupted traces with clang world, the cause seems to be in rtld.

...

   (gdb) bt
   #0  0x0008009455ac in ?? ()
   #1  0x000800944fa7 in ?? ()


After some digging, this turned out to be caused by the empty function
r_debug_state() in libexec/rtld-elf/rtld.c.  This function is just a
necessary hook for gdb, but since it is completely empty, calls to it in
the same compilation unit simply don't generate any code, even if the
function is marked as __noinline.

The attached patch fixes this, by marking the function __noinline, and
inserting an empty asm statement, that pretends to clobber memory.  It
generates no extra code, and forces clang to emit calls to r_debug_state
throughout rtld.c.  It looks rather hackish, though.

An alternative solution would be to move the r_debug_state() function to
another .c file, which should work OK, until we eventually start using
link time optimization... :)



And compiling rtld with clang + -O0 makes it crash.


This is caused by yet another interesting problem, which is in the
_rtld() function in rtld.c.  It is run at the very beginning of rtld,
when relocations have not yet been processed.  This initial code must be
very careful to *not* use any relocated symbols, or problems will arise.

The early initialization goes like:

...

/* Initialize and relocate ourselves. */
assert(aux_info[AT_BASE] != NULL);
init_rtld((caddr_t) aux_info[AT_BASE]->a_un.a_ptr, aux_info);

__progname = obj_rtld.path;
argv0 = argv[0] != NULL ? argv[0] : "(null)";
environ = env;

The init_rtld() function takes care of the initial relocations, after
which 'global' symbols like __progname and environ can be used.

However, at -O0, clang still reorders the retrieval of the __progname
offset to just *before* the init_rtld() call, and assigns it afterwards:

...
.LBB0_16:   # %cond.end
movq__progname@GOTPCREL(%rip), %rax <-- gets the offset here
leaq-224(%rbp), %rsi
.loc1 329 5 # /usr/src/libexec/rtld-elf/rtld.c:329:5
movq-168(%rbp), %rcx
movq8(%rcx), %rdi
movq%rax, -1504(%rbp)   # 8-byte Spill  <-- saves offset on 
stack
callq   init_rtld
.loc1 331 5 # /usr/src/libexec/rtld-elf/rtld.c:331:5
movqobj_rtld+24(%rip), %rax
movq-1504(%rbp), %rcx   # 8-byte Reload <-- loads offset from 
stack
movq%rax, (%rcx)<-- stores value in 
__progname

It's not clear to me why clang does this reordering even when
optimization is off, but it is normally legal, and quite usual.
However, in case of this early initialization, it is fatal, as
__progname@GOTPCREL(%rip) will still be junk, or zero...

With optimization, such reorderings are even more likely, but for some
reason, we have always been lucky that it turned out OK.  A possible
solution would be to move the code after the init_rtld() call to another
function, and call that, but this could also be defeated again by
inlining. :(
Index: libexec/rtld-elf/rtld.c
===
--- libexec/rtld-elf/rtld.c (revision 225105)
+++ libexec/rtld-elf/rtld.c (working copy)
@@ -143,7 +143,7 @@ static void ld_utrace_log(int, void *, void *, siz
 static void rtld_fill_dl_phdr_info(const Obj_Entry *obj,
 struct dl_phdr_info *phdr_info);
 
-void r_debug_state(struct r_debug *, struct link_map *);
+void r_debug_state(struct r_debug *, struct link_map *) __noinline;
 
 /*
  * Data declarations.
@@ -2780,6 +2780,14 @@ linkmap_delete(Obj_Entry *obj)
 void
 r_debug_state(struct r_debug* rd, struct link_map *m)
 {
+/*
+ * The following is a hack to force the compiler to emit calls to
+ * this function, even when optimizing.  If the function is empty,
+ * the compiler is not obliged to emit any code for calls to it,
+ * even when marked __noinline.  However, gdb depends on those
+ * calls being made.
+ */
+__asm __volatile("" : : : "memory");
 }
 
 /*
___
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

[Dimitry Andric]

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.
___
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

[Dimitry Andric]

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

[Dimitry Andric]

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.

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.

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.
___
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

[Dimitry Andric]

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.

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.
___
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

[Dimitry Andric]

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.

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"

Re: make cleanworld

[Dimitry Andric]

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.
___
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

[Dimitry Andric]

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. :)
___
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

[Dimitry Andric]

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/}
___
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: svn commit: r228435 - in head/libexec/rtld-elf: . amd64 arm i386 ia64 mips powerpc powerpc64 sparc64

[Dimitry Andric]

On 2011-12-14 13:24, Gerald Pfeifer wrote:
> On Mon, 12 Dec 2011, Kostik Belousov wrote:
>> Does anybody on toolchain@ know how to submit the gas change to
>> maintainers for inclusion into mainline, or better, can submit it
>> himself ? I assume that no copyright assignment is required for this
>> trivial flip of settings.
> 
> I would just send to binut...@sourceware.org.  And indeed, the
> patch is sufficiently small not to require copyright assignment
> or disclaimer or the like from what I can tell.

See the thread starting here:
http://cygwin.com/ml/binutils/2011-12/msg00144.html
___
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: buildworld broken with _WITHOUT_SRCCONF=

[Dimitry Andric]

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

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"

Re: [rfc] removing/conditionalising WERROR= in Makefiles

[Dimitry Andric]

On 2011-12-26 11:10, Alexander Best wrote:

that's why i'd like to propose the following patch. i ran a full tinderbox run
against r228878 and it suceeded.


Did you also try this with clang?  For example the xfs module alone gets
a whole slew of warnings, which would be fatal if WERROR= was removed:

  sys/gnu/fs/xfs/xfs_dir2_block.c:1149:17: warning: array index of '1' indexes 
past the end of an array (that contains 1 element) [-Warray-bounds]
  dep->name[0] = dep->name[1] = '.';
 ^ ~
  sys/gnu/fs/xfs/xfs_dir2_data.h:90:2: note: array 'name' declared here
  __uint8_t   name[1];/* name bytes, no null */
  ^
  1 warning generated.

  sys/gnu/fs/xfs/xfs_dir2_sf.c:117:27: warning: array index of '1' indexes past 
the end of an array (that contains 1 element) [-Warray-bounds]
  dep->name[0] == '.' && dep->name[1] == '.';
 ^ ~
  sys/gnu/fs/xfs/xfs_dir2_data.h:90:2: note: array 'name' declared here
  __uint8_t   name[1];/* name bytes, no null */
  ^
  sys/gnu/fs/xfs/xfs_dir2_sf.c:237:28: warning: array index of '1' indexes past 
the end of an array (that contains 1 element) [-Warray-bounds]
   dep->name[0] == '.' && dep->name[1] == '.')
  ^ ~
  sys/gnu/fs/xfs/xfs_dir2_data.h:90:2: note: array 'name' declared here
  __uint8_t   name[1];/* name bytes, no null */
  ^
  2 warnings generated.

  sys/gnu/fs/xfs/xfs_vfsops.c:1958:19: warning: format string is not a string 
literal (potentially insecure) [-Wformat-security]
  sbuf_printf(m, xfs_infop->str);
 ^~
  1 warning generated.

  sys/gnu/fs/xfs/FreeBSD/xfs_super.c:257:9: warning: format string is not a 
string literal (potentially insecure) [-Wformat-security]
  printf(message);
 ^~~
  1 warning generated.

  sys/gnu/fs/xfs/FreeBSD/xfs_stats.c:68:32: warning: format string is not a 
string literal (potentially insecure) [-Wformat-security]
  len += sprintf(buffer + len, xstats[i].desc);
   ^~
  sys/gnu/fs/xfs/FreeBSD/xfs_stats.c:99:33: warning: if statement has empty 
body [-Wempty-body]
  if (&xfs_read_xfsstats != NULL);
 ^
  2 warnings generated.
  sys/gnu/fs/xfs/FreeBSD/xfs_ioctl.c:1252:10: warning: explicitly assigning a 
variable of type 'int' to itself [-Wself-assign]
  error = error;
  ~ ^ ~
  sys/gnu/fs/xfs/FreeBSD/xfs_ioctl.c:1290:9: warning: explicitly assigning a 
variable of type 'int' to itself [-Wself-assign]
  error = error;
  ~ ^ ~
  sys/gnu/fs/xfs/FreeBSD/xfs_ioctl.c:1299:10: warning: explicitly assigning a 
variable of type 'int' to itself [-Wself-assign]
  error = error;
  ~ ^ ~
  sys/gnu/fs/xfs/FreeBSD/xfs_ioctl.c:1350:9: warning: explicitly assigning a 
variable of type 'int' to itself [-Wself-assign]
  error = error;
  ~ ^ ~
  4 warnings generated.

Most of the warnings should probably be fixed, but as this is mainly
contrib code, and GPL to boot, it makes not much sense to do so.
___
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] removing/conditionalising WERROR= in Makefiles

[Dimitry Andric]

On 2011-12-30 14:28, David Chisnall wrote:

On 30 Dec 2011, at 13:06, Dimitry Andric wrote:


  sys/gnu/fs/xfs/xfs_dir2_block.c:1149:17: warning: array index of '1' indexes 
past the end of an array (that contains 1 element) [-Warray-bounds]


I recall some discussion of this warning on the clang list a few months ago, 
and I believe that it should now only appear if you are compiling in a C99 or 
C11 dialect mode (the rationale is that any variable-length structures in C99 
should be using a zero-sized array as the final element, while C89 lacked any 
ability to do this).


Yes, that is perfectly fine, but the xfs code defines the struct in
question as follows:

/*
 * Active entry in a data block.  Aligned to 8 bytes.
 * Tag appears as the last 2 bytes.
 */
typedef struct xfs_dir2_data_entry {
xfs_ino_t   inumber;/* inode number */
__uint8_t   namelen;/* name length */
__uint8_t   name[1];/* name bytes, no null */
/* variable offset */
xfs_dir2_data_off_t tag;/* starting offset of us */
} xfs_dir2_data_entry_t;

E.g there *is* an overrun, but maybe it was really supposed to be like
that.  Meanwhile, upstream has apparently caught on:

  http://oss.sgi.com/archives/xfs/2011-07/msg00024.html
___
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

[Dimitry Andric]

On 2012-02-26 23:38, Warner Losh wrote:
> On Feb 26, 2012, at 2:37 PM, 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.
> 
> What doesn't work?  Or rather, how does it work now?

Setting CC/CXX/CPP and such in src.conf doesn't work, at least not for
all Makefiles in world.  There are still many of them that don't do the
right thing, picking up CC values from sys.mk and/or make.conf instead.

The trickiest one is Makefile.inc1, which does some special magic, and
isn't really a normal BSD Makefile anyway. :)

I've got a git branch with some experiments to have all the compiler
settings read from src.conf instead of make.conf, but I didn't finish it
before some other work took precedence...
___
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

[Dimitry Andric]

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.
___
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] Un-staticise the toolchain

[Dimitry Andric]

On 2012-04-26 13:53, David Chisnall wrote:
...
> I did some benchmarks a little while ago, and there was, I think, about a 5% 
> slowdown on buildworld with a dynamically linked clang vs a statically linked 
> one on x86-64.  Ideally, I'd want the bootstrap compiler to be statically 
> linked but the installed one to be dynamic.  

This is already the case, all bootstrap toolchain components are statically 
linked:

$ file /usr/obj/usr/src/tmp/usr/bin/*
/usr/obj/usr/src/tmp/usr/bin/CC:  ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/addr2line:   ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/as:  ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/bugpoint:ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/c++: ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/c++filt: ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/cc:  ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/clang:   ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/clang++: ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/clang-cpp:   ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/clang-tblgen:ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/cpp: ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/g++: ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/gcc: ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/gcov:ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/gcpp:ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/gnu-ar:  ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/gnu-ranlib:  ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/ld:  ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/lint:ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/llc: ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/lli: ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/llvm-ar: ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/llvm-as: ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/llvm-bcanalyzer: ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/llvm-diff:   ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/llvm-dis:ELF 32-bit LSB executable, Intel 
80386, version 1 (FreeBSD), statically linked, for FreeBSD 9.0 (900505), not 
stripped
/usr/obj/usr/src/tmp/usr/bin/llv

Re: GCC update for testing

[Dimitry Andric]

On 2012-05-17 17:44, Pedro Giffuni wrote:> Hi;
> I took a bunch of patches that were merged into the GCC 4.1 branch
> (under GPLv2) and prepared a patch for merging them into our base
> gcc. These are supposed to be bug fixes only.
> 
> You can get the patch here:
> http://people.freebsd.org/~pfg/patches/patch-contrib-gcc
> And, for those really interested, the log is here:
> http://people.freebsd.org/~pfg/patches/gcc41-pr-log
> 
> It may be my imagination but the patch seems to be causing more
> warnings than usual and it breaks the kernel here:
...
> ../../../cam/scsi/scsi_sa.c: In function 'samount':
> ../../../cam/scsi/scsi_sa.c:1887: warning: 'comp_supported' may be used 
> uninitialized in this function
> ../../../cam/scsi/scsi_sa.c:1888: warning: 'write_protect' may be used 
> uninitialized in this function

These warnings seem wrong, upon casual inspection of the code.  In any
case, if you compile the same file with gcc 4.7, they don't appear. :)

Any idea which particular gcc fix is responsible for them?

As a workaround, we could set all those variable to some reasonable
value, but that feels like a cheap trick to me...

But I'd rather just not import the fix that causes those warnings.
___
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: WITH_CLANG_IS_CC and unrecognized command line options

[Dimitry Andric]

On 2012-05-20 19:34, Bruce Cran wrote:> I've done a fresh install of FreeBSD 
9.0, upgraded to 10-CURRENT and 
> have just tried doing a rebuild with CLANG_IS_CC=yes in src.conf.  
> However there's an error building ncurses:
> 
> cc: unrecognized option '-Qunused-arguments'
> cc: unrecognized option '-Qunused-arguments'
> cc1: error: unrecognized command line option "-Wno-empty-body"
> cc1: error: unrecognized command line option "-Wno-string-plus-int"
> cc1: error: unrecognized command line option "-Wno-tautological-compare"
> cc1: error: unrecognized command line option "-Wno-parentheses-equality"
> cc1: error: unrecognized command line option "-Wno-empty-body"
> cc1: error: unrecognized command line option "-Wno-string-plus-int"
> cc1: error: unrecognized command line option "-Wno-tautological-compare"
> cc1: error: unrecognized command line option "-Wno-parentheses-equality"
> *** [make_hash] Error code 1
> *** [make_keys] Error code 1
> 
> Is there some configuration I've missed?

Yeah, unfortunately, for the first buildworld to succeed you will also
need to have:

CC=clang
CXX=clang++
CPP=clang-cpp

in your src.conf.  After installing world, the new /usr/bin/cc will then
recognize the options. This is a problem that I haven't yet been able to
solve...
___
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: gcc46 header search path

[Dimitry Andric]

On 2012-07-06 22:44, Warner Losh wrote:
...
> The reasons are that /usr/local/include superceds anything in /usr/include.  
> This is dangerous.  Users should get just the system default libraries and 
> headers when they compile unless they ask for more.  That's what makes it 
> stupid.

Well, one issue is that it becomes tricky to *remove* /usr/local/include
from the include path, if you so desire, since it's built-in...  Unless
you start fiddling with -nostdinc, but that is rather painful.
___
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: MCLinker and llvm-config

[Dimitry Andric]

On 2012-07-24 11:02, Erik Cederstrand wrote:
> I'm creating a FreeBSD port for MCLinker (http://code.google.com/p/mclinker/) 
> in preparation of MCLinker working without patching LLVM, and testing 
> MCLinker as a system linker when it gets far enough.
> 
> In the configure stage, MCLinker needs to run llvm-config, which is not 
> installed by default in FreeBSD, even when WITH_CLANG_EXTRAS is set. What is 
> the best option to get llvm-config on my system? Can I just run make && make 
> install somewhere in /usr/src?

I never added the tool to the tree, because I simply didn't think
anybody would need to ever run this (IMO not very useful) tool.  (Since
the configuration is totally static, there's no need to dynamically run
a tool such as this to get at the configuration details.)

It isn't too hard to re-add it to the tree though, and add it to the
WITH_CLANG_EXTRAS case.  Another possibility is to just install the
lang/clang or lang/clang-devel port.

Btw, does MCLinker want to use LLVM as a shared library, by any chance?
If that is the case, you should definitely use the port, as adding the
shared library to the system is something I still need to implement.
___
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: BSD ld (was Re: MCLinker and llvm-config)

[Dimitry Andric]

On 2012-07-28 16:15, Pedro Giffuni wrote:
> The Elftoolchain project has been developing a BSD ld:
> 
> http://sourceforge.net/apps/trac/elftoolchain/ 
> 
> 
> http://sourceforge.net/apps/trac/elftoolchain/browser/trunk/ld 
> 
> 
> I thought that would be the official FreeBSD implementation.

Let's just say there really isn't any consensus yet, except that GNU ld
should be binned. :) 

At EuroBSDCon 2011 there was a toolchain WG, where a few ideas and
requirements for a good system linker were shuffled around.  See
Brooks' report here:

http://wiki.freebsd.org/201110DevSummit/Toolchain?action=AttachFile&do=view&target=toolchain-wg-report.pdf
___
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: BSD archive file formats

[Dimitry Andric]

On 2012-08-06 14:16, Erik Cederstrand wrote:
...
> To do that, it would be helpful if our LLVM is updated to something later 
> than r160433, since our version in CURRENT needs patching for MCLinker to 
> work. I've asked dim@, but no reply yet. As far I know, we try to follow 
> official LLVM releases in CURRENT. In that case, I guess LLVM 3.2 will happen 
> around December 2012.

I'm working on importing a new clang snapshot (from trunk, so version
3.2), on request from Brooks and others.  It's going to take a little
while, though.  This is not because it is tricky to import it into the
tree as-is, but because this new version triggers a whole bunch of new
warnings, that I have to verify the fixes for with several people. :)

Fur -current, I see no big trouble with using a snapshot, as long as it
is reasonably stable.  That is, it must be able to build itself
flawlessly, survive all of llvm and clang's own regression tests, and
obviously, build world, kernel and a reasonable set of ports.

That said, I do remember you asked me to import a specific changelist
from upstream to make MCLinker build.  I will do so tonight, probably.
___
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 as default compiler November 4th

[Dimitry Andric]

On 2012-09-11 09:58, David Chisnall wrote:

Clang should default to c89 mode when invoked as cc.  I had a patch to do this, 
but I seem to have misplaced it.  I'll try to find or rewrite it in the next 
couple of days.

A lot of the ports failures I saw were due to ports using cc as the default C 
compiler (autoconf seems to select it) and then using GNU89 inlining rules, so 
that they died with linker failures.


Yes, this happens a lot, even with relatively new software.  Though I
don't see why we couldn't just add -std=gnu89 by default in bsd.port.mk,
if no CSTD= setting is specified.  This should work for any version of
clang, or any other compilers that don't default to gnu89.

So I am a bit reluctant to change clang's default standard to c89,
unless clang upstream agrees with this.  In the interest of prodding
people to update their software, I would rather have the default stay
c99, personally. :)



Given that POSIX deprecated cc in 1997, I'm quite tempted to say that we should 
just remove it entirely and just have c89, c99 and c11 (which the spec for cc 
says you should use instead), forcing people to explicitly select their 
language dialect, but that's a bikeshed for another day.


I think that is a little bit overkill.  People who don't care about
standards anyway, will not go through the trouble of setting CC
carefully to 'c89', 'c99' or 'c11'.  Most of their software simply
hardcodes "gcc", and must be fixed manually after 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"

Re: Clang as default compiler November 4th

[Dimitry Andric]

On 2012-09-11 15:24, Steve Kargl wrote:
...

How fast clang builds world in comparison to gcc is irrelevant.


Not at all irrelevant: this proposal is about changing the default
compiler for the FreeBSD system itself, not for all software out there.

If certain software performs significantly better with gcc, and using
newer versions of the GPL is no problem, then it is obviously the better
choice.

However, I think the majority of users can get by just fine using clang,
right now.  Doug Barton even confirmed in this thread that 80% of our
ports already work with it!



What is important is whether software built with clang functions
correctly.  See for example,

http://math-atlas.sourceforge.net/errata.html#WhatComp


Yes, maths support, specifically precision, is admittedly still one of
clang's (really llvm's) weaker points.  It is currently not really a
high priority item for upstream.

This is obviously something that a certain part of our userbase will
care a lot about, while most of the time they won't care so much about
licensing or politics.  So those people are probably better off using
gcc for the time being.



Has anyone run Spec CPU2006 on i386 and amd64 FreeBSD?


I am not aware of it, but is that test available publicly?  I might take
a shot, if I can get my hands on it.
___
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 as default compiler November 4th

[Dimitry Andric]

On 2012-09-11 16:27, Tijl Coosemans wrote:> On 11-09-2012 16:10, Dimitry Andric 
wrote:
...

Yes, maths support, specifically precision, is admittedly still one of
clang's (really llvm's) weaker points.  It is currently not really a
high priority item for upstream.

This is obviously something that a certain part of our userbase will
care a lot about, while most of the time they won't care so much about
licensing or politics.  So those people are probably better off using
gcc for the time being.


Does it affect the accuracy of libm functions?


It seems to, at least in specific cases; Steve posted about this in an
earlier thread on -current:

  http://docs.freebsd.org/cgi/mid.cgi?20120905221310.GA97847
___
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 as default compiler November 4th

[Dimitry Andric]

On 2012-09-15 16:30, Tijl Coosemans wrote:

On 15-09-2012 16:09, Roman Divacky wrote:

Is this correct?

lev ~$ ./cos 1.23456789e20
6.031937e-01
-9.629173e-02
2.814722e-01


Yes, that's what the libm call returns.


Fix committed in .

___
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"

Compiler performance tests on FreeBSD 10.0-CURRENT

[Dimitry Andric]

47 28662 28687 
52.201533
msgsnd3 0 2 00.6667 
1.1547005
msgrcv3 0 2 00.6667 
1.1547005
nsignals  3 74107 74107 74107 74107 0
nvcsw 3   1088827   1110096   1089758   1096227 
12019.924
nivcsw3631463668779638421646221 
19843.159

Summary:

On a kernel compiled with gcc 4.2.1, building world in single-threaded mode is
~1.4% slower in real time than on a kernel compiled with clang 3.2, equally fast
in user time, and ~5.6% slower in system time.

Conclusion:
---
The difference in real time is rather minimal, and even negligible in user time,
but in system time it is much more pronounced.

Since system time can be attributed to the kernel proper, a kernel compiled with
clang 3.2 is clearly faster than a kernel compiled with gcc 4.2.1, by a margin
of just over 5 percent.

Building world, multi-threaded, on a GENERIC kernel compiled by clang 3.2
-
  N   Min   MaxMedian   Avg
Stddev
real  3  13832.75  13875.24  13871.47  13859.82 
23.518969
user  3  33658.54  33743.43  33730.26 33710.743 
45.686467
sys   3  14704.76  14775.59  14744.45   14741.6 
35.500903
maxrss3758256758256758256758256 0
ixrss 3  4829  4831  4830  4830 
1
idrss 3   573   574   574 573.7
0.57735027
isrss 3   130   130   130   130 0
minflt3 6.6259374e+08 6.6304066e+08 6.6288552e+08 6.6283997e+08 
226911.43
majflt3  3160  4003  3801 3654.6667 
440.13899
nswap 340404040 0
inblock   3 27763 28008 27853 27874.667 
123.92874
oublock   3 55003 58725 57061 56929.667 
1864.4724
msgsnd3 0 0 0 0 0
msgrcv3 0 0 0 0 0
nsignals  3 60496 60506 60499 60500.333 
5.1316014
nvcsw 3   1891074   1894870   1893148 1893030.7 
1900.7181
nivcsw3   3095468   3126475   3116877   3112940 
15873.988

Building world, multi-threaded, on a GENERIC kernel compiled by gcc 4.2.1
-
  N   Min   MaxMedian   Avg
Stddev
real  3  14017.65  14046.35  14042.26  14035.42 
15.524552
user  3  33596.19  33687.03   33661.9 33648.373 
46.906337
sys   3  15347.75  15438.63  15436.98 15407.787 
51.999823
maxrss3758228758248758244758240 
10.583005
ixrss 3  4808  4809  4809 4808.6667
0.57735027
idrss 3   571   571   571   571 0
isrss 3   130   130   130   130 0
minflt3 6.6301232e+08 6.6339175e+08 6.6312437e+08 6.6317615e+08 
194941.64
majflt3  3715  5509  3812 4345. 
1008.9313
nswap 340404040 0
inblock   3 28327 43672 28374 33457.667 
8845.9034
oublock   3 50661 57892 56870 55141 
3913.3005
msgsnd3 0 0 0 0 0
msgrcv3 0 0 0 0 0
nsignals  3 60501 60506 60504 60503.667 
2.5166114
nvcsw 3   1882397   1910610   1895448 1896151.7 
14119.657
nivcsw3   2747620   2856552   2788778   2797650 
55005.267

Summary:

On a kernel compiled with gcc 4.2.1, building world in multi-threaded mode is
~1.3% slower in real time than on a kernel compiled with clang 3.2, equally fast
in user time, and ~4.5% slower in system time.

Conclusion:
---
As with single-threaded mode, the difference in real time is rather minimal, and
even negligible in user time, but in system time it is much more pronounced.

Since system time can be attributed to the kernel proper, a kernel compiled with
clang 3.2 is clearly faster than a kernel compiled with gcc 4.2.1, by a margin
of just over 4 percent.


Copyright (c) 2012 Dimitry A

Re: Compiler performance tests on FreeBSD 10.0-CURRENT

[Dimitry Andric]

On 2012-09-16 01:22, Luigi Rizzo wrote:
...

the fact that the difference is so small is interesting,
and it might almost suggests that the test is dominated by
other factors than the compiler.


Yes, this result was more or less what I expected: runtime performance
is probably related more to hardware speed, and the efficiency of the
chosen algorithms in the kernel, than to the optimizations any current
compiler can produce.

Apparently our kernel hackers already produce quite efficient code. :)



By chance do you have a
way to produce other data points with different optimization
levels in the compiler ?


I could re-run the tests with e.g. -O1 instead of -O2, or maybe even
-O0, though I am not sure if the kernel will compile correctly without
any optimization.  This will take a while though, and I am not sure if I
can borrow Gavin's machine long enough. :)

-Dimitry
___
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 performance tests on FreeBSD 10.0-CURRENT

[Dimitry Andric]

On 2012-09-16 07:19, Konstantin Belousov wrote:

On Sun, Sep 16, 2012 at 12:34:45AM +0200, Dimitry Andric wrote:

...

I tried to map the CPUID into more human-friendly family moniker, and it
seems that these are Pentium-4 class CPUs. Am I right ?


Yes, it is apparently a Nocona model, this is part of the dmesg:

CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2793.24-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0xf41  Family = f  Model = 4  Stepping = 1
  
Features=0xbfebfbff
  Features2=0x641d
  AMD Features=0x20100800
  TSC: P-state invariant
real memory  = 4294967296 (4096 MB)
avail memory = 4097470464 (3907 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s) x 2 HTT threads
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP/HT): APIC ID:  1
 cpu2 (AP): APIC ID:  6
 cpu3 (AP/HT): APIC ID:  7



If yes, could you, please, rerun the tests on anything more recent than
Core2, i.e. any Core i7-whatever class of Xeons ?


I would love to, especially because the tests will complete faster, but
I currently do not have access to physical machines of that class.

Normally I do performance tests on the FreeBSD reference machines, but
since these tests require booting with a custom kernel (and preferably
root access + remote console), I cannot use them.

So if somebody can offer such a machine (for a limited time only, a few
days most likely, 1 week maximum), it would be great.

-Dimitry
___
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 performance tests on FreeBSD 10.0-CURRENT

[Dimitry Andric]

On 2012-09-16 07:25, Garrett Cooper wrote:
...

 If you can provide the tests, I can rerun it on some Nehalem class
workstations I have access to. I unfortunately don't have access to
SNB/Romley hardware yet.


I did these tests as follows:
- Install a recent -CURRENT snapshot on the box (or rebuild world and
  kernel by hand and install them).
- Install Subversion.
- Checkout head sources into /usr/src, if not already there.
- Build GENERIC kernel with gcc, using default settings, and install it
  into /boot/kernel.gcc.
- Build GENERIC kernel with clang, using default settings, and install
  it into /boot/kernel.clang.
- Boot machine with either kernel, then run the attached runtest.sh
  script, with the buildworld_{single,multi}.sh scripts in the same
  directory.  Save the resulting run-*.txt files in a directory that
  indicates whether the kernel in use was built by gcc or by clang.

You can tweak the 'num_runs' variable at the top of runtest.sh to do
more runs, if the machine is fast.  This should give more confidence in
the final statistics.  I did just 3 runs on Gavin's machine, since it
took more than 7 hours for a single-threaded buildworld to complete.
Doing 6 runs should be more than enough.

The run-*.txt files contain the time(1) output of each run, and should
be processed through ministat to give average, stddev and so on.  Just
send them to me, I will process them and summarize the statistics.

Alternatively, you can give me remote access, and I'll do it. :)
#!/bin/sh
mypath="${0%/*}"
num_runs=3

set -e

do_runtest() {
  for i in $(jot ${num_runs}); do
rm -rf /usr/obj/*
sync
echo "Doing build $1, run $i..."
/usr/bin/time -l -o run-$1-$i.txt ${mypath}/build$1.sh > run-$1-$i.log
head -1 run-$1-$i.txt
  done
}

do_runtest world_single
do_runtest world_multi
#!/bin/sh
set -e
cd /usr/src
make -s buildworld
#!/bin/sh
set -e
cd /usr/src
make -s -j8 buildworld
___
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: enabling libc++ by default when building with clang

[Dimitry Andric]

On 2012-09-17 21:10, Brooks Davis wrote:

Now that we have the COMPILER_TYPE variable I'm following up on an idea
by theraven@ that we should enable libc++ by default when we are
building world with a compiler that supports it.  The following patch
implements this:

http://people.freebsd.org/~brooks/patches/libc%2b%2b-default.diff

One key question is, when do we want to throw this switch?  Do we do it
now so people using clang start using it sooner or do we wait until
we've switched the default compiler and things have settled a bit?


Well, building libc++ does not mean automatically using it.  What is the
use case for only building (and installing) libc++, but not linking it
to anything?  Just so people could build something with it later on?

In any case, I have been building libc++ for a long time now, and also
did some commits left and right to be able to actually use it for the
base system, e.g.  all C++ programs in my installations are already
linked to libc++ (dynamically or statically).  I have seen no problems
at all, and I am even working on a WITHOUT_LIBSTDCPLUSPLUS option. :)

I think the end goal should be to enable building and using libc++ with
one switch.  And sooner or later, to make that the default.  Then
FreeBSD will finally be able to use C++0x and C++11 features natively.
___
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"

More kernel performance tests on FreeBSD 10.0-CURRENT

[Dimitry Andric]

   
Stddev
real  6   4943.74   4965.28   4955.62   4953.78 
7.2888627
user  6  12274.46  12334.13  12322.13 12314.472 
21.858036
sys   6   4576.99   4621.09   4617.21   4609.75 
16.658918
maxrss6758208758256758224758232 
19.595918
ixrss 6  4897  4902  4898 4898.6667 
1.9663842
idrss 6   581   582   581 581.3
0.51639778
isrss 6   131   131   131   131 0
minflt6  6.626435e+08  6.634147e+08 6.6301953e+08  6.629835e+08 
279004.88
majflt6  6092 11215  9188 8755.1667 
1849.3565
nswap 6406248 49.33 
7.1180522
inblock   6 29076 44462 29163 31697 
6253.6444
oublock   6 25415 28495 28175 27508.167 
1179.5914
msgsnd6 0 0 0 0 0
msgrcv6 0 0 0 0 0
nsignals  6 60488 60499 60495 60494.333 
3.9832984
nvcsw 6   1575048   1588567   1584504 1582316.7 
5705.6913
nivcsw6   1682902   1745827   1730506 1722802.3 
24060.717

Building world, multi-threaded, on a GENERIC kernel compiled by gcc 4.2.1 -O2
-
  N   Min   MaxMedian   Avg
Stddev
real  6   4876.16   4901.55   4895.24 4888.7583 
10.598318
user  6  12241.35  12306.04  12283.94 12278.767 
23.922356
sys   6   4400.43   4452.62   4446.22 4438.0117 
19.231095
maxrss6758212758256758224 758229.33 
17.095809
ixrss 6  4899  4905  4900 4900.6667 
2.2509257
idrss 6   581   582   582 581.8
0.40824829
isrss 6   131   131   131   131 0
minflt6 6.6214332e+08 6.6334997e+08 6.6298766e+08 6.6278723e+08 
436172.22
majflt6  6055 12473  91698895.5 
2381.6063
nswap 640544848 
4.5607017
inblock   6 29193 3 29313 31804 
6192.0071
oublock   6 25113 28152 26770 26490.167 
1254.3383
msgsnd6 0 0 0 0 0
msgrcv6 0 0 0 0 0
nsignals  6 60496 60501 60499 60498.667 
2.2509257
nvcsw 6   1566521   1592140   1579251 1578889.5  
9354.883
nivcsw6   1686675   1809406   1785290 1756283.7 
50719.325

Summary:

On a kernel compiled with clang 3.2 -O2, building world in multi-threaded mode
is ~1.9% faster in real time than on a kernel compiled with gcc 4.2.1 -O2, and
~8.3% faster in system time.

On a kernel compiled with clang 3.2 -O1, building world in multi-threaded mode
is ~3.2% faster in real time than on a kernel compiled with gcc 4.2.1 -O1, and
~13.1% faster in system time.

On a kernel compiled with gcc 4.2.1 -O2, building world in multi-threaded mode
is ~1.3% faster in real time than on a kernel compiled with gcc 4.2.1 -O1, and
~3.9% faster in system time.

The difference between building world in multi-threaded mode on kernels compiled
with clang 3.2 -O2 and -O1 is not significant (to within 1 standard deviation).

Conclusion:
---
Kernels compiled with clang are a little faster in real time for building world,
and in system time the difference is even larger, roughly 10%.  For clang, the
difference between -O1 and -O2 is not measurable, but for gcc, -O2 is slightly
faster than -O1.

========
Copyright (c) 2012 Dimitry Andric 

Verbatim copying and redistribution of this entire text are permitted, provided
this notice is preserved.

___
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: More kernel performance tests on FreeBSD 10.0-CURRENT

[Dimitry Andric]

On 2012-09-22 09:35, O. Hartmann wrote:

Am 09/21/12 23:39, schrieb Dimitry Andric:

...

At least one can say FreeBSD does not suffer from performance drain
using the cutting edge clang 3.2 compared with a gcc 4.2.1 compiler, the
echo from the past.


Well, the main idea of these tests is to prove that we will have no
regression, or even an improvement in performance, if we make clang
3.2 the default compiler for FreeBSD 10.0, instead of gcc 4.2.1.  And
that seems to be the case, at least for the kernel.

That said, for one of the earlier tests, it seemed that for runtime
performance, gcc 4.7.1-compiled programs (in this case clang 3.2
executables) were slightly faster than clang 3.2-compiled ones.

In my opinion that result is not bad for such a relatively new
compiler, against such a well-established one. :)



Dimirty, are you planning also to benchmark clang 3.2 versus gcc 4.8.0?
 From the development point of view, such a benchmark would be more
natural, but I do not know whether the kernel sources are gcc
4.8-friendly and would allow such a test.


The kernel sources are currentely not very friendly to anything but
our in-tree gcc and clang.  We hacked our version of gcc to recognize
several non-standard flags, such as -fformat-extensions, and a few
others.  We also implemented the -fformat-extensions flag for clang,
since our custom printf format specifiers are used throughout the
kernel.

Ideally, we would remove all these non-standard flags and format
specifiers, which would make it possible to compile the kernel with
any version of gcc or clang, even external ones installed from ports,
or by hand.  This is not a trivial task...

But maybe I'll take a shot, it would be nice to have at least one
comparison against more modern gcc.  I can't give any serious ETA,
though. :)



What is about optimization level "-O3" and architectural recognition via
"-march=native"?


There are only so many things you can test, the possibilities are
literally endless!

I have already done a few preliminary tests for -march=native, but at
least for clang, there seems to be no measureable difference in
performance.  The tests for gcc are still running.

And indeed, -O3 is also a possibility, but again I think the difference
will be very marginal, if measurable at all.

-Dimitry
___
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: More kernel performance tests on FreeBSD 10.0-CURRENT

[Dimitry Andric]

On 2012-09-22 14:52, O. Hartmann wrote:
...

When we used FreeBSD for scientific work, that was around 1998 - 2002,
there were some attempts made to use Intel's icc compiler suite on
FreeBSD in the 32Bit Linuxulator. That time I used that compiler only
for compiling my modelling software, but there where reports of people
made it possible to use the icc compiler also for compiling the FreeBSD
system - with success as far as I know. What happened since then and
more recent days that the sources got "polluted" by those hacks?


The Intel compiler support has been largely removed, because it was not
maintained.  There are still remnants in cdefs.h though, and in theory
it could be revived, if there was enough interest.

However, Intel simply does not support anything else besides Windows and
Linux for its compiler suite, and even on the Linux side you are best
off if you use Red Hat or a Red Hat-based distribution such as CentOS or
Scientific Linux.

Some time ago I attempted to get a fairly recent Intel compiler version
working on FreeBSD, but it was very tricky, and I remember I did not get
everything working correctly.

So unless either Intel starts supporting FreeBSD (or other BSDs), which
is very unlikely, or somebody manages to get the Linux version working
perfectly as a port, I don't see much sense in restoring the Intel
compiler support.



No offense to you, but somehow this sounds that the efford has been
placed in the wrong way since people revert with energy that what has
been hacked with energy ;-)


I think you see this incorrectly; when I removed the Intel compiler
support from the tree, it was unmaintained for several years already.
Apparently there was very little interest for it.


...

I have already done a few preliminary tests for -march=native, but at
least for clang, there seems to be no measureable difference in
performance.  The tests for gcc are still running.


I was wondering if the organisation and amount of cache present in a
modern CPU is not taken into account when optimising code. Our Core2Duo
CPUs still in use do have different architectural features than the more
recent Core-i7 systems. Latter ones have level 3 caches. How does a
compiler take advantage of those features by not given an explicit hint?


I don't think the amount of CPU cache, or the number of levels, is taken
into account, really.  When you select a certain CPU type with -march,
the compiler will just enable several features that are supported on
that CPU, e.g. MMX, SSE, AVX and so on.  It can also enable extra CPU
registers, and/or switch to slightly different instruction scheduling.

But since we are compiling the kernel with -mno-mmx, -mno-sse and even
floating point disabled, apparently there is no real gain from
specifying higher CPU types.

-Dimitry
___
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: [patch][libc++]using some undeclared functions with -std=c++98, -std=c++03 or -ansi

[Dimitry Andric]

On 2012-11-23 00:09, Yamaya Takashi wrote:

With -std=c++98, -std=c++03 or -ansi, __LONG_LONG_SUPPORTED is not defined.
So some functions((lldiv_t, )atoll, strtoll, strtoull, llabs, lldiv,
wcstoll, wcstoull) are undeclared.
But libc++ headers(cstdlib and cwchar) use them.


The general idea of your patch is good, but we need to check it with
upstream first.  For example, __LONG_LONG_SUPPORTED is a FreeBSD
specific define, so for the general case the solution might be more
complicated.

Note there are also other problems when compiling libc++ with -std=c++98
and -std=c++03, such as complaints about namespacing and such.  I am not
entirely sure libc++ is fully supported yet under those restrictions. :)

In any case, I will see if I can come up with a patch which is more
suitable for upstream, and move the discussion there.
___
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: [patch][libc++]using some undeclared functions with -std=c++98, -std=c++03 or -ansi

[Dimitry Andric]

On 2012-11-24 11:45, David Chisnall wrote:

On 23 Nov 2012, at 21:27, Dimitry Andric wrote:

Note there are also other problems when compiling libc++ with -std=c++98
and -std=c++03, such as complaints about namespacing and such.  I am not
entirely sure libc++ is fully supported yet under those restrictions. :)


In theory, the libc++ headers that are part of the C++03 spec (i.e. not things like 
) should work in C++98 / C++03 mode, however the implementation in 
libc++ must be compiled in C++11 mode.

To upstream this patch, the __LONG_LONG_SUPPORTED flag should be 
unconditionally set for non-FreeBSD flags in the __config file in libc++.  This 
will have no functionality change on other platforms.


I have posted a proposed patch to the upstream mailing list here:

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20121119/068587.html

If it is accepted as-is, I will merge it immediately.
___
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: [patch][libc++]using some undeclared functions with -std=c++98, -std=c++03 or -ansi

[Dimitry Andric]

On 2012-11-24 11:45, David Chisnall wrote:
...

In theory, the libc++ headers that are part of the C++03 spec (i.e. not things like 
) should work in C++98 / C++03 mode, however the implementation in 
libc++ must be compiled in C++11 mode.


Minor note: we now use -std=c++0x by default for building libc++, so
shall I update that to -std=c++11?
___
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: [patch][libc++]using some undeclared functions with -std=c++98, -std=c++03 or -ansi

[Dimitry Andric]

On 2012-11-25 18:31, Dimitry Andric wrote:
...

I have posted a proposed patch to the upstream mailing list here:

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20121119/068587.html

If it is accepted as-is, I will merge it immediately.


Upstream committed the patch after some explanation, and I merged it to
head in r243572.
___
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: svn commit: r309380 - head/emulators/wine-devel (fwd)

[Dimitry Andric]

On 2012-12-22 04:15, Gerald Pfeifer wrote:

If someone wants to have a look, this was on
   10.0-CURRENT FreeBSD 10.0-CURRENT #6 r243901: Wed Dec 5 21:18:57 UTC 2012
with
   FreeBSD clang version 3.2 (branches/release_32 168974) 20121130

Attached you'll find the log and two trace files created by clang.



Assertion failed: (CanSROA), function visitUsers, file 
/scratch/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar/SROA.cpp,
 line 2395.
Stack dump:
0.  Program arguments: /usr/bin/cc -cc1 -triple i386-unknown-freebsd10.0 
-emit-obj -disable-free -main-file-name ptrace.c -mrelocation-model static 
-mdisable-fp-elim -relaxed-aliasing -masm-verbose -mconstructor-aliases 
-target-cpu i486 -momit-leaf-frame-pointer -coverage-file 
/scratch2/tmp/gerald/wine-devel-work/wine-1.5.20/server/ptrace.o -resource-dir 
/usr/bin/../lib/clang/3.2 -D __WINESRC__ -I . -I . -I ../include -I ../include 
-I /home/gerald/10-i386/include/freetype2 -I /home/gerald/10-i386/include -I 
/home/gerald/10-i386/include -fmodule-cache-path /var/tmp/clang-module-cache 
-O2 -Wall -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers 
-Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wwrite-strings 
-Wpointer-arith -fconst-strings -fdebug-compilation-dir 
/scratch2/tmp/gerald/wine-devel-work/wine-1.5.20/server -ferror-limit 19 
-fmessage-length 0 -mstackrealign -fobjc-runtime=gnustep 
-fdiagnostics-show-option -o ptrace.o -x c ptrace.c
1.   parser at end of file
2.  Per-function optimization
3.  Running pass 'SROA' on function '@write_process_memory'


Thanks for reporting this, it was due to LLVM PR 14601.  It should be
fixed in r244598.  The fix will also go into stable/9, when that gets
clang 3.2.
___
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: temp file turd left behind in odd case...

[Dimitry Andric]

On 2013-01-15 20:35, John-Mark Gurney wrote:

If you try to compile the following file:
#include 

__m128i
bar(__m128i a, __m128i b)
{
 return _mm_aesenc_si128(a, b);
}

w/ the command:
clang -D__AES__ -c intrintest.c

You'll get the error:
fatal error: error in backend: Cannot select: intrinsic %llvm.x86.aesni.aesenc

and a intrintest.o- temp file left behind from the failed compile...


Hm, weird... On i386, this simply produces errors about SSE2 not being
enabled, and a whole bunch of other errors and warnings.

On amd64, it does indeed produce the llvm backend error you have shown.
I will report this to upstream, but there is a good chance they will say
"don't do that then". :-)



Yes, the correct way to enable the AES instructions is with the -maes
option, but I didn't know that at the time...  Looks like clang doesn't
fully clean up in this case...

I tried this on MacOSX's clang, but the smmintrin.h header prevents me
from compiling w/ the error:
In file included from /usr/bin/../lib/clang/2.1/include/wmmintrin.h:31:
/usr/bin/../lib/clang/2.1/include/smmintrin.h:28:2: error: #error "SSE4.1
   instruction set not enabled"
#error "SSE4.1 instruction set not enabled"

It'd be nice if -maes and related SSE enabling options were documented
in the man page... :)


We don't maintain our own manpage, upstream produces either .rst or .pod
files, and manpages or other docs are generated from those.  Please send
any suggestions for documentation updates to one of the appropriate
upstream mailing lists for review.
___
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: ports/170256: audio/mpg123: SIGNAL 10 (SIGBUS) error

[Dimitry Andric]

On 2013-01-22 18:13, Jan Beich wrote:

The bug probably happens with every .mp3 file.

...

And this is caused by a broken .align check in configure.ac:

$ echo '.align 3' | clang -c -o /dev/null -x assembler -
$ echo '.align 3' | gcc47 -c -o /dev/null -x assembler -
{standard input}: Assembler messages:
{standard input}:1: Error: alignment not a power of 2
Exit 1
$ echo '.align 3' | as -o /dev/null
{standard input}: Assembler messages:
{standard input}:1: Error: alignment not a power of 2
Exit 1

No clue whose bug is this but here's a workaround.


I'm inclined to say this is a bug in mpg123's configure script, or even
simpler, in their code.  They shouldn't use .align, but .balign or
.p2align, if they want to be sure of the correct alignment.

That said, the difference is that gas (depending on arch) errors out
when it finds the argument to .align is not a power of 2, while clang
accepts such weird alignments.  (That is, if you are crazy enough to
want to align to 3 bytes, why shouldn't the assembler oblige? :-)



--- configure.ac~
+++ configure.ac
@@ -838,21 +838,21 @@

  dnl ## Assembler, compiler properties

  # based on posting from John Dalgliesh  on ffmpeg (LGPL) 
mailing list
  # find if .align arg is power-of-two or not
  asmalign_exp="unknown"
  if test x"$asmalign_exp" = xunknown; then
AC_MSG_CHECKING([if .align takes 2-exponent])
asmalign_exp="no"
echo '.align 3' > conftest.s
-   if $CCAS -c -o conftest.o conftest.s 1>/dev/null 2>&1; then
+   if $AS -c -o conftest.o conftest.s 1>/dev/null 2>&1; then


Well, either this, or just patching src/libmpg123/mangle.h to use the
more predictable .balign or .p2align directives.
___
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: Removing default build of gcc

[Dimitry Andric]

On 2013-01-25 21:54, Pedro Giffuni wrote:
...

I am aware a fix is being worked on. I think that as long as
the default compiler/C++ library works it is OK to make things
easier for other compilers. I am OK with having that change in
-current but for 9.x it is simply unacceptable.


Actually, clang with libc++ works fine, and both clang and gcc with
libstdc++ don't...

If the problem is caused by the switchable libsupc++.so backend lib, I
would have no trouble with reverting that.  But do we know that for sure
at this point?  I have not spent enough time looking deeply into the
issue.

I did notice that libsupc++ .So objects get linked into libstdc++.so,
even while they are also in libsupc++.so.  Maybe that is causing trouble?
___
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: base gcc and _GLIBCXX_USE_C99

[Dimitry Andric]

On 2013-02-01 14:01, Andriy Gapon wrote:

on 28/01/2013 17:11 Andriy Gapon said the following:

I wonder why the following is the case for the base gcc.
/usr/include/c++/4.2/bits/c++config.h:

/* Define if C99 functions or macros from , , ,
, and  can be used or exposed. */
/* #undef _GLIBCXX_USE_C99 */

Because of this undef there is no e.g. std::strtoll().
Ditto for other things in stdlib.h.


Maybe this support can't be enabled, because we don't expose all the
required functions yet?  Or maybe it is just something that was
committed years ago, and then forgotten.

If we are sure that all the C99 functions libstdc++ requires are now
available and working, I see no problem in turning on _GLIBCXX_USE_C99.
___
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: [patch]r246028, libcxxrt's Version.map is broken

[Dimitry Andric]

On 2013-02-01 16:28, Yamaya Takashi wrote:

On 2013/02/01 08:03, Yamaya Takashi wrote:

After r246028, make buildworld with -stdlib=libc++ -std=c++11 is failed.
libcxxrt's Version.map is broken, because some needed symbols are removed.

Add missing symbol and refine.


Thank you very much.  I have verified that your patch makes building
world with -stdlib=libc++ work.  I have committed it in r246297.

-Dimitry
___
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: base gcc and _GLIBCXX_USE_C99

[Dimitry Andric]

On 2013-02-01 15:46, Pedro Giffuni wrote:

On 02/01/2013 08:01, Andriy Gapon wrote:

on 28/01/2013 17:11 Andriy Gapon said the following:

I wonder why the following is the case for the base gcc.
/usr/include/c++/4.2/bits/c++config.h:

/* Define if C99 functions or macros from , , ,
 , and  can be used or exposed. */
/* #undef _GLIBCXX_USE_C99 */

Because of this undef there is no e.g. std::strtoll().
Ditto for other things in stdlib.h.


I looked at this very briefly and it looks like it would fix a nasty
issue we have been working around in OpenOffice.

I suggest to enable it first on a gcc port though (it's tied to a
configure flag, but don't remember which).


I had a bit more in-depth look at our current libstdc++ configuration.

I took the original gcc 4.2.1 release tarball, modified a few autoconf
related scripts to cope with "freebsd10.0" being the current version,
and did a full three-stage build, though only targeting C and C++.

The libstdc++ configure script in 4.2.1 does detect a few new features
that are not in our shipping config.h, but is does not detect any
different settings regarding C99.

The reason it does not turn on _GLIBCXX_USE_C99, is that not all of the
C99 requirements are met, specifically  checks fail:

  checking for ISO C99 support in ... yes
  checking for ISO C99 support in ... no
  checking for ISO C99 support in ... yes
  checking for ISO C99 support in ... yes
  checking for ISO C99 support in ... yes
  checking for fully enabled ISO C99 support... no

The exact failure testcase goes like this:

  configure:7435: checking for ISO C99 support in 
  configure:7492:  /home/dim/obj/gcc-4.2.1/./gcc/xgcc -shared-libgcc 
-B/home/dim/obj/gcc-4.2.1/./gcc -nostdinc++ 
-L/home/dim/obj/gcc-4.2.1/i386-unknown-freebsd10.0/libstdc++-v3/src 
-L/home/dim/obj/gcc-4.2.1/i386-unknown-freebsd10.0/libstdc++-v3/src/.libs 
-B/home/dim/ins/gcc-4.2.1/i386-unknown-freebsd10.0/bin/ 
-B/home/dim/ins/gcc-4.2.1/i386-unknown-freebsd10.0/lib/ -isystem 
/home/dim/ins/gcc-4.2.1/i386-unknown-freebsd10.0/include -isystem 
/home/dim/ins/gcc-4.2.1/i386-unknown-freebsd10.0/sys-include -c -g -O2   conftest.cc 
>&5
  conftest.cc: In function 'int main()':
  conftest.cc:41: error: 'clogf' was not declared in this scope
  conftest.cc:47: error: 'cpowf' was not declared in this scope
  conftest.cc:54: error: 'clog' was not declared in this scope
  conftest.cc:60: error: 'cpow' was not declared in this scope
  conftest.cc:64: error: 'ccosl' was not declared in this scope
  conftest.cc:65: error: 'ccoshl' was not declared in this scope
  conftest.cc:66: error: 'cexpl' was not declared in this scope
  conftest.cc:67: error: 'clogl' was not declared in this scope
  conftest.cc:68: error: 'csinl' was not declared in this scope
  conftest.cc:69: error: 'csinhl' was not declared in this scope
  conftest.cc:71: error: 'ctanl' was not declared in this scope
  conftest.cc:72: error: 'ctanhl' was not declared in this scope
  conftest.cc:73: error: 'cpowl' was not declared in this scope
  configure:7498: $? = 1

So until we actually implement and declare those functions, we should
probably not enable _GLIBCXX_USE_C99_COMPLEX and _GLIBCXX_USE_C99.

I have attached a diff of the other changes that can be applied on our
current libstdc++ config file, as detected by the configure script.  I
will probably commit that soonish, if there are no objections.

As to the missing complex functions, I am not sure.  Maybe these can be
imported from somewhere else, e.g. NetBSD?  This is probably something
to ask the lib/msun specialists...

-Dimitry
Index: gnu/lib/libstdc++/config.h
===
--- gnu/lib/libstdc++/config.h	(revision 246297)
+++ gnu/lib/libstdc++/config.h	(working copy)
@@ -22,7 +22,7 @@
 #define HAVE_ATAN2F 1
 
 /* Define to 1 if you have the `atan2l' function. */
-/* #undef HAVE_ATAN2L */
+#define HAVE_ATAN2L 1
 
 /* Define to 1 if you have the `atanf' function. */
 #define HAVE_ATANF 1
@@ -67,7 +67,7 @@
 #define HAVE_EXPF 1
 
 /* Define to 1 if you have the `expl' function. */
-/* #undef HAVE_EXPL */
+#define HAVE_EXPL 1
 
 /* Define to 1 if you have the `fabsf' function. */
 #define HAVE_FABSF 1
@@ -100,7 +100,7 @@
 #define HAVE_FMODF 1
 
 /* Define to 1 if you have the `fmodl' function. */
-/* #undef HAVE_FMODL */
+#define HAVE_FMODL 1
 
 /* Define to 1 if you have the `fpclass' function. */
 /* #undef HAVE_FPCLASS */
@@ -134,7 +134,7 @@
 #define HAVE_HYPOTF 1
 
 /* Define to 1 if you have the `hypotl' function. */
-/* #undef HAVE_HYPOTL */
+#define HAVE_HYPOTL 1
 
 /* Define to 1 if you have the `iconv' function. */
 /* #undef HAVE_ICONV */
@@ -293,7 +293,7 @@
 #define HAVE_SQRTF 1
 
 /* Define to 1 if you have the `sqrtl' function. */
-/* #undef HAVE_SQRTL */
+#define HAVE_SQRTL 1
 
 /* Define to 1 if you have the  header file. */
 #define HAVE_STDBOOL_H 1
@@ -304,6 +304,12 @@
 /* Define to 1 if you have the  header file. */
 #define HAVE_STDLIB_H 1
 
+/* De

Re: standards/175453: Catching C++ std::bad_cast doesn't work in FreeBSD 9.1

[Dimitry Andric]

On 2013-02-04 23:12, Pedro Giffuni wrote:

On 02/04/2013 17:03, Hongli Lai wrote:

Any progress on fixing this issue?

I think there is a fix (and a fix to the fix) in -current.


I have merged the necessary fixes to stable/9 in r246368.
___
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: bin/175930: clang does not define __STDC_ISO_10646__, despite having Unicode in wchar_t

[Dimitry Andric]

On 2013-02-09 17:03, lini...@freebsd.org wrote:> Old Synopsis: CLang does not 
define __STDC_ISO_10646__, despite having Unicode in wchar_t

New Synopsis: clang does not define __STDC_ISO_10646__, despite having Unicode 
in wchar_t

Responsible-Changed-From-To: freebsd-bugs->freebsd-toolchain
Responsible-Changed-By: linimon
Responsible-Changed-When: Sat Feb 9 16:02:36 UTC 2013
Responsible-Changed-Why:
let's see if anyone on toolchain@ has an opinion.

http://www.freebsd.org/cgi/query-pr.cgi?pr=175930


I don't think this has anything to do with clang (or gcc, for that
matter).  It is a potential issue with our system headers, specifically
.

Our wchar_t is either int or unsigned int (on armeabi), so I guess it
should not be a problem to define a sensible value for the
__STDC_ISO_10646__ macro there.

As to what the exact value should be, I have no idea really.  The
C99 standard says only this:

__STDC_ISO_10646__
   An integer constant of the form mmL (for example, 199712L),
   intended to indicate that values of type wchar_t are the coded
   representations of the characters defined by ISO/IEC 10646, along
   with all amendments and technical corrigenda as of the specified
   year and month.

GNU libc has this:

/* wchar_t uses ISO 10646-1 (2nd ed., published 2000-09-15) / Unicode 3.1.  */
#define __STDC_ISO_10646__  29L

So maybe that is a good value for us too?
___
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: c89 broken on head?

[Dimitry Andric]

On 2013-03-07 18:24, Tijl Coosemans wrote:

Whatever the command line arguments, running c89 almost always results in
the following output. Anyone else seeing this?

c89: illegal option -- 1
usage: c89 [-cEgOs] [-D name[=value]] ... [-I directory] ... [-L directory] ...
[-o outfile] [-U name] ... operand ...

where operand is one or more of file.c, file.o, file.a
or -llibrary


Does anybody ever actually use this tool, really? :-)

In any case, what happens is that /usr/bin/c89 builds up an argv[]
array, prepending the flags "-std=iso9899:199409" and "-pedantic" to the
other arguments, but it sets argv[0] to "/usr/bin/c89" too.

If /usr/bin/cc is gcc, this causes no problems, since gcc always runs
/usr/libexec/cc1 for its first stage compilation process.  It basically
ignores the value of argv[0].

When /usr/bin/cc is clang, however, it uses argv[0] to run its first
stage compilation, with -cc1 as the first argument.  So this will run
/usr/bin/c89 yet again, and that complains about the unrecognized '1'
option.

It can be solved very easily, by letting c89.c set argv[0] to
/usr/bin/cc instead, similar to c99.c, as with this diff:

Index: usr.bin/c89/c89.c
===
--- usr.bin/c89/c89.c   (revision 247448)
+++ usr.bin/c89/c89.c   (working copy)
@@ -72,7 +72,7 @@ main(int argc, char **argv)
Argv.a = malloc((argc + 1 + N_ARGS_PREPENDED) * sizeof *Argv.a);
if (Argv.a == NULL)
err(1, "malloc");
-   Argv.a[Argc++] = argv[0];
+   Argv.a[Argc++] = CC;
for (j = 0; j < N_ARGS_PREPENDED; ++j)
Argv.a[Argc++] = args_prepended[j];
while ((i = getopt(argc, argv, "cD:EgI:l:L:o:OsU:")) != -1) {



Also, I seem to remember a discussion about making -std=gnu89 the default
for clang when run as "cc", but nothing seems to have changed. Could this
be picked up again, because there are in fact subtle semantic differences
between gnu89 inline and c99 inline that old code may rely on.


Why on earth would you want gnu89 still as the default in 2013?  I would
rather have it default to C11, but the support for this isn't complete
yet... :-)
___
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: c89 broken on head?

[Dimitry Andric]

On 2013-03-07 21:22, Tijl Coosemans wrote:
...

Because it's the practical thing to do? Old code/makefiles can't possibly
be expected to know about compilers of the future, while new code can be
expected to add -std=c11.


I am not sure I buy that argument; if it were so, we should default to
K&R C instead, since "old code" (for some arbitrary definition of "old")
could never have been expected to know about gcc defaulting to gnu89.
___
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: -mno-omit-leaf-frame-pointer

[Dimitry Andric]

On Mar 30, 2013, at 09:10, Andriy Gapon  wrote:
> It seems that, unlike gcc, for clang -fno-omit-frame-pointer does not imply
> -mno-omit-leaf-frame-pointer.  This is probably a bug.

Yes, this is indeed the case.  There is even a rather old unresolved PR
for it in LLVM's Bugzilla:

http://llvm.org/bugs/show_bug.cgi?id=9825


> Meanwhile I would like to propose the following amd64-specific patch.  Perhaps
> the same type of change would be useful for powerpc as well.

Most likely yes.


> I would like this change primarily for DTrace (fbt), but other
> debugging/profiling code may benefit from it as well.
> 
> I chose to make -mno-omit-leaf-frame-pointer not conditional on clang, because
> with gcc it is just a nop (i.e. it doesn't hurt anything).

The patch looks good to me, please commit.

___
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: Miscellaneous questions

[Dimitry Andric]

On 2013-05-03 03:08, Kennith Caudill wrote:

1.) Processor affinity with C++11 threads

Will there be a standard non-hackish way to set processor affinity on C++11 
std::threads?

This would be a great feature imho. I admit that I haven't researched this and 
maybe it's
possible to use the pthreads API to accomplish this but I'd prefer a more 
idiomatic choice.


As far as I understand the standard, there is no portable way to do it.
For libc++, you can call std::thread::native_handle() to retrieve the
implementation-defined thread type, which is just pthread_t.

Maybe in C++14 or C++17, just keep on lobbying... :-)



2.) Alternative linkers

Is there a document available detailing the current feasible linkers and their 
status?

e.g., is it possible to build a working system with mclinker, gold, etc., and 
what is the
process for accomplishing this? I'm willing to write up detailed guides if 
someone
will provide the broad strokes of how to test this out.


I am not aware of any documentation, but there have been a few efforts,
by different people.  In all cases, it seems to be highly experimental,
and a lot of things might still be broken.  The most interesting
challenge is linking the kernel, of course.  And custom linker scripts,
written specifically for GNU ld.



3.) DWARF support

My application returns tens of thousands of link warnings when built with -g:

/usr/bin/ld: Dwarf Error: Invalid or unhandled FORM value: 25.

I assume this is a DWARF4 thing,  relating to my second question.


I fixed this in head, in r248802, and merged it to stable/9 in r249040,
to stable/8 in r249058, and to stable/7 in r249059.  If you update your
binutils, the message should go away.

This does not mean full DWARF4 support, though.  We need binutils and
gdb replacements for that, especially for the linker (and possibly the
assembler, but the assembler could already be mostly replaced with
clang's integrated assembler).  Alternatively, we could attempt to
support using more recent binutils from ports.



4.) lldb status

Is this described in detail anywhere?


Last I know, Kip Macy was working on this for a time, but he disappeared
again.  I am not sure of any other efforts.

-Dimitry
___
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: patch to add AES & PCLMUL intrinsics to gcc

[Dimitry Andric]

On 2013-05-06 10:39, David Chisnall wrote:

On 6 May 2013, at 01:27, John-Mark Gurney  wrote:


One question I have is that I copied wmmintrin.h from clang... It has a
license statement, but no copyright statement...  Do I need to add one
from somewhere?


The clang headers are all supposed to have a UIUC license header.  If you find 
one that is missing, then file a bug report upstream.


All of the clang headers have this at the start:

/*=== smmintrin.h - SSE4 intrinsics ===
 *
 * Permission is hereby granted, free of charge, to any person obtaining a copy
 * of this software and associated documentation files (the "Software"), to deal
 * in the Software without restriction, including without limitation the rights
 * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 * copies of the Software, and to permit persons to whom the Software is
 * furnished to do so, subject to the following conditions:
 *
 * The above copyright notice and this permission notice shall be included in
 * all copies or substantial portions of the Software.
 *
 * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
 * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
 * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
 * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
 * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
 * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
 * THE SOFTWARE.
 *
 *===---===
 */

E.g., there is no copyright statement, and it seems to be a BSD/MIT-like 
license...

___
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: missing some c++11 support for clang in FreeBSD

[Dimitry Andric]

On May 14, 2013, at 02:35, Alexander K. Beros  wrote:
> I have just started using clang (on FreeBSD 9.1 AMD64) and encountered a
> couple problems.  I have worked around these points, but in case they
> represent something unintentional (as opposed to some error on my part while
> building from the port) I would like to mention them.  I am using
> 
> FreeBSD clang version 3.1 (branches/release_31 156863) 20120523
> Target: x86_64-unknown-freebsd9.0
> Thread model: posix
> 
> A key element in solving both problems was the installation of gcc47.  That
> was unexpected since I initially installed clang under the assumption that
> FBSD is moving from gcc to clang and since gcc42 doesn't support c++11.

On FreeBSD 9.1, you first need to build libc++, which provides C++11
support. (On 10.0-CURRENT, it is enabled and installed by default, but
not on previous releases.)

To build and install libc++ on 9.1, add the following lines to
/etc/src.conf:

  CC=clang
  CXX=clang++
  CPP=clang-cpp
  WITH_LIBCPLUSPLUS=foo

Then build and install world in the usual manner.  If you prefer to only
build libc++ (and its support library, libcxxrt) manually, you can do
the following:

  cd /usr/src/lib/libcxxrt
  make obj && make depend && make
  sudo make install
  cd /usr/src/lib/libc++
  make obj && make depend && make
  sudo make install

After libc++ is installed, you still need to tell clang to use it
instead of GNU libstdc++; see below.


> 1.. 
> Symptom:
> 
>   %>  clang++ -std=c++11 -stdlib=libstdc++ refparms.c++
>   initListTest.cpp:43:10: fatal error: 'initializer_list' file not
> found
>   #include 
> 
> I had included initializer_list.

To enable libc++, you must add the flag -stdlib=libc++ instead.  If you
use -stdlib=libstdc++, or no -stdlib option, it will use the base system
version of GNU libstdc++, which is the version that comes with gcc 4.2,
and does not support C++11.


> Temporary Solution:
>   I built gcc47 from the port and then added the following to my
> .cshrc file
>   alias clang11 'clang++ -std=c++11 -I/usr/local/lib/gcc47/include/c++
> -I/usr/local/lib/gcc47/include/c++/x86_64-portbld-freebsd9.1'
> 
> Alternate solution, compile using g++47.

This will only work partially, since you still need to make sure to add
the proper flags during linking, so clang can find the libstdc++
libraries installed by the gcc47 port.


> 2..
> Symptom:
>   /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.14 required by
> /usr/home/../binaries/a.out  not found

Yes, this is a problem with the gcc ports.  They are basically unusable
for C++ as-is.  Please complain to the maintainer. :-)


> Solution:
>   I added the following line to /etc/libmap.conf
>   libstdc++.so.6  gcc47/libstdc++.so.6
> 
>   again compiling with g++47 had no such problem.

This is a rather brute-force solution, but it should work, since newer
versions of libstdc++ are backwards compatible.

-Dimitry

___
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: [CFT] gcc: support for barcelona

[Dimitry Andric]

On May 27, 2013, at 21:12, Rui Paulo  wrote:
> On 27 May 2013, at 09:41, Pedro Giffuni  wrote:
>> Almost a year ago I tried to bring in the support for AMD's barcelona
>> chipset into our gcc. This actually filled a lot of holes in that were left
>> when similar intel support was brought in.
>> 
>> Unfortunately I had to revert rapidly such support as it broke building
>> some C++ ports even when it was not being used.
>> 
>> jkim@ did some cleanup of the support and the patch has been
>> gathering rust here:
>> 
>> http://people.freebsd.org/~jkim/reworked-r236962-3.diff
>> 
>> The patch still applies cleanly and there is a good chance it will work
>> since there have been other fixes merged since the last time.
>> 
>> I did some basic testing and so far it works for me but I don't have
>> the specific chipset. Additional testing would be welcome.
> 
> I have to question the general direction of this work. We switched to Clang 
> as the default compiler for i386/amd64 some months ago and now you're working 
> on improving our base GCC especially for amd64? I don't really understand how 
> useful this is. It doesn't strike me as a good idea to see people working on 
> things that will eventually be replaced / removed.

It is probably a better use of time to work on getting the tree to build
with an out-of-tree gcc 4.7 or 4.8 instead.  Why spend more effort on a
completely dead branch of gcc?  Newer gcc's have better code generation,
support for more modern CPUs, and better diagnostics (including even
those controversial carets ;-).

That said, if it is a particular itch somebody wants to scratch, I see
no reason not to, as long as it doesn't break anything else...

-Dimitry

___
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: Should "make -DNOCLEAN buildworld" always rebuild clang?

[Dimitry Andric]

On May 30, 2013, at 22:49, David Wolfskill  wrote:
> As some of you may be aware, I track stable/9 daily.  (A recent history
> of "uname -vp" outputs for stable/9 on my laptop may be seen at
> .)
> 
> And lest this message is misinterpreted: I am not complaining.  In
> particular, I am not complaining about clang: I switched to using clang
> for the system-build compiler shortly after BSDCan 2012, and I've never
> looked back.  I'm very happy to have an alternative to gcc.
> 
> Yesterday, I had built r251096M; this morning, I updated to r251113M
> and rebuilt with "touch /sys/conf/newvers.sh && make -j4 -DNOCLEAN
> buildworld".  (Copy of typescript file available at
> .)
> 
> As shown in the typescript, the sole change showed up as:
> 
> Script started on Thu May 30 04:22:12 2013
> svn update /usr/src
> Updating '/usr/src':
> U/usr/src/usr.sbin/newsyslog/newsyslog.c
> Updated to revision 251129.
> 
> Script done on Thu May 30 04:22:18 2013
> 
> 
> which would seem to have had minimal effect on the toolchain.
> 
> Yet the vast bulk of the above-cited typescript appears to be showing
> the toolchain being rebuilt.  Is this intended?

It is not really intended, but an unfortunate side effect of
.  When you touch
sys/conf/newvers.sh, it causes include/Makefile to generate a new
osreldate.h, so everything depending on that header will be rebuilt.

And r250217 introduced a dependency of the llvm config.h file on
osreldate.h, to determine whether log2() is available (and so make it
possible to build head on older FreeBSD releases).

I am not sure if there is an easy way around this.  When implementing
r250217, I considered various ways to detect at build time which host
system is used, but IIRC none of the alternatives were completely
bulletproof.

The only suggestion I can give at the moment is: don't touch
sys/conf/newvers.sh. :)  Why are you doing this anyway?

-Dimitry

___
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: Should "make -DNOCLEAN buildworld" always rebuild clang?

[Dimitry Andric]

On May 30, 2013, at 23:19, Dimitry Andric  wrote:
> On May 30, 2013, at 22:49, David Wolfskill  wrote:
>> As some of you may be aware, I track stable/9 daily.  (A recent history
>> of "uname -vp" outputs for stable/9 on my laptop may be seen at
>> <http://www.catwhisker.org/~david/FreeBSD/history/laptop_i386_9.txt>.)
>> 
>> And lest this message is misinterpreted: I am not complaining.  In
>> particular, I am not complaining about clang: I switched to using clang
>> for the system-build compiler shortly after BSDCan 2012, and I've never
>> looked back.  I'm very happy to have an alternative to gcc.
>> 
>> Yesterday, I had built r251096M; this morning, I updated to r251113M
>> and rebuilt with "touch /sys/conf/newvers.sh && make -j4 -DNOCLEAN
>> buildworld".  (Copy of typescript file available at
>> <http://www.catwhisker.org/~david/FreeBSD/stable_9/bw.txt>.)
>> 
>> As shown in the typescript, the sole change showed up as:
>> 
>> Script started on Thu May 30 04:22:12 2013
>> svn update /usr/src
>> Updating '/usr/src':
>> U/usr/src/usr.sbin/newsyslog/newsyslog.c
>> Updated to revision 251129.
>> 
>> Script done on Thu May 30 04:22:18 2013
>> 
>> 
>> which would seem to have had minimal effect on the toolchain.
>> 
>> Yet the vast bulk of the above-cited typescript appears to be showing
>> the toolchain being rebuilt.  Is this intended?
> 
> It is not really intended, but an unfortunate side effect of
> <http://svnweb.freebsd.org/changeset/base/250217>.  When you touch
> sys/conf/newvers.sh, it causes include/Makefile to generate a new
> osreldate.h, so everything depending on that header will be rebuilt.

Gah, never mind that...  I failed to notice you are building stable/9,
sorry.  In that case, I don't know exactly what is going on.  Obviously,
osreldate.h is being updated too, but I would not expect so much stuff
to be rebuilt because of it.

-Dimitry

___
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: strange stable/9 buildworld failure

[Dimitry Andric]

On Jul 11, 2013, at 19:19, Andriy Gapon  wrote:
> on 11/07/2013 19:43 Andriy Gapon said the following:
>> 
>> buildword was run as make -j8 buildworld and the it mysteriously failed like 
>> this:
>> 
>> sh /usr/src/tools/install.sh -s -o root -g wheel -m 444 liblwres.so.80
>> /usr/obj/usr/src/tmp/usr/lib
>> sh /usr/src/tools/install.sh -l s liblwres.so.80
>> /usr/obj/usr/src/tmp/usr/lib/liblwres.so
>> 1 error
>> *** [libraries] Error code 2
>> 
>> 
>> I could not find any actual error message in the build log.
>> /usr/obj was cleaned out before the build.
>> 
> 
> I was able to reproduce this exact failure 3 times in a row.
> Running buildworld without -j allowed the build to proceed further.
> Please note that my current userland is at (quite old) r248369, also stable/9.

Hi Andriy,

Can you please post the complete build log somewhere?  Maybe there is
something unexpected going wrong which does not show a clear error
message?

-Dimitry

___
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 looking all over for linux libs [9.2 PRERELEASE]

[Dimitry Andric]

On Jul 18, 2013, at 14:48, Kurt Lidl  wrote:
> On 7/17/13 5:33 PM, Roman Divacky wrote:
>> Yes, this is because the FreeBSD driver toolchain shares the same
>> infrastructure with Linux. So we stat ~200 linux dirs :(
>> 
>> This rys.vlakno.cz/~rdivacky/freebsd-driver.patch proof of concept
>> patch fixes it by unsharing FreeBSD from Linux but I am not
>> convinced it's worth it.
>> 
>> It should also be possible to only stat those libs when -m32/-m64
>> is specified. That would be the preferred solution.
>> 
>> Roman
> 
> Thanks for that patch, but when applied to the 9.2-PRERELEASE
> clang tree, a buildworld fails like this:
> 
> building static c library
> ranlib libc.a
> building shared library libc.so.7
> /usr/bin/ld: this linker was not configured to use sysroots
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> *** [libc.so.7] Error code 1
> 1 error
> *** [lib/libc__L] Error code 2
> 1 error
> *** [libraries] Error code 2
> 1 error
> *** [_libraries] Error code 2
> 1 error
> *** [buildworld] Error code 2
> 1 error

I'm not sure what goes wrong here, but please take the problem upstream,
instead of using local patches.  We want less of those, not more. :-)

In any case, the probability of such a change making it into 9.2 is very
small, since it is in no way critical.  Apparently clang has been doing
this for years, and you are the first one to notice...

-Dimitry

___
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: stable/8 kernel-toolchain fails with clang on head

[Dimitry Andric]

On Aug 23, 2013, at 14:16, Andriy Gapon  wrote:
> $ /usr/obj/usr/devel/svn/base/stable/8/make.amd64/make kernel-toolchain
> WITHOUT_CLANG=1 __MAKE_CONF=/dev/null SRCCONF=/dev/null
...
> It seems that the problem is specific to stable/8 and is caused by missing
> -std=gnu89.  And that seems to be caused by -DNO_WARNS that is used for
> toolchain target.
> Dependency between NO_WARNS and CSTD was removed in r198335 + r198365, but 
> those
> were never MFC-ed.
> 
> What do you think?

Yes, I agree those should be MFC'd to stable/8.

-Dimitry

___
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 -fprofile-generate

[Dimitry Andric]

On Sep 2, 2013, at 21:40, Tijl Coosemans  wrote:
> I was trying to build multimedia/x264 using clang as follows:
> In the Makefile remove USE_GCC=any.
> In option dialog on leave PGO on.
> 
> It ends in the following linker error:
> 
> cc -o x264  x264.o input/input.o input/timecode.o input/raw.o input/y4m.o 
> output/raw.o output/matroska.o output/matroska_ebml.o output/flv.o 
> output/flv_bytestream.o filters/filters.o filters/video/video.o 
> filters/video/source.o filters/video/internal.o filters/video/resize.o 
> filters/video/cache.o filters/video/fix_vfr_pts.o 
> filters/video/select_every.o filters/video/crop.o filters/video/depth.o 
> input/thread.o libx264.a  -m32  -fstack-protector  -fstack-protector 
> -L/usr/local/lib -lm -pthread -fprofile-generate
> /usr/bin/ld: /usr/bin/../lib/libprofile_rt.a: No such file: No such file or 
> directory
> cc: error: linker command failed with exit code 1 (use -v to see invocation)
> 
> Isn't libprofile_rt.a included with the base system llvm?


Nope, not currently.  Last time I tried building it, it didn't yet work
properly.  The library gets used in at link time, but I don't see where
any entry point to it gets called.

I did not have time yet to take a deeper look at it.  For now, profile
generation should be disabled for x264.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: i386 clang optimisation problem with stack alignment

[Dimitry Andric]

On Sep 10, 2013, at 18:34, Tijl Coosemans  wrote:
> On Tue, 10 Sep 2013 18:16:01 +0200 Tijl Coosemans wrote:
>> I've attached a small test program extracted from multimedia/gstreamer-ffmpeg
>> (libavcodec/h264_cabac.c:ff_h264_init_cabac_states(H264Context *h)).
>> 
>> When you compile and run it like this on FreeBSD/i386, it results in a
>> SIGBUS:
>> 
>> % cc -o paddd paddd.c -O3 -msse2 -fPIE -fomit-frame-pointer 
>> % ./paddd
>> Bus error
>> 
>> The reason is this instruction where %esp isn't 16-byte aligned:
>> paddd   (%esp), %xmm7

Hmm, as far as I can see, the problem is related to position independent code, 
in combination with omitting the frame pointer:

$ cc -o paddd paddd.c -O3 -msse2 -fomit-frame-pointer
$ ./paddd
$ 

$ cc -o paddd paddd.c -O3 -msse2 -fPIE -fomit-frame-pointer
$ ./paddd
Bus error (core dumped)
$ 

$ cc -o paddd paddd.c -O3 -msse2 -fPIE -fno-omit-frame-pointer
$ ./paddd
$ 


>> Is this an upstream bug or is this because of local changes (to make the
>> stack 4 byte aligned by default or something)?

The 4 byte alignment on i386 changes are from upstream, but we initiated them 
after a bit of discussion (see 
http://llvm.org/viewvc/llvm-project?view=revision&revision=167632 ).

Note the problem only occurs at -O3, which enables the vectorizer, so there 
might an issue with it in combination with position independent code generation 
and omitting frame pointers.  If you check what clang passes to its cc1 stage 
with your original command line, it gives:

"/usr/bin/cc" -cc1 -triple i386-unknown-freebsd10.0 -emit-obj -disable-free 
-main-file-name paddd.c -mrelocation-model pic -pic-level 2 -pie-level 2 
-masm-verbose -mconstructor-aliases -target-cpu i486 -target-feature +sse2 -v 
-resource-dir /usr/bin/../lib/clang/3.3 -O3 -fdebug-compilation-dir 
/home/dim/bugs/paddd -ferror-limit 19 -fmessage-length 130 -mstackrealign 
-fobjc-runtime=gnustep -fobjc-default-synthesize-properties 
-fdiagnostics-show-option -fcolor-diagnostics -backend-option -vectorize-loops 
-o /tmp/paddd-zdRbKM.o -x c paddd.c

So it does pass -mstackrealign, but for some reason it isn't always effective.  
For the -fPIE -fomit-frame-pointer case, the prolog for init_states() becomes :

init_states:# @init_states
# BB#0: # %vector.ph
pushl   %ebp
pushl   %ebx
pushl   %edi
pushl   %esi
subl$28, %esp
calll   .L0$pb
.L0$pb:
popl%edx

If you remove -fPIE, the data is directly accessed via its (properly 16 byte 
aligned) symbol, so there is no alignment problem:

paddd   .LCPI0_0, %xmm7

but the stack is not realigned in the prolog either:

init_states:# @init_states
# BB#0: # %vector.ph
pushl   %ebx
pushl   %edi
pushl   %esi
movd16(%esp), %xmm0
...

Then, if you use -fPIE, but add -fno-omit-frame-pointer:

init_states:# @init_states
# BB#0: # %vector.ph
pushl   %ebp
movl%esp, %ebp
pushl   %ebx
pushl   %edi
pushl   %esi
andl$-16, %esp
subl$48, %esp
calll   .L0$pb
.L0$pb:
popl%edx
.Ltmp0:

E.g., here the stack is properly realigned, and the function works fine.

In any case: yes, I think this is a bug, and we should report it upstream.  
This is a very nice test case to do so.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: gcc failing for mips cross-compile

[Dimitry Andric]

On Sep 27, 2013, at 22:07, hiren panchasara  wrote:
...
>> So, following worked:
>> sudo make TARGET=mips TARGET_ARCH=mipseb TARGET_CPUARCH=mips toolchain
>> 
>> What does that mean?
>> 
>> how do I get/know 32bit mips setup?

Reading https://wiki.freebsd.org/FreeBSD/BuildingMIPS , it seems just
"mips" means 32-bit big-endian, using the old ABI.  If you want the new
ABI, use "mipsn32" instead.

I have just tried "make TARGET=mips toolchain", and that seemed to work
fine.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: clang sanitizers (memory, address, etc)

[Dimitry Andric]

On Oct 22, 2013, at 15:05, sq...@peralex.com wrote:
> I'm running current, and I've managed to compile, but not link some code
> using -sanitizer=memory.  The linker is missing some symbols
> (__msan_memcpy and others), and I can't find the appropriate library.
> I've found no mention of anybody using the sanitizers on FreeBSD though.
> 
> Are those symbols available for FreeBSD, and if so, what library are
> they in?  Or are the sanitizers only available for Linux?

The sanitizers have not yet been ported, and while I have heard that
some work was done, there is no coordinated effort yet.  This is one of
the many items on my todo-lists, but other things came first...

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: make xdev broken

[Dimitry Andric]

On 17 Nov 2013, at 20:37, Warner Losh  wrote:
> In 9.2 stable on amd64, make xdev is broken.
> 
> sudo make xdev XDEV=i386 XDEV_ARCH=i386
> 
> terminates with
> 
> In file included from 
> /imp/svn/stable/9/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/lib/Analysis/CFG.cpp:17:
> /imp/svn/stable/9/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/AST/Attr.h:
>  In static member function 'static bool 
> clang::MSInheritanceAttr::classof(const clang::Attr*)':
> /imp/svn/stable/9/lib/clang/libclanganalysis/../../../contrib/llvm/tools/clang/include/clang/AST/Attr.h:148:
>  error: 'LAST_MS_INHERITABLE' is not a member of 'clang::attr'
> 
> what's up with that? Any ideas on how to fix this?

Was it ever supposed to work?  As far as I can see in Makefile.inc1, it
is only supposed to build binutils and gcc, but nothing clang-related.

In any case, to build clang, you also need to build tblgen and
clang-tblgen as bootstrap tools, otherwise you might end up with
incorrectly generated .inc files.  This is most likely the cause of the
errors you list above.

If the only purpose of xdev is to build binutils and gcc, the easiest
solution is probably to exclude the clang libraries from the
_xi-libraries target, for example by setting WITHOUT_CLANG to a
non-empty value.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: clang++ 3.3 issue (excessively slow compile vs. gcc 4.6 in just one file of a port)

[Dimitry Andric]

On 18 Nov 2013, at 22:20, Matthias Andree  wrote:
> [Please keep me in Cc:, I am not subscribed.]
> 
> Greetings,
> 
> I have recently spent some efforts getting rawtherapee to compile on
> 10-stable.  I think I succeeded, and came across something I find worth
> investigating.
> 
> For just one of rawtherapee's files, clang++ 3.3's compile time is
> excessively long, compared both to the other files, as well as against
> gcc 4.6.
> 
> System: FreeBSD 10.0-BETA3 #1 r258178: Fri Nov 15 20:00:11 CET 2013
> toor@vmf10:/usr/obj/usr/src/sys/GENERIC
> 
> Compiler: FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
> Target: x86_64-unknown-freebsd10.0
> Thread model: posix
> 
> The port as it currently stands hacks the cmake-generated build.make to
> compile ipsharpen.cc with only -O1 option.  If I remove that patch, so
> that the port compiles with -O2 or -O3, compiling that single file takes
> too long for me to wait for it, in excess of 10 minutes, on my 2.5 GHz
> AMD Phenom II X4.  GCC 4.6 does not exhibit such behaviour.
> 
> I have not yet isolated what might cause this, how would I best go about
> that so we can pin this issue and possibly fix clang++?

In general, first try to reproduce it with top-of-tree clang.  If it
does not occur there, the problem was fixed in the mean time, so the
next question is which revision(s) fixed it, and if it is easy to import
the fix on top of 3.3 release.  This is usually done through bisection.

If it also occurs with top-of-tree clang, either post a preprocessed
file (.ii) to llvm.org's bugzilla, with the used optimization flags, or
attempt to minimize the testcase yourself.

I will have a look at the port meanwhile, I hope it does not pull in too
many dependencies?

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: clang++ 3.3 issue (excessively slow compile vs. gcc 4.6 in just one file of a port)

[Dimitry Andric]

On 18 Nov 2013, at 23:25, Matthias Andree  wrote:
> Am 18.11.2013 23:04, schrieb Dimitry Andric:
> 
>> I will have a look at the port meanwhile, I hope it does not pull in too
>> many dependencies?
> 
> Thanks for the prompt response. Trying top-of-clang-tree will take me a
> few days until I get around to it (is clang-devel good enough for a
> first attempt?)

Can you please run the ipsharpen.cc compilation command with -save-temps
added on your system, and then upload the resulting .ii file somewhere?

That would save me the trouble of building most of GNOME, which it seems
to pull in... :)


> (Oh, and I wish we had more prominent error messages telling about an
> ABI mismatch between libc++ and libstdc++ than just the innocuous
> undefined references about - roughly -
> Glib::ustring::ustring(std::basic_string<> const &) - I needed to nm -sC
> the glibmm-2.0.so to figure out it provided the std::_1:: namespace
> stuff for c++ and finally figure out the libraries were alright but they
> were using the libc++ ABI rather than GCC's libstdc++.)

Most of the time, you will only find out at link time if you have mixed
libstdc++ and libc++ STL containers...  I'm not sure if there is a nicer
way to bring bad news. :-)

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: clang++ 3.3 issue (excessively slow compile vs. gcc 4.6 in just one file of a port)

[Dimitry Andric]

On 18 Nov 2013, at 23:54, Matthias Andree  wrote:
...
> Uploaded. http://people.freebsd.org/~mandree/ has:
> 
> : the xzipped .ii
> file (unpacked: 6.5 MB)
> 
> :
> compiler command line (make VERBOSE=1 MAKE_JOBS_UNSAFE=yes)
> and early warnings.

Ok, this looks like http://llvm.org/PR16474 , which has a relatively
simple fix.  I have attached it, can you please try it out?  You can
just apply the patch to /usr/src and do:

make -C /usr/src/lib/clang
make -C /usr/src/usr.bin/clang/clang
sudo make -C /usr/src/usr.bin/clang/clang install

It should basically recompile just one file, and re-link the clang
executable.  I tried building ipsharpen.ii at -O3, and it uses about
20 seconds now (on my relatively slow VM).

-Dimitry



import-llvm-r191896-1.diff
Description: Binary data



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: clang++ 3.3 issue (excessively slow compile vs. gcc 4.6 in just one file of a port)

[Dimitry Andric]

On 19 Nov 2013, at 09:10, Matthias Andree  wrote:
> Am 19.11.2013 08:49, schrieb Dimitry Andric:
...
>> Ok, this looks like http://llvm.org/PR16474 , which has a relatively
>> simple fix.  I have attached it, can you please try it out?  You can
>> just apply the patch to /usr/src and do:
>> 
>> make -C /usr/src/lib/clang
>> make -C /usr/src/usr.bin/clang/clang
>> sudo make -C /usr/src/usr.bin/clang/clang install
>> 
>> It should basically recompile just one file, and re-link the clang
>> executable.  I tried building ipsharpen.ii at -O3, and it uses about
>> 20 seconds now (on my relatively slow VM).
> 
> Dimitry,
> 
> thanks.
> 
> The patch speeds up the compile by one and a half orders of magnitude,
> and we're down to 30 s for my VM and compiling the .ii file.
> 
> The .cc now compiles in 22 s, rather than 500 s.
> 
> Excellent, problem solved!
> 
> Can we commit this (what the LLVM PR calls "regression") fix so it
> becomes part of 10.0-RELEASE?

I will commit it to head tonight, and after the normal MFC period of 3
days I will ask re@ to approve merging it to stable/10.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: clang++ 3.3 issue (excessively slow compile vs. gcc 4.6 in just one file of a port)

[Dimitry Andric]

On 19 Nov 2013, at 11:27, Dimitry Andric  wrote:
> On 19 Nov 2013, at 09:10, Matthias Andree  wrote:
>> Am 19.11.2013 08:49, schrieb Dimitry Andric:
> ...
>>> Ok, this looks like http://llvm.org/PR16474 , which has a relatively
>>> simple fix.
...
>> Excellent, problem solved!
>> 
>> Can we commit this (what the LLVM PR calls "regression") fix so it
>> becomes part of 10.0-RELEASE?
> 
> I will commit it to head tonight, and after the normal MFC period of 3
> days I will ask re@ to approve merging it to stable/10.

Fix committed as r258350.  This will probably make it into 10.0.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

[CFT] Update to clang 3.4

[Dimitry Andric]

Hi,

I have almost completed the preliminary work to import clang 3.4 into
FreeBSD 11-CURRENT.  The official clang 3.4 release has not yet been
announced, but I do not expect any more changes from upstream for now.

However, since this version introduces a bunch of new warnings, and a
more strict options parser, I would like to call for some additional
testing by anyone who is interested.

Specifically, the following:
* Building and installing world with non-standard settings in make.conf
  and/or src.conf.
* Compiling your favorite set of ports.  (I will request a ports
  exp-run too).
* Fixing any kernel source with LINT that has not yet been fixed.  (I
  am still working on some of the things that are not in GENERIC.)
* Any other problems you may encounter with optimization,
  incompatibilities, and so on.

One thing to look out for, in particular with ports, is the more strict
option parsing introduced with clang 3.4.  In earlier releases, unknown
or unsupported command line options were ignored, with just a "argument
unused during compilation" warning.  From 3.4 onwards, such options will
result in a "unknown argument" error.

Another important new issue is that clang 3.4 now outputs DWARF4 as
default format when using -g.  Our ancient version of gdb in base does
not support this, so you must either install the gdb port, or build lldb
and use it (very experimental at this time!).

Moreover, our CTF tools such as ctfconvert use a quite old version of
libdwarf in our base system, which also does not support DWARF4.  So
ctfconvert processing of kernel objects doe not work at the moment.  Any
assistance with solving this (for example, by importing the most recent
libdwarf from upstream) is greatly appreciated.

The current patch, which can be applied to head r260112 or later, is
located here:

  http://www.andric.com/freebsd/clang/head-r260112-clang34-1.diff.xz

  SHA256 (head-r260112-clang34-1.diff.xz) = 
1b5735946526fe97f0cea1822ecbcc3ec86f15282277aef7e3d7b2835a777b11

To apply, unxz the file into a fresh head checkout, and run:

  svn patch head-r260112-clang34-1.diff

Please check carefully if Subversion reports no problems during
patching, as it is rather fragile.  Afterwards, you can do a normal
world and kernel build, and installation.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [CFT] Update to clang 3.4

[Dimitry Andric]

On 01 Jan 2014, at 23:37, Warner Losh  wrote:
> I'd add to the list the upgrade path (from 9.x, 10.x and current) as well, 
> just to make sure they all still work... If there are problems with the 9.x 
> upgrade path, we'll need to call them out since 10.0 hasn't been released yet 
> and there's still a lot of 9.x boxes in the wild...

Ah yes, I already found one issue when building head on 9-STABLE:

In file included from contrib/llvm/lib/Support/Signals.cpp:30:
contrib/llvm/lib/Support/Unix/Signals.inc:22:11: fatal error: 'execinfo.h' file 
not found
# include  // For backtrace().
  ^

This is of course a detection from autoconf which finds execinfo.h on
-current.  So I will need to make that __FreeBSD_version dependent.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [CFT] Update to clang 3.4

[Dimitry Andric]

On 02 Jan 2014, at 01:11, Dimitry Andric  wrote:
> On 01 Jan 2014, at 23:37, Warner Losh  wrote:
>> I'd add to the list the upgrade path (from 9.x, 10.x and current) as well, 
>> just to make sure they all still work... If there are problems with the 9.x 
>> upgrade path, we'll need to call them out since 10.0 hasn't been released 
>> yet and there's still a lot of 9.x boxes in the wild...
> 
> Ah yes, I already found one issue when building head on 9-STABLE:
> 
> In file included from contrib/llvm/lib/Support/Signals.cpp:30:
> contrib/llvm/lib/Support/Unix/Signals.inc:22:11: fatal error: 'execinfo.h' 
> file not found
> # include  // For backtrace().
>  ^
> 
> This is of course a detection from autoconf which finds execinfo.h on
> -current.  So I will need to make that __FreeBSD_version dependent.

I have fixed this particular problem, new patch is here:

http://www.andric.com/freebsd/clang/head-r260112-clang34-2.diff.xz
SHA256 (head-r260112-clang34-2.diff.xz) = 
4c602b42e890f82cbf5f7ee4aecb91a77ce3dcaacc01c210953e1cdd29d1ac21

This will only use execinfo.h and backtrace() for the world stage of the
build, when the libraries that supply them have already been built.

With this diff, I have successfully built head on 9.2-STABLE with gcc as
the base compiler.  I will also test it on 10.0-RC4, but I foresee no
problems there.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [CFT] Update to clang 3.4

[Dimitry Andric]

On 02 Jan 2014, at 22:36, Dimitry Andric  wrote:
> On 02 Jan 2014, at 01:11, Dimitry Andric  wrote:
>> On 01 Jan 2014, at 23:37, Warner Losh  wrote:
>>> I'd add to the list the upgrade path (from 9.x, 10.x and current) as well, 
>>> just to make sure they all still work... If there are problems with the 9.x 
>>> upgrade path, we'll need to call them out since 10.0 hasn't been released 
>>> yet and there's still a lot of 9.x boxes in the wild...
...
> With this diff, I have successfully built head on 9.2-STABLE with gcc as
> the base compiler.  I will also test it on 10.0-RC4, but I foresee no
> problems there.

Rebased against head r260207, since sys/amd64/vmm/intel/vmx.c did not
need patching anymore:

http://www.andric.com/freebsd/clang/head-r260207-clang34-1.diff.xz
SHA256 (head-r260207-clang34-1.diff.xz) = 
02ddf89b5173bb1dac1e18e529b146ba5882f5ae6cb9c3527ef4eb514e17dd3c

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [CFT] Update to clang 3.4

[Dimitry Andric]

On 05 Jan 2014, at 13:06, Ed Schouten  wrote:
> 2014/1/1 Dimitry Andric :
>> Another important new issue is that clang 3.4 now outputs DWARF4 as
>> default format when using -g.  Our ancient version of gdb in base does
>> not support this, so you must either install the gdb port, or build lldb
>> and use it (very experimental at this time!).
> 
> Would it make sense to just change our copy of Clang to emit DWARF2
> when using -g? People expect that -g emits something that can be used
> by our shipped version of gdb.

There are multiple problems with that: first of all, it changes the
upstream defaults, which I am very reluctant to do.  Upstream actually
wants to get rid of older DWARF support, since that makes their code
needlessly complicated, and the rest of the world has long since moved
on to newer DWARF versions.  Even gcc defaults to DWARF4 now.

Second, the shipped version of gdb in our tree is very old, and is
basically unmaintained.  Nobody in their right mind should ever use it
for debugging, unless they have no other choice.  As soon as the in-tree
version of lldb is in workable state, we should get rid of the base gdb.

I think the only tricky task left is our custom kgdb hacks, which must
be ported to some newer version of gdb soon, or preferably to lldb.  I
have no idea if anybody is working on those.

Last but not least, I can build a kernel with -gdwarf-2, but ctfconvert
and/or ctfmerge still have some trouble correctly converting and/or
merging the debug information to CTF.  So there is something broken in
either the DWARF2 output, or there is a problem in ctfconvert and
ctfmerge.

I need some assistance with this, from somebody who knows exactly how
CTF and DTrace work together.  Our CTF tools use libdwarf in base, which
is also quite old, and seems to be largely unmaintained.  It does not
seem to support anything beyond DWARF2.  I think it would be worthwhile
to upgrade this library from upstream ASAP.

-Dimitry



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [CFT] Update to clang 3.4

[Dimitry Andric]

On 12 Jan 2014, at 13:12, Yamaya Takashi  wrote:
> buildworld is failed when WITH_LLDB=

Yes, this is a known issue. I discussed it with Ed Maste.  Clang 3.4
will have to be imported first, afterwards we can fix lldb.  


> some ports cannot build.
> 
> reason1: clang cannot handle some options.
> (libmad build)
> cc: error: unknown argument: '-fforce-addr'
> cc: error: unknown argument: '-fthread-jumps'
> cc: error: unknown argument: '-fcse-follow-jumps'
> cc: error: unknown argument: '-fcse-skip-blocks'
> cc: error: unknown argument: '-fregmove'
> cc: error: unknown argument: '-fschedule-insns2'
> (libtheora build)
> cc: error: unknown argument: '-fforce-addr'
> (poppler build)
> c++: error: unknown argument: '-fno-check-new'
> (py27-sqlite build)
> cc: error: unknown argument: '-R/usr/local/lib'
> (tbb build)
> c++: error: unknown argument: '-fno-schedule-insns2'
> (gstreamer-ffmpeg build)
> cc: error: unknown argument: '-fno-force-addr'

Indeed, this is likely the most troublesome aspect of the upgrade.

Most of the above options, like "-fcse-follow-jumps", "-fno-check-new",
etc are gcc-specific, and will never be supported by clang.  These
options will have to be removed, or made conditional on the compiler.

The -R option is not a compiler option, but an ld option, and is also
ambiguous: ld interprets it as --just-symbols when it is followed by the
name of a file, but as -rpath when it is followed by the name of a
directory.  In all cases, this should be replaced with -Wl,-rpath.


> reason2: c++ -std=c++11 detect bad c++ code which older clang cannot detect.
> (libproxy build)
> /usr/ports/net/libproxy/work/libproxy-0.4.6/libproxy/modules/wpad_dns_alias.cpp:30:23:
> error: cannot initialize return object of type 'libproxy::url *' with an
> rvalue of type 'bool'
>if (lasturl) return false;
>^
> (liveMedia build)

I have not looked in detail at this one, but this looks like a simple
bug.  The code should not return a boolean when the return type of the
function is a libproxy::url pointer.  Should be easy to fix.

The new C++11 rules make it possible to avoid 'casting' a false value to
a NULL pointer, and clang 3.4 detects this.


> c++ -c -Iinclude -I../UsageEnvironment/include -I../groupsock/include
> -I. -DBSD=1 -DSOCKLEN_T=socklen_t -D_LARGEFILE_SOURCE=1
> -D_FILE_OFFSET_BITS=64 -DHAVE_SOCKADDR_LEN=1 -Wall -DBSD=1  -O2 -pipe
> -Qunused-arguments -march=native -fPIC -fno-strict-aliasing -std=c++11
> -Wno-c++11-narrowing -stdlib=libc++ -Wno-deprecated RTSPRegisterSender.cpp
> RTSPClient.cpp:916:25: error: comparison between pointer and integer
> ('const char *' and 'int')
>  if (&line[paramIndex] == '\0') return False; // the header is assumed
> to be bad if it has no parameters
>  ~ ^  
> (mp4v2 build)

This looks like an incorrect comparison: a pointer is compared with a
literal character.  Should be easy to fix.


> c++ -DHAVE_CONFIG_H -I./include -I./include -I. -I. -Wall -Wformat -O2
> -pipe -Qunused-arguments -march=native -fno-strict-aliasing -std=c++11 
> -Wno-c++11-narrowing -stdlib=libc++ -fvisibility=hidden -c
> src/mp4container.cpp  -fPIC -DPIC -o src/.libs/mp4container.o
> src/mp4.cpp:679:20: error: cannot initialize return object of type
> 'mp4v2_ismacrypParams *' (aka 'mp4v2_ismacryp_session_params *') with an
> rvalue of type 'MP4TrackId' (aka 'unsigned int')
>return MP4_INVALID_TRACK_ID;
>   ^~~~
> ./include/mp4v2/general.h:45:33: note: expanded from macro
> 'MP4_INVALID_TRACK_ID'
> #define MP4_INVALID_TRACK_ID((MP4TrackId)0)   /**< Constant:
> invalid MP4TrackId. */
>^~~
> (thunderbird build)

Again, an attempt is made to use an incorrect type for the return value
of a function.  Either the value should be explicitly cast to the
correct type (mp4v2_ismacrypParams *), or the MP4_INVALID_TRACK_ID
define should be fixed to be of the correct type.


> clang++ -o jsoptparse.o -c  -I../../../dist/system_wrappers_js -include
> /usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src/config/gcc_hidden.h
> -DEXPORT_JS_API -DIMPL_MFBT -DMOZ_GLUE_IN_PROGRAM -DNO_NSPR_10_SUPPORT
> -I/usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src -I..
> -I/usr/ports/mail/thunderbird/work/comm-esr24/mozilla/js/src/shell -I.
> -I../../../dist/include  -I/usr/local/include/nspr   -fPIC
> -Qunused-arguments -isystem/usr/local/include  -Qunused-arguments -Wall
> -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits
> -Wempty-body -Werror=conversion-null -Wsign-compare
> -Wno-invalid-offsetof -Wno-c++0x-extensions -Wno-extended-offsetof
> -Wno-unknown-warning-option -Wno-return-type-c-linkage
> -Wno-mismatched-tags -O2 -pipe -Qunused-arguments -march=native -O3
> -fno-strict-aliasing -std=c++11 -Wno-c++11-narrowing -stdlib=libc++
> -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -pipe 
> -DNDEBUG