question on bitmap_set_subtract unction in pre

[Amker.Cheng]

Hi,
In PRE, function compute_antic_aux uses bitmap_set_subtract to compute
value/expression set subtraction.

The comment of bitmap_set_subtract says it subtracts all the values
and expressions contained in ORIG from DEST.

But the implementation as following
---
static bitmap_set_t
bitmap_set_subtract (bitmap_set_t dest, bitmap_set_t orig)
{
  bitmap_set_t result = bitmap_set_new ();
  bitmap_iterator bi;
  unsigned int i;

  bitmap_and_compl (&result->expressions, &dest->expressions,
&orig->expressions);

  FOR_EACH_EXPR_ID_IN_SET (result, i, bi)
{
  pre_expr expr = expression_for_id (i);
  unsigned int value_id = get_expr_value_id (expr);
  bitmap_set_bit (&result->values, value_id);
}

  return result;
}

Does it just subtract the expressions, rather than values. And It
resets values according to the resulting expression.

I am a little confused here. Any explanation?

Thanks very much.
-- 
Best Regards.

libgcc maintainer

[Zoltán Kócsi]

Who'd be the best person to contact regarding to libgcc for ARM 4T, 6M and 7M
targets?

Thanks,

Zoltan

Re: weird optimization in sin+cos, x86 backend

[James Courtier-Dutton]

Hi,

I looked at this a bit closer.
sin(1.0e22) is outside the +-2^63 range, so FPREM1 is used to bring it
inside the range.
So, I looked at FPREM1 a bit closer.

#include 
#include 

int main (void)
{
 long double x, r, m;

 x = 1.0e22;
// x = 5.26300791462049950360708478127784;  <- This is what the answer
should be give or take 2PI.
 m =  M_PIl * 2.0;
 r = remainderl(x, m);   // Utilizes FPREM1

 printf ("x = %.17Lf\n", x);
 printf ("m = %.17Lf\n", m);
 printf ("r = %.17Lf\n", r);

 return 1;
}

This outputs:
x = 100.0
m = 6.28318530717958648
r = 2.66065232182161996

But, r should be
5.26300791462049950360708478127784... or
-1.020177392559086973318201985281...
according to wolfram alpha and most arbitrary maths libs I tried.

I need to do a bit more digging, but this might point to a bug in the
cpu instruction FPREM1

Kind Regards

James

Tutorial on GCC for Parallelization

[Uday Khedker]

We are conducting a full day tutorial on GCC for Parallelization in 
conjuction with AMC PPoPP (Principles and Practices of Parallel 
Programming) being held at New Orleans from 25-29 February 2012.


Conference Website: http://dynopt.org/ppopp-2012/

More details about the tutorial can be found from the conference website
or from: http://www.cse.iitb.ac.in/grc/index.php?page=gcc-tut-ppopp.

We have been conducting workshops in India regularly. We have conducted
a tutorial earlier in France (along with CGO). This is our first tutorial 
in North America and we look forward to seeing enthusiastic participation.


Thanks and regards,

Uday Khedker.
(GCC Resource Center)

--
--
Dr. Uday Khedker
Professor
Department of Computer Science & Engg.
IIT Bombay, Powai, Mumbai 400 076, India.
email   : u...@cse.iitb.ac.in
homepage: http://www.cse.iitb.ac.in/~uday
phone   : Office - 91 (22) 2576 7717
  Res.   - 91 (22) 2576 8717, 91 (22) 2572 0288
--

Size of enum‏

[Alexandre Almeida]

What do you think about making enum types have only the size needed for the 
number of constants held?
If an enum type has 256 constants or less, for example, it needs only one byte. 
If it has between 257 and 65536 constants, in the other hand, it needs two 
bytes.
  

Re: weird optimization in sin+cos, x86 backend

[Tim Prince]

 On 02/05/2012 11:08 AM, James Courtier-Dutton wrote:

Hi,

I looked at this a bit closer.
sin(1.0e22) is outside the +-2^63 range, so FPREM1 is used to bring it
inside the range.
So, I looked at FPREM1 a bit closer.

#include
#include

int main (void)
{
  long double x, r, m;

  x = 1.0e22;
// x = 5.26300791462049950360708478127784;<- This is what the answer
should be give or take 2PI.
  m =  M_PIl * 2.0;
  r = remainderl(x, m);   // Utilizes FPREM1

  printf ("x = %.17Lf\n", x);
  printf ("m = %.17Lf\n", m);
  printf ("r = %.17Lf\n", r);

  return 1;
}

This outputs:
x = 100.0
m = 6.28318530717958648
r = 2.66065232182161996

But, r should be
5.26300791462049950360708478127784... or
-1.020177392559086973318201985281...
according to wolfram alpha and most arbitrary maths libs I tried.

I need to do a bit more digging, but this might point to a bug in the
cpu instruction FPREM1

Kind Regards

James
As I recall, the remaindering instruction was documented as using a 
66-bit rounded approximation fo PI, in case that is what you refer to.


--
Tim Prince

Re: weird optimization in sin+cos, x86 backend

[Vincent Lefevre]

On 2012-02-04 13:00:45 +0100, Andreas Schwab wrote:
> But it is indistinguishable from 10^22+pi.  So both -0.8522008497671888
> and 0.8522008497671888 are correct results, or anything inbetween.

No, 10^22 and 10^22+pi are different numbers. You are not
following the IEEE 754 model, where each input is assumed
to be exact.

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

Re: weird optimization in sin+cos, x86 backend

[Geert Bosch]

On Feb 5, 2012, at 11:08, James Courtier-Dutton wrote:

> But, r should be
> 5.26300791462049950360708478127784... or
> -1.020177392559086973318201985281...
> according to wolfram alpha and most arbitrary maths libs I tried.
> 
> I need to do a bit more digging, but this might point to a bug in the
> cpu instruction FPREM1

No, this is all as expected. The instructions are documented to use
a 66-bit approximation of Pi (really 64 bits, but the next two
happen to be 0).

Ada requires a relative error less than 2 eps for arguments in the
range - 2.0**32 .. 2.0**32, for a binary floating point type
with 64 bits of mantissa. So, he GCC Ada run time library uses 
a 150-bit or so approximation to ensure accurate argument reduction
over the required range.

Even with an approximation of Pi that is not precise enough to
guarantee a small relative error of the result, there is still
value in consistent argument reduction. For example, a point
(Sin (X), Cos (X)) should always be close to the unit circle,
regardless of the magnitude of X.

  -Geert

Re: Size of enum‏

[David Brown]

On 05/02/12 17:29, Alexandre Almeida wrote:


What do you think about making enum types have only the size needed
for the number of constants held? If an enum type has 256 constants
or less, for example, it needs only one byte. If it has between 257
and 65536 constants, in the other hand, it needs two bytes.



I think you have the wrong mailing list - this is for the development of 
the gcc compiler, not for development /using/ gcc.  You probably want 
gcc-h...@gcc.gnu.org.


I'm sure someone will correct me if my details are wrong, but my 
understanding is this:


Enum types in C are all "int" - "signed int" by default, or "unsigned 
int" if one or more elements requires the range of unsigned int, or if 
one or more has an unsigned int suffix (e.g., "1u").


Enum types in C++ can be any integer type big enough to cover the 
required range.  I think most C++ compilers use the smallest integer 
type that covers the range.


gcc has a switch "-fshort-enums" that makes the compiler use the 
smallest usable integer type for its enums, which is the effect you are 
looking for.  Be careful when mixing modules (including libraries) with 
different settings for this flag - enum types will be incompatible 
between them.

Re: [GCC steering committee] TILEPro/TILE-Gx port maintainership

[Gerald Pfeifer]

Walter,

I am happy to announce your appointment as maintainer for this port / 
these ports pending initial technical approval.  That could come from
Richard or Joseph, for example.

As part of your initial commit, please add your name to MAINTAINERS
and submit a news item for our main page as well as an entry for the
GCC 4.7 (or 4.8) release notes at htdocs/gcc-4.7/changes.html (cf.
http://gcc.gnu.org/cvs.html ).

Happy hacking!

Gerald

Re: weird optimization in sin+cos, x86 backend

[Dave Korn]

On 05/02/2012 19:01, Vincent Lefevre wrote:
> On 2012-02-04 13:00:45 +0100, Andreas Schwab wrote:
>> But it is indistinguishable from 10^22+pi.  So both -0.8522008497671888
>> and 0.8522008497671888 are correct results, or anything inbetween.
> 
> No, 10^22 and 10^22+pi are different numbers. 

  Only one of which can be represented in floating point.

  So, the gist of the argument is that FP numbers do not represent ranges;
they are a precise but sparse representation of the number line.

  It's still not a lot of use doing trig up at the top end of the FP range
where 1 ulp > 2pi.  The odds of the value that you wanted to represent
actually being representable are tiny, and hence so are the odds of getting
anything like the result you were hoping for.  But, at least identities should
work.

cheers,
  DaveK

Re: [GCC steering committee] TILEPro/TILE-Gx port maintainership

[Walter Lee]

Hi Gerald.  Great thanks!  I'll prepare the items you mentioned below.

Walter

On 2/5/2012 3:52 PM, Gerald Pfeifer wrote:
> Walter,
> 
> I am happy to announce your appointment as maintainer for this port / 
> these ports pending initial technical approval.  That could come from
> Richard or Joseph, for example.
> 
> As part of your initial commit, please add your name to MAINTAINERS
> and submit a news item for our main page as well as an entry for the
> GCC 4.7 (or 4.8) release notes at htdocs/gcc-4.7/changes.html (cf.
> http://gcc.gnu.org/cvs.html ).
> 
> Happy hacking!
> 
> Gerald

Re: Size of enum‏

[Jonathan Wakely]

2012/2/5 David Brown :
>
> Enum types in C++ can be any integer type big enough to cover the required
> range.  I think most C++ compilers use the smallest integer type that covers
> the range.

With the three C++ compilers I tried enums are int-sized for
compatiblity reasons, so that enums declared in a header file included
by C code and C++ code will agree on the type layout.

C++11 allows you to fix the underlying type of an enum, to use a specific size:

enum E : unsigned char { E1, E2 };

The syntax isn't valid in C, so there's no reason to use the same
layout as a C enum would.

Re: Size of enum‏

[James Dennett]

On Sun, Feb 5, 2012 at 12:58 PM, Jonathan Wakely  wrote:
> 2012/2/5 David Brown :
>>
>> Enum types in C++ can be any integer type big enough to cover the required
>> range.  I think most C++ compilers use the smallest integer type that covers
>> the range.
>
> With the three C++ compilers I tried enums are int-sized for
> compatiblity reasons, so that enums declared in a header file included
> by C code and C++ code will agree on the type layout.

A decade ago I dealt with at least one platform where that was not the
case (meaning that using enums had to be disallowed in header files
that defined interfaces between C and C++ code).

I don't recall whether C allows enums types to vary in size, but in
practice I've not noticed a C compiler that did.

Re: weird optimization in sin+cos, x86 backend

[Vincent Lefevre]

On 2012-02-05 20:52:39 +, Dave Korn wrote:
> On 05/02/2012 19:01, Vincent Lefevre wrote:
> > On 2012-02-04 13:00:45 +0100, Andreas Schwab wrote:
> >> But it is indistinguishable from 10^22+pi.  So both -0.8522008497671888
> >> and 0.8522008497671888 are correct results, or anything inbetween.
> > 
> > No, 10^22 and 10^22+pi are different numbers. 
> 
>   Only one of which can be represented in floating point.
> 
>   So, the gist of the argument is that FP numbers do not represent ranges;
> they are a precise but sparse representation of the number line.
> 
>   It's still not a lot of use doing trig up at the top end of the FP range
> where 1 ulp > 2pi.  The odds of the value that you wanted to represent
> actually being representable are tiny, and hence so are the odds of getting
> anything like the result you were hoping for.  But, at least identities should
> work.

Yes, but one point I'd like to make is that one may want to specify a
portable result, as for instance, one may want to perform computations
on a heterogeneous network of machines. Even on a single machine,
there may be different algorithms/implementations to evaluate some
function (e.g., compile time vs runtime, and grouped evaluations such
as with a sincos function if both sin and cos are evaluated on the
same argument). And correct rounding is the only good specification
if one wants a portable result.

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