Re: the latest version of Clang/LLVM for the world and kernel
Excluding the build errors arising from code becoming incompatible with old
headers [1], the use of the latest version of Clang/LLVM for the world and
kernel is mostly hitch-free, if I
(1)remove, from the Clang installation, the headers that are already
available in /usr/include, ie.,
$ cd /home/me/my_compilers/lib/clang/3.3/include
$ rm float.h iso646.h limits.h tgmath.h and varargs.h
$ rm stdalign.h stdarg.h stdbool.h stddef.h stdint.h stdnoreturn.h
and
(2) replace -fformat-extensions with -Wno-error-format in sys/conf/kern.mk.
On 02/15/2013 16:57, Dimitry Andric wrote:
On 2013-02-15 14:26, deeptech71 wrote:
During ``make installworld'':
* btxld: Command not found.
I had to append not only ``btxld'', but also ``ls dd cp'', to the ITOOLS
variable in Makefile.inc1.
There are apparently several things that can trigger that btxld error,
but the usual one is that your system clock is out of whack. I have
never researched it too deeply; maybe somebody else can chip in here.
I did find my system clock out of whack, but I've already fixed that weeks
ago. I get the same error now. I don't recall getting the error when I was using the
compiler in ${WORLDTMP} [1].
Also, there are still some eye-popping warnings (-Warray-bounds,
-Wsizeof-pointer-memaccess, -Wuninitialized, -Wunsequenced) not apparently
fixed yet.
[1] http://lists.freebsd.org/pipermail/freebsd-current/2013-February/040160.html
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: the latest version of Clang/LLVM for the world and kernel
On 02/16/2013 17:17, Dimitry Andric wrote: On 2013-02-16 00:04, deeptech71 wrote: First of all, you should understand that these are compilation errors No, they are only errors because we have turned on -Werror. You meant to say: Yes, but they are only errors because we have turned on -Werror. Regarding this particular warning, it could be fixed by casting status to int, or adding -Wno-tautological-constant-out-of-range-compare to the flags for its WARNS= level (which is 2, if I looked it up correctly). I'd change the variable to an int. Second of all, you should understand that these are real errors; in this case, the compiler may omit generating code to check for a boolean condition, if the value of that condition is known at compile time, and thus generating a program with an undesired mode of operation. No, this is not the case with enums, unless you use the -fstrict-enums flag, which we don't use at the moment. And even with that flag, I did not see any change in the resulting assembly. This is probably because it would break too much software, if such an optimization was implemented, even if that optimization is strictly speaking completely legal to do. What makes you think that no semantic changes will occur in the future? What about other compilers? As the makefile comments say, some warnings are kept enabled to create an incentive to fix the code. But the real incentive should be that fixing the code makes the difference between WRONG and non-WRONG. * /usr/src/lib/libugidfw/ugidfw.c:74:10: error: comparison of unsigned expression 0 is always false [-Werror,-Wtautological-compare] * if (len 0 || len left) * ~~~ ^ ~ Normally, they are not errors, but just warnings, unless you changed something in the bsd.*.mk logic to not detect clang. WRONG. Clang detection measures are intact here: /etc/make.conf contains: CC=/dir1/clang CPP=/dir1/clang-cpp CXX=/dir1/clang++ TBLGEN=/dir1/clang-tblgen ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: the latest version of Clang/LLVM for the world and kernel
On 2013-02-16 00:04, deeptech71 wrote: ... Another purpose is development. Developers will have to import the next version of Clang/LLVM sooner or later. Let's hedge against the developer-time requirements in case the next version of Clang gets released just before a particular version of FreeBSD, and someone decides to update the base Clang, with only a couple of days of time at hand. :P FreeBSD has no control over when the llvm/clang projects do their releases. That said, the llvm/clang projects release roughly every 6 months, while FreeBSD is, shall we say, a little bit irregular. ;-) But as you say, any bugs or warnings that can be fixed now, without too much trouble, should be fixed, pending maintainer approval, and so on. * /usr/src/lib/libc/net/nss_compat.c:154:18: error: comparison of constant 16 with expression of type 'enum nss_status' is always true [-Werror,-Wtautological-constant-out-of-range-compare] * else if (status != NS_RETURN) * ~~ ^ ~ * /usr/src/lib/libc/net/nss_compat.c:255:18: error: comparison of constant 16 with expression of type 'enum nss_status' is always true [-Werror,-Wtautological-constant-out-of-range-compare] * else if (status != NS_RETURN) * ~~ ^ ~ These can safely be ignored. They are the result of a compability shim. It might be neater to just cast 'status' to int there, to silence the warning. First of all, you should understand that these are compilation errors (under an up-to-date version of Clang, at least), and that they should be fixed (sooner or later, that is), whether by altering the program code or the makefiles. No, they are only errors because we have turned on -Werror. For some parts of the tree, fixing the warnings is not worth the trouble, and for this we have the WARNS= setting in the Makefiles. Regarding this particular warning, it could be fixed by casting status to int, or adding -Wno-tautological-constant-out-of-range-compare to the flags for its WARNS= level (which is 2, if I looked it up correctly). Second of all, you should understand that these are real errors; in this case, the compiler may omit generating code to check for a boolean condition, if the value of that condition is known at compile time, and thus generating a program with an undesired mode of operation. No, this is not the case with enums, unless you use the -fstrict-enums flag, which we don't use at the moment. And even with that flag, I did not see any change in the resulting assembly. This is probably because it would break too much software, if such an optimization was implemented, even if that optimization is strictly speaking completely legal to do. Again, this particular piece of code was inserted for compatibility reasons, so casting the enum value to int is probably the cleanest way of fixing the warning. Finally, of course personally I can ignore these warnings (with whatever hack). However, as I said, I am not asking for support (ie., I do not say help me get this compiler working ! -- I understand that there is little consumer support for what I'm doing); instead, I am simply reporting issues to the committers. Well, thanks for the reports. A number of fixes has already made it into the tree. * /usr/src/lib/libsm/../../contrib/sendmail/libsm/test.c:110:7: error: promoted type 'int' of KR function parameter is not compatible with the parameter type 'bool' declared in a previous prototype [-Werror,-Wknr-promoted-parameter] Even excluding the fact that this is a compilation error (which can, for example, be silenced by passing appropriate flags to Clang), I doubt this should be just ignored. If a parameter is interpreted as an int inside the function definition, then all source files using the relevant function should also pass an int, not a bool (even if there is no difference on a particular architecture). So, for example, bool should be changed to int in the prototype/declaration; or bool should be typedefed/preprocessed to int; or something like that. This may be so, but sendmail is contributed software, and we cannot change too much things locally, or it will make it very hard to import future versions. It is up to upstream to decide whether they want to go through the trouble of fixing all their prototypes and definitions, not us. Also, these compilation errors are due to -Werror, which is normally suppressed when using clang for these particular sendmail components, specifically for these KR issues. The problem is that in earlier versions of clang, there was no specific -W option to disable this warning. Since both head and stable/9 now have 3.2, I think I can add support for -Wno-knr-promoted-parameter to the relevant bsd.*.mk file. * /usr/src/lib/libugidfw/ugidfw.c:74:10: error: comparison of unsigned expression 0 is always false [-Werror,-Wtautological-compare] * if (len 0 || len left) * ~~~ ^ ~
the latest version of Clang/LLVM for the world and kernel
In an effort to test out the latest version of Clang -- for supposedly
increased performance and less crashes --, I've checked out and compiled a
recent version Clang/LLVM (recompiled it with itself), compiled a new kernel
and world using WITHOUT_GCC=1 and WITHOUT_CLANG=1, installed them, removed
(almost) all remnants of the base GCC and base Clang binaries
(/usr/{libexec/cc1{|plus}|bin/c{c|pp|++|++filt|89|99}} -- that ``make
delete-old'' did not remove!) (keeping only the latest Clang installation), and
recompiled the kernel and world again. This whole process was very annoying,
not only due to compilation errors, but also due to makefile-related workings
that I learned via the hard way.
I'll describe the errors I've encountered, along with some workarounds I used
to get the compiling process to move on. I've also looked at the compiler
warnings, and noticed some frightening/valid ones. I expect committers to do
something about both the errors and, where appropriate, the warnings (which
perhaps means telling me what I did WRONG).
It was difficult to properly keep a record of all errors. That doesn't matter
much anyway, as I will re-test often to see if there are any errors and
suspicious warnings remaining.
Note that I haven't even begun testing portbuilding on this base-compiler-free
setup.
Logs are prefixed with ``* ''. Only slimmed logs are be posted here (fuller
logs, including invocation, etc. will be posted in a subsequent e-mail upon
request).
First come the compilation errors.
* /usr/src/lib/libc/net/nss_compat.c:154:18: error: comparison of constant 16
with expression of type 'enum nss_status' is always true
[-Werror,-Wtautological-constant-out-of-range-compare]
* else if (status != NS_RETURN)
* ~~ ^ ~
* /usr/src/lib/libc/net/nss_compat.c:255:18: error: comparison of constant 16
with expression of type 'enum nss_status' is always true
[-Werror,-Wtautological-constant-out-of-range-compare]
* else if (status != NS_RETURN)
* ~~ ^ ~
* /usr/src/lib/libsm/../../contrib/sendmail/libsm/test.c:110:7: error: promoted
type 'int' of KR function parameter is not compatible with the parameter type
'bool' declared in a previous prototype [-Werror,-Wknr-promoted-parameter]
* bool success;
* ^
* /usr/src/lib/libsm/../../contrib/sendmail/include/sm/test.h:38:7: note:
previous declaration is here
* bool _success,
* ^
* /usr/include/sys/cdefs.h:136:21: note: expanded from macro '__P'
* #define __P(protos) protos /* full-blown ANSI C */
* ^
In short, the last error above also applies to:
/usr/src/lib/libsm/../../contrib/sendmail/libsm/signal.c:264:7
/usr/src/lib/libsm/../../contrib/sendmail/libsm/sem.c:40:7
/usr/src/lib/libsm/../../contrib/sendmail/libsm/sem.c:224:9
/usr/src/lib/libsm/../../contrib/sendmail/libsm/sem.c:40:7
/usr/src/lib/libsm/../../contrib/sendmail/libsm/shm.c:45:7
/usr/src/lib/libsm/../../contrib/sendmail/include/sm/shm.h
/usr/src/lib/libsm/../../contrib/sendmail/libsm/shm.c:96:7
/usr/src/lib/libsm/../../contrib/sendmail/libsm/shm.c:127:9
/usr/src/libexec/mail.local/../../contrib/sendmail/mail.local/mail.local.c:439:7
/usr/src/libexec/smrsh/../../contrib/sendmail/smrsh/smrsh.c:117:7
* /usr/src/lib/libugidfw/ugidfw.c:74:10: error: comparison of unsigned expression
0 is always false [-Werror,-Wtautological-compare]
* if (len 0 || len left)
* ~~~ ^ ~
In short, the last error above is repeated numerous times for ``len 0''
expressions.
* /usr/src/sbin/fsck_ffs/pass1.c:141:17: error: comparison of unsigned
expression
*0 is always false [-Werror,-Wtautological-compare]
* if (inosused 0)
* ^ ~
* /usr/src/sbin/ifconfig/regdomain.c:350:25: error: comparison of constant
65535 with expression of type 'enum ISOCountryCode' is always false
[-Werror,-Wtautological-constant-out-of-range-compare]
* if (mt-country-code == NO_COUNTRY) {
* ~ ^ ~~
* /usr/src/sbin/routed/rtquery/rtquery.c:388:4: error: array index 1 is past
the end of the array (which contains 1 element) [-Werror,-Warray-bounds]
* OMSG.rip_nets[1] = OMSG.rip_nets[0];
* ^ ~
* /usr/src/sbin/routed/rtquery/rtquery.c:101:14: note: expanded from macro
'OMSG'
* #define OMSG omsg_buf.rip
* ^
* /usr/include/protocols/routed.h:110:6: note: array 'ru_nets' declared here
* struct netinfo ru_nets[1];
* ^
* /usr/src/sbin/routed/rtquery/rtquery.c:395:4: error: array index 1 is past
the end of the array (which contains 1 element) [-Werror,-Warray-bounds]
* OMSG.rip_nets[1] = OMSG.rip_nets[0];
* ^ ~
* /usr/src/sbin/routed/rtquery/rtquery.c:101:14: note: expanded from
Re: the latest version of Clang/LLVM for the world and kernel
On 2013-02-15 14:26, deeptech71 wrote:
In an effort to test out the latest version of Clang -- for supposedly
increased performance and less crashes --, I've checked out and compiled a
recent version Clang/LLVM (recompiled it with itself), compiled a new kernel
and world using WITHOUT_GCC=1 and WITHOUT_CLANG=1, installed them, removed
(almost) all remnants of the base GCC and base Clang binaries
(/usr/{libexec/cc1{|plus}|bin/c{c|pp|++|++filt|89|99}} -- that ``make
delete-old'' did not remove!) (keeping only the latest Clang installation), and
recompiled the kernel and world again. This whole process was very annoying,
not only due to compilation errors, but also due to makefile-related workings
that I learned via the hard way.
I'll describe the errors I've encountered, along with some workarounds I used
to get the compiling process to move on. I've also looked at the compiler
warnings, and noticed some frightening/valid ones. I expect committers to do
something about both the errors and, where appropriate, the warnings (which
perhaps means telling me what I did WRONG).
Sorry, but you are doing something that is totally unsupported.
Therefore, any broken pieces are yours to keep. :-)
First come the compilation errors.
* /usr/src/lib/libc/net/nss_compat.c:154:18: error: comparison of constant 16
with expression of type 'enum nss_status' is always true
[-Werror,-Wtautological-constant-out-of-range-compare]
* else if (status != NS_RETURN)
* ~~ ^ ~
* /usr/src/lib/libc/net/nss_compat.c:255:18: error: comparison of constant 16
with expression of type 'enum nss_status' is always true
[-Werror,-Wtautological-constant-out-of-range-compare]
* else if (status != NS_RETURN)
* ~~ ^ ~
These can safely be ignored. They are the result of a compability shim.
It might be neater to just cast 'status' to int there, to silence the
warning.
* /usr/src/lib/libsm/../../contrib/sendmail/libsm/test.c:110:7: error: promoted
type 'int' of KR function parameter is not compatible with the parameter type
'bool' declared in a previous prototype [-Werror,-Wknr-promoted-parameter]
* bool success;
* ^
* /usr/src/lib/libsm/../../contrib/sendmail/include/sm/test.h:38:7: note:
previous declaration is here
* bool _success,
* ^
* /usr/include/sys/cdefs.h:136:21: note: expanded from macro '__P'
* #define __P(protos) protos /* full-blown ANSI C */
* ^
In short, the last error above also applies to:
/usr/src/lib/libsm/../../contrib/sendmail/libsm/signal.c:264:7
/usr/src/lib/libsm/../../contrib/sendmail/libsm/sem.c:40:7
/usr/src/lib/libsm/../../contrib/sendmail/libsm/sem.c:224:9
/usr/src/lib/libsm/../../contrib/sendmail/libsm/sem.c:40:7
/usr/src/lib/libsm/../../contrib/sendmail/libsm/shm.c:45:7
/usr/src/lib/libsm/../../contrib/sendmail/include/sm/shm.h
/usr/src/lib/libsm/../../contrib/sendmail/libsm/shm.c:96:7
/usr/src/lib/libsm/../../contrib/sendmail/libsm/shm.c:127:9
/usr/src/libexec/mail.local/../../contrib/sendmail/mail.local/mail.local.c:439:7
/usr/src/libexec/smrsh/../../contrib/sendmail/smrsh/smrsh.c:117:7
These can also be safely ignored. This is a side effect of the KR
declarations still used in sendmail. It is every unlikely these will
ever go away, as sendmail is probably still supported on systems with
very old compilers which require KR.
* /usr/src/lib/libugidfw/ugidfw.c:74:10: error: comparison of unsigned expression
0 is always false [-Werror,-Wtautological-compare]
* if (len 0 || len left)
* ~~~ ^ ~
In short, the last error above is repeated numerous times for ``len 0''
expressions.
* /usr/src/sbin/fsck_ffs/pass1.c:141:17: error: comparison of unsigned
expression
*0 is always false [-Werror,-Wtautological-compare]
* if (inosused 0)
* ^ ~
Again, these can be safely ignored. These warnings really depend on the
type of variable, and if you cannot predict in advance whether the type
is signed or unsigned, it is too costly (too much churn) to fix them
all.
* /usr/src/sbin/ifconfig/regdomain.c:350:25: error: comparison of constant
65535 with expression of type 'enum ISOCountryCode' is always false
[-Werror,-Wtautological-constant-out-of-range-compare]
* if (mt-country-code == NO_COUNTRY) {
* ~ ^ ~~
This could be fixed by defining NO_COUNTRY as value in enum
ISOCountryCode, but that up to the maintainer. Another solution is to
cast mt-country-code to int.
* /usr/src/sbin/routed/rtquery/rtquery.c:388:4: error: array index 1 is past
the end of the array (which contains 1 element) [-Werror,-Warray-bounds]
* OMSG.rip_nets[1] = OMSG.rip_nets[0];
* ^ ~
* /usr/src/sbin/routed/rtquery/rtquery.c:101:14: note: expanded from
Re: the latest version of Clang/LLVM for the world and kernel
Dimitry Andric wrote this message on Fri, Feb 15, 2013 at 16:57 +0100: /usr/src/usr.sbin/wpa/wpa_passphrase/../../../contrib/wpa//src/crypto/md5-internal.c:191:30: note: did you mean to dereference the argument to 'sizeof' (and multiply it by the number of elements)? * os_memset(ctx, 0, sizeof(ctx)); /* In case it's sensitive */ * ^~~ There just has to be an organization behind these backdoors... No, this is just a very common error. The idiom is either: memset(object, 0, sizeof object); or memset(pointer, 0, sizeof *pointer); but apparently it is difficult to choose the right one. :) I assume you mean: memset(pointer, 0, sizeof *pointer); :) -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: the latest version of Clang/LLVM for the world and kernel
On 02/15/2013 16:57, Dimitry Andric wrote: On 2013-02-15 14:26, deeptech71 wrote: [...] an effort to test out the latest version of Clang [...] Sorry, but you are doing something that is totally unsupported. Therefore, any broken pieces are yours to keep. :-) Another purpose is development. Developers will have to import the next version of Clang/LLVM sooner or later. Let's hedge against the developer-time requirements in case the next version of Clang gets released just before a particular version of FreeBSD, and someone decides to update the base Clang, with only a couple of days of time at hand. :P First come the compilation errors. * /usr/src/lib/libc/net/nss_compat.c:154:18: error: comparison of constant 16 with expression of type 'enum nss_status' is always true [-Werror,-Wtautological-constant-out-of-range-compare] * else if (status != NS_RETURN) * ~~ ^ ~ * /usr/src/lib/libc/net/nss_compat.c:255:18: error: comparison of constant 16 with expression of type 'enum nss_status' is always true [-Werror,-Wtautological-constant-out-of-range-compare] * else if (status != NS_RETURN) * ~~ ^ ~ These can safely be ignored. They are the result of a compability shim. It might be neater to just cast 'status' to int there, to silence the warning. First of all, you should understand that these are compilation errors (under an up-to-date version of Clang, at least), and that they should be fixed (sooner or later, that is), whether by altering the program code or the makefiles. Second of all, you should understand that these are real errors; in this case, the compiler may omit generating code to check for a boolean condition, if the value of that condition is known at compile time, and thus generating a program with an undesired mode of operation. Finally, of course personally I can ignore these warnings (with whatever hack). However, as I said, I am not asking for support (ie., I do not say help me get this compiler working ! -- I understand that there is little consumer support for what I'm doing); instead, I am simply reporting issues to the committers. * /usr/src/lib/libsm/../../contrib/sendmail/libsm/test.c:110:7: error: promoted type 'int' of KR function parameter is not compatible with the parameter type 'bool' declared in a previous prototype [-Werror,-Wknr-promoted-parameter] * bool success; * ^ * /usr/src/lib/libsm/../../contrib/sendmail/include/sm/test.h:38:7: note: previous declaration is here * bool _success, * ^ * /usr/include/sys/cdefs.h:136:21: note: expanded from macro '__P' * #define __P(protos) protos /* full-blown ANSI C */ * ^ In short, the last error above also applies to: /usr/src/lib/libsm/../../contrib/sendmail/libsm/signal.c:264:7 /usr/src/lib/libsm/../../contrib/sendmail/libsm/sem.c:40:7 /usr/src/lib/libsm/../../contrib/sendmail/libsm/sem.c:224:9 /usr/src/lib/libsm/../../contrib/sendmail/libsm/sem.c:40:7 /usr/src/lib/libsm/../../contrib/sendmail/libsm/shm.c:45:7 /usr/src/lib/libsm/../../contrib/sendmail/include/sm/shm.h /usr/src/lib/libsm/../../contrib/sendmail/libsm/shm.c:96:7 /usr/src/lib/libsm/../../contrib/sendmail/libsm/shm.c:127:9 /usr/src/libexec/mail.local/../../contrib/sendmail/mail.local/mail.local.c:439:7 /usr/src/libexec/smrsh/../../contrib/sendmail/smrsh/smrsh.c:117:7 These can also be safely ignored. This is a side effect of the KR declarations still used in sendmail. It is every unlikely these will ever go away, as sendmail is probably still supported on systems with very old compilers which require KR. Even excluding the fact that this is a compilation error (which can, for example, be silenced by passing appropriate flags to Clang), I doubt this should be just ignored. If a parameter is interpreted as an int inside the function definition, then all source files using the relevant function should also pass an int, not a bool (even if there is no difference on a particular architecture). So, for example, bool should be changed to int in the prototype/declaration; or bool should be typedefed/preprocessed to int; or something like that. KR incompatibility warnings happen at: /usr/src/lib/libmilter/../../contrib/sendmail/libmilter/main.c:117:7 /usr/src/lib/libmilter/../../contrib/sendmail/libmilter/listener.c:63:7: /usr/src/lib/libmilter/../../contrib/sendmail/libmilter/listener.c:125:7: /usr/src/usr.bin/vacation/../../contrib/sendmail/vacation/vacation.c:503:7: 110 other KR warnings from source files in /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/ Can be ignored. ... * /usr/src/lib/libugidfw/ugidfw.c:74:10: error: comparison of unsigned expression 0 is always false [-Werror,-Wtautological-compare] * if (len 0 || len left) * ~~~ ^ ~ In short, the last error above is repeated numerous times for ``len 0'' expressions. *
