public inbox for gentoo-amd64@lists.gentoo.org
 help / color / mirror / Atom feed
* Re: [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems
@ 2011-07-01  2:30 Ian McCulloch
  0 siblings, 0 replies; 18+ messages in thread
From: Ian McCulloch @ 2011-07-01  2:30 UTC (permalink / raw
  To: gentoo-amd64@lists.gentoo.org


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



^ permalink raw reply	[flat|nested] 18+ messages in thread
* [gentoo-amd64] GCC-4.5.2 Has Serious Problems
@ 2011-06-30 21:45 Frank Peters
  2011-06-30 23:35 ` [gentoo-amd64] " Nikos Chantziaras
  0 siblings, 1 reply; 18+ messages in thread
From: Frank Peters @ 2011-06-30 21:45 UTC (permalink / raw
  To: gentoo-amd64

[-- 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);
}

^ permalink raw reply	[flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-07-01 16:56 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-07-01  2:30 [gentoo-amd64] Re: GCC-4.5.2 Has Serious Problems Ian McCulloch
  -- strict thread matches above, loose matches on Subject: below --
2011-06-30 21:45 [gentoo-amd64] " Frank Peters
2011-06-30 23:35 ` [gentoo-amd64] " Nikos Chantziaras
2011-06-30 23:44   ` Nikos Chantziaras
2011-07-01  0:04     ` Frank Peters
2011-07-01  0:11       ` Nikos Chantziaras
2011-07-01  0:58         ` Duncan
2011-07-01  1:23           ` Frank Peters
2011-07-01  1:52             ` Duncan
2011-07-01  2:15             ` Ian McCulloch
2011-07-01  4:36             ` Mark Knecht
2011-07-01  5:22               ` Frank Peters
2011-07-01  0:25     ` Frank Peters
2011-07-01  1:04     ` Frank Peters
2011-07-01  2:18       ` Duncan
2011-07-01  2:22       ` Barry Schwartz
2011-07-01  2:43         ` Frank Peters
2011-07-01 11:53       ` Nikos Chantziaras
2011-07-01 16:53         ` Frank Peters

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox