Re: Exception handling tables for function generated on the fly
Tom Quarendon wrote: > If I do this I get std::terminate called from __cxa_throw. Researching > this it seems that I somehow need to register some exception handling > tables to correspond to the "magic" function to enable the exception > handler to allow the exception to propagate through. Right. > I'd welcome any pointers to where I might be able to get some > information on this. I've looked at the C++ ABI documentation which > helps a bit, and I've found some information on the format that the > tables need to be in (and indeed I've looked at the assembler generated > by the gcc compiler if I code up "magic" and compile it directly), but I > don't yet see quite how to put it all together. There's no quick way to solve this: you'll just have to study DWARF unwinder data and figure out how to generate it. It's not particularly difficult, but there is a fair bit to learn. As you're writing a JIT it may well be that you can use a simplified subset of DWARF; you don't need to cater for every possibility. Call __register_frame_info() when you're done. Andrew.
External variables in shared library constructor code
Hi, I have a problem using external variables in the constructor code of my shared library. The constructor code is an init() function labeled by gcc __attribute__((constructor)). In that function I make a reference to an extern variable X provided by the driving app. The problem is that X is not yet initialized at the moment init() is invoked, which is before main() is entered. A solution might be to introduce a init flag and move the initialization code to some other exported function, but this is not really elegant. I will appreciate any alternative suggestion. -- View this message in context: http://www.nabble.com/External-variables-in-shared-library-constructor-code-tp18960710p18960710.html Sent from the gcc - Dev mailing list archive at Nabble.com.
Broken Tree
Hi, Checkin r139050 broke the build. In the file gcc/toplev.h, the new declaration pedwarn_at is incomplete, leading to syntax errors. Sebastian Index: gcc/toplev.h === --- gcc/toplev.h(revision 139053) +++ gcc/toplev.h(working copy) @@ -65,7 +65,8 @@ ATTRIBUTE_NORETURN; /* Pass one of the OPT_W* from options.h as the first parameter. */ extern bool pedwarn (int, const char *, ...) ATTRIBUTE_GCC_DIAG(2,3); -extern bool pedwarn_at (location_t, int, const char *, ...) +extern bool pedwarn_at (location_t, int, const char *, ...) + ATTRIBUTE_GCC_DIAG(3,4); extern bool permerror (const char *, ...) ATTRIBUTE_GCC_DIAG(1,2); extern bool permerror_at (location_t, const char *, ...) ATTRIBUTE_GCC_DIAG(2,3);
Re: Broken Tree
2008/8/13 Sebastian Redl <[EMAIL PROTECTED]>: > Hi, > > Checkin r139050 broke the build. In the file gcc/toplev.h, the new > declaration pedwarn_at is incomplete, leading to syntax errors. > > Sebastian Apologies, my fault. I messed up a conflict resolution. Committed as obvious as revision 139054. Index: gcc/toplev.h === --- gcc/toplev.h(revision 139053) +++ gcc/toplev.h(revision 139054) @@ -66,6 +66,7 @@ /* Pass one of the OPT_W* from options.h as the first parameter. */ extern bool pedwarn (int, const char *, ...) ATTRIBUTE_GCC_DIAG(2,3); extern bool pedwarn_at (location_t, int, const char *, ...) + ATTRIBUTE_GCC_DIAG(3,4); extern bool permerror (const char *, ...) ATTRIBUTE_GCC_DIAG(1,2); extern bool permerror_at (location_t, const char *, ...) ATTRIBUTE_GCC_DIAG(2,3); Index: gcc/ChangeLog === --- gcc/ChangeLog (revision 139053) +++ gcc/ChangeLog (revision 139054) @@ -1,3 +1,7 @@ +2008-08-13 Manuel Lopez-Ibanez <[EMAIL PROTECTED]> + + * toplev.h (pedwarn_at): Fix declaration. +
vectorization, -floop-strip-mine, -floop-block and -floop-interchange
Can anyone explain the relationship between the current vectorization optimizations in the gcc trunk compiler and the new -floop-strip-mine, -floop-interchange and -floop-block loop optimizations? Which takes precedence and does one set block the other in any way? I would hope that the new loop optimizations simply redefine the loops that are then processed for vectorization so that both sets of optimizations can be in effect at the same time. Thanks in advance for any clarifications on how these optimizations interact with each other. Jack
Re: vectorization, -floop-strip-mine, -floop-block and -floop-interchange
>Can anyone explain the relationship between the current vectorization > optimizations in the gcc trunk compiler and the new -floop-strip-mine, > -floop-interchange and -floop-block loop optimizations? Which takes > precedence and does one set block the other in any way? I would hope > that the new loop optimizations simply redefine the loops that are then > processed for vectorization so that both sets of optimizations can > be in effect at the same time. Thanks in advance for any clarifications > on how these optimizations interact with each other. There's currently no interaction between the Graphite optimizations and vectorization. I don't know what considerations/cost-model Graphite uses before applying its optimizations, but vectorization is not one of them. We are now starting to look into teaching Graphite to take into account factors that affect the applicability and profitability of vectorization, but this work is in a very initial stage. dorit > Jack
Re: vectorization, -floop-strip-mine, -floop-block and -floop-interchange
Dorit, So it is correct to say that any loop that is vectorized is removed from consideration for these other loop optimizations? I ask because I am wondering if I should be testing these new loop optimizations at -O2 in order to see their full effect (without vectorization inhibiting their use). Jack On Wed, Aug 13, 2008 at 05:08:53PM +0300, Dorit Nuzman wrote: > >Can anyone explain the relationship between the current vectorization > > optimizations in the gcc trunk compiler and the new -floop-strip-mine, > > -floop-interchange and -floop-block loop optimizations? Which takes > > precedence and does one set block the other in any way? I would hope > > that the new loop optimizations simply redefine the loops that are then > > processed for vectorization so that both sets of optimizations can > > be in effect at the same time. Thanks in advance for any clarifications > > on how these optimizations interact with each other. > > There's currently no interaction between the Graphite optimizations and > vectorization. I don't know what considerations/cost-model Graphite uses > before applying its optimizations, but vectorization is not one of them. We > are now starting to look into teaching Graphite to take into account > factors that affect the applicability and profitability of vectorization, > but this work is in a very initial stage. > > dorit > > > Jack
Re: vectorization, -floop-strip-mine, -floop-block and -floop-interchange
hi, they should work completely independently from vectorization. It does not matter if vectorizaton is already run or not, they will apply if You enable them by flags. konrad From: Jack Howarth <[EMAIL PROTECTED]> To: Dorit Nuzman/Haifa/[EMAIL PROTECTED] Cc: gcc@gcc.gnu.org, Konrad Trifunovic/Haifa/Contr/[EMAIL PROTECTED] Date: 13/08/2008 17:24 Subject:Re: vectorization, -floop-strip-mine, -floop-block and -floop-interchange Dorit, So it is correct to say that any loop that is vectorized is removed from consideration for these other loop optimizations? I ask because I am wondering if I should be testing these new loop optimizations at -O2 in order to see their full effect (without vectorization inhibiting their use). Jack On Wed, Aug 13, 2008 at 05:08:53PM +0300, Dorit Nuzman wrote: > >Can anyone explain the relationship between the current vectorization > > optimizations in the gcc trunk compiler and the new -floop-strip-mine, > > -floop-interchange and -floop-block loop optimizations? Which takes > > precedence and does one set block the other in any way? I would hope > > that the new loop optimizations simply redefine the loops that are then > > processed for vectorization so that both sets of optimizations can > > be in effect at the same time. Thanks in advance for any clarifications > > on how these optimizations interact with each other. > > There's currently no interaction between the Graphite optimizations and > vectorization. I don't know what considerations/cost-model Graphite uses > before applying its optimizations, but vectorization is not one of them. We > are now starting to look into teaching Graphite to take into account > factors that affect the applicability and profitability of vectorization, > but this work is in a very initial stage. > > dorit > > > Jack
Re: vectorization, -floop-strip-mine, -floop-block and -floop-interchange
Hi, sorry for my top-posting in last e-mail. > hi, > > they should work completely independently from vectorization. It does not > matter if vectorizaton is already run or not, they will apply > if You enable them by flags. > > konrad > > > Dorit, > So it is correct to say that any loop that is vectorized is > removed from consideration for these other loop optimizations? > I ask because I am wondering if I should be testing these new > loop optimizations at -O2 in order to see their full effect > (without vectorization inhibiting their use). >Jack > > On Wed, Aug 13, 2008 at 05:08:53PM +0300, Dorit Nuzman wrote: >> >Can anyone explain the relationship between the current > vectorization >> > optimizations in the gcc trunk compiler and the new -floop-strip-mine, >> > -floop-interchange and -floop-block loop optimizations? Which takes >> > precedence and does one set block the other in any way? I would hope >> > that the new loop optimizations simply redefine the loops that are then >> > processed for vectorization so that both sets of optimizations can >> > be in effect at the same time. Thanks in advance for any clarifications >> > on how these optimizations interact with each other. >> By looking at passes.c I see that graphite is invoked before vectorizer. This means that first the loop optimizations -floop-interchange etc. will take place and then vectorizer will try to vectorize them. There is no direct interaction between those optimizations. I would be glad to see the results though. >> There's currently no interaction between the Graphite optimizations and >> vectorization. I don't know what considerations/cost-model Graphite uses >> before applying its optimizations, but vectorization is not one of them. > We >> are now starting to look into teaching Graphite to take into account >> factors that affect the applicability and profitability of vectorization, >> but this work is in a very initial stage. >> >> dorit >> >> > Jack > > > > konrad
Re: vectorization, -floop-strip-mine, -floop-block and -floop-interchange
On Wed, Aug 13, 2008 at 05:33:39PM +0300, Konrad Trifunovic wrote: > hi, > > they should work completely independently from vectorization. It does not > matter if vectorizaton is already run or not, they will apply > if You enable them by flags. > > konrad > Konrad, So gcc will always perform the vectorization optimization before the new loop-strip-mine, loop-block and loop-interchange ones are done? Also, are those three new optimizations performed in a specific order relative to each other? Jack
broken FE diagnostics wrt complex expressions
Hi folks.
I'm looking at 3544[123] and 35742, which are all related to
pp_c_expression not handling complex expressions, so we can't display
correct error messages for statement expressions, etc:
({break;})()
The error here is currently:
#'goto_expr' not supported by pp_c_expression#'bug.c: In function 'foo':
bug.c:4: error: called object is not a function
I've looked into what needs to happen to give correct error messages.
First, I believe this is foremost a representation problem. We can't
give accurate error messages if we keep reconstructing the original
sources from GENERIC.
For example, in the above example, the error machinery thinks we're
talking about a GOTO_EXPR, because GENERIC has no way of representing
BREAK/CONTINUE.
Similary, when we ignore the result of a function call, many FE's create
an artificial variable. For "extern int foo(); foo();", the
representation is actually " = foo()", which will also be
unreadable even if handled by pp_c_expression.
It seems to me that the only approach here would be to provide caret
diagnostics, because reconstructing the original sources from GENERIC
seems like a loosing proposition.
But, is this slew of work even worth it? I for one think that the
aforementioned PRs should at least be marked down considerably. 3 of
them are P2s-- and I think they should be some Pn+5, and/or mark them as
an enhancement request.
Are there any thoughts on this (the PRs, the caret diagnostics, plan of
attack, etc?).
Aldy
Re: broken FE diagnostics wrt complex expressions
On Wed, 13 Aug 2008, Aldy Hernandez wrote: > It seems to me that the only approach here would be to provide caret > diagnostics, because reconstructing the original sources from GENERIC > seems like a loosing proposition. In some cases the only useful place to find the expression is in the preprocessed sources, not the original sources, so you want to be able to print an expression extracted from those not just one extracted from pointers into the original sources. But in either case extracting an expressions using some form of beginning and ending locations would give better results than reconstructing a representation of the expression from trees. (This would involve keeping two locations for an expression rather than one, but an opaque location_t cookie ought to be able to represent locations in both original and preprocessed source so you shouldn't need four locations.) > But, is this slew of work even worth it? I for one think that the > aforementioned PRs should at least be marked down considerably. 3 of > them are P2s-- and I think they should be some Pn+5, and/or mark them as > an enhancement request. I set 35441 to P4, and Volker complained that it should have been P2 (though he didn't take me up on my invitation to reset it to P3 for another RM to look at it). I think it would certainly be reasonable to print for anything unsupported instead of broken diagnostics, and to reclassify all such bugs as wishlist requests for certain complex expressions to be better supported in diagnostics. -- Joseph S. Myers [EMAIL PROTECTED]
Re: broken FE diagnostics wrt complex expressions
> "Aldy" == Aldy Hernandez <[EMAIL PROTECTED]> writes: Aldy> The error here is currently: Aldy> #'goto_expr' not supported by pp_c_expression#'bug.c: In function 'foo': Aldy> bug.c:4: error: called object is not a function Aldy> But, is this slew of work even worth it? I for one think that the Aldy> aforementioned PRs should at least be marked down considerably. 3 of Aldy> them are P2s-- and I think they should be some Pn+5, and/or mark them as Aldy> an enhancement request. It would be nice not to emit a completely bogus message like that, even if we cannot immediately emit an excellent message. Aldy> Are there any thoughts on this (the PRs, the caret diagnostics, plan of Aldy> attack, etc?). Caret diagnostics do seem like the way to go. If you're interested in working on this, I think one way to do it would be to start with a parser and make sure it always picks the proper token from which to extract a location. This is a reasonable amount of work, and unfortunately much of it would have to be complete before we could enable caret- or column-output. (I have a few random unsubmitted patches toward this direction, I can forward them if you are interested.) I suspect that there's some work fixing optimization passes. I have not looked but I would not be surprised if some of them pick locations poorly when rearranging things. My full wish here, getting rid of input_location, requires changes all over. E.g., the location should be an argument to build_decl; that alone has hundreds of calls. As far as I know nobody is actively working on any of this, though Mañuel and I talk about it sporadically. Tom
Re: broken FE diagnostics wrt complex expressions
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes: Tom> As far as I know nobody is actively working on any of this, though Tom> Mañuel and I talk about it sporadically. Crap, I misspelled his name while trying extra to get it right. Sorry about that. Tom
Re: broken FE diagnostics wrt complex expressions
Tom Tromey wrote: Aldy> Are there any thoughts on this (the PRs, the caret diagnostics, plan of Aldy> attack, etc?). Caret diagnostics do seem like the way to go. Yes, I've advocated that for years. People consistently tell me that EDG's diagnostics are superior to GCC, in part because of EDG's use of carets. As far as I know, EDG does not have the capability to show preprocessed source (as Joseph suggests), but I agree that this would be a useful capability. I suspect that even without fully accurate token information from the parsers, caret diagnostics would be an improvement. Some of these problems that we consistently struggle with (printing complex expressions, using the same spellings of keywords and types that the user did, etc.) would be significantly improved by using carets -- even if the carets didn't point in exactly the right place. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
successful gcc 3.4.6 build
Per the request in doc/install.texi, I'm reporting a successful build of gcc 3.4.6. I have not run the tests; I have none of the test infrastructure tools (dejagnu, tcl, expect) installed, and (unless it proves to be broken when I try to use it, and maybe not even then) the tests are nowhere near important enough to me to make me put myself through making them build. config.guess says "alpha-unknown-netbsd3.1". The machine is a Digital Personal WorkStation 600au. gcc -v says Reading specs from /home/mouse/gcj/INST/lib/gcc/alpha-unknown-netbsd3.1/3.4.6/specs Configured with: ../gcc-3.4.6/configure --prefix=/home/mouse/gcj/INST --with-local-prefix=/home/mouse/gcj/INCLUDE --disable-shared --disable-threads --enable-languages=java --with-x --enable-java-awt=xlib --disable-gtktest Thread model: single gcc version 3.4.6 The only caveat is that this is _not_ built from the NetBSD /usr/src/gnu/dist/gcc import (which is 3.3.3, not 3.4.6, anyway); that version has had major pieces, including Java support, deleted to save space, since NetBSD doesn't build them. Since the whole point of my doing this was to build gcj, I picked up the bzip2ed tarball for gcc-3.4.6 from ftp.gnu.org. /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML[EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: broken FE diagnostics wrt complex expressions
> If you're interested in working on this, I think one way to do it > would be to start with a parser and make sure it always picks the > proper token from which to extract a location. This is a reasonable > amount of work, and unfortunately much of it would have to be complete > before we could enable caret- or column-output. (I have a few random > unsubmitted patches toward this direction, I can forward them if you > are interested.) Sure, send them my way. > I suspect that there's some work fixing optimization passes. I have > not looked but I would not be surprised if some of them pick locations > poorly when rearranging things. But this has nothing to do with error messages. I mean, not initially. Although all this is bound to help Alex, or whomever is working on proper debug information (I'm guessing). > My full wish here, getting rid of input_location, requires changes all > over. E.g., the location should be an argument to build_decl; that > alone has hundreds of calls. Well, perhaps we can start one step at a time, hopefully in steps that can be independently committed-- thus requiring no branch :). Something like this-- in order: 1. beginning/ending locations functionality as Joseph suggests. 2. make sure the parsers pick the proper token/location. 3. error reporting machinery How does this sound? (As is customary with me, I'm doing a lot of hand-waving, because everything's a 4-5 day job in my mind-- just like tuples. I'm sure it'll be a can of worms.) Aldy
gcc-4.2-20080813 is now available
Snapshot gcc-4.2-20080813 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080813/ 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/branches/gcc-4_2-branch revision 139084 You'll find: gcc-4.2-20080813.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20080813.tar.bz2 C front end and core compiler gcc-ada-4.2-20080813.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20080813.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20080813.tar.bz2 C++ front end and runtime gcc-java-4.2-20080813.tar.bz2 Java front end and runtime gcc-objc-4.2-20080813.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20080813.tar.bz2The GCC testsuite Diffs from 4.2-20080806 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.
Re: broken FE diagnostics wrt complex expressions
Tom> I suspect that there's some work fixing optimization passes. I have Tom> not looked but I would not be surprised if some of them pick locations Tom> poorly when rearranging things. Aldy> But this has nothing to do with error messages. I mean, not initially. Yeah, it is somewhat indirect. It can matter if some expression's location is later used when emitting an error. Users will probably benefit a lot more from work in the FE than the ME. Aldy> 1. beginning/ending locations functionality as Joseph suggests. Aldy> 2. make sure the parsers pick the proper token/location. Aldy> 3. error reporting machinery Aldy> How does this sound? It sounds good to me. #1 might be hard, I have not looked into it. ISTR Manuel having a patch for caret diagnostic output... ? Aldy> (As is customary with me, I'm doing a lot of hand-waving, because Aldy> everything's a 4-5 day job in my mind-- just like tuples. I'm sure Aldy> it'll be a can of worms.) :) Tom
Re: broken FE diagnostics wrt complex expressions
On Aug 13, 2008, at 12:16 PM, Joseph S. Myers wrote:
On Wed, 13 Aug 2008, Aldy Hernandez wrote:
It seems to me that the only approach here would be to provide caret
diagnostics, because reconstructing the original sources from GENERIC
seems like a loosing proposition.
In some cases the only useful place to find the expression is in the
preprocessed sources, not the original sources, so you want to be
able to
print an expression extracted from those not just one extracted from
pointers into the original sources. But in either case extracting an
expressions using some form of beginning and ending locations would
give
better results than reconstructing a representation of the
expression from
trees.
I agree, this is the best way to go. Clang produces:
$ clang t.c
t.c:4:15: error: called object is not a function or function pointer
({ int i; })();
^
t.c:13:9: error: called object is not a function or function pointer
((B)a)();
~~^
t.c:17:10: error: called object is not a function or function pointer
(p - q)();
~~~^
t.c:18:18: error: called object is not a function or function pointer
(p < q ? p : q)();
~~~^
4 diagnostics generated.
Which scales well to other arbitrary expressions.
-Chris
