[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Imgcif-l] gcc bug? in CBFlib-0.8.0

• To: MATSUURA Takanori <[email protected]>
• Subject: Re: [Imgcif-l] gcc bug? in CBFlib-0.8.0
• From: "Herbert J. Bernstein" <[email protected]>
• Date: Thu, 11 Sep 2008 06:56:49 -0400 (EDT)
• Cc: [email protected]
• In-Reply-To: <20080911.123332.769599706407290392.t-matsuu@protein.osaka-u.ac.jp>
• References: <20080911.123332.769599706407290392.t-matsuu@protein.osaka-u.ac.jp>

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
                  [email protected]
=====================================================

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
>
_______________________________________________
imgcif-l mailing list
[email protected]
http://scripts.iucr.org/mailman/listinfo/imgcif-l

Reply to: [list | sender only]

• Prev by Date: [Imgcif-l] proposed change in first line of imgcif files
• Next by Date: Re: [Imgcif-l] proposed change in first line of imgcif files
• Prev by thread: Re: [Imgcif-l] additional dictionary items to map marccd exposure,integration, readout times?
• Next by thread: [Imgcif-l] proposed change in first line of imgcif files
• Index(es):
  • Date
  • Thread