[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: [Imgcif-l] gcc bug? in CBFlib-0.8.0
- To: MATSUURA Takanori <t-matsuu@protein.osaka-u.ac.jp>
- Subject: Re: [Imgcif-l] gcc bug? in CBFlib-0.8.0
- From: "Herbert J. Bernstein" <yaya@bernstein-plus-sons.com>
- Date: Thu, 11 Sep 2008 06:56:49 -0400 (EDT)
- Cc: imgcif-l@iucr.org
- 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 yaya@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 > _______________________________________________ imgcif-l mailing list imgcif-l@iucr.org 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):