gfortran -fstack-check valgrind Segmentation fault

Hi all!

I am not sure if this should go to valgrind or to gfortran, so it goes
both ways... 

I may be doing something wrong and Google is not very helpful, but it
does look buggy to me:

$ cat ./tst.f90 
program empty
  implicit none
  stop
end program empty
$ gfortran -g -fstack-check -o ./tst ./tst.f90
$ valgrind --tool=memcheck ./tst
==****== Memcheck, a memory error detector
[...]
==****== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
Segmentation fault
$ gfortran -g -o ./tst ./tst.f90
$ valgrind --tool=memcheck ./tst
==****== Memcheck, a memory error detector
[...]
==****== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
$
$ gfortran --version
GNU Fortran (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Copyright (C) 2010 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.

order dependence of -l option

Why must the -l<library> argument be placed after the fortran source 
file name when compiling with gfortran.

The following does not find object codes in libutil.a

gfortran -Llib -lutil a.f90

but the following works as expected

gfortran -Llib a.f90 -lutil

I understand that the order of -l arguments matter is there are multiple 
libraries, but I do not understand why gfortran doesn't just pass the 
-l<library> arguments on to the linker after creating a.o.

[patch, testsuite, committed] Test case for vectorization PR 32380

Hello world,

I committed the attached test case after verifying that it passes and
that only real(4) variables occur (so the requiredment on vect_float
should be correct.)

	Thomas

2012-02-08  Thomas Koenig  <tkoenig <at> gcc.gnu.org>

         PR fortran/32380
         * gfortran.dg/vect/pr32380.f90:  New test.

[Patch, Fortran] PR 52151: reallocation w/ RESHAPE: also set stride

Hi all,

this patch is a follow up to the recent patch on RESHAPE with an 
allocatable LHS. It turned out that if the LHS is not allocated or has 
the wrong shape, the bounds are not correctly set. Or to be precise: The 
just internally used* "stride" is not set correctly.

Result: Either the wrong elements were accessed or - in particular for 
unallocated arrays with "garbage" or malloc_perturb_ initialization - a 
segfault occurred. Especially the case of having the wrong values is nasty!

The bug was found by Dominique, who found it when looking at the 
chapter08/puppeteer_f2003 example in Damian (et al.)'s book. Thanks 
Dominique!

While that's not a regression, I think the bug is seriously enough and 
the fix simple enough that it should also be applied to 4.6.

Thus: OK for the trunk and 4.6? (The patch has been build and regtested 
on x86-64-linux.)

Tobias

2012-02-08  Tobias Burnus  <burnus <at> net-b.de>

	PR fortran/52151
	* trans-expr.c (fcncall_realloc_result): Set also the stride.

2012-02-08  Tobias Burnus  <burnus <at> net-b.de>

[Patch, fortran] PR50981 (elemental/optional interaction) follow-up fix

Hello,

this fixes the fairly recent PR50981 patch
[http://gcc.gnu.org/ml/fortran/2011-12/msg00170.html] which didn't work 
for subroutine calls, as they use code->resolved_sym instead of 
code->expr1 to store the procedure symbol.

The first patch moves gfc_walk_elemental_function_args's code to get the 
procedure interface into a new procedure.

The second patch moves the procedure call out of 
gfc_walk_elemental_function_args.

The third patch changes the function called in gfc_trans_call so that 
code->resolved_sym is used if code->expr1 fails to give the interface.
I choose to try code->expr1 first for fear that in typebound calls, 
code->resolved_sym may point to the base object, which is obviously not 
the procedure interface.

The testcase is Tobias' comment #13
[http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50981#c13] stripped down to 
the working part.

Regression tested on x86_64-unknown-freebsd9.0. OK for trunk?

Mikael

2012-02-07  Mikael Morin  <mikael <at> gcc.gnu.org>

Regression on character function

Gfortran developers,

A build from a snapshot of the development branch as of two days ago
(installed by macports) appears to have a regression on deferred-length
character functions.  The text below shows a test that compiles with gcc
4.6.2 but not with 4.7.  Should I file a PR?

Damian

$ cat character_function.F90
module foo_class 
  implicit none 
  type foo 
  contains 
    procedure :: bar
  end type 
contains 
  function bar(this)
    class(foo) :: this
    character(:), allocatable :: bar
  end function 
end module 
$ /opt/local/bin/gfortran-mp-4.6 -c character_function.F90
$ /opt/local/bin/gfortran-mp-4.7 -c character_function.F90
character_function.F90:9.22:

    class(foo) :: this
                      1
Error: Deferred-length character component 'bar' at (1) is not yet
supported

Re: Added test case for PR 32373, missed vectorization with equivalence

Thomas,

The test fails on powerpc-apple-darwin9 because double are not
vectorized. I think the following patch is required:

--- /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/vect/vect-8.f90	2012-02-05
23:32:31.000000000 +0100
+++ /opt/gcc/work/gcc/testsuite/gfortran.dg/vect/vect-8.f90	2012-02-06 11:17:54.000000000 +0100
@@ -1,5 +1,5 @@
 ! { dg-do compile }
-! { dg-require-effective-target vect_float }
+! { dg-require-effective-target vect_double }

 module lfk_prec
  integer, parameter :: dp=kind(1.d0)

TIA

Dominique

[patch, fortran] Fix PR 48847, bogus "unused parameter" warning

Hello world,

the attached, rather obvious patch fixed a bogus "unused parameter"
warning with procedure dummy arguments and warns about these if
they occur.

Regression-tested.  OK for trunk?  Or rather wait until 4.8?

	Thomas

2012-02-05  Thomas König  <tkoenig <at> gcc.gnu.org>

         PR fortran/48847
         * trans-decl.c:  Warn about unused dummy procedure arguments
         if -Wunused-dummy-argument is specified.  Suppress middle-end
         warnings about procedure arguments.

2012-02-05  Thomas König  <tkoenig <at> gcc.gnu.org>

         PR fortran/48847
         * gfortran.dg/warn_unused_dummy_argument_3.f90:  New test.

Index: trans-decl.c
===================================================================
--- trans-decl.c	(Revision 183873)
+++ trans-decl.c	(Arbeitskopie)
@@ -4683,6 +4683,22 @@ generate_local_decl (gfc_symbol * sym)
 	  && sym->ts.type == BT_CHARACTER && sym->ts.is_c_interop
 	  && sym->ns->proc_name != NULL && sym->ns->proc_name->attr.is_bind_c)

[Patch, Fortran, committed] PR51972 - Extended checking of gfortran.dg/class_48.f90

The patch for PR 51972 fixed some issues with intrinsic assignment, 
which involved polymorphic components.

However, I couldn't check the correctness in some cases as I run ICEs. 
Those were fixed by Mikael's recent patch (cf. PR 51754 et alia).

The committed (Rev. ) and attached patch adds the missing checks. On the 
way, I run into another issue (now: PR 52102), which I worked around. 
However, as MALLOC_PERTURB_ or valgrind shows, the issue also affects 
the current version. Thus, in the committed patch, only test3() has 
proper checking, for test4() I have added a commented out test case, 
which without MALLOC_PERTURB_ should work.

Committed as Rev. 183904.

Tobias

Index: gcc/testsuite/gfortran.dg/class_48.f90
===================================================================
--- gcc/testsuite/gfortran.dg/class_48.f90	(Revision 183903)
+++ gcc/testsuite/gfortran.dg/class_48.f90	(Arbeitskopie)
@@ -70,14 +70,16 @@

   type(t2) :: one, two

-  one = two
+  allocate (two%a(2))
+  two%a(1)%x = 4
+  two%a(2)%x = 6

closing bug reports in bugzilla

Hello All,

I was in bugzilla trolling for something little to consume a little
time on this Saturday morning, and have kind of come to the
realization that we are very reluctant to close bug reports.

Reluctant is not a problem, in general, but over a period of time it
makes the whole list of open bug reports a little overwhelming.

There are a fair number of bug reports where the last comment is
something like " I propose we close this with no further action".
(maybe 10 of these? maybe more?)

I would like to ask, or propose, the following:

If there is a comment that recommends closure, and another member of
the team (using the definition of the team as loosely as possible)
concurs, then we go ahead and close the bug.

Is this OK ?

--bud davis

[Patch, Fortran] PR 52093 - fix simplification of SIZE((x))

Dear all,

I have committed the attached patch as obvious (Rev.183848) - after 
building and regtesting on x86-64-linux.

I intent to backport it to 4.6 soon. (It's a regression.)

Tobias

2012-02-02  Tobias Burnus  <burnus <at> net-b.de>

	PR fortran/52093
	* simplify.c (gfc_simplify_size): Handle INTRINSIC_PARENTHESES.

2012-02-02  Tobias Burnus  <burnus <at> net-b.de>

	PR fortran/52093
	* gfortran.dg/shape_7.f90: New.

Index: gcc/fortran/simplify.c
===================================================================
--- gcc/fortran/simplify.c	(Revision 183846)
+++ gcc/fortran/simplify.c	(Arbeitskopie)
@@ -5541,6 +5541,7 @@ gfc_simplify_size (gfc_expr *array, gfc_expr *dim,
 	  case INTRINSIC_NOT:
 	  case INTRINSIC_UPLUS:
 	  case INTRINSIC_UMINUS:
+	  case INTRINSIC_PARENTHESES:
 	    replacement = array->value.op.op1;