GCC Bugzilla Bug 26049

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)

Created an attachment (id=10767) [edit]
Test case as an attachment.

This is related to (or really a dup of) PR 14010.

Hmm, (reg:DI 0 0 [194]) is what is causing the issue as far as I can tell.

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

I understand for ppc32 but should we require gcc-4.1 -m64 for glibc (which had
worked in the past)?

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

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

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.

Won't fix for 3.4.6