[Bug fortran/15718] New: [3.3.4 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[Bug fortran/15718] New: [3.3.4 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[jbuck at gcc dot gnu dot org]

I noticed regression failures on this platform that I hadn't seen before.
See

http://gcc.gnu.org/ml/gcc-testresults/2004-05/msg01284.html

and check the failing g77 tests.  Gcc 3.3.3 had no g77 failures at all.

The new Fortran failures are all ICE's, of the form

90826-2.f:25: internal compiler error: in subreg_hard_regno, at emit-rtl.c:928

-- 
           Summary: [3.3.4 regression][alpha] ICE in subreg_hard_regno, at
                    emit-rtl.c:928
           Product: gcc
           Version: 3.3.4
            Status: UNCONFIRMED
          Severity: critical
          Priority: P1
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jbuck at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
  GCC host triplet: alphaev6-dec-osf5.1
GCC target triplet: alphaev6-dec-osf5.1


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug middle-end/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|fortran                     |middle-end
           Keywords|                            |ice-on-valid-code
      Known to fail|                            |3.3.4
      Known to work|                            |3.3.3
            Summary|[3.3.4 regression][alpha]   |[3.3 regression][alpha] ICE
                   |ICE in subreg_hard_regno, at|in subreg_hard_regno, at
                   |emit-rtl.c:928              |emit-rtl.c:928
   Target Milestone|---                         |3.3.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug middle-end/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-28 23:59 -------
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

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug middle-end/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-29 00:25 -------
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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug rtl-optimization/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|middle-end                  |rtl-optimization


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug target/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-29 01:31 -------
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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rth at gcc dot gnu dot org
             Status|UNCONFIRMED                 |NEW
          Component|rtl-optimization            |target
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2004-05-29 01:31:18
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug target/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2004-05-29 04:02 -------
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.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug target/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-05-29 06:39 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

Re: [Bug target/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[Gabriel Dos Reis]

"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

[Bug target/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[jbuck at gcc dot gnu dot org]

------- Additional Comments From jbuck at gcc dot gnu dot org  2004-05-29 05:55 -------
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.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug target/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[jbuck at gcc dot gnu dot org]

------- Additional Comments From jbuck at gcc dot gnu dot org  2004-06-02 01:03 -------
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?



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug target/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-06-02 02:25 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug target/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.3.4                       |3.3.5


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug target/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-13 14:11 -------
*** Bug 15859 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pluto at pld-linux dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug target/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-13 14:12 -------
*** Bug 15971 has been marked as a duplicate of this bug. ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |debian-gcc at lists dot
                   |                            |debian dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug target/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-06-29 06:28 -------
*** Bug 16255 has been marked as a duplicate of this bug. ***

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug target/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[pinskia at gcc dot gnu dot org]

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

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug target/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[doko at cs dot tu-berlin dot de]

------- Additional Comments From doko at cs dot tu-berlin dot de  2004-06-29 07:54 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug target/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[ft01 at webmastery dot com dot au]

------- Additional Comments From ft01 at webmastery dot com dot au  2004-08-24 06:05 -------
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

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug target/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[rth at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
                   |dot org                     |
             Status|REOPENED                    |ASSIGNED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718

[Bug target/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-08-27 00:01 -------
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/bugzilla/show_bug.cgi?id=15718

[Bug target/15718] [3.3 regression][alpha] ICE in subreg_hard_regno, at emit-rtl.c:928

[rth at gcc dot gnu dot org]

------- Additional Comments From rth at gcc dot gnu dot org  2004-08-27 00:09 -------
http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02198.html

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15718