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
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-
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
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 O
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 l
