Re: Undefined behavior or gcc is doing additional good job?

[Bin.Cheng]

On Fri, Jan 3, 2014 at 5:17 PM, Jakub Jelinek  wrote:
> On Fri, Jan 03, 2014 at 04:44:48PM +0800, Bin.Cheng wrote:
>> >> extern uint32_t __bss_start[];
>> >> extern uint32_t __data_start[];
>> >>
>> >> void Reset_Handler(void)
>> >> {
>> >>  /* Clear .bss section (initialize with zeros) */
>> >>  for (uint32_t* bss_ptr = __bss_start; bss_ptr != __data_start; 
>> >> ++bss_ptr) {
>> >>   *bss_ptr = 0;
>> >>  }
>> >> }
>> >
>> > I believe this is undefined behavior, so GCC can assume
>> > bss_ptr != __data_start is true always.  You need something like
>> Sorry for posting the premature question.  Since both __bss_start and
>> __data_start are declared as array, it seems there is no undefined
>> behavior, the check is between two pointers with same type actually,
>
> I think this has been discussed in some PR, unfortunately I can't find it.
> If it was < or <=, then it would be obvious undefined behavior, those
> comparisons can't be performed between different objects, the above is
> questionable, because you still assume that you get through pointer
> arithmetics from one object to another one, without dereference pointer
> arithmetics can be at one past last entry in the array, but whether that is
> equal to the object object is still quite problematic.
Sorry for late replying.
It seems equality operators allow two pointers to compare equal if one
pointer is a pointer to one past the end of one array object and the
other is a pointer to the start of a different array object that
happens to immediately follow the first array object in the address
space.  Then the "!=" condition can't be always true in the example.

>
>> right?  So the question remains, why GCC would clear the two lower
>> bits of " __data_start - __bss_start" then?  Am I some stupid mistake?
>
> That said, if either of __bss_start of __data_start aren't 32-bit aligned,
> then it is a clear undefined behavior, the masking of low 2 bits (doesn't
> happen on x86_64) comes from IVopts computing the end as
> ((__data_start - __bss_start) + 1) * 4 and the __data_start - __bss_start
> is exact division by 4, apparently we don't fold that back to just
> (char *) __data_start - (char *) __bss_start + 4.
Em, YES, it comes from ivopt rewriting, but, if it's not undefined
behavior, won't it be annoying (or simply wrong) for compiler to do
something not written by the code?

Thanks,
bin


-- 
Best Regards.

Re: Undefined behavior or gcc is doing additional good job?

[Jakub Jelinek]

On Tue, Jan 07, 2014 at 04:01:23PM +0800, Bin.Cheng wrote:
> Em, YES, it comes from ivopt rewriting, but, if it's not undefined
> behavior, won't it be annoying (or simply wrong) for compiler to do
> something not written by the code?

If __bss_start of __data_start aren't 32-bit aligned, then it is undefined
behavior, so it is not wrong.

Jakub

Re: Undefined behavior or gcc is doing additional good job?

[Bin.Cheng]

On Tue, Jan 7, 2014 at 4:10 PM, Jakub Jelinek  wrote:
> On Tue, Jan 07, 2014 at 04:01:23PM +0800, Bin.Cheng wrote:
>> Em, YES, it comes from ivopt rewriting, but, if it's not undefined
>> behavior, won't it be annoying (or simply wrong) for compiler to do
>> something not written by the code?
>
> If __bss_start of __data_start aren't 32-bit aligned, then it is undefined
> behavior, so it is not wrong.
I see.  Thanks for elaborating.

Thanks,
bin

-- 
Best Regards.

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

[Florian Weimer]

On 01/04/2014 07:21 PM, Joseph S. Myers wrote:


FYI: a draft set of C bindings for additional floating-point functions
from IEEE 754-2008 are now available (draft TS 18661-4):


Is there an accurate summary of IEEE 754-2008 available online?

I'm asking because IEEE 754 is widely quoted, but nobody really seems to 
know what's in it.  (It seems that some operations are allowed to be off 
by an ulp or more, for instance, which I find rather surprising.)


--
Florian Weimer / Red Hat Product Security Team

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

[Joseph S. Myers]

On Tue, 7 Jan 2014, Florian Weimer wrote:

> On 01/04/2014 07:21 PM, Joseph S. Myers wrote:
> 
> > FYI: a draft set of C bindings for additional floating-point functions
> > from IEEE 754-2008 are now available (draft TS 18661-4):
> 
> Is there an accurate summary of IEEE 754-2008 available online?

No.  It's available for purchase from IEEE, or through IEEE Xplore if you 
have a site subscription to that.  (ISO/IEC/IEEE 60559:2011 is just IEEE 
754-2008 with different cover pages / front matter.)

> I'm asking because IEEE 754 is widely quoted, but nobody really seems to know
> what's in it.  (It seems that some operations are allowed to be off by an ulp
> or more, for instance, which I find rather surprising.)

The IEEE 754 operations are corrected rounded.  However, the C bindings 
choose to provide most of the recommended operations from IEEE 754-2008 
subclause 9.2 only in versions with unspecified accuracy, and not in 
correctly rounded versions, with names being reserved for the correctly 
rounded versions but no requirement that those functions be provided.  (As 
far as I know, the state of the art on exhaustive searches for worst cases 
for correct rounding - as needed to implement correctly rounded 
transcendental functions with bounded resource use - does not make such 
searches feasible for IEEE binary128, which is a clear reason not to 
require such functions to be provided.)

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

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

[Joseph S. Myers]

On Tue, 7 Jan 2014, Joseph S. Myers wrote:

> The IEEE 754 operations are corrected rounded.  However, the C bindings 

(Except that the IEEE 754 reduction operations - subclause 9.4 - return 
"an implementation-defined approximation".  But 9.2 is "Recommended 
correctly rounded functions", e.g. exp and sin, for which the strictly 
corresponding C functions are crexp and crsin.)

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

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

[Andrew Haley]

On 01/07/2014 02:48 PM, Joseph S. Myers wrote:
> On Tue, 7 Jan 2014, Joseph S. Myers wrote:
> 
>> The IEEE 754 operations are corrected rounded.  However, the C bindings 
> 
> (Except that the IEEE 754 reduction operations - subclause 9.4 - return 
> "an implementation-defined approximation".  But 9.2 is "Recommended 
> correctly rounded functions", e.g. exp and sin, for which the strictly 
> corresponding C functions are crexp and crsin.)

Has anyone found a way to do it?  Even crlibm only provides routines
that are probably correctly rounded.  Although I'll grant you that the
probability of incorrect rounding is very low.

Andrew.

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

[Paulo Matos]

> -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.
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 --
> PMatos

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

[Vincent Lefevre]

On 2014-01-07 14:36:58 +, Joseph S. Myers wrote:
> (As far as I know, the state of the art on exhaustive searches for
> worst cases for correct rounding - as needed to implement correctly
> rounded transcendental functions with bounded resource use - does
> not make such searches feasible for IEEE binary128, which is a clear
> reason not to require such functions to be provided.)

Well, an implementation can still provide very accurate versions
(say, with a guaranteed 512 bits accuracy), and the functions will
be correctly rounded with a very high probability. In practice, the
proof of correct rounding can be obtained only with an exhaustive
search (well there is some hope to obtain a proof if the maximum
precision of the implementation is around several thousands bits).
The exhaustive search also allows one to optimize code even more.

On 2014-01-07 14:55:31 +, Andrew Haley wrote:
> On 01/07/2014 02:48 PM, Joseph S. Myers wrote:
> > On Tue, 7 Jan 2014, Joseph S. Myers wrote:
> > 
> >> The IEEE 754 operations are corrected rounded.  However, the C bindings 
> > 
> > (Except that the IEEE 754 reduction operations - subclause 9.4 - return 
> > "an implementation-defined approximation".  But 9.2 is "Recommended 
> > correctly rounded functions", e.g. exp and sin, for which the strictly 
> > corresponding C functions are crexp and crsin.)
> 
> Has anyone found a way to do it?  Even crlibm only provides routines
> that are probably correctly rounded.  Although I'll grant you that the
> probability of incorrect rounding is very low.

For some of them, this is proved. Here's a summary of the current
status:

  http://tamadiwiki.ens-lyon.fr/tamadiwiki/images/c/c1/Lefevre2013.pdf

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

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

[Joseph S. Myers]

On Tue, 7 Jan 2014, Vincent Lefevre wrote:

> For some of them, this is proved. Here's a summary of the current
> status:
> 
>   http://tamadiwiki.ens-lyon.fr/tamadiwiki/images/c/c1/Lefevre2013.pdf

Thanks for the details.  What's the current state of the art on the 
asymptotic cost of the exhaustive searches?

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

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

[Vincent Lefevre]

On 2014-01-07 14:48:01 +, Joseph S. Myers wrote:
> (Except that the IEEE 754 reduction operations - subclause 9.4 - return 
> "an implementation-defined approximation".  But 9.2 is "Recommended 
> correctly rounded functions", e.g. exp and sin, for which the strictly 
> corresponding C functions are crexp and crsin.)

Some of the reduction operations may be standardized with the
correct rounding requirement in the future IEEE 1788 standard
on interval arithmetic (even though I think that such operations
do not belong to IEEE 1788), if it passes. In any case, they
should also have their own correctly rounded version.

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

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

[Vincent Lefevre]

On 2014-01-07 16:18:48 +, Joseph S. Myers wrote:
> On Tue, 7 Jan 2014, Vincent Lefevre wrote:
> 
> > For some of them, this is proved. Here's a summary of the current
> > status:
> > 
> >   http://tamadiwiki.ens-lyon.fr/tamadiwiki/images/c/c1/Lefevre2013.pdf
> 
> Thanks for the details.  What's the current state of the art on the 
> asymptotic cost of the exhaustive searches?

The theoretical bound is O(N^(2/3+epsilon)), where N is the number
of inputs. In practice, for binary128 (N ~ 2^128), this is already
unfeasible.

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

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

[Joseph S. Myers]

On Tue, 7 Jan 2014, Vincent Lefevre wrote:

> On 2014-01-07 14:48:01 +, Joseph S. Myers wrote:
> > (Except that the IEEE 754 reduction operations - subclause 9.4 - return 
> > "an implementation-defined approximation".  But 9.2 is "Recommended 
> > correctly rounded functions", e.g. exp and sin, for which the strictly 
> > corresponding C functions are crexp and crsin.)
> 
> Some of the reduction operations may be standardized with the
> correct rounding requirement in the future IEEE 1788 standard
> on interval arithmetic (even though I think that such operations
> do not belong to IEEE 1788), if it passes. In any case, they
> should also have their own correctly rounded version.

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.

(I'd like to see GCC and glibc get full support for C99/C11 Annexes F and 
G and the TS parts 1 and 4 at least, but given the amount of work involved 
have no current plans to work on this.)

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

[ANN] Registration for C++Now 2014 is Open

[Boris Kolpackov]

Hi,

Registration is now open for the eighth annual C++Now conference
(formerly BoostCon) which will be held in Aspen, Colorado, USA, May
12th to 17th, 2014.

C++Now is a general C++ conference for C++ experts and enthusiasts.
It is not specific to any library/framework or compiler vendor and
has three tracks with presentations ranging from hands-on, practical
tutorials to advanced C++ design and development techniques. In
particular, one of the tracks is dedicated exclusively to tutorials.

Last year the conference sold out pretty quickly and we expect it to
happen again this year. As a result, we encourage anyone interested
in attending to register early. Additionally, early bird hotel
reservations end January 10th.

For more information on registering, visit:

http://cppnow.org/2014/01/2014-registration-is-open/


For early bird hotel reservations, visit:

http://cppnow.org/location/lodging/


For general information about the conference, visit:

http://cppnow.org/about/

Boris

Re: Remove spam in GCC mailing list

[Tae Wong]

GMANE replaces "@" with "  ", so that @#$* becomes "  #$*".

The wiki.documentfoundation.org site is taking too late to load.

Possible enhancement for RTL data flow?

[Bin.Cheng]

Hi,
I noticed function df_insn_rescan always deletes and re-computes
insn_info if any one of defs/uses/eq_uses/mw is verified changed by
df_insn_refs_verify, even in some passes (like fwprop), the defs are
never changed.  Could it be improved to only update the changed part
(especially we have df_refs_add_to_chains which already does such
thing)?

Thanks,
bin

-- 
Best Regards.