[Patch, fortran] PR 52428 Reading of large negative values and range checking

View: New views
4 Messages — Rating Filter:   Alert me  

[Patch, fortran] PR 52428 Reading of large negative values and range checking

by Janne Blomqvist-3 :: Rate this Message:

| View Threaded | Show Only this Message

Hi,

currently when -frange-check is enabled, we check for overflow when
doing a formatted read of an integer value. This check, however, is
against the Fortran numerical model (see 13.4 in F2008), which defines
a symmetric interval [-huge(), huge()], whereas all targets gfortran
supports use a two's complement representation with a range of
[-huge()-1, huge()].

However, there is no checking against the numerical model when doing
arithmetic, and thus we can generate and write the value -huge()-1,
but we cannot read it back in! With the -fno-range-check option, this
overflow checking can be disabled, but at the cost of disabling all
overflow checking, which leads to reading nonsense values if the
hardware supported range overflows.

The attached patch changes this logic such that overflow checking
against the hardware supported range [-huge()-1, huge()] is always
done when reading, regardless of the -frange-check flag setting. This
also seems to be what ifort 12.0 does, I haven't checked other
compilers.

For some more arguments back and forth, see the PR.

Regtested on x86_64-unknown-linux-gnu, Ok for trunk?

gcc/fortran ChangeLog:

2012-04-25  Janne Blomqvist  <jb@...>

        PR fortran/52428
        * gfortran.texi: Update _gfortran_set_options documentation.
        * invoke.texi: Remove runtime behavior description of
        -fno-range-check.
        * trans-decl.c (create_main_function): Don't pass the range-check
        setting to the library.


libgfortran ChangeLog:

2012-04-25  Janne Blomqvist  <jb@...>

        PR fortran/52428
        * io/io.h (max_value): Rename to si_max, remove second argument.
        * io/list_read.c (convert_integer): Use unsigned types when
        parsing the digits, set max value depending on the sign.
        * io/read.c (max_value): Rename to si_max, remove second argument,
        simplify.
        (read_decimal): Set max value depending on sign, always check
        overflow.
        (read_radix): Calculate max unsigned value directly.
        * libgfortran.h (struct compile_options_t): Remove range_check
        field.
        * runtime/compile_options.c (set_options): Skip handling
        options[7].
        (init_compile_options): Don't set removed field.


gcc/testsuite ChangeLog:

2012-04-25  Janne Blomqvist  <jb@...>

        PR fortran/52428
        * gfortran.dg/int_range_io_1.f90: New test.


--
Janne Blomqvist



intparse.diff (12K) Download Attachment
int_range_io_1.f90 (1K) Download Attachment

Re: [Patch, fortran] PR 52428 Reading of large negative values and range checking

by Janne Blomqvist-3 :: Rate this Message:

| View Threaded | Show Only this Message

PING

On Thu, Apr 26, 2012 at 12:08 AM, Janne Blomqvist
<blomqvist.janne@...> wrote:

> Hi,
>
> currently when -frange-check is enabled, we check for overflow when
> doing a formatted read of an integer value. This check, however, is
> against the Fortran numerical model (see 13.4 in F2008), which defines
> a symmetric interval [-huge(), huge()], whereas all targets gfortran
> supports use a two's complement representation with a range of
> [-huge()-1, huge()].
>
> However, there is no checking against the numerical model when doing
> arithmetic, and thus we can generate and write the value -huge()-1,
> but we cannot read it back in! With the -fno-range-check option, this
> overflow checking can be disabled, but at the cost of disabling all
> overflow checking, which leads to reading nonsense values if the
> hardware supported range overflows.
>
> The attached patch changes this logic such that overflow checking
> against the hardware supported range [-huge()-1, huge()] is always
> done when reading, regardless of the -frange-check flag setting. This
> also seems to be what ifort 12.0 does, I haven't checked other
> compilers.
>
> For some more arguments back and forth, see the PR.
>
> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
>
> gcc/fortran ChangeLog:
>
> 2012-04-25  Janne Blomqvist  <jb@...>
>
>        PR fortran/52428
>        * gfortran.texi: Update _gfortran_set_options documentation.
>        * invoke.texi: Remove runtime behavior description of
>        -fno-range-check.
>        * trans-decl.c (create_main_function): Don't pass the range-check
>        setting to the library.
>
>
> libgfortran ChangeLog:
>
> 2012-04-25  Janne Blomqvist  <jb@...>
>
>        PR fortran/52428
>        * io/io.h (max_value): Rename to si_max, remove second argument.
>        * io/list_read.c (convert_integer): Use unsigned types when
>        parsing the digits, set max value depending on the sign.
>        * io/read.c (max_value): Rename to si_max, remove second argument,
>        simplify.
>        (read_decimal): Set max value depending on sign, always check
>        overflow.
>        (read_radix): Calculate max unsigned value directly.
>        * libgfortran.h (struct compile_options_t): Remove range_check
>        field.
>        * runtime/compile_options.c (set_options): Skip handling
>        options[7].
>        (init_compile_options): Don't set removed field.
>
>
> gcc/testsuite ChangeLog:
>
> 2012-04-25  Janne Blomqvist  <jb@...>
>
>        PR fortran/52428
>        * gfortran.dg/int_range_io_1.f90: New test.
>
>
> --
> Janne Blomqvist



--
Janne Blomqvist

Re: [Patch, fortran] PR 52428 Reading of large negative values and range checking

by Janne Blomqvist-3 :: Rate this Message:

| View Threaded | Show Only this Message

PING #2!

On Wed, May 2, 2012 at 10:22 PM, Janne Blomqvist
<blomqvist.janne@...> wrote:

> PING
>
> On Thu, Apr 26, 2012 at 12:08 AM, Janne Blomqvist
> <blomqvist.janne@...> wrote:
>> Hi,
>>
>> currently when -frange-check is enabled, we check for overflow when
>> doing a formatted read of an integer value. This check, however, is
>> against the Fortran numerical model (see 13.4 in F2008), which defines
>> a symmetric interval [-huge(), huge()], whereas all targets gfortran
>> supports use a two's complement representation with a range of
>> [-huge()-1, huge()].
>>
>> However, there is no checking against the numerical model when doing
>> arithmetic, and thus we can generate and write the value -huge()-1,
>> but we cannot read it back in! With the -fno-range-check option, this
>> overflow checking can be disabled, but at the cost of disabling all
>> overflow checking, which leads to reading nonsense values if the
>> hardware supported range overflows.
>>
>> The attached patch changes this logic such that overflow checking
>> against the hardware supported range [-huge()-1, huge()] is always
>> done when reading, regardless of the -frange-check flag setting. This
>> also seems to be what ifort 12.0 does, I haven't checked other
>> compilers.
>>
>> For some more arguments back and forth, see the PR.
>>
>> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
>>
>> gcc/fortran ChangeLog:
>>
>> 2012-04-25  Janne Blomqvist  <jb@...>
>>
>>        PR fortran/52428
>>        * gfortran.texi: Update _gfortran_set_options documentation.
>>        * invoke.texi: Remove runtime behavior description of
>>        -fno-range-check.
>>        * trans-decl.c (create_main_function): Don't pass the range-check
>>        setting to the library.
>>
>>
>> libgfortran ChangeLog:
>>
>> 2012-04-25  Janne Blomqvist  <jb@...>
>>
>>        PR fortran/52428
>>        * io/io.h (max_value): Rename to si_max, remove second argument.
>>        * io/list_read.c (convert_integer): Use unsigned types when
>>        parsing the digits, set max value depending on the sign.
>>        * io/read.c (max_value): Rename to si_max, remove second argument,
>>        simplify.
>>        (read_decimal): Set max value depending on sign, always check
>>        overflow.
>>        (read_radix): Calculate max unsigned value directly.
>>        * libgfortran.h (struct compile_options_t): Remove range_check
>>        field.
>>        * runtime/compile_options.c (set_options): Skip handling
>>        options[7].
>>        (init_compile_options): Don't set removed field.
>>
>>
>> gcc/testsuite ChangeLog:
>>
>> 2012-04-25  Janne Blomqvist  <jb@...>
>>
>>        PR fortran/52428
>>        * gfortran.dg/int_range_io_1.f90: New test.
>>
>>
>> --
>> Janne Blomqvist
>
>
>
> --
> Janne Blomqvist



--
Janne Blomqvist

Re: [Patch, fortran] PR 52428 Reading of large negative values and range checking

by jerry DeLisle-3 :: Rate this Message:

| View Threaded | Show Only this Message

On 05/11/2012 09:07 AM, Janne Blomqvist wrote:

> PING #2!
>
> On Wed, May 2, 2012 at 10:22 PM, Janne Blomqvist
> <blomqvist.janne@...>  wrote:
>> PING
>>
>> On Thu, Apr 26, 2012 at 12:08 AM, Janne Blomqvist
>> <blomqvist.janne@...>  wrote:
>>> Hi,
>>>
>>> currently when -frange-check is enabled, we check for overflow when
>>> doing a formatted read of an integer value. This check, however, is
>>> against the Fortran numerical model (see 13.4 in F2008), which defines
>>> a symmetric interval [-huge(), huge()], whereas all targets gfortran
>>> supports use a two's complement representation with a range of
>>> [-huge()-1, huge()].
>>>
>>> However, there is no checking against the numerical model when doing
>>> arithmetic, and thus we can generate and write the value -huge()-1,
>>> but we cannot read it back in! With the -fno-range-check option, this
>>> overflow checking can be disabled, but at the cost of disabling all
>>> overflow checking, which leads to reading nonsense values if the
>>> hardware supported range overflows.
>>>
>>> The attached patch changes this logic such that overflow checking
>>> against the hardware supported range [-huge()-1, huge()] is always
>>> done when reading, regardless of the -frange-check flag setting. This
>>> also seems to be what ifort 12.0 does, I haven't checked other
>>> compilers.
>>>
>>> For some more arguments back and forth, see the PR.
>>>
>>> Regtested on x86_64-unknown-linux-gnu, Ok for trunk?

Patch OK for trunk.  In spite of myself, it does not hurt anything.

Regards,

Jerry