headers
FX | 1 May 2008 01:33
Picon

gfortran.dg/intrinsic_product_1.f90 fails on x86_64-linux with -m32

gfortran.dg/intrinsic_product_1.f90 fails at all optimisation levels  
on x86_64-linux when -m32 is used:

$ cat intrinsic_product_1.f90
! { dg-do run }
! PR 35993 - some intrinsics with mask = .false. didn't set
! the whole return array for multi-dimensional arrays.
! Test case adapted from Dick Hendrickson.

       program try

       call       ga3019(  1,  2,  3,  4)
       end program

       SUBROUTINE GA3019(nf1,nf2,nf3,nf4)
       INTEGER IDA(NF2,NF3)
       INTEGER IDA1(NF2,NF4,NF3)

       ida1 = 3

       ida = -3
       IDA(NF1:NF2,NF1:NF3) = PRODUCT(IDA1,NF2, NF1 .LT. 0)  !fails
       print *, ida
       if (any(ida /= 1)) call abort

       ida = -3
       IDA(NF1:NF2,NF1:NF3) = PRODUCT(IDA1,NF2, .false. )    !fails
       print *, ida
       if (any(ida /= 1)) call abort
(Continue reading)

Permalink | Reply | 0 comments |
headers
FX | 1 May 2008 01:34
Picon

[fortran,patch] Call mpfr_check_range after setting emin/emax

For a few months now, I've seen a failure of gfortran.dg/ 
nearest_4.f90 on my x86_64-linux build machine; the fact that noone  
else saw it, I suppose, is because I use GMP and MPFR built with  
internal checking (assertions) enabled. The following patch fixes it:

Index: simplify.c
===================================================================
--- simplify.c  (revision 134839)
+++ simplify.c  (working copy)
 <at>  <at>  -2821,6 +2821,7  <at>  <at>  gfc_simplify_nearest (gfc_expr *x, gfc_e
    mpfr_set_emin ((mp_exp_t) gfc_real_kinds[kind].min_exponent -
                 mpfr_get_prec(result->value.real) + 1);
    mpfr_set_emax ((mp_exp_t) gfc_real_kinds[kind].max_exponent - 1);
+  mpfr_check_range (result->value.real, 0, GMP_RNDU);

    if (mpfr_sgn (s->value.real) > 0)
      {

It follows the MPFR doc, which says that it's our responsability to  
make sure a real number is still in range after we've used mpfr_set_e 
{min,max}. These functions are used in another place in arith.c,  
which I propose to also fix:

Index: arith.c
===================================================================
--- arith.c     (revision 134839)
+++ arith.c     (working copy)
 <at>  <at>  -384,6 +384,7  <at>  <at>  gfc_check_real_range (mpfr_t p, int kind
        en = gfc_real_kinds[i].min_exponent - gfc_real_kinds 
[i].digits + 1;
(Continue reading)

Permalink | Reply | 4 comments |
headers
Jerry DeLisle | 1 May 2008 02:42
Picon

Re: [fortran,patch] Add SELECTED_CHAR_KIND intrinsic

FX wrote:
> Attached patch adds the Fortran 2003 SELECTED_CHAR_KIND intrinsic: 
> front-end symbol, checking and simplifying routines, library routine, 
> documentation and testcases (both valid and invalid code). This is 
> really fairly straightforward. I include in that patch an unrelated 
> diagnostics bug-fix: I realized that the following code
> 
>   integer, parameter :: k = 1
>   print *, 42_k
>   print *, k_"hello world"
>   end
> 
> when compiled with -O2 -W -Wunused will give warnings that k is an 
> unused parameter, which is not true. This is fixed by calling 
> gfc_set_sym_referenced() on the appropriate kind value named constants 
> right after they are successfully matched; this is done by two 
> one-liners in primary.c.
> 
> Built on i386-apple-darwin8.10.1, will bootstrap and regtest on 
> x86_64-linux as soon as I get back home (later today). OK to commit if 
> it passes bootstrap and regtesting?
> 
> PS: Jerry, what's the status of ENCODING="..." I/O specifier? Can we 
> already claim that we support Fortran 2003 international character sets 
> (the requirements for that are fairly low, as quite a few compilers have 
> a "yes" in that column and I know none that actually supports any 
> nondefault character kind).

ENCODING="default" is now supported.  All the front-end syntaxery is ready to do
ENCODING="UTF-8" whenever we have the internals ready to do it.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tim Prince | 1 May 2008 02:43
Picon
Favicon

Re: PR 26436 again?

Salvatore Filippone wrote:
> Il giorno mer, 30/04/2008 alle 07.25 -0700, Tim Prince ha scritto:
>> Salvatore Filippone wrote:
>>> Hi there, 
>>> Using a self-compiled version of gcc 4.3.0 on an HP-Itanium 2 system
>>> with Linux kernel 2.4.21, I have seen the (infamous) message 
>>> /tmp/ccu6kPNd.s:24139: Warning: Use of 'mov' may violate WAW dependency 'GR%, % in 1 - 127'
(impliedf), specific resource number is 14
>>>
>>> from the subject PR. The assembler used is :
>>> $ as -v
>>> GNU assembler version 2.14.90.0.4 (ia64-redhat-linux) using BFD version 2.14.90.0.4 20030523
>>>
>>> Is this something to be worried about? From bugzilla it looks like the
>>> original problem was never fully fixed...
>> That is an extremely old buggy binutils.  The oldest binutils which I have 
>> been able to use successfully for IA64 is
>> binutils-2.15.92.0.2-19.ia64.rpm
>> (not from a concern about spurious warnings).
>> If you are using the binutils which red hat issued with EL4.3, there was a 
>> red hat hot fix for premature exhaustion of short data segment.
> 
> I have no control over that machine, but I'll forward the info to the
> sysadmins.
You could download up to date binutils source, e.g. from ftp.kernel.org, 
and configure it to install in your own space, e.g. along with your own 
gcc, If you can use your own gcc, surely you can use your personal 
compatible binutils.  Note the binutils related configure options of gcc. 
  Replacing the binutils in /usr/bin is of more interest to those whose 
applications using other compilers are broken.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Jerry DeLisle | 1 May 2008 02:45
Picon

Re: [fortran,patch] Add SELECTED_CHAR_KIND intrinsic

Tobias Burnus wrote:
> Hello FX,
> 
> FX wrote:
>> PS: Jerry, what's the status of ENCODING="..." I/O specifier? Can we
>> already claim that we support Fortran 2003 international character sets
>> (the requirements for that are fairly low, as quite a few compilers have
>> a "yes" in that column and I know none that actually supports any
>> nondefault character kind).
> 
> I think with that patch we support about as much as other compilers, but
> still I would only claim PARTIAL, following NAG f95 which also has only
> ASCII support. Actually, the library implementation has a diagnostic
> bug. The following should give a run-time error (the compile-time diagnostic
> is OK):
> 
> character(len=10) :: cc = 'UTF-8'
> open(99,file="dd",encoding=cc)
> write(*,*) 'HELLO'
> end
> 
Hmm, I will fix this.

Jerry
Permalink | Reply | 0 comments |
headers
Jerry DeLisle | 1 May 2008 06:57
Picon

[patch, libfortran] PR36094 Runtime error show_locus not working correctly

Hi,

This simple patch takes care of the case where filename_from_unit returns NULL. 
If a filename is not yet associated with the given unit when an error occurs, 
show_locus will show unit number by itself.

The patch also comments out a portion of the encoding_options array so that 
"utf-8" throws a runtime error.

I will commit as obvious and simple if regression testing passes.

Jerry

2008-04-30  Jerry DeLisle  <jvdelisle <at> gcc.gnu.org>

	PR libfortran/36094
	* runtime/error.c (show_locus): Provide modified error message when
	filename has not yet been associated with a unit number.
	* io/open.c (encoding_opt[]): Comment out "utf-8" option and add TODO.
Attachment (error.diff): text/x-patch, 835 bytes
Permalink | Reply | 0 comments |
headers
Tobias Burnus | 1 May 2008 12:43
Picon

Re: [RFC] Use wide chars to represent Fortran source internally

FX wrote:
> This patch is a first step to handling non ASCII encoded source files 
> and non-default character kinds in gfortran.
Thanks for the patch; I think supporting non-8bit characters is useful - 
especially with the move to UTF-8 and the growing importance Asian 
languages which are not representable in 8bits.

> As a consequence of this patch, memory usage to store the source file 
> roughly quadruples. I've not seen a single case where it gives a 
> significant memory increase on the total amount used during 
> compilation higher than 7%, even at -O0: for the huge 
> cp2k-in-one-file, which has 26MB, 430k-lines source files, compilation 
> at -O0 requires 1.5 GB of memory, so the 75 MB additional memory isn't 
> seen.
I think the increase is OK (as is the patch), however, I do not know 
whether anyone thinks this increase it too big.

Regarding the 100 MB (25+75 MB), I really wonder whether we could not 
release some memory while compiling. Do we really need to have that much 
in memory? For instance, do we really access lines (e.g. for error 
messages) in a module after END MODULE? Or the body of a subroutine 
after END subroutine? Actually, when are they released? I think after 
some early processing of the middle end (e.g. unused variables) the 
whole source could be thrown away, which would reduce the totally needed 
amount of memory.

Tobias,
who will do a proper review after Whit Sunday.
(Continue reading)

Permalink | Reply | 2 comments |
headers
FX | 1 May 2008 13:01
Picon

Re: [RFC] Use wide chars to represent Fortran source internally

> Actually, when are they released? I think after some early processing of the
> middle end (e.g. unused variables) the whole source could be thrown away,
> which would reduce the totally needed amount of memory.

We currently release source information at the very end of
compilation, when the finish lang hook is called. I'm not sure we can
reliably do it much earlier.

FX

--

-- 
FX Coudert
http://www.homepages.ucl.ac.uk/~uccafco/
Permalink | Reply | 0 comments |
headers
FX | 1 May 2008 14:23
Picon

Re: GCC performance with CP2K

Below is a mail from Joost VandeVondele (from the cp2k team) to the
gcc mailing-list. I post it here also to spread the good news...

------------------------

I've just tested gcc/gfortran with CP2K, which some of you might know
from PR29975 and other messages to the list, and observed some very
pleasing evolution in the runtime of the code. In each case the set of
compilation options is '-O2 -ffast-math -funroll-loops
-ftree-vectorize -march=native' (-march=k8-sse3), the intel reference
'-O2 -xW -heap-arrays 64'

version subroutine time[s]

out.intel: CP2K 504.52

out.gfortran.4.2.3: CP2K 601.35
out.gfortran.4.3.0: CP2K 569.42
out.gfortran.4.4.0: CP2K 508.12

I hope that this rate of improvement sets a standard up to gcc 4.95.3 ;-)

Thanks for your efforts...

Cheers,

Joost
Permalink | Reply | 0 comments |
headers
Tobias Burnus | 1 May 2008 18:03
Picon

Unreviewed gfortran patches

Hello,

to my knowledge the following patches are currently unreviewed:
http://gcc.gnu.org/wiki/GFortranPatchTracker

if someone has the time ...

* [fortran,patch] Call mpfr_check_range after setting emin/emax
* [PATCH] Fix Fortran common handling in dwarf2out.c (PR debug/35896) 
(Middle-end review needed)
* Re: PING: [patch, fortran] PR 27997: Implement F2003-style array 
# constructor with typespec [patch, fortran] PR18428: use libcpp for 
preprocessing (review of C/C++ and fortran maintainers needed)
# Re: [PATCH, Fortran] preparing procedure pointers
# [RFC] Use wide chars to represent Fortran source internally

Tobias
Permalink | Reply | 1 comment |

Gmane