Free-Standing and Non-OS Dependent

Hello all, esp. Dave and Mike, sorry to bother you again. To begin with, I apologise for my incomplete or ambiguous question. I would like to represent my problem with better clarity. Our company (a hardware company) has given a contract to another company to port gcc onto its proprietory pr

Protoize does not build with gcc 4.x

Hi Richard, the protoize utility can't be built with gcc 4.x. Your patch "Using .opt files for target options" http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01297.html makes options.h to be included by tm.h by adding it to tm_include_list in gcc/configure.ac. tm.h is included by protoize.c. That

Re: folding after TER notes

On Tue, 2005-04-26 at 23:40 -0700, Zack Weinberg wrote: > Wasn't TER a temporary kludge that should be going away? When we have a tree combiner I would expect TER to disappear. jeff

about madd instruction in mips instruction sets

i found madd instruction in mips.md, but why when i compiled it with my cross-compile mipsel-linux-gcc as follows, mipsel-linux-gcc -mips4 -O2 test.c -S i can`t find any madd instruction in test.s?? what else should i do?

Re: Java failures [Re: 75 GCC HEAD regressions, 0 new, with your patch on 2005-04-20T14:39:10Z.]

James E Wilson writes: > Andrew Haley wrote: > >* postreload-gcse.c (hash_scan_set): Removve bogus assertion. > > I agree with Roger here, we need to add code to handle REG_EG_REGION > notes here instead of just dropping the gcc_assert call. See my 2 week > old message on the gcc list

gcc 4.0 miscompilation on sparc(32) with ultrasparc optmization

Hi all, this is just a tiny note, that gcc-4.0 does produce miscompiled binaries on sparc(32)-linux with -mcpu=ultrasparc. Some binaries work, however many such as bash, curl or gzip segfault. I know this is not a reduced testcase, just a note. I try to invest some time over the weekend to debug

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-26 13:15:43 -0700, Zack Weinberg wrote: > The initializer thus tries to give a variable with type unsigned:8 > a value that it cannot hold. The diagnostic is correct. However it is correct to store any integer to an unsigned variable, even if the original value cannot be represented. Th

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: > On 2005-04-26 13:15:43 -0700, Zack Weinberg wrote: >> The initializer thus tries to give a variable with type unsigned:8 >> a value that it cannot hold. The diagnostic is correct. > > However it is correct to store any integer to an unsigned variable,

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre writes: > On 2005-04-26 13:15:43 -0700, Zack Weinberg wrote: > > The initializer thus tries to give a variable with type unsigned:8 > > a value that it cannot hold. The diagnostic is correct. > > However it is correct to store any integer to an unsigned variable, > even if th

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 03:37:15 -0700, Zack Weinberg wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > However it is correct to store any integer to an unsigned variable, > > even if the original value cannot be represented. > > If that operation occurs at runtime it has a well-defined result. And

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 11:37:51 +0100, Andrew Haley wrote: > Warnings are to help the programmer see where there is some code that, > although not necessarily an error, may require some attention. This > is a classic case of such a warning. This warning really does > indicate to the programmer that there

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre writes: > On 2005-04-27 03:37:15 -0700, Zack Weinberg wrote: > > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > > However it is correct to store any integer to an unsigned variable, > > > even if the original value cannot be represented. > > > > If that operation occurs at r

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre writes: > On 2005-04-27 11:37:51 +0100, Andrew Haley wrote: > > Warnings are to help the programmer see where there is some code that, > > although not necessarily an error, may require some attention. This > > is a classic case of such a warning. This warning really does > >

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 12:29:53 +0100, Andrew Haley wrote: > Vincent Lefevre writes: > > The only two constraints in 6.6 are: > > > >[#3] Constant expressions shall not contain assignment, > >increment, decrement, function-call, or comma operators, > >except when they

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 12:34:14 +0100, Andrew Haley wrote: > You said "if they are never modified, they evaluate to constants, > right?" To which the correct answer is "no, they don't". Why not? -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 100% accessible validated (X)HTML - Bl

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | > Bruce Lilly <[EMAIL PROTECTED]> writes: | > > static const unsigned char AAA = 0x1U; | > > static const unsigned char BBB = 0x2U; | > | > Again, C does not work the way you think. These are not constants. | | But if they are never modified, they e

Re: New gcc 4.0.0 warnings seem spurious

Zack Weinberg <[EMAIL PROTECTED]> writes: [...] | >> Bruce Lilly <[EMAIL PROTECTED]> writes: | >> > static const unsigned char AAA = 0x1U; | >> > static const unsigned char BBB = 0x2U; | >> | >> Again, C does not work the way you think. These are not constants. | > | > But if they are never mod

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-04-27 03:37:15 -0700, Zack Weinberg wrote: | > Vincent Lefevre <[EMAIL PROTECTED]> writes: | > > However it is correct to store any integer to an unsigned variable, | > > even if the original value cannot be represented. | > | > If that operat

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre wrote:- > > Before the conversion, the value is representable in the type of > the expression, and after the conversion (which is well-defined), > it is still representable in the (new) type of the expression. > 6.7.8#11 mentions the possible conversion. So, I disagree here. Warn

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: [...] | > > But if they are never modified, they evaluate to constants, right? | > > | > > The fact that they are not considered as constant expressions, | > > is it due to the fact that the environment is allowed to modify | > > them? | > | > It

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-04-27 12:29:53 +0100, Andrew Haley wrote: | > Vincent Lefevre writes: | > > The only two constraints in 6.6 are: | > > | > >[#3] Constant expressions shall not contain assignment, | > >increment, decrement, function-

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-04-27 12:34:14 +0100, Andrew Haley wrote: | > You said "if they are never modified, they evaluate to constants, | > right?" To which the correct answer is "no, they don't". | | Why not? I think the answer to that question was in the part you

Re: folding after TER notes

On Wed, 2005-04-27 at 04:22, Jeffrey A Law wrote: > On Tue, 2005-04-26 at 23:40 -0700, Zack Weinberg wrote: > > Wasn't TER a temporary kludge that should be going away? > When we have a tree combiner I would expect TER to disappear. Or if tree expansion were rewritten. One of the many things still

[bug] gcc-3.4-20050422 compiling glibc-2.3.5 internal compiler error in libm-test.c:ctanh_test()

Hi Well, I 've just tried to compile the new glibc-2.3.5 with the latest gcc-3.4-20050422 and ran into the following internal compiler error during the glibc math checks: make[2]: Entering directory `/share/home/clemens/newbuild/glibc-2.3.5/math' gcc test-idouble.c -c -std=gnu99 -O2 -Wall -Winline

Re: [bug] gcc-3.4-20050422 compiling glibc-2.3.5 internal compiler error in libm-test.c:ctanh_test()

On Apr 27, 2005, at 9:51 AM, Clemens Koller wrote: I know that there are precision issues with the test-float and test-ifloat tests with the FPU emulation code, but this crash is new to me. I haven't seen this problem with gcc-3.4.3 and glibc-2.3.4. Well... is this already a known problem, a mista

Re: [bug] gcc-3.4-20050422 compiling glibc-2.3.5 internal compiler error in libm-test.c:ctanh_test()

Hi Andrew! I am reading it right now... I just have to figure out, what you really need or not. Greets, Clemens Koller ___ R&D Imaging Devices Anagramm GmbH Rupert-Mayer-Str. 45/1 81379 Muenchen Germany http://www.anagramm.de Phone: +49-89-741518-50 Fax: +49-89-741518-19

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 15:41:06 +0200, Gabriel Dos Reis wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > | It is said "constant expressions", not "integer constant expressions". > > And an integer constant expression is not a constant expression in > your copy of the C standard? What you are saying

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 15:30:39 +0200, Gabriel Dos Reis wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > [...] > > | > > But if they are never modified, they evaluate to constants, right? > | > > > | > > The fact that they are not considered as constant expressions, > | > > is it due to the f

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 15:44:12 +0200, Gabriel Dos Reis wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > | On 2005-04-27 12:34:14 +0100, Andrew Haley wrote: > | > You said "if they are never modified, they evaluate to constants, > | > right?" To which the correct answer is "no, they don't". > | >

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 15:26:39 +0200, Gabriel Dos Reis wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > | On 2005-04-27 03:37:15 -0700, Zack Weinberg wrote: > | > Vincent Lefevre <[EMAIL PROTECTED]> writes: > | > > However it is correct to store any integer to an unsigned variable, > | > > even if

Re: [bug] gcc-3.4-20050422 compiling glibc-2.3.5 internal compiler error in libm-test.c:ctanh_test()

...and it's not reproducable yet. On a second try the compile was fine and test-idouble just works... ~/newbuild/glibc-2.3.5-build/math$ ./test-idouble testing double (inline functions) Test suite completed: 2562 test cases plus 2337 tests for exception flags executed. All tests passed successf

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-04-27 15:41:06 +0200, Gabriel Dos Reis wrote: | > Vincent Lefevre <[EMAIL PROTECTED]> writes: | > | It is said "constant expressions", not "integer constant expressions". | > | > And an integer constant expression is not a constant expression

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-04-27 15:30:39 +0200, Gabriel Dos Reis wrote: | > Vincent Lefevre <[EMAIL PROTECTED]> writes: | > | > [...] | > | > | > > But if they are never modified, they evaluate to constants, right? | > | > > | > | > > The fact that they are not co

Re: [bug] gcc-3.4-20050422 compiling glibc-2.3.5 internal compiler error in libm-test.c:ctanh_test()

On Apr 27, 2005, at 10:19 AM, Clemens Koller wrote: ...and it's not reproducable yet. On a second try the compile was fine and test-idouble just works... ~/newbuild/glibc-2.3.5-build/math$ ./test-idouble testing double (inline functions) Test suite completed: 2562 test cases plus 2337 tests for e

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-04-27 15:44:12 +0200, Gabriel Dos Reis wrote: | > Vincent Lefevre <[EMAIL PROTECTED]> writes: | > | > | On 2005-04-27 12:34:14 +0100, Andrew Haley wrote: | > | > You said "if they are never modified, they evaluate to constants, | > | > right?"

fold_indirect_ref bogous

fold_indirect_ref, called from the gimplifier happily converts const char *a; ... *(char *)&a[x] = 0; to a[x] = 0; confusing alias1 and ICEing in verify_ssa: /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4.1/gcc/testsuite/gcc.c-torture/execute/20031215-1.c:11: error: Statement makes a memory

Re: [bug] gcc-3.4-20050422 compiling glibc-2.3.5 internal compiler error in libm-test.c:ctanh_test()

Hi, Andrew! > Not really, I would now stop for a minute and check your memory > and your hardware since this is not reproducible. Hmm, okay. It's an embedded system without any case and proper shielding - so some hicups might be possible. I will see, I am doing several compile tests like that to ve

Re: GCC 4.1: Buildable on GHz machines only?

> Matt Thomas writes: Matt> Regardless, GCC4.1 is a computational pig. If you are referring to the compiler itself, this has no basis in reality. If you are referring to the entire compiler collection, including runtimes, you are not using a fair comparison or are making extreme stat

RE: New gcc 4.0.0 warnings seem spurious

Original Message >From: Vincent Lefevre >Sent: 27 April 2005 14:59 > On 2005-04-27 15:30:39 +0200, Gabriel Dos Reis wrote: >> Vincent Lefevre <[EMAIL PROTECTED]> writes: >> >> [...] >> > But if they are never modified, they evaluate to constants, right? > > The fact that the

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 17:30:25 +0200, Gabriel Dos Reis wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > | On 2005-04-27 15:30:39 +0200, Gabriel Dos Reis wrote: > | > Vincent Lefevre <[EMAIL PROTECTED]> writes: > | > > | > [...] > | > > | > | > > But if they are never modified, they evaluate to

RE: New gcc 4.0.0 warnings seem spurious

Original Message >From: Vincent Lefevre >Sent: 27 April 2005 15:47 > Example: the expression 1+1 is not a constant, OK then, let's see you assign a different value to it! cheers, DaveK -- Can't think of a witty .sigline today

Re: GCC 4.1: Buildable on GHz machines only?

David Edelsohn wrote: >>Matt Thomas writes: > > > Matt> Regardless, GCC4.1 is a computational pig. > > If you are referring to the compiler itself, this has no basis in > reality. If you are referring to the entire compiler collection, > including runtimes, you are not using a fair co

building gcc 4.0.0 on Solaris

Hi, I'm attempting to build gcc 4.0.0 on Solaris. I have been unable to build gcc or at least some of its components since the release of gcc 3.4. Here are a few details on my system: - Solaris 8 7/01 - Sun's as/ld as: Sun WorkShop 6 99/08/18 ld: Software Generation Utilities - Solaris Li

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 15:44:15 +0100, Dave Korn wrote: > Original Message > >From: Vincent Lefevre > >Sent: 27 April 2005 14:59 > > > On 2005-04-27 15:30:39 +0200, Gabriel Dos Reis wrote: > >> Vincent Lefevre <[EMAIL PROTECTED]> writes: > >> > >> [...] > >> > > But if they are never modifi

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | On 2005-04-27 17:30:25 +0200, Gabriel Dos Reis wrote: | > Vincent Lefevre <[EMAIL PROTECTED]> writes: | > | > | On 2005-04-27 15:30:39 +0200, Gabriel Dos Reis wrote: | > | > Vincent Lefevre <[EMAIL PROTECTED]> writes: | > | > | > | > [...] | > | > |

Re: GCC 4.1: Buildable on GHz machines only?

On Wed, Apr 27, 2005 at 08:05:39AM -0700, Matt Thomas wrote: > David Edelsohn wrote: > > > GCC now supports C++, Fortran 90 and Java. Those languages have > > extensive, complicated runtimes. The GCC Java environment is becoming > > much more complete and standards compliant, which means ad

Re: GCC 4.1: Buildable on GHz machines only?

> Matt Thomas writes: Matt> That's all positive but if GCC also becomes too expensive to build then Matt> all those extra features become worthless. What is the slowest system Matt> that GCC has been recently bootstrapped on? GCC recently was bootstrapped on a VAX. The GCC b

Re: GCC 4.1: Buildable on GHz machines only?

Jonathan Wakely wrote: > On Wed, Apr 27, 2005 at 08:05:39AM -0700, Matt Thomas wrote: > > >>David Edelsohn wrote: >> >> >>> GCC now supports C++, Fortran 90 and Java. Those languages have >>>extensive, complicated runtimes. The GCC Java environment is becoming >>>much more complete and stan

Re: GCC 4.1: Buildable on GHz machines only?

On Wed, 2005-04-27 at 16:31, David Edelsohn wrote: > The GCC build times are not unreasonable compared to other, > commercial compilers with similar functionality. And the GCC developers > ave plans to address inefficiencies -- GCC 4.0 often is faster than GCC > 3.4. If you are going to ma

RE: GCC 4.1: Buildable on GHz machines only?

Original Message >From: David Edelsohn >Sent: 27 April 2005 16:32 >> Matt Thomas writes: > > Matt> That's all positive but if GCC also becomes too expensive to build > then Matt> all those extra features become worthless. What is the > slowest system Matt> that GCC has been recently

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 18:38:52 +0200, Gabriel Dos Reis wrote: > It has been answered, but I do not believe you made the effort to > understand the answer. Now, let me asnwer it one more time. The vocabulary is important, and I find the gcc diagnostic (cited by Bruce) quite confusing. Then it is not surpr

Re: GCC 4.1: Buildable on GHz machines only?

> Richard Earnshaw writes: Richard> On Wed, 2005-04-27 at 16:31, David Edelsohn wrote: >> The GCC build times are not unreasonable compared to other, >> commercial compilers with similar functionality. And the GCC developers >> ave plans to address inefficiencies -- GCC 4.0 often is faster th

Re: fold_indirect_ref bogous

On Wed, 2005-04-27 at 16:19 +0200, Richard Guenther wrote: > fold_indirect_ref, called from the gimplifier happily converts > > const char *a; > > ... > > *(char *)&a[x] = 0; > > to > > a[x] = 0; > > confusing alias1 and ICEing in verify_ssa: > > /net/alwazn/home/rguenth/src/gcc/cvs/gcc-4

Re: GCC 4.1: Buildable on GHz machines only?

On Wed, 2005-04-27 at 17:19, David Edelsohn wrote: > > Richard Earnshaw writes: > > Richard> On Wed, 2005-04-27 at 16:31, David Edelsohn wrote: > >> The GCC build times are not unreasonable compared to other, > >> commercial compilers with similar functionality. And the GCC developers > >> av

Re: GCC 4.1: Buildable on GHz machines only?

On Wed, 2005-04-27 at 17:29, Richard Earnshaw wrote: > On Wed, 2005-04-27 at 17:19, David Edelsohn wrote: > > > Richard Earnshaw writes: > > > > Richard> On Wed, 2005-04-27 at 16:31, David Edelsohn wrote: > > >> The GCC build times are not unreasonable compared to other, > > >> commercial comp

Re: libstdc++ problem after compiling gcc-4.0 with the -fvisibity-inlines

For the record, I cannot reproduce this on linux with -O2 or -O0. If you continue to have problems, I strongly suggest reporting this in bugzilla. -benjamin

Re: GCC 4.1: Buildable on GHz machines only?

On Wed, Apr 27, 2005 at 08:45:01AM -0700, Matt Thomas wrote: > > If you survived without them previously you can do so now. > > (i.e. don't build libjava if your machine isn't capable of it) > > Yes, you can skip building libjava. But can you skip building GCC? > Will GCC 3.x be supported forever

Re: New gcc 4.0.0 warnings seem spurious

Vincent Lefevre <[EMAIL PROTECTED]> writes: | > Read Zack's sentence | > | > These are not constants. | > | > from | > | >http://gcc.gnu.org/ml/gcc/2005-04/msg01436.html | > | > as | > | > These (i.e. AAA, etc.) are not constant expressions. | > | > Are you happy now? | | T

Re: folding after TER notes

On Wed, Apr 27, 2005 at 12:36:41AM -0600, Jeffrey A Law wrote: > Anyway, I'm going to look into why we're seeing so many *& expressions > during TER. We have an open PR for this. We don't propagate the & when it's not a constant. Like in &x->y. r~

Re: Free-Standing and Non-OS Dependent

On Wed, Apr 27, 2005 at 12:50:52PM +0530, Sriharsha Vedurmudi wrote: > Hello all, esp. Dave and Mike, > >sorry to bother you again. To begin with, I apologise for my > incomplete or ambiguous question. I would like to represent my problem > with better clarity. > > Our company (a hardware c

Dirac, GCC-4.0.0 and SIMD optimisations on x86 architecture

I used GCC-4.0.0 to build the Dirac project. I used the --enable-mmx flag to enable MMX optimisations. Other versions of gcc (3.3.4 and 3.4.3) give a speedup of approximately 30% when the mmx optimisations are enabled. However with gcc-4.0.0, the performance of the Dirac encoder with MMX opts enabl

Re: folding after TER notes

On Wed, 2005-04-27 at 09:35 -0700, Richard Henderson wrote: > On Wed, Apr 27, 2005 at 12:36:41AM -0600, Jeffrey A Law wrote: > > Anyway, I'm going to look into why we're seeing so many *& expressions > > during TER. > > We have an open PR for this. We don't propagate the & when > it's not a const

Re: fold_indirect_ref bogous

Jeffrey A Law wrote: > On Wed, 2005-04-27 at 16:19 +0200, Richard Guenther wrote: > >>fold_indirect_ref, called from the gimplifier happily converts >> >> const char *a; >> >>... >> >> *(char *)&a[x] = 0; >> >>to >> >> a[x] = 0; >> >>confusing alias1 and ICEing in verify_ssa: >> >>/net/alwazn/home

Re: folding after TER notes

On Wed, 2005-04-27 at 08:47 -0400, Andrew MacLeod wrote: > On Wed, 2005-04-27 at 04:22, Jeffrey A Law wrote: > > On Tue, 2005-04-26 at 23:40 -0700, Zack Weinberg wrote: > > > Wasn't TER a temporary kludge that should be going away? > > When we have a tree combiner I would expect TER to disappear. >

Re: gcc 4.0 miscompilation on sparc(32) with ultrasparc optmization

Hi, Steven Bosscher wrote: this is just a tiny note, that gcc-4.0 does produce miscompiled binaries on sparc(32)-linux with -mcpu=ultrasparc. Some binaries work, however many such as bash, curl or gzip segfault. I know this is not a reduced testcase, just a note. I try to invest some time over t

Re: Free-Standing and Non-OS Dependent

On Wed, Apr 27, 2005 at 10:29:54PM +, Sriharsha wrote: > I am not interested in any legal opinion nor are we planning any legal > recourse: > > All I am asking are questions like: > Will a free-standing implementation of newlib not include functions like > 'printf'? See http://www-ccs.ucsd.

Re: GCC 4.1: Buildable on GHz machines only?

Matt Thomas wrote: Alas, the --disable-checking and STAGE1_CFLAGS="-O2 -g" (which I was already doing) only decreased the bootstrap time by 10%. By far, the longest bit of the bootstrap is building libjava. Building libjava takes forever on any platform, relative to the rest of the compiler build

GCC 4.0.0 build report on Fedora Core 3

GCC 4.0.0 has been successfully built on Fedora Core 3 Config.guess output: i686-pc-linux-gnu gcc -v output: Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.0.0/configure --prefix=/usr/local --mandir=/usr/local/share/man --infodir=/usr/local/share/info --enable-languages

Re: GCC 4.1: Buildable on GHz machines only?

> "Ian" == Ian Lance Taylor writes: >> Matt Thomas <[EMAIL PROTECTED]> writes: >> I have a 50MHz 68060 with 96MB of memory (MVME177) approaching 100 hours >> (48 hours just to exit stage3 and start on the libraries) doing a bootstrap >> knowing that it's going to die when doing the ranlib of

Re: Build gcc-4.0.0

On Apr 26, 2005, at 8:40 PM, James E Wilson wrote: Thanks for the info. I have posted a proposed patch on the gcc- patches mailing list here: http://gcc.gnu.org/ml/gcc-patches/2005-04/msg02720.html Yes, this is ok. One final nit, if you'd like to fix it as well, is that obj-c++ should be a

Re: GCC 4.1: Buildable on GHz machines only?

On Wednesday 27 April 2005 17:45, Matt Thomas wrote: > > The features under discussion are new, they didn't exist before. > > And because they never existed before, their cost for older platforms > may not have been correctly assessed. If someone had cared about them, it would have been noticed ea

different address spaces

I have redone the implementation of the eeprom attribute in my prototype. It is now a cleaner solution, but requires larger changes in the core, but the changes in the core should not affect any backend/frontend, if it does not uses them (except a missing case in tree_copy_mem_area, which will caus

Re: GCC 4.1: Buildable on GHz machines only?

> "Steven" == Steven Bosscher <[EMAIL PROTECTED]> writes: Steven> On Wednesday 27 April 2005 17:45, Matt Thomas wrote: >> If no one builds natively on older platforms, the recognition that >> the new features maybe a problem for older platforms will never be >> made. Steven> Maybe the o

Re: GCC 4.1: Buildable on GHz machines only?

> The alternative of course is to do only crossbuilds. Is it reasonable > to say that, for platforms where a bootstrap is no longer feasible, a > successful crossbuild is an acceptable test procedure to use instead? > Sure, and get flamed and trounced by Uli on glibc when you talk about problems

Re: GCC 4.1: Buildable on GHz machines only?

On Wednesday 27 April 2005 22:06, Paul Koning wrote: > > "Steven" == Steven Bosscher <[EMAIL PROTECTED]> writes: > > Steven> On Wednesday 27 April 2005 17:45, Matt Thomas wrote: > >> If no one builds natively on older platforms, the recognition that > >> the new features maybe a problem for

Re: folding after TER notes

On Wednesday 27 April 2005 19:15, Jeffrey A Law wrote: > On Wed, 2005-04-27 at 08:47 -0400, Andrew MacLeod wrote: > > On Wed, 2005-04-27 at 04:22, Jeffrey A Law wrote: > > > On Tue, 2005-04-26 at 23:40 -0700, Zack Weinberg wrote: > > > > Wasn't TER a temporary kludge that should be going away? > >

Re: GCC 4.1: Buildable on GHz machines only?

On Wed, Apr 27, 2005 at 10:36:08PM +0200, Steven Bosscher wrote: > [*] Does anyone have an idea of how large GCC really is? > ~1.8 MLOC. Courtesy of David Wheeler's SLOCCount (testsuites excluded): SLOCDirectory SLOC-by-Language (Sorted) 1179994 gcc ansic=745370,ada=395409,

Re: Build gcc-4.0.0

On Wed, 2005-04-27 at 12:53, Mike Stump wrote: > Yes, this is ok. One final nit, if you'd like to fix it as well, is > that obj-c++ should be added as a non-default language: Good catch. I fixed that in my patch. -- Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: GCC 4.1: Buildable on GHz machines only?

> "Steven" == Steven Bosscher <[EMAIL PROTECTED]> writes: Steven> On Wednesday 27 April 2005 22:06, Paul Koning wrote: >> Isn't a full bootstrap (all languages) part of the required test >> procedure for changes? That's what the website says right now. Steven> Isn't there a special text

Re: GCC 4.1: Buildable on GHz machines only?

On Wed, 27 Apr 2005, Steven Bosscher wrote: > [*] Does anyone have an idea of how large GCC really is? Using sloccount, 4.0.0 release looks like: Totals grouped by language (dominant language first): ansic: 1076327 (43.81%) ada: 541135 (22.03%) java:276544 (11.26%) cpp:

Re: GCC 4.1: Buildable on GHz machines only?

> However, I can always tell when a GCC build has hit the libjava build > -- that's when the *whole system* suddenly slows to a crawl. Maybe > it comes from doing some processing on 5000 foo.o files all at > once... :-( But that is not GCC fault that binutils cannot handle that load. -- Pinski

Re: different address spaces

On Apr 27, 2005, at 1:04 PM, Martin Koegler wrote: @@ -2070,6 +2078,7 @@ result = build3 (CALL_EXPR, TREE_TYPE (fntype), function, coerced_params, NULL_TREE); + EXPR_MEM_AREA (result) = DEFAULT_MEM_AREA; TREE_SIDE_EFFECTS (result) = 1; In the future, please use -p to diff.

Re: Java failures [Re: 75 GCC HEAD regressions, 0 new, with your patch on 2005-04-20T14:39:10Z.]

On Wed, 2005-04-27 at 02:44, Andrew Haley wrote: > Well, of course I'm not going to disagree with you, but I removed the > assertion because it totally broke the Java front end. That means you traded a visible compile time error for a possible silent run-time error. That sounds like a poor trade

Re: GCC 4.1: Buildable on GHz machines only?

On Apr 26, 2005, at 11:12 PM, Matt Thomas wrote: It would be nice if bootstrap emitted timestamps when it was started and when it completed a stage so one could just look at the make output. You can get them differenced for free by using: time make boostrap and written to a log file with

FW: GCC Cross Compiler for cygwin

Does anyone have a working recipe to build gcc as a cross compiler for powerpc, to execute under cygwin I've been able to compile binutils, and build the c/c++ compiler, but am failing in: configure: error: No support for this host/target combination. make: *** [configure-target-libstdc++-v3] Er

Re: GCC 4.1: Buildable on GHz machines only?

Mike Stump wrote: On Apr 26, 2005, at 11:12 PM, Matt Thomas wrote: It would be nice if bootstrap emitted timestamps when it was started and when it completed a stage so one could just look at the make output. You can get them differenced for free by using: time make boostrap I know that. But

Re: GCC Cross Compiler for cygwin

On Apr 27, 2005, at 2:11 PM, Amir Fuhrmann wrote: configure: error: No support for this host/target combination. make: *** [configure-target-libstdc++-v3] Error 1 ../gcc-3.4.3/configure --target=powerpc-eabi powerpc-unknown-eabi?

Re: New gcc 4.0.0 warnings seem spurious

On Apr 27, 2005, at 5:15 AM, Neil Booth wrote: Even better, you can turn of the warning with a cast, making your intent explicit to the compiler, so there's every reason to have it on by default. And, if you don't like casts, you can (...)&255 or whatever.

Re: GCC 4.1: Buildable on GHz machines only?

> "Andrew" == Andrew Pinski <[EMAIL PROTECTED]> writes: >> However, I can always tell when a GCC build has hit the libjava >> build -- that's when the *whole system* suddenly slows to a crawl. >> Maybe it comes from doing some processing on 5000 foo.o files all >> at once... :-( Andrew>

Re: GCC 4.1: Buildable on GHz machines only?

> > > "Andrew" == Andrew Pinski <[EMAIL PROTECTED]> writes: > > >> However, I can always tell when a GCC build has hit the libjava > >> build -- that's when the *whole system* suddenly slows to a crawl. > >> Maybe it comes from doing some processing on 5000 foo.o files all > >> at once...

Re: FW: GCC Cross Compiler for cygwin

Amir Fuhrmann wrote: Does anyone have a working recipe to build gcc as a cross compiler for powerpc, to execute under cygwin I've been able to compile binutils, and build the c/c++ compiler, but am failing in: configure: error: No support for this host/target combination. make: *** [configure-targe

Re: GCC 4.1: Buildable on GHz machines only?

Steven Bosscher wrote: On Wednesday 27 April 2005 17:45, Matt Thomas wrote: The features under discussion are new, they didn't exist before. And because they never existed before, their cost for older platforms may not have been correctly assessed. If someone had cared about them, it would have bee

Re: GCC 4.1: Buildable on GHz machines only?

On Wed, 2005-04-27 at 15:13 -0700, Stan Shebs wrote: > Steven Bosscher wrote: > > >On Wednesday 27 April 2005 17:45, Matt Thomas wrote: > > > >>>The features under discussion are new, they didn't exist before. > >>> > >>And because they never existed before, their cost for older platforms > >>may

Re: GCC 4.1: Buildable on GHz machines only?

On Wed, Apr 27, 2005 at 03:13:21PM -0700, Stan Shebs wrote: > No, there have been plenty of complaints, but the GCC mailing > lists have, shall we say, a "reputation", and a great many > users will not post to them, either for fear of being ridiculed, > or in the expection that they will not be hea

Re: GCC 4.1: Buildable on GHz machines only?

Daniel Berlin <[EMAIL PROTECTED]> writes: > On Wed, 2005-04-27 at 15:13 -0700, Stan Shebs wrote: >> Steven Bosscher wrote: >> >If someone had cared about them, it would have been noticed >> >earlier. But since _nobody_ has complained before you, I guess we >> >can conclude that by far the majorit

Re: GCC 4.1: Buildable on GHz machines only?

Having seen Joe's comment, I should say that I agree with him that a lot of other projects' mailing lists are worse. However, that isn't an excuse in my book. zw

Re: GCC 4.1: Buildable on GHz machines only?

The alternative of course is to do only crossbuilds. Is it reasonable to say that, for platforms where a bootstrap is no longer feasible, a successful crossbuild is an acceptable test procedure to use instead? Sure, and get flamed and trounced by Uli on glibc when you talk about problems with cros

gcc-3.3-20050427 is now available

Snapshot gcc-3.3-20050427 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/3.3-20050427/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 3.3 CVS branch with the following options: -rgcc-ss-3_3-20050427 You'll

Re: [RFA] Which is better? More and simplier patterns? Fewer patterns with more embedded code?

Matt Thomas wrote: I like the more and simplier patterns approach but I'm wondering what the general recommendation is? If an optimization pass will re-recog after rewriting an insn, then it is OK to have two separate patterns for two separate assembly insns. Otherwise, the optimization pass will

Re: GCC 4.1: Buildable on GHz machines only?

On Wed, 2005-04-27 at 16:40 -0700, Zack Weinberg wrote: > Daniel Berlin <[EMAIL PROTECTED]> writes: > > > On Wed, 2005-04-27 at 15:13 -0700, Stan Shebs wrote: > >> Steven Bosscher wrote: > >> >If someone had cared about them, it would have been noticed > >> >earlier. But since _nobody_ has compla

  1   2   >