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: Results for haifa-disabled egcs-970828 g++ testsuite on sparc-sun-solaris2.5

[Joe Buck]

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

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

Alexandre again:
> 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.  

I suggest that any tests that use libg++ headers that are not in libstdc++
either be re-written to use only standard headers, or else they can be
moved to the libg++ test suite.  If anyone is worried about losing a
test, we can do both: move the exact test to libg++/testsuite and leave
the rewritten test in the g++ test suite.

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

I don't think that is a good idea.  Either the tests should be rewritten
or they should be moved to the libg++ test suite; for most of them
a rewrite is easy.

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

[Joern Rennecke]

> Very odd.  Alexandre is not getting any unexpected failures.
> My setup, built from the top with just "make", using the
> 970825 snapshot to build gcc and then that gcc to build cc1plus,
> does get failures for the g++ tests on sparc-sun-solaris2.5.

One thing to double-check when you are getting no failures is that the
tests are actually run.  I've seen sometimes configuration errors that
would result in the tests to be only compiled, so no execute failures
could be detected.

New GCC ports?

[Michael P. Hayes]

In my spare time I have ported GCC (binutils and GDB) to the Texas
Instruments TMS320C3x and TMS320C4x Digital Signal Processors.
Currently my port patches against GCC-2.7.2.2 and is starting to
produce excellent code within the limitations of GCC.  I would like to
have my efforts included into the general GCC release but am unsure
which of the GCC development trees is the most suitable for new ports,
egcs or gcc2?


FYI, the C[34]x architecture has the following salient features:

--the minimum addressable unit is 32-bits so sizeof(char) = sizeof(short) =
  sizeof(int) = sizeof(long) = sizeof(float) = 1.
--three stage instruction pipeline
--delayed branches have three delay slots
--parallel instructions for simultaneous multiply/add, arithmetic/load/store
  operations
--bit reversed and modulo N addressing
--suuport for zero overhead looping
--pre/post increment/decrement addressing modes using an index register for
  the increment/decrement.

The 32-bit bytes required a litle bit of hackery to the GCC modes.
This was more of a problem with the binutils.  Other architectures,
such as the AMD 21xx, require 16-bit bytes so there is room for generalisation.

Having three delay slots exposed many bugs in the 2.7.2.2 version of reorg.c.
Does the new version solve many of the existing problems?

One of the areas of difficulty I found was the handling of the CC.  I
did not want to use cc0 since I wanted insns scheduled between setting
and testing of the CC.  However, the C[34]x sets the CC with many
instructions unlike the other RISC processors that don't use cc0.
Thus many of the C[34]x patterns require clobbers of the CC within a
parallel construct---this has exposed some subtle bugs in the GCC
core.  The setting of the CC is also complicated by the fact that it
is register dependent.  Thus a large number of patterns are required
for each instruction to handle clobbering of the CC.

Another problem area was handling shift instructions.  The C[34]x has
two shift instructions: ASH and LSH.  With a positive shift count they
shift to the left; with a negative shift count they shift to the
right.  This does not map well on to the GCC operators, ashift,
lshiftrt, and ashiftrt.  The best way I found to handle this problem
was to introduce an additional operator lshiftlft.  However, I'm not
fully happy with this approach and wouldn't mind some suggestions how
to handle this.

Extensions to GCC I would like to see would be support for scheduling
parallel instructions (this would require an unroll of loops so that
the operands were available), support for repeating blocks of code (I
had to bolt this on, praying that some of the GCC optimization passes
wouldn't move things around too much---I believe the port for the AMD
SHARC does something similar.  Something like UNSPEC_FIXED would be
useful here to say that the insn is not to be moved around, like
UNSPEC_VOLATILE but without the volatile connotations.), and support
for pre/post inc/decrement addressing with a register increment, rather
than the size of the mode.

Michael.

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

[Alexandre Oliva]

Joern Rennecke writes:

>> Very odd.  Alexandre is not getting any unexpected failures.
>> My setup, built from the top with just "make", using the
>> 970825 snapshot to build gcc and then that gcc to build cc1plus,
>> does get failures for the g++ tests on sparc-sun-solaris2.5.

> One thing to double-check when you are getting no failures is that the
> tests are actually run.  I've seen sometimes configuration errors that
> would result in the tests to be only compiled, so no execute failures
> could be detected.

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

Another possible difference is that I have built gcc with `make
bootstrap' (stage1 was compiled with gcc 2.7.2.2), then built the rest
of the package (including libg++) with make all at the top-level.
Then I installed the whole package with `make install' and tested it
manually, by running runtest (from dejagnu-970707) with a command line
such as:

runtest --tool g++ --srcdir=$egcsroot/gcc/testsuite \
GXX_UNDER_TEST=$egcsinstall/bin/gcc CXXFLAGS="-g -O"

I don't remember having got any of those errors with egcs-970825 (when
I finally set things up to produce a decent report, egcs-970828 was
released :-)

My site.exp file contained just:

set tmpdir /some/directory

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

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

[Joe Buck]

Very odd.  Alexandre is not getting any unexpected failures.
My setup, built from the top with just "make", using the
970825 snapshot to build gcc and then that gcc to build cc1plus,
does get failures for the g++ tests on sparc-sun-solaris2.5.
The only differences I can think of is that I used -O2 -g,
not -O4 -g, and I did not use --enable-shared.

Here are the FAILs and XPASSes:

FAIL: g++.brendan/crash20.C (test for excess errors)
FAIL: g++.brendan/crash30.C (test for excess errors)
FAIL: g++.brendan/crash39.C (test for excess errors)
XPASS: g++.brendan/scope4.C (test for excess errors)
FAIL: g++.law/operators4.C warning (test for errors, line 16)
FAIL: g++.law/operators4.C (test for excess errors)
FAIL: g++.mike/p658.C (test for excess errors)
XPASS: g++.mike/p7325.C *-*-* Execution test
FAIL: g++.mike/p784.C  (test for errors, line 2302)
FAIL: g++.mike/p784.C (test for excess errors)
FAIL: g++.mike/p785.C (test for excess errors)

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

[Alexandre Oliva]

Test Run By oliva on Fri Aug 29 13:28:32 1997
Native configuration is sparc-sun-solaris2.5

		=== g++ tests ===

XPASS: g++.brendan/scope4.C (test for excess errors)
XPASS: g++.mike/p7325.C *-*-* Execution test

		=== g++ Summary ===

# of expected passes		3268
# of unexpected successes	2
# of expected failures		81
# of untested testcases		6
/n/temp1/gcctest/bin/egcsc version egcs-2.90.03 970828 (gcc2-970802 experimental)
configure flags: --with-gnu-as --with-gnu-ld --enable-shared
BOOT_CFLAGS: -O4 -g