[Imgcif-l] gcc bug? in CBFlib-0.8.0
Herbert J. Bernstein
yaya at bernstein-plus-sons.com
Thu Sep 11 11:56:49 BST 2008
Dear Matsuura Takanori,
What we are doing is to use:
/* Get the local byte order of the default integer type */
int cbf_get_local_integer_byte_order (char ** byte_order)
{
static char le[14] = "little_endian";
static char be[11] = "big_endian";
int *test;
int probe = 1;
test = (int *)&probe;
if (*(char*)test) *byte_order = le;
else *byte_order = be;
return 0;
}
from cbf.c.
For the moment, that survives gcc's increasingly strange choices in
default behavior. Some might choose to call this particular gcc choice a
design feature. I think of it as an optimization bug. We can follow your
suggestion of using a union when the gcc developers decide to change the C
language yet again. I already have the code. It was actually in the
first version of cbf_get_local_integer_byte_order, but this version looked
neater, so I'll use it for the moment.
Yes, I do understand that the C99 rules make it "illegal to create an
alias of a different type than the original," and yes, I have been
cleaning a lot of type puns out of my code, but for at the moment, gcc
does not seem to think this code is a violation, and I thought I was
compiling ANSI C, rather than C99.
However, this all goes deeper. It simply does not seem sensible to me for
the compiler to consider a construct syntactically valid without
optimization and invalid with optimization. Optimization should process
the same language, just make the code run faster.
Thank you for allowing me to vent.
Regards,
Herbert
=====================================================
Herbert J. Bernstein, Professor of Computer Science
Dowling College, Kramer Science Center, KSC 121
Idle Hour Blvd, Oakdale, NY, 11769
+1-631-244-3035
yaya at dowling.edu
=====================================================
On Thu, 11 Sep 2008, MATSUURA Takanori wrote:
> Dear Herbert,
>
> I found the comment of
> Commented out 19 June 2008 because of optimization bug in gcc
> in CBFlib_0.8.0/examplesadscimg2cbf_sub.c.
> I have not tested but I suppose the problem is the line 223:
> i2 = (short *) pi4;
>
> I think this is not a bug in gcc but a spec in gcc. 3 or higher
> version of gcc includes the "-fstrict-aliasing" in O2 or O3
> optimization. Temporary fix is like "-O2 -fno-strict-aliasing". But
> the fundamental fix is to use union type. See "-fstrict-aliasing" in
> "man gcc"
>
>
> Regards,
> Takanori
>
>
> --
> MATSUURA Takanori, Ph.D.
> Visiting Associate Professor
> Annotators' Leader, Group of Primary Annotation,
> Protein Data Bank Japan (PDBj)
> Research Center for Structural and Functional Proteomics,
> Institute for Protein Research, Osaka University
> 3-2 Yamadaoka, Suita, Osaka 565-0871, JAPAN
> Tel: +81-6-6879-8634
> Fax: +81-6-6879-8636
>
More information about the imgcif-l
mailing list