Re: wget build: is this normal?

Steve, thank you very much for testing this and reporting.


What to do?

Well, first of all (even when you choose to ignore the rest), do
yourself and other folks a favor and pass that sample code (your
base64 encoded piece) to Intel first thing in the morning: file a bug
report with them, because this is a compiler bug for sure. (If that
bit of source code wasn't 100% C89 standard compliant I'll eat one of
my hats, au bain marie without spices.)

You mentioned you ran revision .18 of their compiler, so they probably
yak you've got to upgrade to their latest patch level (are they at .24
or some today?); test the same sample again there.

Given that I cannot find a KB or bug report on the net for this (but I
didn't look too hard), file it anyway.


Why this hassle?

Because if they get something simple like /this/ wrong, God knows
where you'll get bitten by it next.
(Technically, it's not a compiler bug, but a preprocessor bug, but
that is rather 'deep geek' nitpicking while the fact of the matter is
that the preprocessor is an integral part of the compiler. Unless
Intel still uses a separate preprocessor app like we used in the old
days.)



Second, since the compiler chokes on this comment, I'd say: add your
'extra newline' work-around to the very same comment in the crm114
GerH source code and go from there.
Be warned (see 'third' item below): test the resulting binary.

I am discussing with myself if I should 'work around' this bug by
reformatting the code there or simply state that 10.1.18 Intel is
b0rked beyond belief and publish the solution with that.



Third, and this is me with all the raw edges, I wouldn't trust that
compiler for /anything/ anymore. At least this particular revision.
Their QA department must have been on strike to allow this to pass
through. I've met my share of compiler bugs in the past, but never
seen this level of stupidity get outside the labs of any major vendor.
Bill might call this a typo but it sure as Hell shows that someone was
thinking all the wrong things when writing that parser (scanner) bit.
All he had to do was this: "C comments: scan and discard until you hit
the two-character end-of-comment marker '*/'." [censored thoughts
about equal opportunity employment for retards in the compiler
development industry...]

I wrote you back last time thinking 'this can't be, this can't be...
but we /got/ to check' because my inner devil gave it a 5% chance and,
poof, there it is. :-((    I hate it when my hunches turn out right.
(Normally, it's in the optimization section (backend) of a compiler
where you risk hitting a bug, because that's where the really hard
stuff is hiding, so I can understand a booboo or two there[*], but
this... I'm still looking for my jaw, 'cause I dropped it.)

[*] The pattern used to 'solve' those is to rerun the whole thing with
-O0 or the local equivalent of 'all optimizations turned off' and then
incrementally introduce one optimization level or option at a time
until the produce goes nuclear again. I mention this because you might
need it next.


Anyway, useless rant aside, you've got two, pardon, three options:

1- add the 'extra newline' work-around, get out the prayer wheels
bought wholesale and recompile. (Incidentally, same prayerwheels for
BillY's vanilla crm114 or anything else you try to compile with this
piece of (censored).)

2- 'upgrade' to their latest incantation of a compiler and hope
somebody woke up their QA dept. in time. No code changes, just
recompile and test.

3- switch compilers. I know Intel is the alleged 'standard' when it
comes to optimized binary code production in some industries and
platforms, but it's like with stock-based products sold by our beloved
banks: one fuckup won't guarantee there won't be another. Do you want
the hassle or do you want a rock-steady multiyear credibility line
(and maybe, a little slower code)? The toughest choice to make. (You
didn't pick ICC just for the look of the acronym.)
(Microsoft compilers? good stuff, apart from their MSVC2002 release
which was utter dung; haven't tested their MSVC2008 yet, because with
Microsoft I've found it much more profitable for your health to 'lag
one behind'. Watcom? Very nice until they were starving financially at
the end; still want to take a look at the OpenWatcom followup to see
if they recovered but haven't alloted time for it, yet there's still
lingering love for Watcom in this body. It was my first officially
*personally* owned compiler and you never forget your first love. 450
Dutch Guilders, all my own hard earned dosh. GCC? rock-solid unless
you consider the 2.x series or try to magick all possible C++ features
into your code. The CC compilers that come with your UNIX OS are
generally quite okay, though some of their linkers have some really
weird quircks sometimes, which makes me a little jumpy there. For
other platforms (embedded) I suggest CodeWarrior, though you can have
them for the 'desktops' as well. Other embedded platforms, there's
IAR, though their optimizer is sometimes left wanting (not bugs, but
the output isn't all that optimized, and sometimes the clockticks
really do count.))



Anyway, your choice to make. A matter of taste, really. None is a
get-out-jail-free card, no matter the commercial spittle flying around
them.











On Tue, Oct 14, 2008 at 10:42 PM, Steve <[email protected]> wrote:
> -------- Original-Nachricht --------
>> Datum: Mon, 6 Oct 2008 15:47:39 +0200
>> Von: "Ger Hobbelt" <[email protected]>
>> An: Steve <[email protected]>
>> CC: [email protected]
>> Betreff: Re: [Crm114-general] wget build: is this normal?
>
>> ... VERY interesting. <he says, with a big frown>
>>
>> Say, how does the next bit of sample code compile there? You've got a
>> quite up-to-snuff compiler there and it barfs on *this*?!
>> Unfortunately, I don't have the Intel compiler handy here
>> (self-employed doesn't allow you to buy every Maserati out there) so I
>> need a bit of help here.
>>
>> If this next sample compiles with *any* error, you can take it to the
>> bank this is a compiler bug and worth an inquiry at the Intel service
>> desk/mailing list/..., minimum.
>>
>> The sample contains the erroring function definition as a
>> byte-for-byte copy. email will damage that, so you might want to
>> copy&paste it straight from that crm114_osbf.h file.
>>
>>
>> If this does compile without error, next step: can you 'tweak' your
>> compile commandline to include /E (or the local equivalent to instruct
>> Intel to 'preprocess only')?
>> That will not produce any object file, but it will cough up a torrent
>> of preprocessed C code on stdout (or to the target file specced after
>> the /o commandline switch (check equivalent commandline option for
>> ICC), so you may have to massage the compiler into only 'compiling'
>> (preprocessing) the sourcefile it was compiling when the original
>> error popped up. I am VERY MUCH interested to see what ICC thinks it's
>> doing right there: if we get to do this /E stuff, you should email
>> output to my private email (same address I always use here:
>> [email protected]) as the output will be /way/ too big for 'shared'
>> conversation on the ML.
>>
>>
>> BTW: are you on Windows (maybe MSVC IDE with Intel compiler backend?)
>> or UNIX? (In both cases this sample program won't *run* without
>> crashing but *must* compile without error or warning.)
>>
>>
>> Final note: make sure you feed that Intel cc the *exact* same set of
>> commandline options as you fed it when compiling the GerH crm114 code.
>>
>> (YES, a compiler barfing on a
>> 'standard-C-since-the-birth-of-Kernighan-and-Ritchie-dawn-of-time'
>> /**/ multiline comment makes me /that/ degree of worried! I screw up,
>> often badly, but definitely not here. This is through 'wicked' and out
>> the other side.)
>>
>> -------snip here---------------
>> #include <stdio.h>
>> #include <stdlib.h>
>>
>> #ifndef __CRM114_OBSF_H__
>> #define __CRM114_OBSF_H__
>>
>> #ifdef __cplusplus
>> extern "C"
>> {
>> #endif
>>
>> extern int crm_osbf_create_cssfile(char *cssfile, unsigned int buckets,
>>         unsigned int major, unsigned int minor /* [i_a] unused anyway ,
>>                                                 * unsigned int
>> spectrum_start */);
>>
>>
>>
>>
>> #ifdef __cplusplus
>> }
>> #endif
>>
>> #endif /* __CRM114_OBSF_H__ */
>>
>> int main(int argc, char **argv)
>> {
>> unsigned int buckets = 1;
>> unsigned int major = 1;
>> unsigned int minor = 1;
>>
>>       return crm_osbf_create_cssfile(argv[1], buckets,
>>               major, minor /* [i_a] unused anyway ,
>>               * unsigned int spectrum_start */);
>> }
>>
>>
>> int crm_osbf_create_cssfile(char *cssfile, unsigned int buckets,
>>         unsigned int major, unsigned int minor /* [i_a] unused anyway ,
>>      * unsigned int spectrum_start */)
>> {
>>       return cssfile[buckets + major + minor];
>> }
>> --------------------------
>>
> Not working. I get this error:
> test.c(14): error: expected a ")"
>                                                  * unsigned int spectrum_start */);
>                                                  ^
>
> test.c(29): error: expected an expression
>                                * unsigned int spectrum_start */);
>                                  ^
>
> test.c(34): error: expected a ")"
>                                                  * unsigned int spectrum_start */)
>                                                  ^
>
> compilation aborted for test.c (code 2)
>
>
>
> This is the code I used. Encoded with base64:
> -------snip here---------------
> I2luY2x1ZGUgPHN0ZGlvLmg+CiNpbmNsdWRlIDxzdGRsaWIuaD4KCiNpZm5k
> ZWYgX19DUk0xMTRfT0JTRl9IX18KI2RlZmluZSBfX0NSTTExNF9PQlNGX0hf
> XwoKI2lmZGVmIF9fY3BsdXNwbHVzCmV4dGVybiAiQyIKewojZW5kaWYKCmV4
> dGVybiBpbnQgY3JtX29zYmZfY3JlYXRlX2Nzc2ZpbGUoY2hhciAqY3NzZmls
> ZSwgdW5zaWduZWQgaW50IGJ1Y2tldHMsCiAgICAgICAgdW5zaWduZWQgaW50
> IG1ham9yLCB1bnNpZ25lZCBpbnQgbWlub3IgLyogW2lfYV0gdW51c2VkIGFu
> eXdheSAsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
> ICAgICAgICAgICogdW5zaWduZWQgaW50IHNwZWN0cnVtX3N0YXJ0ICovKTsK
> CiNpZmRlZiBfX2NwbHVzcGx1cwp9CiNlbmRpZgoKI2VuZGlmIC8qIF9fQ1JN
> MTE0X09CU0ZfSF9fICovCgppbnQgbWFpbihpbnQgYXJnYywgY2hhciAqKmFy
> Z3YpCnsKCXVuc2lnbmVkIGludCBidWNrZXRzID0gMTsKCXVuc2lnbmVkIGlu
> dCBtYWpvciA9IDE7Cgl1bnNpZ25lZCBpbnQgbWlub3IgPSAxOwoJcmV0dXJu
> IGNybV9vc2JmX2NyZWF0ZV9jc3NmaWxlKGFyZ3ZbMV0sIGJ1Y2tldHMsCgkJ
> bWFqb3IsIG1pbm9yIC8qIFtpX2FdIHVudXNlZCBhbnl3YXkgLAogICAgICAg
> ICAgICAgICAgICAgICAgICAgICAgICAqIHVuc2lnbmVkIGludCBzcGVjdHJ1
> bV9zdGFydCAqLyk7Cn0KCmludCBjcm1fb3NiZl9jcmVhdGVfY3NzZmlsZShj
> aGFyICpjc3NmaWxlLCB1bnNpZ25lZCBpbnQgYnVja2V0cywKCXVuc2lnbmVk
> IGludCBtYWpvciwgdW5zaWduZWQgaW50IG1pbm9yIC8qIFtpX2FdIHVudXNl
> ZCBhbnl3YXkgLAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
> ICAgICAgICAgICAgICAqIHVuc2lnbmVkIGludCBzcGVjdHJ1bV9zdGFydCAq
> LykKewoJcmV0dXJuIGNzc2ZpbGVbYnVja2V0cyArIG1ham9yICsgbWlub3Jd
> Owp9Cg==
> --------------------------
>
> What works is when adding an new line after */
> So ... */); becomes ... */
> );
>
>
> What to do now?
>
>
>>
>>
>>
>>
>> On Mon, Oct 6, 2008 at 8:45 AM, Steve <[email protected]> wrote:
>> > Hallo Ger
>> >
>> > Here the requested information:
>> > compiler brand: Intel ICC
>> > version: 10.1
>> > patchlevel: 018
>> > full version number: 10.1.018
>> >
>> >
>> > cheers
>> >
>> > Steve
>>
>>
>> --
>> Met vriendelijke groeten / Best regards,
>>
>> Ger Hobbelt
>>
>> --------------------------------------------------
>> web:    http://www.hobbelt.com/
>>         http://www.hebbut.net/
>> mail:   [email protected]
>> mobile: +31-6-11 120 978
>> --------------------------------------------------
>
> --
> Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
> Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Crm114-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/crm114-general
>
>
>



-- 
Met vriendelijke groeten / Best regards,

Ger Hobbelt

--------------------------------------------------
web:    http://www.hobbelt.com/
        http://www.hebbut.net/
mail:   [email protected]
mobile: +31-6-11 120 978
--------------------------------------------------

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/