Fortran: Intel vs G77

Fortran: Intel vs G77

[David Lecomber]

[-- Attachment #1: Type: text/plain, Size: 838 bytes --]

The current situation with g77 and Intel meets gdb is as follows for
multi-dim arrays

Intel compiled code:
  whatis -- wrong way round real(4 * 5 ) is reported as real (5 * 4)
  indexing -- correct 
  print elements -- boundaries not aligned properly ( it prints a 5 * 4 
as a 4 * 5 )


g77 fortran compilers compiled code:
  whatis -- correct
  print elements -- correct
  indexing -- 'print A(1,2)' will get the wrong answer.

So, unless there is a method to check what the compiler was used, we are
left with

  1. status quo
or
  2. compile up two different versions -- one for gdb + intel, the
other for gdb + g77

Does anyone know of the existence of such a check?

Patches to fix the three issues are attached, but of course they
cannot all be applied at once; the fix to make g77 work will bust
intel, and vice-versa..

David




[-- Attachment #2: gdb.g77-array-printing-patch --]
[-- Type: text/plain, Size: 621 bytes --]

*** eval.c	Fri Jan  4 17:51:38 2002
--- eval.c	Wed Oct 16 14:08:04 2002
*************** evaluate_subexp_standard (struct type *e
*** 1358,1364 ****
  	    if (retcode == BOUND_FETCH_ERROR)
  	      error ("Cannot obtain dynamic lower bound");
  
! 	    array_size_array[i] = upper - lower + 1;
  
  	    /* Zero-normalize subscripts so that offsetting will work. */
  
--- 1358,1364 ----
  	    if (retcode == BOUND_FETCH_ERROR)
  	      error ("Cannot obtain dynamic lower bound");
  
! 	    array_size_array[nargs - i + 1] = upper - lower + 1;
  
  	    /* Zero-normalize subscripts so that offsetting will work. */
  

[-- Attachment #3: gdb.intel-print-elements-patch --]
[-- Type: text/plain, Size: 1665 bytes --]

*** f-valprint.c	Mon Oct 21 17:47:36 2002
--- /tmp/gdb-5.2/gdb/f-valprint.c	Mon Oct 21 16:14:33 2002
*************** f77_create_arrayprint_offset_tbl (struct
*** 234,239 ****
--- 234,241 ----
    int eltlen;
    int ndimen = 1;
    int upper, lower, retcode;
+   int i, j;
+   int t;
  
    tmp_type = type;
  
*************** f77_create_arrayprint_offset_tbl (struct
*** 256,270 ****
        ndimen++;
      }
  
    /* Now we multiply eltlen by all the offsets, so that later we 
       can print out array elements correctly.  Up till now we 
       know an offset to apply to get the item but we also 
       have to know how much to add to get to the next item */
  
    ndimen--;
    eltlen = TYPE_LENGTH (tmp_type);
    F77_DIM_OFFSET (ndimen) = eltlen;
!   while (--ndimen > 0)
      {
        eltlen *= F77_DIM_SIZE (ndimen + 1);
        F77_DIM_OFFSET (ndimen) = eltlen;
--- 258,285 ----
        ndimen++;
      }
  
+ 
    /* Now we multiply eltlen by all the offsets, so that later we 
       can print out array elements correctly.  Up till now we 
       know an offset to apply to get the item but we also 
       have to know how much to add to get to the next item */
  
    ndimen--;
+ 
+   /**
+      intel compiler, reckon this to be wrong way round.. so here's a quick in-place swap.
+    */
+ 
+   for (i = 1, j = ndimen; i < j; i++,j--) {
+     t = F77_DIM_SIZE(i);
+     F77_DIM_SIZE(i) = F77_DIM_SIZE(j);
+     F77_DIM_SIZE(j) = t;
+   }
+ 
    eltlen = TYPE_LENGTH (tmp_type);
    F77_DIM_OFFSET (ndimen) = eltlen;
! 
!   while (--ndimen > 0) 
      {
        eltlen *= F77_DIM_SIZE (ndimen + 1);
        F77_DIM_OFFSET (ndimen) = eltlen;

[-- Attachment #4: gdb.intel-print-whatis-patch --]
[-- Type: text/plain, Size: 1526 bytes --]

*** f-typeprint.c	Sun Jan 20 19:42:04 2002
--- f-typeprint.c	Mon Oct 21 16:18:12 2002
*************** f_type_print_varspec_suffix (struct type
*** 175,183 ****
  
        if (arrayprint_recurse_level == 1)
  	fprintf_filtered (stream, "(");
  
-       if (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_ARRAY)
- 	f_type_print_varspec_suffix (TYPE_TARGET_TYPE (type), stream, 0, 0, 0);
  
        retcode = f77_get_dynamic_lowerbound (type, &lower_bound);
  
--- 175,183 ----
  
        if (arrayprint_recurse_level == 1)
  	fprintf_filtered (stream, "(");
+       else
+ 	fprintf_filtered (stream, ",");
  
  
        retcode = f77_get_dynamic_lowerbound (type, &lower_bound);
  
*************** f_type_print_varspec_suffix (struct type
*** 212,221 ****
  
        if (TYPE_CODE (TYPE_TARGET_TYPE (type)) != TYPE_CODE_ARRAY)
  	f_type_print_varspec_suffix (TYPE_TARGET_TYPE (type), stream, 0, 0, 0);
        if (arrayprint_recurse_level == 1)
  	fprintf_filtered (stream, ")");
-       else
- 	fprintf_filtered (stream, ",");
        arrayprint_recurse_level--;
        break;
  
--- 212,223 ----
  
        if (TYPE_CODE (TYPE_TARGET_TYPE (type)) != TYPE_CODE_ARRAY)
  	f_type_print_varspec_suffix (TYPE_TARGET_TYPE (type), stream, 0, 0, 0);
+ 
+       if (TYPE_CODE (TYPE_TARGET_TYPE (type)) == TYPE_CODE_ARRAY)
+ 	f_type_print_varspec_suffix (TYPE_TARGET_TYPE (type), stream, 0, 0, 0);
+ 
        if (arrayprint_recurse_level == 1)
  	fprintf_filtered (stream, ")");
        arrayprint_recurse_level--;
        break;
  

Re: Fortran: Intel vs G77

[Daniel Jacobowitz]

On Wed, Jan 15, 2003 at 09:51:04PM +0000, David Lecomber wrote:
> The current situation with g77 and Intel meets gdb is as follows for
> multi-dim arrays
> 
> Intel compiled code:
>   whatis -- wrong way round real(4 * 5 ) is reported as real (5 * 4)
>   indexing -- correct 
>   print elements -- boundaries not aligned properly ( it prints a 5 * 4 
> as a 4 * 5 )
> 
> 
> g77 fortran compilers compiled code:
>   whatis -- correct
>   print elements -- correct
>   indexing -- 'print A(1,2)' will get the wrong answer.
> 
> So, unless there is a method to check what the compiler was used, we are
> left with
> 
>   1. status quo
> or
>   2. compile up two different versions -- one for gdb + intel, the
> other for gdb + g77
> 
> Does anyone know of the existence of such a check?

Sure, via gcc_compiled, but that's not the right way to approach this
problem.

First of all, what version of G77 did you test with?  And what format
of debug information?

Secondly, which compiler's debug information is correct?  Or are they
just different and triggering different bugs?

Third, it really sounds like we're going to need copyright assignment
papers from you.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Fortran: Intel vs G77

[David Lecomber]

On Wed, Jan 15, 2003 at 05:08:43PM -0500, Daniel Jacobowitz wrote:
>On Wed, Jan 15, 2003 at 09:51:04PM +0000, David Lecomber wrote:
[..]>
>Sure, via gcc_compiled, but that's not the right way to approach this
>problem.
>
>First of all, what version of G77 did you test with?  And what format
>of debug information?

g77 2.96 (on redhat-7.3) -- symptom also appears in the g77 of
redhat-6.2 but I don't have the version to hand --  and Intel Fortran
Compiler v6.0.

The debug info was the default from the -g option.  I've now also just
run g77 with -gdwarf and the same problem arises..

>Secondly, which compiler's debug information is correct?  Or are they
>just different and triggering different bugs?

Beats me ;-) -- a good googling uncovers g77 probably has its problems
-- but as gdb doesn't get it right all the time for either compiler,
whichever format is correct we need to do something in gdb to be
consistent.  
 
I think using the gcc_compiled flag is the way to go to merge the
patches into one gdb build.  I know it seems like a hack, but it seems
a whole lot easier than getting folks to change either the Intel or
GNU compiler.  It looks like the issue has been known about for a long
time so perhaps the compiler people just can't agree?

>Third, it really sounds like we're going to need copyright assignment
>papers from you.

No probs -- will contact the appropriate folks at FSF (unless you have
one to hand)

Cheers
David

Re: Fortran: Intel vs G77

[Daniel Jacobowitz]

On Wed, Jan 15, 2003 at 11:22:23PM +0000, David Lecomber wrote:
> On Wed, Jan 15, 2003 at 05:08:43PM -0500, Daniel Jacobowitz wrote:
> >On Wed, Jan 15, 2003 at 09:51:04PM +0000, David Lecomber wrote:
> [..]>
> >Sure, via gcc_compiled, but that's not the right way to approach this
> >problem.
> >
> >First of all, what version of G77 did you test with?  And what format
> >of debug information?
> 
> g77 2.96 (on redhat-7.3) -- symptom also appears in the g77 of
> redhat-6.2 but I don't have the version to hand --  and Intel Fortran
> Compiler v6.0.
> 
> The debug info was the default from the -g option.  I've now also just
> run g77 with -gdwarf and the same problem arises..

Could you try a recent (i.e. 3.2 or 3.2.1) version of g77?  Those are
pretty old.

> >Secondly, which compiler's debug information is correct?  Or are they
> >just different and triggering different bugs?
> 
> Beats me ;-) -- a good googling uncovers g77 probably has its problems
> -- but as gdb doesn't get it right all the time for either compiler,
> whichever format is correct we need to do something in gdb to be
> consistent.  
>  
> I think using the gcc_compiled flag is the way to go to merge the
> patches into one gdb build.  I know it seems like a hack, but it seems
> a whole lot easier than getting folks to change either the Intel or
> GNU compiler.  It looks like the issue has been known about for a long
> time so perhaps the compiler people just can't agree?

No, testing this sort of thing on gcc_compiled is too much of a hack
until we have looked directly at the debug info and figured out what it
should say.

> >Third, it really sounds like we're going to need copyright assignment
> >papers from you.
> 
> No probs -- will contact the appropriate folks at FSF (unless you have
> one to hand)

Ask assign@gnu.org for the paperwork, they'd be glad to give it to you.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Fortran: Intel vs G77

[David Lecomber]

On Wed, Jan 15, 2003 at 11:40:58PM -0500, Daniel Jacobowitz wrote:
>On Wed, Jan 15, 2003 at 11:22:23PM +0000, David Lecomber wrote:
>> 
>> g77 2.96 (on redhat-7.3) -- symptom also appears in the g77 of
>> redhat-6.2 but I don't have the version to hand --  and Intel Fortran
>> Compiler v6.0.
>> 
>> The debug info was the default from the -g option.  I've now also just
>> run g77 with -gdwarf and the same problem arises..
>
>Could you try a recent (i.e. 3.2 or 3.2.1) version of g77?  Those are
>pretty old.

Using 3.2.1 we get the same result..

Cheers
David