Bug in libiberty configure
I am configuring `libiberty', but during `libiberty' configure on DJGPP (without a working vfork), configure reports that I have a working vfork. This is a bug in configure.ac. Samuel Lauber -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Re: PATCH RFA: Use years for ChangeLog names
> As originally proposed here: > http://gcc.gnu.org/ml/gcc/2005-01/msg00031.html > > I propose switching the ChangeLogs to use year-based names rather than > numeric indexes. > > Specifically, I propose adding these files: > > ChangeLog-1997: from last part of ChangeLog.0 > ChangeLog-1998: from first part of ChangeLog.0 and last part of ChangeLog.1 > ChangeLog-1999: from first part of ChangeLog.1 and all of ChangeLog.2 > ChangeLog-2000: from ChangeLog.3 and ChangeLog.4 > ChangeLog-2001: from ChangeLog.5 and ChangeLog.6 > ChangeLog-2002: from ChangeLog.7 and ChangeLog.8 > ChangeLog-2003: from ChangeLog.9 and ChangeLog.10 > ChangeLog-2004: from ChangeLog.11 and ChangeLog.12 > > There is one entry at the end of ChangeLog.11 which would move into > ChangeLog-2003 rather than ChangeLog-2004. > > Then these files would be removed: > > ChangeLog.0 > ChangeLog.1 > ChangeLog.2 > ChangeLog.3 > ChangeLog.4 > ChangeLog.5 > ChangeLog.6 > ChangeLog.7 > ChangeLog.8 > ChangeLog.9 > ChangeLog.10 > ChangeLog.11 > ChangeLog.12 > > Going forward, in early July of each year ChangeLog would be moved > into ChangeLog-. Then in early January, ChangeLog would be moved > to the front of ChangeLog-. > > The intent of this patch is to make it easier to find old ChangeLog > entries when you know the approximate date. Rather than having to > remember the association of ChangeLog indexes and years, you can just > look at the ChangeLog for the appropriate year. This is also how some > other GNU programs organize their ChangeLog files, including libhava > and libstdc++-v3. > > When I proposed this a couple of months ago, Hans-Peter objected: > http://gcc.gnu.org/ml/gcc/2005-01/msg00640.html > I honestly didn't understand the objection. Hans-Peter, let me know > if you want to try again to explain it. I'm not him, but everybody in the world dosen't agree about things. Some of us disagree and think things are enough. > If this patch is approved, I will follow up with a similar patch for > gcc/cp/ChangeLog*. In fact, perhaps that one could be pre-approved. I would like that. Since ChangeLogs are primarily for historical intrest, a year would make it easier to find. Samuel Lauber -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
GCC generating invalid assembly
I compiled unexec.c from Emacs 21.3 with -O2, and I got the error from GNU as on line 1498: Fatal error: C_EFCN symbol out of scope I'm on the x86. This only happens if all three of the following are satisfied 1) -gcoff debugging information is being generated 2) -funit-at-a-time is on 3) -O is on Turning off -O caused it to work fine. Turning off -funit-at-a-time caused it to work fine. Using a diffrent debugging information format caused it to work fine. Samuel Lauber -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
re: GCC generating invalid assembly
> > I compiled unexec.c from Emacs 21.3 with -O2, and I got the error > > from GNU as on line 1498: > > > > Fatal error: C_EFCN symbol out of scope > > > > I'm on the x86. This only happens if all three of the following > > are satisfied > > > > 1) -gcoff debugging information is being generated > > 2) -funit-at-a-time is on > > 3) -O is on > > > > Turning off -O caused it to work fine. Turning off > > -funit-at-a-time caused it to work fine. Using a diffrent > > debugging information format caused it to work fine. > > You forgot to say which version of gcc. 3.4.3. > Is this maybe http://gcc.gnu.org/PR9963 ? No. I'm on i386-pc-msdosdjgpp. Samuel Lauber -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
`make uninstall' and GCC
The gccinstall info says that `make uninstall' would open a can of worms. I don't get it. Why? Samuel Lauber -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Use Bohem's GC for compiler proper in 4.1?
I know that Bohem's GC is used in the Java runtime for GCC. However, the compiler proper itself can _really_ cramp people's avalible RAM (for those who don't belive me and have Windows w/ DJGPP, change all the memory controls from `auto' to the highest value and just try to compile libiberty/regex.c), so my suggestion is usage of Bohem's GC in the compiler proper itself. Samuel Lauber -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Re: Use Bohem's GC for compiler proper in 4.1?
Perhaps then a scheme in which the compiler 1) compresses all tree structures (this would be a good project) 2) after each pass, all internal structures are freed unless doing so would create a dead pointer (maybe an -Om option like -Os but saves compilation memory?) 3) dosen't use memory in general, i.e do things like int i; for (i = 0; i != n_something; i++) putc(getc(fp), ofp); instead of things like pointer_to_something = malloc(n_something * sizeof(int)); fgets(n_something, pointer_to_something, fp); fputs(pointer_to_something, ofp); 4) use less memory-intensive alogrithms and investigate using more memory-efficent repersentations Samuel Lauber > > > > I know that Bohem's GC is used in the Java runtime for GCC. > > > > However, the compiler proper itself can _really_ cramp people's > > > > avalible RAM (for those who don't belive me and have Windows w/ > > > > DJGPP, change all the memory controls from `auto' to the highest > > > > value and just try to compile libiberty/regex.c), so my suggestion > > > > is usage of Bohem's GC in the compiler proper itself. > > > > > > Do you have any reason to believe that such a change would reduce > > > memory consumption? > > > > I should note this is a loaded question, because anyone who has > > actually tried using boehm's gc with gcc will tell you the memory > > usage actually increases, not decreases. > > > > It's almost as if conservative mark and sweep is not going to work > > as well as accurate mark and sweep. > > Astonshing, isn't it? :-) > > To be fair to the Boehm gc, though: it isn't inherently a conservative > collector, but will also do precise gc. > > Andrew. -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Re: Use Bohem's GC for compiler proper in 4.1?
>> 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. > Now, having said that, we do believe that it would make for > interesting research to try less memory intensive algorithms, or to > rearrange code so that the working set is reduced to help boost > cache hits. Currently gcc takes a cache miss every 20 > instructions, or some ungodly number, and that really saps > performance. Would it be possible for an option -fprofile-cache that allows GCOV to profile cache hits/misses? That would really pay off during a profiled bootstrap. And an option -ftry-keeping-on-stack that (on machines allowing random access[1] to the stack) attempts to use the upper part of the stack as a storage for automatic (or equivlent for programming langauge) variables on stack? That would help[2] reduce GCC's cache misses, because not only is it cached, it's there. Samuel Lauber [1] I don't know if any machines do, but last time I looked at `-1(%esp)', I thought so. [2] It would also have the disadvantage that if a program wrecks havoc on the stack or overflows it, some internal variables might get out of sync and cause the generated program to core-dump (a lesson to be learned from GCC 3.3.3's [flaky] SSA optimizer). -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Re: Use Bohem's GC for compiler proper in 4.1?
>> 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. > Now, having said that, we do believe that it would make for > interesting research to try less memory intensive algorithms, or to > rearrange code so that the working set is reduced to help boost > cache hits. Currently gcc takes a cache miss every 20 > instructions, or some ungodly number, and that really saps > performance. Would it be possible for an option -fprofile-cache that allows GCOV to profile cache hits/misses? That would really pay off during a profiled bootstrap. And an option -ftry-keeping-on-stack that (on machines allowing random access[1] to the stack) attempts to use the upper part of the stack as a storage for automatic (or equivlent for programming langauge) variables on stack? That would help[2] reduce GCC's cache misses, because not only is it cached, it's there. Samuel Lauber [1] I don't know if any machines do, but last time I looked at `-1(%esp)', I thought so. [2] It would also have the disadvantage that if a program wrecks havoc on the stack or overflows it, some internal variables might get out of sync and cause the generated program to core-dump (a lesson to be learned from GCC 3.3.3's [flaky] SSA optimizer). -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Re: Use Bohem's GC for compiler proper in 4.1?
>> 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. > Now, having said that, we do believe that it would make for > interesting research to try less memory intensive algorithms, or to > rearrange code so that the working set is reduced to help boost > cache hits. Currently gcc takes a cache miss every 20 > instructions, or some ungodly number, and that really saps > performance. Would it be possible for an option -fprofile-cache that allows GCOV to profile cache hits/misses? That would really pay off during a profiled bootstrap. And an option -ftry-keeping-on-stack that (on machines allowing random access[1] to the stack) attempts to use the upper part of the stack as a storage for automatic (or equivlent for programming langauge) variables on stack? That would help[2] reduce GCC's cache misses, because not only is it cached, it's there. Samuel Lauber [1] I don't know if any machines do, but last time I looked at `-1(%esp)', I thought so. [2] It would also have the disadvantage that if a program wrecks havoc on the stack or overflows it, some internal variables might get out of sync and cause the generated program to core-dump (a lesson to be learned from GCC 3.3.3's [flaky] SSA optimizer). -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Packing booleans?
Would it be possible to have a -fpack-bools option that packs booleans into the smallest form possible (8 booleans -> 1 8-bit reg, etc.) into a register (or memory, as the case may be)? Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: Packing booleans?
> Unless you are using an architecture with btst, bset, bclr instructions. Pretty much any architechure that could be called a binary computer has something like that ;-) Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: Packing booleans?
> If this were being done at the level of register allocation, why would > one need a user visible option? 'Just' rearrange the register file to look > like a set of single bit registers overlaid on a more conventional register > file. As someone pointed out, this might change semantics (read: screw up ;-) of the * and & operators: &somebool, though it would be placed into memory, wouldn't deserve an address, since most[1] architechures aren't bit- adressable. Samuel Lauber [1] I said ``some'', not ``all'', because the TMS340x0 port is. -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
FORTH frontend?
I am experimenting with the FORTH langauge, and I would like a front-end to be added to GCC. I think I can get most of the parts down, but how can I generate a tree that can be used in the code-generator? Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: FORTH frontend?
> There are a few diffciulties here, particularly with addressing the > open stack in an efficient way. > > This problem is probably going to get a little off-topic for this > group, and it may be better to discuss this on comp.lang.forth. I wasn't asking about the langauge implementation. What I want to know is how to plug a frontend I write into GCC's code-generator and optimizer. Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Automatically choosing registers for register variables?
The GCC manual says that ``Eventually there may be a way of asking the compiler to choose a register automatacally...'' Would it be possible to implement it? My idea is: add a builtin function __builtin_choose_register(HINTS) with the property a) it is special in that the return value is ``constant enough'' to be used in a ``register TYPE foo asm()'' (preprocessor expansion?) b) it looks for a register c) it honors the HINTS argument (more on this later in this message) On the part of the machine description, there would be a macro, BUILTIN_CHOOSE_REG(HINTS) that returns a string containing what __builtin_ choose_register would return. The HINTS argument would be a bitmask contisting of the following bits: 01 Use a register normally used for global variables. 02 Use highest register number possible (on CISC archs highest letter) 04 As last resort use memory etc Other bits are arch-dependant Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Automatically choosing registers for register variables?
The GCC manual says that ``Eventually there may be a way of asking the compiler to choose a register automatacally...'' Would it be possible to implement it? My idea is: add a builtin function __builtin_choose_register(HINTS) with the property a) it is special in that the return value is ``constant enough'' to be used in a ``register TYPE foo asm()'' (preprocessor expansion?) b) it looks for a register c) it honors the HINTS argument (more on this later in this message) On the part of the machine description, there would be a macro, BUILTIN_CHOOSE_REG(HINTS) that returns a string containing what __builtin_ choose_register would return. The HINTS argument would be a bitmask contisting of the following bits: 01 Use a register normally used for global variables. 02 Use highest register number possible (on CISC archs highest letter) 04 As last resort use memory etc Other bits are arch-dependant Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: unexpected hidden symbol in gcc 4.0.0
> > The documentation for -fvisibility=hidden suggets that this switch is > > useful for shared libraries, to make things smaller and faster. It > > doesn't seem to be appropriate for object libraries. > It's done *exactly* so that we catch this bug in your configury. I don't know about you, but forcing a link failure in good code just because someone screwed up GCC configuration is probably the of the most worst compiler hacker's sins. Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Making GCC faster
There has been a lot of work recently on making GCC output faster code. But GCC isn't very fast. On my slow 750MHz Linux box (which the PIII in it is now R.I.P), it took a whole night to compile 3.4.3. On my fast iBook G4 laptop, to compile just one source file in Perl made me wait long enough for me to start doing ``tick-tock tick-tock tick-tock ...''. Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option
> Hello, > > I have a question about a valid C code. I am trying to compile > the following code in MacOSX (*). I don't understand what the > problem is ? Could someone please explain me what is going on ? > Since I declare the variable with extern I should not need to pass > -fno-common, right ? > > Thanks for your help > Mathieu > > foo.h: > extern int bar[]; > > foo.c: > int bar[4 * 256]; > > And compile lines are: > $ gcc -o foo.o -Wall -W -fPIC-c foo.c > $ gcc -dynamiclib -o libfoo.dylib foo.o > ld: common symbols not allowed with MH_DYLIB output format with the > -multi_module option > foo.o definition of common _bar (size 4096) > /usr/bin/libtool: internal link edit command failed > > using gcc 3.3 20030304 (Apple Computer, Inc. build 1671) This is not a problem with GCC. In fact, it is not a problem at all. It is a misunderstanding of the linker. When you run gcc -dynamiclib -o libfoo.dylib foo.o it really does libtool -dynamic -o libfoo.dylib foo.o which becomes ld -dylib -o libfoo.dylib foo.o However, -multi_module is the default, so it really is ld -dylib -o libfoo.dylib foo.o -multi_module -multi_module is enabled by default, so you can get errors from the linker of the form `libfoo.dylib(foo.o)' when there's a link problem. The error happens because a) an `extern' variable is called a `common variable' b) in multipule module mode, common variables are not allowed c) if they were allowed, it would defeat the purpose of that option: better diagnostics To fix it, add -Wl,-single_module to the end of the GCC command line. However, note that subsequent linker errors will refer to `libfoo.dylib' instead of `libfoo.dylib(foo.o)'. Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option
> Hello, > > I have a question about a valid C code. I am trying to compile > the following code in MacOSX (*). I don't understand what the > problem is ? Could someone please explain me what is going on ? > Since I declare the variable with extern I should not need to pass > -fno-common, right ? > > Thanks for your help > Mathieu > > foo.h: > extern int bar[]; > > foo.c: > int bar[4 * 256]; > > And compile lines are: > $ gcc -o foo.o -Wall -W -fPIC-c foo.c > $ gcc -dynamiclib -o libfoo.dylib foo.o > ld: common symbols not allowed with MH_DYLIB output format with the > -multi_module option > foo.o definition of common _bar (size 4096) > /usr/bin/libtool: internal link edit command failed > > using gcc 3.3 20030304 (Apple Computer, Inc. build 1671) This is not a problem with GCC. In fact, it is not a problem at all. It is a misunderstanding of the linker. When you run gcc -dynamiclib -o libfoo.dylib foo.o it really does libtool -dynamic -o libfoo.dylib foo.o which becomes ld -dylib -o libfoo.dylib foo.o However, -multi_module is the default, so it really is ld -dylib -o libfoo.dylib foo.o -multi_module -multi_module is enabled by default, so you can get errors from the linker of the form `libfoo.dylib(foo.o)' when there's a link problem. The error happens because a) an `extern' variable is called a `common variable' b) in multipule module mode, common variables are not allowed c) if they were allowed, it would defeat the purpose of that option: better diagnostics To fix it, add -Wl,-single_module to the end of the GCC command line. However, note that subsequent linker errors will refer to `libfoo.dylib' instead of `libfoo.dylib(foo.o)'. Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: ld: common symbols not allowed with MH_DYLIB output
> int bar [ 4 * 256 ] = { 0,1,2, ... };
>
> I did not changed nor any compiler option, neither any
> declaration. I still cannot see the difference in between those
> two, since the declaration is exactly the same. The only difference
> being a default initialization.
There is a more subtle diffrence at work here. According to ANSI:
``An external declaration for an object is a definition if it has an
initalizer.
*An external object declaration that does not have an initalizer, and does not
contain the extern specifier, is a tentaive definition.* If a definition for
an
object appears in a translation unit, all its tentative definitions become a
single definition with initalizer 0.''
The highlighted sentence is very subtle, but it is the entire diffrence between
an executables `text' and `bss' sections. In Darwin, ``tentative definition''
is called ``common symbol''. _When you add the initalizer, you make the
definition non-tentative_. Got it? (If not, you should reread this paragraph.)
The moral of the story is, be sure to always read the fine print.
(Translation:
keep track of subtleties when doing work.)
Samuel Lauber
--
___
Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com
Powered by Outblaze
Re: Will Apple still support GCC development?
> >> Intel already handed icc + performace libs to apple, but from my > >> experience icc doesn't create any faster code then gcc. Is there > >> any *recent* benchmark that shows otherwise? > > Define "recent". > > >> I know that heavy math code is likely to perform better on icc but > >> this is rather uninteresting to general audience. > > In general, the choice of compiler is unimportant for the performance of > most user-bound programs. I doubt KDE would run much faster if compiled > with ICC, for example. > > However, for codecs, image processing, and other math-intensive > operations, Intel generally produces faster code, though > not always. This isn't just a matter of floating-point generation -- > Intel's vectorizer gives their compiler a distinct advantage over GCC, > although I expect GCC to catch up in this regard. > > Rather than speculate about Apple, it would be better to find more > funding for GCC development. I know that some people are working on this. I don't think you should worry about this. Because: a) Apple just started the transition to PowerPC64. (A politically correct statement would be that Apple just stopped the transition to PowerPC32). If they were still working on that (large parts of OSX still aren't 64-bit), the programmers at Apple would probably be very annoyed, considering that pretty much everything (exceptions: Darwin, iTunes, AppleWorks, QuickTime) was written for the PowerPC. b) It's unlikely that _every_ Mac software company would port all of there programs to the x86, more or less Apple themselves. c) Some existing work (e.g. BootX) would have to be completly trashed or rewritten from scratch. d) Most of us don't want to waste there money on a new Mac just because there switching to x86. In summary, we shouldn't worry about this, because 75% of what Apple is planning to do is a bad idea for them. Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option
> > I'd put this more simply... > > > > On Monday, June 6, 2005, at 02:06 PM, Mathieu Malaterre wrote: > >>I have a question about a valid C code. I am trying to > >> compile the following code in MacOSX (*). I don't understand > >> what the problem is? > > > > You must use -fno-common when you are building dynamic libraries on darwin. > > > >> Could someone please explain me what is going on? > > > > You didn't use -fno-common. > > > > > > > Can someone please tell me then which one of the three > possibilities is the right one: > > #1. I need to tell the linker to use -single_module > #2. Rewrite the code to make a fake initialization > #3. I need to pass -fno-common to the compiler >From a standpoint of just getting the thing deployed, any one of these three is right. > I really don't understand why I need to do that, since this is > valid C code. Why the linker does not default to proper option, or > why the -fno-common option isn't used. At compile time gcc should > figure that out, right ? The code parses, has the right nesting levels of blocks, arrays, parens, has valid types, the statements are valid, ETC. As far as the ANSI standard is concerned, this code is valid, and it's the programmer's buisness to read the documentation for the toolchain and understand that this kind of thing might happen. It is not GCC's buisness, it is not any ANSI compiler's buisness, it is not any pre-ANSI compiler's buisness, it is not any compiler's buisness. GCC does not know and does not care that this might be invalid input to the linker. All that GCC cares about is that it is valid C code and the assembler likes it's assembly output. All other parts of the toolchain are not anyone's buisness but the programmer. The ANSI standard dosen't specify anything about a linker; the only thing that makes GCC a compiler is the assembly source it produces. It isn't the compiler's buisness what goes in the assembler's object file. It isn't the compiler's buinsness what goes in the final executable. > Now compared to the linker option, at least the compiler flag I can > specify it for the specific file I want, which is great. But then > again why is this up to the user to do it ? Is there a performance > reason ? Why isn't it the default ? The compiler dosen't know that you might be making a dynamic library from it's object file. It dosen't know about the linker having that behavior. -fno-common is not default because it causes symbols to be moved out of the BSS. Moving symbols out of the BSS causes extra code to be generated. And most people agree that the BSS is the proper resting place for unitalized symbols. > How do other people do when porting *nix lib to MacOSX ? Is this is > trial-and-error process to get the lib compiled ? Perl does it by initalizing the values. Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option
> Sigh. #2 doesn't work as the compiler can synthesize common > variables that you can't control, and when it does this, things > won't work. Forcing people to use -single_module strikes me as > wrong. I don't know why it was set up like that. Come to think of it, this would probably be a really good thread to forward to the Darwin mailing lists. They would probably know ;-). > So, from the standpoint of good advice, -fno-common is the only answer. But if you already have good code (who would make a shared library out of poorly written code?), then you should use -single_module because the only visible influence on the resulting library is linker diagnostics, but a good shared library wouldn't trigger any linker errors. (And plus, the linker does a good job of finding errors before the library even gets stored to disk, unless you use options like `-undefined dynamic_lookup'). Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: RFA: Integrate ABI testsuite in GCC
> I have this x86-64 ABI testsuite I worked on lately again (after some > years lingering around, it was first written when we did the port on > simulators still). It currently lies on cvs.x86-64.org in the 'abitest' > module, for the curious (it has anoncvs too). > I would like to somehow integrate this into GCC, so that it is run > automatically when doing a make check. I've pondered about several ways > to do this: >1) add something like --with-abitest=/dir/to/abitest to gccs configure > make check could then use this external path to run the ABI testsuite >2) mirror the testsuite somehow inside GCC's CVS to be tighly integrated > > I'm not sure which way is best. The second one has the advantage that you > can't miss running it, when just checking out GCC and developing on it. > The first one has the advantage the GCC's CVS would not be clobbered with > something external, and very architecture specific. > > Currently the testsuite contains some testcase generators written in C, > and some hand-written testcases. I'm thinking about rewriting the > generators at least in something better suited to text manipulation, i.e. > bash or perl. What would be the feeling having such kind of stuff in > GCC's CVS? That stuff should go in directories like `gcc/config/PLATFORM/'. Even better, make the testsuite platform-independant. And write the generators in perl ;-). > Basically I'm looking for some consensus how to make my above goal happen. > So anyone any suggestions, ideas, flames? What about a more generic mechanisim `--with-extratest=/path/to/test' that causes an extra testsuite in that path to be executed as part of `make test'? Maybe even the GCC testsuite could be based on an even more generic harness mechanisim that expects test information in some agreed output format (I'm thinking TAP) and tests everything and outputs it in a format similar to the current format. Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
Re: Reporting bugs: there is nothing to gain in frustrating reporters
> > > Agreed. But keep in mind that it is not necessary to reply: once the bug is > > > open and confirmed, the last comment "wins", in a way. If the bugmaster > > > wanted to close it, he would just do it, so an objection in a comment does > > > not make the bug invalid per se. > > > > But an objection from one of the bugmasters *is* enough to keep people > > from presenting a patch. > > How do you come to this conclusion? From my experience this > is untrue - bugs get fixed because either someone feels resposible, > it's too easy to do, or someone has personal interest in getting the > bug fixed. Negative or positive comments do not change this. Once I submitted a bug to a project (not GCC) in November '04. I didn't recive a conformation mail until last month! Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com Powered by Outblaze
RSS feed for webpage?
Would it be possible for the GCC webpage to have a RSS feed for the news? Samuel Lauber -- ___ Surf the Web in a faster, safer and easier way: Download Opera 8 at http://www.opera.com
Re: GCC 3.3.5: -march=i586 does not use all pentium FPU instructions
I think Intel's confusing numbering system has confused
you. All ix86 processors, if the expression
x in first ix86 < x in second ix86
holds true, then second ix86 is compatible. The i586 is
NOT the Pentium. Nor is the i686. But the i686 was one of
the first Intel processors with built-in FPU. If you are
asking for Pentium, try the following switches:
-march=pentium
-march=pentium -mmmx # Pentium MMX
-march=pentium2
-march=pentium3
-march=celron
-march=pentium4
-march=prescott # this will probably get you in trouble
If you use any of these switches, it will add FP
instruction calls. -march=prescott has caused more than
one problem elsewhere.
Samuel Lauber
> I was wondering why the above gcc parameter does not enable the use of the
> fst/fld opcodes for pentium processors, while -march=i686 does. The Intel
> manuals specifically say that they can be used across all pentium processors.
>
> Example :
> $ gcc -g -c -mcpu=i586 mdouble.cpp -o mdouble.o
> $ objdump -dS -M intel mdouble.o
> <...>
> void foo()
> {
> 0: 55 push ebp
> 1: 89 e5 movebp,esp
> 3: 83 ec 10subesp,0x10
> double d;
> double a;
> d = 3.0;
> 6: b8 00 00 00 00 moveax,0x0
> b: ba 00 00 08 40 movedx,0x4008
>10: 89 45 f8movDWORD PTR [ebp-8],eax
>13: 89 55 fcmovDWORD PTR [ebp-4],edx
> a = d;
>16: 8b 45 f8moveax,DWORD PTR [ebp-8]
>19: 8b 55 fcmovedx,DWORD PTR [ebp-4]
>1c: 89 45 f0movDWORD PTR [ebp-16],eax
>1f: 89 55 f4movDWORD PTR [ebp-12],edx
> }
>22: c9 leave
>23: c3 ret
>
> While :
> $ gcc -g -c -mcpu=i686 mdouble.cpp -o mdouble.o
> $ objdump -dS -M intel mdouble.o
> <...>
> void foo()
> {
> 0: 55 push ebp
> 1: 89 e5 movebp,esp
> 3: 83 ec 10subesp,0x10
> double d;
> double a;
> d = 3.0;
> 6: dd 05 00 00 00 00 fldds:0x0
> c: dd 5d f8fstp QWORD PTR [ebp-8]
> a = d;
> f: dd 45 f8fldQWORD PTR [ebp-8]
>12: dd 5d f0fstp QWORD PTR [ebp-16]
> }
>15: c9 leave
>16: c3 ret
>
> FLD and FSTP are available on all pentium processors.
> Is there a chance, for other reasons, that my code will not run on a pentium
> if I use -march=i686 ?
--
_
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.
Powered by Outblaze
Re: License text irregularity in gcc/config/mips/linux-unwind.h
__Way__ to close to the LGPL. The LGPL in effect, says the GPL with that kind exception (letting people link this with there program regardless of whether the license is GPL-compatible). I think that those exceptions in `libgcc' are conflicting with one of the sections of the GPL that prevents proprietary software authors from linking in GPLd software. I think that is an important privlage for the free software community. As for the exception missing, it should be kept that way. Samuel Lauber > It seems that most source files for libgcc have the following exception text: > > -8< > > In addition to the permissions in the GNU General Public License, the > Free Software Foundation gives you unlimited permission to link the > compiled version of this file with other programs, and to distribute > those programs without any restriction coming from the use of this > file. (The General Public License restrictions do apply in other > respects; for example, they cover modification of the file, and > distribution when not linked into another program.) > > -8< > > Which allows libgcc to be linked to a program with out forcing that > program to be GPLed. > > gcc/config/mips/linux-unwind.h is part of libgcc but does not have > the exception in its copyright section. > > It seems that this is an oversight. > > I can add the exception if it is deemed the proper thing to do. > > David Daney -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Re: Why is this diagnostic only reported with -pedantic?
This is _not_ a bug. This is _C_, not C++. ISO C99
requires a diagnostic for it. I think what's going on is
that the compiler is warning about a return with a value
in function returning void in foo(), but baz() is trying
to return a value from a function that never returned
anything. This is probably a confusingly worded warning.
Samuel Lauber
> > Given this program:
> > static void foo(void) { return(1); }
> > static void bar(void) { }
> > static void baz(void) { return(bar()); }
> > int main(int argc, char * argv[]) {
> > baz();
> > return(1);
> > }
> >
> > A compile without -pedantic gives a warning for foo(), but not for
> > baz():
> > $ gcc-3.4 foo.c
> > foo.c: In function `foo':
> > foo.c:1: warning: `return' with a value, in function returning void
> >
> > A compile with -pedantic gives a warning for both functions.
> > $ gcc-3.4 -pedantic foo.c
> > foo.c: In function `foo':
> > foo.c:1: warning: `return' with a value, in function returning void
> > foo.c: In function `baz':
> > foo.c:3: warning: `return' with a value, in function returning void
>
> The code in baz() is perfectly legal since ISO C++ allows void
> returns. -pedantic should not warn about it because it is not a GCC extension
> at all. Would you please file a bugreport about the incorrect warning emitted
> for baz()?
>
> Thanks
> Giovanni Bajo
--
_
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.
Powered by Outblaze
Re: 16-bit real-mode code
> Hello > > I ponder about writing a "i386 16bit realmode" gcc backend as my master > thesis - which would be usefull for generating 16-bit bios code needed > by the virtual machine developed at my university. > > Having never programmed any compiler-related stuff and having a strict > deadline (after 6 months) i would appreciate some commments about the > complexity of such a venture. > > thanks in advance > (please reply (also) directly to me, im not subscribed) Complex. RM places a 64K stack segment limit. As far as I know, GCC requires more than that. Also, GCC was only written for 32-bit machines. My suggestions: a) program GCC to fake 32-bitness by using two 16-bit words b) pack bits (somehow!) to fake a >64K stack segment Samuel Lauber -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Re: Suggestion: Different exit code for ICE
> Regressions that cause ICE's on invalid code often go unnoticed in the
> testsuite, since regular errors and ICE's both match { dg-error "" }.
> See for example g++.dg/parse/error16.C which ICE's since yesterday,
> but the testsuite still reports "PASS":
>
>Executing on host:
> /Work/reichelt/gccbuild/src-4.0/build/gcc/testsuite/../g++
> -B/Work/reichelt/gccbuild/src-4.0/build/gcc/testsuite/../
> /Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C
> -nostdinc++
> -I/home/reichelt/Work/gccbuild/src-4.0/build/i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu
>
> -I/home/reichelt/Work/gccbuild/src-4.0/build/i686-pc-linux-gnu/libstdc++-v3/include
> -I/home/reichelt/Work/gccbuild/src-4.0/gcc/libstdc++-v3/libsupc++
> -I/home/reichelt/Work/gccbuild/src-4.0/gcc/libstdc++-v3/include/backward
> -I/home/reichelt/Work/gccbuild/src-4.0/gcc/libstdc++-v3/testsuite
> -fmessage-length=0 -ansi -pedantic-errors -Wno-long-long -S -o error16.s
> (timeout =
> 300)
>
> /Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:8:
> error: redefinition of 'struct A::B'
>
> /Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:5:
> error: previous definition of 'struct A::B'
>
> /Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:8:
> internal compiler error: tree check: expected class 'type', have
> 'exceptional' (error_mark) in cp_parser_class_specifier, at
> cp/parser.c:12407
>Please submit a full bug report,
>with preprocessed source if appropriate.
>See http://gcc.gnu.org/bugs.html> for instructions.
>compiler exited with status 1
>output is:
>
> /Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:8:
> error: redefinition of 'struct A::B'
>
> /Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:5:
> error: previous definition of 'struct A::B'
>
> /Work/reichelt/gccbuild/src-4.0/gcc/gcc/testsuite/g++.dg/parse/error16.C:8:
> internal compiler error: tree check: expected class 'type', have
> 'exceptional' (error_mark) in cp_parser_class_specifier, at
> cp/parser.c:12407
>Please submit a full bug report,
>with preprocessed source if appropriate.
>See http://gcc.gnu.org/bugs.html> for instructions.
>
>PASS: g++.dg/parse/error16.C (test for errors, line 5)
>PASS: g++.dg/parse/error16.C (test for errors, line 8)
>PASS: g++.dg/parse/error16.C (test for excess errors)
>
> (Btw, Mark, I think the regression was caused by your patch for
> PR c++/20152, could you please have a look?)
>
> The method used right now is to not use "" in the last error message,
> but that's forgotten too often.
>
> This calls for a more robust method IMHO.
> One way would be to make the testsuite smarter and make it recognize
> typical ICE patterns itself. This can indeed be done (I for example
> use it to monitor the testcases in Bugzilla, Phil borrowed the patterns
> for his regression tester).
>
> An easier way IMHO would be to return a different error code when
> encountering an ICE. That's only a couple of places in diagnostic.c
> and errors.c where we now have "exit (FATAL_EXIT_CODE);".
> We could return an (appropriately defined) ICE_ERROR_CODE instead.
> The testsuite would then just have to check the return value.
>
> What do you think?
That would certantly be a Good Thing. As far as I know,
regular errors return exit code 1. I have two suggestions
on that:
a) use a testsuite that supports regexps and match a 1
exit code agianst
/^Please submit a full bug report/
b) make it return a diffrent exit code (say -127 or even
2 ;-).
c) make a seperate function for ICEs and make _that_
return exit code indicating ICE. There would be a
disadvantage: as with any code moving, there would still be
some code that didn't call that function
Samuel Lauber
--
_
Web-based SMS services available at http://www.operamail.com.
From your mailbox to local or overseas cell phones.
Powered by Outblaze
GNU INTERCAL front-end for GCC?
I am thinking of including a front-end for INTERCAL for GCC. INTERCAL is an estoric programming langauge that was created in 1972 with the goal of having nothing in common with other langauges (see http://catb.org/~esr/intercal). There is a C implementation of INTERCAL (called C-INTERCAL) that is avalible there. I think it would be a good project(1) as a front-end(2) to GCC. Samuel Lauber (1) -> Don't say that I'm crazy. (2) -> Some of us would like DO .1 <- #0 to be translated into movl $0, v1 -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Re: GNU INTERCAL front-end for GCC?
> > I am thinking of including a front-end for INTERCAL for GCC. INTERCAL > > is an estoric programming langauge that was created in 1972 with the > > goal of having nothing in common with other langauges (see > > http://catb.org/~esr/intercal). There is a C implementation of > > INTERCAL (called C-INTERCAL) that is avalible there. I think it would > > be a good project(1) as a front-end(2) to GCC. > > Show us your patch. > > Any ideas how GCC could implement the implicit COME FROM multitasking? > > Would a VM-based solution satisfy you? (No I'm not comparing Java to > INTERCAL.) Otherwise I think you might have to introduce new (fork ...) > RTL expressions. No, not fork(2); more line Linux clone(2). I don't think that's needed. We could just put in the RTL insns to call fork(2). But since I am typing this up with DJGPP open (which dosen't have fork(2)), I would sincerly like it if we could implement Threaded INTERCAL some other way (pseudo-threads which alternate control every few microseconds?). > > (2) -> Some of us would like > > LOL. BTW has anyone ever else put "Programming skills: INTERCAL on > their CV?" I've never had this queried, even when I've mentioned this > hot skill in interviews (for jobs I was offered)? > > > DO .1 <- #0 > > Not very polite, are you? Funny. > > to be translated into movl $0, v1 > How do you propose we (read: you :) write a testsuite that allows for > the (language-mandated, IIRC) indeterminacy of the success of compiling > the same program multiple times? (IIRC I'm thinking of E774 - is that > the random sometimes-requirement for PLEASE? And how do you test for > the sometimes-ness?) E778 is the unexplained compiler bug. E774 is random compiler bug. The PLEASE requirement is not random: If fewer then 1/5 of the statements begin with PLEASE, the program is insufficently polite. If more then 1/3, too polite. You mean `random compiler bug'. A quick look through `lose.h' from C-INTERCAL found: /* A compiler error has occured (see section 8.1). */ #define E774 "774 RANDOM COMPILER BUG\n\ ON THE WAY TO %d\n" and under it /* An unexplainible compiler error has occured (see J. Lyon or D. Woods). */ #define E778 "778 UNEXPLAINED COMPILER BUG\n\ ON THE WAY TO %d\n" The random compiler bug test could be made by running the compiler about 10 times, and executing each of the 10 executables until one of them random-compiler-bugs. PLEASE test could be made by the following code: DO .1 <- #0 DO .2 <- #0 DO .3 <- #0 (which is insufficently polite) and the too-polite test could be made by changing the first two DOs to PLEASEs. COME FROMs could be handled the same way they are done in C-INTERCAL; set a bit in the tree structure. A comment in the C-INTERCAL `ick.h' next to a member of a `tuple' structure: /* if NZ, a COME FROM touches this line */ Anyway, about the frontend, what does my frontend have to do? Samuel Lauber P.S. Could an ICE make an E778? (Trapping the ICE is left as an exercise to the reader :-) -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
Re: GNU INTERCAL front-end for GCC?
> > (2) -> Some of us would like DO .1 <- #0 > > > > to be translated into movl $0, v1 v1 is the name of a variable. Needed because the manual says that each variable namespace (meshes, spots, tails, what-have-yous, hybrids) has 65535 variables!!! I don't know of any machine that has 65535+65535+65535+65535 regs. We have to use asm variables. > I've no idea for what target that would be valid assembler, but for x86. > the VAX it would be: > > movzwl #0, r1 > > .1 is a 16-bit variable, and nowhere in the INTERCAL documentation > I've found evidence that assigning to a 16-bit variable means: Set > the lower 16 bits of this 32-bit variable to . > > BTW, success ! -- _ Web-based SMS services available at http://www.operamail.com. From your mailbox to local or overseas cell phones. Powered by Outblaze
