[Bug fortran/45170] [F2003] allocatable character lengths

2011-08-26 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170

--- Comment #23 from Hans-Werner Boschmann boschmann at tp1 dot 
physik.uni-siegen.de 2011-08-26 10:05:32 UTC ---
Is there any chance that gfortran 4.7.0 will support allocatable character
lengths? Using fortran for text processing has been painful since time
immemorial and this little feature is a huge leap indeed.

Unlike iso_varying_string you can combine allocatable characters to all other
built-in features of fortran like print *,string. Additionally, as soon as it
is allocated, you can assign it to a non-allocatable dummy characters so no one
but the supplier has to care about whether it is dynamic or not. That's why it
is much more powerful than iso_varying_string.

[Bug fortran/45170] [F2003] allocatable character lengths

2011-08-26 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170

--- Comment #25 from Hans-Werner Boschmann boschmann at tp1 dot 
physik.uni-siegen.de 2011-08-26 19:44:10 UTC ---
(In reply to comment #24)

 Looking at your code in comment #17, one can easily find
 a trivial change to make it work.

Thank you, I was not aware of this. I was always wondering why you said that it
is partly working, because I could not at all allocate characters. But knowing
this, I should be able to fix my code.

 Yes, there are some bugs, but no one
 has had time to track down the few remaining issues.

Sure, please don't feel pushed. It is in fact a miracle that you keep up with
companies like intel or portland without comparable funding. Great job!

[Bug fortran/45170] [F2003] allocatable character lengths

2011-07-12 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170

Hans-Werner Boschmann boschmann at tp1 dot physik.uni-siegen.de changed:

   What|Removed |Added

 CC||boschmann at tp1 dot
   ||physik.uni-siegen.de

--- Comment #14 from Hans-Werner Boschmann boschmann at tp1 dot 
physik.uni-siegen.de 2011-07-12 13:51:08 UTC ---
I've got one more item for the TODO list:

character(:),allocatable::string
integer::length
length=5
allocate(character(len=length)::string)

This is not yet accepted by gfortran. Is there any other way to allocate
string without a primitive like string=repeat( ,10)?

[Bug fortran/45170] [F2003] allocatable character lengths

2011-07-12 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170

--- Comment #17 from Hans-Werner Boschmann boschmann at tp1 dot 
physik.uni-siegen.de 2011-07-12 15:00:22 UTC ---
This sounds like there is still a lot of work to do in this character issue.
Has anyone ever managed to allocate such strings dynamically? In 

(In reply to comment #15)
 character(:),allocatable::string
 string='yes!!'
 print *, string
 end

the length is constant so you could use character(5)::string. That's not what I
mean, I would like to have something like this:

PROGRAM helloworld
  character(:),allocatable::string
  real::rnd
  call random_number(rnd)
  call hello(ceiling(11*rnd),string)
  print *,string
contains
  subroutine hello (n,string)
character(:),allocatable,intent(out)::string
integer,intent(in)::n
character(10)::helloworld=hello world
string=helloworld(:n)
  end subroutine hello
end PROGRAM helloworld

I guess that's not yet possible with gfortran.

[Bug fortran/49638] New: [OOP] length parameter is ignored when overriding type bound character functions with constant length.

2011-07-05 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49638

   Summary: [OOP] length parameter is ignored when overriding type
bound character functions with constant length.
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boschm...@tp1.physik.uni-siegen.de


module world
  implicit none
  type::world_1
   contains
 procedure,nopass::string=w1_string
  end type world_1
  type,extends(world_1)::world_2
   contains
 procedure,nopass::string=w2_string
  end type world_2
contains
  function w1_string()
character(6)::w1_string
w1_string= world
  end function w1_string
  function w2_string()
character(7)::w2_string
w2_string= world2
  end function w2_string
end module world
program hello
  use world
  implicit none
  type(world_1)::w1
  type(world_2)::w2
  print *,hello world: hello,w1%string()
  print *,hello world2: hello,w2%string()
end program hello

This program compiles and runs fine with gfortran 4.6.1 and gfortran 4.7.
Nevertheless, the length of an array is a type parameter and all type
parameters of an overriding function shall match the overridden type
parameters.

[Bug fortran/49630] New: [OOP] ICE on obsolescent assumed length deferred type bound character function

2011-07-04 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630

   Summary: [OOP] ICE on obsolescent assumed length deferred type
bound character function
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boschm...@tp1.physik.uni-siegen.de
CC: ja...@gcc.gnu.org


Here is one more weird piece of code:

module abc
  implicit none
  type,abstract::abc_abstract
   contains
 procedure(abc_interface),deferred::abc_function
  end type abc_abstract
  type,extends(abc_abstract)::abc_type
   contains
 procedure::abc_function
  end type abc_type
  abstract interface
 function abc_interface(this)
   import abc_abstract
   class(abc_abstract),intent(in)::this
   character(len=*)::abc_interface !obsolescent feature
 end function abc_interface
  end interface
contains
  function abc_function(this)
class(abc_type),intent(in)::this
character(len=5)::abc_function
abc_function=hello
  end function abc_function
  subroutine do_something(this)
class(abc_abstract),intent(in)::this
print *,this%abc_function()
  end subroutine do_something
end module abc

gcc 4.7 terminates with a segmentation fault. I get an ICE error message on my
full program, but it turned to a segfault in this reduced module.

Anyway this code doesn't look right, so I have tried some workarounds like
allocatable characters. But those ended up in different compiler errors.

So what is the state of allocatable character functions? Are they supposed to
work?

[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function

2011-07-04 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630

--- Comment #2 from Hans-Werner Boschmann boschmann at tp1 dot 
physik.uni-siegen.de 2011-07-04 19:29:50 UTC ---
C417: A function name shall not be declared with an asterisk type-param-value
unless it is of type CHAR- ACTER and is the name of the result of an external
function or the name of a dummy function.

So it is allowed to put an assumed character length into an interface, but not
in the way as I did in the code above. My example is invalid.

But how would I declare an abstract interface of a function with variable
length? I am allowed to use any scalar integer expression as length parameter
of a character function, but I cannot leave it empty in the interface. That's
why I use character(:),allocatable::res with the NAG fortran compiler. As far a
I know, this is the only valid way and that's why I am looking forward for
gfortran to implement it.

[Bug fortran/49562] New: [OOP] ICE at invalid code: assigning value to function of polymorphic object

2011-06-28 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49562

   Summary: [OOP] ICE at invalid code: assigning value to function
of polymorphic object
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boschm...@tp1.physik.uni-siegen.de
CC: ja...@gcc.gnu.org


The code:

module ice
  type::ice_type
   contains
 procedure::ice_func
  end type ice_type
contains
  pure integer function ice_func(this)
class(ice_type),intent(in)::this
ice_func=1
  end function ice_func
  subroutine ice_sub(a)
class(ice_type)::a
a%ice_func()=1   ! This is the invalid line
  end subroutine ice_sub
end module ice

The marked line is obviously not allowed. When I replace class(ice_type)::a by
type(ice_type)::a then get a proper error message, but the class statement
results in an internal compiler error.

My gfortran version is 4.7.0 20110620

[Bug fortran/48059] New: [OOP] ICE in in gfc_conv_component_ref: character function of extended type

2011-03-10 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059

   Summary: [OOP] ICE in in gfc_conv_component_ref: character
function of extended type
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boschm...@tp1.physik.uni-siegen.de


The code:
module a_module
  type :: a_type
 integer::length=0
  end type a_type
  type,extends(a_type) :: b_type
  end type b_type
contains
  function a_string(this) result(form)
class(a_type),intent(in)::this
character(max(1,this%length))::form
  end function a_string
  subroutine b_sub(this)
class(b_type),intent(inout),target::this
print *,a_string(this)
  end subroutine b_sub
end module a_module

The ICE message:
a.f90: In Funktion »b_sub«:
a.f90:14:0: interner Compiler-Fehler: in gfc_conv_component_ref, bei
fortran/trans-expr.c:523

Fortran version:
GNU Fortran (GCC) 4.6.0 20110310 (experimental)

I know that the length specification in a_string is a little bit creepy, but it
is valid. I had a discussion with the NAG about this before and they decided to
give a questionable warning message but no error message.

It anyway went right until today. I have updated gfortran and got this ICE for
the first time although the code is a few months old now. Unfortunately, I'm
not totally sure when I have done the last update before.

[Bug fortran/48059] [OOP] ICE in in gfc_conv_component_ref: character function of extended type

2011-03-10 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48059

--- Comment #2 from Hans-Werner Boschmann boschmann at tp1 dot 
physik.uni-siegen.de 2011-03-10 14:06:06 UTC ---
I have removed this character function from my project and found the same ICE
message with other, non character-valued functions of extended types. So it
seems to be a more general problem then character-valued functions.

[Bug fortran/45827] [4.6 Regression] [OOP] mio_component_ref(): Component not found

2011-01-03 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827

--- Comment #44 from Hans-Werner Boschmann boschmann at tp1 dot 
physik.uni-siegen.de 2011-01-03 12:55:53 UTC ---
I've run my project on R168414, there are no error messages so far. Thank you
all for making this fix, this bug has bothered me for a long time.

[Bug fortran/46210] New: segfault when using large arrays with -fopenmp

2010-10-28 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46210

   Summary: segfault when using large arrays with -fopenmp
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boschm...@tp1.physik.uni-siegen.de


I don't know, whether this is a gcc bug or a openMP bug, but maybe you can
tell. When I use large arrays with dimension  2**20 and compile with -fopenmp,
then the executable will cause a segmentation fault. The code is:

program mpbug
  implicit none
  integer,parameter::dim=2**21
  integer,dimension(dim)::array
  integer::d
  forall(d=1:dim)
 array(d)=0
  end forall
end program mpbug

gfortran -fopenmp mpbug.f03

valgrind --leak-check=full  `gfortran -v 21 -fopenmp mpbug.f03 | grep f951`
==20196== Memcheck, a memory error detector
==20196== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==20196== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==20196== Command:
/opt/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951 mpbug.f03 -quiet
-dumpbase mpbug.f03 -mtune=generic -march=x86-64 -auxbase mpbug -version
-fopenmp -fintrinsic-modules-path
/opt/gcc-trunk/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/finclude -o
/tmp/cc0xLtsi.s
==20196== GNU Fortran (GCC) Version 4.6.0 20101022 (experimental)
(x86_64-unknown-linux-gnu)
kompiliert von GNU-C-Version 4.6.0 20101022 (experimental), GMP version
4.3.1, MPFR version 2.4.2, MPC version 0.8.1
GGC-Heuristik: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU Fortran (GCC) Version 4.6.0 20101022 (experimental)
(x86_64-unknown-linux-gnu)
kompiliert von GNU-C-Version 4.6.0 20101022 (experimental), GMP version
4.3.1, MPFR version 2.4.2, MPC version 0.8.1
GGC-Heuristik: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
==20196==
==20196== HEAP SUMMARY:
==20196== in use at exit: 322,314 bytes in 1,357 blocks
==20196==   total heap usage: 3,715 allocs, 2,358 frees, 2,114,876 bytes
allocated
==20196==
==20196== 159 bytes in 1 blocks are definitely lost in loss record 264 of 330
==20196==at 0x4C234E7: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20196==by 0xCEF728: xcalloc (xmalloc.c:162)
==20196==by 0x659964: init_emit (emit-rtl.c:5582)
==20196==by 0x6E68D8: prepare_function_start (function.c:4382)
==20196==by 0x6EC428: init_function_start (function.c:4436)
==20196==by 0x551E6E: trans_function_start.isra.2 (trans-decl.c:2003)
==20196==by 0x55C110: gfc_generate_function_code (trans-decl.c:4563)
==20196==by 0x503B67: gfc_parse_file (parse.c:4243)
==20196==by 0x53B495: gfc_be_parse_file (f95-lang.c:250)
==20196==by 0x839E2F: toplev_main (toplev.c:919)
==20196==by 0x5709A7C: (below main) (libc-start.c:220)
==20196==
==20196== 159 bytes in 1 blocks are definitely lost in loss record 265 of 330
==20196==at 0x4C234E7: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==20196==by 0xCEF728: xcalloc (xmalloc.c:162)
==20196==by 0x659964: init_emit (emit-rtl.c:5582)
==20196==by 0x6E68D8: prepare_function_start (function.c:4382)
==20196==by 0x6EC428: init_function_start (function.c:4436)
==20196==by 0x55CAA5: gfc_generate_function_code (trans-decl.c:4315)
==20196==by 0x503B67: gfc_parse_file (parse.c:4243)
==20196==by 0x53B495: gfc_be_parse_file (f95-lang.c:250)
==20196==by 0x839E2F: toplev_main (toplev.c:919)
==20196==by 0x5709A7C: (below main) (libc-start.c:220)
==20196==
==20196== LEAK SUMMARY:
==20196==definitely lost: 318 bytes in 2 blocks
==20196==indirectly lost: 0 bytes in 0 blocks
==20196==  possibly lost: 0 bytes in 0 blocks
==20196==still reachable: 321,996 bytes in 1,355 blocks
==20196== suppressed: 0 bytes in 0 blocks
==20196== Reachable blocks (those to which a pointer was found) are not shown.
==20196== To see them, rerun with: --leak-check=full --show-reachable=yes
==20196==
==20196== For counts of detected and suppressed errors, rerun with: -v
==20196== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)


valgrind --leak-check=full  ./a.out 
(...)
==20234== Invalid write of size 4
==20234==at 0x400644: MAIN__ (in
/afs/tp1.physik.uni-siegen.de/user/boschmann/tmp/gccbug/openmp/a.out)
==20234==by 0x40068C: main (in
/afs/tp1.physik.uni-siegen.de/user/boschmann/tmp/gccbug/openmp/a.out)
==20234==  Address 0x7fe7ffc40 is on thread 1's stack
==20234==
==20234==
==20234== Process terminating with default action of signal 11 (SIGSEGV)
==20234==  Access not within mapped region at address 0x7FE7FFC40
==20234==at 0x400644: MAIN__ (in
/afs/tp1.physik.uni-siegen.de/user/boschmann/tmp/gccbug/openmp/a.out)
==20234==  If you believe this happened as a result of a stack
==20234==  overflow in your program's main thread (unlikely but
==20234==  possible), you can try to

[Bug fortran/46210] segfault when using large arrays with -fopenmp

2010-10-28 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46210

--- Comment #1 from Hans-Werner Boschmann boschmann at tp1 dot 
physik.uni-siegen.de 2010-10-28 12:23:15 UTC ---
(In reply to comment #0)

Sorry, I was to quick. The reason is already given in the valgrind output. The
stack size is to small. So it's neither gcc's fault nor openmp's fault.

[Bug fortran/46196] New: [OOP] gfortran compiles invalid generic TBP: dummy arguments are type compatible

2010-10-27 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46196

   Summary: [OOP] gfortran compiles invalid generic TBP: dummy
arguments are type compatible
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boschm...@tp1.physik.uni-siegen.de


module generic
  type :: a_type
   contains
 procedure :: a_subroutine
  end type a_type
  type,extends(a_type) :: b_type
   contains
 procedure :: b_subroutine
 generic :: g_sub = a_subroutine,b_subroutine
  end type b_type
contains
  subroutine a_subroutine(this)
class(a_type)::this
  end subroutine a_subroutine
  subroutine b_subroutine(this)
class(b_type)::this
  end subroutine b_subroutine
end module generic

GNU Fortran (GCC) 4.6.0 20101022 (experimental)

This code is invalid, because the dummy arguments in a_subroutine and
b_subroutine are type compatible. Therefore they must not share a generic
interface.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

2010-10-27 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827

--- Comment #31 from Hans-Werner Boschmann boschmann at tp1 dot 
physik.uni-siegen.de 2010-10-27 09:35:07 UTC ---
I've posted the generic issue as Bug 46196

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

2010-10-26 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827

--- Comment #30 from Hans-Werner Boschmann boschmann at tp1 dot 
physik.uni-siegen.de 2010-10-26 15:27:27 UTC ---
I've realized today, that the sample code is actually invalid. If you look at
lines 488 and 681 in arguments.f03, you'll see:

subroutine
argument_initialize(this,arg_list,short,long,description,description_list,named_option)
subroutine real_argument_initialize(this)

These subroutines seem to have different interfaces, but when you have a closer
look, you see that all dummy arguments are optional, except this. Besides,
both this dummy arguments are type compatible. Therefore these subroutines
must not share a generic interface. But that is declared in line 133:

generic::initialize=argument_initialize,real_argument_initialize

Could this ambiguity cause the confusion about symbols? I always have suspected
this module to be the reason for the error, because I never got the error
message before I wrote it. Furthermore, all error messages were somehow related
to this module, even when they were generated for other modules. 

Nevertheless, gfortran should complain about the ambiguity. I will try to
reduce the code to illustrate this point and open a new bug report.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

2010-10-24 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827

--- Comment #22 from Hans-Werner Boschmann boschmann at tp1 dot 
physik.uni-siegen.de 2010-10-24 10:17:00 UTC ---
Yes, I still get the error with later revisions. I am using an amd64 machine
with open SuSE 11.2. Here are some updates of my statements:

* All means like renaming files or using -std=f2003 coincidentally fixed the
problem for a specific revision and a specific peace of code. This is no
general fix.

* I also got the error with 4.6.0-20100928 when I changed some lines of code.

* Putting all use statements in proper order fixes the problem for all
revisions, including 4.6.0-20100921. I noticed later, that I forgot to sort the
intrinsic module iso_fortran_env in the example. It is mentioned before kinds
in arguments_module and after kinds in common_module.

* Not putting use statements into proper order doesn't mean that the error
shows up, it randomly appears sometimes while you edit the code.

So I have to update use statements in all modules, when I change dependencies
in a fundamental module. That's really annoying, but it is a workaround for all
revisions so far. Still, this is not what I take to mean works for me.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

2010-10-01 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827

--- Comment #15 from Hans-Werner Boschmann boschmann at tp1 dot 
physik.uni-siegen.de 2010-10-01 06:52:14 UTC ---
Thank you, now I understand the difference. The correct invocation does not
supply any new information.

Revision 20100928 compiles my code, so it's fine for me now. But I have got
huge tables of use statements in my modules and I continue to get this error
message, when I forget to explicitly use the whole tree of modules.

It also might has been a coincidence that the error disappeared when I renamed
kind.f90 to kinds.f03. I did the same for 20100928, and it didn't work. But
mentioning all modules works for 20100928.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

2010-10-01 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827

--- Comment #16 from Hans-Werner Boschmann boschmann at tp1 dot 
physik.uni-siegen.de 2010-10-01 07:57:44 UTC ---
I have checked the f90/f03 combination again, there DEFINITELY IS A CORRELATION
between mixing dialects and the error. Using -std=f2003 also fixed the problem.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

2010-09-30 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827

--- Comment #11 from Hans-Werner Boschmann boschmann at tp1 dot 
physik.uni-siegen.de 2010-09-30 07:37:46 UTC ---
So it works with 4.6.0 20100924, but it still doesn't work with 4.6.0 20100921.
Unfortunately, I cannot use the latest revision, until bug 45746 is fixed.
Plus, I assume that the error message will show up in later revisions again.

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

2010-09-30 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827

--- Comment #13 from Hans-Werner Boschmann boschmann at tp1 dot 
physik.uni-siegen.de 2010-09-30 13:03:09 UTC ---
(In reply to comment #12)
 Actually, I am confused: From that comment it sounds as if 20100921 does not
 have the bug 45746 - but it has been reported using 20100921 and a comment by
 Dominique indicates that it never worked with GCC 4.5/4.6 but it only worked
 for a while on the fortran-dev branch.

You are right about this, I'm switching back and forth in the version of gcc
and got lost.


But I have run valgrind now. It was the first time, so I don't understand the
result. Is it somehow the fault of my hardware/OS? Here is the output:


valgrind --leak-check=full /opt/gcc-trunk/bin/gfortran -ffree-form
-ffree-line-length-0 -I. -L.  -c common.f03 -o common.o
==31832== Memcheck, a memory error detector 
==31832== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.   
==31832== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info 
==31832== Command: /opt/gcc-trunk/bin/gfortran -ffree-form -ffree-line-length-0
-I. -L. -c common.f03 -o common.o  
==31832==   
common.f03:27.22:   

  use arguments_module
  1
Interner Fehler bei (1):
mio_component_ref(): Component not found
==31832==   
==31832== HEAP SUMMARY: 
==31832== in use at exit: 32,209 bytes in 82 blocks
==31832==   total heap usage: 268 allocs, 186 frees, 49,388 bytes allocated
==31832==  
==31832== 1 bytes in 1 blocks are definitely lost in loss record 2 of 70   
==31832==at 0x4C234E7: calloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==by 0x41FC38: xcalloc (xmalloc.c:162)   
==31832==by 0x40DE7F: main (gcc.c:6993) 
==31832==   
==31832== 4 bytes in 1 blocks are possibly lost in loss record 4 of 70  
==31832==at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==by 0x41FBF7: xmalloc (xmalloc.c:147)   
==31832==by 0x41DA2D: concat (concat.c:159) 
==31832==by 0x407090: driver_handle_option (gcc.c:3729) 
==31832==by 0x410A37: handle_option (opts-common.c:673) 
==31832==by 0x410B7C: read_cmdline_option (opts-common.c:812)   
==31832==by 0x40580E: process_command (gcc.c:4177)  
==31832==by 0x40C63C: main (gcc.c:6593) 
==31832==   
==31832== 15 bytes in 1 blocks are definitely lost in loss record 10 of 70  
==31832==at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==by 0x41FBF7: xmalloc (xmalloc.c:147)   
==31832==by 0x4025D5: save_string (gcc.c:7322)  
==31832==by 0x40B3AB: handle_braces (gcc.c:6093)
==31832==by 0x409303: do_spec_1 (gcc.c:5485)
==31832==by 0x40B455: handle_braces (gcc.c:6096)
==31832==by 0x409303: do_spec_1 (gcc.c:5485)
==31832==by 0x40B455: handle_braces (gcc.c:6096)
==31832==by 0x409303: do_spec_1 (gcc.c:5485)
==31832==by 0x40A25A: do_spec_2 (gcc.c:4554)
==31832==by 0x40A282: do_self_spec (gcc.c:4619) 
==31832==by 0x40ABCE: do_option_spec (gcc.c:4608)   
==31832==   
==31832== 18 bytes in 1 blocks are definitely lost in loss record 16 of 70  
==31832==at 0x4C241C3: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==31832==by 0x41FBF7: xmalloc (xmalloc.c:147)   
==31832==by 0x4025D5: save_string (gcc.c:7322)  
==31832==by 0x40B3AB: handle_braces (gcc.c:6093)
==31832==by 0x409303: do_spec_1 (gcc.c:5485)
==31832==by 0x40B455: handle_braces (gcc.c:6096)
==31832==by 0x409303: do_spec_1 (gcc.c:5485)
==31832==by 0x40B455: handle_braces (gcc.c:6096)
==31832==by 0x409303: do_spec_1 (gcc.c:5485

[Bug fortran/45827] New: mio_component_ref(): Component not found when mixing f90 and f03 in large projects

2010-09-29 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827

   Summary: mio_component_ref(): Component not found when mixing
f90 and f03 in large projects
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: boschm...@tp1.physik.uni-siegen.de


Created attachment 21911
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=21911
The sample source code of this bug report

common.f03:27.22:

  use arguments_module
  1
Interner Fehler bei (1):
mio_component_ref(): Component not found

GNU Fortran (GCC) 4.6.0 20100921 (experimental)


Hi all!

First of all, I'm sorry about the bad sample code for this bug. It is attached
to the report as gccbug.tar.gz. This bug has bothered me for a while and I
never was able to isolate it. The error message comes and goes when I update to
the latest revision of gfortran and appears in a part of my project, when I
edit a completely different part. Now it showed up in a module with few
dependencies to other modules. It is the smallest collection of modules so far,
that show this bug. I can repair it, when

* I rename all files to *.f03. Usually, *.f90 files are mixed with *.f03 in my
project. Maybe this is not supposed to work, but the compiler should give a
better error message then.

* I add an use statement for all modules that are used by the used modules and
put them into proper order, such that no module depends to a module that is
used further down. That is what I've done until now, because I didn't knew
the first fact till this day. But in 4.6.0 20100921, even this has failed.

* I remove symbols somewhere. Obviously, the bug needs a certain complexity to
show up. That's why I cannot give you a smaller sample code.

* I use the actual GNU Fortran (GCC) 4.6.0 20100928. But it already happened,
that the bug disappeared and appeared again.

Best regards,
Hans Boschmann

[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects

2010-09-29 Thread boschmann at tp1 dot physik.uni-siegen.de 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827

--- Comment #9 from Hans-Werner Boschmann boschmann at tp1 dot 
physik.uni-siegen.de 2010-09-29 11:49:11 UTC ---
My makefile is now:
FC=gfortran
FFLAGS=-ffree-form -ffree-line-length-0 -I. -L.

all: common.o common_module.mod arguments.o arguments_module.mod kinds.o
kinds.mod

kinds.o kinds.mod: kinds.f90
$(FC) $(FFLAGS) -c $ -o kinds.o

arguments.o arguments_module.mod: arguments.f03 kinds.mod
$(FC) $(FFLAGS) -c $ -o arguments.o

common.o common_module.mod: common.f03 arguments_module.mod kinds.mod
$(FC) $(FFLAGS) -c $ -o common.o

clean:
rm -rf *.mod *.o test


The result:

gfortran -ffree-form -ffree-line-length-0 -I. -L.  -c kinds.f90 -o kinds.o
gfortran -ffree-form -ffree-line-length-0 -I. -L.  -c arguments.f03 -o
arguments.o
gfortran -ffree-form -ffree-line-length-0 -I. -L.  -c common.f03 -o common.o
common.f03:27.22:

  use arguments_module
  1
Interner Fehler bei (1):
mio_component_ref(): Component not found
make: *** [common.o] Fehler 1