Seg fault caused by allocate statement with source variable

[lopes8070]

Another compiler catastrophoc error. This time there is an allocate statement with a source definition. There are 3 classes in play. 2 classes (C,H) extend a third (D). There is a pointer (same thing happens with allocate attribute) to an object of class D defined in the main program. I then allocate the pointer with the source defined as one of either C or H (Trying to them make it of that type which is known only at runtime.

Source code attached.

Upon compilation:

echo "Compiling with F90=ifort -O0 -g -fp-stack-check -traceback -gen-interface -warn interface and CC=icc"
Compiling with F90=ifort -O0 -g -fp-stack-check -traceback -gen-interface -warn interface and CC=icc
make compile TARGET=demo \
F77="ifort -O0 -g -fp-stack-check -traceback -gen-interface -warn interface " F90="ifort -O0 -g -fp-stack-check -traceback -gen-interface -warn interface " CXX="icc" \
CC="icc" LINKER="ifort -O0 -g -fp-stack-check -traceback -gen-interface -warn interface " \
FFLAGS="" CFLAGS="-O2 -g"
echo "Compiling" Program.f90
Compiling Program.f90
ifort -O0 -g -fp-stack-check -traceback -gen-interface -warn interface -c Program.f90
: catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.

compilation aborted for Program.f90 (code 3)
make[1]: *** [Program.o] Error 3
make: *** [ifort] Error 2

[lopes8070]

Quoting - lopes8070

Another compiler catastrophoc error. This time there is an allocate statement with a source definition. There are 3 classes in play. 2 classes (C,H) extend a third (D). There is a pointer (same thing happens with allocate attribute) to an object of class D defined in the main program. I then allocate the pointer with the source defined as one of either C or H (Trying to them make it of that type which is known only at runtime.

Source code attached.

Upon compilation:

echo "Compiling with F90=ifort -O0 -g -fp-stack-check -traceback -gen-interface -warn interface and CC=icc"
Compiling with F90=ifort -O0 -g -fp-stack-check -traceback -gen-interface -warn interface and CC=icc
make compile TARGET=demo
F77="ifort -O0 -g -fp-stack-check -traceback -gen-interface -warn interface " F90="ifort -O0 -g -fp-stack-check -traceback -gen-interface -warn interface " CXX="icc"
CC="icc" LINKER="ifort -O0 -g -fp-stack-check -traceback -gen-interface -warn interface "
FFLAGS="" CFLAGS="-O2 -g"
echo "Compiling" Program.f90
Compiling Program.f90
ifort -O0 -g -fp-stack-check -traceback -gen-interface -warn interface -c Program.f90
: catastrophic error: **Internal compiler error: segmentation violation signal raised** Please report this error along with the circumstances in which it occurred in a Software Problem Report. Note: File and line given may not be explicit cause of this error.

compilation aborted for Program.f90 (code 3)
make[1]: *** [Program.o] Error 3
make: *** [ifort] Error 2

I hope I'm not overstepping my bounds reporting all these errors. I think I am using the allocate statement correctly. Correct me if I am not.

[Kevin_D_Intel]

No you're not at all. We appreciate your taking time to report these and provide a test case. Right or wrong, the usage should never cause an internal compiler error.

I'll take a look and post again with more information.

[lopes8070]

Quoting - Kevin Davis (Intel)

No you're not at all. We appreciate your taking time to report these and provide a test case. Right or wrong, the usage should never cause an internal compiler error.

I'll take a look and post again with more information.

I have also tried

allocate(C::classD)

in Program.f90 instead of the other allocate statement, but that is throwing the following error:

Program.f90(13): error #8234: If type specification appears, it shall specify a type with which each object being allocated is type compatible. [CLASSD]

I have looked up 'type compatible' in the standard (F03 Section 2.11) and it appears that C and D should definitely be type compatible since C extends D. At least that's what I think should be happening.

[lopes8070]

Quoting - lopes8070

I have also tried

allocate(C::classD)

in Program.f90 instead of the other allocate statement, but that is throwing the following error:

Program.f90(13): error #8234: If type specification appears, it shall specify a type with which each object being allocated is type compatible. [CLASSD]

I have looked up 'type compatible' in the standard (F03 Section 2.11) and it appears that C and D should definitely be type compatible since C extends D. At least that's what I think should be happening.

Note that defining the classD as a targetable variable (, target), makes this compile but segfaults on the actual allocation. This is similar to another thread, though I don't know how to link it here.

[Kevin_D_Intel]

I cannot get past the error #8234 when using allocatable,target so I don't know what more is be needed to reproduce the third issue involving the run-time fault.

Two of the three issues reported were submitted to Development. I'll keep the thread updated with information that I receive.

(Internal tracking id: DPD200148482 - internal error with SOURCE=)
(Internal tracking id: DPD200148483 - error #8234 types not compatible)

[Kevin_D_Intel]

Quoting - Kevin Davis (Intel)

I cannot get past the error #8234 when using allocatable,target so I don't know what more is be needed to reproduce the third issue involving the run-time fault.

Two of the three issues reported were submitted to Development. I'll keep the thread updated with information that I receive.

(Internal tracking id: DPD200148482 - internal error with SOURCE=)
(Internal tracking id: DPD200148483 - error #8234 types not compatible)

Development confirmed and already fixed the erroneous "error #8234 types not compatible" based on an earlier report. The samefix also addressed the error I receivedwith allocatable,target and the allocation executes successfully too.

We hope to provide this fix in a future 11.1 update. I will update the post when I know more.

(New Internal tracking id: DPD200140688 - error #8234 types not compatible)

[lopes8070]

Quoting - Kevin Davis (Intel)

Development confirmed and already fixed the erroneous "error #8234 types not compatible" based on an earlier report. The samefix also addressed the error I receivedwith allocatable,target and the allocation executes successfully too.

We hope to provide this fix in a future 11.1 update. I will update the post when I know more.

(New Internal tracking id: DPD200140688 - error #8234 types not compatible)

Thank you for responding and keeping me in the loop. Has the new update come out yet? I heard it was supposed to come out this week sometime.

[Steven_L_Intel1]

Not yet, but it should be very soon. You can log in to the Intel Registration Center to check.

[Steven_L_Intel1]

Update 4 is now posted to the Intel Registration Center.

[lopes8070]

Quoting - Steve Lionel (Intel)

Update 4 is now posted to the Intel Registration Center.

I saw that update 5 is estimated for late January, does this adress this issue (or either of the other 2 I posted recently)? Just wanted an update, sorry to bump.

[Kevin_D_Intel]

Quoting - lopes8070

I saw that update 5 is estimated for late January, does this adress this issue (or either of the other 2 I posted recently)? Just wanted an update, sorry to bump.

For the internal ids tracked under this post:

- There is no fix yet available for (Internal tracking id: DPD200148482 - internal error with SOURCE=) so as of right now update 5 will not address this issue. I'll ping Development for status of a fix and see if it can make Update 5.

- The fix for (Internal tracking id: DPD200140688 - error #8234 types not compatible) is approved for 11.1 so this one should be in Update 5, although, its not yet appearing in 11.1 internal builds yet.

I only found one other post (here) thatI testedandfound is *not* currently fixed in 11.1 either. I'll check w/Steve on the status of that issue and we'll update that post accordingly.

Was there another post we missed?

[lopes8070]

Quoting - Kevin Davis (Intel)

For the internal ids tracked under this post:

- There is no fix yet available for (Internal tracking id: DPD200148482 - internal error with SOURCE=) so as of right now update 5 will not address this issue. I'll ping Development for status of a fix and see if it can make Update 5.

- The fix for (Internal tracking id: DPD200140688 - error #8234 types not compatible) is approved for 11.1 so this one should be in Update 5, although, its not yet appearing in 11.1 internal builds yet.

I only found one other post (here) thatI testedandfound is *not* currently fixed in 11.1 either. I'll check w/Steve on the status of that issue and we'll update that post accordingly.

Was there another post we missed?

One was not given a tracking number, but can be found at
http://software.intel.com/en-us/forums/showthread.php?t=70459

The other is internal tracking number 200148269

[Kevin_D_Intel]

Quoting - lopes8070

One was not given a tracking number, but can be found at
http://software.intel.com/en-us/forums/showthread.php?t=70459

The other is internal tracking number 200148269

Ok, thanks.

The first (thread #70459) is the post Steve has and which I just re-tested and found is not currently fixed in 11.1. I don't yet know if there's an associated internal tracking id, but we'll post it to that thread once known.

The second (internal tracking number 200148269) does not yet have a fix available so as of right now Update 5 will not address that issue either. I'll also ping Development for status and whether it can make Update 5 and post to the associated thread (here).

[lopes8070]

Quoting - Kevin Davis (Intel)

Ok, thanks.

The first (thread #70459) is the post Steve has and which I just re-tested and found is not currently fixed in 11.1. I don't yet know if there's an associated internal tracking id, but we'll post it to that thread once known.

The second (internal tracking number 200148269) does not yet have a fix available so as of right now Update 5 will not address that issue either. I'll also ping Development for status and whether it can make Update 5 and post to the associated thread (here).

Thank you.

[Kevin_D_Intel]

An updated status of fixes in 11.1 Update 5:

- There is still no fix available for (Internal tracking id: DPD200148482 - internal error with SOURCE=) so its unlikely this will be fixed in 11.1 update 5.

- I confirmed the fix is in 11.1 update 5 for (Internal tracking id: DPD200140688 - error #8234 types not compatible).

- There is no fix available for (Internal tracking id: DPD200148269 - Incorrect error 6678 for pointer assignment to a type-bound procedure returning a pointer). Steve will keep you updated in the corresponding post (here).

- There is a fix available for (Internal tracking id: DPD200149063 - Internal error for call to type component that is not a type-bound procedure) but it is not currently appearing in internal 11.1 builds so availability in 11.1 update 5 is uncertain. However, this is the issue Steve provided the needed source correction for to resolve that issue (here).

[Steven_L_Intel1]

For DPD200149063, which is caused by a coding error, the fix for that is not currently being considered for 11.1.

[Kevin_D_Intel]

Quoting Kevin Davis (Intel)

An updated status of fixes in 11.1 Update 5:

- There is still no fix available for (Internal tracking id: DPD200148482 - internal error with SOURCE=) so its unlikely this will be fixed in 11.1 update 5.

- I confirmed the fix is in 11.1 update 5 for (Internal tracking id: DPD200140688 - error #8234 types not compatible).

- There is no fix available for (Internal tracking id: DPD200148269 - Incorrect error 6678 for pointer assignment to a type-bound procedure returning a pointer). Steve will keep you updated in the corresponding post (here).

- There is a fix available for (Internal tracking id: DPD200149063 - Internal error for call to type component that is not a type-bound procedure) but it is not currently appearing in internal 11.1 builds so availability in 11.1 update 5 is uncertain. However, this is the issue Steve provided the needed source correction for to resolve that issue (here).

An updated status of fixes in 11.1 Update 5:

This defect (Internal tracking id: DPD200140688 - error #8234 types not compatible) is fixed in the Intel Fortran Compiler Professional Edition 11.1 Update 5 (11.1.069 - Linux).

I will update the thread again when a fix is available for this defect (Internal tracking id: DPD200148482 - internal error with SOURCE=).

Please see the links in my quoted reply above (from my 1/20/10 post) to your other earlier reported issues for updates regarding fixes for those defects.

[lopes8070]

Thank you for keeping track of this. So the fix is for the compiler compilation error where the types were not compatible, but the other error (Source=) is still unresolved. I am eagerly waiting this fix as the work around is very cumbersome.

[Kevin_D_Intel]

You're welcome.

I'm also watching the fix for (Internal tracking id: DPD200148482 - internal error with SOURCE=). It exists and is ready for inclusion into the next 11.1 update 6 (tentatively in the April/May '10 time-frame), but it hasn't yet appeared in our 11.1 internal compilers. I'll keep watching our internal builds to ensureit makes update 6 andwill keep this post updated.

[lopes8070]

Are you going to post when it's available or when it starts to appear in your internal builds? Both would be appreciated :)