[Bug middle-end/26049] New: ICE compiling glibc part using -O1 -m64 -mlong-double-128

[Bug middle-end/26049] New: ICE compiling glibc part using -O1 -m64 -mlong-double-128

[bergner at vnet dot ibm dot com]

I get an ICE compiling the following test case using a 3.4 compiler (checked
out and built today [2006/01/31]).

bergner@vervain:~> cat _IO_vfprintf_internal.i

union printf_arg {
  long double pa_long_double;
  const char *pa_string;
  const int *pa_wstring;
  void *pa_pointer;
};

struct _IO_FILE {
  int _flags2;
};

void
_IO_vfprintf_internal(struct _IO_FILE *s, const char *format, __builtin_va_list
ap)
{
  const char *f;
  __builtin_va_list ap_save;
  long unsigned int nargs = 0;
  int *args_type;
  union printf_arg *args_value;
  long unsigned int cnt;

  __builtin_va_copy(ap_save, ap);

  for (f = format; *f; f++) {
    nargs += 1;
  }

  args_value = __builtin_alloca(nargs * sizeof (union printf_arg));

  for (cnt = 0; cnt < nargs; ++cnt)
    switch (args_type[cnt]) {
    case 0:
            args_value[cnt].pa_string =
                __builtin_va_arg(ap_save, const char *);
            break;
    case 1:
            args_value[cnt].pa_wstring =
                __builtin_va_arg(ap_save, const int *);
            break;
    case 2:
            args_value[cnt].pa_pointer =
                __builtin_va_arg(ap_save, void *);
            break;
    default:
            if ((args_type[cnt] & (1 << 11)) != 0)
                    args_value[cnt].pa_pointer =
                        __builtin_va_arg(ap_save, void *);
            else
                    args_value[cnt].pa_long_double = 0.0;
            break;
    case -1:
            ((void) ((s->_flags2 & 4) ? 0
              : (__assert_fail ("s", "v", 1743, __PRETTY_FUNCTION__), 0)));
            __libc_fatal ("*** invalid %N$ use detected ***\n");
    }
}

bergner@vervain:~> ./gcc/gcc-20060131-3_4-biarch/bin/gcc -O1 -c -m64
-mlong-double-128 _IO_vfprintf_internal.i
_IO_vfprintf_internal.i: In function `_IO_vfprintf_internal':
_IO_vfprintf_internal.i:57: error: insn does not satisfy its constraints:
(insn 280 157 159 15 _IO_vfprintf_internal.i:50 (set (mem/s/j:TF (plus:DI
(reg:DI 0 0 [194])
                (reg/v/f:DI 29 29 [orig:126 args_value ] [126])) [0
<variable>.pa_long_double+0 S16 A128])
        (reg:TF 32 0)) 312 {*movtf_internal} (nil)
    (nil))
_IO_vfprintf_internal.i:57: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:391
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.

bergner@vervain:~> ./gcc/gcc-20060131-3_4-biarch/bin/gcc -v
Reading specs from
/home/bergner/gcc/gcc-20060131-3_4-biarch/lib/gcc/powerpc-linux/3.4.6/specs
Configured with: /home/bergner/gcc/gcc-20060131-3_4/configure
--target=powerpc-linux --host=powerpc-linux --build=powerpc-linux
--enable-targets=powerpc64-linux --enable-threads=posix --enable-shared
--enable-__cxa_atexit --enable-languages=c,c++ --disable-checking
--prefix=/home/bergner/gcc/gcc-20060131-3_4-biarch
Thread model: posix
gcc version 3.4.6 20060131 (prerelease)


-- 
           Summary: ICE compiling glibc part using -O1 -m64 -mlong-double-
                    128
           Product: gcc
           Version: 3.4.6
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bergner at vnet dot ibm dot com
 GCC build triplet: powerpc-linux
  GCC host triplet: powerpc-linux
GCC target triplet: powerpc-linux --enable-targets=powerpc64-linux


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

[Bug middle-end/26049] ICE compiling glibc part using -O1 -m64 -mlong-double-128

[bergner at vnet dot ibm dot com]

------- Comment #1 from bergner at vnet dot ibm dot com  2006-01-31 20:47 -------
Created an attachment (id=10767)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10767&action=view)
Test case as an attachment.


-- 


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

[Bug middle-end/26049] ICE compiling glibc part using -O1 -m64 -mlong-double-128

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-01-31 20:53 -------
This is related to (or really a dup of) PR 14010.


-- 


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

[Bug middle-end/26049] ICE compiling glibc part using -O1 -m64 -mlong-double-128

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-01-31 21:07 -------
Hmm, (reg:DI 0 0 [194]) is what is causing the issue as far as I can tell.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.0.0


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

[Bug middle-end/26049] ICE compiling glibc part using -O1 -m64 -mlong-double-128

[dje at gcc dot gnu dot org]

------- Comment #4 from dje at gcc dot gnu dot org  2006-01-31 21:30 -------
This was fixed by adding the 'Y' constraint to movtf_internal.  One would need
to add the constraint and modify the word_offset_memref_operand() function in
rs6000.c on the GCC-3.4 branch.  I am hesitant to start along that path this
late in the GCC 3.4 release cycle because changing the predicate could be much
more destabilizing.  We can backport that to a distro if needed.

GCC 3.4 is not intended to build GLIBC with -mlong-double-128.  GLIBC now
depends on GCC 4.1 if that option is used.

This sounds like a classic "doctor it hurts when I do this."  "Then don't do
that."


-- 

dje at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dje at gcc dot gnu dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-01-31 21:30:53
               date|                            |
   Target Milestone|4.0.0                       |---


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

[Bug middle-end/26049] ICE compiling glibc part using -O1 -m64 -mlong-double-128

[munroesj at us dot ibm dot com]

------- Comment #5 from munroesj at us dot ibm dot com  2006-01-31 21:57 -------
I understand for ppc32 but should we require gcc-4.1 -m64 for glibc (which had
worked in the past)?


-- 

munroesj at us dot ibm dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |munroesj at us dot ibm dot
                   |                            |com


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

[Bug middle-end/26049] [3.4 only] ICE compiling glibc part using -O1 -m64 -mlong-double-128

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2006-01-31 22:01 -------
This is not really a regression, and I should note that GCC's policy if this is
not a regression, it does not get fixed on the release branches.   I should
note that even the requiring of 4.1 for ppc32 is pushing GCC to the point where
it is going to break (in that it goes against all the current policies of GCC).


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-valid-code
      Known to fail|                            |3.4.5 3.4.6
      Known to work|                            |4.0.0 4.1.0 4.0.2
            Summary|ICE compiling glibc part    |[3.4 only] ICE compiling
                   |using -O1 -m64 -mlong-      |glibc part using -O1 -m64 -
                   |double-128                  |mlong-double-128
   Target Milestone|---                         |3.4.6


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

[Bug middle-end/26049] [3.4 only] ICE compiling glibc part using -O1 -m64 -mlong-double-128

[dje at gcc dot gnu dot org]

------- Comment #7 from dje at gcc dot gnu dot org  2006-01-31 23:26 -------
> I understand for ppc32 but should we require gcc-4.1 -m64 for glibc (which had
> worked in the past)?

We are not requiring gcc-4.1 for -m64, gcc-4.0 -m64 -mlong-double-128 includes
the fix.  If gcc-4.0 did not work, that would be the place to fix it.

IBM extended format long double was a new feature in gcc-3.4 and would be fixed
if gcc-3.4 were the current release, but it is not.  At this point in the
release cycle, only fixes to regressions relative to previous releases are
applied.


-- 


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

[Bug middle-end/26049] [3.4 only] ICE compiling glibc part using -O1 -m64 -mlong-double-128

[amodra at bigpond dot net dot au]

------- Comment #8 from amodra at bigpond dot net dot au  2006-02-14 06:11 -------
I think David indentified the wrong patch in comment #4.  My guess is that rev
83504, rs6000_eliminate_indexed_memrefs, (and followup rev 92567) is the real
fix for this problem.


-- 

amodra at bigpond dot net dot au changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amodra at bigpond dot net
                   |                            |dot au


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

[Bug middle-end/26049] [3.4 only] ICE compiling glibc part using -O1 -m64 -mlong-double-128

[gdr at gcc dot gnu dot org]

------- Comment #9 from gdr at gcc dot gnu dot org  2006-03-01 05:12 -------
Won't fix for 3.4.6


-- 

gdr at gcc dot gnu dot org changed:

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


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