Pedro Alves wrote:

> What about the attached?  Isn't it simpler?
> 
> We get passed the max number of bits the number we're parsing
> can hold in TWOS_COMPLEMENT_BITS.
> 
> Just parse the number as unsigned, if it overflows, it doesn't
> matter, we just account for the bits.
> If it doesn't overflow (host has a big long),
>     and TWOS_COMPLEMENT_BITS < sizeof (long) * HOST_CHAR_BIT
>     and number is signed according to TWOS_COMPLEMENT_BITS - 1
>     bit being set, sign extend the number into a long.
> 
> Just tested that it also fixes the problem.  I'll give it a
> testsuite spin for C/C++ on Cygwin tomorrow, but the testcase
> that suposedly tests this is in ADA, which I don't have a
> setup for...
> 

Just tested the slightly updated patch on Cygwin, and it doesn't
bring about any new problem.

I also stepped through read_huge_number using the attached
read_huge_number.s as a test.  I don't know how to force gcc to
output a range type in octal that triggers
'TWOS_COMPLEMENT_BITS < sizeof (long) * HOST_CHAR_BIT', so I've hacked
the stabs myself:

Replaced:
.stabs  "short int:t(0,8)=@s16;r(0,8);-32768;32767;",128,0,0,0
.stabs  "short unsigned int:t(0,9)=@s16;r(0,9);0;65535;",128,0,0,0

By:
.stabs	"short int:t(0,8)=@s16;r(0,8);0100000;077777;",128,0,0,0
.stabs	"short unsigned int:t(0,9)=@s16;r(0,9);0000000;0177777;",128,0,0,0

'ptype main' triggers the read_range_type call, which calls
read_huge_number twice for the range.

I've confirmed that we read 0100000 as (long)-32768.

Don't know how to convert this to a testcase.
'maint print type short int' doesn't show these ranges,
are they stored anywhere?

Cheers,
Pedro Alves