The only change to the f77 front-end was:
        Backport:
        2004-02-24  Michael Matz  <matz@suse.de>
        * sta.c (ffesta_save_): Don't break aliasing rules.
which I doubt even messed it up

The line above the abort in emit-rtl.c:
  if (check_mode && ! HARD_REGNO_MODE_OK (base_regno, GET_MODE (reg)))

I wonder if it is related to RTH's changes:
        * config/alpha/alpha.h (MASK_LONG_DOUBLE_128): New.
        (TARGET_LONG_DOUBLE_128): New.
        (TARGET_SWITCHES): Add long-double-{128,64}.
        (TARGET_HAS_XFLOATING_LIBS): Default to TARGET_LONG_DOUBLE_128.
        (LONG_DOUBLE_TYPE_SIZE): Honor TARGET_LONG_DOUBLE_128.
        (LIBGCC2_LONG_DOUBLE_TYPE_SIZE): New.
        (WIDEST_HARDWARE_FP_SIZE): New.
        (TARGET_CPU_CPP_BUILTINS): Define __LONG_DOUBLE_128__.
        * config/alpha/alpha.c (override_options): Clear MASK_LONG_DOUBLE_128
        if TARGET_VAX_FLOAT.
        * config/alpha/osf5.h (LONG_DOUBLE_TYPE_SIZE): Remove.
        (TARGET_DEFAULT): Set MASK_LONG_DOUBLE_128.

Confirmed.  The rtx which is ICEing:
(subreg:DF (reg:SC 48 $f16) 0)

Note the failure for FAIL: gcc.c-torture/execute/complex-6.c compilation,  -Os  is the same.
Here is the reduced source for that testcase:
int err;
__complex__ float ctest_float (__complex__ float x)
{
 __complex__ float res;
 res = ~x;
 return res;
 }
void test_float (void)
{
 __complex__ float res, x;
 x = 1.0 + 2.0i;
 res = ctest_float (x);
 if (res != 1.0 - 2.0i)
  ++err;
}

I think is a bug in the alpha backend as it does not check for the complex modes.

Yes, of course this is a backend bug.  Unfortunately, the fix requires
an ABI change.  This has been done in gcc 3.4.  It will not be backported.

Sorry, WONTFIX is not acceptable for a bug that was not present in 3.3.3 and is
present in 3.3.4.  This is an ICE-on-valid-code regression that affects two
rather simple cases already in our testsuite.  The apparent effect would be that
Alpha users would have to avoid the use of complex numbers in Fortran programs.
 To be fair, I can't assess what proportion of programs would be affected.

WONTFIX is basically saying "Alpha Fortran users should consider 3.3.4 unusable".

I appreciate that the fix that you were considering would require an ABI change
and therefore can't be backported.  But this bug was not present before, so it
should be possible to fix it in another way.  Even if this means re-breaking
other bug fixes.

Subject: Re:  [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

"jbuck at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| Sorry, WONTFIX is not acceptable for a bug that was not present in 3.3.3 and is
| present in 3.3.4.  This is an ICE-on-valid-code regression that affects two
| rather simple cases already in our testsuite.  The apparent effect would be that
| Alpha users would have to avoid the use of complex numbers in Fortran programs.

I think that is too far an excessive statement.  As I pointed out in
another message, this coerner case is pretty much a known issue.
We've been around this in V3 by special casing.  What is happening, I
remember correctly, is that passing/returning complex numbers in
register is pretty much broken on alpha and can be fixed only by
changing the ABI. They cn still be used -- one just has to pas them 
by reference.  (The way we got around that in C++, was to make the
resulting complex<> class a non-trivial POD so that the compiler was
forced to  put them always in stack)

    http://gcc.gnu.org/ml/gcc-bugs/2000-03/msg01215.html
    http://sources.redhat.com/ml/libc-alpha/2004-01/msg00121.html

The problem has been there for long time awaiting (some) complex
programs to hit it.

|  To be fair, I can't assess what proportion of programs would be affected.
| 
| WONTFIX is basically saying "Alpha Fortran users should consider 3.3.4 unusable".
| 
| I appreciate that the fix that you were considering would require an ABI change
| and therefore can't be backported.  But this bug was not present before, so it

From my understanding, the bug was there, just hidden, awaiting to be hit.

-- Gaby

OK, I'll reluctantly accept leaving this as WONTFIX if people can help me
produce a release note saying how to avoid the bug.  

"Avoid passing __complex__ in a register" doesn't cut it, because the user
doesn't write "__complex__" or "register".

Consider g77.f-torture/execute/19990826-2.f .  In this case we have a simple
Fortran program that defines an inline function with a complex argument.
Evidently we have to tell Fortran users that they must never do this?

In short: what are the contexts in which a __complex__ is passed in a register
on the Alpha?  Are all such contexts broken?

Subject: Re:  [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

"jbuck at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

| OK, I'll reluctantly accept leaving this as WONTFIX if people can help me
| produce a release note saying how to avoid the bug.  
| 
| "Avoid passing __complex__ in a register" doesn't cut it, because the user
| doesn't write "__complex__" or "register".

That is fully understood, but that comment was made as an explanation
of what was going on to you (Joe), much more knowledgeable than "the user"
(even if you happen to be user too, but then you're not a common user
:-))

| Consider g77.f-torture/execute/19990826-2.f .  In this case we have a simple
| Fortran program that defines an inline function with a complex argument.
| Evidently we have to tell Fortran users that they must never do this?
| 
| In short: what are the contexts in which a __complex__ is passed in a register
| on the Alpha?  Are all such contexts broken?

My understanding is that the contexts are those where you have an
equivalent of bytewise copy.  RTH may have better words to
explain that. 

-- Gaby

*** Bug 15859 has been marked as a duplicate of this bug. ***

*** Bug 15971 has been marked as a duplicate of this bug. ***

*** Bug 16255 has been marked as a duplicate of this bug. ***

I should note that this causes Ada to fail to bootstrap also.

Subject: Re:  [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

pinskia at gcc dot gnu dot org writes:
> 
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-29 06:30 -------
> I should note that this causes Ada to fail to bootstrap also.

hmm, a bootstrap succeeds, when setting GNATLIBCFLAGS to -g -O

Just for the record -- this bug also affects C code in glibc-2.3.3-20040728, so it is not just ada or 
fortran. Workaround was to reduce optimisation to -O1. I'll attach the source file, just in case.

$ alpha-unknown-linux-gnu-gcc -O2 a.c
In file included from ../include/bits/cmathcalls.h:1,
                 from ../math/complex.h:97,
                 from ../include/complex.h:1,
                 from ../sysdeps/alpha/fpu/s_cexpf.c:23:
../math/bits/cmathcalls.h:117: warning: conflicting types for built-in function `conjl'
../math/bits/cmathcalls.h:126: warning: conflicting types for built-in function `cimagl'
../math/bits/cmathcalls.h:129: warning: conflicting types for built-in function `creall'
../sysdeps/alpha/fpu/s_cexpf.c: In function `__c1_cexpf':
../sysdeps/alpha/fpu/s_cexpf.c:42: internal compiler error: in subreg_hard_regno, at emit-rtl.c:928
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.
$ alpha-unknown-linux-gnu-gcc -v
Reading specs from /Volumes/Linux/lfh/xcompiler/alpha-unknown-linux-gnu/lib/gcc-lib/alpha-
unknown-linux-gnu/3.3.4/specs
Configured with: ../gcc-core-3.3.4/configure --prefix=/Volumes/Linux/lfh/xcompiler/alpha-
unknown-linux-gnu --target=alpha-unknown-linux-gnu --with-sysroot=/Volumes/Linux/lfh/
xcompiler/alpha-unknown-linux-gnu/sysroot --disable-multilib --with-newlib --disable-nls --
enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c --
disable-shared
Thread model: posix
gcc version 3.3.4

Created attachment 6983 [details]
pre-processed sysdeps/alpha/fpu/s_cexpf.c from glibc-2.3.3-20040728

Subject: Bug 15718

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_3-branch
Changes by:	rth@gcc.gnu.org	2004-08-27 00:01:20

Modified files:
	gcc            : ChangeLog 
	gcc/config/alpha: alpha.h 

Log message:
	PR target/15718
	* config/alpha/alpha.h (HARD_REGNO_MODE_OK): Allow complex float
	modes.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.16114.2.1013&r2=1.16114.2.1014
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/alpha/alpha.h.diff?cvsroot=gcc&only_with_tag=gcc-3_3-branch&r1=1.185.4.5&r2=1.185.4.6

http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02198.html