Re: 4.0 regression: missing debug info for global variables in C with -O2

[Paolo Bonzini]

> Yes; in fact 'main' is even superfluous.  Just compile
>
>  int var;
>
> with -S -O2 -g on gcc 3.4 and 4.0 and look at the resulting
> assembler file, the difference is quite obvious ...


Maybe this is responsible for part of PR21828?

Paolo

Re: Sine and Cosine Accuracy

[Andrew Haley]

chris jefferson writes:
 > Scott Robert Ladd wrote:
 > 
 > >Marc Espie wrote:
 > >  
 > >
 > >>Heck, I can plot trajectories on a sphere that do not follow great circles,
 > >>and that extend over 360 degrees in longitude.  I don't see why I should be
 > >>restricted from doing that.
 > >>
 > >>
 > >
 > >Can you show me a circumstance where sin(x - 2 * pi) and sin(x + 2 * pi)
 > >are not equal to sin(x)?
 > >
 > >Using an earlier example in these threads, do you deny that
 > >sin(pow(2.0,90.0)) == sin(5.15314063427653548) ==
 > >sin(-1.130044672903051) -- assuming no use of
 > >-funsafe-math-optimizations, of course?
 > >
 > >  
 > >
 > I would like to say yes, I disagree that this should be true. By your 
 > argument, why isn't sin(pow(2.0,90.0)+1) == sin(6.153104..)? Also, how 
 > the heck do you intend to actually calculate that value? You can't just 
 > keep subtracting multiples of 2*pi from pow(2.0, 90.0) else nothing will 
 > happen,

Actually you can, and this is how real floating-point packages work.  

Rether than speculate how things _might_ work, I invite you to have a
look at glibc sysdeps/ieee754/dbl-64/sincos32.c.  Accurate techniques
for range reduction are quite well-known, and this list is not an
appropriate place for tutorials on floating-point arithmetic.

Andrew.

Re: Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

[Geert Bosch]

On May 30, 2005, at 16:50, Florian Weimer wrote:


I'll try to phrase it differently: If you access an object whose bit
pattern does not represent a value in the range given by
TYPE_MIN_VALUE .. TYPE_MAX_VALUE of the corresponding type, does this
result in erroneous execution/undefined behavior?  If not, what is the
exact behavior WRT to out-of-bounds values?



This is correct. Note that this is only valid for objects,
in expressions intermediate values may lay outside the range
of the type.

Re: Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

[Richard Kenner]

This is correct. Note that this is only valid for objects, in
expressions intermediate values may lay outside the range of the type.

The question was about expressions, not objects, and I disagree with you:
intermediate values may not lay outside the range of the type.  Gimplification
changes expressions to objects, so if what you claim were true, you
could never use the type range values to deduce anything.

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Vincent Lefevre]

On 2005-05-30 16:12:07 -0400, Robert Dewar wrote:
> Haren Visavadia wrote:
> >--- Robert Dewar wrote:
> 
> >I would expect the seem behaviour for both cases.
> 
> why? You have some inaccurate model of computation,
> which in the absence of switches, is not guaranteed.
> Floating-point semantics are indeed tricky.

According to 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2, the assert should
not fail (unless the division yields a NaN, but that would be a very
bad implementation anyway).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

chris jefferson wrote:
> I would like to say yes, I disagree that this should be true. By your
> argument, why isn't sin(pow(2.0,90.0)+1) == sin(6.153104..)? Also, how
> the heck do you intend to actually calculate that value? You can't just
> keep subtracting multiples of 2*pi from pow(2.0, 90.0) else nothing will
> happen, and if you choose to subtract some large multiple of 2*pi, your
> answer wouldn't end up accurate to anywhere near that many decimal
> places. Floating point numbers approximate real numbers, and at the size
> you are considering, the approximation contains values for which sin(x)
> takes all values in the range [-1,1].

Nonsense.

Show me an example where the following function should *not* print the
same values for a and b:

void same_sines(double x)
{
double a = sin(x);
double b = sin(fmod(x, 2.0 * PI));
printf("%20.15f,%20.15f\n",a,b);
}

Granted, -funsafe-math-optimizations *will* produce different values for
certain values, such as x = pow(2.0,90.0), on x87 hardware, but that is
an error in computing a, not a violation of principle.

..Scott

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Andrew Haley]

Vincent Lefevre writes:
 > On 2005-05-30 16:12:07 -0400, Robert Dewar wrote:
 > > Haren Visavadia wrote:
 > > >--- Robert Dewar wrote:
 > > 
 > > >I would expect the seem behaviour for both cases.
 > > 
 > > why? You have some inaccurate model of computation,
 > > which in the absence of switches, is not guaranteed.
 > > Floating-point semantics are indeed tricky.
 > 
 > According to 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2, the assert should
 > not fail (unless the division yields a NaN, but that would be a very
 > bad implementation anyway).

I have read the sections you mention, and I cannot see how they imply
what you write.  Can you explain, please?

Andrew.
  

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Vincent Lefevre]

On 2005-05-30 22:18:14 +0200, Toon Moene wrote:
> Vincent Lefevre wrote:
[...]
> >First there is a bug in GCC concerning casts and assignments
> >(see ISO/IEC 9899: 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2).
> >
> >But even this were fixed, many users would still complain.
> >That's why I think that the Linux kernel should set the CPU
> >in double-precision mode, like some other OS's (MS Windows,
> >*BSD) -- but this is off-topic here.
> 
> It's not off-topic.  In fact, Jim Wilson argued this point here:
> 
> http://gcc.gnu.org/ml/gcc/2003-08/msg01282.html
> 
> "The best pragmatic solution is probably to set the rounding control
> to 64-bits,

[double precision -- 64-bits isn't correct since it's the sign +
53-bit mantissa + extended exponent range internally]

Will gcc do that?

This isn't up to the user himself to do that.

> but then we lose access to long double which some people need, 
> and we still have excess precision problems for float."

But as I said on my page, this isn't much a problem since users
who really need *extended* precision can still set the rounding
precision to extended precision; this isn't portable, but extended
precision isn't portable anyway.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: Sine and Cosine Accuracy

[Andrew Haley]

Scott Robert Ladd writes:
 > chris jefferson wrote:
 > > I would like to say yes, I disagree that this should be true. By your
 > > argument, why isn't sin(pow(2.0,90.0)+1) == sin(6.153104..)? Also, how
 > > the heck do you intend to actually calculate that value? You can't just
 > > keep subtracting multiples of 2*pi from pow(2.0, 90.0) else nothing will
 > > happen, and if you choose to subtract some large multiple of 2*pi, your
 > > answer wouldn't end up accurate to anywhere near that many decimal
 > > places. Floating point numbers approximate real numbers, and at the size
 > > you are considering, the approximation contains values for which sin(x)
 > > takes all values in the range [-1,1].
 > 
 > Nonsense.
 > 
 > Show me an example where the following function should *not* print the
 > same values for a and b:
 > 
 > void same_sines(double x)
 > {
 > double a = sin(x);
 > double b = sin(fmod(x, 2.0 * PI));
 > printf("%20.15f,%20.15f\n",a,b);
 > }

Please!  Every correct implementation of libm will not print the same
result for these two values, because it is necessary to do the range
reduction in extended precision.

Andrew.

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Andreas Schwab]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

> But as I said on my page, this isn't much a problem since users
> who really need *extended* precision can still set the rounding
> precision to extended precision; this isn't portable, but extended
> precision isn't portable anyway.

What about LDBL_* from ?

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Sine and Cosine Accuracy

[Vincent Lefevre]

On 2005-05-30 11:51:59 -0400, Scott Robert Ladd wrote:
> The fact that trigonometric functions can extended beyond 2D geometry in
> no way invalidates their use in their original domain. I've written many
> 2D and 3D applications over the years without need for a sine outside
> the range [0, 2*PI] (or [-PI, PI] in some cases). Some people live and
> die by one of those programs, and no one's died yet because I used
> -ffast-math in compiling it.

I wonder if compilers could use information for assertions.
For instance, instead of writing sin(x), you could write:

  sin((assert(x >= 0 && x <= 2 * pi), x))

possibly via a macro. IMHO, this would be better than using
switches such as -ffast-math, and you could mix small ranges
and large ranges in the same program.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Vincent Lefevre]

On 2005-05-31 13:16:55 +0100, Andrew Haley wrote:
> Vincent Lefevre writes:
>  > According to 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2, the assert should
>  > not fail (unless the division yields a NaN, but that would be a very
>  > bad implementation anyway).
> 
> I have read the sections you mention, and I cannot see how they imply
> what you write.  Can you explain, please?

Consider the example:

#include 
volatile float x = 3;
int main()
{
  float a = 1 / x;
  x = a;
  assert(a == x);
}

Concerning the line "float a = 1 / x;", 1 / x may be computed in
any extended precision, but when assigned to a, the result must
be converted to float (precision and range). Then concerning the
line "x = a;", since the type is the same, the value is unchanged.
And in the assert, a and x should have exactly the same value, so
that the comparison should return 1 (i.e., true).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Vincent Lefevre]

On 2005-05-31 14:27:01 +0200, Andreas Schwab wrote:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> > But as I said on my page, this isn't much a problem since users
> > who really need *extended* precision can still set the rounding
> > precision to extended precision; this isn't portable, but extended
> > precision isn't portable anyway.
> 
> What about LDBL_* from ?

What do you mean here?

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: 4.0 regression: missing debug info for global variables in C

[Ulrich Weigand]

Paolo Bonzini wrote:

> Maybe this is responsible for part of PR21828?

I'd say this *is* PR21828: note that the variables whose
type is unknown are global variables in C code compiled
with -O2 ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  Linux on zSeries Development
  [EMAIL PROTECTED]

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Vincent Lefevre]

On 2005-05-31 13:16:55 +0100, Andrew Haley wrote:
> Vincent Lefevre writes:
>  > According to 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2, the assert should
>  > not fail (unless the division yields a NaN, but that would be a very
>  > bad implementation anyway).
> 
> I have read the sections you mention, and I cannot see how they imply
> what you write.  Can you explain, please?

Well, concerning the first reference, it should be 5.1.2.3#12.
Concerning 6.3.1.8#2, see the footnote (52).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: 4.0 regression: missing debug info for global variables in C

[Paolo Bonzini]

Maybe this is responsible for part of PR21828?
   


I'd say this *is* PR21828: note that the variables whose
type is unknown are global variables in C code compiled
with -O2 ...
 


Oh, of course.  I was confusing with the first part:

 Run till exit from #0 mangle_macro_name ([snip]) at 
../../gcc/gengtype-lex.l:429
 yylex () at ../../gcc/gengtype-lex.l:263
 263   t = find_structure (ptr, 0);
 Value returned is $1 = 0x11ccb0 "VEC_tree"
 (gdb) p ptr
 No symbol "ptr" in current context.

where ptr is not global.  But -fno-tree-lrs or whatever the option is 
called should help with that.


I've updated PR21828 so that it does not refer to stabs.

Paolo

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Andreas Schwab]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

> On 2005-05-31 14:27:01 +0200, Andreas Schwab wrote:
>> Vincent Lefevre <[EMAIL PROTECTED]> writes:
>> > But as I said on my page, this isn't much a problem since users
>> > who really need *extended* precision can still set the rounding
>> > precision to extended precision; this isn't portable, but extended
>> > precision isn't portable anyway.
>> 
>> What about LDBL_* from ?
>
> What do you mean here?

They give you access to long double in a portable manner, but if you
change the rounding mode then the constants are no longer accurate.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Sine and Cosine Accuracy

[Paul Koning]

> "Geoffrey" == Geoffrey Keating <[EMAIL PROTECTED]> writes:

 Geoffrey> Paul Koning <[EMAIL PROTECTED]> writes:
 >> After some off-line exchanges with Dave Korn, it seems to me that
 >> part of the problem is that the documentation for
 >> -funsafe-math-optimizations is so vague as to have no discernable
 >> meaning.

 Geoffrey> I believe that (b) is intended to include:

 Geoffrey> ... - limited ranges of elementary functions

You mean limited range or limited domain?  The x87 discussion suggests
limiting the domain.  And "limited" how far?  Scott likes 0 to 2pi;
equally sensibly one might recommend -pi to +pi.

All these things may well make sense, but few or none of them are
implied by the text of the documentation.

 paul

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Vincent Lefevre]

On 2005-05-31 15:33:48 +0200, Andreas Schwab wrote:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> > On 2005-05-31 14:27:01 +0200, Andreas Schwab wrote:
> >> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> >> > But as I said on my page, this isn't much a problem since users
> >> > who really need *extended* precision can still set the rounding
> >> > precision to extended precision; this isn't portable, but extended
> >> > precision isn't portable anyway.
> >> 
> >> What about LDBL_* from ?
> >
> > What do you mean here?
> 
> They give you access to long double in a portable manner,

No, this is not portable, since if extended precision is necessary to
get correct results for some application, the same application run on
PowerPC, where there is no extended precision, would give incorrect
results.

> but if you change the rounding mode then the constants are no longer
> accurate.

The implementation could provide another way to get the necessary
information; perhaps nextafterl()...

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

GCC Compiler

[Thomas Bernard]

Dear Sir,

My name is Thomas Bernard. I am working as a Master Student for the UvA 
(Universitat Van Amsterdam) in the section of Computers Systems 
Architecture of the Informatics Institute.


I am doing a study about compilers. I have to monitor many existing 
compilers and benchmark them. After I have to modify and optimize the 
'back-end' part for multithreads models.


I have found your works and I would like to have more informations about 
the IR (Intermediate Representation) during the compilation. For 
example, if a file containing the IR is created during the compilation.

If there is another way,I would like to know how can I access the IR.
Is it easy to modify? etc...

If you can give me some documents about your IR (and RTL, Back-End).


Best wishes,
Thomas Bernard
--

=
Thomas Bernard

Section of Computer Systems Architecture
Universiteit van Amsterdam
Informatics Institute
Kruislaan 403
1098 SJ Amsterdam
Room F.221

E-Mail: [EMAIL PROTECTED]
Cell Phone : +33 6 18 22 67 83
=

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Andreas Schwab]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

> On 2005-05-31 15:33:48 +0200, Andreas Schwab wrote:
>> Vincent Lefevre <[EMAIL PROTECTED]> writes:
>> > On 2005-05-31 14:27:01 +0200, Andreas Schwab wrote:
>> >> Vincent Lefevre <[EMAIL PROTECTED]> writes:
>> >> > But as I said on my page, this isn't much a problem since users
>> >> > who really need *extended* precision can still set the rounding
>> >> > precision to extended precision; this isn't portable, but extended
>> >> > precision isn't portable anyway.
>> >> 
>> >> What about LDBL_* from ?
>> >
>> > What do you mean here?
>> 
>> They give you access to long double in a portable manner,
>
> No, this is not portable,

Sure they are, since they are required since C89.

> since if extended precision is necessary to get correct results for some
> application, the same application run on PowerPC, where there is no
> extended precision, would give incorrect results.

You can use  to find that out.  That's what portability is about.

>> but if you change the rounding mode then the constants are no longer
>> accurate.
>
> The implementation could provide another way to get the necessary
> information; perhaps nextafterl()...

But you still have to take care of (1.0 + LDBL_EPSILON) != 1.0, or the
other required identities in .

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: GCC Compiler

[sjhill]

> I am doing a study about compilers. I have to monitor many existing 
> compilers and benchmark them. After I have to modify and optimize the 
> 'back-end' part for multithreads models.
> 
You should go look at Scott's site (http://www.coyotegulch.com/) as he
does a lot of benchmarking.

> I have found your works and I would like to have more informations about 
> the IR (Intermediate Representation) during the compilation. For 
> example, if a file containing the IR is created during the compilation.
> If there is another way,I would like to know how can I access the IR.
> Is it easy to modify? etc...
> 
> If you can give me some documents about your IR (and RTL, Back-End).
> 
RTFM. In all seriousness, you go to the main GCC page (http://gcc.gnu.org)
and look in the documentation sections. Some good starting places are:

   http://gcc.gnu.org/wiki
   http://gcc.gnu.org/readings.html

When you have read all of that, then come back and ask some more
questions. Cheers.

-Steve

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Scott Robert Ladd]

Andreas Schwab wrote:
>> No, this is not portable,
> 
> Sure they are, since they are required since C89.
> 
> You can use  to find that out.  That's what portability is
> about.

"Portability" means different things to different people. There's a
difference between source code portability and "result" portability.

If you follow Standard C, you are guaranteed source code portability, in
the program compiles and produce the "same" results with any Standard C
compiler.

When we start talking about floating-point code, however, we enter the
realm of "result" portability, in that different platforms (or different
compiler swicthes) return slightly different numbers from the same
source code.

An example of this is the use of long double, the implementation of
which differs from platform to platform. On Intel-inspired processors, a
long double is 80 bits long with a 64-bit mantissa, corresponding to the
x87 registers. On other systems, long double may be the same as double,
having 64 bits and a 53-bit mantissa. Calculations with 80-bit long
doubles will differ from the same computations performed using 64-bit
long doubles.

C does not enforce identical results on all platforms; Java does (or at
least tries to).

It's an easy problem to get tripped by, as I recently experienced on
this forum.

..Scott

Re: GCSE considers read only memory clobbered by function calls.

[Jeffrey A Law]

On Mon, 2005-05-23 at 10:47 +0300, Mostafa Hagog wrote:
> 
> 
> 
> 
> Jeffrey A Law <[EMAIL PROTECTED]> wrote on 09/05/2005 18:17:45:
> 
> > Yes, it looks quite reasonable.  Please go ahead with the full testing
> > cycle and consider the patch pre-approved once complete.
> >
> I have changed the patch according to some feedbacks that I have got -- the
> main idea didn't change. One change is to check the MEM_READONLY_P flag
> also in load_killed_in_block. The new patch is attached below. bootstrap
> passed (with -O2 -g -fgcse -fgcse-las --param max-gcse-passes=3) and no new
> regressions on powerpc-apple-darwin.
> 
> Since I have changed the patch a bit I am asking again for approval to
> commit.
> 
> 2005-05-23 Mostafa Hagog <[EMAIL PROTECTED]>
> 
>   * gcse.c (compute_transp, load_killed_in_block): use MEM_READONLY_P.
This is fine.  Please install.

Thanks,
Jeff

FYI: Upgrading sourceware mysql to 4.x

[Daniel Berlin]

At approximately 2pm EST, we will be upgrading mysql on sourceware from
version 3.x to version 4.x.

This will cause a short amount of downtime in gcc.gnu.org and
sources.redhat.com Bugzilla and GCC's wiki  (< 30 minutes).


--Dan

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Andreas Schwab]

Scott Robert Ladd <[EMAIL PROTECTED]> writes:

> Andreas Schwab wrote:
>>> No, this is not portable,
>> 
>> Sure they are, since they are required since C89.
>> 
>> You can use  to find that out.  That's what portability is
>> about.
>
> "Portability" means different things to different people. There's a
> difference between source code portability and "result" portability.

But making round to double the default makes it only worse in this case,
since there is no portable way to change the rounding precision.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Hello,Gnu

[dk zhou]

I want to use gcc to compile program for windows,how
can i get it?






 thank you!

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Hello,Gnu

[Jonathan Wakely]

On Tue, May 31, 2005 at 08:58:14AM -0700, dk zhou wrote:

> I want to use gcc to compile program for windows,how
> can i get it?

http://www.google.com/search?hl=en&lr=&q=%22gcc+for+windows%22&btnG=Search

you probably want MinGW

jon

RE: What is wrong with Bugzilla?

[Dave Korn]

Original Message
>From: Russ Allbery
>Sent: 31 May 2005 04:51


> It's not the request for the e-mail address.  It's that it's phrased as a
> login screen and a button to create an account.  I know that I definitely
> pause and consider before I create an account at a web site.  There are
> many on-line newspapers that I refuse to read articles from, for example,
> because I don't want to create an account.  That creates a piece of
> authorization out there that I have to record a password for and that I'm
> to some degree responsible for.


  Whenever I come across one of those interfaces, I test it to see if it'll
let me create an account called 'guest' with password 'guest'.  (I believe
in keeping the old net.traditions alive!)  If it wants an email address, I
use '[EMAIL PROTECTED]'. 


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

RE: What is wrong with Bugzilla?

[Daniel Berlin]

On Tue, 2005-05-31 at 17:52 +0100, Dave Korn wrote:
> Original Message
> >From: Russ Allbery
> >Sent: 31 May 2005 04:51
> 
> 
> > It's not the request for the e-mail address.  It's that it's phrased as a
> > login screen and a button to create an account.  I know that I definitely
> > pause and consider before I create an account at a web site.  There are
> > many on-line newspapers that I refuse to read articles from, for example,
> > because I don't want to create an account.  That creates a piece of
> > authorization out there that I have to record a password for and that I'm
> > to some degree responsible for.
> 
> 
>   Whenever I come across one of those interfaces, I test it to see if it'll
> let me create an account called 'guest' with password 'guest'.  (I believe
> in keeping the old net.traditions alive!)  If it wants an email address, I
> use '[EMAIL PROTECTED]'. 


And then if we need more info for your bug report, and can't reach you,
we'll simply close it.

RE: Hello,Gnu

[Dave Korn]

Original Message
>From: Jonathan Wakely
>Sent: 31 May 2005 17:06

> On Tue, May 31, 2005 at 08:58:14AM -0700, dk zhou wrote:
> 
>> I want to use gcc to compile program for windows,how
>> can i get it?
> 
> http://www.google.com/search?hl=en&lr=&q=%22gcc+for+windows%22&btnG=Search
> 
> you probably want MinGW
> 
> jon


  Or perhaps Cygwin:  http://cygwin.com/, which provides gcc *and* a full
Unix/Linux-alike environent for Windows, with all the usual GNU/Linux shells
and command-line tools.

  Of the two, MinGW is probably a better match for those who want to write
native Windows programs using gcc; Cygwin is probably the better choice for
those who want to work with portable open source and POSIX-compatible
software on Windows.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Mike Stump]

On Tuesday, May 31, 2005, at 06:43  AM, Vincent Lefevre wrote:

No, this is not portable, since if extended precision is necessary to
get correct results for some application, the same application run on
PowerPC, where there is no extended precision


?  News to me!  Ok, who removed it?  Speak up now, or we're going to 
send the firing squad.

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Hugh Sasse]

On Sun, 29 May 2005, Ross Smith wrote:


On Sunday, 29 May 2005 03:17, Uros Bizjak wrote:


There is no problem that Bugzilla is un-intuitive, it is far from
that. The users don't fill bugreports because they are afraid of
filling an invalid report or a duplicate.


I strongly suspect you're mistaken about the reason.


Well, the site is pretty stern about searching first :-)  Which is
fair enough for the usual internet-culture (RTFM, STFW) reasons.



Is perhaps some kind of anonymous account needed (as in Slashdot's
case) to encourage these users to fill bugreports?


I think this is probably the real showstopper. [...]

Whenever I see something like "we need a valid email address" on a
corporate web site, I always take it for granted that it's because they
want to spam me. [...]


I don't think this is entirely the problem, however.  That recaction
is reasonable nowadays, but I think there are textual improvements
that could help.

It's an oft-quoted idea in teaching that you tell people what you
are going to tell them, then you tell them it, then you tell them
what you have told them.  I think the bugzilla site could be
improved by explaining the process a bit more:

 * How will your email address be used?
 * Who will actually see it?  Does it get shrouded, at all?
 * Will the system send you alerts of changes?
 * Do you have any control over the kinds of alerts you get?
 * Is there a person/group/list you can talk to about our
   bugzilla culture if the information here is insufficient?

Then there might be information such as

 * What will affect the time it takes to fix your bug?
 * Is there a normal lifecycle for bug reports, so you know how
   far your bug has progessed?
 * Any terminology you should be aware of (such as PR)?

If this information is available I think it could be made more
obvious, so that you pass through/close by it when reaching the page
where you make the account.


There has been an assertion that GCC is for developers, and the
sites reflect this.  Well, I'd like to challange that.  Many
packages (and I think among them are, or were,  Exim, Python, Perl
and Ruby) are designed to work best when built with GCC, and if you
have problems you are often advised to try with (the latest?) GCC.  Given
that many OS vendors don't supply a compiler now, it maybe that many
people experiencing problems are not familiar with GCC develpment,
and may not consider themselves familiar with modern C.  They may be
finding bugs (or only perceived bugs) when using GCC to get
somewhere else.  Obviously friendliness for developers is important,
but I don't helieve it covers everyone.

So, to conclude, I don't think there is much wrong with Bugzilla,
but that it could benefit from managing people's expectations of it, 
by supplying such information up front.


Hope this helps
Hugh

RE: What is wrong with Bugzilla?

[Dave Korn]

Original Message
>From: Daniel Berlin
>Sent: 31 May 2005 18:00

> On Tue, 2005-05-31 at 17:52 +0100, Dave Korn wrote:

>> Original Message
>>> From: Russ Allbery
>>> Sent: 31 May 2005 04:51

>>> There are many on-line newspapers that I refuse to read articles from,
>>> for example, because I don't want to create an account.  That creates a
>>> piece of authorization out there that I have to record a password for
>>> and that I'm to some degree responsible for.

>>   Whenever I come across one of those interfaces, I test it to see if
>> it'll let me create an account called 'guest' with password 'guest'.  (I
>> believe in keeping the old net.traditions alive!)  If it wants an email
>> address, I use '[EMAIL PROTECTED]'.

> And then if we need more info for your bug report, and can't reach you,
> we'll simply close it.

  Oh, really?  

  At precisely *which* on-line newspaper site do you expect to find me
entering gcc bug reports?









   :-P

  Heh, I admit that was a bit O-T; I wasn't recommending that solution for a
situation where you actually _want_ to get in touch with someone, but just
for the general 'I can't read the article on this newspaper's site without
registering' case.

  For bugzilla I use my real email address, because of course if I report a
bug I want to hear back about it.

  I had an even stupider version of this whole debate a little while ago on
IIRC the binutils mailing list, where someone refused to enter a bug report
into bugzilla because it was going to set a cookie and they thought that it
was somehow sinister.  I'm all in favour of people being informed, and
closely guarding their privacy rights, but ranting and raving because you
think a cookie is some kind of evil demon that will magically spy on you is
the sign of a paranoid conspiracy loon, not a keen eye for privacy
violations.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

RE: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Dave Korn]

Original Message
>From: Mike Stump
>Sent: 31 May 2005 17:57

> On Tuesday, May 31, 2005, at 06:43  AM, Vincent Lefevre wrote:
>> No, this is not portable, since if extended precision is necessary to
>> get correct results for some application, the same application run on
>> PowerPC, where there is no extended precision
> 
> ?  News to me!  Ok, who removed it?  

  It fell off and dropped down the back of the sofa!  There's always lots of
bits down there!

> Speak up now, or we're going to send the firing squad.

  Just don't let them use x87 intrinsics to calculate the line of fire, or
we'd all better run!


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Vincent Lefevre]

On 2005-05-31 16:07:53 +0200, Andreas Schwab wrote:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> 
> > On 2005-05-31 15:33:48 +0200, Andreas Schwab wrote:
> >> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> >> > On 2005-05-31 14:27:01 +0200, Andreas Schwab wrote:
> >> >> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> >> >> > But as I said on my page, this isn't much a problem since users
> >> >> > who really need *extended* precision can still set the rounding
> >> >> > precision to extended precision; this isn't portable, but extended
> >> >> > precision isn't portable anyway.
> >> >> 
> >> >> What about LDBL_* from ?
> >> >
> >> > What do you mean here?
> >> 
> >> They give you access to long double in a portable manner,
> >
> > No, this is not portable,
> 
> Sure they are, since they are required since C89.

The "long double" type is required, but it is not required to be
extended precision.

> > since if extended precision is necessary to get correct results
> > for some application, the same application run on PowerPC, where
> > there is no extended precision, would give incorrect results.
> 
> You can use  to find that out. That's what portability is
> about.

No, this is not sufficient.

> >> but if you change the rounding mode then the constants are no longer
> >> accurate.
> >
> > The implementation could provide another way to get the necessary
> > information; perhaps nextafterl()...
> 
> But you still have to take care of (1.0 + LDBL_EPSILON) != 1.0, or the
> other required identities in .

Once you change the rounding precision, this is no longer required,
since you are already working with an extension.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Vincent Lefevre]

On 2005-05-31 10:30:52 -0400, Scott Robert Ladd wrote:
> If you follow Standard C, you are guaranteed source code portability, in
> the program compiles and produce the "same" results with any Standard C
> compiler.
> 
> When we start talking about floating-point code, however, we enter the
> realm of "result" portability, in that different platforms (or different
> compiler swicthes) return slightly different numbers from the same
> source code.

This is not much different from integer arithmetic. Standard types
such as int may have different sizes on different platforms.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Vincent Lefevre]

On 2005-05-31 17:10:58 +0200, Andreas Schwab wrote:
> Scott Robert Ladd <[EMAIL PROTECTED]> writes:
> > "Portability" means different things to different people. There's a
> > difference between source code portability and "result" portability.
> 
> But making round to double the default makes it only worse in this case,
> since there is no portable way to change the rounding precision.

No, if the goal is to be portable with various platforms, you need
to round to double by default, since single precision (almost no
longer used for FP computations) and double precision are the only
standard precisions in IEEE 754.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

RE: What is wrong with Bugzilla?

[Daniel Berlin]

On Tue, 2005-05-31 at 18:12 +0100, Dave Korn wrote:
> Original Message
> >From: Daniel Berlin
> >Sent: 31 May 2005 18:00
> 
> > On Tue, 2005-05-31 at 17:52 +0100, Dave Korn wrote:
> 
> >> Original Message
> >>> From: Russ Allbery
> >>> Sent: 31 May 2005 04:51
> 
> >>> There are many on-line newspapers that I refuse to read articles from,
> >>> for example, because I don't want to create an account.  That creates a
> >>> piece of authorization out there that I have to record a password for
> >>> and that I'm to some degree responsible for.
> 
> >>   Whenever I come across one of those interfaces, I test it to see if
> >> it'll let me create an account called 'guest' with password 'guest'.  (I
> >> believe in keeping the old net.traditions alive!)  If it wants an email
> >> address, I use '[EMAIL PROTECTED]'.
> 
> > And then if we need more info for your bug report, and can't reach you,
> > we'll simply close it.
> 
>   Oh, really?  


>   At precisely *which* on-line newspaper site do you expect to find me
> entering gcc bug reports?
I thought you were generalizing "those interfaces" to include bugzilla,
which was the original topic of discussion :)

>   I had an even stupider version of this whole debate a little while ago on
> IIRC the binutils mailing list, where someone refused to enter a bug report
> into bugzilla because it was going to set a cookie and they thought that it
> was somehow sinister. 

It's completely sinister.
We store all your info in there including YOUR QUERY SORT ORDER!

:)

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Vincent Lefevre]

On 2005-05-31 09:56:31 -0700, Mike Stump wrote:
> On Tuesday, May 31, 2005, at 06:43  AM, Vincent Lefevre wrote:
> >No, this is not portable, since if extended precision is necessary to
> >get correct results for some application, the same application run on
> >PowerPC, where there is no extended precision
> 
> ?  News to me!  Ok, who removed it?  Speak up now, or we're going to 
> send the firing squad.

Well, there is no extended precision with GCC under Linux/PPC.
And according to

http://developer.apple.com/documentation/mac/PPCNumerics/PPCNumerics-14.html

(found with Google), the PowerPC doesn't have hardware support
for extended precision.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Jakub Jelinek]

On Tue, May 31, 2005 at 07:20:49PM +0200, Vincent Lefevre wrote:
> On 2005-05-31 17:10:58 +0200, Andreas Schwab wrote:
> > Scott Robert Ladd <[EMAIL PROTECTED]> writes:
> > > "Portability" means different things to different people. There's a
> > > difference between source code portability and "result" portability.
> > 
> > But making round to double the default makes it only worse in this case,
> > since there is no portable way to change the rounding precision.
> 
> No, if the goal is to be portable with various platforms, you need
> to round to double by default, since single precision (almost no
> longer used for FP computations) and double precision are the only
> standard precisions in IEEE 754.

IEEE 754 is not mandated by the ISO C{90,99} standards and there are indeed
platforms where float and double are not using IEEE 754 single resp. double
precision formats.

Jakub

RE: What is wrong with Bugzilla?

[Dave Korn]

Original Message
>From: Daniel Berlin
>Sent: 31 May 2005 18:22

> On Tue, 2005-05-31 at 18:12 +0100, Dave Korn wrote:

> 
>>   I had an even stupider version of this whole debate a little while ago
>> on IIRC the binutils mailing list, where someone refused to enter a bug
>> report into bugzilla because it was going to set a cookie and they
>> thought that it was somehow sinister.
> 
> It's completely sinister.
> We store all your info in there including YOUR QUERY SORT ORDER!
> 
> :)



  HAH!  That's just what they WANT you to think!!!1



cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Your Resume for the position of Business Analyst

[InactiveJob]

The Business Analyst position in Milwaukee, WI that you applied for was
only recently inactivated.

Please return to Dice and apply for a different position posted by
Genesis10, and we will immediately review your resume.

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Mike Stump]

On May 31, 2005, at 10:25 AM, Vincent Lefevre wrote:

Well, there is no extended precision with GCC under Linux/PPC.


Hum, I do wonder about even that; why do:

2004-02-07  Alan Modra  <[EMAIL PROTECTED]>

* config/rs6000/t-linux64 (LIB2FUNCS_EXTRA): Add darwin- 
ldouble.c.


powerpc64-*-linux*)
tm_file="${tm_file} dbxelf.h elfos.h svr4.h freebsd-spec.h  
rs6000/sysv4.h"

test x$with_cpu != x || cpu_is_64bit=yes
test x$cpu_is_64bit != xyes || tm_file="${tm_file} rs6000/ 
default64.h"

tm_file="rs6000/biarch64.h ${tm_file} rs6000/linux64.h"
extra_options="${extra_options} rs6000/sysv4.opt rs6000/ 
linux64.opt"
tmake_file="rs6000/t-fprules ${tmake_file} rs6000/t-ppccomm  
rs6000/t-linux64"


t-linux64:

LIB2FUNCS_EXTRA = tramp.S $(srcdir)/config/rs6000/ppc64-fp.c \
$(srcdir)/config/rs6000/darwin-ldouble.c

darwin-ldouble.c:
/* 128-bit long double support routines for Darwin.

then?  Certainly, the intent was to push it closer to working.  I  
don't see why someone could not finish off the compiler bits fairly  
quickly, if they wanted to.



And according to
http://developer.apple.com/documentation/mac/PPCNumerics/ 
PPCNumerics-14.html

(found with Google), the PowerPC doesn't have hardware support
for extended precision.


I don't see the relevance, not to the question of can long double be  
used under linux, nor even can long double be used under OSX, nor  
long double on ppc.

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Andreas Schwab]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

> The "long double" type is required, but it is not required to be
> extended precision.

But it can be.

> Once you change the rounding precision, this is no longer required,
> since you are already working with an extension.

The use of long double is not an extension.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

RFA: Fix PR21767 (Was: Re: RFD: what to do about stale REG_EQUAL notes in dead_or_predictable)

[Joern RENNECKE]

I've tried removing REG_EQUAL notes altogether unless we
know that the source of the move is function invariant, and got
identical assembler for all the EEMBC tests as without the patch.
Likewise for an entire sh4-elf multilibbed libgcc, libstdc++-v3
and newlib build.   I think it is therefore reasonable to assume
that removing the notes doesn't cause any relevant performance
loss.  For a 3.4 based compiler, that was just a small ifcvt.c
patch; for 4.x, I also had to reinstate function_invariant_p  as
a global function.

I can't do an i686-pc-linux-gnu bootstrap at the moment because
the bootstrap fails building libjava, both with unpatched sources
from 12:00 and 16:00 UTC.  I'll do a bootstrap / regression test
of the patch when we are back in bootstrap land.

FWIW, this is the failure:
./../.././gcc/gcjh -classpath '' -bootclasspath . 
java/lang/AbstractMethodError

make[2]: *** [java/lang/AbstractMethodError.h] Segmentation fault
make[2]: *** Deleting file `java/lang/AbstractMethodError.h'
make[2]: Leaving directory 
`/mnt/scratch/nightly/2005-05-31/i686/i686-pc-linux-gnu/libjava'


AFAICS, jcf-io.c:format_uint is miscompiled, base is not handed as
second parameter to umoddi, it uses the saved values of esi/edi
instead.
  
2005-05-27  J"orn Rennecke <[EMAIL PROTECTED]>

* rtl.h (function_invariant_p): Re-add declaration.
* reload1.c (function_invariant_p): No longer static.
* ifcvt.c (dead_or_predicable): Remove REG_EQUAL notes that
might have become invalid.

Index: rtl.h
===
RCS file: /cvs/gcc/gcc/gcc/rtl.h,v
retrieving revision 1.550
diff -p -r1.550 rtl.h
*** rtl.h   19 May 2005 10:38:38 -  1.550
--- rtl.h   31 May 2005 18:11:39 -
*** extern void dbr_schedule (rtx, FILE *);
*** 2062,2067 
--- 2062,2070 
  extern void dump_local_alloc (FILE *);
  extern int local_alloc (void);
  
+ /* In reload1.c */
+ extern int function_invariant_p (rtx);
+ 
  /* In reg-stack.c */
  extern bool reg_to_stack (FILE *);
  
Index: reload1.c
===
RCS file: /cvs/gcc/gcc/gcc/reload1.c,v
retrieving revision 1.471
diff -p -r1.471 reload1.c
*** reload1.c   26 May 2005 05:44:38 -  1.471
--- reload1.c   31 May 2005 18:11:39 -
*** static int reload_reg_free_for_value_p (
*** 405,411 
rtx, rtx, int, int);
  static int free_for_value_p (int, enum machine_mode, int, enum reload_type,
 rtx, rtx, int, int);
- static int function_invariant_p (rtx);
  static int reload_reg_reaches_end_p (unsigned int, int, enum reload_type);
  static int allocate_reload_reg (struct insn_chain *, int, int);
  static int conflicts_with_override (rtx);
--- 405,410 
*** free_for_value_p (int regno, enum machin
*** 4984,4990 
 pic_offset_table_rtx is not, and we must not spill these things to
 memory.  */
  
! static int
  function_invariant_p (rtx x)
  {
if (CONSTANT_P (x))
--- 4983,4989 
 pic_offset_table_rtx is not, and we must not spill these things to
 memory.  */
  
! int
  function_invariant_p (rtx x)
  {
if (CONSTANT_P (x))
Index: ifcvt.c
===
RCS file: /cvs/gcc/gcc/gcc/ifcvt.c,v
retrieving revision 1.189
diff -p -r1.189 ifcvt.c
*** ifcvt.c 29 May 2005 18:56:42 -  1.189
--- ifcvt.c 31 May 2005 18:11:40 -
*** dead_or_predicable (basic_block test_bb,
*** 3430,3441 
--- 3430,3460 
/* Move the insns out of MERGE_BB to before the branch.  */
if (head != NULL)
  {
+   rtx insn;
+ 
if (end == BB_END (merge_bb))
BB_END (merge_bb) = PREV_INSN (head);
  
if (squeeze_notes (&head, &end))
return TRUE;
  
+   /* PR 21767: When moving insns above a conditional branch, REG_EQUAL
+notes might become invalid.  */
+   insn = head;
+   do
+   {
+ rtx note, set;
+ 
+ if (! INSN_P (insn))
+   continue;
+ note = find_reg_note (insn, REG_EQUAL, NULL_RTX);
+ if (! note)
+   continue;
+ set = single_set (insn);
+ if (!set || !function_invariant_p (SET_SRC (set)))
+   remove_note (insn, note);
+   } while (insn != end && (insn = NEXT_INSN (insn)));
+ 
reorder_insns (head, end, PREV_INSN (earliest));
  }
  

Re: Sine and Cosine Accuracy

[Geoff Keating]

On 31/05/2005, at 6:34 AM, Paul Koning wrote:


"Geoffrey" == Geoffrey Keating <[EMAIL PROTECTED]> writes:



 Geoffrey> Paul Koning <[EMAIL PROTECTED]> writes:


After some off-line exchanges with Dave Korn, it seems to me that
part of the problem is that the documentation for
-funsafe-math-optimizations is so vague as to have no discernable
meaning.



 Geoffrey> I believe that (b) is intended to include:

 Geoffrey> ... - limited ranges of elementary functions

You mean limited range or limited domain?  The x87 discussion suggests
limiting the domain.


Both.  (For instance, this option would also cover the case of an exp 
() which refuses to return zero.)



  And "limited" how far?  Scott likes 0 to 2pi;
equally sensibly one might recommend -pi to +pi.


I guess another way to put it is that the results may become  
increasingly inaccurate for values away from zero or one (or  
whatever).  (Or they might just be very inaccurate to start with.)



All these things may well make sense, but few or none of them are
implied by the text of the documentation.


I think they're all covered by (b).

It is intentional that the documentation doesn't specify exactly how  
the results differ from IEEE.  The idea is that if you need to know  
such things, this is not the option for you.

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Vincent Lefevre]

On 2005-05-31 19:30:48 +0200, Jakub Jelinek wrote:
> IEEE 754 is not mandated by the ISO C{90,99} standards and there are indeed
> platforms where float and double are not using IEEE 754 single resp. double
> precision formats.

But without IEEE-754 support, the ISO C99 standard is just a big joke
concerning floating point: almost nothing is guaranteed. And yes,
I know that there are platforms without IEEE-754 support, where a
multiplication by 1.0 may yield an overflow...

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Vincent Lefevre]

On 2005-05-31 11:39:39 -0700, Mike Stump wrote:
> On May 31, 2005, at 10:25 AM, Vincent Lefevre wrote:
> >Well, there is no extended precision with GCC under Linux/PPC.
> 
> Hum, I do wonder about even that; why do:
> 
> 2004-02-07  Alan Modra  <[EMAIL PROTECTED]>
> 
> * config/rs6000/t-linux64 (LIB2FUNCS_EXTRA): Add darwin- 
> ldouble.c.
> 
> powerpc64-*-linux*)

Hmm... this is powerpc64. Under the 32-bit version, there's no
extended precision.

> >And according to
> >http://developer.apple.com/documentation/mac/PPCNumerics/ 
> >PPCNumerics-14.html
> >(found with Google), the PowerPC doesn't have hardware support
> >for extended precision.
> 
> I don't see the relevance, not to the question of can long double be  
> used under linux, nor even can long double be used under OSX, nor  
> long double on ppc.

This just explains why there's no extended precision on Linux/ppc.
You can use long double, but if you want to be portable enough,
your program must not require extended precision.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Vincent Lefevre]

On 2005-05-31 21:16:19 +0200, Andreas Schwab wrote:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> > The "long double" type is required, but it is not required to be
> > extended precision.
> 
> But it can be.

So what?

> > Once you change the rounding precision, this is no longer required,
> > since you are already working with an extension.
> 
> The use of long double is not an extension.

Changing the rounding precision is. The C standard defines how you
can change the rounding direction, but not the rounding precision.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Andreas Schwab]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

> On 2005-05-31 21:16:19 +0200, Andreas Schwab wrote:
>> Vincent Lefevre <[EMAIL PROTECTED]> writes:
>> > The "long double" type is required, but it is not required to be
>> > extended precision.
>> 
>> But it can be.
>
> So what?

You can take advantage of it if it exists (which you can find out about
portably).  But not if your compiler has crippled it.

>> > Once you change the rounding precision, this is no longer required,
>> > since you are already working with an extension.
>> 
>> The use of long double is not an extension.
>
> Changing the rounding precision is. The C standard defines how you
> can change the rounding direction, but not the rounding precision.

Yes, my point.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Vincent Lefevre]

On 2005-05-31 22:11:36 +0200, Andreas Schwab wrote:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> > On 2005-05-31 21:16:19 +0200, Andreas Schwab wrote:
> >> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> >> > The "long double" type is required, but it is not required to be
> >> > extended precision.
> >> 
> >> But it can be.
> >
> > So what?
> 
> You can take advantage of it if it exists (which you can find out about
> portably).  But not if your compiler has crippled it.

You're wrong. If it is written in a portable way, the program will
still work if the processor rounds in double precision.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Andreas Schwab]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

> On 2005-05-31 22:11:36 +0200, Andreas Schwab wrote:
>> Vincent Lefevre <[EMAIL PROTECTED]> writes:
>> > On 2005-05-31 21:16:19 +0200, Andreas Schwab wrote:
>> >> Vincent Lefevre <[EMAIL PROTECTED]> writes:
>> >> > The "long double" type is required, but it is not required to be
>> >> > extended precision.
>> >> 
>> >> But it can be.
>> >
>> > So what?
>> 
>> You can take advantage of it if it exists (which you can find out about
>> portably).  But not if your compiler has crippled it.
>
> You're wrong. If it is written in a portable way, the program will
> still work if the processor rounds in double precision.

You are mistaken.

#include 
#include 

long double one = 1.0;
long double one_plus_eps;

int
main (void)
{
  long double one_plus_eps;

  one_plus_eps = one + LDBL_EPSILON;
  assert (one != one_plus_eps);
  return 0;
}

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Improving GCC Floating-Point [was: What is wrong with Bugzilla?]

[Scott Robert Ladd]

Vincent Lefevre wrote:
> Changing the rounding precision is. The C standard defines how you
> can change the rounding direction, but not the rounding precision.

Back in the early 1990's, work on solving this inadequacy was being done
by the X3J11 Numerical C Extensions Group. Rex Jaeschke was the chair,
if memory serves.

In fact, NCEG *did* improve C's numerics if one uses the
Zortech/Symantec/Digital Mars compiler. I know, because I wrote a
90-page manual on numerical computing for Zortech/Symantec. I haven't
looked at Digital Mars C, but I believe it still supports the proposed
NCEG extensions.

Only a few fragments of NCEG's work made it into C99, much to my
disappointment. I suppose it would be possible to implement NCEG in GCC,
but I doubt anyone would pay for the work involved -- yet I'd love to
have a -ffloat-nceg on platforms that could support it.

If anyone's curious, I have a PDF of that old manual of mine I can make
available. I don't have any electronic copies of the NCEG documents,
unfortunately, but my book covers pretty much everything.

..Scott

ERROR in the gfortran testsuite

[Andrew Pinski]

Right now on powerpc-darwin with the following versions:
Expect version is   5.38.0
Tcl version is  8.4
Framework version is1.4.4

I get the following failure in the gfortran-
ERROR: tcl error sourcing  
/Users/pinskia/src/local3/gcc/gcc/testsuite/gfortran.fortran-torture/ 
execute/execute.exp.

ERROR: expected boolean value but got ""
while executing
"if { $done_p } {
return
}"
invoked from within
"if [file exists [file rootname $src].x] {
verbose "Using alternate driver [file rootname [file tail  
$src]].x" 2

set done_p 0
catch "set done_p \[so..."
(procedure "fortran-torture-execute" line 10)
invoked from within
"fortran-torture-execute $testcase"
("foreach" body line 5)
invoked from within
"foreach testcase [lsort [glob -nocomplain $srcdir/$subdir/*.f90]] {
if ![runtest_file_p $runtests $testcase] then {
continue
}
fortran-to..."
(file  
"/Users/pinskia/src/local3/gcc/gcc/testsuite/gfortran.fortran-torture/ 
execute/execute.exp" line 46)

invoked from within
"source  
/Users/pinskia/src/local3/gcc/gcc/testsuite/gfortran.fortran-torture/ 
execute/execute.exp"

("uplevel" body line 1)
invoked from within
"uplevel #0 source  
/Users/pinskia/src/local3/gcc/gcc/testsuite/gfortran.fortran-torture/ 
execute/execute.exp"

invoked from within
"catch "uplevel #0 source $test_file_name""
testcase  
/Users/pinskia/src/local3/gcc/gcc/testsuite/gfortran.fortran-torture/ 
execute/execute.exp completed in 217 seconds


I think this is due to the empty file  
"testsuite/gfortran.fortran-torture/execute/forall_3.x" but I don't  
know for sure.  Could someone check to make sure and fix this?


Thanks,
Andrew Pinski

gcc-3.4-20050531 is now available

[gccadmin]

Snapshot gcc-3.4-20050531 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050531/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050531 

You'll find:

gcc-3.4-20050531.tar.bz2  Complete GCC (includes all of below)

gcc-core-3.4-20050531.tar.bz2 C front end and core compiler

gcc-ada-3.4-20050531.tar.bz2  Ada front end and runtime

gcc-g++-3.4-20050531.tar.bz2  C++ front end and runtime

gcc-g77-3.4-20050531.tar.bz2  Fortran 77 front end and runtime

gcc-java-3.4-20050531.tar.bz2 Java front end and runtime

gcc-objc-3.4-20050531.tar.bz2 Objective-C front end and runtime

gcc-testsuite-3.4-20050531.tar.bz2The GCC testsuite

Diffs from 3.4-20050524 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-3.4
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Vincent Lefevre]

On 2005-06-01 00:58:25 +0200, Andreas Schwab wrote:
> You are mistaken.

No, I don't see any problem.

> #include 
> #include 
> 
> long double one = 1.0;
> long double one_plus_eps;
> 
> int
> main (void)
> {
>   long double one_plus_eps;
> 
>   one_plus_eps = one + LDBL_EPSILON;
>   assert (one != one_plus_eps);
>   return 0;
> }

I don't know how the standard should be interpreted (see below), but
if your program fails, this means that either your program is buggy
or the C implemention is buggy.

The standard says for LDBL_EPSILON: "the difference between 1 and the
least value greater than 1 that is representable in the given floating
point type, b^(1-p)".

One may decide that p = 64. The processor will round to double
precision, but that's OK since the C standard doesn't require
correct rounding (the accuracy is implementation-defined, as
said in #4). Your program will fail because it is not portable:
you made some assumptions about the accuracy.

One may decide that p = 53. I think this is better. Your program
will work (unless LDBL_EPSILON has a value assuming that p = 64,
but this would mean that your C implementation is buggy).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: ERROR in the gfortran testsuite

[Steve Kargl]

On Tue, May 31, 2005 at 07:40:37PM -0400, Andrew Pinski wrote:
> Right now on powerpc-darwin with the following versions:
> Expect version is   5.38.0
> Tcl version is  8.4
> Framework version is1.4.4
> 
> I get the following failure in the gfortran-
> ERROR: tcl error sourcing  

(snip)

> I think this is due to the empty file  
> "testsuite/gfortran.fortran-torture/execute/forall_3.x" but I don't  
> know for sure.  Could someone check to make sure and fix this?

I just finished a bootstrap/regression test of gfortran on HEAD
and do not see this problem.  Can you XFAIL forall_3.f90 and
see if the problem persists?

amd64-*-freebsd
=== gfortran Summary ===

# of expected passes7004
# of unexpected successes   8
# of expected failures  35
# of unsupported tests  16
obj41/gcc/testsuite/../gfortran  version 4.1.0 20050531 (experimental)


-- 
Steve

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Marcin Dalecki]

On 2005-05-31, at 19:14, Dave Korn wrote:



Speak up now, or we're going to send the firing squad.



  Just don't let them use x87 intrinsics to calculate the line of  
fire, or

we'd all better run!


Some remarkable time ago I was exposed to a 12 bit "RISC" CPU with  
two banks
of 4k ferrite core memory... We where able to hit with the precision  
of about

half a meter, yes just meters not km, from a distance of 45km!
No no there where no laser guided "funnies" involved just pure boring  
ari.

Successful bootstrap of GCC 4.0 on Mac OS X 10.4.1

[Dan Allen]

I built the released gcc 4.0 C compiler on Mac OS X Tiger 10.4.1  
(Darwin 8.1).


I did a make bootstrap of just the C language on a Power Macintosh G5  
Dual 2 GHz machine and it built without incident.


% ./config.guess
powerpc-apple-darwin8.1.0


The compiler used to built 4.0 is the one shipped with Tiger:

% gcc -v
Reading specs from /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/specs
Configured with: /private/var/tmp/gcc/gcc-4061.obj~8/src/configure -- 
disable-checking --prefix=/usr --mandir=/share/man --enable- 
languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^+.-]*$/ 
s/$/-4.0/ --with-gxx-include-dir=/include/gcc/darwin/4.0/c++ -- 
build=powerpc-apple-darwin8 --host=powerpc-apple-darwin8 -- 
target=powerpc-apple-darwin8

Thread model: posix
gcc version 4.0.0 20041026 (Apple Computer, Inc. build 4061)

% as -v Apple Computer, Inc. version cctools-576.obj~23, GNU assembler  
version 1.38



The resulting bootstrapped compiler gives this info:

[~/gcc-4.0.0/build/gcc] % ./xgcc -v
Using built-in specs.
Target: powerpc-apple-darwin8.1.0
Configured with: ../configure
Thread model: posix
gcc version 4.0.0


I have not run make check, but the bootstrap went through all 3  
stages without any errors.


Dan Allen
N39°59.8' W111°45.4'

Mac OS X Panther to Tiger Build Changes for GCC 3.3 and 3.4

[Dan Allen]

I tried doing bootstrap builds of GCC 3.3.6 and GCC 3.4.4 but these  
builds fail due to the absence of the 'c++filt' tool.  I noticed in  
the libiberty Makefile that there is some comment about this tool  
being moved to a different binutils package, which I have not  
installed on my machine.


I used the core-release files as well as the full release files and  
did the following:


1.  unpack sources with bunzip2 and gnutar
2.  cd into dir
3.  mkdir build
4.  cd build
5.  ../configure
6.  make bootstrap

The builds proceed for quite awhile until they hit this missing 'c+ 
+filt' tool problem.


These builds were done on an Apple Power Macintosh G5 Dual 2GHz  
machine running Mac OS X 10.4.1 Tiger and Apple's standard Xcode 2  
development tools which I guess are now missing c++filt.


I previously have done bootstrap builds of earlier versions of GCC  
3.3 and GCC 3.4 and they have built successfully under Mac OS X  
10.3.9 Panther.


GCC 4.0 builds fine on 10.4.1 Tiger without this problem, so whatever  
small fix was made to GCC 4.0 probably could be made to 3.3.6 and  
3.4.4 to get them to build, but I have not taken the time to track  
this problem down further.


Dan Allen
N39°59.8' W111°45.4'

Google Summer of Code

[Jeyasankar Kottalam]

Hi,

* Are the FSF and GCC interested in mentoring students under Google's Summer of
Code?

* What projects would the GCC maintainers like to see done for Google's Summer
of Code? Anything at http://gcc.gnu.org/projects/ ? Or do you have specific
project suggestions?

Thanks,
-Jey Kottalam

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

[Alan Modra]

On Tue, May 31, 2005 at 09:53:05PM +0200, Vincent Lefevre wrote:
> On 2005-05-31 11:39:39 -0700, Mike Stump wrote:
> > On May 31, 2005, at 10:25 AM, Vincent Lefevre wrote:
> > >Well, there is no extended precision with GCC under Linux/PPC.
> > 
> > Hum, I do wonder about even that; why do:
> > 
> > 2004-02-07  Alan Modra  <[EMAIL PROTECTED]>
> > 
> > * config/rs6000/t-linux64 (LIB2FUNCS_EXTRA): Add darwin- 
> > ldouble.c.
> > 
> > powerpc64-*-linux*)
> 
> Hmm... this is powerpc64.

Yes.  powerpc64-linux uses IBM extended precision long doubles.

> Under the 32-bit version, there's no extended precision.

No.  powerpc-linux has 128-bit IEEE soft-float long double.

$ cat > fadd.c <<\EOF
long double fadd (long double a, long double b) { return a + b; }
EOF
$ gcc -m32 -mlong-double-128 -c fadd.c
$ nm fadd.o
 T fadd
 U _q_add

Now all you need is a library that supplies _q_add and similar.  Let's
see, glibc is a likely place..

./sysdeps/powerpc/soft-fp/Makefile:powerpc-quad-routines := q_add q_cmp q_cmpe 
q_div q_dtoq q_feq q_fge \
./sysdeps/powerpc/soft-fp/Versions:_q_add; _q_cmp; _q_cmpe; _q_div; 
_q_dtoq; _q_feq; _q_fge; _q_fgt;
./sysdeps/powerpc/soft-fp/q_add.c:long double _q_add(const long double a, const 
long double b)

Then of course, you need to convince glibc to build them for you.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Google Summer of Code

[Ranjit Mathew]

Jeyasankar Kottalam wrote:
> Hi,
> 
> * Are the FSF and GCC interested in mentoring students under Google's Summer 
> of
> Code?
> 
> * What projects would the GCC maintainers like to see done for Google's Summer
> of Code? Anything at http://gcc.gnu.org/projects/ ? Or do you have specific
> project suggestions?

I was a bit confused by this question since I hadn't read
Slashdot yet.

For the benefit of others, the reference is to:

  http://code.google.com/summerofcode.html

Ranjit.

-- 
Ranjit Mathew  Email: rmathew AT gmail DOT com

Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/