Getting type used in THROW_EXPR
Hi all, I have yet another question that has arisen as i have started testing my code. Basically I am trying to get the type that is being used in throwing an exception. Is there a simple macro i can use to get the type of an exception from a THROW_EXPR? I think this is a matter of getting the TREE_TYPE for the value passed into the function: except.c: build_throw(tree exp) I have been printing out the TREE_CODE of the node that comes from calling TREE_TYPE(exp) inside that function, and i think from what i can tell this gives the correct value for the type of the exception being thrown (maybe i should also pass it through the prepare_eh_type() function too). The problem is: How do i get a reference to the expression tree passed into the build_throw() method from a THROW_EXPR node or at least its type? OR How do i get a reference to the node with the type of the exception for a THROW_EXPR? Note: I also tried to change the THROW_EXPR node to have 2 operands instead of 1 in (cp-tree.def) and then use build2() with the original exp node instead of the existing build1() and attached the original exp node to it. This had other disastrous consequences which i kind of expected. I was not sure if I could just add an additional operand to the THROW_EXPR node. I figured that all other commands would just use operand 0 and ignore the new operand but it seems to fail with an ICE, so i gave up that line of thinking... Thanks for any help/info on this. Brendon.
Bliss 0.210 released
Hi In case it may be of interest: There is a new version of Bliss out, 0.210. Available from ftp://ftp.nvg.ntnu.no/pub/vms/bliss/bliss-0_210.tgz (Do not mind the vms path, it compiles on Linux i386/x86_64.) News: Now a frontend for gcc 4.1.1. More support for block value in control expressions. Bliss compiling something now takes less than one tenth of the time it did with 3.4.3. Bliss is a relative of C, but a couple of years older. (See http://en.wikipedia.org/wiki/BLISS_programming_language) Many thanks to the gcc developers for reducing the compile time to less than one tenth. -- Regards, Roar Thronæs
Re: Getting type used in THROW_EXPR
On 10/14/06, Brendon Costa <[EMAIL PROTECTED]> wrote: Hi all, I have yet another question that has arisen as i have started testing my code. Basically I am trying to get the type that is being used in throwing an exception. Is there a simple macro i can use to get the type of an exception from a THROW_EXPR? I think this is a matter of getting the TREE_TYPE for the value passed into the function: except.c: build_throw(tree exp) If you look at cp/cp-tree.def you will see /* A throw expression. operand 0 is the expression, if there was one, else it is NULL_TREE. */ DEFTREECODE (THROW_EXPR, "throw_expr", tcc_expression, 1) which means that TREE_OPERAND (t, 0) is the expression thrown. Based on whether that is a reference already or not, you need to create a reference by your own using build1 (ADDR_EXPR, ...) with a properly constructed reference type (I guess there's some helper for that in the C++ frontend). Richard.
Re: Getting type used in THROW_EXPR
Richard Guenther wrote:
> On 10/14/06, Brendon Costa <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> I have yet another question that has arisen as i have started testing my
>> code. Basically I am trying to get the type that is being used in
>> throwing an exception.
>>
>>
>> Is there a simple macro i can use to get the type of an exception from a
>> THROW_EXPR? I think this is a matter of getting the TREE_TYPE for the
>> value passed into the function: except.c: build_throw(tree exp)
>
> If you look at cp/cp-tree.def you will see
>
> /* A throw expression. operand 0 is the expression, if there was one,
> else it is NULL_TREE. */
> DEFTREECODE (THROW_EXPR, "throw_expr", tcc_expression, 1)
>
> which means that TREE_OPERAND (t, 0) is the expression thrown. Based
> on whether that is a reference already or not, you need to create a
> reference by your own using build1 (ADDR_EXPR, ...) with a properly
> constructed reference type (I guess there's some helper for that in the
> C++ frontend).
Thanks for the fast reply. I have read that documentation before. The
problem is that the expression that you get from TREE_OPERAND(t, 0) is
not the same as the one that is passed into the except.c:
build_throw(tree exp) function which is the actual expression used to
determine the exception type.
Looking through the code for the function build_throw(), it adds
NOP_EXPR nodes, numerous compound expressions + cleanup nodes etc to the
original expression and this jumble of additional expressions is what is
considered the "expression" in the above comment (it somewhere contains
a link to the original expression somewhere). So getting the tree type
of that expression will not give me the type for the exception being
thrown, unlike getting the type of the expression that is initially
passed into that function.
For example getting the TREE_TYPE for the code below of the "exp" node
passed into build_throw() gives a node type of:
RECORD_TYPE
where as doing the same on TREE_OPERAND(t, 0) gives:
VOID_TYPE
class C
{
};
int main()
{
throw C();
return 0;
}
Also my terminology is not quite correct, when i say "reference" i meant
i need to get a pointer to the tree node that has the information, i.e.
a reference to the tree node with the information. Not a ADDR_EXPR.
Sorry for the confusing use of terminology.
Thanks,
Brendon.
Re: #line numbers in insn-recog.c
On Wed, May 03, 2006 at 12:29:17PM +0200, Bernd Schmidt wrote: > Does anyone find the use of #line in insn-recog.c actually useful? It > seems to make debugging recog() impossible. I think the line directives are nearly useless when you want to debug those files. A comment with the file name and line number would often better. However, those line directives are also used by GCC when emitting error or warning messages during compilation and are useful in those cases. Line directives are only usable with line numbers of at most 32767 while you can put anyting in a comment. For debugging, you can filter the offending file through something like sed -e 's_^#line _// _' and recompile. -- Rask Ingemann Lambertsen
Re: Getting type used in THROW_EXPR
My GCC extension will never be merged with the GCC source I dont think but will be distributed as a patch for GCC. So with that in mind do you think there will be any functional issues for me to set the TREE_TYPE of all THROW_EXPR nodes to have the type of the exception they are throwing or void (as it is currently) if the type is not known (Like for rethrow)? Currently the throw expr nodes are constructed with the line: exp = build1 (THROW_EXPR, void_type_node, exp); I was going to change that line to: exp = build1 (THROW_EXPR, resulting_type, exp); where resulting_type is the type of the exception being thrown (stripped of CV qualifiers + references by calling prepare_eh_type to get the correct type). I have tried it and there don't seem to be any problems with the small tests I have performed, but just thought i would see if others know of any issues that may arise from doing this? Thanks, Brendon.
Re: GNAT, SJLJ and zero-cost exception handling
Eric Botcazou writes: > You need GCC 3.x or GCC 4.2 for GNAT SJLJ exceptions to work. Do you mean that it does not work with GCC 4.1.1? That would be very bad news. >> From [2] it looks like this is a configure-time option only. > > [2] describes GCC SJLJ, which is not the same as GNAT SJLJ. How different? I was somehow suspecting that gnat1 supports both ZCX and SJLJ, looks in system.ads, and decides what kind of assembly code it needs to emit based on that. Am I correct? In that case, I need just one compiler and two libgnats, right? Thanks for the input! -- Ludovic Brenta.
Dead include file: dwarf.h ?
Hi, As far as I can tell, dwarf.h is not included anywhere in gcc/ or any of its subdirectories. Is there any reason not to remove this file? Thanks, Gr. Steven
Re: GNAT, SJLJ and zero-cost exception handling
> Do you mean that it does not work with GCC 4.1.1? Yes, it doesn't work in the 4.1.x series. > > [2] describes GCC SJLJ, which is not the same as GNAT SJLJ. > > How different? The latter is a "primitive" form of SJLJ, the former is more structured. > I was somehow suspecting that gnat1 supports both ZCX and SJLJ, looks in > system.ads, and decides what kind of assembly code it needs to emit based on > that. Am I correct? Yes, you are. > In that case, I need just one compiler and two libgnats, right? Right. -- Eric Botcazou
Re: building gcc
On Sat, Oct 14, 2006 at 02:16:01PM +1000, Brendon Costa wrote: > Bob Rossi wrote: > > Hi Ian, > > > > Basically, I want to use GCC with C,C++. I want to walk a tree that GCC > > creates for the translation units. I would like to know if for these two > > languages if I should use a language dependent tree, the generic tree or > > the gimple tree. In general, I would like to use the tree that most > closely > > resembles the source language, and that is documented best. > > > > For starters, can you recommend which tree structure I should use in > > GCC? If so, would it be to much to ask to point me to the object in the > > source code that represents the tree after the tree has been populated? > > > > If I should be using gimple, I found this paper. > > ftp://gcc.gnu.org/pub/gcc/summit/2003/GENERIC%20and%20GIMPLE.pdf > > Is there any other good documentation on this? > > I cant help much as i have only been fumbling around in the GCC source > for a short time now and still have no idea about a lot of stuff. > However I did want to also look at the full tree for the C++ front end. > I did this from the parser.c: cp_parser_translation_unit() function just > after the call to: finish_translation_unit() and I was looking at the > tree defined globally elsewhere in the variable: global_namespace Thanks Brendon, that was really helpful. I'm very new at this, and may have some seemingly rather odd questions. I see that global_namespace is of type 'union tree_node'. Is this the C++ language dependent AST? I found the documentation doc/c-tree.info. Is this the documentation representing the global_namespace tree? Is there any better documentation that you know of? Also, I noticed that converting it to html failed. Maybe this is a documentation error? Thanks again, Bob Rossi $ makeinfo --html ../../../gcc/gcc/doc/c-tree.texi ../../../gcc/gcc/doc/c-tree.texi:10: `Trees' has no Up field (perhaps incorrect sectioning?). makeinfo: Removing output file `/home/bob/rcs/svn/gcc/gcc/builddir/gcc/doc/c-tree/index.html' due to errors; use --force to preserve. $ makeinfo --version makeinfo (GNU texinfo) 4.8
Re: FW: How does GCC implement dynamic binding?
David Daney wrote: Perhaps you are right, but it would not surprise me if there were commercial entities based around FOSS that would provide that type of support. Certainly for instance AdaCore is able to provide this kind of certification for its customers using its commercial version of GNAT Pro (an Ada compiler based on GNAT Pro), and perhaps for example Code Sourcery might be able to provide similar certification for a product that they provide, but if you are looking for certification of some publicly available version, I think you are out of luck. It reminds me of a time in 1999, when someone demanded that we provide Y2K compliance guarantees for the public version of GNAT. Of course I declined (for one thing I had no way of knowing exactly what he was using). He was outraged, and said "well in that case I will have to stop using this version". I explained that this was indeed the case, and offered the possibility of using the commerical version supported by us, but that's not he wanted to hear, he wanted to use the freely available public version (which is fine if it meets someones needs), but wanted someone to guarantee compliance (which is not fine).
Re: building gcc
Bob Rossi wrote: Also, I noticed that converting it to html failed. Maybe this is a documentation error? Thanks again, Bob Rossi $ makeinfo --html ../../../gcc/gcc/doc/c-tree.texi ../../../gcc/gcc/doc/c-tree.texi:10: `Trees' has no Up field (perhaps incorrect sectioning?). makeinfo: Removing output file `/home/bob/rcs/svn/gcc/gcc/builddir/gcc/doc/c-tree/index.html' due to errors; use --force to preserve. 'make -k html' from the top level Makefile should do what you want. It starts at the root of the texi hierarchy and does not suffer from the failure you report. David Daney.
gcc-4.2-20061014 is now available
Snapshot gcc-4.2-20061014 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20061014/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 117733 You'll find: gcc-4.2-20061014.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20061014.tar.bz2 C front end and core compiler gcc-ada-4.2-20061014.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20061014.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20061014.tar.bz2 C++ front end and runtime gcc-java-4.2-20061014.tar.bz2 Java front end and runtime gcc-objc-4.2-20061014.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20061014.tar.bz2The GCC testsuite Diffs from 4.2-20061007 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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.
Adding support for demangling MSVC symbols to libiberty
Hi all! I'm currently investigating adding support for demangling/undecorating MSVC style symbols to libiberty. Is anyone else already working on this? Has this been considered in the past, but rejected for some reason? Should I have posted this to a different GCC list? :P Thanks, Phil Lello
Status of 4.1.2
There have been some discussions recently about a possible release of 4.1.2 in the near future and the following information might be useful in this debate. Matthias Klose asked me to test 4.1.2 20061007 to see whether it can be used instead of 4.1.2 20060901 for our next version of Debian. I found the following three regressions, two of which are issues where code is rejected that 4.1.2 20060901 accepted: - PR c++/29408: rejects templates in destructors - PR c++/29435: segmentation fault, related to sizeof - PR c++/29469: [DR 224] error: non-template 'pair' used as template Affected packages: - PR29408 firebird2_1.5.3.4870-10_20061011-1541 holotz-castle_1.3.8-1.1 koffice_1:1.5.2-2 matplotlib_0.87.5-2 qucs_0.0.9-1 scummvm_0.9.0-1 supertransball2_1.5-3 - PR29435 cinepaint_0.20-1-1.3 - PR29469 avifile_1:0.7.44.20051021-2.2 crystalspace_0.99-20060125-2 -- Martin Michlmayr http://www.cyrius.com/
Re: Status of 4.1.2
On Sat, 2006-10-14 at 21:14 +0100, Martin Michlmayr wrote: > There have been some discussions recently about a possible release of > 4.1.2 in the near future and the following information might be useful > in this debate. Matthias Klose asked me to test 4.1.2 20061007 to > see whether it can be used instead of 4.1.2 20060901 for our next > version of Debian. I found the following three regressions, two of > which are issues where code is rejected that 4.1.2 20060901 accepted: > > - PR c++/29408: rejects templates in destructors > > - PR c++/29435: segmentation fault, related to sizeof > > - PR c++/29469: [DR 224] error: non-template 'pair' used as template And only one of those are not questionable at being invalid code, PR 29435. -- Pinski
Re: Adding support for demangling MSVC symbols to libiberty
Has this been considered in the past, but rejected for some reason? Don't see why it would. Could be useful. Should I have posted this to a different GCC list? :P This is fine. -eric
Re: building gcc
Bob Rossi wrote: > > Thanks Brendon, that was really helpful. I'm very new at this, and may > have some seemingly rather odd questions. I see that global_namespace is > of type 'union tree_node'. Is this the C++ language dependent AST? Yes, this is the C++ AST. I actually think it is just a superset of GENERIC. I.e. it uses a lot of stuff defined in the tree.def file but also has some stuff specific to C++ that is defined in the cp-tree.def file. >From what i have gathered ALL tree types use this "union tree" type to represent a node in the tree. A good place to start in the documentation is the GCC internals documentation: http://gcc.gnu.org/onlinedocs/gccint/ There is a section on: The intermediate representations used by the C and C++ front ends that describes a lot of useful information about the C++ front end tree. This C++ tree includes the nodes for the C tree also, so look in the files tree.def, cp-tree.def for documentation on the different types of nodes that can be found in this tree. In addition the file: tree.h contains a number of functions and macros that can be used for manipulating and checking the contents of tree nodes. A lot of this information is in the above documentation, but some things you just need to search the sources for. I find that if something doesn't have any documentation, i search the.c files for uses of it using grep and see how it is used to get some idea of what it does. Finally there is a lot of documentation in the source files. I just find it difficult searching for the correct macro/function to use to do what i want. Once I have found it, using it is not as big of an issue. Brendon.
Re: GNAT, SJLJ and zero-cost exception handling
> Eric Botcazou writes: > > You need GCC 3.x or GCC 4.2 for GNAT SJLJ exceptions to work. > > Do you mean that it does not work with GCC 4.1.1? That would be very > bad news. I can confirm that gnat gcc 4.1.1 does *not* correctly handle SJLJ exceptions, at least on MinGW where SJLJ is currently the only viable EH mechanism. Eric, how difficult would it be to backport a fix from 4.2 to 4.1? Is there already a corresponding PR? Rolf -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
Re: Additional tree node questions.
Ian Lance Taylor wrote:
> Brendon Costa <[EMAIL PROTECTED]> writes:
>
>> For each FUNCTION_DECL node I find, I want to determine what its
>> exception specification list is. I.e. the throws() statement in its
>> prototype.
>
> Look at TYPE_RAISES_EXCEPTIONS (FNDECL).
>
> Ian
This macro does not seem to work. Either that or i am doing something wrong.
I have some code that looks a little like:
temp_tree = TYPE_RAISES_EXCEPTIONS(node);
if (temp_tree)
{
fprintf(stderr, "Has an exception spec.\n");
for (list = node; list; list = TREE_CHAIN(list))
{
/* Get the type for the specification. */
temp_tree = TREE_VALUE(list);
...
If i use the test code below:
void Function1() throw()
{
}
void Function2() throw(float)
{
throw 1.0f;
}
int main()
{
Function1();
Function2();
return 0;
}
I never see the print statement. I am doing this with the FUNCTION_DECL
nodes that pass through the: gimplify_function_tree() function.
Is there something incorrect about my usage of this macro?
I am using gcc-4.0.1
Thanks,
Brendon.
