Steve Kargl | 1 Feb 01:29
Picon

Re: [PATCH] Fix for PR fortran/38956 - take 2

On Sat, Jan 31, 2009 at 01:44:16PM +0100, Daniel Franke wrote:
> On Saturday 31 January 2009 13:06:58 David Billinghurst wrote:
> 
> David,
> 
> I can't comment on the functionality, but you can use the '-cpp' option 
> instead of the workaround:
> 
> > +! { dg-options "-std=gnu -x f95-cpp-input" }
> +! { dg-options "-std=gnu -cpp" }
> 

He should just xfail these tests on cygwin.

--

-- 
Steve

Tobias Burnus | 1 Feb 18:01
Picon

[Patch, Fortran, 4.5] [RFC] -fruntime-check=<....>

Hi all,

this patch adds -fruntime-check=... which can later be used for other
options such as DO variable checks or recursion checks, which have been
already approved (http://gcc.gnu.org/wiki/GFortranPatchTracker).

The patch is extracted from the run-time memory check patch,
http://gcc.gnu.org/ml/fortran/2008-11/msg00380.html

(The reason of this patch is to prepare the ground for the DO and
RECURSIVE check patch, but also for the run-time memory check patch;
thus I'd like to get it in soon after branching.)

RFC items

*** option question ***
a) -fcheck-array-temporaries: Should there also be a
-fruntime-check=array-temporaries ?
b) I added an option "all"; especially if
-fruntime-check=array-temporaries is supported, should "all" also be
included? The other question is whether an "all" option is useful at all?
*** texinfo question ***
c) -fbounds-check is the main item, one could also move this up to
-fruntime-check=bounds, should this be done?
d) Can the wording in .texi be improved?
*** code question ***
e) Should one keep flag_bounds_check or should one change trans* to use
    (gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
   instead? (Ditto for gfc_option.flag_check_array_temporaries)

(Continue reading)

Daniel Franke | 1 Feb 19:32
Picon

Re: [Patch, Fortran, 4.5] [RFC] -fruntime-check=<....>

On Sunday 01 February 2009 18:01:18 Tobias Burnus wrote:

Hi Tobias,

my 2ct here:

> *** option question ***
> a) -fcheck-array-temporaries: Should there also be a
> -fruntime-check=array-temporaries ?

Yes. And one could (eventually) get rid of the -fcheck-array-temporaries 
option.

> b) I added an option "all"; especially if
> -fruntime-check=array-temporaries is supported, should "all" also be
> included? The other question is whether an "all" option is useful at all?

  -fruntime-check=array-temporaries,bounds,do,recursive,...
vs.
  -fruntime-check=all?

I'm lazy, make that 'all' for me :)

> c) -fbounds-check is the main item, one could also move this up to
> -fruntime-check=bounds, should this be done?

Yes. And one could (eventually) get rid of the -fbounds-check option.

> e) Should one keep flag_bounds_check or should one change trans* to use
>     (gfc_option.rtcheck & GFC_RTCHECK_BOUNDS)
(Continue reading)

VandeVondele Joost | 1 Feb 20:10
Picon
Favicon

gfortran / gdb question

Hi,

I'm wondering if I'm doing something trivially wrong, or if there is an 
issue somewhere. Trying to debug [gfortran 4.4]'ed Fortran code, I can not 
print the values of local variables from within gdb (starting from a 
core). I get the following session:

gdb cp2k.psmp core.9523
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
<http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu"...
Core was generated by `./cp2k.psmp -i input_bulk_HFX_MD.inp -o 
input_bulk_HFX_MD.out.512'.
Program terminated with signal 6, Aborted.
[New process 9527]
[New process 9529]
[New process 9524]
[New process 9523]
#0  0x00000000028c277d in raise ()
(gdb) bt
#0  0x00000000028c277d in raise ()
#1  0x000000000290e1e0 in abort ()
#2  0x000000000292576b in __libc_message ()
#3  0x000000000292a011 in malloc_printerr ()
#4  0x000000000292bebc in _int_malloc ()
(Continue reading)

Tobias Burnus | 1 Feb 20:27
Picon

Re: [Patch, Fortran, 4.5] [RFC] -fruntime-check=<....>

Daniel Franke wrote:
> On Sunday 01 February 2009 18:01:18 Tobias Burnus wrote:
> my 2ct here: [...]
>   
I updated the patch.
OK for 4.5?

Tobias
2009-02-01  Francois-Xavier Coudert  <fxcoudert <at> gcc.gnu.org>
            Paul Thomas  <pault <at> gcc.gnu.org>
            Tobias Burnus  <burnus <at> net-b.de>

        * gfortran.h (gfc_option_t): Add rtcheck, remove
	flag_check_array_temporaries.
        * lang.opt: New option -fruntime-check.
        * libgfortran.h: Add GFC_RTCHECK_* constants.
        * invoke.texi: Document -fruntime-check.
        * options.c (gfc_handle_runtime_check_option): New function.
        (gfc_init_options,gfc_post_options,gfc_handle_option):
        Add -fruntime-check option.
	* trans-expr.c (gfc_conv_substring,gfc_conv_function_call):
	Change flag_bounds_check to gfc_option.rtcheck.
	* trans-array.c (gfc_trans_array_ctor_element,
	gfc_trans_array_constructor, gfc_trans_array_bound_check,
	gfc_conv_array_ref, gfc_conv_ss_startstride,
	gfc_trans_dummy_array_bias, gfc_conv_array_parameter): Ditto.
	* trans-stmt.c (compute_inner_temp_size): Ditto.
	* trans-decl.c (gfc_generate_function_code): Ditto.
(Continue reading)

Jerry DeLisle | 1 Feb 20:34
Picon

Re: [Patch, Fortran, 4.5] [RFC] -fruntime-check=<....>

Daniel Franke wrote:
> On Sunday 01 February 2009 18:01:18 Tobias Burnus wrote:
>
> Hi Tobias,
>
> my 2ct here:
>
>   
>> *** option question ***
>> a) -fcheck-array-temporaries: Should there also be a
>> -fruntime-check=array-temporaries ?
>>     
>
> Yes. And one could (eventually) get rid of the -fcheck-array-temporaries 
> option.
>
>
>   
>> b) I added an option "all"; especially if
>> -fruntime-check=array-temporaries is supported, should "all" also be
>> included? The other question is whether an "all" option is useful at all?
>>     
>
>   -fruntime-check=array-temporaries,bounds,do,recursive,...
> vs.
>   -fruntime-check=all?
>
> I'm lazy, make that 'all' for me :)
>
>
(Continue reading)

Jerry DeLisle | 1 Feb 20:44
Picon

Re: [PATCH] Fix for PR fortran/38956 - take 2

Steve Kargl wrote:
> On Sat, Jan 31, 2009 at 01:44:16PM +0100, Daniel Franke wrote:
>   
>> On Saturday 31 January 2009 13:06:58 David Billinghurst wrote:
>>
>> David,
>>
>> I can't comment on the functionality, but you can use the '-cpp' option 
>> instead of the workaround:
>>
>>     
>>> +! { dg-options "-std=gnu -x f95-cpp-input" }
>>>       
>> +! { dg-options "-std=gnu -cpp" }
>>
>>     
>
> He should just xfail these tests on cygwin.
>
>   
I have to second this.  There are some things that just don't work with 
Windows.  These tests were never intended to see if permissions work or 
not.  The purpose is to see if the fortran call to chmod function works 
on platforms where it really works.

That being said, xfail them on Cygwin rather than doing all this 
pre-processing. Thanks for your efforts though, David.  I am also OK 
with the splitting out of test cases and xfailing just the ones that fail.

Jerry
(Continue reading)

Jerry DeLisle | 1 Feb 21:01
Picon

Re: gfortran / gdb question

VandeVondele Joost wrote:
> Hi,
> 
> I'm wondering if I'm doing something trivially wrong, or if there is an 
> issue somewhere. Trying to debug [gfortran 4.4]'ed Fortran code, I can 
> not print the values of local variables from within gdb (starting from a 
> core). I get the following session:
> 
> gdb cp2k.psmp core.9523
> GNU gdb 6.8
> Copyright (C) 2008 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later 
> <http://gnu.org/licenses/gpl.html>
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
> and "show warranty" for details.
> This GDB was configured as "x86_64-unknown-linux-gnu"...
> Core was generated by `./cp2k.psmp -i input_bulk_HFX_MD.inp -o 
> input_bulk_HFX_MD.out.512'.
> Program terminated with signal 6, Aborted.
> [New process 9527]
> [New process 9529]
> [New process 9524]
> [New process 9523]
> #0  0x00000000028c277d in raise ()
> (gdb) bt
> #0  0x00000000028c277d in raise ()
> #1  0x000000000290e1e0 in abort ()
> #2  0x000000000292576b in __libc_message ()
> #3  0x000000000292a011 in malloc_printerr ()
(Continue reading)

Tobias Burnus | 1 Feb 22:01
Picon

Re: [Patch, Fortran, 4.5] [RFC] -fruntime-check=<....>

Jerry DeLisle wrote:
> I prefer the -fcheck-whatever form rather than the -fruntime=whatever
> form for any and all of these checks. I also think that having a
> -fruntime-check-all would be a good idea if we are going to have all
> these different kinds of checks.
Jerry and I discussed on IRC about it and we both found
-fruntime-check=... a bit lengthy. -fcheck=... would be a shorter
version, which Jerry thinks could be confused with compile-time checks;
he then proposed -frun-check=...

I'm open for different names, but otherwise I would go for:

  -frun-check=all,bounds,array-temps,do,recursive

(which means for the patch: s/fruntime-check/frun-check/g)

Any other opinion? And can someone review the patch? Thanks!

Tobias

Daniel Franke | 1 Feb 22:37
Picon

Fwd: Re: [Patch, Fortran, 4.5] [RFC] -fruntime-check=<....>

On Sunday 01 February 2009 22:01:55 Tobias Burnus wrote:
> Jerry DeLisle wrote:
> > I prefer the -fcheck-whatever form rather than the -fruntime=whatever
> > form for any and all of these checks. I also think that having a
> > -fruntime-check-all would be a good idea if we are going to have all
> > these different kinds of checks.
>
> Jerry and I discussed on IRC about it and we both found
> -fruntime-check=... a bit lengthy. -fcheck=... would be a shorter
> version, which Jerry thinks could be confused with compile-time checks;
> he then proposed -frun-check=...

IIRC, ifort has "-check xy", thus -fcheck should be IMO be ok as well.

> I'm open for different names, but otherwise I would go for:
>
>   -frun-check=all,bounds,array-temps,do,recursive
>
> (which means for the patch: s/fruntime-check/frun-check/g)
>
> Any other opinion? And can someone review the patch? Thanks!

Thanks for updating. Ok for trunk when a name was agreed upon :)

Cheers

	Daniel


Gmane