headers
Steve Kargl | 1 Jan 2012 02:57
Picon

Re: a fatal runtime error with complex sqrt and v4.7.0 under windows.

On Sat, Dec 31, 2011 at 07:03:42PM -0300, Jorge D'ELIA wrote:
> > On Sat, Dec 31, 2011 at 06:35:29PM -0300, Jorge D'ELIA wrote:
> >
> > D:\TMP>make
> > gfortran-beta -std=f2008 -Wall -Wno-maybe-uninitialized
> > -O3 -fargument-alias -fopenmp -fno-second-underscore
> > -fomit-frame-pointer -fbounds-check -funroll-loops
> > -ftree-vectorize -foptimize-sibling-calls -mmmx
> > -march=native -o test2.exe *.o
> >
> >
> > What happens if you use a same set of options?
> > 
> > Steve
> 
> 
> 1) The same output with a simple set of flags, e.g. with:
> 
> gfortran-beta -std=f2008 -Wall -o test2.exe *.o
> 
> 2) Without the use of a module and with or without the 
> several flags, it runs ok, e.g. see below.
> 
> 3) Sorry I did not understand what you mean with "s/same/sane/".
> 

I was correcting the spelling error.  I meant 'sane'
instead of 'same'.  s/same/sane is a common unix 
idiom used with regular expression substitution.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jorge D'ELIA | 1 Jan 2012 20:41
Picon

Re: a fatal runtime error with complex sqrt and v4.7.0 under windows.

Steve,

> On Sat, Dec 31, 2011 at 07:03:42PM -0300, Jorge wrote:
>>> On Sat, Dec 31, 2011 at 06:35:29PM -0300, Jorge wrote:
>>>
>>> D:\TMP>make
>>> gfortran-beta -std=f2008 -Wall -Wno-maybe-uninitialized
>>> -O3 -fargument-alias -fopenmp -fno-second-underscore
>>> -fomit-frame-pointer -fbounds-check -funroll-loops
>>> -ftree-vectorize -foptimize-sibling-calls -mmmx
>>> -march=native -o test2.exe *.o
>>>
>>> What happens if you use a same set of options?
>>>
>>> Steve
>>
>> 1) The same output with a simple set of flags, e.g. 
>>    with:
>>
>> gfortran-beta -std=f2008 -Wall -o test2.exe *.o
>>
>> 2) Without the use of a module and with or without 
>> the several flags, it runs ok, e.g. see below.
>>
>> 3) Sorry I did not understand what you mean with 
>> "s/same/sane/".
>
> I was correcting the spelling error.  I meant 'sane'
> instead of 'same'.  s/same/sane is a common unix
> idiom used with regular expression substitution.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mikael Morin | 2 Jan 2012 01:25
Picon
Favicon

Re: Changing module files

On 30/12/2011 05:21, Andrew Benson wrote:
> I'm finding strange behavior in which a module file generated on compiling a 
> source file sometimes changes, even though the source file (and everything else) 
> is unchanged. The change seems to be of a binary nature - running md5sum on 
> the module file returns one of two values. The module files seem to be almost 
> identical - usually with some lines moved and a few numbers changed. 
> Everything still compiles correctly, but the changing module files make it 
> impossible to do dependency checks in a Makefile when compiling a large project 
> (e.g. sometimes a source file can receive a minor change - one which shouldn't 
> normally affect the module file - gets recompiled producing a different module 
> file which then triggers a recompile of a large number of dependent files).
> 
> This is happening with gfortran 4.7.0 r182342.
> 
> Unfortunately, I haven't been able to find a self-contained test case as the 
> problem is intermittent and seems to be very sensitive to the structure of the 
> source file. Additionally, it doesn't even seem to happen on every system that 
> I've tried it on - the problem occurs on a RHEL5 Linux system, but not on a 
> Fedora 16 system (both running the exact same version of gfortran). The best I 
> can offer is a tarball (attached) containing the source file and various module 
> files which is USEs. I've included a script, test.sh, which compiles the source 
> 100 times and reports the md5sum of the module. The reported value should show 
> two different values - one reported about 90% of the time and the other about 
> 10% of the time - seemingly at random.
> 
> If anyone has suggestions of how to get a better test case I'd be happy to 
> pursue this further.
> 
> -Andrew.
>
(Continue reading)

Permalink | Reply | 9 comments |
headers
Tobias Burnus | 2 Jan 2012 12:34
Picon

Re: [Patch, fortran] Improve common function elimination

Thomas Koenig wrote:
> --- dependency.c	(Revision 182430)
> +++ dependency.c	(Arbeitskopie)
>  <at>  <at>  -245,7 +245,9  <at>  <at>  gfc_dep_compare_functions (gfc_expr *e1, gfc_expr
>      * 0 if e1 == e2
>      * -1 if e1<  e2
>      * -2 if the relationship could not be determined
> -   * -3 if e1 /= e2, but we cannot tell which one is larger.  */
> +   * -3 if e1 /= e2, but we cannot tell which one is larger.
> +   REAL and COMPLEX constants are only compared for equality
> +   or inequality; if they are unequal, -2 is returned in all cases.  */

Can we finally move to an ENUM? I think we slowly drift into the realm 
of magic numbers ...
(I know that you didn't modify that part.)

Steve Kargl wrote:
> On Wed, Dec 28, 2011 at 04:21:55PM +0100, Thomas Koenig wrote:
>>> OK for trunk?
> I did not test the patch, but it appears correct to me.
> OK.

Same here: Not tested, but it looks OK.

Tobias
Permalink | Reply | 1 comment |
headers
Thomas Koenig | 2 Jan 2012 15:13
Picon
Favicon

Re: [Patch, fortran] Improve common function elimination

Hi Tobias and Steve,

> Same here: Not tested, but it looks OK.

Committed (after Steve's mail already).  Thanks a lot for the reviews!

	Thomas
Permalink | Reply | 0 comments |
headers
Paul Richard Thomas | 2 Jan 2012 17:19
Picon

Re: PR46328 - [OOP] type-bound operator call with non-trivial polymorphic operand - redux (2)

Dear Tobias,

This is PR48946.  It should be easily fixed.... well, maybe :-)

Cheers

Paul

On Fri, Dec 30, 2011 at 10:15 PM, Tobias Burnus <burnus <at> net-b.de> wrote:
> Paul Richard Thomas wrote:
>>
>> Should the attached, modified version of typebound_procedure_7.f03 work?
>
>
> No idea - but Crayftn compiles it - and no failure occurs when running it
> (no output either).
>
> $ ftn poly_long2.f90
>
>  function i_plus_i(lhs,rhs)
>           ^
> ftn-287 crayftn: WARNING I_PLUS_I, File = poly_long2.f90, Line = 52, Column
> = 12
>  The result of function name "I_PLUS_I" in the function subprogram is not
> defined.
>
>  function i_multiply_real(lhs,rhs)
>           ^
> ftn-287 crayftn: WARNING I_MULTIPLY_REAL, File = poly_long2.f90, Line = 65,
> Column = 12
(Continue reading)

Permalink | Reply | 1 comment |
headers
Tim Prince | 2 Jan 2012 18:55
Picon
Favicon

pre-processor macro associated with availability of execute_command_line

As execute_command_line has been available in gfortran for over a year 
without penetrating to commonly used targets (e.g. mingw-64), I wondered 
if there is a suggestion for pre-processor macro to choose a source code 
branch, such as keying on gcc version number.
I suppose if it were easy to back-port to gfortran 4.5, it would have 
been done already.
Thanks,
--

-- 
Tim Prince
Permalink | Reply | 2 comments |
headers
Tobias Burnus | 2 Jan 2012 19:15
Picon

Re: pre-processor macro associated with availability of execute_command_line

Tim Prince wrote:
> As execute_command_line has been available in gfortran for over a year 
> without penetrating to commonly used targets (e.g. mingw-64), I 
> wondered if there is a suggestion for pre-processor macro to choose a 
> source code branch, such as keying on gcc version number.
> I suppose if it were easy to back-port to gfortran 4.5, it would have 
> been done already.

GCC 4.7.0 (including "gfortran -cpp" and "cpp") set (cf. "gfortran -cpp 
-dM test.F90"):
#define __GNUC__ 4
#define __GNUC_MINOR__ 7

The main reason that execute_command_line has not been backported to 
older GCC versions is that it is not a regression and not a bug. (The 
patch is not very small but rather localized.) Actually, I am surprised 
that you are considering a backport: execute_command_line is a Fortran 
2008 feature and very few compilers support it. On the other hand, the 
vendor intrinsic SYSTEM (either as function or as subroutine - or as 
with gfortran: both) is widely supported. (Besides the standard 
conformance, the main advantage of execute_command_line is the support 
of WAIT=.false., which is often not needed.)

Tobias
Permalink | Reply | 1 comment |
headers
Toon Moene | 2 Jan 2012 20:14

Re: Changing module files

On 01/02/2012 01:25 AM, Mikael Morin wrote:

> I opened a PR on bugzilla:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727

The PR contains the following suggestion:

  - tree rebalancing.  Module I/O manages structures to be serialized 
using a
global tree ordered (when writing) by structures' addresses.  Could an
unrepeatable order just mean an unrepeatable address?.

If you think that using a modern Linux kernel (or a kernel of any other 
commercial successful operating system), using tree balancing by sorting 
addresses is stable across multiple invocations, I have an interesting 
bridge to sell in New York, New York for you :-)

Take this simple Fortran program:

       PRINT '(Z16)',LOC(A)
       END

compile it and run it ten times:

$ for i in 1 2 3 4 5 6 7 8 9 10; do ./a.out; done
     7FFF6C7824EC
     7FFFCAF9DD0C
     7FFFA2F3426C
     7FFF7CAB262C
     7FFFF7A5F62C
(Continue reading)

Permalink | Reply | 8 comments |
headers
Janne Blomqvist | 2 Jan 2012 22:53
Picon

Re: Changing module files

On Mon, Jan 2, 2012 at 21:14, Toon Moene <toon <at> moene.org> wrote:
> On 01/02/2012 01:25 AM, Mikael Morin wrote:
>
>> I opened a PR on bugzilla:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51727
>
>
> The PR contains the following suggestion:
>
>  - tree rebalancing.  Module I/O manages structures to be serialized using a
> global tree ordered (when writing) by structures' addresses.  Could an
> unrepeatable order just mean an unrepeatable address?.
>
> If you think that using a modern Linux kernel (or a kernel of any other
> commercial successful operating system), using tree balancing by sorting
> addresses is stable across multiple invocations, I have an interesting
> bridge to sell in New York, New York for you :-)
>
> Take this simple Fortran program:
>
>      PRINT '(Z16)',LOC(A)
>      END
>
> compile it and run it ten times:
>
> $ for i in 1 2 3 4 5 6 7 8 9 10; do ./a.out; done
>    7FFF6C7824EC
>    7FFFCAF9DD0C
>    7FFFA2F3426C
>    7FFF7CAB262C
(Continue reading)

Permalink | Reply | 5 comments |

Gmane