Apropos of the recent "older compilers" discussion,
the string literal concatenation pre-processor bug
that I mentioned encountering in gcc-3.3.x and
gcc-3.4.[0,1] appears to be fixed in gcc-3.4.3.
(It was not the well-known "##" token pasting
pre-processor bug, incidentally.)
I've only tested with glibc-2.2.5 so far,
but I could reproduce it before with both
glibc-2.2.5 and glibc-2.3.2, so it probably
really is fixed.
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
On Wed, Nov 10, 2004 at 04:40:10AM -0500, Clayton Weaver wrote:
> Apropos of the recent "older compilers" discussion,
> the string literal concatenation pre-processor bug
> that I mentioned encountering in gcc-3.3.x and
> gcc-3.4.[0,1] appears to be fixed in gcc-3.4.3.
> (It was not the well-known "##" token pasting
> pre-processor bug, incidentally.)
>
> I've only tested with glibc-2.2.5 so far,
> but I could reproduce it before with both
> glibc-2.2.5 and glibc-2.3.2, so it probably
> really is fixed.
1) What the hell does glibc version have to preprocessor behaviour?
2) Could you post the code (as small as possible) that triggers whatever
bug you are talking about? Not a "here's the fragment that gets miscompiled"
but something that could be fed to gcc and actually reproduce the bug.
Al Viro wrote:
> On Wed, Nov 10, 2004 at 04:40:10AM -0500, Clayton Weaver wrote:
>
>>Apropos of the recent "older compilers" discussion,
>>the string literal concatenation pre-processor bug
>>that I mentioned encountering in gcc-3.3.x and
>>gcc-3.4.[0,1] appears to be fixed in gcc-3.4.3.
>>(It was not the well-known "##" token pasting
>>pre-processor bug, incidentally.)
>>
>>I've only tested with glibc-2.2.5 so far,
>>but I could reproduce it before with both
>>glibc-2.2.5 and glibc-2.3.2, so it probably
>>really is fixed.
>
>
> 1) What the hell does glibc version have to preprocessor behaviour?
There is no claim that it has anything, it just looks like a nice
complete statement of the conditions of the test. I believe there were
some issues with another problem, but I don't remember details.
> 2) Could you post the code (as small as possible) that triggers whatever
> bug you are talking about? Not a "here's the fragment that gets miscompiled"
> but something that could be fed to gcc and actually reproduce the bug.
I'd like to see that as well, in case it's something I might have in
application code.
--
-bill davidsen ([email protected])
"The secret to procrastination is to put things off until the
last possible moment - but no longer" -me
Quick review:
Someone asked why the kernel included backward
compatibility code to accomodate older gcc
versions than (I presume) whatever is the
newest stable gcc release version.
I described an example where gcc-3.3.x and
gcc-3.4.0 (and 3.4.1) could not parse
string literal concatenation code that
the gcc preprocessor from gcc-2.95.3 parses
with no problem, simply as an example of why
some people may not be jumping to upgrade
their gcc version, whether they are upgrading
their kernels or not.
I did not post an example that reproduces
the bug, because this is not the gcc bug list.
(I did post a simplified, ad-hoc snippet
of the same basic structure as the code
that triggered the bug, merely to show that
it was in fact routine C that the gcc
preprocessor should parse correcty without fail
if it is really ready for production use.)
There are of course other reasons to drag
one's feet on a gcc upgrade, like
some backend code generators being ready
for prime-time and others (for other cpu
architectures) not ready in particular gcc
releases.
> 1) What the hell does glibc version have
> to preprocessor behaviour?
My guess would be nothing in this case,
but as I have only tested the code that
triggered the literal string concatenation
bug that I saw in gcc-3.x (up to gcc-3.4.1)
and that I no longer see in gcc-3.4.3 with
one glibc version so far, that is merely likely
rather than certain.
> 2) Could you post the code (as small as possible)
> that triggers whatever bug you are talking about?
> Not a "here's the fragment that gets miscompiled"
> but something that could be fed to gcc and actually
> reproduce the bug.
If the original application code that triggered
the bug in gcc-3.x no longer triggers it in gcc-3.4.3,
what would be the point? Even if you still want
to use gcc-3.3.4, for example (which has the bug),
you'd have to patch gcc yourself. If you posted it
to a gcc development list, the gcc maintainers
would be likely to tell you it is already fixed
in 3.4.3, "so use that".
(Plus I'd have to go back and rebuild and reinstall
one of the no-longer-installed broken gcc versions,
just to test a piece of code that reproduces the bug
without being an application fragment. I'd do it
if it were for a good cause, but I'm not convinced
that simply using gcc-3.4.3 and forgetting about the
string literal concatenation bug in earlier 3.x versions
is not the better choice here.)
I had not tested gcc-3.4.3 when replying
to the question in the original thread
(about why the kernel has compatibility code
for gcc versions older than the current stable
gcc release), and I didn't want to leave the
impression that the bug I described in that
reply to the original thread was still an
unfixed gcc 3.x bug, once I discovered that
it was fixed in gcc-3.4.3.
Are we clear?
Regards,
Clayton Weaver
<mailto: [email protected]>
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
gcc-3.4.3 caveats:
While gcc-3.4.3 fixed the string literal parsing
bug I saw, which involved chunks of literal string
with escaped newlines sandwiched around repeated
instances of a string-valued macro and the whole
thing assigned directly as the value of a
const char *, 3.4.3 is more strict than gcc-3.3.x
about embedded, unescaped newlines.
In gcc-3.3.2, string literals like this merely
got a "deprecated" warning:
const char * msg = "hello
world";
gcc-3.4.3 refuses to parse that at all, reporting
a missing " error as soon as it sees the unescaped
newline after 'hello' (and then reporting itself
confused by the remainder of the source file).
(Recompiling a system full of old laissez faire
C applications code with gcc-3.4.3, there is going
to be some additional maintenance involved.)
gcc-3.4.3 also bloats the kernel a little.
While stripped application binaries
(-march=i686 -O2 -fno-strict-aliasing)
consistently end up smaller than they were
when compiled with gcc-2.95.3, a 2.4.28-rc3
kernel ended up 60k bigger with the same
.config.
Regards,
Clayton Weaver
<mailto: [email protected]>
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
On Wed, Nov 17, 2004 at 05:29:01PM -0500, Clayton Weaver wrote:
> In gcc-3.3.2, string literals like this merely
> got a "deprecated" warning:
>
> const char * msg = "hello
> world";
>
> gcc-3.4.3 refuses to parse that at all, reporting
Fortunately, I don't anybody who writes such a crap. The
example you gave here misses a space after 'hello' and
the only way to see it is to put the cursor at the end
of the line. That's why doing this is wrong. It's a
good thing that recent gcc explicitly forbids such
usages, it will force people to fix their code. The
correct way of doing it should be :
const char * msg = "hello "
"world";
> gcc-3.4.3 also bloats the kernel a little.
> While stripped application binaries
> (-march=i686 -O2 -fno-strict-aliasing)
> consistently end up smaller than they were
> when compiled with gcc-2.95.3, a 2.4.28-rc3
> kernel ended up 60k bigger with the same
> .config.
Could you please retest with -Os. I've noticed
that starting from about gcc-3.2, code optimized
for speed tended to increase in size (eventhough
sometimes becoming slower). However, code optimized
for size (-Os) clearly reduced its size at the
expense of speed which sometimes fell dramatically.
Regards,
Willy
Upon further investigation, the literal
string concatenation bug I described may
have been an unnoticed unescaped newline
in a literal string after all (which gcc-3.3.4
and newer report as an error). I have not
been able to reproduce it with the compilers
where I originally noticed it. (I changed
the original code shortly after that to
not use string concatenation, but numerous
attempts to put it back the way it was have
failed to reproduce the error.)
However, I have yet to see any code that gcc-3.4.3
refuses to compile that gcc-3.3.4 does not also
find fault with, so if using 3.3.4 or newer,
one may as well upgrade and get the bug fixes
and compiler performance improvements. (3.3.2
is less whiny, but it doubtless has bugs
that are fixed in the newer versions.)
The gcc-3.4.3 kernel bloating only seems to
be true at -O2 and above, at least on x86.
With -Os, gcc-3.4.3 compiles a smaller bzImage
than gcc-2.95.3.
There is another potential code generation issue
on i686 architectures with gcc-3.3.4 (it is not
obvious that this would affect the kernel, but
this seems to me the sort of thing to avoid on
principle if you don't have to use that compiler).
Compiling gcc itself, I supply optimization flags
in CFLAGS and CXXFLAGS to configure, then supply
-march= to make (any trailing blanks in this post
are email client artifacts):
(in a build directory)
CC="gcc" CXX="g++" CFLAGS="-O2" CXXFLAGS="-O2" \
../gcc-[version]/configure [configure options]
make CFLAGS+="-march=pentium3" CXXFLAGS+="-march=pentium3" \
LIBCXXFLAGS+="-march=pentium3 -fno-implicit-templates" \
bootstrap
gcc-3.3.4 does not finish the compile with this make command,
reporting an error from collect2 while building the C++ support.
gcc-3.4.3 completes this build without problems. (Same binutils,
libc-2.2.5, same configure options, same make command.)
This alternative works for the gcc-3.3.4 source tree:
make CFLAGS+="-march=pentium3" CXXFLAGS+="-march=pentium3" \
LIBCXXFLAGS+="-march=i686 -fno-implicit-templates" bootstrap
(-fno-implicit-templates is not an issue. The gcc-3.3.4
build only fails with -march=pentium3 instead of -march=i686
in LIBCXXFLAGS).
Draw your own conclusions.
Additional data point: using the bc tests in
the bc-1.06 source tree, gcc-3.4.3 produces
slightly faster divides on a pIII (-O2 -march=i686 or
-march=pentium3) than gcc-2.95.3, but 2.95.3
generates consistently faster multiplies by
a larger margin. (Altered bc's "timetest"
script to do one run and throw away the
results on each test for each bc version,
then do 3 in a row of the same test with
the same bc and take an average.)
Change in estimated cost of a shift altering
the code generator's choices, ie p4 pollution
in all submodels in the i686 code generator?
2.95.3 getting away with something by chance
that 3.4.3 considers unsafe? (Mathematical output
values in the bc tests were the same.)
--
___________________________________________________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm