[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
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