Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-18 13:52:01 +0200, Toon Moene wrote:
> Vincent Lefevre wrote:
> 
> >Saying that the x86 processor is buggy is just completely silly.
> >Only some gcc developers think so.
> 
> No, Kahan thinks so too (sorry, can't come up with a link just right 
> now).

I'd be very interested in such a link. That would mean that he changed
his mind and it would contradict some points given in "How Java's FP
Hurt Everyone Everywhere". He even seems to like x87, see page 61 for
instance (though I disagree with him on the advantages of extended
precision, for portability reasons).

>  The original plan for x87 extended precision floating point was 
> to have a small stack of 80-bit floats on the chip, and an interrupt to 
> the OS if more registers were needed than the number extant on the chip. 
>  The OS was then to provide the extra storage to "feign" the unlimited 
> number of 80-bit "registers".
> 
> Unfortunately, somewhere in the design process of the 8087 things went 
> wrong and the chip only handles 8 80-bit registers, not providing an 
> interrupt (or any other support) to an OS to fake the "virtual" 80-bit 
> registers.
> 
> Hence our problems.

Why? Even when the 8-register limit isn't reached, there are problems.
And I recall the problem: the fact that an extended-precision value of
type double is not rounded to double-precision after an assignment or
a cast. I don't see the relation with the 8-register limit.

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-18 15:51:50 +0200, Mattias Karlsson wrote:
> Anyway my point of view is that the solution to anyone needing
> strict IEEE semantics are:

You are wrong. IEEE allows extended precision. We are talking about
*ISO C99* semantics.

> 1) Use -float-store

Note: -ffloat-store. This is not a solution as it doesn't affect casts
(I haven't checked, but it was said by several GCC developers).

> 2) Use sse math

Not available everywhere, and not the default everywhere even when it
is available.

> 3) Learn to live without it.

Learn to live with buggy compilers?

> Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
> 1) Be a lot of work.
> 2) Cause a lot of regressions.

This remains to see. BTW, the Opteron uses SSE by default. Did you see
a lot of regressions?

Other solutions that would fix the bug (but not ultimate solutions):
1) Do not claim that gcc is a conforming ISO C implementation.
2) Output a diagnostic.

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-18 16:45:06 -0400, Robert Dewar wrote:
> Mattias Karlsson wrote:
> 
> >Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
> >1) Be a lot of work.
> >2) Cause a lot of regressions.
> 
> To this you can add
> 
>   3) generate less efficient code

Not by changing the rounding precision. Anyway this is not the point
here (i.e. to consider where the bug comes from).

>   4) cause some algorithms that work now to fail

Only non-portable ones (those designed for extended precision only).
And portable algorithms that didn't work will work after the fix.

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Mattias Karlsson]

On Sun, 19 Jun 2005, Vincent Lefevre wrote:


Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
1) Be a lot of work.
2) Cause a lot of regressions.


This remains to see. BTW, the Opteron uses SSE by default. Did you see
a lot of regressions?


Opteron is not an issue, when I talked about regressions above I dont mean 
only "My code give a diffrent answer" regressions but also "My code that 
uses both float/doubles is bigger and slower"

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-18 18:01:33 -0400, Robert Dewar wrote:
> Laurent GUERBY wrote:
> >If you code run in extra range issue then you'll get "expected"
> >results on x86 and it will fail everywhere else, a nice
> >way to detect those issues indeed (and you won't face
> >this if you developped your code on non x86).
> 
> That's not right, your algorithm may expect infinities in certain
> ranges, handle them right, and blow up if they are not generated,
> and vice versa. IEEE = IEEE, not some approximation thereof.

I don't understand your "IEEE = IEEE". To make things clearer:
IEEE 754 explicitly allows an extended exponent range. The ISO C
language doesn't. But this can be solved by stores, then there
wouldn't by any problem as far as the standards are concerned.

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

| Other solutions that would fix the bug (but not ultimate solutions):
| 1) Do not claim that gcc is a conforming ISO C implementation.

As far as I can see, there is no such claim.

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 10:59:24 +0200, Mattias Karlsson wrote:
> On Sun, 19 Jun 2005, Vincent Lefevre wrote:
> 
> >>Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
> >>1) Be a lot of work.
> >>2) Cause a lot of regressions.
> >
> >This remains to see. BTW, the Opteron uses SSE by default. Did you see
> >a lot of regressions?
> 
> Opteron is not an issue, when I talked about regressions above I
> dont mean only "My code give a diffrent answer" regressions but also
> "My code that uses both float/doubles is bigger and slower"

Not by the proposed solution "of changing x87 rounding modes".
Of course, this solution is not sufficient to completely fix the
bug (due to the exponent range), but it would solve most problems.
And concerning the solution with stores, then users would have to
learn to use compiler options. BTW, in this way, they could even
learn the existence of -ffast-math and have smaller and faster
programs! :)

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 11:12:49 +0200, Gabriel Dos Reis wrote:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> | Other solutions that would fix the bug (but not ultimate solutions):
> | 1) Do not claim that gcc is a conforming ISO C implementation.
> 
> As far as I can see, there is no such claim.

The standard says:

   __STDC__ The decimal constant  1,  intended  to  indicate  a
conforming implementation.

   __STDC_VERSION__ The decimal constant 199901L.138)

In my program, I have:

#if __STDC__ == 1 && __STDC_VERSION__ >= 199901 && defined(__STDC_IEC_559__)
  printf ("__STDC_IEC_559__ defined:\n"
  "The implementation shall conform to the IEEE-754 standard.\n"
  "FLT_EVAL_METHOD is %d (see ISO/IEC 9899, 5.2.4.2.2#7).\n",
  (int) FLT_EVAL_METHOD);
#endif
[...]

and it outputs:

__STDC_IEC_559__ defined:
The implementation shall conform to the IEEE-754 standard.
FLT_EVAL_METHOD is 2 (see ISO/IEC 9899, 5.2.4.2.2#7).
The IEEE-754 result is 9007199254740994 with double precision.
The IEEE-754 result is 9007199254740996 with extended precision.
The obtained result is 9007199254740996.

BUG:
The implementation doesn't seem to convert values to the target type after
an assignment (see ISO/IEC 9899: 5.1.2.3#12, 6.3.1.5#2 and 6.3.1.8#2[52]).

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Mattias Karlsson]

On Sun, 19 Jun 2005, Vincent Lefevre wrote:


Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
1) Be a lot of work.
2) Cause a lot of regressions.


This remains to see. BTW, the Opteron uses SSE by default. Did you see
a lot of regressions?


Opteron is not an issue, when I talked about regressions above I
dont mean only "My code give a diffrent answer" regressions but also
"My code that uses both float/doubles is bigger and slower"


Not by the proposed solution "of changing x87 rounding modes".
Of course, this solution is not sufficient to completely fix the
bug (due to the exponent range), but it would solve most problems.
And concerning the solution with stores, then users would have to
learn to use compiler options. BTW, in this way, they could even
learn the existence of -ffast-math and have smaller and faster
programs! :)


True, more people should try -ffast-math since on x87 it can give them 
more precisison and not less, with the nasty non-deterministic loss of 
that extra precission.



On the other hand, sysadmins refuse to install gcc versions past 3.3 at my 
institution (gcc is the default and only compiler available to students 
on non-windows machines) since "It's not binary compatible, and then we 
need an costly OS update". True, ABI changed in 3.3 but reading PR's I see 
that it only affects 64-bit code, and 64-bit libraries are not available 
anyway.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

| I don't understand your "IEEE = IEEE". To make things clearer:
| IEEE 754 explicitly allows an extended exponent range. The ISO C
| language doesn't. But this can be solved by stores, then there
| wouldn't by any problem as far as the standards are concerned.

Vincent --

  I recommend you google GCC's archive for past discussions on this
issue.  This is not the first time it is being discussed.  If I
remember correctly, core back-end people looked at it and concluded
that fixing it requires a *major* rewrite of the back-end, if at all
possible [1].  I read your paragraph above as suggesting that it would
be simple thing to fix.  It would be wonderful if that is true; would
you mind submitting a patch?

[1]:  http://gcc.gnu.org/ml/gcc/2003-08/msg01234.html
  http://gcc.gnu.org/ml/gcc/2003-08/msg01257.html

--- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

| On 2005-06-19 10:59:24 +0200, Mattias Karlsson wrote:
| > On Sun, 19 Jun 2005, Vincent Lefevre wrote:
| > 
| > >>Since the "gcc-is-buggy" solution of changing x87 rounding modes will:
| > >>1) Be a lot of work.
| > >>2) Cause a lot of regressions.
| > >
| > >This remains to see. BTW, the Opteron uses SSE by default. Did you see
| > >a lot of regressions?
| > 
| > Opteron is not an issue, when I talked about regressions above I
| > dont mean only "My code give a diffrent answer" regressions but also
| > "My code that uses both float/doubles is bigger and slower"
| 
| Not by the proposed solution "of changing x87 rounding modes".
| Of course, this solution is not sufficient to completely fix the
| bug (due to the exponent range), but it would solve most problems.

since you seem OK with that solution, would you mind preparing a patch?
(discussions are not executables; someone needs to make things happen.) 

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Haren Visavadia]

--- Gabriel Dos Reis wrote:
> Vincent Lefevre writes:
> 
> | Other solutions that would fix the bug (but not
> ultimate solutions):
> | 1) Do not claim that gcc is a conforming ISO C
> implementation.
> 
> As far as I can see, there is no such claim.

It's implied when using -std=c99




___ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

Re: basic VRP min/max range overflow question

[Kai Henningsen]

[EMAIL PROTECTED] (Florian Weimer)  wrote on 18.06.05 in <[EMAIL PROTECTED]>:

> * Paul Schlie:
>
> > So in effect the standard committee have chosen to allow any program which
> > invokes any undefined behavior to behave arbitrarily without diagnosis?
> >
> > This is a good thing?
>
> It's the way things are.  There isn't a real market for
> bounds-checking C compilers, for example, which offer well-defined
> semantics even for completely botched pointer arithmetic and pointer
> dereference.
>
> C isn't a programming language which protects its own abstractions
> (unlike Java, or certain Ada or Common Lisp subsets), and C never was
> intended to work this way.  Consequently, the committee was right to
> deal with undefined behavior in the way it did.  Otherwise, the
> industry would have adopted C as we know it, and the ISO C standard
> would have had the same relevance as, say, the ISO Pascal on the
> evolution of Pascal.

And yet, languages like ISO Pascal *still* define undefined behaviour  
pretty much the same way C does. They just choose a different set of  
situations (well, there *is* overlap) to apply it to.

Pretty much all languages which allow access to "the bare metal" need this  
escape clause, because making a program safe in that context pretty much  
requires the compiler to solve the halting problem or equivalent - and we  
can't do that. The alternative is putting enough padding between the  
program and the metal to enable the compiler and runtime system  
significantly more control - and, of course, giving the programmer  
significantly *less* control. For example, there won't be any type-punning  
in such a language. It's a very different trade-off.

MfG Kai

Re: basic VRP min/max range overflow question

[Kai Henningsen]

[EMAIL PROTECTED] (Robert Dewar)  wrote on 18.06.05 in <[EMAIL PROTECTED]>:

> Here is an interesting example I have used sometimes to indicate just
> how this kind of information can propagate in a manner that would result
> in unexpected chaos. (Ada but obvious analogies in other languages)
>
>
>-- process command to delete system disk, check password first
>
>loop
>   read (password)
>   if password = expected_password then
> delete_system_disk;
>   else
> complain_about_bad_password;
> npassword_attempts := npassword_attempts + 1;
> if npassword_attempts = 4 then
>abort_execution;
> end if;
>   end if;
>end loop;
>
> Now suppose that npassword_attempt is not initialized, and we are in a
> language where doing an operation on an uninitialized value is undefined,
> erroneous or whatever other term is used for undefined disaster.
>
> Now the compiler can assume that npassword_attempts is not referenced,
> therefore it can assume that the if check on password is true, therefore
> it can omit the password check AARGH!
>
> This kind of backward propagation of undefinedness is indeed worrisome,
> but it is quite difficult to create a formal definition of undefined
> that prevents it.

But at least, in that case, the compiler could easily issue the  
(presumably not required by the standard) warning that the else branch is  
"unreachable code".

1/2 :-)

MfG Kai

Re: basic VRP min/max range overflow question

[Robert Dewar]

Kai Henningsen wrote:

But at least, in that case, the compiler could easily issue the  
(presumably not required by the standard) warning that the else branch is  
"unreachable code".


Yes, absolutely, a compiler should generate warnings as much as possible when
it is making these kind of assujmptions. Sometimes this is difficult though,
because the unexpected actions emerge from the depths of complex optimization
algorithms that don't easily link back what they are doing to the source code.

Actually an easier warning here is that npassword_attempts is uninitialized.
That should be easy enough to generate (certainly GNAT would generate that
warning in this situation).

Working hard to generate good warnings is an important part of the compiler
writers job, even if it is quite outside the scope of the formal standard.
Being careful to look at warnings and not ignore them is an important part
of the programmers job :-)

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 11:42:04 +0200, Gabriel Dos Reis wrote:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> 
> | I don't understand your "IEEE = IEEE". To make things clearer:
> | IEEE 754 explicitly allows an extended exponent range. The ISO C
> | language doesn't. But this can be solved by stores, then there
> | wouldn't by any problem as far as the standards are concerned.
> 
> Vincent --
> 
>   I recommend you google GCC's archive for past discussions on this
> issue.  This is not the first time it is being discussed.  If I
> remember correctly, core back-end people looked at it and concluded
> that fixing it requires a *major* rewrite of the back-end, if at all
> possible [1].

OK, I'm not saying that this is simple. I'm just saying that it *can*
be solved. Even if the fix is complex, it is not a reason to mark the
bug as INVALID.

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
> since you seem OK with that solution, would you mind preparing a patch?
> (discussions are not executables; someone needs to make things happen.) 

This is complete non-sense. One doesn't prepare a patch for an invalid
bug.

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 11:17:47 +0100, Haren Visavadia wrote:
> --- Gabriel Dos Reis wrote:
> > Vincent Lefevre writes:
> > 
> > | Other solutions that would fix the bug (but not
> > ultimate solutions):
> > | 1) Do not claim that gcc is a conforming ISO C
> > implementation.
> > 
> > As far as I can see, there is no such claim.
> 
> It's implied when using -std=c99

Yes, and if GCC developers think it is better to lie concerning the
C standard comformance, this could be acceptable when such an option
is given, but this should be clearly documented. According to the man
page, this just means that the source is to be seen as C99 (what "the
compiler accepts").

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Steven Bosscher]

On Jun 19, 2005 12:55 PM, Vincent Lefevre <[EMAIL PROTECTED]> wrote:

> On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
> > since you seem OK with that solution, would you mind preparing a patch?
> > (discussions are not executables; someone needs to make things happen.) 
> 
> This is complete non-sense. One doesn't prepare a patch for an invalid
> bug.

What exactly do you want to _achieve_ with this thread?  Please, do tell,
because you've completely lost most of us by now, I'm sure.

I have re-closed PR323 now as SUSPENDED instead of INVALID because I find
the messages from Jim Wilson, that Gaby pointed us to, convincing enough
to admit that the problem is _also_ with gcc and not just with the x87
hardware. With a little serious effort on your part, you could have found
those messages as well.

But I'm fed up with the way you're participating in this discussion.  In
this mail I'm replying to, you say you don't want to prepare a patch for
a bug that is marked INVALID. But in your previous mail, and throughout
this discussion, you are arguing that the bug should not be marked INVALID
to begin with.

So by all means, pretty _please_, get your story consistent or quit arguing.
And frankly, I _do_ expect a patch from you, now that PR323 is no longer
marked invalid.  If you don't post a patch, that will be the ultimate proof
that you are just trolling here.

Gr.
Steven

Re: Libstdc++ versioning issues

[Mike Hearn]

On Tue, 14 Jun 2005 20:24:40 -0500, Benjamin Kosnik wrote:
> I'm testing a patch that resolves the issue. I expect to have additional
> details within 24 hrs, and will let you know details.

Is this bug #21405, or some other versioning issue?

thanks -mike

Bugzilla queries extremely slow

[Paolo Carlini]

Hi,

it looks like, today, even the simplest queries (by PR #) take forever
to complete. Any idea why?

Thanks,
Paolo.

Re: Libstdc++ versioning issues

[Paolo Carlini]

Mike Hearn wrote:

>On Tue, 14 Jun 2005 20:24:40 -0500, Benjamin Kosnik wrote:
>  
>
>>I'm testing a patch that resolves the issue. I expect to have additional
>>details within 24 hrs, and will let you know details.
>>
>>
>Is this bug #21405, or some other versioning issue?
>  
>
The issue that Benjamin just fixed is very simple to explain (much less
to fix ;) : some recently added exported symbols had the default v6
version, that is, 3.4.0, instead of 3.4.5.

Paolo.

Re: Bugzilla queries extremely slow

[Paolo Carlini]

Paolo Carlini wrote:

>it looks like, today, even the simplest queries (by PR #) take forever
>to complete. Any idea why?
>  
>
Works fine now, sorry for the false alarm: maybe just a temporary high load.

Paolo.

Re: Bugzilla queries extremely slow

[Daniel Berlin]

I cannot make sourceware faster, unfortunately :)

I can make sure all the queries are using the right indexes, etc, which
i do.

(I monitor index/key efficiency on the server, as well as number of temp
tables created, scanned, blah blah blah)


On Sun, 2005-06-19 at 15:04 +0200, Paolo Carlini wrote:
> Hi,
> 
> it looks like, today, even the simplest queries (by PR #) take forever
> to complete. Any idea why?
> 
> Thanks,
> Paolo.

Re: Bugzilla queries extremely slow

[Paolo Carlini]

Daniel Berlin wrote:

>I cannot make sourceware faster, unfortunately :)
>
>I can make sure all the queries are using the right indexes, etc, which
>i do.
>
>(I monitor index/key efficiency on the server, as well as number of temp
>tables created, scanned, blah blah blah)
>
Ok ;) FWIW, I can confirm that performance usually a pretty good for me.
That's why today I thought something was broken, not just somewhat slow.

Paolo.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

| On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
| > since you seem OK with that solution, would you mind preparing a patch?
| > (discussions are not executables; someone needs to make things happen.) 
| 
| This is complete non-sense. One doesn't prepare a patch for an invalid
| bug.

If you think it is an invalid bug, then it effectively is a complete
non-sense that you continue making noise on this list about it. 
FWIW, I would remind you that this is not news:fr.comp.lang.c.

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

Haren Visavadia <[EMAIL PROTECTED]> writes:

| --- Gabriel Dos Reis wrote:
| > Vincent Lefevre writes:
| > 
| > | Other solutions that would fix the bug (but not
| > ultimate solutions):
| > | 1) Do not claim that gcc is a conforming ISO C
| > implementation.
| > 
| > As far as I can see, there is no such claim.
| 
| It's implied when using -std=c99

I see.  Patch to reword the documentation are welcome.

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

| On 2005-06-19 11:17:47 +0100, Haren Visavadia wrote:
| > --- Gabriel Dos Reis wrote:
| > > Vincent Lefevre writes:
| > > 
| > > | Other solutions that would fix the bug (but not
| > > ultimate solutions):
| > > | 1) Do not claim that gcc is a conforming ISO C
| > > implementation.
| > > 
| > > As far as I can see, there is no such claim.
| > 
| > It's implied when using -std=c99
| 
| Yes, and if GCC developers think it is better to lie concerning the
| C standard comformance, this could be acceptable when such an option
| is given, but this should be clearly documented. According to the man
| page, this just means that the source is to be seen as C99 (what "the
| compiler accepts").

Now that you have equated GCC developers to liars, are you willing to
improve over the situation?

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Andrew Pinski]

On Jun 19, 2005, at 9:54 AM, Gabriel Dos Reis wrote:


Vincent Lefevre <[EMAIL PROTECTED]> writes:
| Yes, and if GCC developers think it is better to lie concerning the
| C standard comformance, this could be acceptable when such an option
| is given, but this should be clearly documented. According to the man
| page, this just means that the source is to be seen as C99 (what "the
| compiler accepts").

Now that you have equated GCC developers to liars, are you willing to
improve over the situation?


Also I think GCC is not the one who is defining it either.  It is glibc
who is defining that so complain to them instead.

-- Pinski

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 15:47:58 +0200, Gabriel Dos Reis wrote:
> If you think it is an invalid bug, then it effectively is a complete
> non-sense that you continue making noise on this list about it. 

I've never said that I thought it was an invalid bug.

> FWIW, I would remind you that this is not news:fr.comp.lang.c.

I remind it you too.

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

| On 2005-06-19 15:47:58 +0200, Gabriel Dos Reis wrote:
| > If you think it is an invalid bug, then it effectively is a complete
| > non-sense that you continue making noise on this list about it. 
| 
| I've never said that I thought it was an invalid bug.

Then, care to explain

   On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
   > since you seem OK with that solution, would you mind preparing a patch?
   > (discussions are not executables; someone needs to make things happen.) 

   This is complete non-sense. One doesn't prepare a patch for an invalid
   bug.

?

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 13:16:33 +0200, Steven Bosscher wrote:
> What exactly do you want to _achieve_ with this thread?  Please, do tell,
> because you've completely lost most of us by now, I'm sure.

Just that the problem should be considered as a bug, and not a bug
in the users' code (for some of them), nor a bug in x86 (a bad design
if you want).

> I have re-closed PR323 now as SUSPENDED instead of INVALID because I find

Thank you very much. Note that you're "re-closed" is incorrect because
a SUSPENDED bug is still open (but suspended); look at bugzilla's
documentation... This is important for the above reasons and also
because users will be able to see this bug when searching on bugzilla
(let's hope that this will reduce future duplicates).

> the messages from Jim Wilson, that Gaby pointed us to, convincing
> enough to admit that the problem is _also_ with gcc and not just
> with the x87 hardware. With a little serious effort on your part,
> you could have found those messages as well.

Well, there have been many useful comments in PR323 and duplicates,
but have always been ignored.

> But I'm fed up with the way you're participating in this discussion.  In
> this mail I'm replying to, you say you don't want to prepare a patch for
> a bug that is marked INVALID. But in your previous mail, and throughout
> this discussion, you are arguing that the bug should not be marked INVALID
> to begin with.

There's no contradiction. The bug shouldn't be marked as INVALID,
and there shouldn't be patches as long as it is marked as INVALID.
That's what I meant.

> So by all means, pretty _please_, get your story consistent or quit
> arguing. And frankly, I _do_ expect a patch from you, now that PR323
> is no longer marked invalid. If you don't post a patch, that will be
> the ultimate proof that you are just trolling here.

No, because as some other users said too, INVALID bugs make people
don't feel the need to write patches. Now, *if* I write a patch
(fixing the bug in some way), will it be accepted, even if people
don't like it? (If they don't like it, they could write a better
patch after all.)

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Michael Veksler]

[EMAIL PROTECTED] wrote on 19/06/2005 18:33:55:

> Vincent Lefevre <[EMAIL PROTECTED]> writes:
>
> | On 2005-06-19 15:47:58 +0200, Gabriel Dos Reis wrote:
> | > If you think it is an invalid bug, then it effectively is a complete
> | > non-sense that you continue making noise on this list about it.
> |
> | I've never said that I thought it was an invalid bug.
>
> Then, care to explain
>
>On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
>> since you seem OK with that solution, would you mind preparing a
patch?
>> (discussions are not executables; someone needs to make things
happen.)
>
>This is complete non-sense. One doesn't prepare a patch for an invalid
>bug.
>
> ?
>
> -- Gaby

I think that what Vincent meant was:
"One doesn't prepare a patch for a PR marked as INVALID".

Re: Libstdc++ versioning issues

[Mike Hearn]

On Sun, 19 Jun 2005 15:06:58 +0200, Paolo Carlini wrote:
> The issue that Benjamin just fixed is very simple to explain (much less
> to fix ;) : some recently added exported symbols had the default v6
> version, that is, 3.4.0, instead of 3.4.5.

Ah I see :) 

Are the new symbols new APIs, or will pre-existing code compiled with GCC
3.4.5 depend on these symbols when they would not have done when compiled
with GCC 3.4.0?

Also, is anybody looking at bug #21405? This bug makes the symbol
versioning not so useful - to successfully distribute C++ apps on Linux we
have had to resort to a binary diffing/cross-build system so the user gets
a binary built with the right ABI installed. This problem affects games a
lot, because they tend to use SDL and libSDL dlopens sound drivers
according to the environment. When SDL dlopens the aRTS driver, you get
both libstdc++.so.5 and libstdc++.so.6 versions mixed into the same binary
and the symbol versioning is not enough to stop them conflicting.

thanks -mike

Re: Libstdc++ versioning issues

[Paolo Carlini]

Mike Hearn wrote:

>Are the new symbols new APIs, or will pre-existing code compiled with GCC
>3.4.5 depend on these symbols when they would not have done when compiled
>with GCC 3.4.0?
>  
>
AFAICS, there are no problems whatsover, because version 3.4.5 is *new*
in 4.0.1.

Paolo.

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Andrew Pinski]

Thank you very much. Note that you're "re-closed" is incorrect because
a SUSPENDED bug is still open (but suspended); look at bugzilla's
documentation... This is important for the above reasons and also
because users will be able to see this bug when searching on bugzilla
(let's hope that this will reduce future duplicates).


Note this bug was not marked as invalid by some random bug master
but by RTH, one of the core GCC developers, and there was a reason
why it was because it is a bug which cannot fixed so easily.  Maybe
will not fix would be better but since at the time, we using gnats
which did not have "will not fix", it got marked as invalid instead.
Also note the description of this "bug" is on the non-bug part of
the bug reporting page and we still get dups.  In fact we get dups
of other real non-bugs dealing with C/C++ aliasing rule violation
so we will still get bugs for this one too.

Quote from bugs.html:

Problems with floating point numbers - the most often reported non-bug.


In a number of cases, GCC appears to perform floating point 
computations incorrectly. For example, the C++ program


#include 

int main()
{
  double a = 0.5;
  double b = 0.01;
  std::cout << (int)(a / b) << std::endl;
  return 0;
}



might print 50 on some systems and optimization levels, and 49 on 
others.



This is the result of rounding: The computer cannot represent all real 
numbers exactly, so it has to use approximations. When computing with 
approximation, the computer needs to round to the nearest representable 
number.



This is not a bug in the compiler, but an inherent limitation of the 
floating point types. Please study this paper for more information.


-- Pinski

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 15:54:20 +0200, Gabriel Dos Reis wrote:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> | Yes, and if GCC developers think it is better to lie concerning the
> | C standard comformance, this could be acceptable when such an option
> | is given, but this should be clearly documented. According to the man
> | page, this just means that the source is to be seen as C99 (what "the
> | compiler accepts").
> 
> Now that you have equated GCC developers to liars, are you willing to
> improve over the situation?

I haven't said that. Sorry if I wasn't clear enough. I meant that
the gcc implementation lies about C standard comformance, and
showed an example. Concerning the documentation, I'll put that
on my todo list (now that I know a little more about what gcc
does and when). You can see I've already posted comments on the
documentation:

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

But I'm not a GCC developer and doesn't know the GCC internals
(I can just see the effects). So, producing a correct documentation
could be a bit difficult for me.

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

| On 2005-06-19 13:16:33 +0200, Steven Bosscher wrote:
| > What exactly do you want to _achieve_ with this thread?  Please, do tell,
| > because you've completely lost most of us by now, I'm sure.
| 
| Just that the problem should be considered as a bug, and not a bug
| in the users' code (for some of them), nor a bug in x86 (a bad design
| if you want).
| 
| > I have re-closed PR323 now as SUSPENDED instead of INVALID because I find
| 
| Thank you very much. Note that you're "re-closed" is incorrect because
| a SUSPENDED bug is still open (but suspended); look at bugzilla's
| documentation... This is important for the above reasons and also
| because users will be able to see this bug when searching on bugzilla
| (let's hope that this will reduce future duplicates).

Vincent --
   
   You can make a difference by helping yourself, creating a bugzilla
account, adding comments and modifying PR status based on informed facts.

[...]

| There's no contradiction. The bug shouldn't be marked as INVALID,
| and there shouldn't be patches as long as it is marked as INVALID.
| That's what I meant.

Is that a GCC development policy or a new rule you would like people
to adopt?

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 09:57:33 -0400, Andrew Pinski wrote:
> Also I think GCC is not the one who is defining it either. It is
> glibc who is defining that so complain to them instead.

Thanks for the information (I'm a bit surprised because these are gcc
command-line options that are the first cause of these definitions).
Is there a way to know what gcc defines and what glibc defines?

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

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

Michael Veksler <[EMAIL PROTECTED]> writes:

| [EMAIL PROTECTED] wrote on 19/06/2005 18:33:55:
| 
| > Vincent Lefevre <[EMAIL PROTECTED]> writes:
| >
| > | On 2005-06-19 15:47:58 +0200, Gabriel Dos Reis wrote:
| > | > If you think it is an invalid bug, then it effectively is a complete
| > | > non-sense that you continue making noise on this list about it.
| > |
| > | I've never said that I thought it was an invalid bug.
| >
| > Then, care to explain
| >
| >On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
| >> since you seem OK with that solution, would you mind preparing a
| patch?
| >> (discussions are not executables; someone needs to make things
| happen.)
| >
| >This is complete non-sense. One doesn't prepare a patch for an invalid
| >bug.
| >
| > ?
| >
| > -- Gaby
| 
| I think that what Vincent meant was:
| "One doesn't prepare a patch for a PR marked as INVALID".

Then let me explain my previous message.  Either

  (1) Vincent thinks it is an invalid bug, then

 http://gcc.gnu.org/ml/gcc/2005-06/msg00818.html

  (2) or Vincent thinks it is NOT an invalid bug, then

 http://gcc.gnu.org/ml/gcc/2005-06/msg00803.html

Vincent can help himself changing the status of PRs, based on informed
facts. And in effect, that just happened to that very PR.  If the only
thing that was stopping him from producing a patch was the status of
the PR, then now that it changed I expect patch from him. 

-- Gaby

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Gabriel Dos Reis]

Vincent Lefevre <[EMAIL PROTECTED]> writes:

| On 2005-06-19 09:57:33 -0400, Andrew Pinski wrote:
| > Also I think GCC is not the one who is defining it either. It is
| > glibc who is defining that so complain to them instead.
| 
| Thanks for the information (I'm a bit surprised because these are gcc
| command-line options that are the first cause of these definitions).
| Is there a way to know what gcc defines and what glibc defines?

As a first approximation, you can start with the assumption that
anything having to do with the C standard library is expected to be
provided by the target system library.  GCC does some transformations
based on the standard semantics -- look for the so-called "built-ins"
in the documentation.  The options are sometime needed for the target
library to profide some functionalities, so that means that it is
close do impossible for GCC to know when a switch is selected by 
User L. but is not honored by the target library.

-- Gaby

Re: towards reduction part 3/n: what does vec lower pass do to vector shifts?

[Dorit Naishlos]

> why??
>

The problem is that in 'expand_vector_operations_1()' in
tree-vect-generic.c we call 'optab_for_tree_code()' to get an optab for
VEC_RSHIFT_EXPR; 'optab_for_tree_code' does not have a case for
VEC_RSHIFT_EXPR, so the vector-lowering function concludes that this
tree-code is not supported, and expands it into the code I showed before.

To my understanding 'optab_for_tree_code' never promised anyone to provide
full information for all tree-codes. It even says so explicitely: "This
function is not always usable (for example, it cannot give complete results
for multiplication or division)". So, either (1)
'expand_vector_operations_1' needs to find a different way to query if a
tree code is supported, or, (2) if there is an expectation that
'optab_for_tree_code' handles all tree-codes, then we need to add the
missing info, and to start with passing it the tree expression itself, not
just the tree code, because at least for the vector-shift case I need to
check that the shift operand is constant, and only then return
optab_shri/shli. For now, to work around this problem until we decide on
the proper approach I did the following: (3)

Index: optabs.c
===
RCS file: /cvs/gcc/gcc/gcc/optabs.c,v
retrieving revision 1.281
diff -u -3 -p -r1.281 optabs.c
--- optabs.c18 Jun 2005 13:18:37 -  1.281
+++ optabs.c19 Jun 2005 16:26:29 -
@@ -301,7 +301,15 @@ optab_for_tree_code (enum tree_code code
   return TYPE_UNSIGNED (type) ? reduc_umin_optab : reduc_smin_optab;

 case REDUC_PLUS_EXPR:
-  return reduc_plus_optab;
+  return TYPE_UNSIGNED (type) ? reduc_uplus_optab : reduc_splus_optab;
+
+case VEC_LSHIFT_EXPR:
+  /* FIXME: this optab is appropriate only if second argument is
constant.  */
+  return vec_shli_optab;
+
+case VEC_RSHIFT_EXPR:
+  /* FIXME: this optab is appropriate only if second argument is
constant.  */
+  return vec_shri_optab;

 default:
   break;

This is safe for now, because at the only place where we generate these
vector shifts we do that using constants shift amounts. Would this be ok
for now, until 'expand_vector_operations_1' or 'optab_for_tree_code' are
fixed?

thanks,

dorit

> I'm preparing the third part of the reduction support for mainline,
> introducing vector shifts (see
> http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01317.html). The vectorizer
> generates the following epilog code:
>
>   vect_var_.53_60 = vect_var_.50_59 v>> 64;
>   vect_var_.53_61 = vect_var_.50_59 + vect_var_.53_60;
>   vect_var_.53_62 = vect_var_.53_61 v>> 32;
>   vect_var_.53_63 = vect_var_.53_61 + vect_var_.53_62;
>   vect_var_.52_64 = BIT_FIELD_REF ;
>
> and the next pass, vec_lower2 transforms that into the following:
>
>   D.2057_108 = BIT_FIELD_REF ;
>   D.2058_109 = BIT_FIELD_REF <64, 32, 0>;
>   D.2059_110 = D.2057_108 v>> D.2058_109;
>   D.2060_111 = BIT_FIELD_REF ;
>   D.2061_112 = BIT_FIELD_REF <64, 32, 32>;
>   D.2062_113 = D.2060_111 v>> D.2061_112;
>   D.2063_114 = BIT_FIELD_REF ;
>   D.2064_115 = BIT_FIELD_REF <64, 32, 64>;
>   D.2065_116 = D.2063_114 v>> D.2064_115;
>   D.2066_117 = BIT_FIELD_REF ;
>   D.2067_118 = BIT_FIELD_REF <64, 32, 96>;
>   D.2068_119 = D.2066_117 v>> D.2067_118;
>   vect_var_.53_60 = {D.2059_110, D.2062_113, D.2065_116, D.2068_119};
>   vect_var_.53_61 = vect_var_.50_59 + vect_var_.53_60;
>   D.2069_120 = BIT_FIELD_REF ;
>   D.2070_121 = BIT_FIELD_REF <32, 32, 0>;
>   D.2071_122 = D.2069_120 v>> D.2070_121;
>   D.2072_123 = BIT_FIELD_REF ;
>   D.2073_124 = BIT_FIELD_REF <32, 32, 32>;
>   D.2074_125 = D.2072_123 v>> D.2073_124;
>   D.2075_126 = BIT_FIELD_REF ;
>   D.2076_127 = BIT_FIELD_REF <32, 32, 64>;
>   D.2077_128 = D.2075_126 v>> D.2076_127;
>   D.2078_129 = BIT_FIELD_REF ;
>   D.2079_130 = BIT_FIELD_REF <32, 32, 96>;
>   D.2080_131 = D.2078_129 v>> D.2079_130;
>   vect_var_.53_62 = {D.2071_122, D.2074_125, D.2077_128, D.2080_131};
>   vect_var_.53_63 = vect_var_.53_61 + vect_var_.53_62;
>   vect_var_.52_64 = BIT_FIELD_REF ;
>
>
> why??
>
> thanks,
> dorit
>

Re: towards reduction part 3/n: what does vec lower pass do to vector shifts?

[Richard Henderson]

On Sun, Jun 19, 2005 at 07:36:15PM +0300, Dorit Naishlos wrote:
> ... because at least for the vector-shift case I need to
> check that the shift operand is constant, and only then return
> optab_shri/shli.

This isn't true.  Just because the altivec patterns don't accept
anything other than a constant doesn't mean that the pattern can't
be valid for other operands.  The operation is completely specified
by its code.

Adding the operations to optab_for_tree_code is the right approach.

Ideally we'd also update tree-vect-generic to handle this new operation;
its behaviour with this code at present is actively wrong.  For the
moment we should add an assert

---
compute_type = TREE_TYPE (type);
}

+ gcc_assert (code != VEC_LSHIFT_EXPR && code != VEC_RSHIFT_EXPR);
  rhs = expand_vector_operation (bsi, type, compute_type, rhs, code);
  if (lang_hooks.types_compatible_p (TREE_TYPE (lhs), TREE_TYPE (rhs)))
---

which should verify that we only generate this operation when we have
the expectation that the backend will handle it.


r~

Re: towards reduction part 3/n: what does vec lower pass do to vector shifts?

[Dorit Naishlos]

Richard Henderson <[EMAIL PROTECTED]> wrote on 19/06/2005 19:49:46:
> On Sun, Jun 19, 2005 at 07:36:15PM +0300, Dorit Naishlos wrote:
> > ... because at least for the vector-shift case I need to
> > check that the shift operand is constant, and only then return
> > optab_shri/shli.
>
> This isn't true.  Just because the altivec patterns don't accept
> anything other than a constant doesn't mean that the pattern can't
> be valid for other operands.  The operation is completely specified
> by its code.

Altivec does support non immediate shift amount (even if less efficiently -
I have to put the shift amount in a vector register first). But since we
have defined these optabs to represent shift operations that take immediate
shift amount, I shouldn't be returning vec_shli/vec_shri if the shift is
not constant. I could return a "vec_shl_optab"/"vec_shr_optab" that
supported a general shift amount if we wanted to introduce these optabs (in
addition, or instead of "vec_shli_optab/vec_shri_optab"). (For the
vectorizer, immediate shifts would suffice).

>
> Adding the operations to optab_for_tree_code is the right approach.
>
> Ideally we'd also update tree-vect-generic to handle this new operation;
> its behaviour with this code at present is actively wrong.  For the
> moment we should add an assert
>
> ---
> compute_type = TREE_TYPE (type);
> }
>
> + gcc_assert (code != VEC_LSHIFT_EXPR && code != VEC_RSHIFT_EXPR);
>   rhs = expand_vector_operation (bsi, type, compute_type, rhs, code);
>   if (lang_hooks.types_compatible_p (TREE_TYPE (lhs), TREE_TYPE (rhs)))
> ---
>
> which should verify that we only generate this operation when we have
> the expectation that the backend will handle it.
>

ok,

thanks,

dorit

>
> r~

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Vincent Lefevre]

On 2005-06-19 17:33:55 +0200, Gabriel Dos Reis wrote:
> Then, care to explain
> 
>On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote:
>> since you seem OK with that solution, would you mind preparing a patch?
>> (discussions are not executables; someone needs to make things happen.) 
> 
>This is complete non-sense. One doesn't prepare a patch for an invalid
>bug.
> 
> ?

By "an invalid bug", I meant "a bug marked as invalid" (I thought every
one would have understood with the context). Is that clear now?

Concerning about reopening it, I didn't feel the need since some other
users tried before (and gave good reasons), without any success (see
the last duplicates for instance).

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

question about match_operand and vec_select

[Ling-hua Tseng]

I noticed that the (vec_select:m ...) couldn't be matched by (match_operand:m 
...).
For example:
  (set (vec_select:HI (reg:V4QI r3)
  (parallel [(const_int 0) (const_int 1)]))
   (const_int 0x1122))
couldn't be matched by:
 [(set (match_operand:HI 0 "register_operand" "=R")
   (match_operand 1 "const_int_operand" "i"))]

Only the RTL templates which contained explicit (vec_select:HI ...) are matched.

Is the situation natural and right?

Thanks a lot.

Re: towards reduction part 3/n: what does vec lower pass do to vector shifts?

[Richard Henderson]

On Sun, Jun 19, 2005 at 08:00:22PM +0300, Dorit Naishlos wrote:
> Altivec does support non immediate shift amount (even if less efficiently -
> I have to put the shift amount in a vector register first). But since we
> have defined these optabs to represent shift operations that take immediate
> shift amount, I shouldn't be returning vec_shli/vec_shri if the shift is
> not constant.

I think this is a bit silly; unless we have a good reason I don't think
we should define different optabs for constant/non-constant shift counts.


r~

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Joseph S. Myers]

On Sun, 19 Jun 2005, Vincent Lefevre wrote:

> On 2005-06-19 11:12:49 +0200, Gabriel Dos Reis wrote:
> > Vincent Lefevre <[EMAIL PROTECTED]> writes:
> > | Other solutions that would fix the bug (but not ultimate solutions):
> > | 1) Do not claim that gcc is a conforming ISO C implementation.
> > 
> > As far as I can see, there is no such claim.
> 
> The standard says:
> 
>__STDC__ The decimal constant  1,  intended  to  indicate  a
> conforming implementation.
> 
>__STDC_VERSION__ The decimal constant 199901L.138)

I would have hoped the documentation (trouble.texi, "Undefining 
@code{__STDC__} when @option{-ansi} is not used.") would have been clearly 
enough applicable here.  The standard only relates to conforming 
compilers, the definitions for compilers aiming towards conformance but 
not there yet (-std=c89, -ansi, -std=c99 etc.) and for compilers not 
aiming towards conformance are a pragmatic matter only.

As in standards.texi, GCC *aims towards* being usable as a conforming 
freestanding implementation,   The support is not feature-complete as 
regards C99 and not fully correct as regards either C90 or C99.  There is 
no claim to be free from bugs, or free from known bugs, as regards 
conformance, and I do not believe bug-free compilers (or popular compilers 
free from known bugs) exist.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: basic VRP min/max range overflow question

[Paul Schlie]

> From: Robert Dewar <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>>> From: "Joseph S. Myers" <[EMAIL PROTECTED]>
>>> "no requirements" means that *any* translation conforms in the case of
>>> undefined behavior.  Only those executions not involving undefined
>>> behavior have any requirements.
>> 
>> What delineates the bounds between undefined and non-undefined behaviors?
>> 
>> (As in the extreme if an undefined behavior may arbitrarily corrupt the
>> entire specified program state, and/or modify the languages otherwise
>> required semantics governing the translation/execution of a program, it
>> would seem that rather than attempting to utilize undefined behaviors as
>> a basis of optimizations, the compiler should more properly simply abort
>> compilation upon their detection, as the resulting program would be
>> otherwise be arguably useless for any likely purpose if the effect of an
>> undefined behavior within a program is not bounded?)
> 
> But of COURSE you can't detect these situations at compile time. Even
> if you had all the input in advance, this would be trivially equivalent
> to solving the halting problem. Programming language definitions reserve
> this use of undefined PRECISELY for those cases where it cannot be
> determined statically whether some rule in the dynamic semantic
> definition is or is not met.
> 
> When a compiler can determine that a given construct is sure to result
> in undefined behavior, e.g. it can prove at compile time that overflow
> will always occur, then indeed the best approach is to abort, or raise
> some kind of exception (depending on the language), and to generate a
> warning at compile time that this is going on. It CAN NOT "abort
> compilation", since this is not an error condition, it would be improper
> to refuse to compile the program. Besides which it would in practice
> be wrong, since the compiler may very well be able to tell that a given
> statement IF EXECUTED will cause trouble, but be unable to tell if in
> fact it will be executed (my password program is like this, a friendly
> compiler would warn that the reference to npasswords_entered (or whatever
> I called it) results in undefined behavior, and an attentive programmer
> who does not ignore warnings will deal with this warning before the
> program causes chaotic results.

The root of the concern being expressed is with respect to the compilers use
of statically identified undefined behaviors as opportunities to invoke
alternative semantics which are easily identified as being inconsistent with
the target's native semantics, thus altering the logical behavior of the
program than would otherwise have resulted. (without any halting solutions
required)

As candidly, regardless of this being technically allowed, it should obvious
that any optimization which may likely alter the behavior of a program
should never be invoked without explicit request and ideally diagnosis of
the resulting alternative possibly undesired and/or fatal behavior.

To be more clear, specifically as examples:

- As VRP relies on the static analysis of value ranges, primarily based
on embedded implicit and/or explicit constant values which enables the
detection of both bound ranges and potential value range overflows, this
information may be used to both identify both known safe optimizations,
as well as those known to be potentially unsafe based upon the easily
identifiable true overflow behavior of the target. Therefore is seems
clear that the most desirable default behavior for VRP based optimizations
would be to only enable those which are known to be safe (i.e. not alter
the behavior of the resulting program, nor requires a halting problem be
solved), by default; and enable through an explicit command line switch
the presumption that no integer overflows will occur, with optionally the
warning diagnosis of all locations were potential overflow was identified
and may result in differing program behavior. (Again no halting problems
need to solved)

- Correspondingly, as pointer null comparison optimizations are known to be
unsafe for targets which are known to not trap null-pointer dereferences,
this optimization should only be enabled by default for targets which are
known to do so (regardless of if it's perceived to be "technically allowed",
as it should be obvious that any optimization which will identifiably alter
program behavior should never be invoked by default at any optimization
level without explicit request and optional corresponding diagnosis).

As just my opinion, and possibly the opinion of many who've ever cursed
the result of an optimization's altering a program's logical behavior
(which I can't imagine as ever being desirable in any circumstance, as
optimizations should ideally eliminate logical redundancies, not alter
logical semantics, without explicit request).

Re: GCC 4.0.1 RC2

[Jakub Jelinek]

On Sat, Jun 18, 2005 at 11:46:42AM -0700, Mark Mitchell wrote:
> Benjamin Kosnik wrote:
> >>Please test this version and report problems in Bugzilla, with a Cc:
> >>to me. I'd also appreciate explicit confirmation from a representative
> >>of the libstdc++ team that this version as packaged still has the
> >>desired behavior, just to catch any packaging snafus.
> >
> >
> >This version looks correct to me. Thanks!
> 
> Would you please comment on PR 22111?  This is apparently a new 
> testsuite failure from the changes.

PR 22111 is about libstdc++-v3 being built with binutils 2.15, while
2.15.90 or later are required by the patch.  But as seen on hppa,
even 2.15.90 is at least on some arches not enough.
The problem is still the one I have tried to explain to Paolo in
http://gcc.gnu.org/ml/gcc-patches/2005-06/msg01421.html
Although what is ATM in CVS avoids doing that for 4 of the symbols
that need to be dual exported (@GLIBCXX_3.4 and @@GLIBCXX_3.4.5),
it does not avoid that for the remaining 22 symbols and clearly
it makes many linkers (apparently all I have tried < 2.15.90
and from recent PR also latest hppa GNU ld) very unhappy.

Below is a patch that makes sure all the 26 symbols in compatibility.cc
are renamed, rather than just the 4 that makes even current CVS crash
on all architectures.
I admit it is fragile, the renaming using #define is quite brutal hack,
as the #define can't selectively apply only to some occurences of the name
that needs to be renamed, but with current libstdc++-v3 it works properly
and exports the same symbols as current CVS, and is linkable even by far
older binutils (tried current CVS, 2.15.94.0.2.2 and 2.14.90.0.4, but
really, what it wants from the linker is what is glibc using for years).

The alternative is to add _GLIBCXX_SYMVER_COMPATIBILITY
renames like ATM include/bits/char_traits.h has to the remaining 22
templates, which would be cleaner thing for compatibility.cc, but
further uglification of the installed headers.

2005-06-19  Jakub Jelinek  <[EMAIL PROTECTED]>

* src/compatibility.cc (_GLIBCXX_SYMVER_COMPATIBILITY): Remove.
(istreambuf_iterator, basic_fstream, basic_ifstream, basic_ofstream,
_M_copy, _M_move, _M_assign, _M_disjunct, _M_check_length,
_M_set_length_and_sharable, ignore, eq): Define to XX suffixed
variants.
(ignore (streamsize)): Remove _W prefixed aliases.
(_GLIBCXX_3_4_SYMVER_SPECIAL, _GLIBCXX_3_4_5_SYMVER_SPECIAL,
_GLIBCXX_APPLY_SYMVER_SPECIAL): Remove.
(_GLIBCXX_3_4_SYMVER, _GLIBCXX_3_4_5_SYMVER): Add XXname argument.
Use #XXname instead of #name as the alias argument.
* config/abi/compatibility.h: Replace uses of
_GLIBCXX_APPLY_SYMVER_SPECIAL with _GLIBCXX_APPLY_SYMVER.  Always
pass 2 arguments to the _GLIBCXX_APPLY_SYMVER macro.
* include/bits/char_traits.h (char_traits::eq): Revert 2005-06-15
change.
* acinclude.m4: Decrease glibcxx_min_gnu_ld_version back to 21400.
* configure: Rebuilt.

--- libstdc++-v3/src/compatibility.cc.jj2005-06-18 04:15:05.0 
-0400
+++ libstdc++-v3/src/compatibility.cc   2005-06-19 02:52:31.0 -0400
@@ -31,7 +31,18 @@
 #include 
 
 #if defined(_GLIBCXX_SYMVER) && defined(PIC)
-# define _GLIBCXX_SYMVER_COMPATIBILITY 1
+#define istreambuf_iterator istreambuf_iteratorXX
+#define basic_fstream basic_fstreamXX
+#define basic_ifstream basic_ifstreamXX
+#define basic_ofstream basic_ofstreamXX
+#define _M_copy(a, b, c) _M_copyXX(a, b, c)
+#define _M_move(a, b, c) _M_moveXX(a, b, c)
+#define _M_assign(a, b, c) _M_assignXX(a, b, c)
+#define _M_disjunct(a) _M_disjunctXX(a)
+#define _M_check_length(a, b, c) _M_check_lengthXX(a, b, c)
+#define _M_set_length_and_sharable(a) _M_set_length_and_sharableXX(a)
+#define ignore ignoreXX
+#define eq eqXX
 #endif
 
 #include 
@@ -42,27 +53,6 @@
 namespace std
 {
   // std::istream ignore explicit specializations.
-#if defined(_GLIBCXX_SYMVER) && defined(PIC)
-  template<>
-basic_istream&
-basic_istream::ignore(streamsize __n) 
-#ifdef _GLIBCXX_PTRDIFF_T_IS_INT
-asm ("_W_ZNSi6ignoreEi");
-#else
-asm ("_W_ZNSi6ignoreEl");
-#endif
-
-#ifdef _GLIBCXX_USE_WCHAR_T
-  template<>
-basic_istream&
-basic_istream::ignore(streamsize __n)
-#ifdef _GLIBCXX_PTRDIFF_T_IS_INT
- asm ("_W_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEi");
-#else
- asm ("_W_ZNSt13basic_istreamIwSt11char_traitsIwEE6ignoreEl");
-#endif
-#endif
-#endif // _GLIBCXX_SYMVER && PIC
 
   template<>
 basic_istream&
@@ -347,43 +337,27 @@ namespace std
 // In the future, GLIBCXX_ABI > 6 should remove all uses of
 // _GLIBCXX_*_SYMVER macros in this file.
 
-#define _GLIBCXX_3_4_SYMVER(name) \
-   extern "C" void \
-   _X##name() \
-   __attribute__ ((alias(#name))); \
-   asm (".symver " "_X" #name "," #name "@GLIBCXX_3.4");
-
-#define _GLIBCXX_3_4_5_SYMVER(name) \
-   extern "C" void \
-   _Y##name() \
-   __attribute__ ((alias(#name))); \
-   

Re: Reporting bugs: there is nothing to gain in frustrating reporters

[Marcin Dalecki]

On 2005-06-19, at 17:59, Vincent Lefevre wrote:


On 2005-06-19 09:57:33 -0400, Andrew Pinski wrote:


Also I think GCC is not the one who is defining it either. It is
glibc who is defining that so complain to them instead.



Thanks for the information (I'm a bit surprised because these are gcc
command-line options that are the first cause of these definitions).
Is there a way to know what gcc defines and what glibc defines?


For GCC, sure, yes. GLIBC: certainly NO. To be more precise:
It's only possible in a time-span which exceeds the MTBF of an  
developer.

Re: Libstdc++ versioning issues

[John David Anglin]

> AFAICS, there are no problems whatsover, because version 3.4.5 is *new*
> in 4.0.1.

See .  This is
also .

This is probably a bug in binutils but I don't have a warm fuzzy
feeling about this.  I have done some debugging of the problem.
It appears that PLABEL relocations aren't being correctly handled
for versioned symbols.  However, it's not clear why we have a PLABEL
relocation for the symbol _ZNSt11char_traitsIcE2eqERKcS2_@@GLIBCXX_3.4.5
in the first place.

Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

Re: Libstdc++ versioning issues

[Paolo Carlini]

John David Anglin wrote:

>>AFAICS, there are no problems whatsover, because version 3.4.5 is *new*
>>in 4.0.1.
>>
>>
>See .  This is
>also .
>
>This is probably a bug in binutils but I don't have a warm fuzzy
>feeling about this.  I have done some debugging of the problem.
>It appears that PLABEL relocations aren't being correctly handled
>for versioned symbols.  However, it's not clear why we have a PLABEL
>relocation for the symbol _ZNSt11char_traitsIcE2eqERKcS2_@@GLIBCXX_3.4.5
>in the first place.
>  
>
I have nothing technically interesting to say about these specific
issues and, in any case, people like Jakub and Benjamin are much more
expert than me in this area.

However, please don't point out these issues citing my sentence of
earlier today. That's misleading: I was only replying to Mike Hearn's
concerns about incompatibilities between different versions of the
library and certainly Mike was not interested in binutils issues and
possible linker bugs.

Paolo.

Re: some compile problem about gcc-2.95.3

[Kai Ruottu]

Steven J. Hill kirjoitti:


zouqiong wrote in 15.4.2005 10:16:


> i download the release version of gcc-2.95.3, and binutils 2.15,
> then i did the following things:
> 1. mkdir binutils-build;
> .../../binutils-2.15/configure --prefix=/opt/gcc
> --target=mipsel-linux -v;
> make;make install;
>
> 2.i copy the o32 lib, o32 include to the /opt/gcc/mipsel-linux/lib,
> /opt/gcc/mipsel-linux/include,
>
> 3. mkdir gcc-build;
> .../../gcc-2.95.3/configure --prefix=/opt/gcc --target=mipsel-linux
> --enable-languages=c --disable-checking -enable-shared -v;
>

i am surprised about it.


 I am surprised where this message lied since 15.4.2005 before appearing
now...


You seem surprised, and I am terrified you are using a compiler that
old. Please go look at:

   http://kegel.com/crosstool/

which automatically builds cross toolchains and even still has
scripts to build your ancient (IMHO) combination.


... but much more I am surprised why anyone here could advice people,
who would like to get petrol to their old custom ancient cars, to get
gasoline and a modern fully standard car (but self-built from standard
parts) where to use that gasoline...

Re: towards reduction part 3/n: what does vec lower pass do to vector shifts?

[Dorit Naishlos]

Richard Henderson <[EMAIL PROTECTED]> wrote on 19/06/2005 20:33:02:
> On Sun, Jun 19, 2005 at 08:00:22PM +0300, Dorit Naishlos wrote:
> > Altivec does support non immediate shift amount (even if less
efficiently -
> > I have to put the shift amount in a vector register first). But since
we
> > have defined these optabs to represent shift operations that take
immediate
> > shift amount, I shouldn't be returning vec_shli/vec_shri if the shift
is
> > not constant.
>
> I think this is a bit silly; unless we have a good reason I don't think
> we should define different optabs for constant/non-constant shift counts.
>

The thought was to supply an API that would let the vectorizer ask for the
minimal capability it needs - if all we need is a vector shift of a
constant value in bytes, lets ask exactly for that, so that targets that
don't support non-constant shifts, or that support only byte shifts, could
also enjoy this feature.
A general vector shift that can take both constant and non-constant counts
is indeed more general, and maybe what we prefer to have at the tree level.
In this case, targets that can't tell the vectorizer that they can support
general vector shifts, but could have told the vectorizer that they support
an immediate vector shift, will just have to implement the REDUC_OP
directly (using immediate vector shifts) in their machine description.

dorit

>
> r~

Re: some compile problem about gcc-2.95.3

[Kai Ruottu]

zouqiong kirjoitti:


.../../gcc-2.95.3/configure --prefix=/opt/gcc --target=mipsel-linux
--enable-languages=c --disable-checking -enable-shared -v;


 This is not true at all 


-B=/opt/gcc-2.95//mipsel-linux/bin/
-I=/opt/gcc-2.95//mipsel-linux/include


 Because these rows tell that a '--prefix=/opt/gcc-2.95/' was used 


as: unrecognized option `-O2'


 The assembler, 'as', was tried to be used from the chosen
'$prefix/$target/bin', here '/opt/gcc-2.95//mipsel-linux/bin/', but not 
 found from it.


i am surprised about it. 


 I'm not... Using different $prefix values in the binutils configure and
the GCC configure is a quite common newbie mistake... Maybe because some
people really believe GCC being a human being and therefore having the
'$target-as' and '$target-ld' being in PATH being enough... The opsys
will find them when a human being uses them, so also GCC must find them
or how?

 Those who have opened the GCC manual or tried the '-print-search-dirs'
option with GCC, don't believ anything like that...

Re: c/c++ validator

[Tommy Vercetti]

On Sunday 19 June 2005 04:48, Gabriel Dos Reis wrote:
> Mathieu Malaterre <[EMAIL PROTECTED]> writes:
> | Gabriel Dos Reis wrote:
> | > Tommy Vercetti <[EMAIL PROTECTED]> writes:
> | > | On Sunday 19 June 2005 03:03, you wrote:
> | > | > Elsa does not parse C++.
> | > |
> | > | Elsa is for C/C++, so it says on their website.
> | >
> | > I know what the website says.  My comment was about the actual *uses*
> | > of the parser.  Have you tried it on actual C++ programs?

They claim it does compile qt, and they work on making it compile KDE. That's 
enough for me. 
On free software "market" there is lack of good static checker/validator of 
c++ code. 
I was looking on different ones, for C, that claimed to have ability to find 
security problems. One that I found the best, is splint. But it's still not 
able to find such obvious problem:

char a[10];
for( unsigned int i; i< 100 ; i++ ) {
a[i]=a[i]+1;
}

Even thou, it analyzes buffers, and other stuff. So...
Plus it can't do that for c++. 
It shouldn't be so hard, if they have code that gathers so much information 
already, and can find infinite loops, even not easy cases..

Elsa parses c++ code well enough for me, to at least try to write some code 
that will do something like that. Elsa thou has one potential problem, it's 
on bsd licence. Licence issues sux. 
You can't take some code from splint, and stick it into bsd code. I guess, but 
I maybe wrong. I don't even think that it will work from design point of 
view.

> | How about gccxml:
> |
> | http://www.gccxml.org
>
> It is a not C++ parser :-) -- if you're interested in function bodies
> and other more fundamental things, you lose.  It suffers from the same
> problems (at least ones we've found quite annoying) of using GCC
> currently:  too much of low-level stuff directly geared to code
> generation as understood by GCC now, and C++ programs are not
> represented at the most abstract level (contrast that with a
> celebrated C++ front-end on the market).  And it also shares problems
> with Elsa, no real support for templates (although the case of Elsa is
> slightly "worse" :-)).  Now, if you're just interested in simple
> "toplevel" decls, then that might be fine :-)

gccxml parser is a good idea maybe, but I don't think it's good for what I am 
looking for.

-- 
Vercetti

Re: GCC 4.0.1 RC2

[Geoffrey Keating]

Mark Mitchell <[EMAIL PROTECTED]> writes:

> GCC 4.0.1 RC2 is now available here:
> 
>ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050616
> 
> This version has the libstdc++ versioning changes, and most of the PO
> file updates.  The PO file that Joseph checked in today is not
> included, but will be in the final release.
> 
> Please test this version and report problems in Bugzilla, with a Cc:
> to me.  I'd also appreciate explicit confirmation from a
> representative of the libstdc++ team that this version as packaged
> still has the desired behavior, just to catch any packaging snafus.
> 
> With luck, I'll announce the final release during the summit next week...

RC2 seems to be good on powerpc-darwin8,



compared to



except that the testcase

libstdc++-v3/testsuite/26_numerics/cmath/c99_classification_macros_c.cc

appears to fail, with lots of complaints like

c99_classification_macros_c.cc:49:21: error: macro "isgreaterequal" requires 2 
arguments, but only 1 given

but the actual file did this with previous versions too, I think
something changed in the test harness.  As far as I can tell, this
testcase is in fact invalid and should produce exactly this error
message.

Re: towards reduction part 3/n: what does vec lower pass do to vector shifts?

[Richard Henderson]

On Sun, Jun 19, 2005 at 11:46:52PM +0300, Dorit Naishlos wrote:
> The thought was to supply an API that would let the vectorizer ask for the
> minimal capability it needs - if all we need is a vector shift of a
> constant value in bytes, lets ask exactly for that, so that targets that
> don't support non-constant shifts, or that support only byte shifts, could
> also enjoy this feature.

Hmm.  In theory we could get this information out of the predicates
on the expander, but it wouldn't be very clean.

> A general vector shift that can take both constant and non-constant counts
> is indeed more general, and maybe what we prefer to have at the tree level.
> In this case, targets that can't tell the vectorizer that they can support
> general vector shifts, but could have told the vectorizer that they support
> an immediate vector shift, will just have to implement the REDUC_OP
> directly (using immediate vector shifts) in their machine description.

At present I believe that most targets implement general shifts.  Lets
just go with that for now.  As you say -- there's always a fallback
option available.


r~

Re: GCC 4.0.1 RC2

[Gabriel Dos Reis]

Geoffrey Keating <[EMAIL PROTECTED]> writes:

| libstdc++-v3/testsuite/26_numerics/cmath/c99_classification_macros_c.cc
| 
| appears to fail, with lots of complaints like
| 
| c99_classification_macros_c.cc:49:21: error: macro "isgreaterequal" requires 
2 arguments, but only 1 given
| 
| but the actual file did this with previous versions too, I think
| something changed in the test harness.  As far as I can tell, this
| testcase is in fact invalid and should produce exactly this error
| message.

Why?

(I only thing I see wrong, right now is that the function definitions
should be part of a class, instead of being at the global scope).

-- Gaby

libstdc++-libc6.1-1.so.2 libraries

[Bill]

Below is the error I receive when attempting to run a newly installed
version of netscape 4.79 on centOS 4.0 (RHEL 3), which is my personal
computer at home. This is the only browser that works on linux that is
compatible with the Thorium installer for BMC Patrol. I downloaded the
browser from netscapes website browser archive and used the
prepackaged installer script with all defaults.

[EMAIL PROTECTED] ~]$ cd /opt/netscape
[EMAIL PROTECTED] netscape]$ ./netscape
./netscape: error while loading shared libraries:
libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file
or directory

To correct this I intend to install the necessary libraries. At this
point I'm only guessing and have googled my way to the conclusion that
I need to install libstdc++2.9-glibc2.1 to get the
libstdc++-libc6.1-1.so.2 libraries for this version of netscape to
run. I am fairly certain that I did not install properly but even so
if the libraries were there, shouldn't they be somewhere in the
directory I installed this in (maybe not and please don't bother
responding if this is too moronic to answer)? The command I used to
search for this is:

ls -la /usr/lib/gcc2/libstdc++-libc6.1-1.so.2 
ls -la /usr/local/bin/libstdc++-libc6.1-1.so.2 

/usr/lib/gcc2 is the objdir I built it in. I followed the installation
instructions exactly with using only the default settings. The only
setting I entered was the objdir ( objdir is /usr/lib/gcc2 ). Below
are the exact steps I took.

Extracted tarball to /home/bill/files/gcc/gcc-2.95.3
mkdir /usr/lib/gcc2
cd /usr/lib/gcc2
/home/bill/files/gcc/gcc-2.95.3/configure
make bootstrap
make install

This is the output from running /home/bill/files/gcc/gcc-2.95.3/config.guess
i686-pc-linux-gnu

The reason I used /usr/lib/gcc2 was because the instuctions sounded
like you could install two versions of gcc and make a symbolic link
between them. I assumed the current version of gcc libraries would be
in /usr/lib and just wanted to keep them together. If none of this
makes any sense please do not attemt to make any out of it and let me
know if this is even the correct package to install to get the
libstdc++-libc6.1-1.so.2 libraries on my system...or just let me know
where to download the right thing if it is even part of gccIf you
are able to please let me know how to get this installed onto my
system. Thanks in advance!

Bill

Re: GCC 4.0.1 RC2

[Geoff Keating]

On 19/06/2005, at 3:45 PM, Gabriel Dos Reis wrote:


Geoffrey Keating <[EMAIL PROTECTED]> writes:

| libstdc++-v3/testsuite/26_numerics/cmath/ 
c99_classification_macros_c.cc

|
| appears to fail, with lots of complaints like
|
| c99_classification_macros_c.cc:49:21: error: macro  
"isgreaterequal" requires 2 arguments, but only 1 given

|
| but the actual file did this with previous versions too, I think
| something changed in the test harness.  As far as I can tell, this
| testcase is in fact invalid and should produce exactly this error
| message.

Why?

(I only thing I see wrong, right now is that the function definitions
should be part of a class, instead of being at the global scope).


The testcase includes math.h, which we've said should supply the C99  
functions (or, in this case, macros) even in C++ mode.  C99 says that  
'isgreaterequal' is a macro which takes 2 arguments.




smime.p7s
Description: S/MIME cryptographic signature

Re: GCC 4.0.1 RC2

[Gabriel Dos Reis]

Geoff Keating <[EMAIL PROTECTED]> writes:

| On 19/06/2005, at 3:45 PM, Gabriel Dos Reis wrote:
| 
| > Geoffrey Keating <[EMAIL PROTECTED]> writes:
| >
| > | libstdc++-v3/testsuite/26_numerics/cmath/
| > c99_classification_macros_c.cc
| > |
| > | appears to fail, with lots of complaints like
| > |
| > | c99_classification_macros_c.cc:49:21: error: macro
| > "isgreaterequal" requires 2 arguments, but only 1 given
| > |
| > | but the actual file did this with previous versions too, I think
| > | something changed in the test harness.  As far as I can tell, this
| > | testcase is in fact invalid and should produce exactly this error
| > | message.
| >
| > Why?
| >
| > (I only thing I see wrong, right now is that the function definitions
| > should be part of a class, instead of being at the global scope).
| 
| The testcase includes math.h, which we've said should supply the C99

 is also mandated by C++.  Clearly, this is a tricky area and
I do not believe the testcase is invalid (except as I noted earlier).

| functions (or, in this case, macros) even in C++ mode.  C99 says that
| 'isgreaterequal' is a macro which takes 2 arguments.

C++ says that no functional macros (except assert) shall be active.
Which leads to interesting games we're playing in the V3 headers to
make sure those are not active.  The C++ TR1 which include proposals
to extend  to C99 features also mandate non-functional macros.
See what we do with .

-- Gaby

Getting to the gcc summit

[Daniel Kegel]

For those who are attending the gcc summit for the first time,
here's a page with a bit more detail about how to
get from the airport to the hotel, etc.
   http://kegel.com/gcc/summit2005.html
It's pretty easy, but I remember figuring it out
the first time was harder, so I figured a page
of notes and links might come in handy for some folks.

Re: c/c++ validator

[David Bremner]

I complied this list for the local C++ users group several months ago, 
it might be helpful.

http://www.nwcpp.org/Misc/Tools_DavidBremner.html

Regards,
David Bremner

Re: basic VRP min/max range overflow question

[Robert Dewar]

Paul Schlie wrote:


The root of the concern being expressed is with respect to the compilers use
of statically identified undefined behaviors as opportunities to invoke
alternative semantics which are easily identified as being inconsistent with
the target's native semantics, thus altering the logical behavior of the
program than would otherwise have resulted. (without any halting solutions
required)


You are still not understanding, these are NOT cases of "statically
identified undefined behavior". Those are the trivial cases that are
uninterestig.


As candidly, regardless of this being technically allowed, it should obvious
that any optimization which may likely alter the behavior of a program
should never be invoked without explicit request and ideally diagnosis of
the resulting alternative possibly undesired and/or fatal behavior.


If the behavior is undefined, then it is undefined, and you cannot
talk about a change in behavior. This is what non-deterministic semantics
is about.


To be more clear, specifically as examples:

- As VRP relies on the static analysis of value ranges, primarily based
on embedded implicit and/or explicit constant values which enables the


It most certainly is NOT possible to statically identify situations that
cause overflow. I cannot believe this is not clear to you.

gcc 4.0.1 (prerelease): new libstdc++ testsuite failures on sparc-linux

[Christian Joensson]

Looking at http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00837.html,
LAST_UPDATED: Sun Jun 12 16:16:31 UTC 2005, and this
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01121.html,
LAST_UPDATED: Fri Jun 17 08:33:08 UTC 2005 (and the later one
http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01191.html), I notice
a few new libstdc++ testsuite failures:

FAIL: abi_check
FAIL: 21_strings/basic_string/find/char/1.cc execution test
FAIL: 21_strings/basic_string/find/wchar_t/1.cc execution test
FAIL: 22_locale/time_put/put/char/3.cc execution test
FAIL: 22_locale/time_put/put/char/wrapped_env.cc execution test
FAIL: 22_locale/time_put/put/char/wrapped_locale.cc execution test
FAIL: 22_locale/time_put/put/wchar_t/3.cc execution test
FAIL: 22_locale/time_put/put/wchar_t/wrapped_env.cc execution test
FAIL: 22_locale/time_put/put/wchar_t/wrapped_locale.cc execution test
FAIL: 27_io/basic_filebuf/imbue/wchar_t/12868.cc execution test

Are these to expect and accept?


-- 
Cheers,

/ChJ

Error building 4.0.1-RC2

[Mark Williams (MWP)]

Thought i should report this...

Building 4.0.1 RC2, i get this error:

make[1]: Leaving directory `/data/backup/linux/gcc/gcc-4.0.1-20050616/intl'
make[1]: Entering directory
`/data/backup/linux/gcc/gcc-4.0.1-20050616/build-i686-pc-linux-gnu/libiberty'
make[1]: *** No rule to make target `../include/ansidecl.h', needed by 
`regex.o'.  Stop.
make[1]: Leaving directory
`/data/backup/linux/gcc/gcc-4.0.1-20050616/build-i686-pc-linux-gnu/libiberty'
make: *** [all-build-libiberty] Error 2

Anything else you guys need to know?

Mark W.

Re: Error building 4.0.1-RC2

[Eric Christopher]

On Mon, 2005-06-20 at 15:02 +0930, Mark Williams (MWP) wrote:
> Thought i should report this...
> 
> Building 4.0.1 RC2, i get this error:
> 
> make[1]: Leaving directory `/data/backup/linux/gcc/gcc-4.0.1-20050616/intl'
> make[1]: Entering directory
> `/data/backup/linux/gcc/gcc-4.0.1-20050616/build-i686-pc-linux-gnu/libiberty'
> make[1]: *** No rule to make target `../include/ansidecl.h', needed by 
> `regex.o'.  Stop.
> make[1]: Leaving directory
> `/data/backup/linux/gcc/gcc-4.0.1-20050616/build-i686-pc-linux-gnu/libiberty'
> make: *** [all-build-libiberty] Error 2
> 
> Anything else you guys need to know?

Configure command? I'll assume the host was i686-pc-linux-gnu.

In this case I'll bet you built in the source directory?

-eric

Re: Error building 4.0.1-RC2

[Mark Williams (MWP)]

>On Mon, 2005-06-20 at 15:02 +0930, Mark Williams (MWP) wrote:
>> Thought i should report this...
>> 
>> Building 4.0.1 RC2, i get this error:
>> 
>> make[1]: Leaving directory `/data/backup/linux/gcc/gcc-4.0.1-20050616/intl'
>> make[1]: Entering directory
>> `/data/backup/linux/gcc/gcc-4.0.1-20050616/build-i686-pc-linux-gnu/libiberty'
>> make[1]: *** No rule to make target `../include/ansidecl.h', needed by
>> `regex.o'.  Stop.
>> make[1]: Leaving directory
>> `/data/backup/linux/gcc/gcc-4.0.1-20050616/build-i686-pc-linux-gnu/libiberty'
>> make: *** [all-build-libiberty] Error 2
>> 
>> Anything else you guys need to know?
>
>Configure command? I'll assume the host was i686-pc-linux-gnu.
>
>In this case I'll bet you built in the source directory?

Yes i did... i always do and have never had a problem doing so before.
I will try building in a different directory though and report back.

Configure was:
./configure --prefix=/usr --enable-languages="c,c++"

Compiling with GCC 4.0.0, latest version GNU make.

BTW, can you CC to me please, im not on the list.

Thanks.

Re: Error building 4.0.1-RC2

[Eric Christopher]

> 
> Yes i did... i always do and have never had a problem doing so before.
> I will try building in a different directory though and report back.

http://gcc.gnu.org/install/configure.html

To be honest I'm always surprised when it works at all.

-eric

Re: basic VRP min/max range overflow question

[Paul Schlie]

> From: Robert Dewar <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>> The root of the concern being expressed is with respect to the compilers use
>> of statically identified undefined behaviors as opportunities to invoke
>> alternative semantics which are easily identified as being inconsistent with
>> the target's native semantics, thus altering the logical behavior of the
>> program than would otherwise have resulted. (without any halting solutions
>> required)
> 
> You are still not understanding, these are NOT cases of "statically
> identified undefined behavior". Those are the trivial cases that are
> uninterestig.

OK, assuming I may misunderstand, the following is my understanding:

- presently if GCC STATICALLY identifies a pointer dereference which
  precedes a pointer null comparison, it presumes that the comparison may
  be optimized away under the rationalization that preceding dereference
  would be trapped, and if not, rationalizes that an undefined behavior
  grants it permission do what it wants regardless of the fact that it
  is only safe (logically equivalent) to do so for targets which are known
  to trap null dereferences.

- given the following code fragment:

  int x, y;
  volatile z;

  x = z ? 1 : 2;// x == [1, 2]
  y = z ? z + x;// y == [INT_MIN+1, INT_MAX+2]

  if (x < 0)// which may be safely optimized away as
somthing(); // [1, 2] is STATICALLY known to be never < 0.

  if (y == INT_MIN) // which may not be safely optimized away unless
something();// it is known that the target does not wrap overflow.

My position is simply that an optimization should never remove a specified
operation unless it is known to yield logically equivalent behavior, as
producing a program which does not behave as specified is not a good idea,
to be polite, unless specifically requested to do so; as if the programmer
didn't intend the code to be evaluated, it wouldn't have been specified;
regardless of the compilers presumed license to do what ever it pleases
when encountering a STATICALLY identified/potential undefined behavior.


>> As candidly, regardless of this being technically allowed, it should obvious
>> that any optimization which may likely alter the behavior of a program
>> should never be invoked without explicit request and ideally diagnosis of
>> the resulting alternative possibly undesired and/or fatal behavior.
> 
> If the behavior is undefined, then it is undefined, and you cannot
> talk about a change in behavior. This is what non-deterministic semantics
> is about.

I guess I simply believe that optimizations should never alter the logical
behavior of a specified program relative to it's un-optimized form unless
explicitly granted permission to do so, therefore such optimizations should
never be considered enabled at any level of optimization by default.

As I personally I believe the unbounded liberty to arbitrary alter the
logical evaluation of program statements/expressions distinct from those
which are considered undefined without explicit permission is misguided.

As it's likely more useful/important that optimizations preserve the
behavior of even non-portable programs, than it likely useful/important
to produce a faster program which may have an arbitrary different behavior.

>> To be more clear, specifically as examples:
>> 
>> - As VRP relies on the static analysis of value ranges, primarily based
>> on embedded implicit and/or explicit constant values which enables the
> 
> It most certainly is NOT possible to statically identify situations that
> cause overflow. I cannot believe this is not clear to you.

Actually it is (or we may be talking about different things, see below).

But regardless, what's important is identifying those with predicable value
ranges, as they are the only ones which may be safely used for optimizations
i.e.:

Known no overflow:
 [1, 4] = [0, 1] + [1, 3];   // safe to use as a basis of VRP optimization.

Possible overflow:
 [?, ?] = [0, 1] + [0, INT_MAX]; // unsafe without OverFlow knowledge.

~[INT_MIN+1, -1] = [0, 1] + [0, INT_MAX] // safe with 2's comp OvF.

Known overflow:
 [?, ?] = [INT_MAX-1 INT_MAX] + INT_MAX; // unsafe without OvF knowledge.

 [-3, -2] = [INT_MAX-1, INT_MAX] + INT_MAX; // known safe with 2's comp OvF

(What undefined overflow semantics should really be utilized to provide is
target specific overflow optimization based on a targets native overflow
semantics, which would be a whole lot more useful than pretending otherwise
and risk altering the programs otherwise un-optimized behavior.)

Again, just my opinion (as after all, undefined semantics enable the
compiler to do anything, so might as well do something more useful than not
:)

Re: Error building 4.0.1-RC2

[Mark Williams (MWP)]

> 
> > 
> > Yes i did... i always do and have never had a problem doing so before.
> > I will try building in a different directory though and report back.
> 
> http://gcc.gnu.org/install/configure.html
> 
> To be honest I'm always surprised when it works at all.

Ok, that fixed it, thanks.

Maybe a warning should be included in the configure script that is shown when
poeple do run configure from the gcc source root?

Thanks again,
 Mark W.

PATCH: PR/1025: binutils failed to build gcc 4.0.1 20050619

[H. J. Lu]

This patch fixes PR/1025. It also shows up on many platforms where
indirect symbols aren't handled properly, like

http://gcc.gnu.org/ml/gcc/2005-06/msg00842.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22109

Those platforms need similar patch.


H.J.
-
2005-06-19  H.J. Lu  <[EMAIL PROTECTED]>

PR 1025:
* elf32-i386.c (elf_i386_check_relocs): Handle indirect symbol.
* elf64-x86-64.c (elf64_x86_64_check_relocs): Likewise.

--- bfd/elf32-i386.c.got2005-06-18 10:16:12.0 -0700
+++ bfd/elf32-i386.c2005-06-19 23:03:13.0 -0700
@@ -924,7 +924,12 @@ elf_i386_check_relocs (bfd *abfd,
   if (r_symndx < symtab_hdr->sh_info)
h = NULL;
   else
-   h = sym_hashes[r_symndx - symtab_hdr->sh_info];
+   {
+ h = sym_hashes[r_symndx - symtab_hdr->sh_info];
+ while (h->root.type == bfd_link_hash_indirect
+|| h->root.type == bfd_link_hash_warning)
+   h = (struct elf_link_hash_entry *) h->root.u.i.link;
+   }
 
   r_type = elf_i386_tls_transition (info, r_type, h == NULL);
 
--- bfd/elf64-x86-64.c.got  2005-06-18 10:16:12.0 -0700
+++ bfd/elf64-x86-64.c  2005-06-19 23:05:34.0 -0700
@@ -677,7 +677,12 @@ elf64_x86_64_check_relocs (bfd *abfd, st
   if (r_symndx < symtab_hdr->sh_info)
h = NULL;
   else
-   h = sym_hashes[r_symndx - symtab_hdr->sh_info];
+   {
+ h = sym_hashes[r_symndx - symtab_hdr->sh_info];
+ while (h->root.type == bfd_link_hash_indirect
+|| h->root.type == bfd_link_hash_warning)
+   h = (struct elf_link_hash_entry *) h->root.u.i.link;
+   }
 
   r_type = elf64_x86_64_tls_transition (info, r_type, h == NULL);
   switch (r_type)

Re: Error building 4.0.1-RC2

[Ranjit Mathew]

Mark Williams (MWP) wrote:
> Thought i should report this...
> 
> Building 4.0.1 RC2, i get this error:
> 
> make[1]: Leaving directory `/data/backup/linux/gcc/gcc-4.0.1-20050616/intl'

Looks like you're trying to build GCC in the source
folder itself - this is not supported (yet).

Try creating a separate build folder totally outside
of the expanded source tree and run configure
and then make there.

HTH,
Ranjit.

-- 
Ranjit Mathew  Email: rmathew AT gmail DOT com

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