Segmentation faults related to derived types

I am having some serious trouble debugging a segmentation fault that occurs in my grid generation algorithm. Unfortunately, I can not provide a minimal working example. I guess if I could, I would be half-way to solving the problem myself. So basically I am hoping that somebody can share some thoughts on the problems I am facing.

Using traceback, the intel debugger and some old-fashioned write(*,*) I think I was able to narrow down the origin of the segmentation fault in the following subroutine:

SUBROUTINE create_type_12(l)

    use types
    use parameters
    use vars_and_data

    implicit none

    INTEGER(I4B), INTENT(IN) :: l
    INTEGER(I4B) :: b, nl, neighbor, n_11

    do b=1, nf(l)
        if(levels(l)%blocks(b)%state .EQ. state_interface_undecided) then
            n_11 = 0
            do nl=1, nlinks
                neighbor = levels(l)%blocks(b)%neighbors(nl)
                if(neighbor .GT. 0) then
                    if(levels(l)%blocks(neighbor)%state .EQ. state_fine1) n_11 = n_11 + 1
                end if
            end do
            if(n_11 .GT. 0) levels(l)%blocks(b)%state = state_fine2
        end if
    end do

END SUBROUTINE create_type_12

to be more precise, this line

if(levels(l)%blocks(neighbor)%state .EQ. state_fine1) n_11 = n_11 + 1

The data structure this subroutine operates on has been defined like this:

TYPE :: blockinfo
    INTEGER(I4B)                :: number
    INTEGER(I4B)                :: state
    INTEGER(I4B)                :: state_floodfill
    INTEGER(I4B)                :: state_proximity
    INTEGER(I4B), DIMENSION(26) :: neighbors
    INTEGER(I4B), DIMENSION(26) :: linktype
    INTEGER(I4B)                :: parent
    INTEGER(I4B), DIMENSION(8)  :: children
    INTEGER(I4B), DIMENSION(3)  :: pos
    INTEGER(I4B)                :: triangle_amount
    INTEGER(I4B)                :: triangle_ll
END TYPE blockinfo

TYPE :: block
    TYPE(blockinfo), DIMENSION(:), ALLOCATABLE :: blocks
END TYPE block

TYPE(block), DIMENSION(:), ALLOCATABLE :: levels

Now this is where the trouble starts. Normally I would compile with -check bounds to determine the origin of the segmentation fault. Unfortunetely with -check bounds the code runs normally and produces a valid result data set. Other compiler flags I used are -O3 -xSSE4.2 -ipo -static -assume buffered_io. Ifort compiler versions are 16.0.1 and 13.1.3. Verified the behavior on different machines.

Even worse, If I change some of the compile flags (e.g. omitting -xSSE4.2) the code runs fine. However, using -xSSE4.2 alone without any other optimization the code runs fine aswell. Switching to gfortran with 'similar' compile flags the code runs fine aswell.

Doing some more debugging I found out that the segmentation fault occurs when the variable b has the value 27388461. But to my surprise all values of levels(l)%blocks(27388461)%neighbors are within the size of blocks (which is 102883584 here), except for the negative ones of course. So I have no idea what could cause a segmentation fault here.

Long story short I have three questions, but any other hint is welcome:

1. is there anything obviously wrong with the way I am using the derived types here?
2. what could I do to further narrow down the origin of the segmentation fault?
3. and I really would not ask this if I had not run out of ideas several days ago: are there any known compiler bugs related to derived types?

Edit: forgot to include the error message

forrtl: severe (174): SIGSEGV, segmentation fault occurred
Image              PC                Routine            Line        Source
gabel_v112         000000000054A346  Unknown               Unknown  Unknown
gabel_v112         0000000000544C2C  Unknown               Unknown  Unknown
gabel_v112         00000000005093DB  Unknown               Unknown  Unknown
gabel_v112         000000000040103C  Unknown               Unknown  Unknown
gabel_v112         000000000048E3F0  Unknown               Unknown  Unknown
gabel_v112         0000000000400F17  Unknown               Unknown  Unknown