Re: gfortran testsuite failures with 4.3.0 on powerpc64-apple-darwin8.8.0
make -k -j 8 check >& check.log ; make mail-report-with-warnings.log I got results that appear not much different from the powerpc-apple- darwin8.8.0 (i.e., 32-bit) results: http://gcc.gnu.org/ml/gcc-testresults/2006-12/msg00267.html i.e., these results don't show a particular fortran problem. Oh good. I'd realized I'd used an older checkout earlier and was having to rerun them. Glad everything seems ok. -eric
Re: Interface for manipulating the abstract syntax tree
> /* below I pass a the tree of the current_function_decl a global
> variable in tree.h */
> this_cfun = DECL_STRUCT_FUNCTION(current_function_decl);
> FOR_EACH_BB_FN(bb, this_cfun) /* Crashes here, Also tried with
> FOR_EACH_BB */
> for (bsi = bsi_start(bb); !bsi_end_p(bsi); bsi_next(&bsi))
> {
>bsi_stmt(bsi);
> }
> bsi = bsi_for_stmt(current_function_decl); /* Crashes right here */
> }
bsi_for_stmt(current_function_decl); does not seems correct to me
as it should return the function's declaration's basic block
iterator; which does not belongs to bb.
I think you are also missing some statement to get the current
tree node in the loop:
tree stmt = bsi_stmt (bsi);
and later recursively manipulate it with walk_tree ().
Please look how it is done in cgraph_create_edges().
Revital
Re: Interface for manipulating the abstract syntax tree
Hi Revital,
Because of doing copy, paste I forgot to delete one line from the CASE
1 example:
Instead:
> /* below I pass a the tree of the current_function_decl a global
> variable in tree.h */
> this_cfun = DECL_STRUCT_FUNCTION(current_function_decl);
> FOR_EACH_BB_FN(bb, this_cfun) /* Crashes here, Also tried with
> FOR_EACH_BB */
> for (bsi = bsi_start(bb); !bsi_end_p(bsi); bsi_next(&bsi))
> {
>bsi_stmt(bsi);
> }
> bsi = bsi_for_stmt(current_function_decl); /* Crashes right here */
> }
I have:
/* below I pass a the tree of the current_function_decl a global
variable in tree.h */
this_cfun = DECL_STRUCT_FUNCTION(current_function_decl);
FOR_EACH_BB_FN(bb, this_cfun)
/* Crashes here, Also tried with FOR_EACH_BB */
for (bsi = bsi_start(bb); !bsi_end_p(bsi); bsi_next(&bsi))
{
bsi_stmt(bsi);
}
}
And the code crashes at the macro FOR_EACH_BB_FN.. This is exatly as
it is implemented in cgraph_create_edges() function.. but I think that
the problem is because I call it at wrong time (too early, or too late
- before or after parsing).. Could it be?
When cgraph_create_edges() function is called it is passed a
function's declaration tree. In my case I also pass a function
declaration tree:
this_cfun = DECL_STRUCT_FUNCTION(current_function_decl);
where this_cfun is used in macro FOR_EACH_BB_FN
bsi_for_stmt(current_function_decl); does not seems correct to me
as it should return the function's declaration's basic block
iterator; which does not belongs to bb.
I am sorry this statement shouldn't be in the code. I have it in CASE2
that is a different way I tried to do my implementation/
I think you are also missing some statement to get the current
tree node in the loop:
tree stmt = bsi_stmt (bsi);
and later recursively manipulate it with walk_tree ().
The execution actually does not reach this part of the code. I had it
written but, decided to remove them until solvin the problem with the
correct initialization of bb (basic blok) with the FOR_EACH_BB_FN
macro.
Ferad Zyulkyarov
Re: Interface for manipulating the abstract syntax tree
> > And the code crashes at the macro FOR_EACH_BB_FN.. This is exatly as > it is implemented in cgraph_create_edges() function.. but I think that > the problem is because I call it at wrong time (too early, or too late > - before or after parsing).. Could it be? Yes. You can start by calling it in the same place cgraph_create_edges () is been called. (cgraph_analyze_function ()) > When cgraph_create_edges() function is called it is passed a > function's declaration tree. In my case I also pass a function > declaration tree: > > this_cfun = DECL_STRUCT_FUNCTION(current_function_decl); Check if current_function_decl is actually set when you access it. You can learn more by looking at the function that calls cgraph_create_edges() which sets current_function_decl. Revital
Re: Interface for manipulating the abstract syntax tree
Hi again,
Yes. You can start by calling it in the same place cgraph_create_edges ()
is been called. (cgraph_analyze_function ())
To be able to do that, probably I will need to register a new token
(i.e. MY_PRAGMA_TOKEN) and build a node of this token within the
pragma handler (in c-pragma.c). And later call the the function that
implements the logic of the MY_PRAGMA_TOKEN in
cgraph_analyze_function(). I think that the OMP pragmas are
implemented in a similar way.. (or probably I am wrong).
For now, I could not see a direct way how to get a reference to the
syntax tree from within the c-pragma.c file where I define the pragma
handler and register it as a call back. If by the way someone knows a
method.. I would be very thankful to share it with me..
Check if current_function_decl is actually set when you access it.
Yes current_function_decl is set to the declaration tree of the
current function where the pragma directive is.
void foo()
{
#pragma test_praga
}
the current_function_decl is set to the declaration of foo() (I debugged it)
You can learn more by looking at the function that calls
cgraph_create_edges()
which sets current_function_decl.
I will examine that more carefully.
Revital, thank you very much once again.
Ferad Zyulkyarov
Re: compile time testsuite [Re: alias slowdown?]
On 12/3/06, Gerald Pfeifer <[EMAIL PROTECTED]> wrote: Hi Richie, On Tue, 21 Nov 2006, Richard Guenther wrote: > Public monitoring would be more useful. If you have working single-file > testcases that you want be monitored for compile-time and memory-usage > just contact me and I can add them to the daily tester > (http://www.suse.de/~gcctest/c++bench/). that's a neat one. Would you mind adding this to the list of performance testers at http://gcc.gnu.org/benchmarks/ ? That would be nice. Done with the attached patch. Richard. p Description: Binary data
Understanding some EXPR nodes.
Hi All, I am trying to understand certain EXPR nodes, when they are generated and how code generated from them behaves in the resulting program. The nodes that have me a little confused are: TRY_CATCH_EXPR TRY_FINALLY_EXPR MUST_NOT_THROW_EXPR EH_FILTER_EXPR Note: I have read the GCC Internals documentation and the documentation in the appropriate .def files for these tree codes. It does not mention the information I am after. TRY_CATCH_EXPR/TRY_FINALLY_EXPR When code generated from these nodes encounter an exception while processing code from operand 0 is there an implicit rethrow of that exception at the end of the block of code given by operand 1 or does it "sink" the exception and only rethrow it if the user specifically requests it (In C++ anyway)? In what situations are these nodes generated? MUST_NOT_THROW_EXPR What sort of code produces one of these nodes? They do not seem to be used for the throw() specifiers for a function (At least in C++) as i would have expected. EH_FILTER_EXPR In what situations are these nodes generated? I assume that the code that these filters applies to is external to the node and if an exception occurs in this external code that does not match any of the types in the EH_FILTER_TYPES list (Do they have to be exact matches/how is type matching done here) then it calls the EH_FILTER_FAILURE which could be for example a call to terminate()? How does the EH_FILTER_MUST_NOT_THROW() macro work? If it returns true then the filter allows NO exceptions and if false then allows only exceptions of type that are in this list? Is it possible for the EH_FILTER_TYPES list to be empty and EH_FILTER_MUST_NOT_THROW() to return false? Thanks for any information on these questions. It will help me a great deal. Brendon.
gcc-4.0-20061207 is now available
Snapshot gcc-4.0-20061207 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20061207/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.0 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_0-branch revision 119635 You'll find: gcc-4.0-20061207.tar.bz2 Complete GCC (includes all of below) gcc-core-4.0-20061207.tar.bz2 C front end and core compiler gcc-ada-4.0-20061207.tar.bz2 Ada front end and runtime gcc-fortran-4.0-20061207.tar.bz2 Fortran front end and runtime gcc-g++-4.0-20061207.tar.bz2 C++ front end and runtime gcc-java-4.0-20061207.tar.bz2 Java front end and runtime gcc-objc-4.0-20061207.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.0-20061207.tar.bz2The GCC testsuite Diffs from 4.0-20061130 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.0 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: Gfortran and using C99 cbrt for X ** (1./3.)
Toon Moene wrote: I can measure the contribution of the cbrt effect in isolation, though (given the above change of HIRLAM source code). Well, the effect of the cbrt change (X ** (1./3.) -> cbrt(X)) is close to zero. Some other change must have diminished the number of pow[f] calls substantially. I think Andrew P's patch to declare the Fortran pow functions constant might be a good candidate. [ I did this exercise for g77 in 2000 - I'd never thought that that wouldn't be the basis for people to work on gfortran ... ] Cheers, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands A maintainer of GNU Fortran: http://gcc.gnu.org/fortran/ Who's working on GNU Fortran: http://gcc.gnu.org/ml/gcc/2006-01/msg0.html
Re: Understanding some EXPR nodes.
Brendon Costa <[EMAIL PROTECTED]> writes:
> The nodes that have me a little confused are:
>
> TRY_CATCH_EXPR
> TRY_FINALLY_EXPR
> MUST_NOT_THROW_EXPR
> EH_FILTER_EXPR
Yes, those are a bit mysterious.
> TRY_CATCH_EXPR/TRY_FINALLY_EXPR
> When code generated from these nodes encounter an exception while
> processing code from operand 0 is there an implicit rethrow of that
> exception at the end of the block of code given by operand 1 or does it
> "sink" the exception and only rethrow it if the user specifically
> requests it (In C++ anyway)?
If operand 0 throws an exception, there is an implicit rethrow after
executing operand 1. (Of course, operand 1 can prevent that rethrow
by doing its own throw, or by calling a function which does not
return, etc.).
> In what situations are these nodes generated?
TRY_CATCH_EXPR is generated for C++
try { ... } catch (...) { }
TRY_FINALLY_EXPR is generated for
class C { ~C(); }; ... { C c; ... }
to ensure that C's destructor is run.
And of course they can be generated for other languages as well.
> MUST_NOT_THROW_EXPR
> What sort of code produces one of these nodes? They do not seem to be
> used for the throw() specifiers for a function (At least in C++) as i
> would have expected.
MUST_NOT_THROW_EXPR is a C++ specific code. It is used for a few
places which must not throw, like the copy constructor of a catch
parameter. It is eliminated during gimplification. throw() is
handled via EH_SPEC_BLOCK, which is another C++ specific code
eliminated during gimplification.
> EH_FILTER_EXPR
> In what situations are these nodes generated?
EH_FILTER_EXPR is generated when EH_SPEC_BLOCK and MUST_NOT_THROW_EXPR
are gimplified.
> I assume that the code
> that these filters applies to is external to the node and if an
> exception occurs in this external code that does not match any of the
> types in the EH_FILTER_TYPES list (Do they have to be exact matches/how
> is type matching done here) then it calls the EH_FILTER_FAILURE which
> could be for example a call to terminate()?
EH_FILTER_EXPR will be operand 2 of a TRY_CATCH_EXPR. When the body
(operand 1) of the TRY_CATCH_EXPR throws an exception, then if operand
2 is EH_FILTER_EXPR, the exception is matched against EH_FILTER_TYPES.
If the exception does not match, then EH_FILTER_FAILURE is called.
EH_FILTER_FAILURE is normally a call to terminate() or unexpected().
> How does the EH_FILTER_MUST_NOT_THROW() macro work?
It generates an exception region such that if an exception is seen
there, terminate is called. (At least, I think that is how it works.)
> If it returns true
> then the filter allows NO exceptions and if false then allows only
> exceptions of type that are in this list?
Yes.
> Is it possible for the
> EH_FILTER_TYPES list to be empty and EH_FILTER_MUST_NOT_THROW() to
> return false?
Perhaps. The two cases are essentially equivalent.
Ian
Re: Understanding some EXPR nodes.
Thanks for the reply. One thing that I didnt quite get...
Ian Lance Taylor wrote:
TRY_CATCH_EXPR/TRY_FINALLY_EXPR
If operand 0 throws an exception, there is an implicit rethrow after
executing operand 1. (Of course, operand 1 can prevent that rethrow
by doing its own throw, or by calling a function which does not
return, etc.).
TRY_CATCH_EXPR is generated for C++
try { ... } catch (...) { }
TRY_FINALLY_EXPR is generated for
class C { ~C(); }; ... { C c; ... }
to ensure that C's destructor is run.
And of course they can be generated for other languages as well.
For the C++ code shown above try { ... } catch(...) {}
From memory I get a TRY_BLOCK node and not a TRY_CATCH_EXPR.
Also is the implicit rethrow just for the TRY_FINALLY_EXPR and not for
the TRY_CATCH_EXPR or is it for both of them?
Thanks,
Brendon.
ELDK Cross complier hang
Hi, I am trying to build LMBench v3.0 with ELDK (Embedded Linux Development Kit) for ARM Linux cross compiler (GCC 4.1). For a particular file (lat_ops.c) in LMBench, the cross compiler hangs. It worked well with compiler version 3.3.2. I am using Fedora core 4, Intel P4 machine and my target is ARM Linux 2.6.14. Please help me. Best regards, Rajasekaran.P PS: Is there any mailing list for ELDK? I could not find any. The information contained in this e-mail message and in any annexure is confidential to the recipient and may contain privileged information. If you are not the intended recipient, please notify the sender and delete the message along with any annexure. You should not disclose, copy or otherwise use the information contained in the message or any annexure. Any views expressed in this e-mail are those of the individual sender except where the sender specifically states them to be the views of SoCrates Software India Pvt Ltd., Bangalore.
Re: Understanding some EXPR nodes.
Brendon Costa <[EMAIL PROTECTED]> writes:
> >>TRY_CATCH_EXPR/TRY_FINALLY_EXPR
> >>
> >If operand 0 throws an exception, there is an implicit rethrow after
> >executing operand 1. (Of course, operand 1 can prevent that rethrow
> >by doing its own throw, or by calling a function which does not
> >return, etc.).
> > TRY_CATCH_EXPR is generated for C++
> >try { ... } catch (...) { }
> >
> >TRY_FINALLY_EXPR is generated for
> >class C { ~C(); }; ... { C c; ... }
> >to ensure that C's destructor is run.
> >
> >And of course they can be generated for other languages as well.
> >
>
> For the C++ code shown above try { ... } catch(...) {}
> From memory I get a TRY_BLOCK node and not a TRY_CATCH_EXPR.
TRY_BLOCK is a C++ language specific code. It is converted to
TRY_CATCH_EXPR during gimplification. See genericize_try_block.
> Also is the implicit rethrow just for the TRY_FINALLY_EXPR and not for
> the TRY_CATCH_EXPR or is it for both of them?
It's for both of them. If the body of a TRY_FINALLY_EXPR throws an
exception, then the finally clause, operand 1, will be executed. If
the finally clause completes normally, then the exception will be
rethrown. To be clear, if the body of a TRY_FINALLY_EXPR completes
normally, or executes a return statement, then the finally clause
won't throw an exception, it will continue with the next statement or
do a return. In other words, the finally clause is run, and then
whatever else was going to happen happens. And, to be clear, if the
finally clause throws an exception, then that is the exception that
will be thrown, and the original exception will not be rethrown and
will, in fact, be ignored.
Ian
Re: gfortran testsuite failures with 4.3.0 on powerpc64-apple-darwin8.8.0
On Wed, 2006-12-06 at 10:24 -0800, Steve Kargl wrote: > > > > I have reported no other bootstrap/regtests. So, depending on your > > meaning, perhaps there has never been a "last good bootstrap". > > > > Can you make testsuite/gfortran/gfortran.log available? > I suspect that this is yet another Darwin is a broken > OS problem. In case anyone does not know yet, the warning is the same as PR 29779. I don't remember if this was mentioned or not. Thanks, Andrew Pinski
Re: messages in objective-C
On Wed, 2006-12-06 at 17:19 +0100, Come Lonfils wrote: > Hi, > I'm trying to know more about how messages are send to the objects in > objective-C Messages are send via a dynamic lookup using strings. For the GNU runtime, objc_msg_lookup is called to get the function pointer and then we cast it to the "correct" type and calls the function pointer. > , how they are store,... At runtime, they are stored in a hashtable (at least for the GNU runtime) for most cases. > In which structures en how? MethodList_t at the startup time in the GNU runtime (as defined in objc/objc-api.h in libobjc). > Where should I look in the source code of gcc to know it? objc-act.c I don't know how much about how the NeXT runtime works except instead of a function pointer, it uses a call to a function to call the messages. Thanks, Andrew Pinski
Adding New Function Attributes
Hi all, In case i have to support a new function attribute specifically for my target, 1. Do i have to modify the GCC source base like adding a new flag in tree_function_decl(tree.h), adding a new handler to set the flag in c-common.h. or can i do it from the backend itself. 2. Any documentation regarding adding new function attributes? 3. If i have to emit an assembler directive based on the flag status, where should i look for? 4. If i specify the attribute at the time of function declaration and i need to update the same flag while defining the function, where should i look to change? Regards, Rohit
