libI77 fmt uncleanliness

libI77 fmt uncleanliness

[Richard Henderson]

I77's fmt.h defines struct syl as

     struct syl { int op, p1, p2, p3; }

and then goes off and does things like

     *(char **)&sp->p2 = s + 1;

which is broken for 64-bit hosts.

Am I correct in assuming that the fortran front end
knows about the layout of these structures?  What
would I have to modify to change to

     typedef int syl_int __attribute__((mode(pointer)));
     struct syl { syl_int op, p1, p2, p3; };


r~

Re: Results for haifa-disabled egcs-970828 g++ testsuite on sparc-sun-solaris2.5

[Alexandre Oliva]

Joe Buck writes:

>> The tests that have failed are compile-time ones, and I can assure
>> that my configuration does run tests.

> Please try explicitly hand-running one of the tests I report as failing and
> your report as passing.  

Gotcha!

I looked at the test files, and found out they all #include header
files that are only installed with libg++, which I had installed with
egcs-970822.  

These are the offending lines:

g++.brendan/crash20.C:3:#include 
g++.brendan/crash30.C:3:#include 
g++.brendan/crash39.C:4:#include 
g++.brendan/crash39.C:5:#include 
g++.law/operators4.C:8:#include 
g++.mike/p658.C:4:#include 
g++.mike/p784.C:137:#include 
g++.mike/p785.C:3249:#include 

It seems to be that the last three files could have the offending
#includes removed.  operators4.C could have the Complex class replaced
with anything else, it seems to me.  crash20.C could use the stdc++
complex template too, and crash30.C could use stdc++ string, but
crash39.C, that does not use neither of these classes, seems to imply
that libg++ classes could really affect the behavior of g++ in
unexpected manners.

Is there anyway to tell runtest that `it is ok if this error occurs,
but it is not an expected one'.  It should be counted as an
unsupported test, IMO.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil

Re: libI77 fmt uncleanliness

[Craig Burley]

>Am I correct in assuming that the fortran front end
>knows about the layout of these structures?  What
>would I have to modify to change to
>
>     typedef int syl_int __attribute__((mode(pointer)));
>     struct syl { syl_int op, p1, p2, p3; };

I'm pretty sure g77 doesn't know about this one.  I've
generally tried to use the actual f2c/libf2c names for
things at least once in the pertinent g77 code; "syl"
doesn't occur in either gcc/f/com.c or gcc/f/ste.c, the
two files that actually do the interfacing to the back
end (and, therefore, run-time library).  Between that, and
the fact that I don't recognize it, strongly suggests I
never wrote any g77 code based on that structure.

Maybe dmg@bell-labs.com will provide a real fix; though
he's sometimes away for a week or two at a time, he does fix
libf2c things pretty quickly, which sure has helped us
out on the g77 front!

        tq vm, (burley)

Re: libI77 fmt uncleanliness

[Richard Henderson]

> Maybe dmg@bell-labs.com will provide a real fix; though
> he's sometimes away for a week or two at a time, he does fix
> libf2c things pretty quickly, which sure has helped us
> out on the g77 front!

In the mean time, I can confirm that the following patch resolves
the unaligned accesses I'd been seeing, and runs what Fortran I
have laying about -- mostly spec92.


r~



Index: fmt.h
===================================================================
RCS file: /cvs/cvsfiles/egcs/gcc/f/runtime/libI77/fmt.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 fmt.h
--- fmt.h	1997/08/12 07:47:53	1.1.1.1
+++ fmt.h	1997/09/05 19:47:43
@@ -1,5 +1,6 @@
+typedef int syl_int __attribute__((mode(pointer)));
 struct syl
-{	int op,p1,p2,p3;
+{	syl_int op,p1,p2,p3;
 };
 #define RET1 1
 #define REVERT 2

Re: libI77 fmt uncleanliness

[Dave Love]

>>>>> "Richard" == Richard Henderson  writes:

 Richard> I77's fmt.h defines struct syl as
 Richard>      struct syl { int op, p1, p2, p3; }

 Richard> and then goes off and does things like

 Richard>      *(char **)&sp->p2 = s + 1;

 Richard> which is broken for 64-bit hosts.

We normally pass on basic problems with libf2c exposed by g77 use to
the excellent f2c maintainer so I've done that for comment.  (I don't
think the g77 frontend has any knowledge of such things; burley
probably can't currently read this due to the GNU notwork.)