Re: Generate abs target assembly code with saturation behavior
Therefore, the macro in libgcc should be fine for GCC even if there may occur signed overflow. Because we have GCC implementation defined to follow. GCC implementation defined could be guarantee even if generate abs. Because abssi2 shouldn't do saturation. But how the target generate abs instruction if the target abs have saturation behavior ? We couldn't use abssi2 naming pattern and ss_abssi2 naming pattern doesn't exist. Or we should suggest CPU provider define another abs instruction without saturation ? 2013/6/28 Joseph S. Myers jos...@codesourcery.com: On Fri, 28 Jun 2013, Shiva Chen wrote: Does the abssi2 semantically assume target abs shouldn't do saturation ? Yes. The semantics of RTL abs are modulo, whereas ss_abs does signed saturation. Likewise for addition, subtraction and multiplication. (Some RTL codes have more complicated target-specific semantics, e.g. shifts, and signed INT_MIN / -1 and INT_MIN % -1 should currently be considered undefined in RTL rather than defined with modulo semantics.) -- Joseph S. Myers jos...@codesourcery.com
Re: Generate abs target assembly code with saturation behavior
On Sun, 30 Jun 2013, Shiva Chen wrote: But how the target generate abs instruction if the target abs have saturation behavior ? We couldn't use abssi2 naming pattern and ss_abssi2 naming pattern doesn't exist. If you want to use a saturating abs instruction for C code that exhibits undefined behavior in cases where the instruction saturates, you need to add support for ss_abssi2 patterns and teach the GIMPLE-to-RTL conversion to use such patterns as appropriate (in the absence of -fwrapv/-ftrapv, of course). -- Joseph S. Myers jos...@codesourcery.com
Re: Generate abs target assembly code with saturation behavior
Thank you for all your kindly help make the issue more clear. Currently, we would disable abssi2 pattern and the soft-fp could work correctly. Thanks all the explanation and assistance. I really appreciate it. 2013/6/30 Joseph S. Myers jos...@codesourcery.com: On Sun, 30 Jun 2013, Shiva Chen wrote: But how the target generate abs instruction if the target abs have saturation behavior ? We couldn't use abssi2 naming pattern and ss_abssi2 naming pattern doesn't exist. If you want to use a saturating abs instruction for C code that exhibits undefined behavior in cases where the instruction saturates, you need to add support for ss_abssi2 patterns and teach the GIMPLE-to-RTL conversion to use such patterns as appropriate (in the absence of -fwrapv/-ftrapv, of course). -- Joseph S. Myers jos...@codesourcery.com
Generate abs target assembly code with saturation behavior
Hi,
I have a case which will generate abs instructions.
int main(int argc)
{
if (argc 0)
argc = -(unsigned int)argc;
return argc;
}
To my understanding, given that argc=0x8000 in 32bit int plaform,
the result of (unsigned int)argc is well defined and should be 0x8000u.
(C99 6.3.1.3 point 2)
And then the result of -0x8000u should be 0x8000 because
unsigned operation can never overflow and the value can be
represented by signed integer.
(C99 6.2.5 point 9)
when the case is compiled above -O1,
it would generate abs instruction directly if the target provides
abssi2 naming pattern.
However, if the target's abs have saturation behavior
(i.e abs (0x8000) = 0x7fff)
then the result will wrong.
My question is
Does the abssi2 semantically assume target abs shouldn't do saturation ?
If the target abs have saturation behavior
How should the target generate abs instruction to avoid the wrong result ?
I noticed that there is ss_abs rtx code.
But it seems there is no ss_abssi2 naming pattern.
Any suggestion?
Thanks in advance.
Shiva
Re: Generate abs target assembly code with saturation behavior
On 06/28/2013 08:53 AM, Shiva Chen wrote:
I have a case which will generate abs instructions.
int main(int argc)
{
if (argc 0)
argc = -(unsigned int)argc;
return argc;
}
To my understanding, given that argc=0x8000 in 32bit int plaform,
the result of (unsigned int)argc is well defined and should be 0x8000u.
(C99 6.3.1.3 point 2)
And then the result of -0x8000u should be 0x8000 because
unsigned operation can never overflow and the value can be
represented by signed integer.
(C99 6.2.5 point 9)
Yes, but you can't then assign that to an int, because it will overflow.
0x8000 will not fit in an int: it's undefined behaviour.
Andrew.
Re: Generate abs target assembly code with saturation behavior
On 06/28/2013 11:11 AM, Andrew Haley wrote:
On 06/28/2013 08:53 AM, Shiva Chen wrote:
I have a case which will generate abs instructions.
int main(int argc)
{
if (argc 0)
argc = -(unsigned int)argc;
return argc;
}
To my understanding, given that argc=0x8000 in 32bit int plaform,
the result of (unsigned int)argc is well defined and should be 0x8000u.
(C99 6.3.1.3 point 2)
And then the result of -0x8000u should be 0x8000 because
unsigned operation can never overflow and the value can be
represented by signed integer.
(C99 6.2.5 point 9)
Yes, but you can't then assign that to an int, because it will overflow.
0x8000 will not fit in an int: it's undefined behaviour.
GCC has an extension which makes this implementation-defined, preserving
the bit pattern in the signed type:
For conversion to a type of width N, the value is reduced modulo 2^N to
be within range of the type; no signal is raised.
http://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html#Integers-implementation
--
Florian Weimer / Red Hat Product Security Team
Re: Generate abs target assembly code with saturation behavior
On Fri, 28 Jun 2013, Andrew Haley wrote:
On 06/28/2013 08:53 AM, Shiva Chen wrote:
I have a case which will generate abs instructions.
int main(int argc)
{
if (argc 0)
argc = -(unsigned int)argc;
return argc;
}
To my understanding, given that argc=0x8000 in 32bit int plaform,
the result of (unsigned int)argc is well defined and should be 0x8000u.
(C99 6.3.1.3 point 2)
And then the result of -0x8000u should be 0x8000 because
unsigned operation can never overflow and the value can be
represented by signed integer.
(C99 6.2.5 point 9)
Yes, but you can't then assign that to an int, because it will overflow.
0x8000 will not fit in an int: it's undefined behaviour.
Implementation defined, and ok with gcc:
http://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html
--
Marc Glisse
Re: Generate abs target assembly code with saturation behavior
Accordoing to GCC implementation defined
assigned 0x8000u to signed int should be 0x8000.
If GCC generate abs, abs will saturation or not depend on target ISA.
Then the result of the case won't follow the GCC implementation defined.
Then the result of the marco in
libgcc/soft-fp/op-common.h
1126 #define _FP_FROM_INT(fs, wc, X, r, rsize, rtype)
\
1127 do {
\
1128 if (r)
\
1129 {
\
1130 rtype ur_;
\
1131
\
1132 if ((X##_s = (r 0)))
\
1133 r = -(rtype)r;
The value of r will be target dependent if the input of r = 0x8000
I'm not sure which way would better.
We should avoid undefined C99 behavior
or We should avoid generate abs then the implementation defined could
be guarantee.
2013/6/28 Marc Glisse marc.gli...@inria.fr:
On Fri, 28 Jun 2013, Andrew Haley wrote:
On 06/28/2013 08:53 AM, Shiva Chen wrote:
I have a case which will generate abs instructions.
int main(int argc)
{
if (argc 0)
argc = -(unsigned int)argc;
return argc;
}
To my understanding, given that argc=0x8000 in 32bit int plaform,
the result of (unsigned int)argc is well defined and should be
0x8000u.
(C99 6.3.1.3 point 2)
And then the result of -0x8000u should be 0x8000 because
unsigned operation can never overflow and the value can be
represented by signed integer.
(C99 6.2.5 point 9)
Yes, but you can't then assign that to an int, because it will overflow.
0x8000 will not fit in an int: it's undefined behaviour.
Implementation defined, and ok with gcc:
http://gcc.gnu.org/onlinedocs/gcc/Integers-implementation.html
--
Marc Glisse
Re: Generate abs target assembly code with saturation behavior
On Fri, 28 Jun 2013, Shiva Chen wrote: Does the abssi2 semantically assume target abs shouldn't do saturation ? Yes. The semantics of RTL abs are modulo, whereas ss_abs does signed saturation. Likewise for addition, subtraction and multiplication. (Some RTL codes have more complicated target-specific semantics, e.g. shifts, and signed INT_MIN / -1 and INT_MIN % -1 should currently be considered undefined in RTL rather than defined with modulo semantics.) -- Joseph S. Myers jos...@codesourcery.com
