This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, fortran] PR27996 and PR29978 - warnings and errors on character lengths


Hi Paul,

Paul Thomas wrote:
>> elemental function specific__char_1_i16 (parm)
>>    integer (kind=16) , intent (in) :: parm
>>    character (kind=1,len=1) :: specific__char_1_i16
>>    specific__char_1_i16 = char (parm, kind=1)
>> end function
>>
>> gfortran -c -Wall test.f90   # no error without -Wall
>> test.F90:0: internal compiler error: Segmentation fault
>>   
> I missed this one in resubmittiing the patch a few minutes ago -
> ignore the resubmission, I'll fix this.
> I wonder why you seem to be more sensitive to segfaults than me?  Is
> working on Cygwin protecting me sometimes?

Any news about this patch (30 November 2006)?
Latest patch was http://gcc.gnu.org/ml/gcc-patches/2006-11/msg02067.html

Valgrind outputs with your patch and my test case (-Wall):

==30070== Invalid read of size 8
==30070==    at 0x44F86B: resolve_code (resolve.c:4975)
[...]
foo.f90:0: internal compiler error: Segmentation fault

Test case was:

elemental function specific__char_1_i16 (parm)
   integer (kind=16) , intent (in) :: parm
   character (kind=1,len=1) :: specific__char_1_i16
   specific__char_1_i16 = char (parm, kind=1)
end function


The fix is to change

*************** resolve_code (gfc_code * code, gfc_names
 + 	      else if (code->expr2->ts.cl->length
 + 		    && code->expr2->ts.cl->length->expr_type == EXPR_CONSTANT)

into

 + 	      else if (code->expr2->ts.cl
 +		    && code->expr2->ts.cl->length
 + 		    && code->expr2->ts.cl->length->expr_type == EXPR_CONSTANT)



* * *

With regards to segmentation faults in general:
I often use the following of glibc's malloc options

# fill new malloc areas with 0x42
export MALLOC_PERTURB_=B

# Abort on any malloc related error.
export MALLOC_CHECK_=2

which are quite effective to find memory problems without affecting the
run-time speed too much. valgrind is, however, better suited to find the
exact spot of the problem.

Tobias


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]