Re: [OT] __builtin_cpow((0,0),(0,0))

[Duncan Sands]

Hi Robert,

> >>Well if you tell me there are people about there implementing cpow
> >>with log and exp, that's enough for me to decide that Ada should
> >>continue to stay away (the Ada RM has accuracy requirements that
> >>would preclude a broken implementation of this kind) :-)
> > 
> > 
> > the reference manual allows for a "relaxed mode", which doesn't have
> > those accuracy requirements.  I guess -ffast-math and the use of
> > builtins would be appropriate in the relaxed mode.  Do you plan to
> > implement such a mode one day?
> > 
> > Just curious.
> > 
> > All the best,
> > 
> > Duncan.
> 
> No plans, but also note that the use of log/exp for ** besides
> being horribly inaccurate, is also inefficient. Fast accurate
> math is achievable, we don't see a need for a relaxed mode.

if the Ada front-end has an efficient, accurate implementation
of x^y, wouldn't it make sense to move it to the back-end
(__builtin_pow) so everyone can benefit?

Ciao,

Duncan.

Re: Bug 20375 - ia64 varadic regression

[Nathan Sidwell]

Mark Mitchell wrote:
Zack Weinberg wrote:
So, in other words,
  if (current_function_stdarg)
data->last_named = true;

Actually, no:
  data->last_named = !TREE_CHAIN (parm);
(This is the last "named" parameter iff it's the last parameter.)
yes, this is essentially the patch I am testing.  AFAICT Jim's comments were
again about the confusing name of NAMED_PARM, and really is talking about
non-varadic/varadic.  At the moment I don't see how fixing this bug for ia64
breaks anything else (that wasn't already broken).
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: Deprecating min/max extension in C++

[Olivier Galibert]

On Wed, Mar 09, 2005 at 07:04:39AM +0100, Gabriel Dos Reis wrote:
> That is a rather weak argument.  What is the type of the argument if
> it were possible?

float obviously.  You follow the standard promotion/type resolution
rules you already handle for operators like +.  Done correctly,
min/max are operators too.

  OG.

Re: __builtin_cpow((0,0),(0,0))

[Vincent Lefevre]

On 2005-03-07 17:09:46 +0100, Duncan Sands wrote:
> Mathematically speaking zero^zero is undefined, so it should be NaN.
[...]

Mathematically, this is just about conventions. But the main problem
here is that the power function is overloaded. For instance, you can
use pow() to compute x^i, where i is an integer, and in this case,
having x^0 = 1 is natural. Of course, cpow is not pow, but you have
the idea.

BTW, in  [RR-5406 - Proposal
for a Standardization of Mathematical Function Implementation in
Floating-Point Arithmetic], we said:

On the one hand, as said above, there is no way of defining 0^0
using continuity, but on the other hand, many important properties
remain satisfied if we choose 0^0 = 1 (which is frequently
adopted, as a convention, by mathematicians). Kahan suggests to
choose 0^0 = 1. [...]

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

Re: Deprecating min/max extension in C++

[Giovanni Bajo]

Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:

>>> IMO, if these are C++-only, it's relatively easy to deprecate these
>>> extension -- but I'd like to hear from Jason and Nathan, and also the
>>> user community before we do that.  Of all the extensions we've had, this
>>> one really hasn't been that problematic.
>>
>> I would prefer them to stay. My reasons:
>>
>> 1) std::min() and std::max() are not exact replacements. For instance,
you
>> cannot do std::min(3, 4.0f) because the arguments are of different type.
>
> That is a rather weak argument.  What is the type of the argument if
> it were possible?

"float" of course, like we do for 3 + 4.0f.

> If float, why can't you write 3f?  If int, why can't
> you write 4?

Because the example was just an example. In real code, "3" is probably a
variable of integer type, and "4.0f" is probably a variable of floating
point type.
Going on this way, why don't we to propose to deprecate "+" in C++ because
std::plus can be used as a replacement? I'm sure people won't be happy to be
unable to add an integer and a long.

> With the ominpresence of function templates and the
> rather picky template-argument deduction process, how useful is that
> fuzzy-typed constructs with rather dubious semantics and implementation?

It is useful for me. It has been many times. It avoided me to write casts
which are otherwise necessary. I don't think I will have to explain you the
domain of the problem, why that single variable was float or int, and so on.
My statement is that std::min() is *not* an exact replacement for  I would like to see those extensions deprecated and go with no return.


I would like to propose them for standardization. It is just too bad I don't
have time to prepare the papers.
-- 
Giovanni Bajo

Re: __builtin_cpow((0,0),(0,0))

[Duncan Sands]

> On the one hand, as said above, there is no way of defining 0^0
> using continuity, but on the other hand, many important properties
> remain satisfied if we choose 0^0 = 1 (which is frequently
> adopted, as a convention, by mathematicians). Kahan suggests to
> choose 0^0 = 1. [...]

The problem is x^0.0 (real exponent), not x^0 (integer exponent).
0^0 (integer exponent) *can* be defined by continuity, the value is 1.
The fact that it is defined by continuity is exactly the reason 0^0=1
is useful in contexts where the exponent is an integer (polynomials
etc): the special case 0^0 acts the same as the general case x^0,
since it is the limiting value of it.  In my experience, defining 0^0.0
(real exponent) to be 1.0 is much less useful.  Now in practice I can
imagine that a language confuses x^integer and x^real by mapping them
to the same function, or only provides a function for doing x^real.
Perhaps this is the case with C?  If so, then having 0^0.0 return 1.0
is a convenient hack to work around that mistake.  On the other hand,
ignoring such things as language standards and the weight of history,
if there are separate functions for x^integer and x^real, then in my
opinion the most sensible thing would be for 0^0 to return 1, and
0^0.0 to return NaN.  This might confuse programmers though.

All the best,

Duncan.

Re: __builtin_cpow((0,0),(0,0))

[Vincent Lefevre]

On 2005-03-09 12:45:57 +0100, Duncan Sands wrote:
> The problem is x^0.0 (real exponent), not x^0 (integer exponent).

Well, mathematically, you can distinguish these two functions:

  powrr: RxR -> R (not defined on (0,0) in particular)

and

  powrz: RxZ -> R (where powint(0,0) = 1)

and even other two functions, where R is replaced by C (the complex
numbers). Unfortunately, the C language doesn't distinguish them.

> Now in practice I can imagine that a language confuses x^integer and
> x^real by mapping them to the same function, or only provides a
> function for doing x^real. Perhaps this is the case with C?

Yes, and to compute complex^integer, you need to use cpow(), AFAIK.
I think this is the reason why cpow((0,0),(0,0)) should return 1,
just like pow(0,0).

> If so, then having 0^0.0 return 1.0 is a convenient hack to work
> around that mistake. On the other hand, ignoring such things as
> language standards and the weight of history, if there are separate
> functions for x^integer and x^real, then in my opinion the most
> sensible thing would be for 0^0 to return 1, and 0^0.0 to return
> NaN. This might confuse programmers though.

They would be two different mathematical functions, thus returning
different results should be OK. Anyway the C language has only one
function for that (I don't know about the other languages, though).
Moreover, the implicit conversions between signed and unsigned
integers in C are much more confusing.

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

Re: [OT] __builtin_cpow((0,0),(0,0))

[Robert Dewar]

Duncan Sands wrote:
if the Ada front-end has an efficient, accurate implementation
of x^y, wouldn't it make sense to move it to the back-end
(__builtin_pow) so everyone can benefit?
I don't know how efficient or accurate the current implementation
is (we are in the process of redoing our math routines from
scratch). A fair amount of rewriting would be needed (it's in
Ada of course right now, and the rules for raising exceptions
are different).

http://gcc.gnu.org/install/specific.html#*-*-solaris2*

[Dimitri Papadopoulos-Orfanos]

Hi,
On this page:
http://gcc.gnu.org/install/specific.html
there's a link to:
#*-*-solaris2*
but it doesn't work. Instead from what I can undersatnd it should be:
#g_t*-*-solaris2*
Regards,
Dimitri

Re: Deprecating min/max extension in C++

[Gabriel Dos Reis]

Olivier Galibert <[EMAIL PROTECTED]> writes:

| On Wed, Mar 09, 2005 at 07:04:39AM +0100, Gabriel Dos Reis wrote:
| > That is a rather weak argument.  What is the type of the argument if
| > it were possible?
| 
| float obviously.  You follow the standard promotion/type resolution
| rules you already handle for operators like +.  Done correctly,
| min/max are operators too.

Nobody is disputing that min/max are operators.  However, the point is
that both min and max have a uniform requirement as far as the types
of their operands are concerned.  The rest of the message you left out
have questions you did not address.

-- Gaby

Re: Deprecating min/max extension in C++

[Gabriel Dos Reis]

"Giovanni Bajo" <[EMAIL PROTECTED]> writes:

| Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| 
| >>> IMO, if these are C++-only, it's relatively easy to deprecate these
| >>> extension -- but I'd like to hear from Jason and Nathan, and also the
| >>> user community before we do that.  Of all the extensions we've had, this
| >>> one really hasn't been that problematic.
| >>
| >> I would prefer them to stay. My reasons:
| >>
| >> 1) std::min() and std::max() are not exact replacements. For instance,
| you
| >> cannot do std::min(3, 4.0f) because the arguments are of different type.
| >
| > That is a rather weak argument.  What is the type of the argument if
| > it were possible?
| 
| "float" of course, like we do for 3 + 4.0f.
| 
| > If float, why can't you write 3f?  If int, why can't
| > you write 4?
| 
| Because the example was just an example. In real code, "3" is probably a
| variable of integer type, and "4.0f" is probably a variable of floating
| point type.

Which we have not seen yet, for the purpose of assessing the purpoted
usefulness in real codes.  Arguments are easily made with xyz examples.

| Going on this way, why don't we to propose to deprecate "+" in C++ because
| std::plus can be used as a replacement?

  (1) If you think that has any useful purpose, I certainly won't stand
  in your way.

  (2) you're comparing apples-to-oranges, and you do know that.

-- Gaby

Re: Deprecating min/max extension in C++

[Giovanni Bajo]

Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:

>> Because the example was just an example. In real code, "3" is probably a
>> variable of integer type, and "4.0f" is probably a variable of floating
>> point type.
>
> Which we have not seen yet, for the purpose of assessing the purpoted
> usefulness in real codes.  Arguments are easily made with xyz examples.


Are you disputing the usefulness of promotion rules with operators? If you
agree that promotion is useful, I cannot see why it should not be for
min/max operators.
-- 
Giovanni Bajo

Re: __builtin_cpow((0,0),(0,0))

[Gabriel Dos Reis]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

| On 2005-03-09 12:45:57 +0100, Duncan Sands wrote:
| > The problem is x^0.0 (real exponent), not x^0 (integer exponent).
| 
| Well, mathematically, you can distinguish these two functions:
| 
|   powrr: RxR -> R (not defined on (0,0) in particular)
| 
| and
| 
|   powrz: RxZ -> R (where powint(0,0) = 1)
| 
| and even other two functions, where R is replaced by C (the complex
| numbers). Unfortunately, the C language doesn't distinguish them.

That is no reason for the compiler not to distinguish them.  There are
plenty of stuff the C language does not distinguish but the compiler
has to.

Notice that LIA-2 says in its rationale (§B.5.3.6)

  [...] There is a problem for power_F(x,y) if both x and y are zero: 
  -- Ada raises an `exception' for the operation that is close in
  semantics to power_F when both arguments are zero, in accordance
  with the fact 0^0 is mathematically undefined.
  
  -- The X/OPEN Portability Guide, as well as C9x, specifies for
 pow(0,0 a return value of 1, and no notification.  This
 specification agrees with the recommendations in [51, 53, 54, 57].

  The specification in LIA-2 follows Ada, and returns invalid for
  power_F(0,0), because of the risks inherent in returning a result
  which might be inappropriate for the application at hand.  Note
  however, that power_FI(0,0) is 1, without any notification.  The
  reason is that the limiting value for the corresponding mathematical
  function, when following either of the only two continuous paths, is
  1.  This also agrees with the Ada specification for a floating point
  value raised to the power in an integer datatype, as well as that
  for other programming languages which distinguish there operations.

  Along any path defined by y = k/ln(x) the mathematical function x^y
  has the value exp(k).  It follows that some of the limiting values
  for x^y depend on the choice of k, and hence are undefined, as
  indicated in the specification.

| > Now in practice I can imagine that a language confuses x^integer and
| > x^real by mapping them to the same function, or only provides a
| > function for doing x^real. Perhaps this is the case with C?
| 
| Yes, and to compute complex^integer, you need to use cpow(), AFAIK.

No, you don't need cpow().

| I think this is the reason why cpow((0,0),(0,0)) should return 1,
| just like pow(0,0).

That is a bogus reason.

-- Gaby

Re: Deprecating min/max extension in C++

[Gabriel Dos Reis]

"Giovanni Bajo" <[EMAIL PROTECTED]> writes:

| Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| 
| >> Because the example was just an example. In real code, "3" is probably a
| >> variable of integer type, and "4.0f" is probably a variable of floating
| >> point type.
| >
| > Which we have not seen yet, for the purpose of assessing the purpoted
| > usefulness in real codes.  Arguments are easily made with xyz examples.
| 
| 
| Are you disputing the usefulness of promotion rules with operators? If you

I'm disputing the extensions ? when we have a standard
min()and max().

-- Gaby

Gcc successful build

[Shawn Begin]

I have successfully built GCC-3.4.3 on the alpha-unknown-linux-gnu platform.
The specific OS is gentoo linux 2004.3 on the ev56 alpha platform.
My glibc is version 2.3.2.
The specific version portage emerged is "gcc version 3.4.3-20050110 (Gentoo 
Linux 3.4.3.20050110, ssp-3.4.3.20050110-0, pie-8.7.7)" from gcc -v

If you'd like more info, please let me know, otherwise thanks for the great 
product!
Shawn Begin

Re: Deprecating min/max extension in C++

[Giovanni Bajo]

Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:

 Because the example was just an example. In real code, "3" is probably
a
 variable of integer type, and "4.0f" is probably a variable of floating
 point type.
>>>
>>> Which we have not seen yet, for the purpose of assessing the purpoted
>>> usefulness in real codes.  Arguments are easily made with xyz examples.
>>
>>
>> Are you disputing the usefulness of promotion rules with operators? If
you
>
> I'm disputing the extensions ? when we have a standard
> min()and max().

... which do not handle promotions. So you do not consider useful to have a
min/max operator with promotion (so that it would work exactly like any
other operator) just because there is a cheap version without promotion. And
my statement that min() and max() are not exact replacements still stands.

We'll disagree, as happens.

Since there is no exact replacements (especially for the min/max assignment
operators), and the extensions are definitely not so troublesome, I would
like them to stay.
-- 
Giovanni Bajo

Re: Deprecating min/max extension in C++

[Robert Dewar]

Giovanni Bajo wrote:
... which do not handle promotions. So you do not consider useful to have a
min/max operator with promotion (so that it would work exactly like any
other operator) just because there is a cheap version without promotion. And
my statement that min() and max() are not exact replacements still stands.
We'll disagree, as happens.
Since there is no exact replacements (especially for the min/max assignment
operators), and the extensions are definitely not so troublesome, I would
like them to stay.
There are thousands of things that you can think of that would be marginally
convenient in a complex language like C++ (or Ada for that matter), but that's
not a justification tyo add them as an extension. THe burden of adding an
extension should be pretty high. I don't think this particular extension
meets that requirement.

A plea for help

[Andrew Haley]

This is PR debug/19769.  [4.0/4.1 Regression] GCC produces wrong
dwarf2 output that breaks gdb

Because of this regression it has been impossible to debug any gcj
compiled program for several weeks now.  gdb dies the instand libgcj
is loaded.

Can some C++ wizard please look at this and come up with some
sucggestion about how we might move forward?

Thanks,
Andrew.

Re: __builtin_cpow((0,0),(0,0))

[Vincent Lefevre]

On 2005-03-09 17:37:59 +0100, Gabriel Dos Reis wrote:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> | Well, mathematically, you can distinguish these two functions:
> | 
> |   powrr: RxR -> R (not defined on (0,0) in particular)
> | 
> | and
> | 
> |   powrz: RxZ -> R (where powint(0,0) = 1)
> | 
> | and even other two functions, where R is replaced by C (the complex
> | numbers). Unfortunately, the C language doesn't distinguish them.
> 
> That is no reason for the compiler not to distinguish them.  There are
> plenty of stuff the C language does not distinguish but the compiler
> has to.

Do you mean that the compiler should detect if the second argument
comes from an integer type?

> | Yes, and to compute complex^integer, you need to use cpow(), AFAIK.
> 
> No, you don't need cpow().

>From this point of view, the math library is useless as one can
reimplement it entirely. :)
 
> | I think this is the reason why cpow((0,0),(0,0)) should return 1,
> | just like pow(0,0).
> 
> That is a bogus reason.

No more than any other reason.

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

Re: Deprecating min/max extension in C++

[Sundell Software]

On Wed, 9 Mar 2005 18:48:06 +0100, Giovanni Bajo <[EMAIL PROTECTED]> wrote:

> ... which do not handle promotions. So you do not consider useful to have a
> min/max operator with promotion (so that it would work exactly like any
> other operator) just because there is a cheap version without promotion. And
> my statement that min() and max() are not exact replacements still stands.

If you wish for a min/max with promotion, why not implement
alternative versions of those two template functions? With typeof
going into the standard and already being a available in gcc, it
should be easy to deduce the return type.

> for (int i=0;i<100;i++)
> {
>float cur = Compute(i) * factor;
> if (max_computed < cur)
>max_computed = cur;
> }

for (int i=0;i<100;i++)
  max_computed = std::max(Compute(i) * factor, max_computed);

Rakshasa

-- 
http://libtorrent.rakshasa.no/ - BitTorrent library and client for *nix.

GCC Status Report (2005-03-09)

[Mark Mitchell]

General
===
 
As per previous announcements, please do not place a target milestone
on bugs that are not part of the release criteria.  For example, since
neither Ada nor Java are part of the release criteria, bugs that
affect only those languages should never have a target milestone.
(It's good if they do have "4.0 regression" in their subject line,
though; then you can always find bugs in those languages that you want
to fix before the release by searching on that basis.)

4.1 Status
==

The 4.1 projects Wiki page shows that four projects have been checked
in:

* Code Sinking

* Improved PHI-OPT

* New C Parser

* Part 1 of Libada GNATTools Branch

The remaining 1.1 projects include:

* Autovectorization Enhancements (some parts)

* SMS Improvements

* Structure Aliasing Part I

(Are some of these actually in, but have not been so marked on the
Wiki?  If so, please update the Wiki!)

We want to get these in by March 15th; at that point, the wraps come
off the Stage 1.2 projects.  Again, please submit your patches early,
so that they can be debated/revised/approved and ready to go.  If
you're patches are not being reviewed, let me know.  In many cases, I
may not be able to review them myself, but I will try to find someone
who will.

4.0 Status
==

There are presently 37 "critical" regressions open against 4.0.  These
are bugs that are in the wrong-code, ice-on-valid-code, or
rejects-valid categories; in other words, they are bugs that would
make conforming programs that worked with older releases fail to work
in 4.0.  There are 111 total regressions open, i.e., 74 "non-critical"
regressions. 

In order to help us hit the April 15th target for GCC 4.0, please do
not put the 4.0 target milestone on any new non-critical bugs after
March 15th, without first getting my approval -- and expect that
approval to be hard to get.  For these defects, use the 4.0.1
milestone.  It's still OK to fix non-critical regressions after that
point, but let's aim at a fixed target, rather than trying to accept
new reports at the last minute.

I will undoubtedly kick some of the current non-critical regressions
back to 4.0.1 as well.

Many (40-ish) iof the open regressions (critical and otherwise) have
people assigned to them.  It's the usual suspects: Merrill, Mitchell,
Henderson, Oliva, Sidwell, etc.  We folks need to deal with the bugs
assigned to us.

3.4.4 Status


There are 59 critical and 90 non-critical regressions open against
3.4.4.  I'm not that concerned about the total; it is what it is.
Some of the bugs are not affect platforms/languages that would not
entitle them to release target, as per above, were they being created
now.  Many others are relatively obscure.

I plan to do a 3.4.4 release on May 1st.  That means that, as we focus
on 4.0, and fix bugs also present in 3.4, we'll get a better 3.4.4
release.  The 3.4.4 release will probably be the last 3.4.x release
which I will manage; I want to focus exclusively on 4.0 and 4.1 after
that point.

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]

Re: GCC Status Report (2005-03-09)

[Steven Bosscher]

On Wednesday 09 March 2005 23:51, Mark Mitchell wrote:
> The remaining 1.1 projects include:
>
> * Autovectorization Enhancements (some parts)

Not seen yet.

> * SMS Improvements

Part 1 of n (n unknown) submitted and unreviewed so far:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00681.html

> * Structure Aliasing Part I

Submitted just today:
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg00896.html

Gr.
Steven

Re: GCC Status Report (2005-03-09)

[Greg Schafer]

On Wed, Mar 09, 2005 at 02:51:52PM -0800, Mark Mitchell wrote:

> As per previous announcements, please do not place a target milestone
> on bugs that are not part of the release criteria.

Hmm, see below.

> 4.0 Status
> ==

> In order to help us hit the April 15th target for GCC 4.0, please do
> not put the 4.0 target milestone on any new non-critical bugs after
> March 15th, without first getting my approval -- and expect that
> approval to be hard to get.

4.0 will not bootstrap on Glibc systems built with _stock_ Glibc 2.3.3 or
2.3.4 tarballs. Patched Glibc's are of course fine. (Please, no comments on
the wisdom of using unpatched Glibc's).

This is rather critical, yet a bugmaster saw fit to remove the 4.0.0 target
milestone on this bug:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20166

Any chance of making this one a high priority?

Thanks
Greg

Re: GCC Status Report (2005-03-09)

[Andrew Pinski]

On Mar 9, 2005, at 6:15 PM, Greg Schafer wrote:
This is rather critical, yet a bugmaster saw fit to remove the 4.0.0 
target
milestone on this bug:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20166
Any chance of making this one a high priority?
Of course this is a glibc bug and not really a gcc bug.
-- Pinski

Re: GCC Status Report (2005-03-09)

[Diego Novillo]

Mark Mitchell wrote:
* Structure Aliasing Part I
Submitted today.  I've started reading it over.
Diego.

gcc-3.3-20050309 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 3.3 CVS branch
with the following options: -rgcc-ss-3_3-20050309 

You'll find:

gcc-3.3-20050309.tar.bz2  Complete GCC (includes all of below)

gcc-core-3.3-20050309.tar.bz2 C front end and core compiler

gcc-ada-3.3-20050309.tar.bz2  Ada front end and runtime

gcc-g++-3.3-20050309.tar.bz2  C++ front end and runtime

gcc-g77-3.3-20050309.tar.bz2  Fortran 77 front end and runtime

gcc-java-3.3-20050309.tar.bz2 Java front end and runtime

gcc-objc-3.3-20050309.tar.bz2 Objective-C front end and runtime

gcc-testsuite-3.3-20050309.tar.bz2The GCC testsuite

Diffs from 3.3-20050302 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-3.3
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.

PR 19893 & array_ref bug

[Steve Ellcey]

I was looking at PR 19893 (gcc.dg/vect/vect-76 fails on ia64-hpux) and I
think it is caused by a non-platform specific bug, though it may not
cause vect-76 to fail on other platforms.  I was hoping someone might be
able to help me understand what is going on.

Here is a cut down test case (with no vector stuff in it):

typedef int aint __attribute__ ((__aligned__(16)));
aint ib[12];
int ic[12], *x, *y;
int main (void)
{
  x = &ib[4];
  y = &ic[4];
}

If you look at the assembly language generated on IA64 (HP-UX or Linux)
or probably on any platform, you will see that 'y' gets correctly set to
the address of ic[4].  But 'x' gets set to ib[0], instead of ib[4].
Things look good in all the tree dumps but the first rtl dump looks bad
so I believe things are going wrong during expansion.  Looking in
tree.def I see:

/* Array indexing.
   Operand 0 is the array; operand 1 is a (single) array index.
   Operand 2, if present, is a copy of TYPE_MIN_VALUE of the index.
   Operand 3, if present, is the element size, measured in units of
   the alignment of the element type.  */
DEFTREECODE (ARRAY_REF, "array_ref", tcc_reference, 4)

Now I think this the problem is with operand 3.  What value should it
have if the alignment is greater than the element size?  That is what I
have in the test case above and when I dump the array_ref for ib[4] I
see that I have an operand 3 and it is zero and I think this is causing
the test failure.  What value should operand 3 have in this situation?
Or should it have been left out?

Steve Ellcey
[EMAIL PROTECTED]

Re: __builtin_cpow((0,0),(0,0))

[Gabriel Dos Reis]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

| On 2005-03-09 17:37:59 +0100, Gabriel Dos Reis wrote:
| > Vincent Lefevre <[EMAIL PROTECTED]> writes:
| > | Well, mathematically, you can distinguish these two functions:
| > | 
| > |   powrr: RxR -> R (not defined on (0,0) in particular)
| > | 
| > | and
| > | 
| > |   powrz: RxZ -> R (where powint(0,0) = 1)
| > | 
| > | and even other two functions, where R is replaced by C (the complex
| > | numbers). Unfortunately, the C language doesn't distinguish them.
| > 
| > That is no reason for the compiler not to distinguish them.  There are
| > plenty of stuff the C language does not distinguish but the compiler
| > has to.
| 
| Do you mean that the compiler should detect if the second argument
| comes from an integer type?

No.  I mean when I call powi() either through built-ins or appropriate
overload (several programming languages do so), I expect sane semantics.

| > | Yes, and to compute complex^integer, you need to use cpow(), AFAIK.
| > 
| > No, you don't need cpow().
| 
| From this point of view, the math library is useless as one can
| reimplement it entirely. :)

I don't see how that follows from my statement.

|  
| > | I think this is the reason why cpow((0,0),(0,0)) should return 1,
| > | just like pow(0,0).
| > 
| > That is a bogus reason.
| 
| No more than any other reason.

The asseryion that 0^0 is mathematically undefined is not a bogus reason.
It is a fact.

-- Gaby

Re: Deprecating min/max extension in C++

[Gabriel Dos Reis]

"Giovanni Bajo" <[EMAIL PROTECTED]> writes:

| Since there is no exact replacements

And that statement is false; and you do know that.

-- Gaby

Re: GCC Status Report (2005-03-09)

[Joe Buck]

On Wed, Mar 09, 2005 at 06:18:58PM -0500, Andrew Pinski wrote:
> On Mar 9, 2005, at 6:15 PM, Greg Schafer wrote:
> 
> >This is rather critical, yet a bugmaster saw fit to remove the 4.0.0 
> >target
> >milestone on this bug:
> >
> >  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20166
> >
> >Any chance of making this one a high priority?
> 
> Of course this is a glibc bug and not really a gcc bug.

How many people does this affect?  Does anyone know which distros
have an affected glibc?  (Debian on x86_64, but that's not a supported
platform for sarge, so folks on that platform are probably up to patching
their glibc).

If it is only Debian on non-shipped platforms, it would be reasonable to
ask the Debian x64-64 people to apply the one-line patch to glibc pointed
to by the PR.  It could be a hassle for them now because of the sarge
freeze, though, so maybe fixincludes would be the way to go.

Bad link on webpage

[Marcus]

On the page, http://gcc.gnu.org/gcc-4.0/changes.html, the link 
http://www.nedprod.com/programs/gccvisibility.html (near the end of the 
document) contains

``DOMAIN HOLDING PAGE 

 This is a holding page for a domain registered by Total Registrations on 
behalf of a customer. At this present time the owner of the domain name has 
simply registered the name and has not chosen to host a web site or receive 
email through it. ''

Creating assembler comments from RTL

[HutchinsonAndy]

Is there a good way of creating an assembler comments directly from RTL?

I want to be able to  add debugging/explanation strings to assembler listing 
(GAS). Unfortunately I want to do this from RTL prologue and epilogue  (and 
thus avoid using TARGET_ASM_FUNCTION_EPILOGUE - where it would be easy!)

I know I could define a "psuedo" insn that finally creates assembler strings 
BUT I believe that would interfere with RTL optimisations.

-- 
Andy Hutchinson



__
Switch to Netscape Internet Service.
As low as $9.95 a month -- Sign up today at http://isp.netscape.com/register

Netscape. Just the Net You Need.

New! Netscape Toolbar for Internet Explorer
Search from anywhere on the Web and block those annoying pop-ups.
Download now at http://channels.netscape.com/ns/search/install.jsp

Re: Creating assembler comments from RTL

[DJ Delorie]

> Is there a good way of creating an assembler comments directly from RTL?
> 
> I want to be able to add debugging/explanation strings to assembler
> listing (GAS). Unfortunately I want to do this from RTL prologue and
> epilogue (and thus avoid using TARGET_ASM_FUNCTION_EPILOGUE - where
> it would be easy!)

You might get part of it through the TARGET_START_FUNCTION hook.

You can also define insns that use unspec or unspec_volatile, which
are generated as part of your prologue/epilogue, that use a C function
to emit themselves as assembler.  The C function can return a properly
formatted pattern that produces the comments you want in the final asm
file.

You could also hook ASM_OUTPUT_OPCODE to turn "keyword" opcodes from
those types of insns into full comments as needed.

Re: PR 19893 & array_ref bug

[Mark Mitchell]

Steve Ellcey wrote:
I was looking at PR 19893 (gcc.dg/vect/vect-76 fails on ia64-hpux) and I
think it is caused by a non-platform specific bug, though it may not
cause vect-76 to fail on other platforms.  I was hoping someone might be
able to help me understand what is going on.
Here is a cut down test case (with no vector stuff in it):
typedef int aint __attribute__ ((__aligned__(16)));
aint ib[12];
int ic[12], *x, *y;
int main (void)
{
  x = &ib[4];
  y = &ic[4];
}
If you look at the assembly language generated on IA64 (HP-UX or Linux)
or probably on any platform, you will see that 'y' gets correctly set to
the address of ic[4].  But 'x' gets set to ib[0], instead of ib[4].
Things look good in all the tree dumps but the first rtl dump looks bad
so I believe things are going wrong during expansion.  Looking in
tree.def I see:
/* Array indexing.
   Operand 0 is the array; operand 1 is a (single) array index.
   Operand 2, if present, is a copy of TYPE_MIN_VALUE of the index.
   Operand 3, if present, is the element size, measured in units of
   the alignment of the element type.  */
DEFTREECODE (ARRAY_REF, "array_ref", tcc_reference, 4)
Now I think this the problem is with operand 3.  What value should it
have if the alignment is greater than the element size? 
This program should generate an error; it's illogical.  If the alignment 
of the element is greater than the element size, then arrays of such a 
type should be disallowed.  Otherwise, stuff in either the compiler or 
the program itself could make the justified assumption that things of 
that type are aligned more strictly than they actually are.

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

RE: GCC 3.4.3 static constants, named sections, and -fkeep-static-consts

[Gary Funck]

> From: James E Wilson
> Sent: Tuesday, March 08, 2005 6:59 PM
[...]
> 
> Try re-reading the docs.  -fkeep-static-consts is the default.  The 
> purpose of this is that we don't perform this optimization at -O0 
> normally, but if you use -fno-keep-static-consts, then we do.  So this 
> option can let you remove static consts in extra cases, but will never 
> prevent the compiler from removing them.

Jim,

Thanks for the follow-up. I filed a bug report,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20319
and note #2 summarizes some relevant, conflicting facts:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20319#c2

The gist is the documentation describes the current behavior.
However, I don't think the current behavior is useful, and
it does not agree with comments in the source code, nor the
help line.

However, as you noted __attribute__ ((used)) works
well as a workaround, although it would be helpful if `used'
was added to the documentation as a supported attribute that
can be applied to variables.

I think that the switch name
-fkeep-static-consts might be more consistenly named if it
was given the opposite sense and named something like
-fdelete-unused-static-consts.  The idea here is that by
asserting the switch a particular optimization is _enabled_.
Thus the optimizations performed at each level can be consistently
enumerated by asserting a particular set of switches which enable
specific optimizations.  This would change the present user interface,
however, I doubt that anyone is making extensive use of the current
interface because at present only -fno-keep-static-consts, asserted
at -O0 (no optimization), actually changes the default behavior of
the compiler.