headers
Paul Richard Thomas | 2 May 2012 09:50
Picon

Re: [Patch, fortran] PR41600 - [OOP] SELECT TYPE with associate-name => exp: Arrays not supported

Dear Tobias,

Thanks for completing the review.  I should be able to commit tonight.

> Thanks for the patch. I think it is OK.
>
> Regarding:
>
>> !       if (ref&&  ref->type != REF_ARRAY&&  seen_array)
>> !       {
>> !         gfc_error ("CLASS selector at %L is an array with CLASS "
>> !                    "components; this is not allowed since the "
>> !                    "elements could have different dynamic types",
>> !               &target->where);
>
>
> Could you open a PR for it? If possible with a test case.

select_type_28.f03 is that testcase (see below).  I am not sure what
the PR would be for - surely such selectors make no logical sense?
Oddly I can see no such restriction in the standard. Indeed, there
seems to me to be an identical diffculty with pointer assignment.
Maybe a message to clf would be in order?

Cheers

Paul

Cheers
(Continue reading)

Permalink | Reply | 0 comments |
headers
vikram_sp | 2 May 2012 10:53
Picon
Favicon

Fortran senmentation fault


Hi
I am trying to port fortran on arm. But the executables generated 
by the cross compiler is giving segmentation fault on the board.

I want to know what special is needs to be initialized in fortran
program, i mean starup files. And what is to be done for safe termination.

--

-- 
View this message in context: http://old.nabble.com/Fortran-senmentation-fault-tp33763363p33763363.html
Sent from the gcc - fortran mailing list archive at Nabble.com.
Permalink | Reply | 1 comment |
headers
Salvatore Filippone | 2 May 2012 12:15
Picon

Segfault in free()

Hello,
I am getting a strange segfault in one of my codes. The segfault
happens with 4.6.3, whereas the code works with 4.7.0 and trunk.

The segfault is very strange because it happens at the following statement

Program received signal 11 (SIGSEGV): Segmentation fault.

Backtrace for this error:
  + /lib64/libc.so.6() [0x3f6d632900]
  + /lib64/libc.so.6(cfree+0x1c) [0x3f6d67a5ac]
  + function __psb_descriptor_type_MOD_psb_cd_destroy (0x502970)
    at line 684 of file psb_desc_type.f90
  + function __psb_descriptor_type_MOD_psb_cdfree (0x502D9C)
    at line 640 of file psb_desc_type.f90
  + function __psb_descriptor_type_MOD_psb_cdtransfer (0x5027F7)
    at line 780 of file psb_desc_type.f90
  + function __psb_base_linmap_mod_MOD_psb_base_linmap_transfer (0x77B0EF)
    at line 154 of file psb_base_linmap_mod.f90
  + function __psb_d_linmap_mod_MOD_psb_dlinmap_transfer (0x566DF3)
    at line 197 of file psb_d_linmap_mod.f90
  + function __mld_d_onelev_mod_MOD_mld_d_onelev_move_alloc (0x465C07)
    at line 336 of file mld_d_onelev_mod.f90
  + function mld_dmlprec_bld_ (0x451AAB)
    at line 292 of file mld_dmlprec_bld.f90
  + function mld_dprecbld_ (0x446A78)
    at line 191 of file mld_dprecbld.f90
  + function ppde2d (0x42D7D3)
    at line 265 of file ppde2d.f90
  + /lib64/libc.so.6(__libc_start_main+0xfd) [0x3f6d61ecdd]
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tobias Burnus | 2 May 2012 13:55
Picon

Re: Fortran senmentation fault

On 05/02/2012 10:53 AM, vikram_sp wrote:
> I am trying to port fortran on arm. But the executables generated
> by the cross compiler is giving segmentation fault on the board.

As preremark, I know that gfortran works with RTEMS and VxWorks and on 
Android (ARM) smart phones. Thus, it shouldn't be very difficult to get 
it running on your system. (Fingers crossed.)

> I want to know what special is needs to be initialized in fortran
> program, i mean starup files. And what is to be done for safe termination.

Startup (GCC 4.5 and later): gfortran uses the normal GCC startup, which 
calls main(). If the (main) PROGRAM is written in Fortran, the generated 
main function calls some library initialization functions, cf. 
http://gcc.gnu.org/onlinedocs/gfortran/Non_002dFortran-Main-Program.html

Additionally, the __attribute__((constructor)) is used for some 
initialization in the run-time library and for coarrays (only with 
--fcoarray=lib). Similary for the __attribute__((destructor)). See 
libgfortran/runtime/main.c, libgfortran/intrinsics/{rand,random}.c

For the library, the only more important actions are: Searching for 
addr2line for backtracing and closing still open files when the program 
terminates.

I hope that helps. Good luck!

Tobias
(Continue reading)

Permalink | Reply | 0 comments |
headers
Janne Blomqvist | 2 May 2012 21:22
Picon

Re: [Patch, fortran] PR 49010/24518 MOD/MODULO fixes, take 2

PING #2

On Thu, Apr 26, 2012 at 12:20 AM, Janne Blomqvist
<blomqvist.janne <at> gmail.com> wrote:
> PING!
>
> On Thu, Apr 19, 2012 at 00:46, Janne Blomqvist
> <blomqvist.janne <at> gmail.com> wrote:
>> Hi,
>>
>> the attached patch implements a few fixes and cleanups for the MOD and
>> MODULO intrinsics.
>>
>> - When the arguments are constant, use mpfr_fmod instead of the naive
>> algorithms which are numerically unstable for large arguments. This
>> extends the PR 24518 fix to constant arguments as well, and makes the
>> compile-time evaluation match the runtime implementation which also
>> uses fmod in the same manner.
>>
>> - Remove the old fallback path for the case builtin_fmod is not
>> available, as the builtin is AFAICS always available.
>>
>> - Specify the behavior wrt. the sign and magnitude of the result,
>> mention this in the documentation. This includes signed zeros which
>> now behave similar to other finite values. I.e. for MOD(A, P) the
>> result has the sign of A and a magnitude less than that of P, and for
>> MODULO(A, P) the result has the sign of P and a magnitude less than
>> that of P. As a (minor?) caveat, at runtime this depends on the
>> implementation of the fmod function in the target C library. But, a
>> fmod that follows C99 Annex F implements this behavior.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Paul Richard Thomas | 3 May 2012 11:28
Picon

Regression following fix for PR52621

Dear Richard,

Using an i686/Ubuntu 10.04 LTS and yesterday's trunk, I get from pr52621.f90:

FAIL: gfortran.dg/pr52621.f90  -O  (test for excess errors)
Excess errors:
f951: warning: -fprefetch-loop-arrays not supported for this target
(try -march switches) [enabled by default]

Cheers

Paul

--

-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy
Permalink | Reply | 2 comments |
headers
Richard Guenther | 3 May 2012 11:43
Picon

Re: Regression following fix for PR52621

On Thu, May 3, 2012 at 11:28 AM, Paul Richard Thomas
<paul.richard.thomas <at> gmail.com> wrote:
> Dear Richard,
>
> Using an i686/Ubuntu 10.04 LTS and yesterday's trunk, I get from pr52621.f90:
>
> FAIL: gfortran.dg/pr52621.f90  -O  (test for excess errors)
> Excess errors:
> f951: warning: -fprefetch-loop-arrays not supported for this target
> (try -march switches) [enabled by default]

I'll add -w which seems to be what other tests do.

Richard.

> Cheers
>
> Paul
>
> --
> The knack of flying is learning how to throw yourself at the ground and miss.
>        --Hitchhikers Guide to the Galaxy
Permalink | Reply | 1 comment |
headers
Tobias Burnus | 3 May 2012 11:45
Picon

[Patch, Fortran] PR53111 - fix -std=f95 diagnostic regression (constructor patch)

Dear all,

attached you find a patch for a -std=f95 diagnostic issue related to 
F2003 constructors, which is a 4.7/4.8 rejects-valid regression.

It was build and regtested on x86-64-linux.
OK for 4.7 and the trunk?

Note that a valid-F95 special case is still rejected with -std=f95 (cf. 
attached test case), but I believe that the current patch is sufficient.

Secondly, I try to get again an overview about pending patches. I found:

a) Pending review

- Janne's Fix handling of temporary files
http://gcc.gnu.org/ml/fortran/2012-05/msg00006.html
- Janne's PR 49010/24518 MOD/MODULO fixes, take 2
http://gcc.gnu.org/ml/fortran/2012-05/msg00007.html
- Janne's PR 52428 Reading of large negative values and range checking
http://gcc.gnu.org/ml/fortran/2012-05/msg00008.html
- Thomas' string comparison patch
http://gcc.gnu.org/ml/fortran/2012-04/msg00068.html
- This patch ;-)

b) Pending committal:

- Paul's SELECT TYPE patch
http://gcc.gnu.org/ml/fortran/2012-05/msg00000.html
- Bernhard's cleanup-module patch
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Richard Thomas | 3 May 2012 15:32
Picon

Re: Regression following fix for PR52621

Thanks, Richi

On Thu, May 3, 2012 at 11:43 AM, Richard Guenther
<richard.guenther <at> gmail.com> wrote:
> On Thu, May 3, 2012 at 11:28 AM, Paul Richard Thomas
> <paul.richard.thomas <at> gmail.com> wrote:
>> Dear Richard,
>>
>> Using an i686/Ubuntu 10.04 LTS and yesterday's trunk, I get from pr52621.f90:
>>
>> FAIL: gfortran.dg/pr52621.f90  -O  (test for excess errors)
>> Excess errors:
>> f951: warning: -fprefetch-loop-arrays not supported for this target
>> (try -march switches) [enabled by default]
>
> I'll add -w which seems to be what other tests do.
>
> Richard.
>
>> Cheers
>>
>> Paul
>>
>> --
>> The knack of flying is learning how to throw yourself at the ground and miss.
>>        --Hitchhikers Guide to the Galaxy

--

-- 
The knack of flying is learning how to throw yourself at the ground and miss.
       --Hitchhikers Guide to the Galaxy
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tobias Burnus | 3 May 2012 20:41
Picon

[Patch, Fortran] PR53175 - Fix another fallout of the TREE_PUBLIC=0 module variable patch

A PRIVATE module variable, which is used in the specification expression 
of a function result variable cannot be TREE_PUBLIC()=0, unless the 
function itself is PRIVATE and also not accessible via type-bound 
procedures or a generic name. (The issue is gfortran specific as most 
compilers do not seem to save the specification expression in the .mod 
file.)

Build and regtested on x86-64-linux.
OK for the trunk?

Tobias
Attachment (private_static-fix2.diff): text/x-patch, 3316 bytes
Permalink | Reply | 1 comment |

Gmane