Everyone working on the C side might want to read this article...

Everyone working on the C side might want to read this article...

[Rob Browning]

The following article explains gcc changes that may be behind at least
some of our recent set of bugs:

  http://www.ddj.com/documents/s=880/ddj0010d/0010d.htm

You may not need to read it if you're already familiar with what the C
standard says about type aliasing, or already know that (for example)
according to the standard this code is illegal and the results are
undefined:

   double d = 3.0;
   int* ip = (int*) &d;
   *ip = 7;

or if you know that an optimizer is within its rights according to the
standard to translate this:code:

  double d = 2.0;
  int *ip = (int*) &d;
  *ip = 3;
  d *= 2;

into this code:

  double d = 2.0;
  int *ip = (int*) &d;
  d *= 2;
  *ip = 3;

Thanks to Marius for tracking the pointer down.  I'm not yet sure what
this means for our code.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Everyone working on the C side might want to read this article...

[Bruce Korb]

Rob Browning wrote:
> 
> The following article explains gcc changes that may be behind at least
> some of our recent set of bugs:
> 
>   http://www.ddj.com/documents/s=880/ddj0010d/0010d.htm
> 
> You may not need to read it if you're already familiar with what the C
> standard says about type aliasing,

It means try turning off strict aliasing rules (like the Linux kernel)
and see if it behaves better:  -fno-strict-aliasing


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Everyone working on the C side might want to read this article...

[Dale P. Smith]

On Thu, 17 Apr 2003 15:00:22 -0500
Rob Browning <rlb@defaultvalue.org> wrote:

> 
> The following article explains gcc changes that may be behind at least
> some of our recent set of bugs:
> 
>   http://www.ddj.com/documents/s=880/ddj0010d/0010d.htm
> 
> You may not need to read it if you're already familiar with what the C
> standard says about type aliasing, or already know that (for example)
> according to the standard this code is illegal and the results are
> undefined:

[ code examples ]

> Thanks to Marius for tracking the pointer down.  I'm not yet sure what
> this means for our code.


Some time ago, some effort was put into guile to use unions and structs
as the type for SCM to provide much more robust type checking from the
compiler.  Unfortunately, that code is almost worthless except for
debugging because of the way structs are returned, iirc.

Does this situation change at all with gcc >= 3 and the new c99 standard?


-Dale

-- 
Dale P. Smith
Senior Systems Consultant,      | Treasurer,
Altus Technologies Corporation  | Cleveland Linux Users Group
dsmith at altustech dot com     | http://cleveland.lug.net
440-746-9000 x239               |


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Everyone working on the C side might want to read this article...

[Rob Browning]

Rob Browning <rlb@defaultvalue.org> writes:

> The following article explains gcc changes that may be behind at least
> some of our recent set of bugs:
>
>   http://www.ddj.com/documents/s=880/ddj0010d/0010d.htm

So does anyone have thoughts about how we should approach this issue?
How common do we think these type aliasing problems might be in our
code, and if we do have problems, can we just fix each offending bit
of code with temp assignments or other "disambiguating" statements, or
is there some higher level way we might be able to address the issue
(i.e. could a union help here, something else?).

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Everyone working on the C side might want to read this article...

[Bruce Korb]

Rob Browning wrote:
> 
> Rob Browning <rlb@defaultvalue.org> writes:
> 
> > The following article explains gcc changes that may be behind at least
> > some of our recent set of bugs:
> >
> >   http://www.ddj.com/documents/s=880/ddj0010d/0010d.htm
> 
> So does anyone have thoughts about how we should approach this issue?
> How common do we think these type aliasing problems might be in our
> code, and if we do have problems, can we just fix each offending bit
> of code with temp assignments or other "disambiguating" statements, or
> is there some higher level way we might be able to address the issue
> (i.e. could a union help here, something else?).

The default optimization is sufficient for many of the aliasing
problems.  If you compile with the GCC 3.3 branch -Wall will trigger
some extra aliasing-related warnings.  Examine the warnings carefully.
Remember that just because it didn't warn doesn't mean there isn't
a problem.  However, the warnings do actually cover most of the common
ways aliasing breaks code.  WRT how to fix, there are several solutions:

1.  you can go the way of the kernel and -fno-strict-aliasing
2.  you can unionize the pointer types
3.  you can use the "I can point to anything" pointer types
    viz., char* and void*.

A sure fire test, once you've discovered a problem, is to
try rebuilding with -fno-strict-aliasing and see if the
problem goes away.


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel

Re: Everyone working on the C side might want to read this article...

[Rob Browning]

Bruce Korb <bkorb@veritas.com> writes:

> The default optimization is sufficient for many of the aliasing
> problems.  If you compile with the GCC 3.3 branch -Wall will trigger
> some extra aliasing-related warnings.  Examine the warnings carefully.
> Remember that just because it didn't warn doesn't mean there isn't
> a problem.  However, the warnings do actually cover most of the common
> ways aliasing breaks code.

Anyone running Debian who's interested in working on this, try

  # apt-get install gcc-3.3

  $ cd src/guile/head/
  $ CC=gcc-3.3 ./configure ...
  $ make clean
  $ make

This shouldn't affect your existing gcc 3.2 install, i.e. gcc
--version should still give you 3.2...

We use -Wall -Werror by default now (in the unstable branch), so
you'll get those options automatically.  From an initial test, it
looks like we've at least got a new slew of signed/unsigned compare
warnings.

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel