[gentoo-amd64] GCC-4.5.2 Has Serious Problems

[gentoo-amd64] GCC-4.5.2 Has Serious Problems

[Frank Peters]

[-- Attachment #1: Type: text/plain, Size: 2548 bytes --]

Hello,

After banging my head for a while over some strange results, I began
to suspect GCC-4.5.2, the latest version in portage, was creating
faulty code.

It seems to a correct suspicion.

What follows is a short C program that reproduces my particular problem,
but there are likely many other situations where GCC could fail.  The code
may be a difficult for some people to follow but only the output is what
actually matters.  Simpler examples will certainly exist but I have not
had the chance to develop them.

The program is included here as both in-line text and as a file attachment
(gcc_test.c).  The problem is described below.

------------------------------------

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
int n;
double x;
unsigned long int arg;
unsigned long int *px = (unsigned long int*)&x;

x=0.0; n=0; arg=0x4010000000000000;
while(n<5)
{

printf("%lx %g\n",arg, x);

*px=arg;

printf("%lx %g\n\n",arg, x);
n++; arg=arg+0x0010000000000000;
}

exit(0);
}

-------------------------

What this code does is not very important (it uses pointers to enter
hexadecimal values into a floating point variable within a short loop).
The output is what matters.

Compiling with "gcc -O2 -march=native -o gcc_test gcc_test.c"
produces this output:

Loop: 0
Val = 4010000000000000, X before =  0
Val = 4010000000000000, X after =   0   -->  X should be 4!!! 

Loop: 1
Val = 4020000000000000, X before =  0
Val = 4020000000000000, X after =   4

Loop: 2
Val = 4030000000000000, X before =  4
Val = 4030000000000000, X after =   8

The printf statements are included before and after the variable, x,
is assigned a value.  Notice how in the first iteration of the loop
the x variable does *not* get assigned a value.  The value of x during
the first iteration should be 4.

The problem can be fixed by compiling the program with "O1"
optimization:

gcc -O1 -march=native -o gcc_test gcc_test.c

Using "O1" the output now becomes:

Loop: 0
Val = 4010000000000000, X before =  0
Val = 4010000000000000, X after =   4  --> Now it works!!!

Loop: 1
Val = 4020000000000000, X before =  4
Val = 4020000000000000, X after =   8

Loop: 2
Val = 4030000000000000, X before =  8
Val = 4030000000000000, X after =   16

This is now the correct output.  In the first iteration the X variable
is assigned the proper value.

For anyone who wants to try to duplicate these results, please feel
free to do so.

So I will have to conclude that GCC-4.5.2 has serious problems.
This kind of erroneous behavior could appear anywhere.
 
Frank Peters


[-- Attachment #2: gcc_test.c --]
[-- Type: text/x-csrc, Size: 393 bytes --]

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
int n;
double x;
unsigned long int arg;
unsigned long int *px = (unsigned long int*)&x;

x=0.0; n=0; arg=0x4010000000000000;
while(n<3)
{

printf("%s %d\n%s %lx, %s %g\n", "Loop:", n,"Val =", arg, "X before = ", x);

*px=arg;

printf("%s %lx, %s %g\n\n", "Val =", arg, "X after =  ", x);

n++; arg=arg+0x0010000000000000;
}

exit(0);
}

Re: [gentoo-amd64] GCC-4.5.2 Has Serious Problems

[Alex Schuster]

Frank Peters writes:

> After banging my head for a while over some strange results, I began
> to suspect GCC-4.5.2, the latest version in portage, was creating
> faulty code.
> 
> It seems to a correct suspicion.
[...]

> The problem can be fixed by compiling the program with "O1"
> optimization:

Or -O3.


> For anyone who wants to try to duplicate these results, please feel
> free to do so.
> 
> So I will have to conclude that GCC-4.5.2 has serious problems.
> This kind of erroneous behavior could appear anywhere.

Oh dear, that's scary. I can confirm this. With -O0, -O1 and -O3, all is
fine. -O2 gives the result you see. And with -Os, I get yet another
result (0/0, 4/4, 8/8).

This is an AMD Athlon(tm) Dual Core Processor 4850e, gcc has been
copmpiled with these use flags: fortran gtk mudflap multilib nls nptl openmp

Who will file the bug report now?

	Wonko

Re: [gentoo-amd64] GCC-4.5.2 Has Serious Problems

[Frank Peters]

On Fri, 01 Jul 2011 00:30:57 +0200
Alex Schuster <wonko@wonkology.org> wrote:

> 
> Who will file the bug report now?
> 

Thanks for the confirmation.

GCC-4.5.2, some may claim, is already old hat.  I just tried
the same experiment using GCC-4.6.0 and there is no problem.
The program works with "O2" optimization.  So I will be using
GCC-4.6.0 from now on.

But the problem does deserve some looking into, I would think.

Frank Peters

[gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Nikos Chantziaras]

On 07/01/2011 12:45 AM, Frank Peters wrote:
> Hello,
>
> After banging my head for a while over some strange results, I began
> to suspect GCC-4.5.2, the latest version in portage, was creating
> faulty code.
>
> It seems to a correct suspicion.
>[...]
> int n;
> double x;
> unsigned long int arg;
> unsigned long int *px = (unsigned long int*)&x;

Your code is buggy, because you're breaking C's aliasing rules.  You are 
not allowed to use a different pointer type to dereference a variable of 
a different type.  Doing so results in undefined behavior.

Short answer, GCC is correct, you are wrong :-)  To compile code that 
breaks aliasing rules, always use the "-fno-strict-aliasing" option.  In 
this case:

   gcc -O2 -fno-strict-aliasing

[gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Nikos Chantziaras]

On 07/01/2011 02:35 AM, Nikos Chantziaras wrote:
> On 07/01/2011 12:45 AM, Frank Peters wrote:
>> Hello,
>>
>> After banging my head for a while over some strange results, I began
>> to suspect GCC-4.5.2, the latest version in portage, was creating
>> faulty code.
>>
>> It seems to a correct suspicion.
>> [...]
>> int n;
>> double x;
>> unsigned long int arg;
>> unsigned long int *px = (unsigned long int*)&x;
>
> Your code is buggy, because you're breaking C's aliasing rules. You are
> not allowed to use a different pointer type to dereference a variable of
> a different type. Doing so results in undefined behavior.

And here you can read more thorough information about strict aliasing:

   http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing

Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Frank Peters]

On Fri, 01 Jul 2011 02:44:36 +0300
Nikos Chantziaras <realnc@arcor.de> wrote:

> >
> > Your code is buggy, because you're breaking C's aliasing rules. You are
> > not allowed to use a different pointer type to dereference a variable of
> > a different type. Doing so results in undefined behavior.
> 

Well, the error occurs only within the loop structure.  If
I manually "unroll" the loop using the same pointers there
is no error when compiled with "O2." 

IOW, the problem is how the loop is optimized under -O2.

Frank Peters

[gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Nikos Chantziaras]

On 07/01/2011 03:04 AM, Frank Peters wrote:
> On Fri, 01 Jul 2011 02:44:36 +0300
> Nikos Chantziaras<realnc@arcor.de>  wrote:
>
>>>
>>> Your code is buggy, because you're breaking C's aliasing rules. You are
>>> not allowed to use a different pointer type to dereference a variable of
>>> a different type. Doing so results in undefined behavior.
>>
>
> Well, the error occurs only within the loop structure.  If
> I manually "unroll" the loop using the same pointers there
> is no error when compiled with "O2."
>
> IOW, the problem is how the loop is optimized under -O2.

When there's "undefined behavior", it really means just that: you cannot 
make any assumptions about when the result is going to be correct and 
when not.  It might as well depend on whether it was raining yesterday.

Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Frank Peters]

On Fri, 01 Jul 2011 02:44:36 +0300
Nikos Chantziaras <realnc@arcor.de> wrote:

> >> unsigned long int *px = (unsigned long int*)&x;

> And here you can read more thorough information about strict aliasing:
> 
>    http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing
> 

Thanks for this link.  I can see what's happening now.

These types of pointers are admittedly unusual, but it's the only
quick way I know to load a double variable with a certain bit pattern,
or to convert big/small endian values, etc.  I ordinarily don't do these
things, but when I do I 'll keep this aliasing in mind.

Frank Peters

[gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Duncan]

Nikos Chantziaras posted on Fri, 01 Jul 2011 03:11:09 +0300 as excerpted:

> On 07/01/2011 03:04 AM, Frank Peters wrote:
>> On Fri, 01 Jul 2011 02:44:36 +0300 Nikos Chantziaras<realnc@arcor.de> 
>> wrote:
>>
>>
>>>> Your code is buggy, because you're breaking C's aliasing rules. You
>>>> are not allowed to use a different pointer type to dereference a
>>>> variable of a different type. Doing so results in undefined behavior.
>>>
>>>
>> Well, the error occurs only within the loop structure.  If I manually
>> "unroll" the loop using the same pointers there is no error when
>> compiled with "O2."
>>
>> IOW, the problem is how the loop is optimized under -O2.
> 
> When there's "undefined behavior", it really means just that: you cannot
> make any assumptions about when the result is going to be correct and
> when not.  It might as well depend on whether it was raining yesterday.

I had wondered if this might be an "undefined behavior" optimization bug, 
but don't personally know enough about C coding to tell.

However, what I have observed, both here and for instance in the recent 
glibc memcp vs memmove instructions (don't ask me if those are 
abbreviated correctly, I'm not a coder, just a user who followed the 
situation as reported in the community press with some interest, 
particularly because I DO tend to unmask and try new versions with such 
issues before they're officially ready), is that in the quest for further 
optimizations, all the "easy" stuff is pretty much already done.  It's 
now the harder, more obscure optimizations that might break code making 
bad assumptions about "undefined behavior", etc, that's the leading edge 
of technology, at least as seen in the FLOSS world encompassing gcc and 
glibc.

The -fno-strict-aliasing thing was a big deal for gcc 4.5, precisely 
because it DOES allow corner-case optimization where it wasn't tried 
before, but does so by taking advantage of "undefined behavior" being 
just that, undefined, to make assumptions about shortcuts the authors did 
NOT take because to do so would be undefined, based on the absence of a 
flag saying NOT to make such assumptions because the author DID take such 
shortcuts, relying on the previous behavior where it is specifically 
defined as "undefined".

As it happens, there was quite a lot of code making such assumptions, 
that needed -fno-strict-aliasing in the short term, but hopefully, 
recoded not to make invalid assumptions about the behavior of 
specifically "undefined behavior" in the longer term.

It's just that sort of testing, bug reporting, and patching, that keeps 
gentoo devs (and indeed, those of many distributions) busy, as new 
versions of gcc and various system libraries come out, and why at times 
they seem to take "forever" to stabilize, or even get unmasked into ~arch 
(where gcc-4.6 has yet to appear, fwiw).

FWIW, I don't know a whole lot about fixing such things in the C/C++/
whatever code itself, but I've developed quite some experience finding 
and applying patches from bugzilla, etc, that haven't made their way into 
any package version available in the tree for negatively affected 
packages that I use, yet, as I do frequently package.unmask new gccs, 
etc, before they're officially unmasked, which generally takes place 
after those patches have actually made it into in-tree versions... which 
can be quite some time!

gcc-config helps as it makes it quite easy to switch between versions for 
specific packages, but OTOH, that doesn't always help with for instance 
kde, when cmake is built with and depends on the newer gcc, but one of 
the kde packages trying to build with cmake is still broken with the 
newer gcc.  Switch to the newer gcc and you can't compile the broken-with-
it package, switch to the older one and cmake is broken, so you /still/ 
can't compile the package!  If that occurs after you've already rebuild 
90% of the system including 80% of kde with the new version... and it 
DOES have you pulling your hair out!  Been there!  Done that!  Which is 
why I've not tried gcc 4.6 yet, tho I'm getting restless and beginning to 
consider it.

So expect more of this type of thing as the gcc and glibc optimizers try 
to squeeze ever more performance out of their optimizations, because all 
the "safe" optimizations have been had, and they're deep into "undefined 
behavior" territory now, taking advantage of the fact that it's undefined 
to change it here and there, thus eking out yet another corner-case 
optimization, whilst ensuring the gentoo devs don't run out of things to 
do, ensuring compatibility of old code with new compiler and system 
library versions. =:^]

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Frank Peters]

On Fri, 01 Jul 2011 02:44:36 +0300
Nikos Chantziaras <realnc@arcor.de> wrote:

> 
> And here you can read more thorough information about strict aliasing:
> 
>    http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing
> 

You've saved the day in more ways than one.

A few days ago I posted about a possible problem with a floating
point test called the UCBTEST.  After examining the source code
of this test, I see violations of aliasing rules throughout.
It's hard to efficiently manipulate variables without them.

Of course, this code was written before the C99 standard and
so is exempt.  But the use of "-fno-strict-aliasing" will
apply with the UCBTEST as well.

Thanks again for the information.

Frank Peters

 

Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Frank Peters]

On Fri, 1 Jul 2011 00:58:46 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

> 
> I had wondered if this might be an "undefined behavior" optimization bug, 
>  

Well, the amd64 users list may not be the appropriate place to discuss
C programming, but the problem here stems from attempting to do things
with C that are not supposed to be done with C.  Such things are aptly
called "tricks" because they stray away from the convention.

Ideally, I suppose, for these purposes would be to use assembly language
routines mixed into the C code.  But this is not as easy as with the
"tricks."

Anyway, I'm glad I presented this issue.  It has definitely improved
my understanding.  GCC has dozens, if not hundreds, of compile options
and I know the actual function of only a small few.

Frank Peters

[gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Duncan]

Frank Peters posted on Thu, 30 Jun 2011 21:23:21 -0400 as excerpted:

> Anyway, I'm glad I presented this issue.  It has definitely improved my
> understanding.  GCC has dozens, if not hundreds, of compile options and
> I know the actual function of only a small few.

Indeed.  The gcc manpage is a veritable treasure-trove of interesting 
options, even (especially?) for those who who don't know C but either 
aspire to be or already consider themselves Gentoo power-users.

And this sort of issue discussion is perfect for a gentoo list, as even 
for those who don't really understand it, it provides a glimpse into the 
sorts of things gentoo devs must deal with on a daily basis (yes, I guess 
that is sort of repeating the point I made before, but it's true).

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Ian McCulloch]

On Fri, 1 Jul 2011, Frank Peters wrote:

> On Fri, 1 Jul 2011 00:58:46 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>
>>
>> I had wondered if this might be an "undefined behavior" optimization bug,
>>
>
> Well, the amd64 users list may not be the appropriate place to discuss
> C programming, but the problem here stems from attempting to do things
> with C that are not supposed to be done with C.  Such things are aptly
> called "tricks" because they stray away from the convention.

I don't think that is true - C has ALWAYS had rules on strict aliasing, 
even from the first attempts at standardization.

Unfortunately it is only recently that common compilers and hardware have 
really taken advantage of the way the language works to give better 
optimizing performance by storing more variables in registers rather than 
reloading pointers from memory every time.  Mostly this is due to the 
small number of registers in the x86 architecture, doesn't lend itself to 
these optimisations as well as other architectures.  Contrast with Itanium 
for example with lots of registers, some of which are designed to be 
preserved across a function call.  FORTRAN compilers have taken advantage 
of aliasing optimizations right from the beginning (ie, since the 
1960's!), and commodity C compilers are only now just catching up!  So 
these are hardly new optimizations.

>
> Ideally, I suppose, for these purposes would be to use assembly language
> routines mixed into the C code.  But this is not as easy as with the
> "tricks."

Not at all, it is about producing more efficient assembly, using the 
language rules that have existed practically forever.  If programmers have 
become accustomed to violating those rules, then they'll just have to get 
accustomed to not violating them.  The rules aren't hard!  And if you DO 
want to alias pointers of different types, then there are well-defined 
ways of doing that, and the resulting code tends to be much more readable 
too.

Regards,
Ian

[gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Duncan]

Frank Peters posted on Thu, 30 Jun 2011 21:04:29 -0400 as excerpted:

> On Fri, 01 Jul 2011 02:44:36 +0300 Nikos Chantziaras <realnc@arcor.de>
> wrote:
> 
>> And here you can read more thorough information about strict aliasing:
>> 
>>    http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing
>> 
> You've saved the day in more ways than one.
> 
> A few days ago I posted about a possible problem with a floating point
> test called the UCBTEST.  After examining the source code of this test,
> I see violations of aliasing rules throughout. It's hard to efficiently
> manipulate variables without them.
> 
> Of course, this code was written before the C99 standard and so is
> exempt.  But the use of "-fno-strict-aliasing" will apply with the
> UCBTEST as well.

Truthfully, I thought sure this was a direct follow-on to that! So I'm 
happy to see that the same cause and solutions apply.  =:^)

As I said in an earlier post, tho, expect there to be more problems like 
that with code of that age as time goes on, because they're well past the 
easy optimizations now, and into stuff like this.  So it may be wise to 
keep an eye out  and test the minor gcc version bumps with an eye toward 
such issues.  They generally put out a porting guide, etc, with the new 
version, that you can read for clues in case the tests start doing 
unexpected things again.  

(If you pay attention to flameeyes' blog, he tends to cover such things 
reasonably early on after release of a new gcc version as well, as he 
does tinderbox runs to see how bad the interaction of the new version is 
with the current gentoo ~arch tree as a whole and eventually to test that 
the latest ~arch packages are updated or patched to fix the problem, 
before that gcc version gets unmasked to ~arch.  By no means do I agree 
with everything he says, but he really is an asset to gentoo and would be 
sorely missed should one of his sick episodes make it impossible for him 
to continue, or if he simply decided he had better things to do with his 
time.  The switch to --as-needed in Gentoo's default ldflags was largely 
due to his work, explaining the issues for other devs, testing and filing 
bugs, helping with the hard cases, and in general pushing it until it 
happened, for instance, and every single gentoo user benefits from that 
in the form of less mandatory rebuilds, every time they update.  It may 
well have happened without him, but it might have taken a decade longer, 
too.  And because gentoo devs normally push those patches upstream where 
they can, that has been a benefit to the entire FLOSS community, not just 
gentoo, as well, reducing "dependency hell" for everyone.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Barry Schwartz]

Frank Peters <frank.peters@comcast.net> skribis:
> A few days ago I posted about a possible problem with a floating
> point test called the UCBTEST.  After examining the source code
> of this test, I see violations of aliasing rules throughout.
> It's hard to efficiently manipulate variables without them.

C is essentially a glorified assembly language for PDP-11, designed
for bit-twiddling, which the original K&R book encouraged, and which
this code is doing. So all is well, from my point of view. :) Fancy
optimizations are not to be trusted on assembly code; never be afraid
to turn them off. You probably don’t need them, anyway. :)

Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Frank Peters]

On Thu, 30 Jun 2011 21:22:39 -0500
Barry Schwartz <chemoelectric@chemoelectric.org> wrote:

> 
> C is essentially a glorified assembly language
>

IMO, that's why C is the best.  It is very close to the machine
and the programmer has to be very attentive to details of hardware
as well as to software concepts.

> for bit-twiddling, which the original K&R book encouraged, and which
> this code is doing. So all is well, from my point of view. :)

Bit manipulations on integers and strings are natural.  The difficulty
is with floating point variables which are not just bits but also
a complex format that does not respect byte boundaries.  The ordinary bit
operators cannot apply to floating point.  The only way to ordinarily get
data in/out is to use the built-in conversion routines.  The language was
never designed, AFAIK, to directly manipulate floating point bits.

> Fancy
> optimizations are not to be trusted on assembly code; never be afraid
> to turn them off. You probably don’t need them, anyway. :)
> 

Certainly true.  But in this case, -fno-strict-aliasing is absolutely
necessary.

Also, I, as probably most others, would rather not concentrate so much
on the compiler as on the task of coding itself.

Frank Peters

Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Mark Knecht]

On Thu, Jun 30, 2011 at 6:23 PM, Frank Peters <frank.peters@comcast.net> wrote:
> On Fri, 1 Jul 2011 00:58:46 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>
>>
>> I had wondered if this might be an "undefined behavior" optimization bug,
>>
>
> Well, the amd64 users list may not be the appropriate place to discuss
> C programming, but the problem here stems from attempting to do things
> with C that are not supposed to be done with C.  Such things are aptly
> called "tricks" because they stray away from the convention.
>
> Ideally, I suppose, for these purposes would be to use assembly language
> routines mixed into the C code.  But this is not as easy as with the
> "tricks."
>
> Anyway, I'm glad I presented this issue.  It has definitely improved
> my understanding.  GCC has dozens, if not hundreds, of compile options
> and I know the actual function of only a small few.
>
> Frank Peters
>
>

I think it's completely appropriate for this list. This distro expects
that we put CFLAG options in make.conf so I need to hear about this
stuff even if I don't have to background to completely understand
what's really causing the problem.

- Mark

Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Frank Peters]

On Thu, 30 Jun 2011 21:36:38 -0700
Mark Knecht <markknecht@gmail.com> wrote:

> 
> I think it's completely appropriate for this list. This distro expects
> that we put CFLAG options in make.conf so I need to hear about this
> stuff even if I don't have to background to completely understand
> what's really causing the problem.
> 

In this case, or in the case of any program where "-fno-strict-aliasing"
could make a difference, the maintainer of the program would include
the option in the ebuild.  The user would not have to worry too much
about it.

But yes, it is always good to know about the compiler flags.

To see exactly what compile flags are being used in your programs, here
is a neat method I picked up from somewhere.  Just open a terminal and
enter the following command:

echo 'int main(){return 0;}' > test.c && gcc -v -Q $CFLAGS test.c -o test && rm test.c test

In place of $CFLAGS just substitute any option of interest.  There will
be a flood of output, but just scroll back a few lines to find the "options
passed:" and "options enabled:" sections.

For example, using "-O2" for $CFLAGS indicates that "-fstrict-aliasing" is
used, but it is not used with "-O1."

It also shows that with "-O2" the option "-mno-sse4" is used, and so if
you want to use SSE4 for certain programs (e.g. video, audio) you will
need to specifically enable it.

There may be an even slicker way to reveal the flags, but this is the
only way I know.

Frank Peters

[gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Nikos Chantziaras]

On 07/01/2011 04:04 AM, Frank Peters wrote:
> A few days ago I posted about a possible problem with a floating
> point test called the UCBTEST.  After examining the source code
> of this test, I see violations of aliasing rules throughout.
> It's hard to efficiently manipulate variables without them.

You can alias them with a char* (a char pointer can alias everything in 
a valid and defined manner).  What you do is use the char* to scan over 
the target type.  And since a char is always guaranteed to be 8 bits, 
it's very suited for doing endian conversions.

Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems

[Frank Peters]

On Fri, 01 Jul 2011 14:53:45 +0300
Nikos Chantziaras <realnc@arcor.de> wrote:

> 
> You can alias them with a char* (a char pointer can alias everything in 
> a valid and defined manner).  What you do is use the char* to scan over 
> the target type.  And since a char is always guaranteed to be 8 bits, 
> it's very suited for doing endian conversions.
> 

Yes, that's true, but in my case another concern was having data
that is more easily human readable.  A text file full of single-byte
data is harder to read than a file with full 64 or 32 bit strings.

For endian conversions, though, the char pointer is recommended.

But with the availability of the "-fno-strict-aliasing" option it
doesn't seem to matter which method is chosen.