This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Expr constructor question


Here are the details:

This problem is motivated by trying to add the x86 bounds instruction to Greg McGary's bounds checker. The x86 bounds instruction takes two arguments:
bounds reg, [mem]
meaning bounds address, [ptr of <low bounds, high bounds>]
If address exceeds the bounds, an exception occurs.


McGary's bounds checker turns pointers into fat pointers with the representation <ptr, low, high>.

Consider the case of global, statically defined arrays. Its bounds are known at compile time, and with the current McGary infrastructure, it does not create a fat pointer to access the array. To use this bounds instruction I always need to have a bounds object <low bounds, high bounds> allocated in memory and initialized.

My hack is to create a fat pointer from the array base address, and bounds. I then rebind the array identifier name, to the fat pointer. Unfortunately the problem described earlier manifests itself when the "array" (now a pointer) is used as an initializer to another pointer:

int somearray[18]; // hack is to first handle declaration normally, then create a
// fat ptr, and bind somearray name to fat pointer
int* someptr = somearray; // initialization of someptr to fat ptr not allowed.


Anyways the problem described below is the fundamental problem. Though any suggestion to improving code generation of the bounds instruction is very much welcome.

From: Ian Lance Taylor <ian@wasabisystems.com>
To: "Weihaw Chuang" <weihawchuang@hotmail.com>
CC: gcc@gcc.gnu.org
Subject: Re: Expr constructor question
Date: 09 Mar 2004 19:15:06 -0500

"Weihaw Chuang" <weihawchuang@hotmail.com> writes:

> At the highest level, can someone tell me why the following is causes
> an error:
> #include <stdio.h>
> struct record {
>     int a;
> };
>
> struct record object;
> struct record * ptr = &object;
> struct record * ptr2 = ptr;        // <============ problem
>
> int main()
> {
>     printf("done");}
>
> >gcc rec2.c -S
> rec2.c:8: initializer element is not constant

That is an error because in C you are only permitted to initialize a
global variable to a constant.  "&object" is a constant--object is not
going to move at runtime.  "ptr" is not a constant.

The rules are different for C++.  In C++ ptr2 will be initialized
using a static constructor function.  C does not support this usage.


Do you have pointers to the C++ machinery? Which TREE attributes are set to allow the digest_init to work properly?


> Now putting aside C rules, say I want to do use the problem line, and > am willing to assume that ptr2 always has the same value as ptr. > Could I have two identifiers "ptr" and "ptr2" in the front-end point > to the same VAR_DECL record pointer?

I doubt it, but I'm not really sure.  There is no way to express this
sort of notion--variable synonyms--in C, so there is no reason for the
compiler to support it.

> Another route is change the
> declaration mechanism.  The problem here is that there is a great deal
> of guard code in c-typeck.c/digest_init involving TREE_CONSTANT
> checks.  Why are these checks needed?

They are required by the language definition.

What are you really trying to do?  Why not just do
    #define ptr2 ptr


Effectively I'd like to do exactly that, exect I need the parser to discriminate arrays from pointers, and to apply this to pointers initialized to arrays.

?

Ian


-Wei

_________________________________________________________________
Frustrated with dial-up? Lightning-fast Internet access for as low as $29.95/month. http://click.atdmt.com/AVE/go/onm00200360ave/direct/01/



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]