Re: wget build: is this normal?

-------- Original-Nachricht --------
> Datum: Wed, 15 Oct 2008 18:08:01 +0200
> Von: "Ger Hobbelt" <[email protected]>
> An: Steve <[email protected]>
> CC: [email protected]
> Betreff: Re: [Crm114-general] wget build: is this normal?

> On Wed, Oct 15, 2008 at 12:16 PM, Steve <[email protected]> wrote:
> > 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...
> 
> Okay, relax.
>
I am relaxed :)


> They've got a webforum as well, if I'm not mistaken, so
> maybe ask around there.
>
I finally got into the premium support area. I hate Intel for their password policy. Anyway... The passwords are now synced and I logged in. Before opening a ticket, I decided to make a small example to post it on the support ticket. I used this example:
-------------------
#include <stdio.h>
int main(int argc, char *argv[] /* Just
       * some
       * useless
       * comment */)
{
        printf("Hello World\n");
}
-------------------

And guess what? It compiles. Even with ultra insane compiler flags:
-------------------
nemesis ~ # /opt/intel/cc/10.1.018/bin/icc -std=c99 -O3 -axK -gcc -unroll2 -ipo -mp -restrict -inline-level=2 -align -Zp16 -parallel -alias_args -fno-alias -fp-port -o hworld hworld.c
ipo: remark #11001: performing single-file optimizations
ipo: remark #11005: generating object file /tmp/.private/root/ipo_iccdGAaBu.o
hworld.c(6): (col. 1) remark: main has been targeted for automatic cpu dispatch.
nemesis ~ # file hworld
hworld: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, not stripped
nemesis ~ # ldd hworld
        linux-gate.so.1 =>  (0xb7fca000)
        libm.so.6 => /lib/libm.so.6 (0xb7f97000)
        libguide.so => /opt/intel/cc/10.1.018/lib/libguide.so (0xb7f21000)
        libgcc_s.so.1 => /usr/lib/gcc/i686-pc-linux-gnu/4.3.1/libgcc_s.so.1 (0xb7f14000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7efb000)
        libc.so.6 => /lib/libc.so.6 (0xb7d95000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7d91000)
        /lib/ld-linux.so.2 (0xb7fcb000)
nemesis ~ #
-------------------

So the problem seems to be something else. But I don't know what?


> The important thing is that this ends up in
> their bug tracking system after all, so some engineer will have to
> look at it. Posting in a forum generally is slow death, I find.
> 
> 
> > For Linux it is still the .018 patchlevel. For Windows the patchlevel is
> .025. And I am using Linux.
> 
> Ah. Hm. If you have the Windows version around somewhere, might try to
> feed it in there as well, just to check how 'widespread' this one is
> in their codebase. If you (or some else) has access to that .025
> revision, best to try the sample with that one as well and file
> another bug report and cross reference them. I get the feeling they
> are focusing on Windows (which I would as the big customers I know of
> all are Windows based) so it might help you indirectly by making sure
> the common codebase gets corrected from both directions.
> 
> 
> 
> > Okay. I might go that path and test with the lowest optimization and go
> one level up if it compiles.
> 
> Please note: I would be *completely* stunned if optimization level
> would influence this bug; see my earlier comment about this being a
> preprocessor bug, not a compiler backend bug. In a good
> (compartmentalized) design, the two are not really related. It is just
> that this thing blows away my trust in the compiler as a whole and
> back when there was 10.0.0x I have worked with people who had
> different trouble with ICC: their problem was executables that acted
> 'weird', which was an optimizer issue or two. You may run into such
> trouble another time (hopefully never); /that/ is when the 'start with
> -O0 and dial up optimizations from there' approach is useful.
> 
> If twiddling the optimization levels shows different behavior /here/ I
> would be truly amazed, not just the jaw dropping ;-)
> 
> Bottom line: if the problem is gone with a 'no optimizations'
> settings, all you'll hear from me is 'WTF?' ;-)
> 
> 
> > BillY's code does not have that issue :)
> 
> I know. He doesn't have that comment as /I/ put it in. It's just that
> my trust in the compiler is reduced to zero right now. Takes time to
> recover from that. I'm slow that way. ;-)
> 
> 
> Easiest way to build a GerH on your system right now is take that
> comment and blow it away or add the extra newline like you did
> already.
> 
> 
// SteveB

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