Re: GCC 3.3.1 -O2 problem with sqrt.c

[Sanjiv Kumar Gupta]

Ian Lance Taylor wrote:


Sanjiv Kumar Gupta <[EMAIL PROTECTED]> writes:



I am using gcc 3.3.1 release as my port, and looks
like I have hit a problem with greg.



You neglected to mention what target you are using.


Ian, the port is for a 32-bit RISC and not complete yet,
hence still not contributed.
This probably makes difficult for you to suggest any
fix, but I still asked in case I could get any pointers
for investigation.




I couldn't understand why the insns 620 and 621 are
being generated here as DI moves.



I'm not sure specifically why it got a DI move here, but it doesn't
look wrong.  It's treating the struct named parts as DImode.



This is creating problem since insn 621 gets splitted
after reload into two SI moves,i.e. @(r21, -8) and
@(r21, -4).
This renders insns 619 as dead and hence insns 618 and
insn 429 as dead, which are eliminated by flow2.



It does look rather suspicious, but it's hard to know whether it is
wrong without seeing the value in r1.


r1 looks unrelated to struct members, and is being used by the
ifcvt pass to expand some comparison insns.



Does the behaviour change if you use -fno-strict-aliasing?  (I can't
remember what the default was in 3.3.1).

Ian

The behaviour doesn't changes with -fno-strict-aliasing or 
-fstrict-aliasing.


Thanks
Sanjiv

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

[Daniel Berlin]

On Mon, 2005-05-30 at 07:59 +0300, Michael Veksler wrote:
> 
> 
> 
> 
> 
> Daniel Berlin <[EMAIL PROTECTED]> wrote on 30/05/2005 06:41:54:
> 
> > On Sun, 2005-05-29 at 12:50 +0200, Giovanni Bajo wrote:
> > > Michael Veksler <[EMAIL PROTECTED]> wrote:
> > >
> > > > 3. Nontrivial search of GCC Bugzilla are, sometimes,
> > > >extremely slow (over a minute).
> > >
> > > 3 could be worked on (Daniel?)
> >
> > Send me the URL's for the buglists and i'll look at the queries (The url
> > for the buglist contains the query).
> >
> > A lot of this is mysql's query engine being stupid, and is hopefully
> > fixed in 4.x or 5.x (sourceware is still on 3.x).
> >
> > I'm happy to optimize the searchs as best i can (by adding lame extra
> > indexes if necessary :P)
> 
> It is difficult to reproduce because behavior changes over time.
> 2 hours ago I was getting time-out even for:
>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21808
> 
> Now, it takes about 2 seconds.
> 
> Here is a synthetic test query that take only 15 seconds ATM:
> 
> http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=float-store+ICE&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=CLOSED&emailassigned_to1=1&emailreporter1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=

I should also note 2 things
1. that new hardware will help both these queries (mysql requires a
filesort for this one, and thus it will be heavily affected by i/o load,
which is usually pretty high on sourceware :( )


I'm still looking into what can be done in the meanwhile, of course.


2. Nobody in this thread has ever emailed me, or gcc@, before now,
complaining about bugzilla UI/speed/etc

You guys really should learn to complain more if you want things fixed.

:)

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

[Daniel Berlin]

On Mon, 2005-05-30 at 07:59 +0300, Michael Veksler wrote:
> 
> 
> 
> 
> 
> Daniel Berlin <[EMAIL PROTECTED]> wrote on 30/05/2005 06:41:54:
> 
> > On Sun, 2005-05-29 at 12:50 +0200, Giovanni Bajo wrote:
> > > Michael Veksler <[EMAIL PROTECTED]> wrote:
> > >
> > > > 3. Nontrivial search of GCC Bugzilla are, sometimes,
> > > >extremely slow (over a minute).
> > >
> > > 3 could be worked on (Daniel?)
> >
> > Send me the URL's for the buglists and i'll look at the queries (The url
> > for the buglist contains the query).
> >
> > A lot of this is mysql's query engine being stupid, and is hopefully
> > fixed in 4.x or 5.x (sourceware is still on 3.x).
> >
> > I'm happy to optimize the searchs as best i can (by adding lame extra
> > indexes if necessary :P)
> 
> It is difficult to reproduce because behavior changes over time.
> 2 hours ago I was getting time-out even for:
>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21808

This may be server load in that case (new hardware is in the process of
being acquired).

> 
> Now, it takes about 2 seconds.
> 
> Here is a synthetic test query that take only 15 seconds ATM:
> 
> http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=float-store+ICE&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=CLOSED&emailassigned_to1=1&emailreporter1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=

Comment searches don't currently take advantage of the fulltext index on
the comments, and mysql isn't particulary good at them.
I'm looking into it.

question in generating rtl code

[zouq]

in gcc-3.4.1
 rtl  can be generated when parsing the source program,
for example,
stmt:
  compstmt
{ stmt_count++; $$ = $1; }
| expr ';'
{ stmt_count++;
  $$ = c_expand_expr_stmt ($1); }

while in c_expand_body, rtl can also be generated .
what are they respectively for?

while in gcc-2.95.3,
i can`t find the function c_expand_body,
does it mean that all the rtl are generated by the c-parse.y
(except for the expand_function_end, end expand_function_start)?

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

[Vincent Lefevre]

On 2005-05-30 00:31:44 -0400, Daniel Berlin wrote:
[http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809]
> Compiling the code there with icc gives us:
> 
> [EMAIL PROTECTED]:~> icc icca.c
> icca.c(7): warning #1572: floating-point equality and inequality
> comparisons are unreliable
> assert(a == x);
> ^

icc is not a good example concerning the warnings. I've been told
that it issues too many annoying warnings, not just related to FP.

> ./[EMAIL PROTECTED]:~> ./a.out
> a.out: icca.c:7: main: Assertion `a == x' failed.
> Aborted

Here, according to the C standard (even if IEEE-754 isn't supported),
the code shouldn't fail.

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

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

[Vincent Lefevre]

On 2005-05-29 23:59:39 -0400, Daniel Berlin wrote:
> On Sun, 2005-05-29 at 18:19 +0300, Michael Veksler wrote:
> > If more than 50 people report it, independently, as a bug then it
> > sure is a bug.
> 
> Which is why it's still open!

It isn't (it was marked as INVALID).

> The problem with 323 isn't that we don't think it's really a bug,

In this case, it shouldn't have been marked as INVALID.

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

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

[Vincent Lefevre]

On 2005-05-29 13:22:55 +0300, Michael Veksler wrote:
> Two examples come in mind:
> 1. Non conformance of x86 to the standard FP due to
>its extra precision.

Wrong. The IEEE-754 standard allows extended precision.

>This includes different results between -O2 and -O0 even with
>-fsave-temps.

Getting different results is not the problem (and indeed, some bug
reports are invalid, but *some* of them only).

>Several PR about this issue were marked invalid in
>the past.
>This is a bug in two places:
> i.  x86 FP which implements wrong precision.

As I've said above, this is not a wrong precision; this is allowed
by the IEEE-754 standard. So, this is definitely not a hardware
bug. Perhaps just a bad design.

> ii. glibc that claims in its headers that it sets to set
>default precision to 64 bits, when in practice it
>sets it to 80 bits.

Where? Has there been a bug report about that?

If you think of FLT_EVAL_METHOD, it is set to 2. It may be wrong
(as said later in this thread), but it certainly does not mean
that the default precision is the IEEE-754 double precision.

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

Re: Sine and Cosine Accuracy

[Vincent Lefevre]

On 2005-05-29 01:33:43 -0600, Roger Sayle wrote:
> I apologise for coming into this argument late.  I'll admit that I
> haven't even caught up on the entire thread, but an interesting
> relevant article that may or may not have already been mentioned is:
> 
> http://web.archive.org/web/20040409144725/http://www.naturalbridge.com/floatingpoint/intelfp.html

I mentioned it here:

Date: Fri, 27 May 2005 14:42:32 +0200
From: Vincent Lefevre <[EMAIL PROTECTED]>
To: gcc@gcc.gnu.org
Subject: Re: GCC and Floating-Point (A proposal)
Message-ID: <[EMAIL PROTECTED]>

> Admittedly on many IA-32 systems there's little difference between
> using FSIN vs calling the OS's libm's sin function, as glibc and
> microsoft's runtimes (for example) themselves use the x87 intrinsics.
> GCC, however, is not to know this and assumes that the user might
> provide a high-precision library, such as Lefevre's perfect O.5ulp
> implementation.  [It's nice to see him join this argument! :)]

Well, I'm just one of the authors of MPFR. Concerning the runtime
libraries for math functions in IEEE double precision, that partly
provide correct rounding, I know:
  * IBM's MathLib, on which the glibc is based (for Athlon 64,
Opteron, PowerPC, Alpha and PA-RISC). Does rounding-to-nearest
only.
URL: ftp://www-126.ibm.com/pub/mathlib/
  * Arenaire's Crlibm.
URL: https://lipforge.ens-lyon.fr/projects/crlibm/
  * Sun's libmcr.
URL: http://www.sun.com/download/products.xml?id=41797765
  * MPFR does correct rounding in multiple precision, but a wrapper
could be written for the double precision (and possibly other
precisions for the*f and *l variants). Of course, this would be
quite slow as MPFR wasn't written for such kind of things, but
some users may still be interested.

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

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

[Vincent Lefevre]

On 2005-05-29 18:19:19 +0300, Michael Veksler wrote:
> If more than 50 people report it, independently, as a bug then it
> sure is a bug. You might argue whether technically it is a bug, but
> from user's perspective it is a bug (and you have over 50 duplicates
> as an evidence). As such it has to be dealt with more positively.

Concerning the extended precision, there are two problems.

First there is a bug in GCC concerning casts and assignments
(see ISO/IEC 9899: 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2).

But even this were fixed, many users would still complain.
That's why I think that the Linux kernel should set the CPU
in double-precision mode, like some other OS's (MS Windows,
*BSD) -- but this is off-topic here. I've written a web page
about that:

  http://www.vinc17.org/research/extended.en.html

> I also think that it is also a bug from the technical angle. As far
> as I know, there is an IEEE standard that dictates things like
> rounding. I don't have it in front of me now, but as I remember it
> refers mostly to CPU's floating point unit. So if the CPU does not
> meet the standard, GCC can say that it is a bug in the CPU.

The IEEE-754 standard allows extended precision, even though the
C type is double precision. The term used by the IEEE-754 standard
is "destination", but doesn't specify what the "destination" is.
It may be a floating-point register.

> The standpoint that it's a bug in the CPU is unproductive. It would
> help the users if GCC were trying to hide IEEE nonconformance as
> much as possible. Things such as

I agree that GCC should try to hide IEEE non-conformance (but
x86 CPUs are conforming IEEE-754 implementations, modulo some
particular bugs).

>  assert( a / b == a / b);
> should not fail according to IEEE (as far as I remember).

According to IEEE, it may fail, for various reasons. In particular
because the IEEE-754 standard does not have language bindings.

Also note that a CPU may have two floating-point units, one
conventional in extended precision and one in double precision
(e.g. SSE2), and they could be used in parallel (this was an
example by Fred J. Tydeman on the stds-754 list).

But if you do,

  double x = a / b;
  double y = a / b;
  double z = a / b;

at least two of x, y, z should be equal if the processor supports
the IEEE-754 standard, even with any extended precision internally.

> An even more surprising example can be created:
>#include 
>volatile float x=3;
>int main()
>{
>  float a = 1/x;
>  x = a;
>  assert(a == x); // -O2 will fail on gcc-3.4.3 and gcc-4.0.0
>}

Yes, this is the bug in GCC I was talking about (the one concerning
the assignments).

> I think that you can't deny it is a bug. Copying a variable of the
> same type should not change its value (regardless of what ==
> generally means in FP context).

Yes.

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

Re: GCC and Floating-Point

[Vincent Lefevre]

On 2005-05-29 19:22:57 +0200, Marc Espie wrote:
> In article <[EMAIL PROTECTED]> you write:
> >  http://csdl.computer.org/dl/mags/co/2005/05/r5091.pdf
> >  "An Open Question to Developers of Numerical Software", by
> >  W. Kahan and D. Zuras
> 
> Doesn't look publically accessible from my machine...

Hmm... yes, I think you need to be in a lab that has subscribed
to the publications by the IEEE Computer Society.

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

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

[Kai Henningsen]

[EMAIL PROTECTED] (William Beebe)  wrote on 29.05.05 in <[EMAIL PROTECTED]>:

> On 29 May 2005 11:37:00 +0200, Kai Henningsen <[EMAIL PROTECTED]>
> > wrote: [EMAIL PROTECTED] (Scott Robert Ladd)  wrote on 28.05.05
> > > in In my experience, people don't file Bugzilla reports because it feels
> > > impersonal and unresponsive. The form is not very user-friendly (as in
> > > friendly to users of GCC, not its developers.)
> >
> > This is pretty much incomprehensible to me (NOT a gcc developer, but a gcc
> > user - that is, a programmer).

[...]

> OK, then let me explain it to you. The problem with the GCC Bugzilla
> reporting system is that it's a system that only other developers can
> tolerate, let alone love.

But then, users of GCC typically *are* developers themselves, no?

>The entire GCC website (of which GCC
> Bugzilla is a part) could be the poster child for why developers
> should never be allowed to design user interfaces, especially web user
> interfaces. I'm sure I'll get flamed for wanting style over substance
> or about the proliferation of eye candy, but the GCC web site and it's

... which I think are poster childs why non-technical people *usually*  
ought not to be allowed to design web sites.

> attendent support pages can only be charitably described as eye trash.
> Yes, you can find the bug link if you read the main page long enough
> and move down the page slowly enough, or if, like me, you fire up
> Firefox's find and use that to go quickly to the bug link. But that's
> beside the point. At the very least the design of the GCC web site
> makes the whole project look like someone who has just discovered the
> web and decided to build a few pages. And please don't harp on making

To me, it looks *very* professional.

> it standards compliant and viewable by every browser in existance.
> There are plenty of well-designed and excellent sites that follow
> those same rules. You just need to be willing to put in the effort to
> look a little more professional and polished. And just to stir the pot

 that effort has pretty obviously been put in.

> further, a web site is an important marketing tool. It's the first
> thing that a lot of people will see when they go looking for help. If
> you want to have more people participate, then make the tools more
> inviting.

I think you're pretty much off by 180 degrees.

MfG Kai

Is it possible to catch overflow in long long multiply ?

[Victor STINNER]

Hi,

I'm using gcc "long long" type for my calculator. I have to check
integer overflow. I'm using sign compare to check overflow, but it
doesn't work for 10^16 * 10^4 :
  1 * 1

Here you have my code to check overflow :
  long long produit = a * b; // a,b: long long
  bool ok;
  if (0 < a) {
if (0 < b)
  ok = (produit > 0);  // (+)*(+) -> (+) ?
else if (b == 0)
  ok = true;
else
  ok = (produit < 0);  // (+)*(-) -> (-) ?
  } else if (a == 0) {
ok = true;
  } else {
if (0 < b)
  ok = (produit < 0);  // (-)*(+) -> (-) ?
else if (b == 0)
  ok = true;
else
  ok = (produit > 0);  // (-)*(-) -> (+) ?
  }

The problem is that "1 * 1" give
7766279631452241920. It's not the "expected result".

I know that GMP is the best solution, but I don't want to use it, I
prefer to just use long long.

I search in gcc code, but I didn't found the __multi3 function. I just
found #define __muldi3 __multi3 in gcc/libgcc2.h.

Any idea ?

Bye, Haypo

Re: Sine and Cosine Accuracy

[Bernhard R. Link]

* Georg Bauhaus <[EMAIL PROTECTED]> [050529 20:53]:
> By "real circle" I mean a thing that is not obfuscated by the useful
> but strange ways in which things are redefined by mathematicians;
> cf. Halmos for some humor.

Sorry, but sin and cos are mathematical functions. If you want to invent
some predating functions, given them other names.

There might be some use in having computational functions not working
in every range (as all computation by computers is somehow limited),
but 0..2pi is definitly too limited. As going-to-be mathematican I
could not even imagine before this discussion that someone might limit
it that much.
Breaking things like sin(-x) or sin(x+y) will definitly hurt people,
because it is natural to expect this to work.

> And yes, I know that all the other stuff mentioned in this thread
> explains very well that there exist useful definitions of sine for real
> numbers outside "(co)sine related ranges", and that these definitions
> are frequently used.

What are "(co)sine related ranges", if I may ask? Have you any sane
definiton than 'values in a range I personaly like'?

Bernhard R. Link

Extension: GCC warnings for pure/reentrant functions

[David Austin]

Hi all,

I've had an idea for additional checking that gcc could do
to help programmers - check that functions declared as
pure or reentrant are actually pure/reentrant.  It appears
that the most obvious checking can be done relatively easily.

I know that there are other methods to check these types of things, 
but I think that gcc can do a better job.  For example, a programmer
can easily check the size of the data/bss segments with size.
However, this requires that the programmer does that and also
can't detect calling non-reentrant functions.

So, questions:

1) Do people think that this is a good idea?

2) What would be the best implementation method? 
   a) Mark leaves in the parse tree as pure/reentrant and 
  propagate up, embedded in the current process.   OR
   b) At the stage that we have a parse tree for a function and
  are generating code, descend the tree and propagate up
  pure/reentrant flags as a separate step and check results.

   The advantage of b) is that it can more easily be turned off
   and has no impact on speed when off.  However, when on, the
   speed will be lower than option a).

Eventually, I would suggest that there should be more language 
support for this type of thing!

David Austin

---
[EMAIL PROTECTED]

Robotic Systems Laboratory,  Hiroshima '45  
Department of Systems Engineering,   Chernobyl '86
RSISE, Australian National University  Windows '95

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

[Michael Veksler]

Daniel Berlin <[EMAIL PROTECTED]> wrote on 30/05/2005 06:41:54:

> On Sun, 2005-05-29 at 12:50 +0200, Giovanni Bajo wrote:
> > Michael Veksler <[EMAIL PROTECTED]> wrote:
> >
> > > 3. Nontrivial search of GCC Bugzilla are, sometimes,
> > >extremely slow (over a minute).
> >
> > 3 could be worked on (Daniel?)
>
> Send me the URL's for the buglists and i'll look at the queries (The url
> for the buglist contains the query).
>
> A lot of this is mysql's query engine being stupid, and is hopefully
> fixed in 4.x or 5.x (sourceware is still on 3.x).
>
> I'm happy to optimize the searchs as best i can (by adding lame extra
> indexes if necessary :P)

It is difficult to reproduce because behavior changes over time.
2 hours ago I was getting time-out even for:
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21808

Now, it takes about 2 seconds.

Here is a synthetic test query that take only 15 seconds ATM:

http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=float-store+ICE&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=CLOSED&emailassigned_to1=1&emailreporter1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=

A more sensible query takes 8 seconds:
http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=&known_to_fail_type=allwordssubstr&known_to_work_type=allwordssubstr&long_desc_type=allwordssubstr&long_desc=float-store+ICE&bug_file_loc_type=allwordssubstr&bug_file_loc=&gcchost_type=allwordssubstr&gcchost=&gcctarget_type=allwordssubstr&gcctarget=&gccbuild_type=allwordssubstr&gccbuild=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&bug_status=VERIFIED&emailassigned_to1=1&emailreporter1=1&emailtype1=substring&email1=&emailassigned_to2=1&emailreporter2=1&emailcc2=1&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Bug+Number&field0-0-0=noop&type0-0-0=noop&value0-0-0=

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

[Daniel Berlin]

> > MfG Kai
> 
> OK, then let me explain it to you. The problem with the GCC Bugzilla
> reporting system is that it's a system that only other developers can
> tolerate, let alone love. 

You probably feel this way about all Bugzilla's then, since they are all
the same except for the really large ones.
Right?
However, if there is some you'd rather see us emulate, please let me
know what it is.
> The entire GCC website (of which GCC
> Bugzilla is a part) could be the poster child for why developers
> should never be allowed to design user interfaces, especially web user
> interfaces. 

You've forgotten that as a non-ui expert, I set my goals low when
dealing with bugzilla forms, because I knew i wasn't a UI expert

The main design goal of gcc bugzilla's forms were

1. Not be as horrible as GNATSweb to enter bugs
2. Not be as horrible as GNATSweb to search for bugs
3. Not be as horrible as GNATSweb to generate reports

In these respects, it's a rousing success! :)

Our forms match bugzilla's default forms except where for where we
replaced or changed a small number of fields.

As such, they don't have the customization that
KDE/GNOME/RedHat/whoever's bugzilla forms you like (if you like any
Bugzilla's at all).

There are currently some UI hackathons going on in Bugzilla world to
make the forms nicer to look at and use, but Bugzilla is not my primary
job.

As such, I keep up to date in what's going on in bugzilla world, keep
our code merged with the latest bugzilla cvs (This can be seen on
http://www.dberlin.org/bugzilla-cvs. We haven't had a stellar reason to
upgrade to the 2.20 series yet, so i haven't bothered).  
When developers or users tell me they need/want things, i do those
things, assuming their is some consensus (or it's non-controversial).

So the main reason the forms suck is because nobody has ever told me
what to do to make them not suck!

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

[Daniel Berlin]

On Sun, 2005-05-29 at 00:52 +0200, Vincent Lefevre wrote:
> On 2005-05-28 17:17:32 +0200, Uros Bizjak wrote:
> > At this point, I wonder what is wrong with Bugzilla, that those 
> > programmers don't fill a proper bug report. If there is a problem with 
> > GCC, that is so annoying to somebody, I think that at least developers 
> > could be informed about it via their standard channels of communication.
> 
> Perhaps because GCC developers think that GCC isn't buggy when the
> processor doesn't do the job for them? (I'm thinking of bug 323.)
> 

I don't believe people feel it's not buggy, it's just that nobody has
plans to fix this.  This is in line with the defaults of other
compilers, as well.

Let's take a duplicate of 323, 21809


Compiling the code there with icc gives us:

[EMAIL PROTECTED]:~> icc icca.c
icca.c(7): warning #1572: floating-point equality and inequality
comparisons are unreliable
assert(a == x);
^

./[EMAIL PROTECTED]:~> ./a.out
a.out: icca.c:7: main: Assertion `a == x' failed.
Aborted

In order to get icc to not generate an executable that will abort, you
have to pass special flags (the same way we have -ffloat-store, except I
believe their -mp flag will just disable any optimization that could get
in the way of this working).

One of these flag options is to tell it to use processor specific
instructions, which auto turns on the equivalent of -mfpmath=sse.

Maybe if the compiler from the people who made the processor didn't do
what we did, we'd be more concerned.  Maybe not.  But it certainly
doesn't slant in favor of the vocal (what appears to be) minority to
change the way we default, etc, when everyone else seems to have come to
the same decision independently.

--Dan

PS i found this humorous for some reason:

  call  __intel_proc_init #4.1
flds  _2il0floatpacket.1#5.17
fdivs x #5.17
fsts  x #6.3
fcompsx #7.3
fnstsw%ax   #7.3
sahf#7.3
jne   ..B1.3# Prob 42%  #7.3
# LOE ebx esi edi
..B1.2: # Preds ..B1.1
xorl  %eax, %eax#8.1
movl  %ebp, %esp#8.1
popl  %ebp  #8.1
ret #8.1
# LOE
..B1.3: # Preds ..B1.1
push  $__STRING.2   #7.3
push  $7#7.3
push  $__STRING.1   #7.3
push  $__STRING.0   #7.3
call  __assert_fail #7.3
# LOE
..B1.6: # Preds ..B1.3


Apparently they estimate the probability of a == x succeeding at 42% for
some reason (This is true at all opts levels, with and without SSE
math). Why this isn't 50%, who knows.

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

[Daniel Berlin]

On Sun, 2005-05-29 at 18:19 +0300, Michael Veksler wrote:
> 
> 
> 
> 
> 
> "Giovanni Bajo wrote on 29/05/2005 13:54:39:
> 
> > Vincent Lefevre <[EMAIL PROTECTED]> wrote:
> >
> > > Perhaps because GCC developers think that GCC isn't buggy when the
> > > processor doesn't do the job for them? (I'm thinking of bug 323.)
> >
> >
> > You are mistaken, we think GCC isn't buggy about 323 because the C/C++
> > standards do not tell us to do better than this. If you have higher
> > expectations about floating point and C/C++, you should file a bugreport
> > against the C/C++ standards.
> >
> 
> If more than 50 people report it, independently,  as a bug then it sure is
> a bug.

Which is why it's still open!
Whoops, you forgot that part didn't you :)

The problem with 323 isn't that we don't think it's really a bug, it's
that nobody has any plans to implement a fix for it other than "use SSE
math or a different arch".

--Dan

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

[Daniel Berlin]

On Sun, 2005-05-29 at 13:22 +0300, Michael Veksler wrote:
> 
> 
> 
> 
> 
> Haren Visavadia wrote on 29/05/2005 10:51:00:
> >
> > You can search Bugzilla as well, so you do not fill in
> > duplicate bug report.
> 
> Unfortunately, this is not 100% correct. Recently I have filed several
> duplicates, *after* searching Bugzilla.
> 1. There are too many ways to phrase a title, and too many
>times I search for wrong words.
> 
> 2. The same bug may have several different user
>visible behaviors. You will end up with at least one
>duplicate per user visible behavior.
> 
>At work, I maintain a bug database for my project and I
>sometimes need to fire-up a debugger to find out that
>a reported bug is a well known one.
> 
>Many times only a trained developer (in the project) can assert
>that a PR is indeed a duplicate of another one.
> 
> 3. Nontrivial search of GCC Bugzilla are, sometimes,
>extremely slow (over a minute). This inhibits multiple
>searches. I usually give up after the first one, and don't
>bother with a different type of query (which could have
>revealed a similar PR).
> 
> >

Please send me the urls' to the buglists that are taking a long time to
generate (I don't care if they are a billion character long urls, i know
what to do with them :P)

I should be able to determine what will be necessary to make them go
faster.
--Dan

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

[Daniel Berlin]

On Sun, 2005-05-29 at 16:37 +1200, Ross Smith wrote:
> On Sunday, 29 May 2005 03:17, Uros Bizjak wrote:
> >
> > There is no problem that Bugzilla is un-intuitive, it is far from
> > that. The users don't fill bugreports because they are afraid of
> > filling an invalid report or a duplicate.
> 
> I strongly suspect you're mistaken about the reason.
> 
> > Is perhaps some kind of anonymous account needed (as in Slashdot's
> > case) to encourage these users to fill bugreports?
> 
> I think this is probably the real showstopper. I'll admit I haven't 
> exactly made a scientific survey here, but I suspect a lot of people 
> give up when they see the login form.
> 

> I'd bet that this is the real reason so few people file bug reports. As 
> soon as they see the demand for an email address, alarm bells start 
> going off in their minds, and they go away.

I've looked at the stats for those who click the "file new bug" (which
goes to the login screen if you aren't entered) and those who submit the
bug form, and they aren't way off from each other.

This is probably because the reason we require a valid email address on
bug reports is because we want to communicate with the person who filed
the bug report.

This is the same as every other bug reporting system i'm aware of that
wants high quality reports.

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

[Daniel Berlin]

On Sun, 2005-05-29 at 12:50 +0200, Giovanni Bajo wrote:
> Michael Veksler <[EMAIL PROTECTED]> wrote:
> 
> > Unfortunately, this is not 100% correct. Recently I have filed several
> > duplicates, *after* searching Bugzilla.
> 
> That is not a problem. Bugmasters are there exactly for that. We realize that
> finding duplicates can be very hard (in fact, sometimes duplicates are
> acknowledged as such only after a fix appears), so that is our work. We just
> ask users for some *basic* duplicate checking, and I think most users do that
> before filing bugreports. So it's ok.
> 
> 
> > 3. Nontrivial search of GCC Bugzilla are, sometimes,
> >extremely slow (over a minute).
> 
> 3 could be worked on (Daniel?)

Send me the URL's for the buglists and i'll look at the queries (The url
for the buglist contains the query).

A lot of this is mysql's query engine being stupid, and is hopefully
fixed in 4.x or 5.x (sourceware is still on 3.x).

I'm happy to optimize the searchs as best i can (by adding lame extra
indexes if necessary :P)

Re: What is wrong with Bugzilla?

[William Beebe]

On 5/29/05, Russ Allbery <[EMAIL PROTECTED]> wrote:

> Setting aside for the moment that GCC is a software package *targetted* at
> developers, and hence the above is not necessarily a serious problem, I
> agree that the Bugzilla interface isn't exactly my favorite UI.  However,
> I haven't figured out a better one either, so I don't have a firm platform
> on which to stand and complain.
> 
> Bug reporting interfaces appear to be a hard problem.

Then I would like you to review and contrast GCC Bugzilla
(http://gcc.gnu.org/bugzilla) with at least two others: Mozilla's
(https://bugzilla.mozilla.org) and Redhat's
(https://bugzilla.redhat.com/bugzilla/index.cgi). Mozilla's is a bit
more organized than GCC's (but not much) and it is organized as a
two-column page with a resonably lucid, short and sweet explaination
on the right. It shares the same ant picture with GCC's, which makes
me wonder if that image isn't part of some core page that comes with
the Bugzilla package.

The best of the two is the Redhat page. Instead of lots of controls on
the page, it has one to start with (search for a bug), with the more
detailed (and powerful) options located at the top of the page as menu
items. It's also good in that it has both expository information on
the page as well as news that someone looking for bugs might want to
read. The only problem with the Redhat page is that its news section
is somewhat dated. And yes, I know that Redhat is a 'real' company and
that the designer(s) are probably paid. It would be interesting to ask
if Redhat could provide some gcc site support.

And if bugzilla is not working out, or if you want some ideas on how
to build better interfaces, there seem to be plenty of open bug
tracking packages on Sourceforge. A quick search for bugzilla produces
a nice long list, and at random I picked phpBugTracker
(http://phpbt.sourceforge.net).

> Well, unless you have some user interface designers lined up and
> volunteering to help, this isn't really the most useful thing to say.  GCC
> is a volunteer project; it uses the labor that it has available.

And I understand and appreciate that. But when the UI heavy hitters
aren't beating your doors down you either have to appeal to them in
the coummunity or else go and do what I do; look at what's out there
and (re)use design elements. I know that there's got to be somebody
out there doing good volunteer UI work. For example, I look at the
Savannah project (http://savannah.gnu.org) which is at the least
reasonably organized and easy to read. Then there's Fedora
(http://fedora.redhat.com) and Gentoo (http://www.gentoo.org). I'm
sure there're others.

As I mentioned before, have you thought to ask for help from Redhat?
If everybody looks to gcc as an important core tool, then perhaps
those power users could help with the site. I would say to go and talk
to Apple, that paragon of UI design, but I have no idea how Apple
would react or if it would be a complete waste of time and energy.

> > You just need to be willing to put in the effort to look a little more
> > professional and polished.
> 
> The people maintaining the GCC web site put a great deal of effort into
> it.  If there is a problem, lack of effort isn't the cause of it.

Maintenence is not design. And when that maintenence is the last thing
you do after everything else, it shows. What triggered this diatribe
was the apparent hard-core attitude that the GCC bugzilla (warts and
all) was the way it was and it was going to stay that way, so live
with it. You can't have that kind of an attitude with the site or the
tool.

You've pointed out the lack of bandwidth to improve it, and I am
sympathetic (believe me, I really am). However, if someone makes a
comment on the look and feel of the site then you should make the
diplomatic equivalent to the comment "do you have a patch" when
someone makes a comment about some "questionable" issue with the
compiler.

> You seem to be arguing that the people maintaining the web site have the
> wrong skill set to do a good job at it.  Personally, the site looks great
> to me, but then I'm a developer, so... :)  However, this is all just noise
> on a mailing list in the absence of someone with different ideas who is
> willing to do the work, just as with any other part of GCC.

The people do have the wrong skill set. And let me be the first to
tell you that when it comes to truly creative design, I suck. I would
certainly be willing to help someone who doesn't suck.

> If you feel there is a better way to do the web site, propose patches,
> volunteer to help maintain it, and demonstrate why it's better.  Just like
> with the rest of GCC.  If you don't have time to do that, you could try to
> convince someone else to do it, or you could pay someone to do it.  Just
> like with the rest of GCC.  In the absence of such a contribution, you
> (and the web site) are at the mercy of the people who *are* willing to put
> the effort into it.

OK. Let's see where we go with tha

Re: What is wrong with Bugzilla?

[Zack Weinberg]

R Hill <[EMAIL PROTECTED]> writes:
> Joe Buck wrote:
>> [The request to create a login] also helps assure that the bug
>> filer is a real person.  If Bugzilla provided an anonymous way to
>> file Bugzilla reports, we'd probably have spammers filling the bug
>> database with ads for penis enlargement.
>
> RESOLVED: WORKSFORME

I laughed, but Joe is right.  The Debian bug database, which creates
new bug reports for every message sent to its submit@ address, has had
to institute aggressive automated spam filtering, and its bugmasters
still spend plenty of time weeding spam out of the database.

However, Ross is also right; it is one more hoop to jump through to
submit a bug report, and privacy concerns aside, some people may just
get annoyed and give up at that point.

A possible happy medium might be to merge the two forms for people who
aren't already logged in:-

 --- 
 Bugzilla does not know who you are.  We need a valid email address
 for you so that we can contact you to discuss your bug report.

 If you already have an account, enter your email address and password
 below.  If you don't, enter your email address and leave the password
 field blank; Bugzilla will email you a password.

 Email address: |--|
 Password:  |--|
 ---
 [existing tell-us-about-the-bug form here]

Could probably be improved further; I just made that up off the top of
my head.

zw

Re: Sine and Cosine Accuracy

[Marc Espie]

On Sun, May 29, 2005 at 05:52:11PM -0400, Scott Robert Ladd wrote:
> (I expect Gabriel dos Rios to respond with something pithy here; please
> don't disappoint me!)

Funny, I don't expect any message from that signature.

Gabriel dos Reis, on the other hand, may have something to say...

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

Marc Espie wrote:
> Heck, I can plot trajectories on a sphere that do not follow great circles,
> and that extend over 360 degrees in longitude.  I don't see why I should be
> restricted from doing that.

Can you show me a circumstance where sin(x - 2 * pi) and sin(x + 2 * pi)
are not equal to sin(x)?

Using an earlier example in these threads, do you deny that
sin(pow(2.0,90.0)) == sin(5.15314063427653548) ==
sin(-1.130044672903051) -- assuming no use of
-funsafe-math-optimizations, of course?

Shall we mark all potentially troublesome optimizations as "unsafe", and
chastise those who use them? Quite a few combinations of options can
cause specific applications to fail, and other programs to work very
well. Under such logic, we should replace -O3 with -Ounsafe, because
some programs break when compiled with -O3.

Since that's patently silly, perhaps we should be more concerned with
making useful choices and improvements to GCC.

> You can decide to restrict this stuff to plain old 2D geometry, and this would
> be fine for teaching in elementary school, but this makes absolutely 
> no sense with respect to any kind of modern mathematics.

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

(I expect Gabriel dos Rios to respond with something pithy here; please
don't disappoint me!)

I keep saying that GCC can and should support the different needs of
different applications. What is wrong with that?

..Scott

ifcvt.c question

[Steven Bosscher]

Hi,

ifcvt.c has this code in find_if_block():

  2718/* If the THEN block has no successors, conditional execution can 
still
  2719   make a conditional call.  Don't do this unless the ELSE block has
  2720   only one incoming edge -- the CFG manipulation is too ugly 
otherwise.
  2721   Check for the last insn of the THEN block being an indirect jump, 
which
  2722   is listed as not having any successors, but confuses the rest of 
the CE
  2723   code processing.  ??? we should fix this in the future.  */
  2724if (EDGE_COUNT (then_bb->succs) == 0)
  2725  {
  2726if (single_pred_p (else_bb))
  2727  {
  2728rtx last_insn = BB_END (then_bb);
  2729
  2730while (last_insn
  2731   && NOTE_P (last_insn)
  2732   && last_insn != BB_HEAD (then_bb))
  2733  last_insn = PREV_INSN (last_insn);
  2734
  2735if (last_insn
  2736&& JUMP_P (last_insn)
  2737&& ! simplejump_p (last_insn))
  2738  return FALSE;
  2739
  2740join_bb = else_bb;
  2741else_bb = NULL_BLOCK;
  2742  }
  2743else
  2744  return FALSE;
  2745  }
  2746

I don't understand what lines 2728 to 2741 are for.  Could someone give
an example of when we can have a then_bb that has no successors, but
still ends in something that satisfies simplejump_p()?  What kind of
strange indirect jump would that be?  And shouldn't the check just use
computed_jump_p() if that is what it is looking for??

Gr.
Steven

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

Marc Espie wrote:
> Heck, I can plot trajectories on a sphere that do not follow great circles,
> and that extend over 360 degrees in longitude.  I don't see why I should be
> restricted from doing that.

Can you show me a circumstance where sin(x - 2 * pi) and sin(x + 2 * pi)
are not equal to sin(x)?

Using an earlier example in these threads, do you deny that
sin(pow(2.0,90.0)) == sin(5.15314063427653548) ==
sin(-1.130044672903051) -- assuming no use of
-funsafe-math-optimizations, of course?

Shall we mark all potentially troublesome optimizations as "unsafe", and
chastise those who use them? Quite a few combinations of options can
cause specific applications to fail, and other programs to work very
well. Under such logic, we should replace -O3 with -Ounsafe, because
some programs break when compiled with -O3.

Since that's patently silly, perhaps we should be more concerned with
making useful choices and improvements to GCC.

> You can decide to restrict this stuff to plain old 2D geometry, and this would
> be fine for teaching in elementary school, but this makes absolutely 
> no sense with respect to any kind of modern mathematics.

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

(I expect Gabriel dos Rios to respond with something pithy here; please
don't disappoint me!)

I keep saying that GCC can and should support the different needs of
different applications. What is wrong with that?

..Scott

Problem with scan-tree-dump-times in dg.exp

[Diego Novillo]

I have a new test case where the dump file ought to have 2
occurrences of the pattern "PREDICATE: p.* ne_expr 0B", so I
added

/* { dg-final { scan-tree-dump-times "PREDICATE: p.* ne_expr 0B" 2 "vrp" } } */

but I'm getting a dump scan failure on that file.  I have
manually checked the dump file and there are 2 instances of
that pattern:

$ grep 'PREDICATE: p.* ne_expr 0B' vrp07.c.t23.vrp
PREDICATE: p_5 ne_expr 0B
PREDICATE: p_5 ne_expr 0B

I can't seem to find other test cases with similar patterns.  And
the verbose flags don't show anything obvious.


Thanks.  Diego.

Re: Problem with scan-tree-dump-times in dg.exp

[Jeffrey A Law]

On Mon, 2005-05-30 at 12:32 -0400, Diego Novillo wrote:
> I have a new test case where the dump file ought to have 2
> occurrences of the pattern "PREDICATE: p.* ne_expr 0B", so I
> added
> 
> /* { dg-final { scan-tree-dump-times "PREDICATE: p.* ne_expr 0B" 2 "vrp" } } 
> */
> 
> but I'm getting a dump scan failure on that file.  I have
> manually checked the dump file and there are 2 instances of
> that pattern:
> 
> $ grep 'PREDICATE: p.* ne_expr 0B' vrp07.c.t23.vrp
> PREDICATE: p_5 ne_expr 0B
>   PREDICATE: p_5 ne_expr 0B
> 
> I can't seem to find other test cases with similar patterns.  And
> the verbose flags don't show anything obvious.
When faced with this kind of problem, I usually start debugging
by removing all the wildcards and checking for the exact pattern
which appears in the output file.  In this case I'd replace the
.* with _5 and see if it matches properly.  If it does, then I'd
tighten the wildcard.  Something like p_[0-9]*

Jeff

Re: Problem with scan-tree-dump-times in dg.exp

[Diego Novillo]

On Mon, May 30, 2005 at 11:03:24AM -0600, Jeffrey A Law wrote:

> In this case I'd replace the .* with _5 and see if it matches
> properly.  If it does, then I'd tighten the wildcard.
> Something like p_[0-9]*
> 
Excellent, that worked.  I wonder why is dejagnu so fussy about
patterns.


Thanks.  Diego.

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

Marc Espie wrote:
> Funny, I don't expect any message from that signature.
> 
> Gabriel dos Reis, on the other hand, may have something to say...

A regrettable mistake, brought on by spending too many years in
Spanish-speaking areas, where "rio" is river.

..Scott

Re: ifcvt.c question

[Roger Sayle]

On Sun, 29 May 2005, Steven Bosscher wrote:
> I don't understand what lines 2728 to 2741 are for.  Could someone give
> an example of when we can have a then_bb that has no successors, but
> still ends in something that satisfies simplejump_p()?  What kind of
> strange indirect jump would that be?  And shouldn't the check just use
> computed_jump_p() if that is what it is looking for??

For the benefit of the list, I did some archeology to determine when
this functionality was written and how it evolved to be so broken now.

The mistake was a bug introduced by Michael Meisner back in 2000.
The functionality was originally introduced by Richard Henderson to
allow predication of then blocks that end in noreturn calls.

2000-05-31  Richard Henderson  <[EMAIL PROTECTED]>

* ifcvt.c (merge_if_block): Be prepared for JOIN to have no
remaining edges.
(find_if_block): Allow THEN with no outgoing edges.
* flow.c (merge_blocks_nomove): Remove a barrier not following
a jump as well.

posted: http://gcc.gnu.org/ml/gcc-patches/2000-05/msg01711.html


Unfortunately, this exposed a bug in the d30v port that caused a
regression in gcc.c-torture/execute/920428-1.c.  As I suggested on
IRC, this was a then-block that ended in a non-local goto, or more
precisely an indirect jump.

Michael tried to resolve this problem by excluding those blocks that
ended in indirect jumps.  His mistake was to assume that the way to
eliminate indirect jumps was to limit this code to simple jumps!
Doh!  This inadvertantly disabled RTH's optimization, and the
optimizations' code has been dead ever since.

2000-08-19  Michael Meissner  <[EMAIL PROTECTED]>

* ifcvt.c (find_if_block): Do not assume that a THEN block has any
instructions in it before checking for indirect jumps.

* ifcvt.c (find_if_block): Do not consider a THEN block that ends
in an indirect jump as a potential for conditional execution.

* d30v.h (d30v_init_expanders): Don't declare here.
* d30v-protos.h (d30v_init_expanders): Declare here with a valid
prototype.

posted: http://gcc.gnu.org/ml/gcc-patches/2000-08/msg00736.html


RTH should probably have added a testcase that checked whether this
code was being optimized, so we'd know when it regressed.  I also can't
immediately see why a block that ends in an indirect jump shouldn't
be considered for conditional execution, and he might well have been
papering over another problem in the compiler (esp. the D30V backend).

Of course now that support for D30V has been removed from CVS, it's
difficult to diagnose whether this really was just a backend problem,
and whether we should just return the code to a form similar to the
one RTH originally contributed.

I hope this answers your question.

Roger
--

Re: Sine and Cosine Accuracy

[Scott Robert Ladd]

Bernhard R. Link wrote:
> Breaking things like sin(-x) or sin(x+y) will definitly hurt people,
> because it is natural to expect this to work.

Where in the name of [insert diety here] did I *ever* say I wanted to
break anything?

Just because something breaks *your* application doesn't mean I
shouldn't be able to use it for *my* application.

I asked for one very simple thing that in no way breaks any code for
anyone: A better break down of floationg-point switches to better serve
diverse users.

..Scott

Re: Sine and Cosine Accuracy

[Georg Bauhaus]

Bernhard R. Link wrote:


Sorry, but sin and cos are mathematical functions.


The mathematical functions sin and cos are mathematical
functions in mathematics but almost never in GCC's world,
"almost never" in the mathematical sense:
They can almost never be computed by programs translated using
GCC, i.e. they can be computed for only finitely many inputs.
You can use gcc for translating functions typically named
"sin" and "cos", this naming doesn't make them equal to the
mathematical functions of the same name. The choice of names
"sin" and "cos" seems to be less than helpful, this thread
demonstrates, but of course correcting them is too late, and
off topic. Knuth *has* chosen different names for metapost, BTW.

Programmers write calls to functions named "sin" and "cos" for
reaons of getting a result that is near what the mathematical
model (involving the same names sin and cos) would suggest.
Question is, how and when should GCC enable a programmer to
trigger either library procedures, or procedures built
into the processor. There is no full mathematical trigonometry
inside the processor, and probably not in any T(n) < infty
library function. But there is reason to use either of them
depending on your application. Scott explains.

I do not want to offend methematicians, but see, you say that this
and that is obvious when it isn't even obviously the best choice
in 2D and 3D programs that depend heavily on "sin" and "cos".


-- Georg 

Re: Sine and Cosine Accuracy

[Bernhard R. Link]

* Georg Bauhaus <[EMAIL PROTECTED]> [050530 19:34]:
> Programmers write calls to functions named "sin" and "cos" for
> reaons of getting a result that is near what the mathematical
> model (involving the same names sin and cos) would suggest.
> Question is, how and when should GCC enable a programmer to
> trigger either library procedures, or procedures built
> into the processor. There is no full mathematical trigonometry
> inside the processor, and probably not in any T(n) < infty
> library function. But there is reason to use either of them
> depending on your application. Scott explains.

As I stated in my earlier mail, I'm not opposed against some
limitation of arguments (2^60 is a large number for me, when it is
correctly documented). What I'm arguing against is an argument
telling only [0,2\pi] is in any sense of the word 'correct'
range for those functions, or in any way sensible range for
computations of those. Code like 
"if( x+y < 2*pi) return sin(x+y); else return(x+y-2*pi);" would
really be useable to make me run around screaming, but
naming any range smaller than some [-50pi,100pi] "valid" could
really make me crazy...

Bernhard R. Link

Re: What is wrong with Bugzilla?

[Russ Allbery]

William Beebe <[EMAIL PROTECTED]> writes:

> Then I would like you to review and contrast GCC Bugzilla
> (http://gcc.gnu.org/bugzilla) with at least two others: Mozilla's
> (https://bugzilla.mozilla.org) and Redhat's
> (https://bugzilla.redhat.com/bugzilla/index.cgi). Mozilla's is a bit
> more organized than GCC's (but not much) and it is organized as a
> two-column page with a resonably lucid, short and sweet explaination on
> the right. It shares the same ant picture with GCC's, which makes me
> wonder if that image isn't part of some core page that comes with the
> Bugzilla package.

> The best of the two is the Redhat page.  Instead of lots of controls on
> the page, it has one to start with (search for a bug), with the more
> detailed (and powerful) options located at the top of the page as menu
> items. It's also good in that it has both expository information on the
> page as well as news that someone looking for bugs might want to read.

The Red Hat page is prettier, and I guess the GCC page could use some more
orientation information, but they all feel roughly equal to me.  (I
actually prefer seeing clear links in the text of the page to the menu
thing that Red Hat is doing.)  But as previously mentioned, I'm not really
the person you want reviewing this, most likely.

> And if bugzilla is not working out, or if you want some ideas on how to
> build better interfaces, there seem to be plenty of open bug tracking
> packages on Sourceforge. A quick search for bugzilla produces a nice
> long list, and at random I picked phpBugTracker
> (http://phpbt.sourceforge.net).

Well, the amount of work required to change bug tracking systems or build
a new interface on top of Bugzilla is significant; if you're not planning
on doing that work or paying someone to do it, it's fairly unlikely there
will be any resources to do it.  So far as I know, Bugzilla is working out
fairly well from the perspective of the people working on GCC, which while
not the whole story is at least as important as the bug reporting
interface.

> And I understand and appreciate that. But when the UI heavy hitters
> aren't beating your doors down you either have to appeal to them in
> the coummunity or else go and do what I do; look at what's out there
> and (re)use design elements.

Well, I don't *have* to do anything.  GCC works great for what I want.
But I think I understand what you're saying.

GCC is using Bugzilla because someone not only got fed up with GNATS but
volunteered to do all the work required to make the switch and keep things
running afterwards.

> As I mentioned before, have you thought to ask for help from Redhat?  If
> everybody looks to gcc as an important core tool, then perhaps those
> power users could help with the site. I would say to go and talk to
> Apple, that paragon of UI design, but I have no idea how Apple would
> react or if it would be a complete waste of time and energy.

There are Red Hat and Apple folks on this list.  Maybe you can convince
them to take such an idea to their companies.  I have no idea.  Whatever
is done, it's very important that it be maintainable five years down the
road.  That's where single efforts often fail.

> You've pointed out the lack of bandwidth to improve it, and I am
> sympathetic (believe me, I really am). However, if someone makes a
> comment on the look and feel of the site then you should make the
> diplomatic equivalent to the comment "do you have a patch" when someone
> makes a comment about some "questionable" issue with the compiler.

I would generally agree, and that's basically what I'm trying to do here.
However, it's also useful to point out to someone with a specific
complaint how hard fixing that complaint might be.  For example, if the
report is "I want to link GCC as a library into my new IDE," people aren't
going to just say "do you have a patch" without explaining why that's
going to be hard to do.  :)

> I think we all suffer from Tin Eye Site Design - TESD. But if we don't
> bring this issue up here, then where should it be brought up?

I'm not saying this is the wrong place to bring it up.  It's the only
place to bring it up, so far as I know.  I just think it's one of those
things that can't really be discussed well in negatives.  I really
appreciated your links above to the other sites that you think are better
laid-out; that's positive and presenting a particular improvement that can
then be discussed.  In general, though, I think it's going to take someone
mocking something up and saying "here, I think this is better, what do
other people think?"

-- 
Russ Allbery ([EMAIL PROTECTED]) 

RE: What is wrong with Bugzilla?

[Gary Funck]

As an occasional user of the Bugzilla database, I don't find it terrible to 
use, though
it would be nice if there were an abbreviated interface that looked for the 
sorts of
queries that users issue the most.  These often-occurring queries might be best 
determined
by saving a month's worth of queries and ferreting out the types of queries 
that occur
most often.  I also didn't find the requirement that I register my e-mail 
address to
be particular surprising or burdomesome.

As an aside, I often stumble into the middle of a Redhat discussion list thread 
via
Google that seems to relate to a problem that I've encountered.  Redhat for 
some reason
requires https access, and in IE6, my browser of non-choice, I have to click OK 
to view
the page.  Now, _that_ is annoying.

What may be confusing to users: where do I report my problem? If I'm a Redhat 
user,
do I log my potential GCC problem to their support site, or to the GCC site?  
To further
confuse matters, for most users, the vendors often modify a given version of 
GCC to
include specific patches and build options of their choice.  This of course 
argues
for logging bugs with the vendor.  One wonders whether the vendors are timely 
in reporting
legit bugs back to the GCC Bugzilla database, but one hopes so.

If we for the moment assume that users of pre-packaged distributions report 
their bugs
back to the vendor, then the GCC mailing lists and bug lists are left for those 
brave
souls who are using GCC source code distributions directly.  (perhaps the GCC 
maintainers
can comment on whether this theory in fact holds).  Matters are further 
complicated by
the fact that there are now several viable GCC releases to choose from: 3.3.x, 
3.4.x,
4.0.x, CVS head, and so on.  There's even the occasional bug filed against one 
of the
many branches.  When we consider the multitude of choices, it is amazing that 
there
is any forward progress. 

As a casual reader of the GCC lists, I do have one observation: the volume on 
the
GCC bug list is very, very high.  Often the bug traffic there relates to 
regressions
and bugs that are found on the CVS head or recent development releases.  As a 
user
of the older releases (3.3, 3.4), I'd much prefer it if there were too separate 
bug
reporting lists: one for the more stable released versions, and a separate list 
for
the "latest".  I'd also like it if there was a web page for each stable release 
that
showed the results of a canned Bugzilla query which lists open bugs and/or 
recently
closed bugs agaisnt the stable releases (not sure how this would be organized).

As far as the tenor of the GCC mailing list goes, it is true that responses to 
"dumb
questions" are often terse, but they're generally helpful.  I think this is to 
be
expected, when interacting with busy developers who have to balance many 
priorities
and pressing deadlines.  I've been particularly disappointed by queries to 
related
lists like the glibc list, which of course is an equally important component of 
a
useful C compilation system.  I would vote affirmatively to somehow more closely
linking GCC releases with specific GLIBC distributions, and have some sort of 
tighter
coordination between the two.  However, after delving into GLIBC on a particular
platform, I can see where handling the many varieties of GLIBC builds is a big
problem, and appears to be one that presently the vendors mainly deal with.

Re: Sine and Cosine Accuracy

[Georg Bauhaus]

Bernhard R. Link wrote:


naming any range smaller than some [-50pi,100pi] "valid" could
really make me crazy...


No one is asking for sine to be restricted in this way.
Some are asking for the freedom to request this or that
kind of sine computation to be generated, because they know
that for *their* range of numbers, this or that kind of sine
computation does what they want.

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

[Ulrich Weigand]

Hello,

we've just noticed a quite serious regression in debug info output
in GCC 4.0 over previous releases: when building with -funit-at-a-time
(which is on by default with -O2), *no* debug info for global variables
appears to be emitted at all.

The problem appears to be this piece of code in check_global_declarations:

  /* Do not emit debug information about variables that are in
 static storage, but not defined.  */
  if (TREE_CODE (decl) == VAR_DECL
  && TREE_STATIC (decl)
  && !TREE_ASM_WRITTEN (decl))
DECL_IGNORED_P (decl) = 1;

which was added by:
http://gcc.gnu.org/ml/gcc-cvs/2004-11/msg01250.html

2004-11-25  Mark Mitchell  <[EMAIL PROTECTED]>

PR c++/18556
* toplev.c (check_global_declarations): Set DECL_IGNORED_P on
unemitted variables with static storage duration.


However, check_global_declarations is called (by the C front-end at least)
*before* the call to cgraph_optimize.  At this time, when -funit-at-a-time
is in effect, *no* variables have been emitted to assembler as far as I
can tell, and thus all global variables get the DECL_IGNORED_P flag.

Interestingly enough, when building with the C++ front-end, the debug
info is properly emitted.  I'm not sure where exactly the difference is ...


Bye,
Ulrich

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

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

[Andrew Pinski]

On May 30, 2005, at 2:59 PM, Ulrich Weigand wrote:


Hello,

we've just noticed a quite serious regression in debug info output
in GCC 4.0 over previous releases: when building with -funit-at-a-time
(which is on by default with -O2), *no* debug info for global variables
appears to be emitted at all.


I could not reproduce it with any of the following examples on 
i686-pc-linux-gnu

with dwarf-2:
static int i;

int main(void)
{
  i += 3;
  i *= 5;
  return 0;
}
-
int i;

int main(void)
{
  i += 3;
  i *= 5;
  return 0;
}

int main(void)
{
static int i;
  i += 3;
  i *= 5;
  return 0;
}
---
Do you have an example which fails?

Thanks,
Andrew Pinski

Re: Sine and Cosine Accuracy

[Gabriel Dos Reis]

Georg Bauhaus <[EMAIL PROTECTED]> writes:

| Bernhard R. Link wrote:
| 
| > naming any range smaller than some [-50pi,100pi] "valid" could
| > really make me crazy...
| 
| No one is asking for sine to be restricted in this way.

Howwever, someone came in lectureing us on:

   Yes, but within the defined mathematical ranges for sine and cosine
   -- [0, 2 * PI) --

(which let me wonder whese those maths come from).

| Some are asking for the freedom to request this or that
| kind of sine computation to be generated, because they know
| that for *their* range of numbers, this or that kind of sine
| computation does what they want.

I have no trouble with that.  But that is very different from the
claim I quoted above.

-- Gaby

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

[Andrew Pinski]

On May 30, 2005, at 3:14 PM, Andrew Pinski wrote:



On May 30, 2005, at 2:59 PM, Ulrich Weigand wrote:


Hello,

we've just noticed a quite serious regression in debug info output
in GCC 4.0 over previous releases: when building with -funit-at-a-time
(which is on by default with -O2), *no* debug info for global 
variables

appears to be emitted at all.


I could not reproduce it with any of the following examples on 
i686-pc-linux-gnu

with dwarf-2:


Never mind, gdb must use something else for variables.
You can reproduce it using:
static int i;
int main(void)
{
  i += 3;
  i *= 5;
  return 0;
}

and readelf and looking for the DW_TAG_variable tag.

Thanks,
Andrew Pinski

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

[Haren Visavadia]

--- Daniel Berlin wrote:
> 
> Let's take a duplicate of 323, 21809
> 
> 
> Compiling the code there with icc gives us:
> 
> [EMAIL PROTECTED]:~> icc icca.c
> icca.c(7): warning #1572: floating-point equality
> and inequality
> comparisons are unreliable
> assert(a == x);
> ^
> 
> ./[EMAIL PROTECTED]:~> ./a.out
> a.out: icca.c:7: main: Assertion `a == x' failed.
> Aborted
> 
> In order to get icc to not generate an executable
> that will abort, you
> have to pass special flags (the same way we have
> -ffloat-store, except I
> believe their -mp flag will just disable any
> optimization that could get
> in the way of this working).
> 
> One of these flag options is to tell it to use
> processor specific
> instructions, which auto turns on the equivalent of
> -mfpmath=sse.
> 

Here is another case for you try out:

test.c:
#include 
#include 

volatile float x = 3;

int main()
{
float a = 1 / x;
x = a;
assert(a == x);
printf("a has value of %g \n",a);
printf("x has value of %g  \n",x);
assert((int)a == 0);
assert((int)x == 0);
return 0;
}


Compile this gcc {-O0,-O1,-O2,-O3,-Os}

You will notice it will always works  (despite not
using  -ffloat-store) and not cause an assertion
failure at all.


























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

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

[Robert Dewar]

Haren Visavadia wrote:


test.c:
#include 
#include 

volatile float x = 3;

int main()
{
float a = 1 / x;
x = a;
assert(a == x);
printf("a has value of %g \n",a);
printf("x has value of %g  \n",x);
assert((int)a == 0);
assert((int)x == 0);
return 0;
}


Compile this gcc {-O0,-O1,-O2,-O3,-Os}

You will notice it will always works  (despite not
using  -ffloat-store) and not cause an assertion
failure at all.


And so? Why would you expect this particular example
to give an assertion error. I would not expect an
assert error here. In unoptimized mode, you certainly
do not expect it, and in optimized mode, I would
expect the register tracker to know that a and x are
in the same register at the point of assertion (and
perhaps even eliminate the comparison entirely).

Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

[Florian Weimer]

How sticky are TYPE_MIN_VALUE and TYPE_MAX_VALUE?  Is it possible to
get rid of their effect using a NOP_EXPR, CONVERT_EXPR or
VIEW_CONVERT_EXPR?

If this is impossible, the Ada front end should probably stop setting
these fields because it assumes that it can use values outside that
range:



Current mainline does not optimize array range checks away (even with
-ftree-vrp), but I'm not sure if this is just a missed optimization
opportunity as far as the optimizers are concerned, or something which
is guaranteed to work in the future.

Re: Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

[Richard Kenner]

How sticky are TYPE_MIN_VALUE and TYPE_MAX_VALUE?  Is it possible to
get rid of their effect using a NOP_EXPR, CONVERT_EXPR or
VIEW_CONVERT_EXPR?

I don't really understand either question.  Also, as to the second,
keep in mind their role in array indexes.

If this is impossible, the Ada front end should probably stop setting
these fields because it assumes that it can use values outside that
range:

http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gnat_ugn_unw/Validity-Checking.html

I don't understand what that chapter has to do with your statement.

There is an outstanding PR where Ada is using the wrong type to store
intermediate values.

A much trickier question comes up in the handling of the 'Valid attribute
because the purpose of that attribute is precisely to determine whether
a value is within the bounds of its type. But that can only be used in
very specific circumstances and should not dictate the way the type
system is used.

Re: Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

[Diego Novillo]

On Mon, May 30, 2005 at 09:59:12PM +0200, Florian Weimer wrote:
> How sticky are TYPE_MIN_VALUE and TYPE_MAX_VALUE?  Is it possible to
> get rid of their effect using a NOP_EXPR, CONVERT_EXPR or
> VIEW_CONVERT_EXPR?
> 
> If this is impossible, the Ada front end should probably stop setting
> these fields because it assumes that it can use values outside that
> range:
> 
> 
> 
> Current mainline does not optimize array range checks away (even with
> -ftree-vrp), but I'm not sure if this is just a missed optimization
> opportunity as far as the optimizers are concerned, or something which
> is guaranteed to work in the future.
>
Missed on purpose because of the bootstrap bug I worked-around a
few weeks ago.  See the comment in tree-vrp.c:extract_range_from_assert
regarding integral types with super-types.

http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00127.html

If this is not what's biting you, send me a test case?  I've got
some local VRP changes that address a few of the limitations of
the existing implementation.


Diego.

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

[Haren Visavadia]

--- Robert Dewar wrote:
> And so? Why would you expect this particular example
> to give an assertion error. I would not expect an
> assert error here. In unoptimized mode, you
> certainly
> do not expect it, and in optimized mode, I would
> expect the register tracker to know that a and x are
> in the same register at the point of assertion (and
> perhaps even eliminate the comparison entirely).
> 

The previous posted case only adds few new lines of
insignificant line of code from:


test-case.c:
#include 
volatile float x = 3;
int main()
{
float a = 1 / x;
x = a;
assert(a == x);
}


to

test.c:
#include 
#include 

volatile float x = 3;

int main()
{
float a = 1 / x;
x = a;
assert(a == x);
printf("a has value of %g \n",a);
printf("x has value of %g  \n",x);
assert((int)a == 0);
assert((int)x == 0);
return 0;
}


I would expect the seem behaviour for both cases.

test-case.c cause an assertion failure with
{-O1,-O2,-O3} but test.c does not all.

The first few lines of both case are pretty simalar.

















___ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail 
http://uk.messenger.yahoo.com

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

[Robert Dewar]

Haren Visavadia wrote:

--- Robert Dewar wrote:



I would expect the seem behaviour for both cases.


why? You have some inaccurate model of computation,
which in the absence of switches, is not guaranteed.
Floating-point semantics are indeed tricky.


test-case.c cause an assertion failure with
{-O1,-O2,-O3} but test.c does not all.

The first few lines of both case are pretty simalar.


pretty similar does not mean guaranteed identical
behavior.

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

[Ulrich Weigand]

Andrew Pinski wrote:

> You can reproduce it using:
> static int i;
> int main(void)
> {
>i += 3;
>i *= 5;
>return 0;
> }
> 
> and readelf and looking for the DW_TAG_variable tag.

Yes; in fact 'main' is even superfluous.  Just compile

  int var;

with -S -O2 -g on gcc 3.4 and 4.0 and look at the resulting
assembler file, the difference is quite obvious ...

Bye,
Ulrich


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

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

[Haren Visavadia]

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

Why are extra switches added onto the test.c and not
test-case.c?









___ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail 
http://uk.messenger.yahoo.com

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

[Toon Moene]

Vincent Lefevre wrote:


On 2005-05-29 18:19:19 +0300, Michael Veksler wrote:


If more than 50 people report it, independently, as a bug then it
sure is a bug. You might argue whether technically it is a bug, but
from user's perspective it is a bug (and you have over 50 duplicates
as an evidence). As such it has to be dealt with more positively.



Concerning the extended precision, there are two problems.

First there is a bug in GCC concerning casts and assignments
(see ISO/IEC 9899: 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2).

But even this were fixed, many users would still complain.
That's why I think that the Linux kernel should set the CPU
in double-precision mode, like some other OS's (MS Windows,
*BSD) -- but this is off-topic here.


It's not off-topic.  In fact, Jim Wilson argued this point here:

http://gcc.gnu.org/ml/gcc/2003-08/msg01282.html

"The best pragmatic solution is probably to set the rounding control to 
64-bits, but then we lose access to long double which some people need, 
and we still have excess precision problems for float."


Hope this helps,

--
Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
News on GNU Fortran 95: http://gfortran.org/

Re: Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

[Florian Weimer]

* Diego Novillo:

>> 
>> 
>> Current mainline does not optimize array range checks away (even with
>> -ftree-vrp), but I'm not sure if this is just a missed optimization
>> opportunity as far as the optimizers are concerned, or something which
>> is guaranteed to work in the future.
>>
> Missed on purpose because of the bootstrap bug I worked-around a
> few weeks ago.  See the comment in tree-vrp.c:extract_range_from_assert
> regarding integral types with super-types.

Thanks, but this doesn't really answer my question. 8-) Do you
consider your patch as a temporary workaround, or should front ends
refrain from emitting TYPE_MIN_VALUE/TYPE_MAX_VALUE fields if they
cannot prove that no out-of-bounds values exist at run time?

> http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00127.html
>
> If this is not what's biting you, send me a test case?

This is PR21573, a miscompiled SWITCH_EXPR.  TYPE_MIN_VALUE and
TYPE_MAX_VALUE are used to avoid some comparisons in the expand_case
machinery in stmt.c.  It's not VRP-related, and it also fails on
GCC 4.0.

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

[Jakub Jelinek]

On Mon, May 30, 2005 at 10:13:19PM +0200, Ulrich Weigand wrote:
> Andrew Pinski wrote:
> 
> > You can reproduce it using:
> > static int i;
> > int main(void)
> > {
> >i += 3;
> >i *= 5;
> >return 0;
> > }
> > 
> > and readelf and looking for the DW_TAG_variable tag.
> 
> Yes; in fact 'main' is even superfluous.  Just compile
> 
>   int var;
> 
> with -S -O2 -g on gcc 3.4 and 4.0 and look at the resulting
> assembler file, the difference is quite obvious ...

BTW, I tried to understand what the PR18556 problem was, but
apparently reverting the PR18556 patch makes zero difference
on eh53.C -fexceptions -g.

Even if PR18556 is still needed for C++, we could perhaps
check cgraph_global_info_ready before setting DECL_IGNORED_P,
assuming this hunk makes no sense for C code.  Reordering
cgraph_optimize and c_write_global_declarations_1 might be
too risky for 4.0 I'm afraid (the C++ frontend apparently
first calls cgraph_optimize and then wrapup_globals_for_namespace
plus check_global_declarations).

Jakub

make check on FreeBSD AMD64 5.4Release

[DJ Vincent]

Here are the results of a make check on a box running FreeBSD 5.4 AMD64 if you 
would like feedback.  If not needed please disregard this email.

http://motoko.deltechlabs.com/Vincent/gcc4.txt


Vincent Hoshino

Re: Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

[Florian Weimer]

* Richard Kenner:

> How sticky are TYPE_MIN_VALUE and TYPE_MAX_VALUE?  Is it possible to
> get rid of their effect using a NOP_EXPR, CONVERT_EXPR or
> VIEW_CONVERT_EXPR?
>
> I don't really understand either question.  Also, as to the second,
> keep in mind their role in array indexes.

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

> If this is impossible, the Ada front end should probably stop setting
> these fields because it assumes that it can use values outside that
> range:
>
> 
> http://gcc.gnu.org/onlinedocs/gcc-4.0.0/gnat_ugn_unw/Validity-Checking.html
>
> I don't understand what that chapter has to do with your statement.

These checks are implemented using the 'Valid attribute (see
Checks.Ensure_Valid and Checks.Insert_Valid_Check).

configure test for a mmap flag

[Steve Kargl]

gfortran uses mmap for its IO if an OS has mmap.  If
found, mmap is used with the MAP_SHARED flag.  On linux
(and other OS's) this seems to be okay, but on FreeBSD
IO can significantly degrade if a file pre-exists.  In
some testing I've done, linux's MAP_SHARED appears to be
equivalent to FreeBSD's (MAP_SHARED | MAP_NOSYNC).  I
need to add a configure test to determine if MAP_NOSYNC
is present.  I haven't found an example in the gcc/
directory hierarachy on how this might be accomplished.
Any pointers?

-- 
Steve

Re: configure test for a mmap flag

[Florian Weimer]

* Steve Kargl:

> I need to add a configure test to determine if MAP_NOSYNC is
> present.

What about "#ifdef MAP_NOSYNC" in the code?  Or do you invoke mmap
directly from Fortran?

Re: Stickiness of TYPE_MIN_VALUE/TYPE_MAX_VALUE

[Richard Kenner]

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

My feeling is yes, it does.

Re: configure test for a mmap flag

[Steve Kargl]

On Mon, May 30, 2005 at 11:17:34PM +0200, Florian Weimer wrote:
> * Steve Kargl:
> 
> > I need to add a configure test to determine if MAP_NOSYNC is
> > present.
> 
> What about "#ifdef MAP_NOSYNC" in the code?  Or do you invoke mmap
> directly from Fortran?

There are sometimes too many TREEs (pun intended :-)
to see the forest.

-- 
Steve

successful build of GCC 4.0.0 on Mac OS 10.4.1

[Bojan Antonovic]

gcc-4.0.0 -v
Using built-in specs.
Target: powerpc-apple-darwin8.1.0
Configured with: ../gcc-4.0.0/configure --program-suffix=-4.0.0 
--enable-languages=c,c++,objc,java

Thread model: posix
gcc version 4.0.0

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


uname -a
Darwin Bojan-Antonovics-Computer.local 8.1.0 Darwin Kernel Version 
8.1.0: Tue May 10 18:16:08 PDT 2005; root:xnu-792.1.5.obj~4/RELEASE_PPC 
Power Macintosh powerpc


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

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

greetings

   Bojan

Re: Sine and Cosine Accuracy

[chris jefferson]

Scott Robert Ladd wrote:


Marc Espie wrote:
 


Heck, I can plot trajectories on a sphere that do not follow great circles,
and that extend over 360 degrees in longitude.  I don't see why I should be
restricted from doing that.
   



Can you show me a circumstance where sin(x - 2 * pi) and sin(x + 2 * pi)
are not equal to sin(x)?

Using an earlier example in these threads, do you deny that
sin(pow(2.0,90.0)) == sin(5.15314063427653548) ==
sin(-1.130044672903051) -- assuming no use of
-funsafe-math-optimizations, of course?

 

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


Chris

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

[chris jefferson]

Kai Henningsen wrote:


The entire GCC website (of which GCC
Bugzilla is a part) could be the poster child for why developers
should never be allowed to design user interfaces, especially web user
interfaces. I'm sure I'll get flamed for wanting style over substance
or about the proliferation of eye candy, but the GCC web site and it's
   



... which I think are poster childs why non-technical people *usually*  
ought not to be allowed to design web sites.


 


attendent support pages can only be charitably described as eye trash.
Yes, you can find the bug link if you read the main page long enough
and move down the page slowly enough, or if, like me, you fire up
Firefox's find and use that to go quickly to the bug link. But that's
beside the point. At the very least the design of the GCC web site
makes the whole project look like someone who has just discovered the
web and decided to build a few pages. And please don't harp on making
   



To me, it looks *very* professional.

 

I'm sorry, but I felt I couldn't leave this comment alone. The main GCC 
page is badly designed. The logo looks very amateurish, and also try 
exploring the page without actual knowledge. I just tried this. I 
suspect most people on their first visit are here because they want a 
copy of gcc, and it's perhaps reasonable to assume at this point they 
don't know a huge amount, and perhaps don't want to compile from source 
(if they had a copy of gcc, they wouldn't be here :). Yes, I know and 
you know it's not gcc's job to provide that, but I'd look for a copy of 
gcc by typing "gcc" into google, and gcc.gnu.org is where you get to first)


Lets try to get a copy of gcc. Firstly I see something in the top-left 
marked "releases". I click on it. It doesn't mention 4.0, and despite 
reasonable attempts I see no sign of code. Next I see a mention of 4.0.0 
in the main body. After wandering around that link for quite a while I 
find a link to the mirrors page, which is full of source.


Next try documentation, installation. Talks about compiling again. 
Finally, at download, binaries I find what I want. Seeing as I suspect 
that is the link most people want when they first visit, it should 
perhaps be a little more obvious, and in the main body near the top?


Chris

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

[Gary Funck]

> 
> Next try documentation, installation. Talks about compiling again. 
> Finally, at download, binaries I find what I want. Seeing as I suspect 
> that is the link most people want when they first visit, it should 
> perhaps be a little more obvious, and in the main body near the top?

Your scenario makes a lot of sense.  However, it should be possible to
verify actual usage patterns by investigating web site logs, to see which
pages are visited and (perhaps) in what order.  Based upon this information,
the pages can be re-organized to place first, and most prominent, the pages
that are generally visited first.

Sub-question: which version would the maintainers recommend that a user
looking for a stable release try first (3.3, 3.4, or 4.0)?

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

[Paul Brook]

> Lets try to get a copy of gcc. Firstly I see something in the top-left
> marked "releases". I click on it. It doesn't mention 4.0, 

Fair point. This needs fixing.

> and despite reasonable attempts I see no sign of code. 

Huh? The first paragraph on that page is
"Source code for GCC releases may be downloaded from our "

The following paragraph clearly states that this is source code, and link to 
the page with binaries on. It even says "Important:".

Furthermore the title of that section is "Download"

I don't see how you could possibly have missed this.

Paul

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

[R Hill]

Daniel Berlin wrote:

On Sun, 2005-05-29 at 16:37 +1200, Ross Smith wrote:

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


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


I think this is probably the real showstopper. I'll admit I haven't 
exactly made a scientific survey here, but I suspect a lot of people 
give up when they see the login form.


I'd bet that this is the real reason so few people file bug reports. As 
soon as they see the demand for an email address, alarm bells start 
going off in their minds, and they go away.


I've looked at the stats for those who click the "file new bug" (which
goes to the login screen if you aren't entered) and those who submit the
bug form, and they aren't way off from each other.

This is probably because the reason we require a valid email address on
bug reports is because we want to communicate with the person who filed
the bug report.

This is the same as every other bug reporting system i'm aware of that
wants high quality reports.


I just wanted to speak up and say that the idea of alarm bells going off 
when people see a request for an email address from bugzilla is probably 
one of the sillier things I've read this week.  Anyone lucid enough to 
be reporting a bug to an open source project like GCC realizes (i hope) 
in some form how the whole internet-thing works.  If you request 
support, obviously people need a way to get in touch with you.  If 
you're looking at GCC and thinking "[EMAIL PROTECTED]@#$" then you may 
have more bugs than you thought. ;)


There are throwaway-email services like http://www.jetable.org and free 
email services available from many sources for the very wary.  Maybe a 
mention of that would help.


--de.

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

[Robert Dewar]

Haren Visavadia wrote:

--- Robert Dewar wrote:


Haren Visavadia wrote:


--- Robert Dewar wrote:



I would expect the seem behaviour for both cases.


why? You have some inaccurate model of computation,
which in the absence of switches, is not guaranteed.
Floating-point semantics are indeed tricky.



Why are extra switches added onto the test.c and not
test-case.c?


I assume you mean why is an extra switch needed in
one case and not the other? Well the answer is that
the optimization that causes extra precision for
one of the operands applies in one case and not the
other. It is often tricky to know exactly what the
effects of optimization are.

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

[Robert Dewar]

Toon Moene wrote:


But even this were fixed, many users would still complain.
That's why I think that the Linux kernel should set the CPU
in double-precision mode, like some other OS's (MS Windows,
*BSD) -- but this is off-topic here.


It's not off-topic.  In fact, Jim Wilson argued this point here:

http://gcc.gnu.org/ml/gcc/2003-08/msg01282.html


There are good arguments on either side of this issue. If you set
double precision mode, then you get more predictable precision
(though range is still unpredictable), at the expense of not being
able to make use of extended precision (there are many algorithms
which can take very effective advantage of extended precision (e.g.
you can use log/exp to compute x**y if you have extended precision
but not otherwise).

Given that there are good arguments on both sides for what the
default should be, I see no good argument for changing the
default, which will cause even more confusion, since programs
that work now will suddenly stop working.

Re: What is wrong with Bugzilla?

[Russ Allbery]

R Hill <[EMAIL PROTECTED]> writes:

> I just wanted to speak up and say that the idea of alarm bells going off
> when people see a request for an email address from bugzilla is probably
> one of the sillier things I've read this week.  Anyone lucid enough to
> be reporting a bug to an open source project like GCC realizes (i hope)
> in some form how the whole internet-thing works.  If you request
> support, obviously people need a way to get in touch with you.  If
> you're looking at GCC and thinking "[EMAIL PROTECTED]@#$" then you may
> have more bugs than you thought. ;)

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

I think this is mostly just a matter of phrasing and presentation, though,
not a fundamental problem.  (Another difficulty is that presenting a login
screen and inviting people to create an account also implies that if you
weren't already invited to create an account, someone might be upset if
you just make one.  It has a very "members only" sort of feel to it.)

-- 
Russ Allbery ([EMAIL PROTECTED]) 

Re: What is wrong with Bugzilla?

[R Hill]

Russ Allbery wrote:


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

I think this is mostly just a matter of phrasing and presentation, though,
not a fundamental problem.  (Another difficulty is that presenting a login
screen and inviting people to create an account also implies that if you
weren't already invited to create an account, someone might be upset if
you just make one.  It has a very "members only" sort of feel to it.)


Ah okay, I completely misinterpreted what you meant by "alarm bells". 
Sorry.  I do agree with you, and I know there are a few sites that I 
ignore due to their no-account-no-view policy too.


to bring in what Zack said earlier:


However, Ross is also right; it is one more hoop to jump through to
submit a bug report, and privacy concerns aside, some people may just
get annoyed and give up at that point.

A possible happy medium might be to merge the two forms for people who
aren't already logged in:-

 --- 
 Bugzilla does not know who you are.  We need a valid email address

 for you so that we can contact you to discuss your bug report.

 If you already have an account, enter your email address and password
 below.  If you don't, enter your email address and leave the password
 field blank; Bugzilla will email you a password.


IMHO, KDE's bugzilla[1] hits this right on the head.  They're also the 
only project I know who's bugzilla doesn't feel like every other 
bugzilla out there, just with a different themepack.


[1] https://bugs.kde.org/

Re: GCC 3.3.1 -O2 problem with sqrt.c

[Sanjiv Kumar Gupta]

. I don't know whether gcc mail server

accepts attachments or not,


Oh. It does.


--- Ian Lance Taylor  wrote:



Sanjiv Kumar Gupta <[EMAIL PROTECTED]> writes:



I am using gcc 3.3.1 release as my port, and looks
like I have hit a problem with greg.


You neglected to mention what target you are using.



I couldn't understand why the insns 620 and 621


are


being generated here as DI moves.


I'm not sure specifically why it got a DI move here,
but it doesn't
look wrong.  It's treating the struct named parts as
DImode.



This is creating problem since insn 621 gets


splitted


after reload into two SI moves,i.e. @(r21, -8) and
@(r21, -4).
This renders insns 619 as dead and hence insns 618


and


insn 429 as dead, which are eliminated by flow2.


It does look rather suspicious, but it's hard to
know whether it is
wrong without seeing the value in r1.

Does the behaviour change if you use
-fno-strict-aliasing?  (I can't
remember what the default was in 3.3.1).

Ian






__ 
Yahoo! Mail 
Stay connected, organized, and protected. Take the tour: 
http://tour.mail.yahoo.com/mailtour.html