Re: wget build: is this normal?

"Steve" <[email protected]> Wed, 15 Oct 2008 12:16:08 +0200
Newsgroups	gmane.mail.spam.crm114
Message-ID	<[email protected]>
-------- Original-Nachricht --------
> Datum: Wed, 15 Oct 2008 03:29:47 +0200
> Von: "Ger Hobbelt" <[email protected]>
> An: Steve <[email protected]>
> CC: [email protected]
> Betreff: Re: [Crm114-general] wget build: is this normal?

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


> 
> 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.)
> 
I am freaking out over here! I have username and password but for whatever reason.... I can not log into the bug tracking system. I need to look how to get there...


> 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.
> 
For Linux it is still the .018 patchlevel. For Windows the patchlevel is .025. And I am using Linux.


> 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.
> 
Okay. I might go that path and test with the lowest optimization and go one level up if it compiles.


> 
> 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).)
> 
BillY's code does not have that issue :)


> 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.
> 
Will do as soon as new Linux version is out.


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


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

-- 
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx

-------------------------------------------------------------------------
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=/