Re: strict aliasing: cast from char[] or char *
Please send questions about using GCC to gcc-h...@gcc.gnu.org, this mailing list is for discussing development of GCC, thanks. On 7 June 2011 04:51, Herman, Geza wrote: > > Here, gcc warns on the reinterpret_cast line. Which version?
Re: strict aliasing: cast from char[] or char *
On Tue, Jun 7, 2011 at 5:51 AM, Herman, Geza wrote:
> Hi,
>
> Sorry, if it has been discussed before, I found a lot of information on
> strict aliasing in gcc, but nothing about this particular case. I'd like to
> code a custom container class: it has a char[] (or dynamically allocated
> "char *") for storage, putting an element is done with placement new,
> getting an element is done with reinterpret_cast'ing the storage, like this:
>
> #include
>
> struct Something {
> int value;
>
> Something() { value = 42; }
> };
>
> template
> struct Container {
> union {
> char data[sizeof(OBJECT)*MAX_SIZE];
> // here goes a member which ensures proper alignment
> };
> int currentSize;
>
> Container() { currentSize=0; }
>
> void add() {
> new(data+sizeof(OBJECT)*currentSize) OBJECT;
> currentSize++;
> }
>
> OBJECT &operator[](int index) {
> // assert(index return reinterpret_cast(data)[index]; // gcc warns here
> }
> };
>
> void bar() {
> Container c;
> c.add();
> c[0].value = 41;
> }
>
> Here, gcc warns on the reinterpret_cast line. However, as I understand,
> this usage cannot cause any harm. If I always access "data" as "OBJECT",
> nothing can go wrong, right? Even, if I access "data" as char sometimes,
> gcc should handle this case, I think. Of course, if "data" would be a
> non-char array, the situation would be different. Is the warning
> appropriate here? Can a cast from char[] cause anything bad? If it's
> difficult to detect this usage method on the compiler side, is there any way
> to avoid this warning just for this line (maybe rephrasing this line somehow
> to tell gcc that everything is OK)?
The code looks ok and should work fine with GCC 4.5 and newer. No
guarantees for older versions though, if it works there it certainly isn't
by design.
Richard.
> Thanks,
> Geza
>
Adding arm-apple-darwin target
Hello, I have come to rely on C++0x support in GCC 4.6 and later. Until clang has feature parity with GCC 4.6, GCC seems to be my only choice for a darwin compiler. As I need to support iPhone it would seem arm-apple-darwin would be the correct target. Would there be any interest in a patch porting arm-apple-darwin target from Apple GCC into mainline, and is it legally possible? Regards, Erik
What should I do to make gcc support PIC code?
Hi all, If I want make a GNU Toolchain support PIC code and Dynamic link, do I need do some work on gcc? If I do need. What should I do? Thanks --Liu
Re: strict aliasing: cast from char[] or char *
On Tue, Jun 7, 2011 at 2:58 PM, Herman, Geza wrote:
> On 06/07/2011 12:27 PM, Richard Guenther wrote:
>>
>> On Tue, Jun 7, 2011 at 5:51 AM, Herman, Geza wrote:
>>>
>>> Hi,
>>>
>>> Sorry, if it has been discussed before, I found a lot of information on
>>> strict aliasing in gcc, but nothing about this particular case. I'd like
>>> to
>>> code a custom container class: it has a char[] (or dynamically allocated
>>> "char *") for storage, putting an element is done with placement new,
>>> getting an element is done with reinterpret_cast'ing the storage, like
>>> this:
>>>
>>> #include
>>>
>>> struct Something {
>>> int value;
>>>
>>> Something() { value = 42; }
>>> };
>>>
>>> template
>>> struct Container {
>>> union {
>>> char data[sizeof(OBJECT)*MAX_SIZE];
>>> // here goes a member which ensures proper alignment
>>> };
>>> int currentSize;
>>>
>>> Container() { currentSize=0; }
>>>
>>> void add() {
>>> new(data+sizeof(OBJECT)*currentSize) OBJECT;
>>> currentSize++;
>>> }
>>>
>>> OBJECT&operator[](int index) {
>>> // assert(index>> return reinterpret_cast(data)[index]; // gcc warns here
>>> }
>>> };
>>>
>>> void bar() {
>>> Container c;
>>> c.add();
>>> c[0].value = 41;
>>> }
>>>
>>> Here, gcc warns on the reinterpret_cast line. However, as I understand,
>>> this usage cannot cause any harm. If I always access "data" as "OBJECT",
>>> nothing can go wrong, right? Even, if I access "data" as char sometimes,
>>> gcc should handle this case, I think. Of course, if "data" would be a
>>> non-char array, the situation would be different. Is the warning
>>> appropriate here? Can a cast from char[] cause anything bad? If it's
>>> difficult to detect this usage method on the compiler side, is there any
>>> way
>>> to avoid this warning just for this line (maybe rephrasing this line
>>> somehow
>>> to tell gcc that everything is OK)?
>>
>> The code looks ok and should work fine with GCC 4.5 and newer. No
>> guarantees for older versions though, if it works there it certainly isn't
>> by design.
>
> Thanks for the answer!
>
> You're right, this example compiles without warnings with GCC 4.5. My
> mistake, I copied a version which warns only with GCC 4.4 in my previous
> email. But, if I add another member function, like:
>
> OBJECT &first() {
> return reinterpret_cast(data)[0]; // gcc warns here
> }
>
> and call it from "bar()":
>
> c.first().value = 41;
>
> I tried both GCC 4.5, and the latest available in my system (gcc version
> 4.7.0 20110531 (experimental) [trunk revision 174470]), both produces a
> warning. Is it a false positive warning?
Yes.
Richard.
> Luckily, generated code works, even with previous versions of GCC.
>
>>
>> Richard.
>>
>>> Thanks,
>>> Geza
>>>
>
>
Re: strict aliasing: cast from char[] or char *
On 06/07/2011 12:27 PM, Richard Guenther wrote:
On Tue, Jun 7, 2011 at 5:51 AM, Herman, Geza wrote:
Hi,
Sorry, if it has been discussed before, I found a lot of information on
strict aliasing in gcc, but nothing about this particular case. I'd like to
code a custom container class: it has a char[] (or dynamically allocated
"char *") for storage, putting an element is done with placement new,
getting an element is done with reinterpret_cast'ing the storage, like this:
#include
struct Something {
int value;
Something() { value = 42; }
};
template
struct Container {
union {
char data[sizeof(OBJECT)*MAX_SIZE];
// here goes a member which ensures proper alignment
};
int currentSize;
Container() { currentSize=0; }
void add() {
new(data+sizeof(OBJECT)*currentSize) OBJECT;
currentSize++;
}
OBJECT&operator[](int index) {
// assert(index(data)[index]; // gcc warns here
}
};
void bar() {
Container c;
c.add();
c[0].value = 41;
}
Here, gcc warns on the reinterpret_cast line. However, as I understand,
this usage cannot cause any harm. If I always access "data" as "OBJECT",
nothing can go wrong, right? Even, if I access "data" as char sometimes,
gcc should handle this case, I think. Of course, if "data" would be a
non-char array, the situation would be different. Is the warning
appropriate here? Can a cast from char[] cause anything bad? If it's
difficult to detect this usage method on the compiler side, is there any way
to avoid this warning just for this line (maybe rephrasing this line somehow
to tell gcc that everything is OK)?
The code looks ok and should work fine with GCC 4.5 and newer. No
guarantees for older versions though, if it works there it certainly isn't
by design.
Thanks for the answer!
You're right, this example compiles without warnings with GCC 4.5. My
mistake, I copied a version which warns only with GCC 4.4 in my previous
email. But, if I add another member function, like:
OBJECT &first() {
return reinterpret_cast(data)[0]; // gcc warns here
}
and call it from "bar()":
c.first().value = 41;
I tried both GCC 4.5, and the latest available in my system (gcc version
4.7.0 20110531 (experimental) [trunk revision 174470]), both produces a
warning. Is it a false positive warning?
Luckily, generated code works, even with previous versions of GCC.
Richard.
Thanks,
Geza
Re: Adding arm-apple-darwin target
Erik Olofsson writes: > I have come to rely on C++0x support in GCC 4.6 and later. Until clang has > feature parity with GCC 4.6, GCC seems to be my only choice for a darwin > compiler. > > As I need to support iPhone it would seem arm-apple-darwin would be the > correct target. > > Would there be any interest in a patch porting arm-apple-darwin target from > Apple GCC into mainline, and is it legally possible? Yes, we would like to have better arm-darwin support. No, you probably do not have permission to port Apple's patches into the gcc source code, unless Apple explicitly grants you that permission. Ian
Re: What should I do to make gcc support PIC code?
Liu writes: > If I want make a GNU Toolchain support PIC code and Dynamic link, > do I need do some work on gcc? > If I do need. What should I do? The GNU toolchain supports PIC and dynamic linking by default. Are you talking about some new gcc target? If so, you need to give us more details. Ian
Re: What should I do to make gcc support PIC code?
On Tue, Jun 7, 2011 at 9:20 PM, Ian Lance Taylor wrote: > Liu writes: > >> If I want make a GNU Toolchain support PIC code and Dynamic link, >> do I need do some work on gcc? >> If I do need. What should I do? > > The GNU toolchain supports PIC and dynamic linking by default. Are you > talking about some new gcc target? If so, you need to give us more > details. > > Ian > Thank you for reply, Ian. Yes, I am working on a new gcc target, it almost finished but PIC and dynamic linking. They want me make the toolchain support PIC and dynamic linking. I'm not sure what should I do, will you show me a path? Thanks again, --Liu
Re: strict aliasing: cast from char[] or char *
On 06/07/2011 03:02 PM, Richard Guenther wrote:
On Tue, Jun 7, 2011 at 2:58 PM, Herman, Geza wrote:
On 06/07/2011 12:27 PM, Richard Guenther wrote:
On Tue, Jun 7, 2011 at 5:51 AM, Herman, Gezawrote:
Hi,
Sorry, if it has been discussed before, I found a lot of information on
strict aliasing in gcc, but nothing about this particular case. I'd like
to
code a custom container class: it has a char[] (or dynamically allocated
"char *") for storage, putting an element is done with placement new,
getting an element is done with reinterpret_cast'ing the storage, like
this:
#include
struct Something {
int value;
Something() { value = 42; }
};
template
struct Container {
union {
char data[sizeof(OBJECT)*MAX_SIZE];
// here goes a member which ensures proper alignment
};
int currentSize;
Container() { currentSize=0; }
void add() {
new(data+sizeof(OBJECT)*currentSize) OBJECT;
currentSize++;
}
OBJECT&operator[](int index) {
// assert(index(data)[index]; // gcc warns here
}
};
void bar() {
Containerc;
c.add();
c[0].value = 41;
}
Here, gcc warns on the reinterpret_cast line. However, as I understand,
this usage cannot cause any harm. If I always access "data" as "OBJECT",
nothing can go wrong, right? Even, if I access "data" as char sometimes,
gcc should handle this case, I think. Of course, if "data" would be a
non-char array, the situation would be different. Is the warning
appropriate here? Can a cast from char[] cause anything bad? If it's
difficult to detect this usage method on the compiler side, is there any
way
to avoid this warning just for this line (maybe rephrasing this line
somehow
to tell gcc that everything is OK)?
The code looks ok and should work fine with GCC 4.5 and newer. No
guarantees for older versions though, if it works there it certainly isn't
by design.
Thanks for the answer!
You're right, this example compiles without warnings with GCC 4.5. My
mistake, I copied a version which warns only with GCC 4.4 in my previous
email. But, if I add another member function, like:
OBJECT&first() {
return reinterpret_cast(data)[0]; // gcc warns here
}
and call it from "bar()":
c.first().value = 41;
I tried both GCC 4.5, and the latest available in my system (gcc version
4.7.0 20110531 (experimental) [trunk revision 174470]), both produces a
warning. Is it a false positive warning?
Yes.
Okay :)
Here's my last question (I hope). As GCC cannot know the usage pattern
of char[], it's good that it emits a warning. For example, if we'd
remove the warning (just for the case where char[] is casted), this case
wouldn't get a warning, and would generate incorrect code:
char data[...];
reinterpret_cast(data) = 1;
printf("%d\n", reinterpret_cast(data));
However, for my construct, which appears to be completely legal, I get a
warning, which I'd like to disable. How can I do that? Currently I'm
using -Wno-strict-aliasing, but I'd like to have a better solution. I
tried to cast (void*) before the cast to (OBJECT*), it didn't help. Is
it possible to disable this warning for this line only (maybe with some
GCC specific tricks)?
Thanks,
Geza
Richard.
Luckily, generated code works, even with previous versions of GCC.
Richard.
Thanks,
Geza
Re: strict aliasing: cast from char[] or char *
On 7 June 2011 15:05, Herman, Geza wrote: > > However, for my construct, which appears to be completely legal, I get a > warning, which I'd like to disable. How can I do that? Currently I'm using > -Wno-strict-aliasing, but I'd like to have a better solution. I tried to > cast (void*) before the cast to (OBJECT*), it didn't help. Is it possible > to disable this warning for this line only (maybe with some GCC specific > tricks)? You might be able to use these: http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html N.B. the push/pop functionality was added in GCC 4.6 and the places where #pragma GCC diagnostic could appear in your source file was more limited before GCC 4.6, see the 4.4 and 4.5 manuals for details.
Re: strict aliasing: cast from char[] or char *
On Tue, Jun 7, 2011 at 4:05 PM, Herman, Geza wrote:
> On 06/07/2011 03:02 PM, Richard Guenther wrote:
>>
>> On Tue, Jun 7, 2011 at 2:58 PM, Herman, Geza wrote:
>>>
>>> On 06/07/2011 12:27 PM, Richard Guenther wrote:
On Tue, Jun 7, 2011 at 5:51 AM, Herman, Geza wrote:
>
> Hi,
>
> Sorry, if it has been discussed before, I found a lot of information on
> strict aliasing in gcc, but nothing about this particular case. I'd
> like
> to
> code a custom container class: it has a char[] (or dynamically
> allocated
> "char *") for storage, putting an element is done with placement new,
> getting an element is done with reinterpret_cast'ing the storage, like
> this:
>
> #include
>
> struct Something {
> int value;
>
> Something() { value = 42; }
> };
>
> template
> struct Container {
> union {
> char data[sizeof(OBJECT)*MAX_SIZE];
> // here goes a member which ensures proper alignment
> };
> int currentSize;
>
> Container() { currentSize=0; }
>
> void add() {
> new(data+sizeof(OBJECT)*currentSize) OBJECT;
> currentSize++;
> }
>
> OBJECT&operator[](int index) {
> // assert(index return reinterpret_cast(data)[index]; // gcc warns here
> }
> };
>
> void bar() {
> Container c;
> c.add();
> c[0].value = 41;
> }
>
> Here, gcc warns on the reinterpret_cast line. However, as I
> understand,
> this usage cannot cause any harm. If I always access "data" as
> "OBJECT",
> nothing can go wrong, right? Even, if I access "data" as char
> sometimes,
> gcc should handle this case, I think. Of course, if "data" would be a
> non-char array, the situation would be different. Is the warning
> appropriate here? Can a cast from char[] cause anything bad? If it's
> difficult to detect this usage method on the compiler side, is there
> any
> way
> to avoid this warning just for this line (maybe rephrasing this line
> somehow
> to tell gcc that everything is OK)?
The code looks ok and should work fine with GCC 4.5 and newer. No
guarantees for older versions though, if it works there it certainly
isn't
by design.
>>>
>>> Thanks for the answer!
>>>
>>> You're right, this example compiles without warnings with GCC 4.5. My
>>> mistake, I copied a version which warns only with GCC 4.4 in my previous
>>> email. But, if I add another member function, like:
>>>
>>> OBJECT&first() {
>>> return reinterpret_cast(data)[0]; // gcc warns here
>>> }
>>>
>>> and call it from "bar()":
>>>
>>> c.first().value = 41;
>>>
>>> I tried both GCC 4.5, and the latest available in my system (gcc version
>>> 4.7.0 20110531 (experimental) [trunk revision 174470]), both produces a
>>> warning. Is it a false positive warning?
>>
>> Yes.
>
> Okay :)
>
> Here's my last question (I hope). As GCC cannot know the usage pattern of
> char[], it's good that it emits a warning. For example, if we'd remove the
> warning (just for the case where char[] is casted), this case wouldn't get a
> warning, and would generate incorrect code:
>
> char data[...];
> reinterpret_cast(data) = 1;
> printf("%d\n", reinterpret_cast(data));
>
> However, for my construct, which appears to be completely legal, I get a
> warning, which I'd like to disable. How can I do that? Currently I'm using
> -Wno-strict-aliasing, but I'd like to have a better solution. I tried to
> cast (void*) before the cast to (OBJECT*), it didn't help. Is it possible
> to disable this warning for this line only (maybe with some GCC specific
> tricks)?
Try
void *temp = (void *)data;
reinterpret_cast(temp)
Richard.
> Thanks,
> Geza
>
>>
>> Richard.
>>
>>> Luckily, generated code works, even with previous versions of GCC.
>>>
Richard.
> Thanks,
> Geza
>
>>>
>>>
>
>
[google] Merged google/main -> google/gcc-4_6
This merge brings google/gcc-4_6 up to rev 174706. Validated on x86_64. Diego.
Re: strict aliasing: cast from char[] or char *
On 7 June 2011 15:20, Richard Guenther wrote: >> >> However, for my construct, which appears to be completely legal, I get a >> warning, which I'd like to disable. How can I do that? Currently I'm using >> -Wno-strict-aliasing, but I'd like to have a better solution. I tried to >> cast (void*) before the cast to (OBJECT*), it didn't help. Is it possible >> to disable this warning for this line only (maybe with some GCC specific >> tricks)? > > Try > > void *temp = (void *)data; > reinterpret_cast(temp) Should that be static_cast not reinterpret_cast? A reinterpret_cast from void* is technically undefined in C++03, see http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1120 and http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/reinterpret-cast-and-pointer-to-void.html Although GCC will do the right thing, if a static_cast will suffice then it should generally be preferred to reinterpret_cast.
Re: strict aliasing: cast from char[] or char *
On Tue, Jun 7, 2011 at 4:31 PM, Jonathan Wakely wrote: > On 7 June 2011 15:20, Richard Guenther wrote: >>> >>> However, for my construct, which appears to be completely legal, I get a >>> warning, which I'd like to disable. How can I do that? Currently I'm using >>> -Wno-strict-aliasing, but I'd like to have a better solution. I tried to >>> cast (void*) before the cast to (OBJECT*), it didn't help. Is it possible >>> to disable this warning for this line only (maybe with some GCC specific >>> tricks)? >> >> Try >> >> void *temp = (void *)data; >> reinterpret_cast(temp) > > Should that be static_cast not reinterpret_cast? > > A reinterpret_cast from void* is technically undefined in C++03, see > http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1120 and > http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/reinterpret-cast-and-pointer-to-void.html > > Although GCC will do the right thing, if a static_cast will suffice > then it should generally be preferred to reinterpret_cast. I thought static_cast might do pointer adjustments while reinterpret_cast will never do that but is value-preserving. Richard.
Re: What should I do to make gcc support PIC code?
Liu writes: > Yes, I am working on a new gcc target, it almost finished but PIC and > dynamic linking. > They want me make the toolchain support PIC and dynamic linking. I'm > not sure what should I do, will you show me a path? [ Sorry for my earlier reply, I see now that you did also reply to the mailing list. ] The first and most important thing you need to do is work out the ABI for position independent code and dynamic linking. This is not a gcc issue. It will depend entirely on how your processor works. You need to design code sequences for position independent function calls and access to global variables. I recommend reading one of the ELF processor supplements--several are available online--to see how they generally work. There is also a short introduction to these ideas at http://www.airs.com/blog/archives/41 . Once you've figured out what code you need to generate, then you can think about how to represent it in gcc. Ian
Re: What should I do to make gcc support PIC code?
On Tue, Jun 7, 2011 at 10:52 PM, Ian Lance Taylor wrote: > Liu writes: > >> Yes, I am working on a new gcc target, it almost finished but PIC and >> dynamic linking. >> They want me make the toolchain support PIC and dynamic linking. I'm >> not sure what should I do, will you show me a path? > > [ Sorry for my earlier reply, I see now that you did also reply to the > mailing list. ] > > The first and most important thing you need to do is work out the ABI > for position independent code and dynamic linking. This is not a gcc > issue. It will depend entirely on how your processor works. You need > to design code sequences for position independent function calls and > access to global variables. I recommend reading one of the ELF > processor supplements--several are available online--to see how they > generally work. There is also a short introduction to these ideas at > http://www.airs.com/blog/archives/41 . > > Once you've figured out what code you need to generate, then you can > think about how to represent it in gcc. > > Ian > Thank you Ian. I'll read your blog and find a simple and complete port to read. Liu
[gimplefe] update your local trees
Ketaki, Sandeep, My last merge from trunk into gimple-front-end was incomplete. I just realized that I had failed to commit several directories. I just committed a fix, so please make sure that your local checkout is at rev 174754. Diego.
Re: strict aliasing: cast from char[] or char *
On 7 June 2011 15:39, Richard Guenther wrote: > On Tue, Jun 7, 2011 at 4:31 PM, Jonathan Wakely wrote: >> On 7 June 2011 15:20, Richard Guenther wrote: However, for my construct, which appears to be completely legal, I get a warning, which I'd like to disable. How can I do that? Currently I'm using -Wno-strict-aliasing, but I'd like to have a better solution. I tried to cast (void*) before the cast to (OBJECT*), it didn't help. Is it possible to disable this warning for this line only (maybe with some GCC specific tricks)? >>> >>> Try >>> >>> void *temp = (void *)data; >>> reinterpret_cast(temp) >> >> Should that be static_cast not reinterpret_cast? >> >> A reinterpret_cast from void* is technically undefined in C++03, see >> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1120 and >> http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/reinterpret-cast-and-pointer-to-void.html >> >> Although GCC will do the right thing, if a static_cast will suffice >> then it should generally be preferred to reinterpret_cast. > > I thought static_cast might do pointer adjustments while reinterpret_cast > will never do that but is value-preserving. static_cast won't do adjustments for casts to/from void, only for pointers to object types. In C++0x the reinterpret_cast(temp) above is defined to be the same as: static_cast(static_cast(temp)) and obviously the first static_cast does nothing because it's already void*, so only the second is needed. Feel free to ignore me - the fact reinterpret_cast doesn't work with void is a defect in the standard that was only discovered quite recently and has been corrected for C++0x, so I'm mostly being pedantic and you can forget I said anything :)
[google] Merged gcc-4_6-branch -> google/gcc-4_6
This brings google/gcc-4_6 up to rev 174748. Validated on x86_64. Diego.
gcc-4.4-20110607 is now available
Snapshot gcc-4.4-20110607 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20110607/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 174777 You'll find: gcc-4.4-20110607.tar.bz2 Complete GCC MD5=7ca744af1900dd35ce52b9db77fcfe6e SHA1=94da649f63d5f5a734f4d01a4159f6b44652f393 Diffs from 4.4-20110531 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
RE: Adding elements into tree data structure
Hello Ian and Everyone,
Here is my problem specifically. I apologize in advance if this email is
long.
I am trying to mark all for loop *top* labels with a integer value.
This integer value is an index to another data structure that I'm trying to
maintain.
I just added the index value (as unsigned int) into the following data
structure (in tree.h):
struct GTY(()) tree_label_decl {
struct tree_decl_with_rtl common;
int label_decl_uid;
int eh_landing_pad_nr;
unsigned int My_INDEX; /* <== THIS IS WHAT I AM TRYING TO DO */
};
I put the above modification and then I set My_INDEX in the "top" tree (top is
created using build1(LABEL_EXPR, void_type_node, NULL_TREE)) in the
c_finish_loop() and tried to reconfigure & build the gcc. Now, it is crashing
when it is trying to compile the files using "prev-gcc/xgcc" (mainly at the
gimplification phase).
I tried to gdb through the cc1 executable and did a tree dump (using
"debug_function" and "debug_c_tree" commands when I was using gdb) and it is
converting some labels into <<>> or .
If I comment out the line where I am setting the My_INDEX, the gcc builds and
works correctly. I am accessing My_INDEX on top as: top->label_decl.My_INDEX
Is there any other files, functions or structures I need to modify for me to
add and use My_INDEX? Also, am I accessing the "My_INDEX" correctly?
I am using gcc-4.6
Any help is highly appreciated!
Thanking You,
Yours Sincerely,
Balaji V. Iyer.
PS. Please CC me when you reply this message.
-Original Message-
From: Ian Lance Taylor [mailto:i...@google.com]
Sent: Monday, May 09, 2011 7:34 PM
To: Iyer, Balaji V
Cc: gcc@gcc.gnu.org
Subject: Re: Adding elements into tree data structure
"Iyer, Balaji V" writes:
> I would like to add 8 integer array fields (I am also OK if they are
> tree-lists) into the tree data structure. I want to update this fields every
> time I see loops. This value will be used later by the optimizer. I tried to
> just add them into the structure in tree.h (under struct tree_base) and it is
> seg-faulting. I am using GCC 4.6.0.
>
> Can someone please tell me the procedure for adding elements into the
> tree structure?
Hard to say what is wrong without more information. Make sure that
tree_code_size returns the right values. But really I would recommend
just using the debugger to find out what is causing the segfault.
Ian
Re: Adding elements into tree data structure
"Iyer, Balaji V" writes:
> I am trying to mark all for loop *top* labels with a integer value.
> This integer value is an index to another data structure that I'm trying to
> maintain.
>
>I just added the index value (as unsigned int) into the following data
> structure (in tree.h):
>
> struct GTY(()) tree_label_decl {
> struct tree_decl_with_rtl common;
> int label_decl_uid;
> int eh_landing_pad_nr;
> unsigned int My_INDEX; /* <== THIS IS WHAT I AM TRYING TO DO */
> };
>
> I put the above modification and then I set My_INDEX in the "top" tree (top
> is created using build1(LABEL_EXPR, void_type_node, NULL_TREE)) in the
> c_finish_loop() and tried to reconfigure & build the gcc. Now, it is crashing
> when it is trying to compile the files using "prev-gcc/xgcc" (mainly at the
> gimplification phase).
The variable top in c_finish_loop is a LABEL_EXPR. tree_label_decl is
used for a LABEL_DECL. If you are realliy seeing My_INDEX for top, then
1) you are doing something wrong; 2) I don't understand how that could
work at all. What does the actual code in c_finish_loop look like?
A tip: after adding your field to tree_label_decl, #define
LABEL_DECL_MY_INDEX along the lines of LABEL_DECL_UID and friends. In
particular, make sure you use LABEL_DECL_CHECK. Then always access the
field using LABEL_DECL_MY_INDEX. And make sure that you configure with
--enable-checking; --enable-checking is the default in the development
sources, but in the release sources the default is
--enable-checking=release. You want --enable-checking, not
--enable-checking=release. Doing that will cause gcc to abort if you
ever try to access your new field incorrectly.
Ian
autogen version testing in fixincludes/genfixes
Hello
With the autogen (GNU AutoGen) 5.11.9 on my Linux/Debian/Sid (or
perhaps /Experimental) the genfixes script fail, because of the version
test.
The following patch corrects that.
Index: fixincludes/genfixes
===
--- fixincludes/genfixes(revision 174734)
+++ fixincludes/genfixes(working copy)
@@ -62,7 +62,7 @@
AG="autogen $AG"
set -e
-if [ -z "`${AG} -v | fgrep 'Ver. 5.'`" ]
+if [ -z "`${AG} -v | fgrep ' 5.'`" ]
then
echo "AutoGen appears to be out of date or not correctly installed."
echo "Please download and install:"
Should I submit the patch, or is there something I missed?
Why do we test the Ver. string ???
Regards.
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***
