Bootstrap fails on HEAD 4.1 for AVR
Hi, when checking out the gcc tree this morning for a clean rebuild and regular testsuite run, I observed that bootstrap failed. It seems that it is related to some preprocessor issue: 1.) Problem occures when assembling the libgcc library. First failing operation is /home/bmh/gnucvs/head/build/./gcc/xgcc -B/home/bmh/gnucvs/head/build/./gcc/ -B/usr/local/avr/bin/ -B/usr/local/avr/lib/ -isystem /usr/local/avr/include -isystem /usr/local/avr/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF -Dinhibit_libc -mcall-prologues -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -DL_mulqi3 -xassembler-with-cpp -c ../../gcc/gcc/config/avr/libgcc.S -c libgcc/./_mulqi3.o and the error message reads ../../gcc/gcc/config/avr/libgcc.S: Assembler messages: ../../gcc/gcc/config/avr/libgcc.S:72: Error: suffix or operands invalid for `clr' ../../gcc/gcc/config/avr/libgcc.S:72: Error: no such instruction: `clear result' ../../gcc/gcc/config/avr/libgcc.S:74: Error: no such instruction: `sbrc r24,0' ../../gcc/gcc/config/avr/libgcc.S:75: Error: too many memory references for `add' ../../gcc/gcc/config/avr/libgcc.S:76: Error: too many memory references for `add' ../../gcc/gcc/config/avr/libgcc.S:76: Error: no such instruction: `shift multiplicand' ../../gcc/gcc/config/avr/libgcc.S:77: Error: no such instruction: `breq __mulqi3_exit' ../../gcc/gcc/config/avr/libgcc.S:77: Error: no such instruction: `while multiplicand!=0' ../../gcc/gcc/config/avr/libgcc.S:78: Error: no such instruction: `lsr r24' ../../gcc/gcc/config/avr/libgcc.S:79: Error: no such instruction: `brne __mulqi3_loop' ../../gcc/gcc/config/avr/libgcc.S:79: Error: no such instruction: `exit if multiplier=0' ../../gcc/gcc/config/avr/libgcc.S:81: Error: too many memory references for `mov' ../../gcc/gcc/config/avr/libgcc.S:81: Error: no such instruction: `result to return register' make[2]: *** [libgcc/./_mulqi3.o] Fehler 1 make[1]: *** [stmp-multilib] Fehler 2 make: *** [all-gcc] Fehler 2 2.) My impression is that the problem is possibly related to some preprocessor issue because when executing /home/bmh/gnucvs/head/build/./gcc/xgcc -B/home/bmh/gnucvs/head/build/./gcc/ -B/usr/local/avr/bin/ -B/usr/local/avr/lib/ -isystem /usr/local/avr/include -isystem /usr/local/avr/sys-include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -DDF=SF -Dinhibit_libc -mcall-prologues -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -DL_mulqi3 -xassembler-with-cpp -c ../../gcc/gcc/config/avr/libgcc.S -c libgcc/./_mulqi3.s in order to have a look at the assembly output, no file _mulqi3.s is generated. Instead the output of the preprocessor is written to stdout. Yours, Björn
Re: Bootstrap fails on HEAD 4.1 for AVR
Björn Haase <[EMAIL PROTECTED]> writes: > -c ../../gcc/gcc/config/avr/libgcc.S -c libgcc/./_mulqi3.s ^^^ Is this "-c" a typo? It surely doesn't come from mklibgcc.in. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Sorry for the noise: Bootstrap fails on HEAD 4.1 for AVR
When trying to figure out the origin of the problem, I have realized so far, that it is obviously stems from a problem during my local configure process: The xgcc I'm just building tries to pipe the asm result through my "host-as" instead of the "target-as". I will myself have to look for why configure chose the wrong assembler. Unfortunately, the error message I got from "make" was not really instructive. So: Sorry for the noise. Yours, Björn
Re: Sorry for the noise: Bootstrap fails on HEAD 4.1 for AVR
>When trying to figure out the origin of the problem, I have realized so far, >that it is obviously stems from a problem during my local configure process: >The xgcc I'm just building tries to pipe the asm result through my "host-as" >instead of the "target-as". I will myself have to look for why configure >chose the wrong assembler. Unfortunately, the error message I got from "make" >was not really instructive. So: Sorry for the noise. When you configured the cross compiler, did you have the target assembler in your PATH? If not configure will use 'as' in your path and find your host assembler instead. -- Peter Barada [EMAIL PROTECTED]
Re: Sorry for the noise: Bootstrap fails on HEAD 4.1 for AVR
Am Sonntag, 3. April 2005 17:24 schrieb Peter Barada: > >When trying to figure out the origin of the problem, I have realized so > > far, that it is obviously stems from a problem during my local configure > > process: The xgcc I'm just building tries to pipe the asm result through > > my "host-as" instead of the "target-as". I will myself have to look for > > why configure chose the wrong assembler. Unfortunately, the error message > > I got from "make" was not really instructive. So: Sorry for the noise. > > When you configured the cross compiler, did you have the target > assembler in your PATH? If not configure will use 'as' in your path > and find your host assembler instead. Actually, it seems that it is *not* sufficient to have the excecutables of the binutils in your search path. I just had moved the binaries in /usr/local/bin to some other location within the search path. Configure, however, did not find them and switched to the host-as without any complaint or error message :-(. When forcing configure by --prefix=/MyDirectoryWithTheBinaries/ to use another path, everything works fine. Thank's BjÃrn
4.0-20050319 / 4-020050402 build error due to --enable-mapped location
Hi all, I tried --enable-mapped-location on recent snapshots and wonder if that is intended to build: ../configure --enable-languages="c,c++" --disable-checking --enable-__cxa_atexit --enable-mapped-location and a make yields: ../../gcc/tree-cfg.c: In function `remove_bb': ../../gcc/tree-cfg.c:2062: error: invalid type argument of `unary *' make[1]: *** [tree-cfg.o] Error 1 Is --enable-mapped-location considered to be a functional in 4.0 ? Yours, -- Renà Rebe - Rubensstr. 64 - 12157 Berlin (Europe / Germany) http://www.exactcode.de | http://www.t2-project.org +49 (0)30 255 897 45 pgphVm1AE3R2l.pgp Description: PGP signature
gcc-4.1-20050403 is now available
Snapshot gcc-4.1-20050403 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20050403/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 CVS branch with the following options: -D2005-04-03 17:43 UTC You'll find: gcc-4.1-20050403.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20050403.tar.bz2 C front end and core compiler gcc-ada-4.1-20050403.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20050403.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20050403.tar.bz2 C++ front end and runtime gcc-java-4.1-20050403.tar.bz2 Java front end and runtime gcc-objc-4.1-20050403.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20050403.tar.bz2The GCC testsuite Diffs from 4.1-20050327 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Use Bohem's GC for compiler proper in 4.1?
Russell Shaw wrote: Memory bloat is a problem for embedded systems. Attitudes about just "buy another gigabyte" is why i use C for everything for speed, portability, compactness, and conciseness of design. For all those hoping to do gcc compilations on their wrist watches :-)
Re: Use Bohem's GC for compiler proper in 4.1?
Gabriel Dos Reis wrote: countries with obscure machines that escaped from Middle Age. While I know a bit of third-wrld, I have also been working in some western European countries for a sufficiant time to say that, well, far many real machines used there for work in univeristies and research labs still don't go beyond 512Mb memory; and they really would love to use GCC and GCC should be usable on those machines. And it would seem a great project for those with such limited machines to concentrate their efforts on making improvements in this area. And of course we all agree on improving memory usage where possible, since this often corresponds to improving performance even on giant machines, But I doubt that projects to buy small linear gains in memory usage are mainstream very worthwhile in the long run (non-linear gains are *always* worth going after by contrast).
Re: Use Bohem's GC for compiler proper in 4.1?
Sam Lauber wrote: if gcc uses more memory than physically available it spends a _very_ long time swapping Swapping, what's that? Here's $20, go buy a gigabyte. You don't know whay swapping is? Shifting memory over from physical RAM to the hard drive when not in use, and putting it back in RAM when in use. aby Er yes, do you not know what a gigabyte is? its a chunk of physical RAM that avoids the need for such swapping :-) (I hardly ever see any significant swapping on my notebook that has 2 gigs, so I can't get excited over the issue. I quite understand that if I was struggling with a machine with only half a gig, especially running XP, gcc would be causing considerable grief in some cases. [1] I don't know if any machines do, but last time I looked at `-1(%esp)', I thought so. All machines allow random access to the stack. I have no idea what you are talking about here or what the relevance of -1(%esp) might be.
Re: Use Bohem's GC for compiler proper in 4.1?
Robert Dewar <[EMAIL PROTECTED]> writes: | Gabriel Dos Reis wrote: | countries with obscure machines that escaped from Middle Age. | > While I know a bit of third-wrld, I have also been working in some | > western | > European countries for a sufficiant time to say that, well, far many real | > machines used there for work in univeristies and research labs still | > don't go beyond 512Mb memory; and they really would love to use GCC and GCC | > should be usable on those machines. | | And it would seem a great project for those with such limited machines to | concentrate their efforts on making improvements in this area. | | And of course we all agree on improving memory usage where possible, since | this often corresponds to improving performance even on giant machines, | | But I doubt that projects to buy small linear gains in memory usage | are mainstream very worthwhile in the long run (non-linear gains are | *always* worth going after by contrast). I wasn't aware that people were exclusively concentrating on small linear gains. -- Gaby
Re: RFC: #pragma optimization_level
A little note is that Ada has a pragma Opimize that would make use of this feature (it's currently pretty much ignored).
Re: Use Bohem's GC for compiler proper in 4.1?
Robert Dewar <[EMAIL PROTECTED]> writes: > But I doubt that projects to buy small linear gains in memory usage > are mainstream very worthwhile in the long run (non-linear gains are > *always* worth going after by contrast). Last year CodeSourcery had a contract to speed up the C++ front end at -O0, and we found that small linear reductions in memory usage corresponded directly to small linear reductions in time usage, at about a 2:1 ratio (so 1% less memory -> 0.5% less time). That wouldn't be worth bothering with except that there are *lots* of places where such reductions are available. We eventually got something like a 40% overall speedup just from this. (Sorry, I haven't got exact numbers.) zw
Re: How is lang.opt processed?
Steve, Toon, On Thu, 10 Mar 2005, Steve Kargl wrote: > Jim, > > Thanks for the detailed explanation of how GCC options work. On Fri, 11 Mar 2005, Toon Moene wrote: > Ditto. Jim, are you reading from some documentation about this option > processing that I couldn't find ? I've spend hours and hours to try to > deduce the option processing rules from debugging various parts of the > gcc driver, with no success. any chance I could convince you to document Jim's explanations and your new findings for "future generations"? Gerald
Re: Use Bohem's GC for compiler proper in 4.1?
> | But I doubt that projects to buy small linear gains in memory usage > | are mainstream very worthwhile in the long run (non-linear gains are > | *always* worth going after by contrast). > > I wasn't aware that people were exclusively concentrating on small > linear gains. although don't know if the use of broader use of GC is appropriate, note the obvious: small gains cumulatively produce larger gains; just as small inefficiencies tend to cumulatively yield larger ones. so would guess that if memory utilization efficiency, which effect cache efficiency, and thereby performance is considered important, every little bit counts either for or against you ultimately. (so would seem that if even only half a dozen %5-10% gains were all that remained to be had, they could enable a memory reduction from 1GB -> 600MB, but acknowledge as remaining marginal gains drop below a few percent, their cumulative benefit is likely questionable, although may still be appropriate to enable a more localized performance benefit).
Re: SUBTARGET_OPTIONS / SUBTARGET_SWITCHES with .opt
Aldy Hernandez <[EMAIL PROTECTED]> writes:
> I've been converting the ppc options to use the .opt machinery, and
> am confused as to how to approach subtargets.
>
> What's the deal with these?
>
> I need options only for certain subtargets. For example, aix.h has
> some options that should not be available by other targets.
>
> I don't see anything relevant in options.texi, and I don't see any
> converted backend that has this problem.
>
> Should we just include the options for all subtargets, or should we
> add generic functionality (I volunteer if so).
Sorry for the slow answer. I see Zack has already replied, and I guess
you've long figured this out, but just for the record:
The idea is that you only put the options that apply to all targets
in MACHINE.opt. If a subtarget has extra options, they should go
in their own .opt file and config.gcc should add those files to
$extra_options.
As for where this documented: well, it's actually in the "Anatomy of
a Target Back End" section (sourcebuild.texi):
A back end for a target architecture in GCC has the following parts:
[...]
@item
An optional @[EMAIL PROTECTED] file in the @[EMAIL PROTECTED]
directory, containing a list of target-specific options. You can also
add other option files using the @code{extra_options} variable in
@file{config.gcc}. @xref{Options}.
...but as so often with gcc documentation, you can probably only find
it if you already know what it says.
Richard
Re: [rtl-optimization] Improve Data Prefetch for IA-64
On Mon, 28 Mar 2005, James E Wilson wrote: > Steven Bosscher wrote: >> OK, so I know this is not a popular subject, but can we *please* stop >> working on loop.c and focus on getting the new RTL and tree loop passes >> to do what we want? > I don't think anyone is objecting to this. [...] > I would however make a distinction here between new development work and > maintenance. It would be better if new development work happened in the new > loop optimizer. However, we still need to do maintenance work in loop.c. ...and since Canqun reported 2.5% improvement on SPEC CFP2000 on ia64 with his current patch, I really think we should consider it. We all know how hard it is to get this kind of improvement on any of the SPECs -- and in fact improving the current optimizers will make raise the bar for the new ones. ;-) Question is: who is going review/potentially approve this patch? Gerald
Re: ISO C prototype style for libiberty?
On Fri, 25 Mar 2005, Joe Buck wrote: > Any retro people out there still trying to run SunOS 4.x? Richard K., as evidenced by the missing Reference:s headers in his mails. But I doubt he's actually bootstrapping GCC on that machine. :-} Gerald
Re: Use Bohem's GC for compiler proper in 4.1?
[EMAIL PROTECTED] (Gabriel Dos Reis) wrote on 02.04.05 in <[EMAIL PROTECTED]>: > While I know a bit of third-wrld, I have also been working in some western > European countries for a sufficiant time to say that, well, far many real > machines used there for work in univeristies and research labs still > don't go beyond 512Mb memory; and they really would love to use GCC and GCC > should be usable on those machines. Not just Europe either, if you go even a little bit higher. I occasionally go looking for possible motherboards, and surprisingly many aren't expandable beyond two gigabytes; and even 64bit ones often seem to be limited at or under four! I've one gig today, so I'd like a replacement that can take more than two ... MfG Kai
Re: RFC: #pragma optimization_level
[EMAIL PROTECTED] (Mark Mitchell) wrote on 01.04.05 in <[EMAIL PROTECTED]>: > In fact, I've long said that GCC had too many knobs. > > (For example, I just had a discussion with a customer where I explained > that the various optimization passes, while theoretically orthogonal, > are not entirely orthogonal in practice, and that truning on another > pass (GCSE, in this caes) avoided other bugs. For that reason, I'm not > actually convinced that all the -f options for turning on and off passes > are useful for end-users, although they are clearly useful for debugging > the compiler itself. I think we might have more satisfied users if we > simply had -Os, -O0, ..., -O3. However, many people in the GCC > community itself, and in certain other vocal areas of the user base, do > not agree.) Well, yes and no - I sometimes think that gcc doesn't have *enough* knobs. But, really, not all knobs are equal. There are classes of knobs that implement a certain kind of control (for example, the -Wxxx flags). There are too many knobs in the sense that, for historical reasons, these seemingly-similar knobs often work in subtly different ways. And there are not enough knobs in the sense that these knobs do not cover the whole spectrum that one would want covered - again, mostly for historical reasons. Regularization would be a way to get at both problems at the same time. A simple regular class of knobs can be handled much better by actual people than a somewhat smaller, irregular one - there are fewer rules to remember. To stay with the warning options example, some options are parts of others in nonobvious ways; some rather different warnings are only controlled by one option; some warnings have no option to control them. It's *this* complexity that is the real problem here, I believe. If every warning was accompanied by some (presumably not translated) tag, and there was an option to enable or disable all warnings with that tag, for all tags, that would be much easier to handle, *and* would cover more functionality at the same place. *And* you could actually try to do a complete warning catalogue for the docs, sorted by tag, and it would still work if the warnings themselves were translated and the docs (a much bigger job) weren't. Oh, and you'd have more success googling for that warning, too. MfG Kai
Re: Use Bohem's GC for compiler proper in 4.1?
[EMAIL PROTECTED] (Mike Stump) wrote on 01.04.05 in <[EMAIL PROTECTED]>: > On Friday, April 1, 2005, at 08:48 AM, Stefan Strasser wrote: > > if gcc uses more memory than physically available it spends a _very_ > > long time swapping > > Swapping, what's that? Here's $20, go buy a gigabyte. $20? That does not seem to correspond to current prices: * PC100 SDRAM 512MB ab 80.50 EUR * PC133 SDRAM 512MB ab 38.89 EUR * PC266 DDRRAM 1GBab 86.90 EUR * PC266 DDRRAM 512MB ab 38.00 EUR * PC333 DDRRAM 1GBab 93.00 EUR * PC333 DDRRAM 512MB ab 34.99 EUR * PC400 DDRAM 512MB ab 32.58 EUR * PC400 DDRRAM 1GBab 84.00 EUR * PC433 DDRAM 512MB ab 85.00 EUR * PC433 DDRRAM 1GBab 184.00 EUR * PC466 DDRAM 512MB ab 56.92 EUR * PC466 DDRRAM 1GBab 116.88 EUR * PC667 DDR2RAM 512MB ab 118.44 EUR * PC800 RDRAM 1GB ab 570.00 EUR * PC800 RDRAM 512MB ab 147.49 EUR But where do I stick that gigabyte? All my memory slots are in use with the current gigabyte. (And yes, this machine *does* swap: total used free sharedbuffers cached Mem: 1030916 978872 52044 0 301948 429344 -/+ buffers/cache: 247580 783336 Swap: 5123072 5534044569668 ) That's while *not* bootstrapping. Bootstrap is *slow*. processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 6 model name : AMD Athlon(tm) Processor stepping: 2 cpu MHz : 1145.142 cache size : 256 KB fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow bogomips: 2287.20 Not an old 486 here. MfG Kai
Re: Use Bohem's GC for compiler proper in 4.1?
Zack Weinberg wrote: Last year CodeSourcery had a contract to speed up the C++ front end at -O0, and we found that small linear reductions in memory usage corresponded directly to small linear reductions in time usage, at about a 2:1 ratio (so 1% less memory -> 0.5% less time). That wouldn't be worth bothering with except that there are *lots* of places where such reductions are available. We eventually got something like a 40% overall speedup just from this. (Sorry, I haven't got exact numbers.) Right I am aware of that work, but we are talking now, so the question is do similar opportunities still exist?
Re: Use Bohem's GC for compiler proper in 4.1?
Gabriel Dos Reis wrote: I wasn't aware that people were exclusively concentrating on small linear gains. Since no one said they were, and since they aren't, it is not surprising that you would be unaware of this non-fact :-) I didn't say people were exclusively concentrating on such gains by any means, just that it makes more sense to look for good targets of opportunity. Some of the suggestions in this thread seemed dubious to me from that point of view.
Re: Use Bohem's GC for compiler proper in 4.1?
Robert Dewar <[EMAIL PROTECTED]> writes: > Zack Weinberg wrote: >> Last year CodeSourcery had a contract to speed up the C++ front end at >> -O0, and we found that small linear reductions in memory usage >> corresponded directly to small linear reductions in time usage, at >> about a 2:1 ratio (so 1% less memory -> 0.5% less time). That >> wouldn't be worth bothering with except that there are *lots* of >> places where such reductions are available. We eventually got >> something like a 40% overall speedup just from this. (Sorry, I >> haven't got exact numbers.) > > Right I am aware of that work, but we are talking now, so the question > is do similar opportunities still exist? Absolutely. Most of the memory-saving potential discussed in my and Nathan Sidwell's paper from last GCC summit, for instance, remains unrealized. zw
Re: RFC: #pragma optimization_level
Robert Dewar wrote: A little note is that Ada has a pragma Opimize that would make use of this feature (it's currently pretty much ignored). Though what GCC does for a compilation unit with Ada's pragma Optimize(Off); inside it is close to what some users seem to be wanting in C. GCC does complain about an attempt to translate the program below with optimization turned on: $ gcc -gnatv -c -O2 opt.adb ... 2.pragma optimize(Off); | >>> warning: must specify -O0 procedure Opt is pragma Optimize(Off); begin for k in 1 .. 1_000_000 loop null; end loop; end Opt;
Re: RFC: #pragma optimization_level
On Apr 1, 2005, at 16:36, Mark Mitchell wrote: In fact, I've long said that GCC had too many knobs. (For example, I just had a discussion with a customer where I explained that the various optimization passes, while theoretically orthogonal, are not entirely orthogonal in practice, and that truning on another pass (GCSE, in this caes) avoided other bugs. For that reason, I'm not actually convinced that all the -f options for turning on and off passes are useful for end-users, although they are clearly useful for debugging the compiler itself. I think we might have more satisfied users if we simply had -Os, -O0, ..., -O3. However, many people in the GCC community itself, and in certain other vocal areas of the user base, do not agree.) Pragmas have even more potential for causing problems than command-line options. People are generally persuaded more easily to change optimization options, than to go through hundreds of source files fixing pragmas. As the average life of a piece of source code is far longer than the life-span of a specific GCC release, users expect to compile unchanged source code with many different compilers. For this reason, I think it is big mistake to allow pragmas to turn on or off individual passes. The internal structure of the compiler changes all the time, and pragmas written for one version may not make sense for another version. The effect will be that over time, user pragmas are wrong more often than right, and the compiler will often do better when just ignoring them all together. (This is when people will ask for a -fignore-source-optimization-pragmas flag.) Pressure on GCC developers to maintain compatibility with old flags will increase as well. This is a recipe for disaster. I think arguments for optimization level should have the following properties: - Obvious meaning, independent of compiler "brand" and version - Similar or identical to widely used pragmas in other compilers - Only broad definitions, to prevent over specification - Pragmas are only hints: the compiler may decide to honor them or not Most cases where pragmas would be used profitably are caused by deficiencies in the compiler. Future improvements will make the hints gradually obsolete. Broad classifications such as "optimize size" or "don't optimize" will stay useful longest. Very specific options such as "optimize using the first scheduler pass" will be obsolete very fast and are not meaningful across a range of compilers. optimization control seems to be something lots of people really want, and other compilers do offer it. I think it can be particularly useful to people who want to work around compiler bugs in a particular routine, without refactoring their code, or losing all optimization for a translation unit. There really are two parts to this: 1. Infra-structure in the compiler to allow for varying optimization levels, such as function attributes, or even finer granularity 2. Syntax for specifying the options in source code The first is even useful without the last. For example, it would be useful for the compiler to automatically optimize for size, if it is known at compile time that a specific function will only be executed once. As the compilers estimates for execution frequency improve, most people would want the compiler to use balanced optimization where "hot" functions are optimized for speed and cold functions are optimized for size. Here, it would even be useful to have granularity per basic block rather than per function, so that different optimization is in effect for cold and hot sections. The syntax part is similar to the "register" keyword in C, which might have been useful at one point, but now is mostly ignored and only retained for compatibility. But doing anything much more elaborate than optimization (off, size, some, all, inlining) corresponding to (-O0, Os, O1, O2, O3) on a per-function basis seems a bad idea. -Geert
Re: RFC: #pragma optimization_level
Georg Bauhaus wrote: Though what GCC does for a compilation unit with Ada's pragma Optimize(Off); inside it is close to what some users seem to be wanting in C. GCC does complain about an attempt to translate the program below with optimization turned on: $ gcc -gnatv -c -O2 opt.adb ... 2.pragma optimize(Off); | >>> warning: must specify -O0 That's what I mean by pretty much ignoring the pragma. It is supposed to affect the optimization, not just check that you being consistent!
Re: ISO C prototype style for libiberty?
Gerald Pfeifer wrote: On Fri, 25 Mar 2005, Joe Buck wrote: Any retro people out there still trying to run SunOS 4.x? Richard K., as evidenced by the missing Reference:s headers in his mails. But I doubt he's actually bootstrapping GCC on that machine. :-} No, he does not do anything but use the (highly irritating :-) mailer on that machine.
