Re: [AD] Allegro on icc

[Evert Glebbeek <eglebbk@xxxxxxxxxx>]

On Sunday 29 February 2004 15:47, Eric Botcazou wrote:
> Yes, dated 02/23 in the "GCC 3.4" thread.

Ah yes, found it.

> Interesting.  Could you post one example of code that triggers the 
warning?

For instance:

./src/colblend.c(901): remark #981: operands are evaluated in unspecified 
order
     return BLEND(15, 255 - ((255 - getr15(x)) * (255 - getr15(y))) / 256,
            ^

I also get a lot of these:

./src/colblend.c(938): remark #424: extra ";" ignored
  SET_BLENDER_FUNC(trans);

and I also get a lot of these:

./src/dispsw.c(442): warning #556: a value of type "void *" cannot be 
assigned to an entity of type "void (*)(struct BITMAP *)"
        info->other->vtable->release = info->release;

icc is actually a C++ compiler,  which may explain some of these warnings. 
It should treat C files as C files though, not as C++ files so I think 
that warning is actually a case ofthecompiler being over pedantic.

I should probably direct all output to a file and sift through that.

> Did you try to compile without optimization?

I hadn't tried. Interesingly enough, the complaints about unspecified order 
of operator evaluation don't appear, confirming that these are indeed 
related to the optimizer. I did, however, now notice the following 
warning:

./src/font.c(32): warning #1368: excess initializers are ignored
  static FONT_GLYPH f_0x20 = { 8, 8, { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00, 0x00 } };

Recompiling only that file with gcc the issue and produces the correct 
output. I'll recompile with full optimizations and build the font.c file 
with gcc (and the same optimization switches as for icc) and post some 
timing tests (there's no automatic benchmark testing, is there?) in a 
moment.

> I'm leaning towards rejecting such a patch on the ground that it is 
perfectly 
> correct and we should not try to endorse the unacceptable behaviour of 
ICC.

Actually, it is not as poor-behaved as you may think. The Intel C compiler 
is highly compatible with gcc, both in the commandline options and the 
language features (GNU extensions). 
I personally lean to the idea that i386+gcc makes AT&T inline asm ok is no 
longer valid.
It isn't a big issue though, as icc has a -no-gcc switch to tell the 
compiler not to #define __GNUC__.

Evert