ia64 linux doesn't bootstrap

ia64 linux doesn't bootstrap

[Aldy Hernandez]

While building stage2.

In file included from /home/aldyh/source/gcc/gcc/c-decl.c:6888:
gt-c-decl.h:338: internal compiler error: Bus error
Please submit a full bug report,

Just curious if anyone had seen this, or had a fix for it.  I guess I
should pull out gdb now...

Aldy

Re: ia64 linux doesn't bootstrap

[Tim Prince]

On Thursday 17 October 2002 22:19, Aldy Hernandez wrote:
> While building stage2.
>
> In file included from /home/aldyh/source/gcc/gcc/c-decl.c:6888:
> gt-c-decl.h:338: internal compiler error: Bus error
> Please submit a full bug report,
>
> Just curious if anyone had seen this, or had a fix for it.  I guess I
> should pull out gdb now...
>
> Aldy
Maybe OT, but what version of gdb would you use, and which version of gcc 
would you build it with?
-- 
Tim Prince

Re: ia64 linux doesn't bootstrap

[Andreas Schwab]

Aldy Hernandez <aldyh@redhat.com> writes:

|> While building stage2.
|> 
|> In file included from /home/aldyh/source/gcc/gcc/c-decl.c:6888:
|> gt-c-decl.h:338: internal compiler error: Bus error
|> Please submit a full bug report,
|> 
|> Just curious if anyone had seen this, or had a fix for it.  I guess I
|> should pull out gdb now...

Bootstrap/regtesting just finished here.

http://gcc.gnu.org/ml/gcc-testresults/2002-10/msg00594.html

But there are a large number of new failures.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ia64 linux doesn't bootstrap

[Jim Wilson]

>Maybe OT, but what version of gdb would you use, and which version of gcc 
>would you build it with?

/usr/bin/gdb and /usr/bin/gcc.  Maybe I didn't understand the question?

Jim

Re: ia64 linux doesn't bootstrap

[Janis Johnson]

On Fri, Oct 18, 2002 at 03:23:39PM +0200, Andreas Schwab wrote:
> Aldy Hernandez <aldyh@redhat.com> writes:
> 
> |> While building stage2.
> |> 
> |> In file included from /home/aldyh/source/gcc/gcc/c-decl.c:6888:
> |> gt-c-decl.h:338: internal compiler error: Bus error
> |> Please submit a full bug report,
> |> 
> |> Just curious if anyone had seen this, or had a fix for it.  I guess I
> |> should pull out gdb now...
> 
> Bootstrap/regtesting just finished here.
> 
> http://gcc.gnu.org/ml/gcc-testresults/2002-10/msg00594.html
> 
> But there are a large number of new failures.

Most of your failures are for the new g++.dg/compat tests, which pass
for me on ia64-unknown-linux-gnu, Red Hat Linux release 7.2 (Enigma).
Can you tell why these tests are failing to execute on your system?
They are also failing to execute on powerpc-unknown-linux-gnu and
i686-unknown-openbsd3.1, but pass on several other systems.

Janis

Re: ia64 linux doesn't bootstrap

[David Edelsohn]

	On AIX I do not get massive failures in the new compat directory,
but I do get:

/gcc/dje/src/gcc/testsuite/g++.dg/compat/break/bitfield7_y.C: In function `void bitfield7_y(U*)':
/gcc/dje/src/gcc/testsuite/g++.dg/compat/break/bitfield7_y.C:7: internal compiler error: in simplify_gen_subreg, at simplify-rtx.c:2681

causing one new failure.

David

Re: ia64 linux doesn't bootstrap

[Aldy Hernandez]

On Fri, Oct 18, 2002 at 03:23:39PM +0200, Andreas Schwab wrote:
> Aldy Hernandez <aldyh@redhat.com> writes:
> 
> |> While building stage2.
> |> 
> |> In file included from /home/aldyh/source/gcc/gcc/c-decl.c:6888:
> |> gt-c-decl.h:338: internal compiler error: Bus error
> |> Please submit a full bug report,
> |> 
> |> Just curious if anyone had seen this, or had a fix for it.  I guess I
> |> should pull out gdb now...
> 
> Bootstrap/regtesting just finished here.
> 
> http://gcc.gnu.org/ml/gcc-testresults/2002-10/msg00594.html
> 
> But there are a large number of new failures.

Hardware was bad.  My bad.

Aldy

Re: ia64 linux doesn't bootstrap

[David Edelsohn]

	Tighten your seatbelt, the AIX failure is another case where the C
and C++ front-ends are not consistent with respect to the state of a DECL
after warnings.  I am not sure which one is right.

	The testcase in g++.dg/break/bitfield7_y.C creates a bitfield that
is too wide:

union U {
  int i: 4096;
};

and accesses it:

void bitfield7_y (U* u)
{
  if (u[0].i != 7)
    abort ();
  if (u[1].i != 8)
    abort ();

This is based on g++.dg/abi/bitfield7.C which declares the union and looks
for both the ABI warning and the "width exceeds type" warning without
accessing a variable of that type.

	The C++ testcase ICEs while the equivalent C testcase does not.

	c-decl.c:finish_struct() ignores out of range field widths -- not
only warning but leaving a number of DECL fields undefined:

          if (tree_int_cst_sgn (DECL_INITIAL (x)) < 0)
            error_with_decl (x, "negative width in bit-field `%s'");
          else if (0 < compare_tree_int (DECL_INITIAL (x), max_width))
            pedwarn_with_decl (x, "width of `%s' exceeds its type");	<***
          else if (integer_zerop (DECL_INITIAL (x)) && DECL_NAME (x) != 0)
            error_with_decl (x, "zero width for bit-field `%s'");
          else
	    {
	      ...

              DECL_SIZE (x) = bitsize_int (width);
              DECL_BIT_FIELD (x) = 1;
              SET_DECL_C_BIT_FIELD (x);
	      ...
	    }

	cp/class.c sometimes leaves the DECL fields undefined (by setting
error_mark_node) and sometimes proceeds with assigning the DECL fields, as
in the case of the "width exceeds type" warning:

      if (TREE_CODE (w) != INTEGER_CST)
        {
          cp_error_at ("bit-field `%D' width not an integer constant",
                       field);
          w = error_mark_node;
        }
      else if (tree_int_cst_sgn (w) < 0)
        {
          cp_error_at ("negative width in bit-field `%D'", field);
          w = error_mark_node;
        }
      else if (integer_zerop (w) && DECL_NAME (field) != 0)
        {
          cp_error_at ("zero width for bit-field `%D'", field);
          w = error_mark_node;
        }
      else if (compare_tree_int (w, TYPE_PRECISION (type)) > 0
               && TREE_CODE (type) != ENUMERAL_TYPE
               && TREE_CODE (type) != BOOLEAN_TYPE)
        cp_warning_at ("width of `%D' exceeds its type", field);	<***
      else if (TREE_CODE (type) == ENUMERAL_TYPE
               && (0 > compare_tree_int (w,
                                         min_precision (TYPE_MIN_VALUE (type),
                                                        TREE_UNSIGNED (type)))
                   ||  0 > compare_tree_int (w,
                                             min_precision
                                             (TYPE_MAX_VALUE (type),
                                              TREE_UNSIGNED (type)))))
        cp_warning_at ("`%D' is too small to hold all values of `%#T'",
                       field, type);
    }

...

  if (w != error_mark_node)
    {
      DECL_SIZE (field) = convert (bitsizetype, w);
      DECL_BIT_FIELD (field) = 1;
      ...
    }


To summarize the situation so far, a bitfield width exceeding the type
size will leave DECL_BIT_FIELD unset for the C front-end but will set it
for the C++ front-end.

	Later in expr.c:expand_expr(), get_inner_reference() will
calculate the mode of the field as the mode of the outer expression for C
(because DECL_BIT_FIELD is false) and VOIDmode for C++ (because
DECL_BIT_FIELD is true).

	For C++, the VOIDmode means the field is an unaligned field in an
aligned union.  This invokes extract_bit_field() which calculates a crazy
bit offset handed to operand_subword() and simplify_gen_subreg() which
eventually ICEs.  For C, the sane outer mode skips the extract_bit_field()
call and accesses the "component" directly.

	I do not know whether C++ should behave like C and not set
DECL_BIT_FIELD.  However, if DECL_BIT_FIELD should not be set for width
exceeding type then why should it ever be set?  The non-VOIDmode case in
expand_expr() using adjust_address() and convert_move() appears to have
succeeded even though the inner mode was not aligned.

The various possibilities seem to be:

cp/class.c should not set DECL_BIT_FIELD when width exceeds type.

OR

c-decl.c should set DECL_BIT_FIELD when width exceeds type.

	If DECL_BIT_FIELD is set when the width exceeds the type, there
needs to be some other change in the backend to prevent the ICE.

get_inner_reference() always should return the outer mode?  expand_expr()
should use adjust_address() and convert_move() even when the inner mode is
VOIDmode?

	I do not know which behavior is correct other than GCC should not
ICE.

Thanks, David

Re: ia64 linux doesn't bootstrap

[Mark Mitchell]

--On Friday, October 18, 2002 04:02:53 PM -0400 David Edelsohn 
<dje@watson.ibm.com> wrote:

> 	Tighten your seatbelt, the AIX failure is another case where the C
> and C++ front-ends are not consistent with respect to the state of a DECL
> after warnings.  I am not sure which one is right.
>
> 	The testcase in g++.dg/break/bitfield7_y.C creates a bitfield that
> is too wide:
>
> union U {
>   int i: 4096;
> };

The key point is that this is valid C++, but not valid C.

So, C++ needs to handle it (somehow) and C does not.

The way the C++ front end tries to handle this is like this.  Suppose
that your widest integer type has 64 bits.  Then, G++ presents "i" as
a 64-bit bit-field to the back end.  Then, it creates some extra
space as an unnamed giant bit field.

I suspect we are running into problems with the unnamed giant field.

But, nobody should every be trying to read or write those bits.  Why
is that happenning?

Anyhow, what is the triplet for the target?  If I run bitfield7.C on
that target's cc1plus I take it I will see the failure?

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: ia64 linux doesn't bootstrap

[Janis Johnson]

On Fri, Oct 18, 2002 at 03:25:17PM -0700, Mark Mitchell wrote:
> 
> 
> --On Friday, October 18, 2002 04:02:53 PM -0400 David Edelsohn 
> <dje@watson.ibm.com> wrote:
> 
> > 	Tighten your seatbelt, the AIX failure is another case where the C
> > and C++ front-ends are not consistent with respect to the state of a DECL
> > after warnings.  I am not sure which one is right.
> >
> > 	The testcase in g++.dg/break/bitfield7_y.C creates a bitfield that
> > is too wide:
> >
> > union U {
> >   int i: 4096;
> > };
> 
> The key point is that this is valid C++, but not valid C.
> 
> So, C++ needs to handle it (somehow) and C does not.
> 
> The way the C++ front end tries to handle this is like this.  Suppose
> that your widest integer type has 64 bits.  Then, G++ presents "i" as
> a 64-bit bit-field to the back end.  Then, it creates some extra
> space as an unnamed giant bit field.
> 
> I suspect we are running into problems with the unnamed giant field.
> 
> But, nobody should every be trying to read or write those bits.  Why
> is that happenning?
> 
> Anyhow, what is the triplet for the target?  If I run bitfield7.C on
> that target's cc1plus I take it I will see the failure?

This is the new test g++.dg/compat/break/bitfield7_main.C, when the
file bitfield7_y.C is compiled.  I think you'll see the failure with
powerpc-eabisim or powerpc-unknown-linux.gnu.

Janis

Re: ia64 linux doesn't bootstrap

[David Edelsohn]

>>>>> Mark Mitchell writes:

Mark> But, nobody should every be trying to read or write those bits.  Why
Mark> is that happenning?

Mark> Anyhow, what is the triplet for the target?  If I run bitfield7.C on
Mark> that target's cc1plus I take it I will see the failure?

	The target triplet seems to be any PowerPC (:-) target:

powerpc-eabisim, powerpc-unknown-linux-gnu, powerpc-ibm-aix4.3.3.0 .

The failure, as Janis mentioned, is g++.dg/compat/break/bitfield7_y.C
which as an ABI compatibility test expands on the original
g++.dg/abi/bitfield7.C test.  bitfield7.C *does not* access the field and
does not ICE.  Only Janis's new test, bitfield7_y.C, operates on the
bitfield eliciting the ICE.  This may be a failure which only visibly ICEs
on big-endian targets due to the logic in extract_bit_field.

David

Re: ia64 linux doesn't bootstrap

[Tim Prince]

On Friday 18 October 2002 09:27, Jim Wilson wrote:
> >Maybe OT, but what version of gdb would you use, and which version of gcc
> >would you build it with?
>
> /usr/bin/gdb and /usr/bin/gcc.  Maybe I didn't understand the question?
>
I was unaware of the sourceforge gdbf95 project, which provides a more 
functional gdb than I had seen before.  I've tried to build gdb-5.2.1 with 
gcc-3.3, and it failed with many complaints about illegal code.  It did 
succeed with a buggy pre-3.0 gcc; there were I think 254 unexpected errors in 
testsuite.  Maybe that's acceptable?  Anyway, I hope to be able soon to 
whittle down a test case for the current breakage in gcc -funroll-loops, now 
that I have a gdb which is able to step through code.

-- 
Tim Prince

Re: ia64 linux doesn't bootstrap

[Andreas Schwab]

Janis Johnson <janis187@us.ibm.com> writes:

|> On Fri, Oct 18, 2002 at 03:23:39PM +0200, Andreas Schwab wrote:
|> > Aldy Hernandez <aldyh@redhat.com> writes:
|> > 
|> > |> While building stage2.
|> > |> 
|> > |> In file included from /home/aldyh/source/gcc/gcc/c-decl.c:6888:
|> > |> gt-c-decl.h:338: internal compiler error: Bus error
|> > |> Please submit a full bug report,
|> > |> 
|> > |> Just curious if anyone had seen this, or had a fix for it.  I guess I
|> > |> should pull out gdb now...
|> > 
|> > Bootstrap/regtesting just finished here.
|> > 
|> > http://gcc.gnu.org/ml/gcc-testresults/2002-10/msg00594.html
|> > 
|> > But there are a large number of new failures.
|> 
|> Most of your failures are for the new g++.dg/compat tests, which pass
|> for me on ia64-unknown-linux-gnu, Red Hat Linux release 7.2 (Enigma).
|> Can you tell why these tests are failing to execute on your system?

It's testsuite bug, I don't have "." in $PATH.  I'm checking this in as
obvious.

2002-10-19  Andreas Schwab  <schwab@suse.de>

	* lib/compat.exp (compat-run): Prepend "./" when $dest has no
	directory component.

--- gcc/testsuite/lib/compat.exp.~1.1.~	2002-10-18 02:22:57.000000000 +0200
+++ gcc/testsuite/lib/compat.exp	2002-10-19 21:22:36.000000000 +0200
@@ -96,6 +96,9 @@ proc compat-run { testname objlist dest 
     }
 
     # Run the self-checking executable.
+    if ![string match "*/*" $dest] then {
+	set dest "./$dest"
+    }
     set result [${tool}_load $dest "" ""]
     set status [lindex $result 0]
     if { $status == "pass" } then {


Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: ia64 linux doesn't bootstrap

[Janis Johnson]

On Sat, Oct 19, 2002 at 09:26:22PM +0200, Andreas Schwab wrote:
> Janis Johnson <janis187@us.ibm.com> writes:
> 
> |> On Fri, Oct 18, 2002 at 03:23:39PM +0200, Andreas Schwab wrote:
> |> > Aldy Hernandez <aldyh@redhat.com> writes:
> |> > 
> |> > |> While building stage2.
> |> > |> 
> |> > |> In file included from /home/aldyh/source/gcc/gcc/c-decl.c:6888:
> |> > |> gt-c-decl.h:338: internal compiler error: Bus error
> |> > |> Please submit a full bug report,
> |> > |> 
> |> > |> Just curious if anyone had seen this, or had a fix for it.  I guess I
> |> > |> should pull out gdb now...
> |> > 
> |> > Bootstrap/regtesting just finished here.
> |> > 
> |> > http://gcc.gnu.org/ml/gcc-testresults/2002-10/msg00594.html
> |> > 
> |> > But there are a large number of new failures.
> |> 
> |> Most of your failures are for the new g++.dg/compat tests, which pass
> |> for me on ia64-unknown-linux-gnu, Red Hat Linux release 7.2 (Enigma).
> |> Can you tell why these tests are failing to execute on your system?
> 
> It's testsuite bug, I don't have "." in $PATH.  I'm checking this in as
> obvious.
> 
> 2002-10-19  Andreas Schwab  <schwab@suse.de>
> 
> 	* lib/compat.exp (compat-run): Prepend "./" when $dest has no
> 	directory component.

Thanks for looking into this.

Janis

Re: ia64 linux doesn't bootstrap

[Mark Mitchell]

--On Friday, October 18, 2002 10:02:32 PM -0400 David Edelsohn 
<dje@watson.ibm.com> wrote:

>>>>>> Mark Mitchell writes:
>
> Mark> But, nobody should every be trying to read or write those bits.  Why
> Mark> is that happenning?
>
> Mark> Anyhow, what is the triplet for the target?  If I run bitfield7.C on
> Mark> that target's cc1plus I take it I will see the failure?
>
> 	The target triplet seems to be any PowerPC (:-) target:
>
> powerpc-eabisim, powerpc-unknown-linux-gnu, powerpc-ibm-aix4.3.3.0 .
>
> The failure, as Janis mentioned, is g++.dg/compat/break/bitfield7_y.C
> which as an ABI compatibility test expands on the original
> g++.dg/abi/bitfield7.C test.  bitfield7.C *does not* access the field and
> does not ICE.  Only Janis's new test, bitfield7_y.C, operates on the
> bitfield eliciting the ICE.  This may be a failure which only visibly ICEs
> on big-endian targets due to the logic in extract_bit_field.

I don't understand the subject line of this thread.  Does this actually
affect a bootstrap on ia64 GNU/Linux?

If the only way to get this problem is with a bitfield longer than its
type, it's not a terribly important bug.  That code didn't used to be
accepted by GCC 2.95.x; it gave a sorry.  Now we crash on some targets.

This is a bug well worth fixing, but I'm trying to figure out if I need
to look at it *right now*.

In any case, please get it into GNATS.

Then, mark it with an appropriate priority.

Thanks,

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Re: ia64 linux doesn't bootstrap

[Jim Wilson]

>I don't understand the subject line of this thread.  Does this actually
>affect a bootstrap on ia64 GNU/Linux?

No.  It has nothing to do with the original subject of this thread.

Jim

Re: ia64 linux doesn't bootstrap

[Janis Johnson]

On Sun, Oct 20, 2002 at 03:41:06PM -0700, Mark Mitchell wrote:
> 
> 
> --On Friday, October 18, 2002 10:02:32 PM -0400 David Edelsohn 
> <dje@watson.ibm.com> wrote:
> 
> > The failure, as Janis mentioned, is g++.dg/compat/break/bitfield7_y.C
> > which as an ABI compatibility test expands on the original
> > g++.dg/abi/bitfield7.C test.  bitfield7.C *does not* access the field and
> > does not ICE.  Only Janis's new test, bitfield7_y.C, operates on the
> > bitfield eliciting the ICE.  This may be a failure which only visibly ICEs
> > on big-endian targets due to the logic in extract_bit_field.
> 
> I don't understand the subject line of this thread.  Does this actually
> affect a bootstrap on ia64 GNU/Linux?

No (as has already been pointed out today).

> If the only way to get this problem is with a bitfield longer than its
> type, it's not a terribly important bug.  That code didn't used to be
> accepted by GCC 2.95.x; it gave a sorry.  Now we crash on some targets.

What happens with GCC 3.[012]?  My attempt to build a cross compiler
failed.

> This is a bug well worth fixing, but I'm trying to figure out if I need
> to look at it *right now*.
> 
> In any case, please get it into GNATS.

middle-end/8306: ICE for bitfield7_y.C in C++ compatibility tests
 
> Then, mark it with an appropriate priority.

I left it with the default; someone can change it if it turns out to be
a regression.  It affects sparc and arm as well as powerpc.

Janis

Re: ia64 linux doesn't bootstrap

[Jim Wilson]

>I was unaware of the sourceforge gdbf95 project, which provides a more 
>functional gdb than I had seen before.

I don't know about gdb Fortran support.  Perhaps you are seeing problems
which are Fortran specific rather than IA-64 specific.

> I've tried to build gdb-5.2.1 with 
>gcc-3.3, and it failed with many complaints about illegal code. 

You will have to be more specific.  I just tried building gdb-5.2.1 with
a 021014 gcc snapshot, and I didn't have any problems building it.  I did
have a problem building dejagnu-gdb-5.2.1, but that was a binutils/gcc
mismatch.  ld tries to pretty-print a "mktemp is dangerous" warning by reading
the debug info, and gets confused because it doesn't have DW_FORM_strp support.
That is fixed by using a newer binutils.  I don't feel like going to that
much trouble at the moment though.

It would also be possible to get a similar gcc/gdb mismatch, since older gdbs
won't have DW_FORM_strp support, and current gcc is likely to emit them.

> It did 
>succeed with a buggy pre-3.0 gcc; there were I think 254 unexpected errors in 
>testsuite.  Maybe that's acceptable?

No, that isn't an acceptable number of gdb failures, but you might have to
live with it for now if you aren't interested in trying to fix gdb problems
yourself.

Jim

Re: ia64 linux doesn't bootstrap

[tprinceusa]

----- Original Message -----
From: "Jim Wilson" <wilson@redhat.com>
To: <tprince@computer.org>
Cc: <gcc@gcc.gnu.org>
Sent: Tuesday, October 22, 2002 12:30 PM
Subject: Re: ia64 linux doesn't bootstrap


> >I was unaware of the sourceforge gdbf95 project, which provides a more
> >functional gdb than I had seen before.
>
> I don't know about gdb Fortran support.  Perhaps you are seeing problems
> which are Fortran specific rather than IA-64 specific.
Not unless trying to step through gcc code when there are g77 built files included is considered Fortran specific.  gdb works fine
with the same build on linux-ia32 and cygwin, and so does the newer .rpm from sourceforge for ia64.
>
> > I've tried to build gdb-5.2.1 with
> >gcc-3.3, and it failed with many complaints about illegal code.
>
> You will have to be more specific.  I just tried building gdb-5.2.1 with
> a 021014 gcc snapshot, and I didn't have any problems building it.
Since there were many diagnostics about violation of standards, such as about the pointer aliasing, I thought maybe options such
as -fno-strict-aliasing or -traditional might be needed, but saw no improvement.  I couldn't find a clear reason for the build to
die where it did consistently.
> I did
> have a problem building dejagnu-gdb-5.2.1, but that was a binutils/gcc
> mismatch.  ld tries to pretty-print a "mktemp is dangerous" warning by reading
> the debug info, and gets confused because it doesn't have DW_FORM_strp support.
> That is fixed by using a newer binutils.  I don't feel like going to that
> much trouble at the moment though.
I've been shooting in the dark trying to figure out which binutils to use.  2.13 died while building with gcc-3.3; 2.12.91 appeared
to work fine, gave good testsuite results, and cured some of my gcc testsuite failures.
>
> It would also be possible to get a similar gcc/gdb mismatch, since older gdbs
> won't have DW_FORM_strp support, and current gcc is likely to emit them.
>
> > It did
> >succeed with a buggy pre-3.0 gcc; there were I think 254 unexpected errors in
> >testsuite.  Maybe that's acceptable?
>
> No, that isn't an acceptable number of gdb failures, but you might have to
> live with it for now if you aren't interested in trying to fix gdb problems
> yourself.
Since someone has been working on adding Fortran-specific support to gdb-5.1.1 on sourceforge, which I do need, and that version
appears to work well enough, I'm not inclined to work on a version which isn't likely to help anyone.  I'm only trying to get
adequate versions of binutils and gdb going so that I could diagnose gcc failures.
>
> Jim

Thanks,

Tim

-------------------------------------------
Introducing NetZero Long Distance
Unlimited Long Distance only $29.95/ month!
Sign Up Today! www.netzerolongdistance.com

Re: ia64 linux doesn't bootstrap

[Ulrich Weigand]

David Edelsohn wrote:

> 	This is explained in my earlier message analyzing the failure.

Ah, I missed that.

Thanks,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de

Re: ia64 linux doesn't bootstrap

[David Edelsohn]

>>>>> Ulrich Weigand writes:

Ulrich> I haven't analysed why extract_bit_field is called like that.

	This is explained in my earlier message analyzing the failure.  It
is called like that because the width of the bitfield exceeds its type yet
DECL_BIT_FIELD is set true.  When DECL_BIT_FIELD is true, the call to
get_inner_reference() sets the MODE to BLKmode which causes
extract_bit_field() to be used to access the bits.  extract_bit_field()
wants to step through the offsets in the word and ends up referring to
word -1 on big-endian targets.

David

Re: ia64 linux doesn't bootstrap

[Ulrich Weigand]

Janis Johnson wrote:

>middle-end/8306: ICE for bitfield7_y.C in C++ compatibility tests

>I left it with the default; someone can change it if it turns out to be
>a regression.  It affects sparc and arm as well as powerpc.

And s390.

What appears to happen is that extract_bit_field is called to
extract a 64-bit bitfield into an SImode target.

This violates the assumption in this comment

  /* ??? We currently assume TARGET is at least as big as BITSIZE.
     If that's wrong, the solution is to test for it and set TARGET to 0
     if needed.  */

and in particular on big-endian targets, causes operand_subword
to be called with a wordnum of -1, which then aborts.

I haven't analysed why extract_bit_field is called like that.

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  weigand@informatik.uni-erlangen.de