Re: [fortran] Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]
Dave Korn wrote: > Tobias Burnus wrote: > >> I have another idea: Just handle "PROGRAM main" specially by using the >> name "MAIN__". It should be still quite readable in the middle-end >> diagnostics. Furthermore, it matches the assembler name and using "b >> main" one still get something useful - and it is less confusing for >> everyone (middle end, users of -fdump-tree-original etc.) if there is >> only a single "main". > > Okeydokey. I'm running this through the fortran+gomp testsuite. No > problems so far. Clean sweep on fortran: > === gfortran Summary === > > # of expected passes 30176 > # of expected failures19 > # of unsupported tests289 > /gnu/gcc/obj-patched2b/gcc/testsuite/gfortran/../../gfortran version 4.5.0 > 20090528 (experimental) (GCC) No regressions (a handful of pre-existing failures) on libgomp: > === libgomp Summary === > > # of expected passes2400 > # of unexpected failures4 > # of unsupported tests 2 > runtest completed at Sun May 31 13:39:24 2009 I reckon you should apply the patch and we can close PR40309. Thanks for all the help :) cheers, DaveK
Re: Inner loop unable to compute sufficient information during vectorization
In this case, I think that Outer loop could be vectorized as there is no dependency in the loop,the access pattern is simple enough and there is unit stride in both the loops. Current version 4.4.* is not doing outer loop vectorization. On Tue, May 26, 2009 at 5:57 PM, Ira Rosen wrote: > > > gcc-ow...@gcc.gnu.org wrote on 25/05/2009 21:53:41: > >> for a loop like >> >> 1 for(i=0;i> 2 for(j=0;j> 3 a[i][j] = a[i][j]+b[i][j]; >> >> GCC 4.3.* is unable to get the information for the inner loop that >> array reference 'a' is alias of each other and generates code for >> runtime aliasing check during vectorization. > > Both current trunk and GCC4.4 vectorize the inner loop without any runtime > alias checks. > >> Is it necessary to >> recompute all information in loop_vec_info in function >> vect_analyze_ref for analysis of inner loop also, as most of the >> information is similar for the outer loop for the program. > > Maybe you are right, and it is possible to extract at least part of the > information for the inner loop from the outer loop information. > >> >> Similarly, outer loop is able to compute correct chrec i.e. NULL , for >> array 'a' reference, while innerloop has chrec as chrec_dont_know, and >> therfore complaint about runtime alias check. > > The chrecs are not the same for inner and outer loops, so it is reasonable > that the results of the data dependence tests will be different. > In this case, however, it seems to be a bug. > > Ira > > > >
gcc-4.3-20090531 is now available
Snapshot gcc-4.3-20090531 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20090531/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.3 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_3-branch revision 148019 You'll find: gcc-4.3-20090531.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20090531.tar.bz2 C front end and core compiler gcc-ada-4.3-20090531.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20090531.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20090531.tar.bz2 C++ front end and runtime gcc-java-4.3-20090531.tar.bz2 Java front end and runtime gcc-objc-4.3-20090531.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20090531.tar.bz2The GCC testsuite Diffs from 4.3-20090524 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 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: [fortran] Different FUNC_DECLS with the same DECL_NAME - MAIN__ and named PROGRAM main functions [was Re: gcc-4.5-20090528 is now available]
Tobias Burnus wrote:
Dave Korn wrote:
Dave Korn wrote:
Dave Korn wrote:
Tobias Burnus wrote:
I agree that for "main" the call to "__main()" should happend and thus
expand_main_function should be called. I'm not sure in about the exact
assumptions of the middle end. In principle, it would be OK if the
MAIN__ function would show up as MAIN__ in gimple/-fdump-tree-original.
The only potential inconvenience I see, is the mentioned reference to
MAIN__ instead of in middle-end warnings, which can
confuse users.
Is it legitimate to have a space in an IDENTIFIER_NODE? I have a cheeky idea:
- gfc_get_symbol (name, ns, &main_program);
+ identifier = gfc_get_string ("PROGRAM %s", name);
That should give reasonable warnings from the middle end, no? I don't know
what it might do to debugging though.
Currently one can use "b MAIN__" and "b helloworld" in the debugger:
(gdb) b helloworld
Breakpoint 1 at 0x400737: file test.f90, line 3.
(gdb) b MAIN__
Note: breakpoint 1 also set at pc 0x400737.
Breakpoint 2 at 0x400737: file test.f90, line 3.
(gdb) b main
Breakpoint 3 at 0x4007b9: file test.f90, line 9.
I have another idea: Just handle "PROGRAM main" specially by using the
name "MAIN__". It should be still quite readable in the middle-end
diagnostics. Furthermore, it matches the assembler name and using "b
main" one still get something useful - and it is less confusing for
everyone (middle end, users of -fdump-tree-original etc.) if there is
only a single "main".
Tobias
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(Revision 148004)
+++ gcc/fortran/trans-decl.c(Arbeitskopie)
@@ -289,7 +289,10 @@ gfc_get_label_decl (gfc_st_label * lp)
static tree
gfc_sym_identifier (gfc_symbol * sym)o commit
{
- return (get_identifier (sym->name));
+ if (sym->attr.is_main_program && strcmp (sym->name, "main") == 0)
+return (get_identifier ("MAIN__"));
+ else
+return (get_identifier (sym->name));
}
@@ -3874,6 +3877,8 @@ create_main_function (tree fndecl)
tmp = build_function_type_list (integer_type_node, integer_type_node,
build_pointer_type (pchar_type_node),
NULL_TREE);
+ main_identifier_node = get_identifier ("main");
+ ftn_main = build_decl (FUNCTION_DECL, main_identifier_node, tmp);
ftn_main = build_decl (FUNCTION_DECL, get_identifier ("main"), tmp);
DECL_EXTERNAL (ftn_main) = 0;
TREE_PUBLIC (ftn_main) = 1;
Tobias and Dave,
I tested the above on x86-64 Linux. OK to commit.
Jerry
Having trouble printing the subvars of structs, under certain conditions
I am using gcc 4.1.1 to do research involving gimple. For this work I need to
know the sizes of all of my variables, without running the program and calling
"sizeof".
To accomplish this, I inserted a call to:
dump_referenced_vars(dump_file_ptr);
At first, everything looked fine. The output looks something like this:
...
Variable: ibin, UID 1428, char[16], is global, call clobbered, default
def: ibin_100
Variable: ie, UID 1429, struct great, sub-vars: { SFT.124 SFT.123 SFT.122 }
Variable: itmp, UID 1430, long unsigned int
...
>From this information, I can work out the sizes of all 3 variables
(ibin, ie, and itmp).
The ie variable is a struct with 3 subbvariables (SFT.124, SFT.123,
SFT.122). To
compute the size of ie, I need to recursively find the name of each
subvar, but this
is not the problem that I want to ask about.
The problem is that the subvars of a struct do not always print. I
specifically see that
it does not print subvars if one of the subvars is an array or itself
a struct. For
example, here is a code snippet for a struct with an array element:
typedef struct card{ int a; char *b; float c[10];}cardtyp;
static cardtyp c1;
And here is the dump_referenced_vars output for it:
Variable: c1, UID 1916, struct cardtyp, is global, call clobbered,
default def: c1_1
Notice that it does not list the subvars, so I cannot catch the size
of cardtype.
It also does not print subvars for arrays of struct variables:
Variable: kns, UID 1272, struct great[17], is addressable, is global,
call clobbered, default def: kns_29
So how can I get this information? (By the way, I'm not particularly
concerned with
referenced variables. I would be even happier to have the information
for all variables,
whether referenced or not.)
Thank you for your help,
Cheng-Yu
