gfortran compiler error: pointer arguments
sudeep
I am unable to compile the following code using gfortran v4.4. I get
the following message
test.f90: In function 'test_sub':
test.f90:15: internal compiler error: Bus error
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
Has this bug been reported before? Is there any way to rewrite the
subroutine without changing the definition of the derived types?
Sincerely,
Sudeep
module test
implicit none
!===================================================
type b
integer :: j
end type b
!===================================================
type a
type(b), dimension(4) :: i
end type a
!===================================================
contains
!===================================================
subroutine test_sub(sorb,ipn)
type(a), intent(in), target :: sorb
integer, dimension(:), pointer :: ipn
ipn=>sorb%i%j
end subroutine test_sub
!===================================================
end module test
Tobias Burnus
sudeep wrote:
> test.f90:15: internal compiler error: Bus error
> Please submit a full bug report,
>
> Has this bug been reported before?
I don't think so; I filled it at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
Otherwise: It is better to either write to
fortran <at> gcc <dot> gnu <another dot> org
or to fill a bug in Bugzilla.
Tobias
adda
"sudeep" <sudeep.pu...@gmail.com> wrote in message
news:5c0feae3-2583-4cfe...@w24g2000prd.googlegroups.com...
> Hi,
>
> I am unable to compile the following code using gfortran v4.4. I get
> the following message
>
> test.f90: In function 'test_sub':
> test.f90:15: internal compiler error: Bus error
What is Bus error?
v4.3.2 gets the error, too.
gcc version 4.3.2 (GCC)
C:\TEMP\fortran>gfortran 1210.f90
1210.f90: In function 'test_sub':
1210.f90:15: internal compiler error: Segmentation fault
Tobias Burnus
>> the following message
I forgot in my previous reply the following: Thank you for reporting the
bug.
>> test.f90: In function 'test_sub':
>> test.f90:15: internal compiler error: Bus error
>
> What is Bus error?
> v4.3.2 gets the error, too.
I'm not exactly sure what is the difference between a SIGBUS (bus error)
and SIGSEGV (segmentation fault), but the problem is here that the C
pointer (gfortran is written in C) "lang_decl" is NULL but one tries to
access "lang_decl->span" which accesses an invalid spot in the memory.
This is denied and the program (the compiler) is killed.
The problem occurs for
pointer => derived_type_array%component
where derived_type_array is an array (section). In principle that should
work, but some attributes cause that the wrong code path is taken in the
compiler.
I think it should be fixed in the next days for 4.4 and about one week
later for 4.3.
As written before: The issue is tracked at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38471
and the proper place to report such problems is Bugzilla or the gfortran
mailing list. Reports elsewhere might get missed.
(The number of invalid bug reports is low enough that we don't bite if
they get reported. ;-) Furthermore, internal compiler errors are by
definition always valid bugs.)
Tobias
PS: I checked wikipedia for SIGBUS vs. SIGSEGV. And SIGBUS is thrown for
"non-existent physical address[es]. This is equivalent to a segmentation
fault [SIGSEGV], but for a physical address rather than a virtual address."
fj
> Hi,
>
> sudeep wrote:
> > test.f90:15: internal compiler error: Bus error
> > Please submit a full bug report,
>
> > Has this bug been reported before?
>
>
> Otherwise: It is better to either write to
> fortran <at> gcc <dot> gnu <another dot> org
> or to fill a bug in Bugzilla.
>
> Tobias
A very similar bug has already been reported (bug 34640). But the last
situation was the following e-mail :
------- Comment #8 from pault at gcc dot gnu dot org 2008-11-06
06:24 -------
Wait until 4.5.0 since it needs the array descriptor reform to be
fixed.
Jan Vorbrüggen
> and SIGSEGV (segmentation fault)
>
> "non-existent physical address[es]. This is equivalent to a segmentation
> fault [SIGSEGV], but for a physical address rather than a virtual address."
Hmmm...well, almost...in that the terms come from a time and a computer
that didn't have a virtual address (as we know them now)...SIGBUS came
from accessing that part of the address space reserved to I/O devices on
the UNIBUS. I believe the non-I/O half was protected by segment
registers (setting base and bound), that's why early Unix called it a
segmentation fault.
In any case, it shows how implementation details from at least three
decades back still serve to - quite unnecessarily - confuse the
grandchildren of the perpetrators 8-)...
Jan
Glen Herrmannsfeldt
(snip)
> PS: I checked wikipedia for SIGBUS vs. SIGSEGV. And SIGBUS is thrown for
> "non-existent physical address[es]. This is equivalent to a segmentation
> fault [SIGSEGV], but for a physical address rather than a virtual address."
The difference mostly doesn't apply on today's machines.
SIGBUS came on many older machines from accessing memory that
didn't exist at all. The address went out on the bus, and if no
memory board responded, a timer that would terminate
the memory cycle and trigger the interrupt. (I believe this
came from early PDP-11 systems. S/360 would call this an
addressing exception.)
SIGSEGV usually meant addressing memory that did exist but that
you weren't allowed to access. Either trying to write somewhere
that you only have read access to, or to memory that your aren't
allowed access to at all. (This would be a protection
exception on S/360.)
Many newer machines without virtual memory completely ignore the
fact that an address is outside the installed memory and return
whatever happens to be on the bus. (Often X'FF' as the bus
floats high.)
With virtual memory, any access errors are processed by the virtual
memory system and in most cases only one type of exception is reported
to the user program.
-- glen
jfh
> adda wrote:
> > "sudeep" <sudeep.punnatha...@gmail.com> wrote in message
The program is OK with at least one gfortran version. I used module
test
without change and appended a main program using it. Our systems
people
don't update compilers very often; the program compiled and ran OK
with
gfortran 4.1.2 (and three other compilers) as follows:
puka[~]$ cat testptrtype.f90
module test
implicit none
!===================================================
type b
integer :: j
end type b
!===================================================
type a
type(b), dimension(4) :: i
end type a
!===================================================
contains
!===================================================
subroutine test_sub(sorb,ipn)
type(a), intent(in), target :: sorb
integer, dimension(:), pointer :: ipn
ipn=>sorb%i%j
end subroutine test_sub
!===================================================
end module test
program tryit
use test
implicit none
type(a):: n
integer, pointer :: iptr(:)
integer m
forall (m=1:4) n%i(m)%j = 2**m
call test_sub(n,iptr)
print *, iptr
end program tryit
puka[~]$ rm -f a.out; gfortran testptrtype.f90; ./a.out
2 4 8 16
puka[~]$ gfortran -v
Using built-in specs.
Target: i386-redhat-linux5E
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --
infodir=/usr/share/info --enable-shared --enable-threads=posix --
enable-checking=release --with-system-zlib --enable-__cxa_atexit --
disable-libunwind-exceptions --with-gxx-include-dir=/usr/include/c++/
3.4.3 --enable-libgcj-multifile --enable-languages=c,c++,java,f95 --
enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/
java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=i386-redhat-
linux5E
Thread model: posix
gcc version 4.1.2 20071124 (Red Hat 4.1.2-42)
puka[~]
John Harper
sudeep
> Hi,
>
> sudeep wrote:
> > test.f90:15: internal compiler error: Bus error
> > Please submit a full bug report,
>
> > Has this bug been reported before?
>
>
> Otherwise: It is better to either write to
> fortran <at> gcc <dot> gnu <another dot> org
> or to fill a bug in Bugzilla.
>
> Tobias
Dear Mr. Tobias,
Thanks for reporting the bug in bugzilla. I am not familiar with the
procedure of reporting bugs in bugzilla. I came across this problem
while compiling an old program which worked fine with ifort.
Sudeep
Steven Correll
> PS: I checked wikipedia for SIGBUS vs. SIGSEGV. And SIGBUS is thrown for
> "non-existent physical address[es]. This is equivalent to a segmentation
> fault [SIGSEGV], but for a physical address rather than a virtual address."
The Wikipedia entries for segmentation violations and bus errors are a
mess, but that merely reflects the state of computer nomenclature
generally. :-)
A fair answer would be that on Unix-like systems, the distinction
varies with the specific hardware and architecture, but generally
SIGSEGV occurs when a memory access is possible but not legal, and
SIGBUS occurs when the access is impossible. For example, on a brand-
new SiCortex Linux MIPS-based machine, the program below gives SIGSEGV
for a well-aligned address on an illegal page of memory, and gives
SIGBUS for a mis-aligned address on a legal page. An SGI IRIX MIPS-
based machine from a few years back behaves likewise. On an X86
machine, the hardware tolerates the mis-aligned address, but I suppose
it might be possible to provoke SIGBUS using an SSE instruction.
(Apologies for not writing the program in Fortran, but it would have
been horribly non-standard anyway.)
~> cat signals.c
#include <stdio.h>
#include <signal.h>
#include <stdlib.h>
static void handler(int num) {
if (num == SIGBUS) {
printf("bus error\n");
}
else if (num == SIGSEGV) {
printf("segmentation violation\n");
}
exit(1);
}
double *p0;
int
main(int argc, char **argv) {
signal(SIGBUS, handler);
signal(SIGSEGV, handler);
if ('y' == getchar()) {
p0 = (double *) 0x8;
printf("p0=%p\n", p0);
printf("%g\n", *p0);
}
else {
p0 = (double *) (((char *) &p0) + 1);
printf("p0=%p\n", p0);
printf("%g\n", *p0);
}
return 0;
}
~> gcc signals.c
~> echo y | ./a.out
p0=0x8
segmentation violation
~> echo n | ./a.out
p0=0x120011109
bus error
paul.rich...@gmail.com
paul.rich...@gmail.com
Dear John,
> The program is OK with at least one gfortran version. I used module
> test
> without change and appended a main program using it. Our systems
> people
> don't update compilers very often; the program compiled and ran OK
> with
> gfortran 4.1.2 (and three other compilers) as follows:
Put another component in type b and you will see that it does not run
correctly.
Our planned overhaul of the array descriptor used in gfortran will fix
this problem.
Best regards
Paul
>
> John Harper