Re: Draft C bindings for IEEE 754-2008 part 4 now available

[Vincent Lefevre]

On 2014-01-07 16:45:49 +, Joseph S. Myers wrote:
> Sure, such a correctly rounded function is useful just like correctly 
> rounded versions of other functions.  The proposed C bindings reserve cr* 
> names *only* for the specific functions listed in 9.2 where IEEE 754 
> recommends correctly rounded functions, not for other existing ISO C 
> functions (e.g. erf, tgamma) or functions added by the C bindings by 
> analogy with other IEEE 754 functions (e.g. tanpi), but I think correctly 
> rounded versions of other functions (with the same naming convention) 
> could reasonably be added to glibc if anyone wishes to implement them.

New CR functions may be added in future revisions of IEEE 754, so
that I think that cr* names should be reserved for all functions.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Infinite number of iterations in loop [v850, mep]

[Richard Biener]

On Tue, Jan 7, 2014 at 4:47 PM, Paulo Matos  wrote:
>> -Original Message-
>> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Paulo
>> Matos
>> Sent: 13 November 2013 16:14
>> To: Andrew Haley
>> Cc: gcc@gcc.gnu.org
>> Subject: RE: Infinite number of iterations in loop [v850, mep]
>>
>> > -Original Message-
>> > From: Andrew Haley [mailto:a...@redhat.com]
>> > Sent: 13 November 2013 15:56
>> > To: Paulo Matos
>> > Cc: gcc@gcc.gnu.org
>> > Subject: Re: Infinite number of iterations in loop [v850, mep]
>> >
>> > On 11/13/2013 03:48 PM, Paulo Matos wrote:
>> >
>> > Because GCC does not know that *c++ = 0; will not overwrite b .  I
>> > suppose you could argue that it's not really infinite, because a will
>> > eventually equal 0x, but I think that's what is going on.
>> >
>> > Andrew.
>> >
>>
>>
>> I will try to investigate further.
>>
>
> After re-encountering this issue something is amiss. I think this is 
> incorrect.
> In the example:
> extern int *c;
>
> void fn1 (unsigned int b)
> {
>   unsigned int a;
>   for (a = 0; a < b; a++)
> *c++ = 0;
> }
>
> It doesn't make sense to assume *c++ will overwrite b. b is an argument to 
> the function.

That was refering to the case with extern b.  For the above case the
issue must be sth else.  Trying a cross to v850-elf to see if it
reproduces for me (if 'b' is a stack or argument slot then we might
bogously think that *c++ = 0 may clobber it, otherwise RTL
number of iteration analysis might just be confused).

So for example (should be arch independent)

struct X { int i; int j; int k; int l[24]; };

int foo (struct X x, int *p)
{
  int z = x.j;
  *p = 1;
  return z;
}

see if there is a anti-dependence between x.j and *p on the RTL side
(at least the code dispatching to the tree oracle using the MEM_EXPRs
should save you from that).

So - v850 at least doesn't pass b in memory and the doloop recognition
works for me (on trunk).

Richard.

> The same situation occurs with a coremark function:
> void matrix_add_const(ee_u32 N, MATDAT *A, MATDAT val) {
>  ee_u32 i,j;
>  for (i=0; i   for (j=0; jA[i*N+j] += val;
>   }
>  }
> }
>
> It also says the inner loop might be infinite but it can't N is given as 
> argument. j starts as 0, N is unsigned like N. This will loop N times. GCC 
> cannot possibly assume array A will overwrite the value of N in the loop. 
> This seems like something is wrong in alias analysis.
>
>> --
>> PMatos

Re: Draft C bindings for IEEE 754-2008 part 4 now available

[Joseph S. Myers]

On Wed, 8 Jan 2014, Vincent Lefevre wrote:

> On 2014-01-07 16:45:49 +, Joseph S. Myers wrote:
> > Sure, such a correctly rounded function is useful just like correctly 
> > rounded versions of other functions.  The proposed C bindings reserve cr* 
> > names *only* for the specific functions listed in 9.2 where IEEE 754 
> > recommends correctly rounded functions, not for other existing ISO C 
> > functions (e.g. erf, tgamma) or functions added by the C bindings by 
> > analogy with other IEEE 754 functions (e.g. tanpi), but I think correctly 
> > rounded versions of other functions (with the same naming convention) 
> > could reasonably be added to glibc if anyone wishes to implement them.
> 
> New CR functions may be added in future revisions of IEEE 754, so
> that I think that cr* names should be reserved for all functions.

I advise making such suggestions direct to WG14.  (I don't know if such 
names should be reserved for correctly rounded complex arithmetic as well 
- where ordinary complex multiplication and division are not expected to 
be correctly rounded at present.)

(I'm currently chasing up possible issues with mail from some people not 
getting through to the WG14 list - the only floating-point TS comments 
I've seen there so far are mine and Paul Eggert's, so if anyone else 
reading this discussion has sent comments on the drafts, please let me 
know.)

-- 
Joseph S. Myers
jos...@codesourcery.com

gcc 4.8.2 online docs broken

[Ryan Mansfield]

A number of the links in 4.8.2 docs are broken (trunk seem to be OK).

http://gcc.gnu.org/onlinedocs/4.8.2/gcc/ has 404s for the following:

http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options
http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/IA-64-Options.html#IA-64-Options
http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/PDP-11-Options.html#PDP-11-Options
http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/TILE-Gx-Options.html#TILE-Gx-Options
http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Conditionally-supported-behavior.html#Conditionally-supported-behavior

The w3c validator page says there's 54 broken links. It looks like 
anything with a "-" in the URL is affected.


Regards,

Ryan Mansfield

libcpp get previous directive

[Prathamesh Kulkarni]

Hi, is there a way in libcpp, to figure out the previous directive
that was parsed correctly ? I guess the current directive being parsed
is stored in cpp_reader.directive by run_directive() /
_cpp_handle_directive(), but wasn't able to figure out for previous
directive(s). Shall I need to explicitly store the previous directive,
or is this done by libcpp ?

In case I require to explicitly store the previous directive,
is following the correct way to do it: ?

in end_directive():
/* Restore state.  */
  pfile->state.save_comments = ! CPP_OPTION (pfile, discard_comments);
  pfile->state.in_directive = 0;
  pfile->state.in_expression = 0;
  pfile->state.angled_headers = 0;
  pfile->prev_directive = pfile->directive; // here
  pfile->directive = 0;

I thought it better to add a member const cpp_hashnode *prev_directive
to cpp_reader, instead of creating a file-scope variable. Or should I
rather have file-scoped (in directives.c) prev_directive instead (if
modification to cpp_reader is not justified for this use case) ?

Thanks and Regards,
Prathamesh

RE: Infinite number of iterations in loop [v850, mep]

[Paulo Matos]

> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 08 January 2014 11:03
> To: Paulo Matos
> Cc: Andrew Haley; gcc@gcc.gnu.org
> Subject: Re: Infinite number of iterations in loop [v850, mep]
> 
> That was refering to the case with extern b.  For the above case the
> issue must be sth else.  Trying a cross to v850-elf to see if it
> reproduces for me (if 'b' is a stack or argument slot then we might
> bogously think that *c++ = 0 may clobber it, otherwise RTL
> number of iteration analysis might just be confused).
> 
> So for example (should be arch independent)
> 
> struct X { int i; int j; int k; int l[24]; };
> 
> int foo (struct X x, int *p)
> {
>   int z = x.j;
>   *p = 1;
>   return z;
> }
> 
> see if there is a anti-dependence between x.j and *p on the RTL side
> (at least the code dispatching to the tree oracle using the MEM_EXPRs
> should save you from that).
> 
> So - v850 at least doesn't pass b in memory and the doloop recognition
> works for me (on trunk).
> 

You are right, everything is fine with the above example regarding the 
anti-dependence and with the loop as well. I got confused with mine not 
generating a loop for 
void fn1 (unsigned int b)
{
  unsigned int a;
  for (a = 0; a < b; a++)
*c++ = 0;
}

but that simply because in our case it is not profitable.

However, for the case:
void matrix_add_const(unsigned int N, short *A, short val) {
 unsigned int i,j;
 for (i=0; i Richard.
> 
> > The same situation occurs with a coremark function:
> > void matrix_add_const(ee_u32 N, MATDAT *A, MATDAT val) {
> >  ee_u32 i,j;
> >  for (i=0; i >   for (j=0; j >A[i*N+j] += val;
> >   }
> >  }
> > }
> >
> > It also says the inner loop might be infinite but it can't N is given as
> argument. j starts as 0, N is unsigned like N. This will loop N times. GCC 
> cannot
> possibly assume array A will overwrite the value of N in the loop. This seems
> like something is wrong in alias analysis.
> >
> >> --
> >> PMatos

Re: Infinite number of iterations in loop [v850, mep]

[Richard Biener]

On Wed, Jan 8, 2014 at 3:09 PM, Paulo Matos  wrote:
>> -Original Message-
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: 08 January 2014 11:03
>> To: Paulo Matos
>> Cc: Andrew Haley; gcc@gcc.gnu.org
>> Subject: Re: Infinite number of iterations in loop [v850, mep]
>>
>> That was refering to the case with extern b.  For the above case the
>> issue must be sth else.  Trying a cross to v850-elf to see if it
>> reproduces for me (if 'b' is a stack or argument slot then we might
>> bogously think that *c++ = 0 may clobber it, otherwise RTL
>> number of iteration analysis might just be confused).
>>
>> So for example (should be arch independent)
>>
>> struct X { int i; int j; int k; int l[24]; };
>>
>> int foo (struct X x, int *p)
>> {
>>   int z = x.j;
>>   *p = 1;
>>   return z;
>> }
>>
>> see if there is a anti-dependence between x.j and *p on the RTL side
>> (at least the code dispatching to the tree oracle using the MEM_EXPRs
>> should save you from that).
>>
>> So - v850 at least doesn't pass b in memory and the doloop recognition
>> works for me (on trunk).
>>
>
> You are right, everything is fine with the above example regarding the 
> anti-dependence and with the loop as well. I got confused with mine not 
> generating a loop for
> void fn1 (unsigned int b)
> {
>   unsigned int a;
>   for (a = 0; a < b; a++)
> *c++ = 0;
> }
>
> but that simply because in our case it is not profitable.
>
> However, for the case:
> void matrix_add_const(unsigned int N, short *A, short val) {
>  unsigned int i,j;
>  for (i=0; i   for (j=0; jA[i*N+j] += val;
>   }
>  }
> }
>
> GCC thinks for v850 and my port that the inner loop might be infinite.
> It looks like GCC is mangling the loop so much that the obviousness that the 
> inner loop is finite is lost.
>
> This however turns out to be very performance degrading. Using -fno-ivopts 
> makes generation of loops work again both in my port and v850.
> Is there a way to fine-tune ivopts besides trying to tune the costs or do you 
> reckon this is something iv-analysis should be smarter about?

Well.  We have

Loop 2 is simple:
  simple exit 5 -> 7
  infinite if: (expr_list:REG_DEP_TRUE (and:SI (reg:SI 76)
(const_int 1 [0x1]))
(nil))
  number of iterations: (lshiftrt:SI (plus:SI (minus:SI (reg:SI 68 [ D.1398 ])
(reg:SI 64 [ ivtmp___6 ]))
(const_int -2 [0xfffe]))
(const_int 1 [0x1]))
  upper bound: 2147483646
  realistic bound: -1
Doloop: Possible infinite iteration case.
Doloop: The loop is not suitable.

as we replaced the induction variable by a pointer induction with
step 2.  So this might be a very common issue for RTL loop opts,
the upper bound of the IV is 2 * N in this case, so 2 * N & 1
should be always false and thus "infinite" be optimized.

(insn 34 33 36 3 (parallel [
(set (reg:SI 76)
(plus:SI (reg/v:SI 71 [ N ])
(reg/v:SI 71 [ N ])))
(clobber (reg:CC 32 psw))
]) 21 {addsi3}
 (expr_list:REG_UNUSED (reg:CC 32 psw)
(nil)))

that doesn't look too difficult to do with the above definition.
nonzero_bits might be of use here, not sure (not my area of
expertise).

Richard.

> Paulo Matos
>
>> Richard.
>>
>> > The same situation occurs with a coremark function:
>> > void matrix_add_const(ee_u32 N, MATDAT *A, MATDAT val) {
>> >  ee_u32 i,j;
>> >  for (i=0; i> >   for (j=0; j> >A[i*N+j] += val;
>> >   }
>> >  }
>> > }
>> >
>> > It also says the inner loop might be infinite but it can't N is given as
>> argument. j starts as 0, N is unsigned like N. This will loop N times. GCC 
>> cannot
>> possibly assume array A will overwrite the value of N in the loop. This seems
>> like something is wrong in alias analysis.
>> >
>> >> --
>> >> PMatos

Re: Draft C bindings for IEEE 754-2008 part 4 now available

[Vincent Lefevre]

On 2014-01-08 13:31:40 +, Joseph S. Myers wrote:
> I advise making such suggestions direct to WG14.  (I don't know if such 
> names should be reserved for correctly rounded complex arithmetic as well 
> - where ordinary complex multiplication and division are not expected to 
> be correctly rounded at present.)
> 
> (I'm currently chasing up possible issues with mail from some people not 
> getting through to the WG14 list - the only floating-point TS comments 
> I've seen there so far are mine and Paul Eggert's, so if anyone else 
> reading this discussion has sent comments on the drafts, please let me 
> know.)

OK, I've just sent comments to the reflector.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

RE: Infinite number of iterations in loop [v850, mep]

[Paulo Matos]

> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: 08 January 2014 14:42
> To: Paulo Matos
> Cc: Andrew Haley; gcc@gcc.gnu.org; Jan Hubicka
> Subject: Re: Infinite number of iterations in loop [v850, mep]
> 
> Well.  We have
> 
> Loop 2 is simple:
>   simple exit 5 -> 7
>   infinite if: (expr_list:REG_DEP_TRUE (and:SI (reg:SI 76)
> (const_int 1 [0x1]))
> (nil))
>   number of iterations: (lshiftrt:SI (plus:SI (minus:SI (reg:SI 68 [ D.1398 ])
> (reg:SI 64 [ ivtmp___6 ]))
> (const_int -2 [0xfffe]))
> (const_int 1 [0x1]))
>   upper bound: 2147483646
>   realistic bound: -1
> Doloop: Possible infinite iteration case.
> Doloop: The loop is not suitable.
> 
> as we replaced the induction variable by a pointer induction with
> step 2.  So this might be a very common issue for RTL loop opts,
> the upper bound of the IV is 2 * N in this case, so 2 * N & 1
> should be always false and thus "infinite" be optimized.
> 
> (insn 34 33 36 3 (parallel [
> (set (reg:SI 76)
> (plus:SI (reg/v:SI 71 [ N ])
> (reg/v:SI 71 [ N ])))
> (clobber (reg:CC 32 psw))
> ]) 21 {addsi3}
>  (expr_list:REG_UNUSED (reg:CC 32 psw)
> (nil)))
> 
> that doesn't look too difficult to do with the above definition.
> nonzero_bits might be of use here, not sure (not my area of
> expertise).
> 

You're right. After having had a look at the code this looks like something to 
be added to simplify_using_initial_values.
I will try to patch it up and will post it upstream once complete for comments.

Thanks,

-- 
Paulo Matos

Re: proposal to make SIZE_TYPE more flexible

[DJ Delorie]

> I think a patch is more useful once believe feature-complete, which
> means replacing the __int128 support with the new mechanism.

One of the side-effects of taking out the existing __int128 support is
that __int128 isn't in the integer_type_kind list, so isn't a type
that is usable for constants.  This breaks int128-4.C, which assumes a
128-bit integer constant.  If I add generic support for intN types in
i_t_k[], then we'll get (for example) 20-bit constants, which might
not be what we want.  The only other option is to special-case
__int128 if we find it in the __intN list.

Thoughts?

Also, I noted a few tests check for the int128-specific error message
when the type is not supported, but as per our previous discussion,
the __int128 keyword just doesn't exist if the type isn't supported.
Do we need to discern between "not supported with these options" and
"not supported ever" ?

Re: proposal to make SIZE_TYPE more flexible

[Joseph S. Myers]

On Wed, 8 Jan 2014, DJ Delorie wrote:

> > I think a patch is more useful once believe feature-complete, which
> > means replacing the __int128 support with the new mechanism.
> 
> One of the side-effects of taking out the existing __int128 support is
> that __int128 isn't in the integer_type_kind list, so isn't a type
> that is usable for constants.  This breaks int128-4.C, which assumes a
> 128-bit integer constant.  If I add generic support for intN types in

I don't see constants in that test.

It's not possible to write constants of type __int128 anyway.  It *is* 
possible to build them up using expressions casting narrower constants to 
__int128.  If you write a constant with a large value (with or without a 
suffix) that won't fit in target intmax_t / uintmax_t (or target long / 
unsigned long for C90), then you should get a pedwarn (and some larger 
type, maybe widest_integer_literal_type_node / 
widest_unsigned_literal_type_node, will be used if available).

> i_t_k[], then we'll get (for example) 20-bit constants, which might
> not be what we want.  The only other option is to special-case
> __int128 if we find it in the __intN list.

Integer constant types should be taken from the int / long / long long 
(and unsigned variants) list.  If a constant can't fit in any type ISO C 
allows for it, then it's reasonable to go on the extended types wider than 
long long, in increasing order of size, but __int20 is never relevant for 
constants as it's always narrower than long.

> Thoughts?

It's desirable anyway to have a way of representing what might be a 
standard type from integer_type_kind, or an extended type, given that it 
would be good for macros such as SIZE_TYPE to evaluate to enumerated 
values not magic strings.  Maybe a reserved space of itk_* values just 
like reserving RID_* values?

> Also, I noted a few tests check for the int128-specific error message
> when the type is not supported, but as per our previous discussion,
> the __int128 keyword just doesn't exist if the type isn't supported.
> Do we need to discern between "not supported with these options" and
> "not supported ever" ?

I don't think there's a need to distinguish, although I don't think it 
would be particularly harmful to have an __int128 keyword present without 
a corresponding type for targets not supporting __int128, if that helps 
diagnostics, as long as nothing else special-cases __int128.

(Draft TS 18661-3 has the interesting peculiarity that the keywords 
_FloatN for N = 16, 32, 64 or >= 128 and a multiple of 32, _DecimalN for N 
>= 32 and a multiple of 32, and _Float32x, _Float64x, _Float128x, 
_Decimal64x, _Decimal128x always exist as keywords whether or not the 
corresponding types are supported.  Implementing that would I suppose 
require special checks to handle arbitrary _FloatN and _DecimalN (for 
valid N) as keywords - an infinite number of keywords - much as we handle 
_Imaginary as a keyword without otherwise implementing it.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: proposal to make SIZE_TYPE more flexible

[DJ Delorie]

> I don't see constants in that test.

// Test for int128 enums.
// { dg-do compile { target int128 } }
// { dg-options "" }

enum E {
  e1 = 0x,
  e2, e3
} e = e3;

#define SA(I,X) int a##I[(X)? 1 : -1]

SA(1, sizeof(E) == sizeof(__int128));

> Integer constant types should be taken from the int / long / long long 
> (and unsigned variants) list.  If a constant can't fit in any type ISO C 
> allows for it, then it's reasonable to go on the extended types wider than 
> long long, in increasing order of size, but __int20 is never relevant for 
> constants as it's always narrower than long.
> 
> > Thoughts?
> 
> It's desirable anyway to have a way of representing what might be a 
> standard type from integer_type_kind, or an extended type, given that it 
> would be good for macros such as SIZE_TYPE to evaluate to enumerated 
> values not magic strings.  Maybe a reserved space of itk_* values just 
> like reserving RID_* values?

It would have to be (1) sorted, and (2) kept in signed/unsigned pairs,
unless we take out the logic that uses it and replace it with
something that doesn't need that pattern.  The table exists only for
finding "smallest matching type" etc.

> I don't think there's a need to distinguish, although I don't think it 
> would be particularly harmful to have an __int128 keyword present without 
> a corresponding type for targets not supporting __int128, if that helps 
> diagnostics, as long as nothing else special-cases __int128.

So... OK if __int20 and __int128 keywords exist always (for ports that
request them, which for __int128 would be all of them), but still be
"unsupported" if for some reason the port doesn't support them because
of command line options?

Still fails with strict-volatile-bitfields

[Joey Ye]

Sandra, Bernd,

Can you take a look at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59734

It seems a siimple case still doesn't work as expected. Did I miss anything?

Thanks,
Joey