gcl-devel
[Top][All Lists]
Advanced

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

Re: [Gcl-devel] 2.5.3 is released


From: Paul F. Dietz
Subject: Re: [Gcl-devel] 2.5.3 is released
Date: Wed, 04 Jun 2003 17:39:48 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Camm Maguire wrote:
Hello again!

One other item - gcc-3.3 has introduced quite a few warnings now in
GCL which I'd like to cleanup.  Most are of the type:

warning: dereferencing type-punned pointer will break strict-aliasing rules

To my limited understanding, this refers to doing things like *(int
*)&a_float_variable.  I suppose the proper thing to do is to use a
union.  I don't understand the implication for the "strict aliasing
rules".  I'd be most appreciative if anyone on this list could
enlighten me as to what deleterious effects constructs such as the
above could produce.


This is related to the -fstrict-aliasing flag.  As I understand it,
this flag was made 'on' by default in gcc 3.3.

From the gcc manual:

-fstrict-aliasing
Allows the compiler to assume the strictest aliasing rules applicable to the language being compiled. For C (and C++), this activates optimizations based on the type of expressions. In particular, an object of one type is assumed never to reside at the same address as an object of a different type, unless the types are almost the same. For example, an unsigned int can alias an int, but not a void* or a double. A character type may alias any other type.

    Pay special attention to code like this:

          union a_union {
            int i;
            double d;
          };

          int f() {
            a_union t;
            t.d = 3.0;
            return t.i;
          }


The practice of reading from a different union member than the one most recently written to (called "type-punning") is common. Even with -fstrict-aliasing, type-punning is allowed, provided the memory is accessed through the union type. So, the code above will work as expected. However, this code might not:

          int f() {
            a_union t;
            int* ip;
            t.d = 3.0;
            ip = &t.i;
            return *ip;
          }


Every language that wishes to perform language-specific alias analysis should define a function that computes, given an tree node, an alias set for the node. Nodes in different alias sets are not allowed to alias. For an example, see the C front-end function c_get_alias_set.

    Enabled at levels -O2, -O3, -Os.

-----

If these warning indicate real potential problems, you can disable this
with -fno-strict-aliasing.

        Paul






reply via email to

[Prev in Thread] Current Thread [Next in Thread]