Bug on PPC (no patch yet)

Bug on PPC (no patch yet)

[Elliot Lee]

compile/961203-1.c

It gets into an infinite recursion between extract_fixed_bit_field()  and
extract_split_bit_field().

Happens on the latest snapshot...
-- Elliot					http://www.redhat.com/
"They don't let my code go into shipping products," Gates said. "They
 haven't done that for eight years." (at the 1997 PDC)

Re: Bug on PPC (no patch yet)

[Jeffrey A Law]

  In message < Pine.LNX.3.95.971015232715.7124A-100000@helix.cs.cuc.edu >you write:
  > compile/961203-1.c
  > 
  > It gets into an infinite recursion between extract_fixed_bit_field()  and
  > extract_split_bit_field().
Known problem.

jeff

Re: Bug on PPC (no patch yet)

[Joe Buck]

>   In message < Pine.LNX.3.95.971015232715.7124A-100000@helix.cs.cuc.edu >you write:
>   > compile/961203-1.c
>   > 
>   > It gets into an infinite recursion between extract_fixed_bit_field()  and
>   > extract_split_bit_field().
> Known problem.

It fails because the offset as measured in bits exceeds 32 bits, and bad
things happen.

My reaction to that particular bug is "who cares?"  Why not just mark it
as XFAIL on 32-bit platforms, if we don't intend to fix it?  It's not like
the users are likely to hit on this case by accident (create a struct
of at least 2^29 bytes that has a bitfield at the end).  The only reason
this is even in there is that someone with knowledge of gcc internals who
is also a language lawyer tossed it in.  I don't believe such code ever
appeared in a real program.  If folks really *are* worried about it
appearing in a real program, possibly we could attempt to produce a
"sorry, not implemented: bit offset too large" message rather than an
infinite recursion.

Re: Bug on PPC (no patch yet)

[Ian Lance Taylor]

   From: Joe Buck <jbuck@synopsys.com>
   Date: Tue, 21 Oct 97 9:02:09 PDT

   The only reason
   this is even in there is that someone with knowledge of gcc internals who
   is also a language lawyer tossed it in.  I don't believe such code ever
   appeared in a real program.

Believe it or not, something of this sort was actually reported by a
Cygnus customer based on code which appeared in a real program.  I
believe they were using a large structure based at address zero to
force memory access to occur at a specific memory address.

Ian

Re: Bug on PPC (no patch yet)

[Joe Buck]

> Believe it or not, something of this sort was actually reported by a
> Cygnus customer based on code which appeared in a real program.  I
> believe they were using a large structure based at address zero to
> force memory access to occur at a specific memory address.

Sigh.  The users are always more clever than we give them credit for. :-)

Re: Bug on PPC (no patch yet)

[Robert Lipe]

> >   > compile/961203-1.c
> >   > It gets into an infinite recursion between extract_fixed_bit_field()  and
> > Known problem.
> 
> It fails because the offset as measured in bits exceeds 32 bits, and bad
> things happen.
> 
> My reaction to that particular bug is "who cares?"  Why not just mark it
> as XFAIL on 32-bit platforms, if we don't intend to fix it?  It's not like

Because it torments the hell out of the VM system when it runs, consuming
all the VM and having Bad Effects on system performance in general.  On my
system, when I run runtest without ulimit-ing the VM, I end up with 
corefiles from this test in the hundreds of megabytes range. 

> appeared in a real program.  If folks really *are* worried about it
> appearing in a real program, possibly we could attempt to produce a
> "sorry, not implemented: bit offset too large" message rather than an
> infinite recursion.

On March 13, Alexandre Oliva implemented just that.  The patch, often 
cited, has never appeared in a GCC/EGCS snapshot.  It's not in gcc-1021. 
I'd like to see something like this patch and the test marked xfail so
that the test would fail quickly and without dogging swap in the process.

Patch from AO.

--- stor-layout.c~      Thu Mar 13 03:08:23 1997
+++ stor-layout.c       Thu Mar 13 03:22:39 1997
@@ -995,6 +995,12 @@
   if (TYPE_SIZE (type) != 0 && TREE_CODE (TYPE_SIZE (type)) != INTEGER_CST)
     TYPE_SIZE (type) = variable_size (TYPE_SIZE (type));

+  /* If type is negative, produce an internal compiler error.
+     This may be caused by an array that is too large. */
+  if (TYPE_SIZE (type) != 0 && TREE_CODE (TYPE_SIZE (type)) == INTEGER_CST
+      && TREE_INT_CST_LOW(TYPE_SIZE (type)) < 0)
+    fatal("internal compiler error: type too big");
+
   /* Also layout any other variants of the type.  */
   if (TYPE_NEXT_VARIANT (type)
       || type != TYPE_MAIN_VARIANT (type))

Re: Bug on PPC (no patch yet)

[Paul Koning]

>>>>> "Robert" == Robert Lipe <robertl@dgii.com> writes:
...
 Robert> Patch from AO.
...
 Robert> + /* If type is negative, produce an internal compiler error.
 Robert> + This may be caused by an array that is too large.

I assume this wouldn't happen for 64-bit targets unless the array size
exceeds 64 (not 32) bits, right?

The error generated should NOT be "internal compiler error".  That
error message should always mean "there's a bug in the compiler" and
never "there's something wrong with your source code".

	paul

Re: Bug on PPC (no patch yet)

[Joe Buck]

>  Robert> + /* If type is negative, produce an internal compiler error.
>  Robert> + This may be caused by an array that is too large.

As I said, I'm not sure that patch is correct, since a larger overflow
can produce an invalid positive result.

> I assume this wouldn't happen for 64-bit targets unless the array size
> exceeds 64 (not 32) bits, right?

Yes.

> The error generated should NOT be "internal compiler error".  That
> error message should always mean "there's a bug in the compiler" and
> never "there's something wrong with your source code".

There's nothing wrong with the source code.  Furthermore, the compiler is
not detecting an error in itself, so it's not an internal compiler error
either.  That's why I suggested a "sorry, not implemented" type of
message.

mongo array/bitfield errors Was: Bug on PPC (no patch yet)

[Robert Lipe]

>  Robert> Patch from AO.
> ...
>  Robert> + /* If type is negative, produce an internal compiler error.
>  Robert> + This may be caused by an array that is too large.
> 
> I assume this wouldn't happen for 64-bit targets unless the array size
> exceeds 64 (not 32) bits, right?

I didn't write (and don't understand) the patch, so I really can't 
defend it, but from previous iterations of this discussion, I think 
it was mentioned that it was a non-problem on 64 bit hosts but a 
problem for all 32 bit hosts.   It could have been targets instead 
of hosts.  I don't recall.

> The error generated should NOT be "internal compiler error".  That
> error message should always mean "there's a bug in the compiler" and
> never "there's something wrong with your source code".

It's one possible starting place.      Feel free to implement 
additional checks (as suggested by Joe Buck) or different errors.  

Feel free to do something else competely.  :-)

RJL

Re: Bug on PPC (no patch yet)

[Richard Henderson]

On Tue, Oct 21, 1997 at 04:02:03PM -0400, Paul Koning wrote:
> I assume this wouldn't happen for 64-bit targets unless the array size
> exceeds 64 (not 32) bits, right?

Yes it will happen.  The overflow is based on the host's idea of "int",
which is 32-bits on all supported 64-bit hosts.

> The error generated should NOT be "internal compiler error".  That
> error message should always mean "there's a bug in the compiler" and
> never "there's something wrong with your source code".

But it is a bug (er limitation) in the compiler.  "There's something
wrong with your source code" should be limited to actual violations
of standards not "you've encountered an implementation limit".


r~