Re: GCC3.0 Produce REALLY slower code!
In article <[EMAIL PROTECTED]> you write: > Then there's the other question: Why should we test a compiler that > seems to be quite proprietary? Apart from questions of optimization, compiling the same code with two different compilers is a very good way to find bugs, both in the code and in the compilers. Besides, the kernel is, for now, dependent on many gcc features; but it might be worth thinking about writing code a bit more "standard", just in case another free C compiler emerges on some specific arch. Then again, aiming at compiling with several compilers is one way to achieve portability. (yet I do not believe it will happen anyday soon) --Thomas Pornin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GCC3.0 Produce REALLY slower code!
In article <[EMAIL PROTECTED]> you write:
> All bench i did, it's slower about 3/5% depending on the kind of code.
On Alpha machines (ev4 and ev56), it seems actually to be the opposite
on integer calculation: gcc-3.0 produces code up to 5% faster than
gcc-2.95.2. The result is still 25% behind the Compaq C compiler,
though.
By the way, the installation procedure is mostly buggy on old Alpha
systems (RedHat 5.1 -> binutils 2.9, glibc 2.0.7). I do not mind gcc
having some requirements about versions of such other tools, but it
could be made a bit more explicit, and the configuration script should
also emit some warnings (it detects the versions installed, it just does
not bother reporting the potential problem).
--Thomas Pornin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
In article <01a401c0f46b$20b932e0$480e6c42@almlba4sy7xn6x> you write:
> -- Getting rid of old code can help simplify the kernel. This means less
> chance of bugs.
Actually, what you suggest is simply getting rid of users. It would
sure simplify things greatly.
Are you nihilist ?
--Thomas Pornin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Children first in fork
In article <9bn90l$anp$[EMAIL PROTECTED]> you write:
> You're probably even better off just intercepting the fork, turning it
> into a clone, and setting the CLONE_PTRACE option.
Actually it is not that simple. The child process will be traced by its
father, not the tracing program. The father must detach from its child
in order to allow the tracing program to attach to the child, and then
you have again the race condition: the child will be untraced for some
time.
The trick is to modify the return address of the call so that the child
and the father loop on the syscall. This way, you can make the father:
-- modify the child so that the child will send itself a SIGSTOP when
released
-- detach itself from the child
(-- if the child is scheduled, it stops itself)
Then the tracing process can attach to the child and handle the
situation.
I have some code almost running, doing that. Well, it works, but with
strange bugs in some occasions. I am still sorting these out. It is
utterly tricky, anyway.
--Thomas Pornin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: quicksort for linked list
In article <[EMAIL PROTECTED]> you write:
> Quicksort however is an algorithm that is recursive. This means that
> it can use unbounded amounts of stack -> This is not for the kernel.
Maybe a heapsort, then. It is guaranteed O(n*log n), even for worst
case, and non-recursive. Yet it implies a significantly larger amount of
comparisons than quicksort (about twice, I think).
Insertion sort will be better anyway for small sets of data (for 5 or
less elements).
--Thomas Pornin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Compatibility issue with 2.2.19pre7
In article <[EMAIL PROTECTED]> you write:
> I know this code has undefined behaviour at _runtime_. But I thought
> you were obliged to allow it to compile. That was my only point.
There is no distinction between compilation and runtime in the standard.
Actually, C could be interpreted, or a very smart compiler could also
think real hard and replace the whole program by an equivalent printf().
Besides, a standard (C99) compiler will reject the 'main' definition.
At least, the return type cannot be implicit anymore.
--Thomas Pornin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Extraneous whitespace removal?
In article <[EMAIL PROTECTED]> you write: > - I'm not yet positive there are no other places in the tree that >aren't safe to s/[]+$//. C can, if formated poorly >enough, be affected by it (multiline strings not ending with \). Multiline strings not ending with \, are errors. gcc admits this syntax but it is bad practice, and should be avoided. For Makefile, DocBook, TeX and assembly, this should be ok too. --Thomas Pornin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: mount and 2.2.18
In article <[EMAIL PROTECTED]> you write:
> Is this harmless or do I need the latest mount?
The latest mount is needed only for NFSv3 support. As long as you do
only NFSv2, there is no problem (except the message, you will get it
once per mounting).
But NFSv3 is great; if your server is NFSv3 aware, I suggest you shift
your client to NFSv3 as well. It rocks.
--Thomas Pornin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: non-gcc linux?
In article <[EMAIL PROTECTED]> you write: > In short, I do not see any enforceable advantages to the current FSF > policies. As a sidenote, this transfer of intellectual property of code is not doable, according to French law (and other non-anglo-saxon countries). In France, the author of a an "intellectual production" cannot give away this authorship; all he can give is the ability to reproduce, reuse and redistribute his work. However, this intellectual property, which is eternal (it does not stop with the death of the author, and yet may not be transfered to other people even in such an occurence), is not bound by any scriptural glyph such as '(c)'. I can add '(c) Free Software Fundation' in all my source files, and they will remain mine. So, where I live, the point is moot. --Thomas Pornin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: non-gcc linux? (was Re: Where did kgcc go in 2.4.0-test10?)
In article <[EMAIL PROTECTED]> you write:
> There are two immediate reasons I can come up with for this:
I do not quite follow you on these two reasons. I daily work on an
Alpha machine, which runs under Linux, and I use the Compaq C compiler
since it gives better code on the applications I am developping (I am
a student in cryptography; I gain 30% speed on MD5 code, for instance,
compared to any version of gcc/egcs).
I think that some small parts of the kernel might take advantage of
the better code (/dev/urandom for instance) but, overall, this is not
critical.
However, using two different compilers is a great way to exhibit bugs.
I was told that some of the code in the kernel makes assumptions about
how gcc optimizes code, which on time to time leads to some problems
when a new version of gcc implements a different strategy. I am not
(yet) an optimizer god, therefore I will not comment any further on this
issue; but I think that it is sane practice, if one wants to remain on
the light side of the code (the one that is specified and does not rely
on not-very-well-documented features), to stress-test portability with
different sets of tools.
Anyway, among the points you talked about:
> 1. C++ style comments
Those ones are in C99. All modern compilers know them, or are doomed to
know them in near future since they are a requirement of the standard.
> 7. Macros with variable numbers of arguments
C99 knows them, with the following syntax: the macro is defined with an
ellipsis (...) as last argument, that represents all extra arguments
(possibly none). The arguments are accessed through the identifier
__VA_ARGS__, which contains all of them (with separating commas).
At least gcc-2.95.2 knows this syntax.
If one wants to build a Linux kernel with another compiler, I would
say that the more critical points are:
** inline assembly (must be almost completely rewritten for each new
compiler -- yuck)
** generalized lvalues (the result of a comma operator being a lvalue
if its last operand is a lvalue)
** compound statements (statement blocks inside expressions)
Other features are likely to be implemented in modern compilers, maybe
with a slightly different syntax, that could be adressed through macros,
or an enhanced preprocessing (put some perl script or smart C parser
between cpp and the compiler itself).
All this is only my opinion. But if I were to design a new OS kernel
right now, I would take special care to isolate and document extensions
as much as possible, so that I could ease portability and find bugs more
easily.
--Thomas Pornin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
