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

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

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

On 2005-06-18 15:51:50 +0200, Mattias Karlsson wrote: > Anyway my point of view is that the solution to anyone needing > strict IEEE semantics are: You are wrong. IEEE allows extended precision. We are talking about *ISO C99* semantics. > 1) Use -float-store Note: -ffloat-store. This is not a so

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

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

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

On Sun, 19 Jun 2005, Vincent Lefevre wrote: Since the "gcc-is-buggy" solution of changing x87 rounding modes will: 1) Be a lot of work. 2) Cause a lot of regressions. This remains to see. BTW, the Opteron uses SSE by default. Did you see a lot of regressions? Opteron is not an issue, when I

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

On 2005-06-18 18:01:33 -0400, Robert Dewar wrote: > Laurent GUERBY wrote: > >If you code run in extra range issue then you'll get "expected" > >results on x86 and it will fail everywhere else, a nice > >way to detect those issues indeed (and you won't face > >this if you developped your code on non

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

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

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

On 2005-06-19 10:59:24 +0200, Mattias Karlsson wrote: > On Sun, 19 Jun 2005, Vincent Lefevre wrote: > > >>Since the "gcc-is-buggy" solution of changing x87 rounding modes will: > >>1) Be a lot of work. > >>2) Cause a lot of regressions. > > > >This remains to see. BTW, the Opteron uses SSE by defa

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

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

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

On Sun, 19 Jun 2005, Vincent Lefevre wrote: Since the "gcc-is-buggy" solution of changing x87 rounding modes will: 1) Be a lot of work. 2) Cause a lot of regressions. This remains to see. BTW, the Opteron uses SSE by default. Did you see a lot of regressions? Opteron is not an issue, when I

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

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

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

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-06-19 10:59:24 +0200, Mattias Karlsson wrote: | > On Sun, 19 Jun 2005, Vincent Lefevre wrote: | > | > >>Since the "gcc-is-buggy" solution of changing x87 rounding modes will: | > >>1) Be a lot of work. | > >>2) Cause a lot of regressions. | >

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

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

Re: basic VRP min/max range overflow question

[EMAIL PROTECTED] (Florian Weimer) wrote on 18.06.05 in <[EMAIL PROTECTED]>: > * Paul Schlie: > > > So in effect the standard committee have chosen to allow any program which > > invokes any undefined behavior to behave arbitrarily without diagnosis? > > > > This is a good thing? > > It's the way

Re: basic VRP min/max range overflow question

[EMAIL PROTECTED] (Robert Dewar) wrote on 18.06.05 in <[EMAIL PROTECTED]>: > Here is an interesting example I have used sometimes to indicate just > how this kind of information can propagate in a manner that would result > in unexpected chaos. (Ada but obvious analogies in other languages) > > >

Re: basic VRP min/max range overflow question

Kai Henningsen wrote: But at least, in that case, the compiler could easily issue the (presumably not required by the standard) warning that the else branch is "unreachable code". Yes, absolutely, a compiler should generate warnings as much as possible when it is making these kind of assujm

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

On 2005-06-19 11:42:04 +0200, Gabriel Dos Reis wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > | I don't understand your "IEEE = IEEE". To make things clearer: > | IEEE 754 explicitly allows an extended exponent range. The ISO C > | language doesn't. But this can be solved by stores, then

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

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

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

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

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

On Jun 19, 2005 12:55 PM, Vincent Lefevre <[EMAIL PROTECTED]> wrote: > On 2005-06-19 11:47:16 +0200, Gabriel Dos Reis wrote: > > since you seem OK with that solution, would you mind preparing a patch? > > (discussions are not executables; someone needs to make things happen.) > > This is complet

Re: Libstdc++ versioning issues

On Tue, 14 Jun 2005 20:24:40 -0500, Benjamin Kosnik wrote: > I'm testing a patch that resolves the issue. I expect to have additional > details within 24 hrs, and will let you know details. Is this bug #21405, or some other versioning issue? thanks -mike

Bugzilla queries extremely slow

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

Re: Libstdc++ versioning issues

Mike Hearn wrote: >On Tue, 14 Jun 2005 20:24:40 -0500, Benjamin Kosnik wrote: > > >>I'm testing a patch that resolves the issue. I expect to have additional >>details within 24 hrs, and will let you know details. >> >> >Is this bug #21405, or some other versioning issue? > > The issue that

Re: Bugzilla queries extremely slow

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

Re: Bugzilla queries extremely slow

I cannot make sourceware faster, unfortunately :) I can make sure all the queries are using the right indexes, etc, which i do. (I monitor index/key efficiency on the server, as well as number of temp tables created, scanned, blah blah blah) On Sun, 2005-06-19 at 15:04 +0200, Paolo Carlini wrot

Re: Bugzilla queries extremely slow

Daniel Berlin wrote: >I cannot make sourceware faster, unfortunately :) > >I can make sure all the queries are using the right indexes, etc, which >i do. > >(I monitor index/key efficiency on the server, as well as number of temp >tables created, scanned, blah blah blah) > Ok ;) FWIW, I can confir

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

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

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

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

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

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-06-19 11:17:47 +0100, Haren Visavadia wrote: | > --- Gabriel Dos Reis wrote: | > > Vincent Lefevre writes: | > > | > > | Other solutions that would fix the bug (but not | > > ultimate solutions): | > > | 1) Do not claim that gcc is a conformin

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

On Jun 19, 2005, at 9:54 AM, Gabriel Dos Reis wrote: Vincent Lefevre <[EMAIL PROTECTED]> writes: | Yes, and if GCC developers think it is better to lie concerning the | C standard comformance, this could be acceptable when such an option | is given, but this should be clearly documented. Accord

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

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

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

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

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

On 2005-06-19 13:16:33 +0200, Steven Bosscher wrote: > What exactly do you want to _achieve_ with this thread? Please, do tell, > because you've completely lost most of us by now, I'm sure. Just that the problem should be considered as a bug, and not a bug in the users' code (for some of them), n

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

[EMAIL PROTECTED] wrote on 19/06/2005 18:33:55: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > | On 2005-06-19 15:47:58 +0200, Gabriel Dos Reis wrote: > | > If you think it is an invalid bug, then it effectively is a complete > | > non-sense that you continue making noise on this list abo

Re: Libstdc++ versioning issues

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

Re: Libstdc++ versioning issues

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

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

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

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

On 2005-06-19 15:54:20 +0200, Gabriel Dos Reis wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > | Yes, and if GCC developers think it is better to lie concerning the > | C standard comformance, this could be acceptable when such an option > | is given, but this should be clearly documented. A

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

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-06-19 13:16:33 +0200, Steven Bosscher wrote: | > What exactly do you want to _achieve_ with this thread? Please, do tell, | > because you've completely lost most of us by now, I'm sure. | | Just that the problem should be considered as a bug,

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

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

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

Michael Veksler <[EMAIL PROTECTED]> writes: | [EMAIL PROTECTED] wrote on 19/06/2005 18:33:55: | | > Vincent Lefevre <[EMAIL PROTECTED]> writes: | > | > | On 2005-06-19 15:47:58 +0200, Gabriel Dos Reis wrote: | > | > If you think it is an invalid bug, then it effectively is a complete | > | > non-

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

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-06-19 09:57:33 -0400, Andrew Pinski wrote: | > Also I think GCC is not the one who is defining it either. It is | > glibc who is defining that so complain to them instead. | | Thanks for the information (I'm a bit surprised because these are g

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

> why?? > The problem is that in 'expand_vector_operations_1()' in tree-vect-generic.c we call 'optab_for_tree_code()' to get an optab for VEC_RSHIFT_EXPR; 'optab_for_tree_code' does not have a case for VEC_RSHIFT_EXPR, so the vector-lowering function concludes that this tree-code is not suppo

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

On Sun, Jun 19, 2005 at 07:36:15PM +0300, Dorit Naishlos wrote: > ... because at least for the vector-shift case I need to > check that the shift operand is constant, and only then return > optab_shri/shli. This isn't true. Just because the altivec patterns don't accept anything other than a cons

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

Richard Henderson <[EMAIL PROTECTED]> wrote on 19/06/2005 19:49:46: > On Sun, Jun 19, 2005 at 07:36:15PM +0300, Dorit Naishlos wrote: > > ... because at least for the vector-shift case I need to > > check that the shift operand is constant, and only then return > > optab_shri/shli. > > This isn

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

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

question about match_operand and vec_select

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

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

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

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

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

Re: basic VRP min/max range overflow question

> From: Robert Dewar <[EMAIL PROTECTED]> >> Paul Schlie wrote: >>> From: "Joseph S. Myers" <[EMAIL PROTECTED]> >>> "no requirements" means that *any* translation conforms in the case of >>> undefined behavior. Only those executions not involving undefined >>> behavior have any requirements. >> >>

Re: GCC 4.0.1 RC2

On Sat, Jun 18, 2005 at 11:46:42AM -0700, Mark Mitchell wrote: > Benjamin Kosnik wrote: > >>Please test this version and report problems in Bugzilla, with a Cc: > >>to me. I'd also appreciate explicit confirmation from a representative > >>of the libstdc++ team that this version as packaged still h

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

On 2005-06-19, at 17:59, Vincent Lefevre wrote: On 2005-06-19 09:57:33 -0400, Andrew Pinski wrote: Also I think GCC is not the one who is defining it either. It is glibc who is defining that so complain to them instead. Thanks for the information (I'm a bit surprised because these are gcc

Re: Libstdc++ versioning issues

> AFAICS, there are no problems whatsover, because version 3.4.5 is *new* > in 4.0.1. See . This is also . This is probably a bug in binutils but I don't have a warm fuzzy feeling about th

Re: Libstdc++ versioning issues

John David Anglin wrote: >>AFAICS, there are no problems whatsover, because version 3.4.5 is *new* >>in 4.0.1. >> >> >See . This is >also . > >This is probably a bug in binutils but I d

Re: some compile problem about gcc-2.95.3

Steven J. Hill kirjoitti: zouqiong wrote in 15.4.2005 10:16: > i download the release version of gcc-2.95.3, and binutils 2.15, > then i did the following things: > 1. mkdir binutils-build; > .../../binutils-2.15/configure --prefix=/opt/gcc > --target=mipsel-linux -v; > make;make install; > >

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

Richard Henderson <[EMAIL PROTECTED]> wrote on 19/06/2005 20:33:02: > On Sun, Jun 19, 2005 at 08:00:22PM +0300, Dorit Naishlos wrote: > > Altivec does support non immediate shift amount (even if less efficiently - > > I have to put the shift amount in a vector register first). But since we > >

Re: some compile problem about gcc-2.95.3

zouqiong kirjoitti: .../../gcc-2.95.3/configure --prefix=/opt/gcc --target=mipsel-linux --enable-languages=c --disable-checking -enable-shared -v; This is not true at all -B=/opt/gcc-2.95//mipsel-linux/bin/ -I=/opt/gcc-2.95//mipsel-linux/include Because these rows tell that a '--pre

Re: c/c++ validator

On Sunday 19 June 2005 04:48, Gabriel Dos Reis wrote: > Mathieu Malaterre <[EMAIL PROTECTED]> writes: > | Gabriel Dos Reis wrote: > | > Tommy Vercetti <[EMAIL PROTECTED]> writes: > | > | On Sunday 19 June 2005 03:03, you wrote: > | > | > Elsa does not parse C++. > | > | > | > | Elsa is for C/C++, s

Re: GCC 4.0.1 RC2

Mark Mitchell <[EMAIL PROTECTED]> writes: > GCC 4.0.1 RC2 is now available here: > >ftp://gcc.gnu.org/pub/gcc/prerelease-4.0.1-20050616 > > This version has the libstdc++ versioning changes, and most of the PO > file updates. The PO file that Joseph checked in today is not > included, but w

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

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

Re: GCC 4.0.1 RC2

Geoffrey Keating <[EMAIL PROTECTED]> writes: | libstdc++-v3/testsuite/26_numerics/cmath/c99_classification_macros_c.cc | | appears to fail, with lots of complaints like | | c99_classification_macros_c.cc:49:21: error: macro "isgreaterequal" requires 2 arguments, but only 1 given | | but the ac

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

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

Re: GCC 4.0.1 RC2

On 19/06/2005, at 3:45 PM, Gabriel Dos Reis wrote: Geoffrey Keating <[EMAIL PROTECTED]> writes: | libstdc++-v3/testsuite/26_numerics/cmath/ c99_classification_macros_c.cc | | appears to fail, with lots of complaints like | | c99_classification_macros_c.cc:49:21: error: macro "isgreaterequa

Re: GCC 4.0.1 RC2

Geoff Keating <[EMAIL PROTECTED]> writes: | On 19/06/2005, at 3:45 PM, Gabriel Dos Reis wrote: | | > Geoffrey Keating <[EMAIL PROTECTED]> writes: | > | > | libstdc++-v3/testsuite/26_numerics/cmath/ | > c99_classification_macros_c.cc | > | | > | appears to fail, with lots of complaints like | > |

Getting to the gcc summit

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

Re: c/c++ validator

I complied this list for the local C++ users group several months ago, it might be helpful. http://www.nwcpp.org/Misc/Tools_DavidBremner.html Regards, David Bremner

Re: basic VRP min/max range overflow question

Paul Schlie wrote: The root of the concern being expressed is with respect to the compilers use of statically identified undefined behaviors as opportunities to invoke alternative semantics which are easily identified as being inconsistent with the target's native semantics, thus altering the lo

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

Looking at http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg00837.html, LAST_UPDATED: Sun Jun 12 16:16:31 UTC 2005, and this http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01121.html, LAST_UPDATED: Fri Jun 17 08:33:08 UTC 2005 (and the later one http://gcc.gnu.org/ml/gcc-testresults/2005-06/msg01

Error building 4.0.1-RC2

Thought i should report this... Building 4.0.1 RC2, i get this error: make[1]: Leaving directory `/data/backup/linux/gcc/gcc-4.0.1-20050616/intl' make[1]: Entering directory `/data/backup/linux/gcc/gcc-4.0.1-20050616/build-i686-pc-linux-gnu/libiberty' make[1]: *** No rule to make target `../inclu

Re: Error building 4.0.1-RC2

On Mon, 2005-06-20 at 15:02 +0930, Mark Williams (MWP) wrote: > Thought i should report this... > > Building 4.0.1 RC2, i get this error: > > make[1]: Leaving directory `/data/backup/linux/gcc/gcc-4.0.1-20050616/intl' > make[1]: Entering directory > `/data/backup/linux/gcc/gcc-4.0.1-20050616/buil

Re: Error building 4.0.1-RC2

>On Mon, 2005-06-20 at 15:02 +0930, Mark Williams (MWP) wrote: >> Thought i should report this... >> >> Building 4.0.1 RC2, i get this error: >> >> make[1]: Leaving directory `/data/backup/linux/gcc/gcc-4.0.1-20050616/intl' >> make[1]: Entering directory >> `/data/backup/linux/gcc/gcc-4.0.1-20050

Re: Error building 4.0.1-RC2

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

Re: basic VRP min/max range overflow question

> From: Robert Dewar <[EMAIL PROTECTED]> >> Paul Schlie wrote: >> The root of the concern being expressed is with respect to the compilers use >> of statically identified undefined behaviors as opportunities to invoke >> alternative semantics which are easily identified as being inconsistent with >

Re: Error building 4.0.1-RC2

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

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

This patch fixes PR/1025. It also shows up on many platforms where indirect symbols aren't handled properly, like http://gcc.gnu.org/ml/gcc/2005-06/msg00842.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22109 Those platforms need similar patch. H.J. - 2005-06-19 H.J. Lu <[EMAIL PROTECT

Re: Error building 4.0.1-RC2

Mark Williams (MWP) wrote: > Thought i should report this... > > Building 4.0.1 RC2, i get this error: > > make[1]: Leaving directory `/data/backup/linux/gcc/gcc-4.0.1-20050616/intl' Looks like you're trying to build GCC in the source folder itself - this is not supported (yet). Try creating a