JavaScript is required to for searching.
Skip Navigation Links
Exit Print View
Oracle Solaris Studio 12.2: C User's Guide
search filter icon
search icon

Document Information

Preface

1.  Introduction to the C Compiler

2.  C-Compiler Implementation-Specific Information

3.  Parallelizing C Code

4.  lint Source Code Checker

5.  Type-Based Alias Analysis

5.1 Introduction to Type-Based Analysis

5.2 Using Pragmas for Finer Control

5.2.1 #pragma alias_level level (list)

5.2.1.1 #pragma alias (type, type [, type]...)

5.2.1.2 #pragma alias (pointer, pointer [, pointer]...)

5.2.1.3 #pragma may_point_to (pointer, variable [, variable]...)

5.2.1.4 #pragma noalias (type, type [, type]...)

5.2.1.5 #pragma noalias (pointer, pointer [, pointer]...)

5.2.1.6 #pragma may_not_point_to (pointer, variable [, variable]...)

5.3 Checking With lint

5.3.1 Struct Pointer Cast of Scalar Pointer

5.3.2 Struct Pointer Cast of Void Pointer

5.3.3 Cast of Struct Field to Structure Pointer

5.3.4 Explicit Aliasing Required

5.4 Examples of Memory Reference Constraints

5.4.1 First Example

5.4.2 Second Example

5.4.3 Third Example

5.4.4 Fourth Example

5.4.5 Fifth Example

5.4.6 Sixth Example

5.4.7 Seventh Example

6.  Transitioning to ISO C

7.  Converting Applications for a 64-Bit Environment

8.  cscope: Interactively Examining a C Program

A.  Compiler Options Grouped by Functionality

B.  C Compiler Options Reference

C.  Implementation-Defined ISO/IEC C99 Behavior

D.  Supported Features of C99

E.  Implementation-Defined ISO/IEC C90 Behavior

F.  ISO C Data Representations

G.  Performance Tuning

H.  The Differences Between K&R Solaris Studio C and Solaris Studio ISO C

Index

5.4 Examples of Memory Reference Constraints

This section provides examples of code that are likely to appear in your source files. Each example is followed by a discussion of the compiler’s assumptions about the code as dictated by the applied level of type-based analysis.

5.4.1 First Example

Consider the following code. It can be compiled with different levels of aliasing to demonstrate the aliasing relationship of the shown types.

struct foo {
    int f1;
    short f2;
    short f3;
    int f4;
} *fp;

struct bar {
    int b1;
    int b2;
    int b3;
} *bp;

int *ip;
short *sp;

If this example is compiled with the -xalias_level=any option, the compiler considers the following indirect accesses as aliases to each other:

*ip, *sp, *fp, *bp, fp->f1, fp->f2, fp->f3, fp->f4, bp->b1, bp->b2, bp->b3

If this example is compiled with the -xalias_level=basic option, the compiler considers the following indirect accesses as aliases to each other:

*ip, *bp, fp->f1, fp->f4, bp->b1, bp->b2, bp->b3

Additionally, *sp, fp->f2, and fp->f3 can alias each other, and *sp and *fp can alias each other.

However, under -xalias_level=basic, the compiler assumes the following:

The compiler makes these assumptions because the access types of the two indirect accesses are different basic types.

If this example is compiled with the -xalias_level=weak option, the compiler assumes the following alias information:

The compiler assumes that fp->fp1 does not alias bp->b2 because f1 is a field with offset 0 in a structure, whereas b2 is a field with a 4-byte offset in a structure. Similarly, the compiler assumes that fp->f1 does not alias bp->b3, and fp->f4 does not alias either bp->b1 or bp->b2.

If this example is compiled with the -xalias_level=layout option, the compiler assumes the following information:

fp->f4 does not alias bp->b3 because f4 and b3 are not corresponding fields in the common initial sequence of foo and bar.

If this example is compiled with the -xalias_level=strict option, the compiler assumes the following alias information:

With -xalias_level=strict, the compiler assumes that *fp, *bp, fp->f1, fp->f2, fp->f3, fp->f4, bp->b1, bp->b2, and bp->b3 do not alias each other because foo and bar are not the same when field names are ignored. However, fp aliases fp->f1 and bp aliases bp->b1.

If this example is compiled with the -xalias_level=std option, the compiler assumes the following alias information:

However, fp->f1 does not alias bp->b1, bp->b2, or bp->b3 because foo and bar are not the same when field names are considered.

If this example is compiled with the -xalias_level=strong option, the compiler assumes the following alias information:

5.4.2 Second Example

Consider the following example source code. It demonstrates the aliasing relationship of the shown types when compiled with different levels of aliasing.

struct foo {
    int f1;
    int f2;
    int f3;
} *fp;

struct bar {
    int b1;
    int b2;
    int b3;
} *bp;

If this example is compiled with the -xalias_level=any option, the compiler assumes the following alias information:

*fp, *bp, fp->f1, fp->f2, fp->f3, bp->b1, bp->b2 and bp->b3 all can alias each other because any two memory accesses alias each other at the level of -xalias_level=any.

If this example is compiled with the -xalias_level=basic option, the compiler assumes the following alias information:

*fp, *bp, fp->f1, fp->f2, fp->f3, bp->b1, bp->b2 and bp->b3 all can alias each other. Any two field accesses using pointers *fp and *bp can alias each other in this example because all the structure fields are the same basic type.

If this example is compiled with the -xalias_level=weak option, the compiler assumes the following alias information:

However, -xalias_level=weak imposes the following restrictions:

If this example is compiled with the -xalias_level=layout options, the compiler assumes the following alias information:

However, -xalias_level=layout imposes the following restrictions:

If this example is compiled with the -xalias_level=strict option, the compiler assumes the following alias information:

However, -xalias_level=strict imposes the following restrictions:

If this example is compiled with the -xalias_level=std option, the compiler assumes the following alias information:

fp->f1, fp->f2, fp->f3, bp->b1, bp->b2, and bp->b3 do not alias each other.

If this example is compiled with the -xalias_level=strong option, the compiler assumes the following alias information:

fp->f1, fp->f2, fp->f3, bp->b1, bp->b2, and bp->b3 do not alias each other.

5.4.3 Third Example

Consider the following example source code that demonstrates that certain levels of aliasing cannot handle interior pointers. For a definition of interior pointers see Table B-13.

struct foo {
        int f1;
        struct bar *f2;
        struct bar *f3;
        int f4;
        int f5;
        struct bar fb[10];
} *fp;

struct bar
        struct bar *b2;
        struct bar *b3;
        int b4;
} *bp;

bp=(struct bar*)(&fp->f2);

The dereference in this example is not supported by weak, layout, strict, or std. After the pointer assignment bp=(struct bar*)(&fp->f2), the following pair of memory accesses touches the same memory locations:

However, under options weak, layout, strict, and std, the compiler assumes that fp->f2 and bp->b2 do not alias. The compiler makes this assumption because b2 has an offset of zero, which is different from the offset of f2 (four bytes), and foo and bar do not have a common initial sequence. Similarly, the compiler also assumes that bp->b3 does not alias fp->f3, and bp->b4 does not alias fp->f4.

Thus, the pointer assignment bp=(struct bar*)(&fp->f2)creates a situation in which the compiler’s assumptions about alias information are incorrect. This may lead to incorrect optimization.

Try compiling after you make the modifications shown in the following example.

struct foo {
        int f1;
        struct bar fb;   /* Modified line */
#define f2 fb.b2         /* Modified line */
#define f3 fb.b3         /* Modified line */
#define f4 fb.b4         /* Modified line */
        int f5;
        struct bar fb[10];
} *fp;

struct bar
        struct bar *b2;
        struct bar *b3;
        int b4;
} *bp;

bp=(struct bar*)(&fp->f2);

After the pointer assignment bp=(struct bar*)(&fp->f2), the following pair of memory accesses touches the same memory locations:

By examining the changes shown in the preceding code example, you can see that the expression fp->f2 is another form of the expression fp->fb.b2. Because fp->fb is of type bar, fp->f2 accesses the b2 field of bar. Furthermore, bp->b2 also accesses the b2 field of bar. Therefore, the compiler assumes that fp->f2 aliases bp->b2. Similarly, the compiler assumes that fp->f3 aliases bp->b3, and fp->f4 aliases bp->b4. As a result, the aliasing assumed by the compiler matches the actual aliases caused by the pointer assignment.

5.4.4 Fourth Example

Consider the following example source code.

struct foo {
        int f1;
        int f2;
} *fp;

struct bar {
        int b1;
        int b2;
} *bp;

struct cat {
        int c1;
        struct foo cf;
        int c2;
        int c3;
} *cp;

struct dog {
        int d1;
        int d2;
        struct bar db;
        int d3;
} *dp;

If this example is compiled with the -xalias_level=weak option, the compiler assumes the following alias information:

fp->f2 can alias cp->c2 because *dp can alias *cp and *fp can alias dp->db.

cp->cf.f1 does not alias dp->db.b1.

cp->c2 does not alias dp->db.b1 and cp->c2 does not alias dp->d3.

With respect to offsets, cp->c2 can alias db->db.b1 only if *dp aliases cp->cf. However, if *dp aliases cp->cf, then dp->db.b1 must alias beyond the end of foo cf, which is prohibited by object restrictions. Therefore, the compiler assumes that cp->c2 cannot alias db->db.b1.

cp->c3 can alias dp->d3.

Notice that cp->c3 does not alias dp->db.b2. These memory references do not alias because the offsets of the fields of the types involved in the dereferences differ and do not overlap. Based on this, the compiler assumes they cannot alias.

Notice that dp->d3 does not alias cp->cf.f2. These memory references do not alias because the offsets of the fields of the types involved in the dereferences differ and do not overlap. Based on this, the compiler assumes they cannot alias.

If this example is compiled with the -xalias_level=layout option, the compiler assumes only the following alias information:

If this example is compiled with the -xalias_level=strict option, the compiler assumes only the following alias information:

If this example is compiled with the -xalias_level=std option, the compiler assumes only the following alias information:

5.4.5 Fifth Example

Consider the following example source code.

struct foo {
        short f1;
        short f2;
        int   f3;
} *fp;

struct bar {
        int b1;
        int b2;
} *bp;

union moo {
        struct foo u_f;
        struct bar u_b;
} u;

Here are the compiler’s assumptions based on the following alias levels:

5.4.6 Sixth Example

Consider the following example source code.

struct bar;

struct foo {
        struct foo *ffp;
        struct bar *fbp;
} *fp;

struct bar {
        struct bar *bbp;
        long        b2;
} *bp;

Here are the compiler’s assumptions based on the following alias levels:

5.4.7 Seventh Example

Consider the following example source code:

struct foo;
struct bar;
#pragma alias (struct foo, struct bar)

struct foo {
        int f1;
        int f2;
} *fp;

struct bar {
        short b1;
        short b2;
        int   b3;
} *bp;

The pragma in this example tells the compiler that foo and bar are allowed to alias each other. The compiler makes the following assumptions about alias information: