Seg fault caused by allocate statement with source variable

Seg fault caused by allocate statement with source variable

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

23 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

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)

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.



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.

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.

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.

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)

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.

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

Steve

Update 4 is now posted to the Intel Registration Center.

Steve

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.

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?

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

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).

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.

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).

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

Steve

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.

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.

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.

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

I planned on posting about both. I want to ensure the fix is in the 11.1 branch in advance of code cutoff for update 6. That will give both of us peace of mind.

My apologies. I lost track of my commitment to reply earlier. I did justconfirm the fix for (Internal tracking id: DPD200148482 - internal error with SOURCE=) is in 11.1 Update 6.

Login to leave a comment.