headers
Richard Guenther | 1 Jan 2007 13:07
Picon

Re: [PATCH][fortran] Make cbrt, cexpi and sincos builtins available

On 12/15/06, Jerry DeLisle <jvdelisle <at> verizon.net> wrote:
> Tobias Burnus wrote:
> > Let's    *ping*   for Richard.
> >
> > with the sincos infrastructure in the middle end (I think all patches
> > are now in the trunk), this speeds up the Polyhedron fatigue test a lot:
> > ~28.3s => ~18.3s  (35% faster).
> >
> > This can be seen at the page
> > http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-fatigue-15.png
> > of http://www.suse.de/~gcctest/c++bench/polyhedron/
> > (The patch was applied for one day.)
> >
> > Tobias
> >
> > Richard Guenther schrieb:
> >> As $subject says.  The cbrt builtins can be used to expand x**1./3. to
> >> cbrt, the other two are on-top of the sincos patches.
> >>
> >> Bootstrap / regtest running.
> >>
> >> Ok if the sincos patch(es) go in?  How can we tell that the target
> >> supports sincos?  (I guess we would need a configure check for that?)
> >>
>
> It was not clear to me the consequences of the question about needing a
> configure check.  Has that been addressed?

No, it has not been addressed.  As far as I see we do not have infrastructure
in place to have tests on the target system in gcc/ because it wouldn't work
(Continue reading)

Permalink | Reply | 12 comments |
headers
Dominique Dhumieres | 1 Jan 2007 15:23
Picon
Picon
Favicon

Building gcc-4.3-20061230/libgfortran failed on OSX 10.3

First, happy new year to everybody!

Now the problem:

While building the latest gcc snapshot on OSX 10.3.9, I got the following
failure:

...
/sw/src/fink.build/gcc4-4.3.0-20061230/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc4-4.3.0-20061230/darwin_objdir/./gcc/
-B/sw/lib/gcc4/powerpc-apple-darwin7/bin/ -B/sw/lib/gcc4/powerpc-apple-darwin7/lib/
-isystem /sw/lib/gcc4/powerpc-apple-darwin7/include -isystem
/sw/lib/gcc4/powerpc-apple-darwin7/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-4.3-20061230/libgfortran -I. -iquote../../../gcc-4.3-20061230/libgfortran/io
-I../../../gcc-4.3-20061230/libgfortran/../gcc
-I../../../gcc-4.3-20061230/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99
-Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings
-ftree-vectorize -funroll-loops -O2 -g -O2 -c
../../../gcc-4.3-20061230/libgfortran/generated/matmul_r10.c  -fno-common -DPIC -o .libs/matmul_r10.o
/sw/src/fink.build/gcc4-4.3.0-20061230/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc4-4.3.0-20061230/darwin_objdir/./gcc/
-B/sw/lib/gcc4/powerpc-apple-darwin7/bin/ -B/sw/lib/gcc4/powerpc-apple-darwin7/lib/
-isystem /sw/lib/gcc4/powerpc-apple-darwin7/include -isystem
/sw/lib/gcc4/powerpc-apple-darwin7/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-4.3-20061230/libgfortran -I. -iquote../../../gcc-4.3-20061230/libgfortran/io
-I../../../gcc-4.3-20061230/libgfortran/../gcc
-I../../../gcc-4.3-20061230/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99
-Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings
-ftree-vectorize -funroll-loops -O2 -g -O2 -c
../../../gcc-4.3-20061230/libgfortran/generated/matmul_r10.c -o matmul_r10.o >/dev/null 2>&1
(Continue reading)

Permalink | Reply | 4 comments |
headers
Tim Prince | 1 Jan 2007 16:19
Picon
Favicon

Re: Building gcc-4.3-20061230/libgfortran failed on OSX 10.3

Dominique Dhumieres wrote:
> First, happy new year to everybody!
> 

> ../../../gcc-4.3-20061230/libgfortran/generated/matmul_r16.c:337: internal compiler error: in
copy_insn_1, at emit-rtl.c:4877
A similar problem is showing up in gcc testsuite on several platforms, 
including my current runs at i686-pc-cygwin.

As far as the libgfortran build is concerned, I continue to see failures 
resulting from FC = being left blank in Makefile, and an instance of 
-I<blank>.
Permalink | Reply | 0 comments |
headers
Dorit Nuzman | 1 Jan 2007 17:01
Picon
Favicon

Re: Building gcc-4.3-20061230/libgfortran failed on OSX 10.3

> First, happy new year to everybody!
>
> Now the problem:
>
> While building the latest gcc snapshot on OSX 10.3.9, I got the following
> failure:
>
> ...
> ../../../gcc-4.3-20061230/libgfortran/generated/matmul_r16.c: In
> function 'matmul_r16':
> ../../../gcc-4.3-20061230/libgfortran/generated/matmul_r16.c:337:
> internal compiler error: in copy_insn_1, at emit-rtl.c:4877
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> make[3]: *** [matmul_r16.lo] Error 1
> make[2]: *** [all] Error 2
> make[1]: *** [all-target-libgfortran] Error 2
> make: *** [all] Error 2
>
> Is this a gfortran problem or a more general one?
>

I think this is because of -
http://gcc.gnu.org/ml/gcc/2006-12/msg00833.html
(not a fortran problem)

dorit

> TIA
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dominique Dhumieres | 1 Jan 2007 19:11
Picon
Picon
Favicon

Re: Building gcc-4.3-20061230/libgfortran failed on OSX 10.3

Thanks for the pointer. I have applied the patch:

http://gcc.gnu.org/ml/gcc/2006-12/txt00006.txt

and I am rebuilding the snapshot (takes a while).
I'll let you know the result at the end.

Dominique
Permalink | Reply | 1 comment |
headers
Jerry DeLisle | 1 Jan 2007 19:24
Picon

Named Pipe unformatted I/O (PR30162)

All,

I have presented a simple patch to handle FORM="formatted" for Thomas to test.

For ACCESS="direct" and ACCESS="stream" with POS= I plan to test for named pipes 
and issue an error.

As you may know, FORM="unformatted" is much trickier.  I have a couple of ideas:

Keep in mind that right now for a write statement such as:

WRITE(10) var1, var2, var3

The record size is sizeof(var1) + sizeof(var2) + sizeof(var3)

we build a set of calls to the library like this:

st_write
transfer var1
transfer var2
transfer var3
st_write_done

Record size is currently determined by accumulating the iolengths as we go, 
forcing us to seek back in the file and fill in the starting record marker.

Idea 1) We could modify the frontend to include a call to test for named pipes 
and setup the calls to run through the transfers between st_write and 
st_write_done with two passes.  At run time, if the file is not a named pipe, we 
skip the first pass, otherwise we proceed with the first pass similar to INQUIRE
(Continue reading)

Permalink | Reply | 3 comments |
headers
Bud Davis | 1 Jan 2007 19:33
Picon
Favicon

Re: Named Pipe unformatted I/O (PR30162)


--- Jerry DeLisle <jvdelisle <at> verizon.net> wrote:

> All,
> 
> I have presented a simple patch to handle
> FORM="formatted" for Thomas to test.
> 
> For ACCESS="direct" and ACCESS="stream" with POS= I
> plan to test for named pipes 
> and issue an error.
> 
> As you may know, FORM="unformatted" is much
> trickier.  I have a couple of ideas:
> 
> Keep in mind that right now for a write statement
> such as:
> 
> WRITE(10) var1, var2, var3
> 
> The record size is sizeof(var1) + sizeof(var2) +
> sizeof(var3)
> 
> we build a set of calls to the library like this:
> 
> st_write
> transfer var1
> transfer var2
> transfer var3
> st_write_done
(Continue reading)

Permalink | Reply | 0 comments |
headers
Steve Kargl | 1 Jan 2007 20:35
Picon

[Committed] fortran/ChangeLog and libgfortran/ChangeLog

I copied the contents of ChangeLog to ChangeLog-2006 in the
gfortran related directories, and have removed the old content
in ChangeLog.

Happy New Years.

--

-- 
Steve
Permalink | Reply | 1 comment |
headers
Thomas Koenig | 1 Jan 2007 21:41
Picon

Re: Named Pipe unformatted I/O (PR30162)

Hi Jerry,

> For ACCESS="direct" and ACCESS="stream" with POS= I plan to test for named 
> pipes and issue an error.

It's probably better to check for a seekable file in this case
(using a sanitized way to check for is_seekable).  This would
also cover standard input/output to a terminal, regular file or pipe.

> As you may know, FORM="unformatted" is much trickier.  I have a couple of 
> ideas:
> 
> Keep in mind that right now for a write statement such as:
> 
> WRITE(10) var1, var2, var3
> 
> The record size is sizeof(var1) + sizeof(var2) + sizeof(var3)
> 
> we build a set of calls to the library like this:
> 
> st_write
> transfer var1
> transfer var2
> transfer var3
> st_write_done
> 
> Record size is currently determined by accumulating the iolengths as we go, 
> forcing us to seek back in the file and fill in the starting record marker.
> 
> Idea 1) We could modify the frontend to include a call to test for named
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jerry DeLisle | 1 Jan 2007 22:05
Picon

Re: Named Pipe unformatted I/O (PR30162)

Thomas Koenig wrote:
> Hi Jerry,
> 
>> For ACCESS="direct" and ACCESS="stream" with POS= I plan to test for named 
>> pipes and issue an error.
> 
> It's probably better to check for a seekable file in this case
> (using a sanitized way to check for is_seekable).  This would
> also cover standard input/output to a terminal, regular file or pipe.

I agree.

> 
>> As you may know, FORM="unformatted" is much trickier.  I have a couple of 
>> ideas:
>>
>> Keep in mind that right now for a write statement such as:
>>
>> WRITE(10) var1, var2, var3
>>
>> The record size is sizeof(var1) + sizeof(var2) + sizeof(var3)
>>
>> we build a set of calls to the library like this:
>>
>> st_write
>> transfer var1
>> transfer var2
>> transfer var3
>> st_write_done
>>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane