[GSoC][Rewrite Rust lints]: Suggestions to get started

Hello, My name is Ryutaro Okada. I am interested in participating in Google Summer of Code 2024 with the GCC organization. I am particularly fascinated by the project "Rewrite Rust lints to operate on our frontend's HIR instead of using GCC's existing infrastructure." I have prior experience in c

Re: [GSoC][Rewrite Rust lints]: Suggestions to get started

Hi, On Sat, Mar 01 2025, 岡田隆太郎 via Gcc wrote: > Hello, > > My name is Ryutaro Okada. I am interested in participating in Google Summer > of Code 2024 with the GCC organization. Presumably 2025? ;-) > I am particularly fascinated by the > project "Rewrite Rust lints to operate on our frontend's H

Re: Two suggestions for GCC beginners projects

On 28/11/2024 12:18, Aaron Peter Bachmann via Gcc wrote: Two suggestions for GCC beginners projects I watched some of the 2024 Gnu Cauldron videos. The question of what could be a suitable project for a beginner came up. I have two suggestions: 1.    Add a warning when users use reserved or

Two suggestions for GCC beginners projects

Two suggestions for GCC beginners projects I watched some of the 2024 Gnu Cauldron videos. The question of what could be a suitable project for a beginner came up. I have two suggestions: 1.    Add a warning when users use reserved or potentially reserved identifiers in their code. This

Re: GSoC 2024 [Fortran - DO CONCURRENT] Seeking feedback/suggestions for project proposal

t;3. Developing parallelization strategies, including OpenMP-based >parallelization and OpenMP offloading. > > I have added a detailed project proposal outlining the implementation > approach, timeline, my relevant background, and experience. > > I would greatly appreciate

GSoC 2024 [Fortran - DO CONCURRENT] Seeking feedback/suggestions for project proposal

oping parallelization strategies, including OpenMP-based parallelization and OpenMP offloading. I have added a detailed project proposal outlining the implementation approach, timeline, my relevant background, and experience. I would greatly appreciate feedback or suggestions from the GCC community rega

Re: [GSoC][Improve nothrow detection]: Suggestions to get started

Ping for [GSoC][Improve nothrow detection]: Suggestions to get started. Could you please take a look when you get a chance? Sincerely, Ken Matsui On Wed, Feb 28, 2024 at 8:00 AM Ken Matsui wrote: > > Hi Jan, > > My name is Ken Matsui. I am highly interested in contributing to your

[GSoC][Improve nothrow detection]: Suggestions to get started

Hi Jan, My name is Ken Matsui. I am highly interested in contributing to your GSoC 2024 project idea, "Improve nothrow detection in GCC." To get started with understanding your project (and, if possible, making small patches), could you please give me some suggestions on what files to

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 29/07/16 20:54, Warren D Smith wrote: > On 7/29/16, Jonathan Wakely wrote: >> Let's imagine we have a 4-bit type, called nibble. >> >> sizeof(nibble) == 1, because you can't have an object with a smaller size. >> >> nibble a[2]; >> sizeof(a) == 1; >> >> Because otherwise there isn't much benefi

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 29/07/16 18:26, Warren D Smith wrote: Booleans are very useful - they turn up all over the place in programming. Nibbles, on the other hand, are almost totally useless. There are very, very few situations where you need to store a number that is within the range 0 .. 15, and are so tightly c

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 29/07/16 20:01, Warren D Smith wrote: > Similarly, when some twerp complained Using terminology like this isn't acceptable on these lists. If that's the way you want to treat people who disagree with you, please go elsewhere. R.

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 29 July 2016 at 20:01, Warren D Smith wrote: >> Given a pointer to an array of nibbles and a length, how do I iterate >> through the array? > > for(i=0; i > --correction, that was for an array of packed bools. For nybbles, > bitsizeof(a)/4. There are various games one can play, and quibbles one

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

> Given a pointer to an array of nibbles and a length, how do I iterate > through the array? for(i=0; ihttp://RangeVoting.org <-- add your endorsement (by clicking "endorse" as 1st step)

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 7/29/16, Jonathan Wakely wrote: > Let's imagine we have a 4-bit type, called nibble. > > sizeof(nibble) == 1, because you can't have an object with a smaller size. > > nibble a[2]; > sizeof(a) == 1; > > Because otherwise there isn't much benefit. --bitsizeof() is required. > So now we have a

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

Let's imagine we have a 4-bit type, called nibble. sizeof(nibble) == 1, because you can't have an object with a smaller size. nibble a[2]; sizeof(a) == 1; Because otherwise there isn't much benefit. So now we have a type which violates one of the core rules of the type system. sizeof(nibble[2 *

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

> Booleans are very useful - they turn up all over the place in programming. > > Nibbles, on the other hand, are almost totally useless. There are very, > very few situations where you need to store a number that is within the > range 0 .. 15, and are so tightly constrained for space that you can'

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

same ideas. The challenge has always been finding ways to implement such ideas in a manner that is consistent, useful across a range of systems and programs, efficient, safe, implementable, etc. It does not take a genius to say "it would be useful to have integer types with known sizes"

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

Citerar Warren D Smith : Also, I'm somewhat amazed how it is argued to me that a 9-bit machine the PDP-10 is covered by C fine, but yet, C insists on having everything a multiple of 8 bits with padding bits disallowed, and that too is fine, and both these facts refute me. Wrong. The C languag

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

>> But it failed to fully correct the error >> because, at least with gcc's implementation of stdint.h, only 8,16,32, >> and 64 are provided. >These cover the needs of virtually everyone in virtually all cases. --a bold claim, made with zero evidence presented. But since we know that even 40 yea

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

> And hell, GCC already includes a lot of really really obscure > builtin functions which are one hell of a lot less common & useful > than multiply-hi&lo. Which exactly proves the point that people are making: whether something is "common & useful" is rarely the criteria that's used in deciding w

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

> It *isn't* "putting every possible feature into every language." > Did I ever advocate that? Yes. When you say "X is a useful feature, therefore we should put it into language Y", you are indeed implicitly advocating that. Because if that were *not* the case, then saying that X is *useful* say

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

And hell, GCC already includes a lot of really really obscure builtin functions which are one hell of a lot less common & useful than multiply-hi&lo. I merely cited div(a,b) because it was one of the least obscure among them. How about freaking "isgraph" and "_mm_set1_epi32"? I mean how can you ju

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

It *isn't* "putting every possible feature into every language." Did I ever advocate that? It's "putting a feature that you already put there, into the language, just no longer arbitrarily selecting certain integer sizes and excluding others." Am I making syntax more complicated? No. I am if anyth

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

> OK, you just said you've used packed nybble arrays a couple of times. > Multiplying you by 100,000 that proves if you put it in GCC, > you'd save 200,000 programmer hours, which is equivalent to saving > over 2 lives. I would suggest that you spend time learning basic principles about language d

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

around that, with at least two people having written nonstandard replacement libraries to try for safety, and huge billions of dollars estimated to be lost due to this bad design. Concerning suggestions I've made that never were adopted, I would like C to have array-bounds checking available as

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

d to be lost due to this bad design. Concerning suggestions I've made that never were adopted, I would like C to have array-bounds checking available as a compiler option. Also profiling. I'd like elsif. I'd like more sophisticated compile time stuff, like right now they have #i

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

I am assuming you intended to post this on the mailing list, so I have restored the addresses. On 26/07/16 19:55, Warren D Smith wrote: > To the guy who falsely claimed MIPS fails to provide an add with carry > instruction, > a google search in 1 minute finds this: > > stackoverflow.com/questions

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

> On Jul 26, 2016, at 2:07 PM, Warren D Smith wrote: > > To the guy who falsely claimed MIPS fails to provide an add with carry > instruction, > a google search in 1 minute finds this: > > stackoverflow.com/questions/1281806/adding-two-64-bit-numbers-in-assembly > > I defy you to find any proc

Two suggestions for gcc C compiler to extend C language (by WD Smith)

To the guy who falsely claimed MIPS fails to provide an add with carry instruction, a google search in 1 minute finds this: stackoverflow.com/questions/1281806/adding-two-64-bit-numbers-in-assembly I defy you to find any processor not providing add with carry, (And I'm not talking about semantic

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

> On Jul 26, 2016, at 12:50 PM, Warren D Smith wrote: > > ... > Sigh. It's really hard to get compiler and language guys to do anything. I find it puzzling that you appear to think that insulting your audience is the best way to influence them. > ... > There is absolutely no good reason why

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 26/07/16 16:37, Warren D Smith wrote: You would get on far better here if you tried a little politeness and respect, rather than anger, accusations and confrontation. The C standards were written by a group of very smart and experienced people, refined over a long time based on real-world issu

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 26/07/16 16:55, Warren D Smith wrote: > On 7/26/16, Joseph Myers wrote: >> On Tue, 26 Jul 2016, Warren D Smith wrote: >> >>> (And in the case of uint4_t, it actually would not even BE an >>> "extension" since as I said, >>> the standard already allows providing other sizes.) >> >> Only sizes wh

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On Tue, 26 Jul 2016, Warren D Smith wrote: > --mind-boggling. > So they actually intentionally made the language worse > in the C11 TC3 revision versus the C99 standard. There is no such thing as C11 TC3. All the relevant requirements about being integer numbers of bytes are present in the orig

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

--mind-boggling. So they actually intentionally made the language worse in the C11 TC3 revision versus the C99 standard. Sigh. It's really hard to get compiler and language guys to do anything. I suggest the most stunningly obvious idea, they tell me I am an idiot. Then years and years later, the

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On Tue, 26 Jul 2016, Warren D Smith wrote: > > Only sizes which are an integer number of bytes with no padding bits. > > wikipedia: Wikipedia is not the standard (and, to be clear, C99 before TC3 had various defects in the specification as well, so you should not refer to pre-TC3 versions for

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On Tue, 2016-07-26 at 10:37 -0400, Warren D Smith wrote: > Also, I know on some machines to access a byte you have to get a word > (larger than 8 bits) > from memory, do shifts and masks. So clearly you already do that > inside gcc. > It therefore is trivial for you to do uint4_t also, because it

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 07/26/16 16:55, Warren D Smith wrote: And they said "only if available in implementation" which gcc chose to interpret as "we're not going to make other sizes available, hahahaha." "if available in implementation" probably means "if supported by the underlying hardware". So, if your hardw

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 7/26/16, Joseph Myers wrote: > On Tue, 26 Jul 2016, Warren D Smith wrote: > >> (And in the case of uint4_t, it actually would not even BE an >> "extension" since as I said, >> the standard already allows providing other sizes.) > > Only sizes which are an integer number of bytes with no padding

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 26/07/16 15:37, Warren D Smith wrote: > --the reason I am suggesting this to this forum, is I probably am not capable > of > recoding GCC myself. > Why not learn from your own history, and do that again, with these two > extensions? > (And in the case of uint4_t, it actually would not even BE

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On Tue, 26 Jul 2016, Warren D Smith wrote: > However, why not provide access to double-precision multiply and > add-with-carry (subtract with borrow? shift-left?) in the same fashion? >twofer x = mul(a,b); would cause x.hi and x.lo to be computed. >twofer x = addwithcarry(a,b) ditto

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On Tue, 26 Jul 2016, Warren D Smith wrote: > (And in the case of uint4_t, it actually would not even BE an > "extension" since as I said, > the standard already allows providing other sizes.) Only sizes which are an integer number of bytes with no padding bits. -- Joseph S. Myers jos...@codesou

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 7/26/16, Jonathan Wakely wrote: > On 26 July 2016 at 14:31, Warren D Smith wrote: >> 1. Gcc with stdint.h already >> provides such nice predefined types as uint8_t. >> Sizes provided are 8,16,32, and 64. >> In some sense uint1_t is available too (stdbool.h) >> but at least on my machine stdbool

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 26 July 2016 at 14:31, Warren D Smith wrote: > 1. Gcc with stdint.h already > provides such nice predefined types as uint8_t. > Sizes provided are 8,16,32, and 64. > In some sense uint1_t is available too (stdbool.h) > but at least on my machine stdbool uses 8-bits to store a bool, Because that

Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

On 26/07/16 14:31, Warren D Smith wrote: > However, why not provide access to double-precision multiply and > add-with-carry (subtract with borrow? shift-left?) in the same fashion? >twofer x = mul(a,b); would cause x.hi and x.lo to be computed. >twofer x = addwithcarry(a,b) ditto.

Two suggestions for gcc C compiler to extend C language (by WD Smith)

1. Gcc with stdint.h already provides such nice predefined types as uint8_t. Sizes provided are 8,16,32, and 64. In some sense uint1_t is available too (stdbool.h) but at least on my machine stdbool uses 8-bits to store a bool, e.g. an array of 1000 bools takes 8000 bits, which is asinine and kind

Re: Suggestions

On 30 November 2014 at 19:47, Ryan Nicholl wrote: > I was not able to register on the bug tracker, so I am posting a > couple feature requests here, I hope someone can repost them for me. If you sent an email asking for the account to be created then it will get done shortly. If you didn't send a

Suggestions

I was not able to register on the bug tracker, so I am posting a couple feature requests here, I hope someone can repost them for me. I would like to suggest -Wident=foo, such that it will warn each time foo is encountered in the code. This is similar to [[deprecated]] but it would allow the user

Re: Ask for suggestions on init_caller_save

alized, just init_caller_save first. Any suggestions? I'd suggest #2 with a status flag indicating whether or not caller-saves has been initialized. That should be low enough overhead to not be a problem. Thanks. I will send a patch to gcc-patches and CC you. -- Jie Zhang CodeSourcery (650) 331-3385 x735

Re: Ask for suggestions on init_caller_save

o remember if init_caller_save has been called or not. 4. There are only three global function in caller-save.c: init_save_areas, setup_save_areas, and save_call_clobbered_regs. We can just add a check in the beginning of those functions. If the data has not been initialized, just init_caller_

Ask for suggestions on init_caller_save

been called or not. 4. There are only three global function in caller-save.c: init_save_areas, setup_save_areas, and save_call_clobbered_regs. We can just add a check in the beginning of those functions. If the data has not been initialized, just init_caller_save first. Any suggestions

RE: "random" "Link tests are not allowed after GCC_NO_EXECUTABLES" -- resolved and some suggestions..

> From: [EMAIL PROTECTED] > To: gcc@gcc.gnu.org > Subject: "random" "Link tests are not allowed after GCC_NO_EXECUTABLES" > Date: Wed, 27 Aug 2008 08:30:29 + > > > gcc 4.3.1 with small patches... (merged tree with binutils 2.18/gmp/mpfr, > also slightly patched) > build=i686-pc-cygwin > host=

Re: How to submit suggestions?

>>>>> Perry Smith writes: Perry> While doing my RS/6000 work last week, I bumped into two bugs and two Perry> other items which I would more consider suggestions. The bugs I will Perry> submit via the prescribed method. But how to the maintainers want to Pe

How to submit suggestions?

While doing my RS/6000 work last week, I bumped into two bugs and two other items which I would more consider suggestions. The bugs I will submit via the prescribed method. But how to the maintainers want to see the suggestions? Thanks, Perry Smith

Re: 2 suggestions

> On Thu, 14 Apr 2005, Kaveh R. Ghazi wrote: > > I guess "x" is fine with me. However can we use "x" only in the > > anchor and not the link's text label? E.g.: > > > >alpha*-*-* > > > > That way, the part people actually read in the document still uses > > asterisk that they are us

Re: 2 suggestions

On Thu, 14 Apr 2005, Gerald Pfeifer wrote: > This patch accomplishes the goal to get rid of asterisks in @anchor > names by > > - replacing components of a target triplet which read "*" by "x", > - and omiting trailing asterisks from all other components. > > Tested by running doc/install.texi2

Re: 2 suggestions

On Thu, 14 Apr 2005, Hugh Sasse Staff Elec Eng wrote: >> ...if we are absolutely disallowed to use "*", probably just replacing >> "*" by "x" without any prefix might be the lesser of all evils? > So long as things to get ported to the x-box? That port wouldn't be called x-box, because dash separa

Re: 2 suggestions

Gerald Pfeifer wrote: On Wed, 13 Apr 2005, Kaveh R. Ghazi wrote: I like prepending a string, for example target= or triplet=, etc. Okay. However,... On Thu, 14 Apr 2005, Georg Bauhaus wrote: If "*-*-solaris2*" should appear as/in the "name" attribute of an , prepending a name start char

Re: 2 suggestions

Gerald Pfeifer wrote: On Thu, 7 Apr 2005, Kaveh R. Ghazi wrote: Not necessary. If people would simply follow the directions here: by setting Also, when I click on the link above, it doesn't follow down the page to the anchor. I'm not sure w

Re: 2 suggestions

> ...if we are absolutely disallowed to use "*", probably just > replacing "*" by "x" without any prefix might be the lesser of all > evils? I guess "x" is fine with me. However can we use "x" only in the anchor and not the link's text label? E.g.: alpha*-*-* That way, the part peop

Re: 2 suggestions

On Thu, 14 Apr 2005, Gerald Pfeifer wrote: On Thu, 14 Apr 2005, Georg Bauhaus wrote: If "*-*-solaris2*" should appear as/in the "name" attribute of an , prepending a name start character is not enough, because this attribute is of type NMTOKEN. Therefore it cannot contain * at all. ...if we are abs

Re: 2 suggestions

On Wed, 13 Apr 2005, Kaveh R. Ghazi wrote: > I like prepending a string, for example target= or triplet=, etc. Okay. However,... On Thu, 14 Apr 2005, Georg Bauhaus wrote: > If "*-*-solaris2*" should appear as/in the "name" attribute of an , > prepending a name start character is not enough, beca

RE: 2 suggestions

Original Message >From: Dave Korn >Sent: 14 April 2005 10:12 > Original Message >> From: Kaveh R. Ghazi >> Sent: 14 April 2005 01:11 > >> > I'm afraid we'll have to rename all of these in some way, either by >> > replacing "*" by "x" or by prepending some string. I'm not too fo

RE: 2 suggestions

Original Message >From: Kaveh R. Ghazi >Sent: 14 April 2005 01:11 > > I'm afraid we'll have to rename all of these in some way, either by > > replacing "*" by "x" or by prepending some string. I'm not too fond > > of either, but just using "x" instead "*" might be less ugly. > > Somew

Re: 2 suggestions

Gerald Pfeifer wrote: On Thu, 7 Apr 2005, Kaveh R. Ghazi wrote: Not necessary. If people would simply follow the directions here: by setting Also, when I click on the link above, it doesn't follow down the page to the anchor. I'm not sure w

Re: 2 suggestions

> I'm afraid we'll have to rename all of these in some way, either by > replacing "*" by "x" or by prepending some string. I'm not too fond > of either, but just using "x" instead "*" might be less ugly. > Somewhat. > What do you think? > Gerald I like prepending a string, for example targe

Re: 2 suggestions

On Thu, 7 Apr 2005, Kaveh R. Ghazi wrote: >>> Not necessary. If people would simply follow the directions here: >>> by setting > Also, when I click on the link above, it doesn't follow down the page > to the anchor. I'm not sure why that is

Re: 2 suggestions

On Thu, 7 Apr 2005, Joe Buck wrote: On Thu, Apr 07, 2005 at 03:11:25PM -0400, Kaveh R. Ghazi wrote: I don't know about the utility of example scripts in general, but for this specific case, I strongly feel autoconf should automatically detect this and reexec the configure script under /bin/ksh. Is

Re: 2 suggestions

Toon Moene <[EMAIL PROTECTED]> writes: | Kaveh R. Ghazi wrote: | | > If people would simply follow the directions here: | > by setting | > CONFIG_SHELL to /bin/ksh before configure;make bootstrap, | | Indeed - I stopped counting how many h

Re: 2 suggestions

On Thu, Apr 07, 2005 at 03:11:25PM -0400, Kaveh R. Ghazi wrote: > I don't know about the utility of example scripts in general, but for > this specific case, I strongly feel autoconf should automatically > detect this and reexec the configure script under /bin/ksh. Is there a specific test we can

Re: 2 suggestions

> > CONFIG_SHELL to /bin/ksh before configure;make bootstrap, they > > wouldn't have such insane build times. I bet it cuts the 48 hours > > to single digits. > > The trouble is that *people* are building this. Googling turns up: > "Freemans rule: Nothing is so simple that it cannot be mi

Re: 2 suggestions

> > Not necessary. If people would simply follow the directions here: > > by setting > > I think this docoument could be made more useful by having the more > specific cases refer people to the applicable more general cases. If by t

Re: 2 suggestions

On Thu, Apr 07, 2005 at 01:14:58PM -0400, Ray Holme wrote: > Perhaps this is why I use /bin/sh for all scripts I write - tis leaner and > meaner by far. But the implementation provided by several vendors (Solaris, AIX) is *extremely* slow for some operations, so slow as to add 24 hours to the time

Re: 2 suggestions

Kaveh R. Ghazi wrote: If people would simply follow the directions here: by setting CONFIG_SHELL to /bin/ksh before configure;make bootstrap, Indeed - I stopped counting how many hours of debugging shell scripts on our Sun server I saved (fo

Re: 2 suggestions

Hugh Sasse Staff Elec Eng wrote: So, I'd like to know if the variations in how to build GCC are so numerous that having a collection of example build scripts is a stupid idea. I think that examples are valuable in aiding understanding. Examples often seem clearer than descriptive text, though the

Re: 2 suggestions

On Thu, 7 Apr 2005, Kaveh R. Ghazi wrote: > > 1) years ago GCC took about 2 hours to compile, last year it was 26 > > hours for me, this year I just surpassed 48 hours and it is still [...] > > Configure with --disable-libgcj. I even considered making this the [...] Not necessary.

Re: 2 suggestions

This is why I suggested several parameters to the question. Assumedly if the parameters were the same, so would the answer be. Note that lots of scripts do the same style confuring and a dictionary or param-set responses was what I was suggesting. It was merely a simple suggestion and I believe it

Re: 2 suggestions

>Also it helps a lot to remove paths to directories over the network (like >NFS) >from PATH and LD_LIBRARY_PATH if this is possible. Saves me half of >bootstrap time with our crappy network setup here at university. > Old trick and highly relevent - but this sun mounts nothing NFS wise. Thanks,

Re: 2 suggestions

Perhaps this is why I use /bin/sh for all scripts I write - tis leaner and meaner by far. Course it cannot do some things - but so far that has never been a problem. Ray Eric Botcazou <[EMAIL PROTECTED]> on Thursday, April 7, 2005 at 12:56 PM wrote: >> Not necessary. If people would simply f

Re: 2 suggestions

> Not necessary. If people would simply follow the directions here: > by setting > CONFIG_SHELL to /bin/ksh before configure;make bootstrap, they > wouldn't have such insane build times. I bet it cuts the 48 hours to > single digits. Sure,

Re: 2 suggestions

> > 1) years ago GCC took about 2 hours to compile, last year it was 26 > > hours for me, this year I just surpassed 48 hours and it is still > > going - it would be very nice if one could compile the compiler and > > what it needs without having to build the entire java set (yes I > > know it

Re: 2 suggestions

On Apr 7, 2005 6:12 PM, Eric Botcazou <[EMAIL PROTECTED]> wrote: > > 1) years ago GCC took about 2 hours to compile, last year it was 26 hours > > for me, this year I just surpassed 48 hours and it is still going - it > > would be very nice if one could compile the compiler and what it needs > > wi

Re: 2 suggestions

> 1) years ago GCC took about 2 hours to compile, last year it was 26 hours > for me, this year I just surpassed 48 hours and it is still going - it > would be very nice if one could compile the compiler and what it needs > without having to build the entire java set (yes I know it is bigger and >

Re: 2 suggestions

On Apr 7, 2005 5:54 PM, David Edelsohn <[EMAIL PROTECTED]> wrote: > > Ray Holme writes: > > Ray> 2) Much of the time is spent in the several iterations of building a > Ray> product doing the convfigure steps. These are repeated ad nauseum with > the > Ray> results being obtained the hard way

Re: 2 suggestions

> Ray Holme writes: Ray> 2) Much of the time is spent in the several iterations of building a Ray> product doing the convfigure steps. These are repeated ad nauseum with the Ray> results being obtained the hard way each time. As a database person, it Ray> seems to me that by perhaps having a s

Re: 2 suggestions

> > Firstly - I love your product and have used it for years. > > I run on the Solaris Sparc platform mostly but use Linux and flavors of > Windows at times. My Sun is getting older so both of these suggestions > would help developers on less-than-super machines. > > 1)

2 suggestions

Firstly - I love your product and have used it for years. I run on the Solaris Sparc platform mostly but use Linux and flavors of Windows at times. My Sun is getting older so both of these suggestions would help developers on less-than-super machines. 1) years ago GCC took about 2 hours to