Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
"H. Peter Anvin" <[EMAIL PROTECTED]> writes: > Robert Dewar wrote: >> H.J. Lu wrote: >> >>> So that is the bug in the Linux kernel. Since fixing kernel is much >>> easier >>> than providing a workaround in compilers, I think kernel should be fixed >>> and no need for icc/gcc fix. >> >> Fixing a bug in the Linux kernel is not "much easier". You are taking >> a purely engineering viewpoint, but life is not like that. There are >> lots of copies of Linux kernels around and in use. The issue is not >> fixing the kernel per se, it is propagating that change to all >> Linux kernels in use -- THAT'S another matter entirely, and is >> far far more difficult than making sure that a kernel fix is >> qualified and widely proopagated. >> > > Not really, it's just a matter of time. Typical distro cycles are on > the order of 3 years. But distros release fixes regularly for their kernels - and adding a fix for this issue with their next security update is something that is possible for distros (at least for openSUSE ;-), Andreas -- Andreas Jaeger, Director Platform / openSUSE, [EMAIL PROTECTED] SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpR6ZRriAlPf.pgp Description: PGP signature
Re: RELEASE BLOCKER: Linux doesn't follow x86/x86-64 ABI wrt direction flag
* Robert Dewar: > again, in the real world, there are MANY projects that are nothing > like this interactive when it comes to moving to new versions of > operating systems. Sure, but how many of those get to see software compiled with GCC 4.3? If this has any real impact, it's more likely to show up in current systems, where both kernel, libc and GCC are regularly updated, and GCC happens to receive an update before the kernel.
RFC: Idea for code size reduction
Hello everybody, I have a feature request. I'd like to (manually) define some byte blocks, eg. as functions with an identifier. Then, if GCC would emit exactly these bytes, it puts a JMP identifier there instead. This would help by sharing many identical (text/code) byte sequences, to make a smaller image - like -fmerge-constants does for data - and therefor helps for cache locality, too. I wrote some perl scripts to test this. I took a "alldefconfig" i686 kernel, let objdump disassemble it, and on "iret", "ret", "ljmp" or "jmp" with a 4 byte address I store the last few bytes. Another script goes through these block-ends, and estimates the number of bytes saved, if identical sequences get changed into a 5 byte opcode (jump with 32bit address). The original kernel has $ size vmlinux textdata bss dec hex filename 4802166 446554 606208 5854928 5956d0 vmlinux and my scripts emit space savings of about 30kB. Now that's not that much, but for embedded systems it means another userspace binary more. [ If anyone's interested, I can post my scripts here ... they're not that large. ] And, of course, the same can be used for other binaries too - which could save other space as well. (blender-bin, text size 8664025, gives 97KB savings) I'd imagine the use that such: - Built the binary - Run my scripts, to find some common code sequences - Give them to gcc - Rebuild, using the optimizations I don't know whether some new optimize switch could be used, to do all that internally in the compiler and linker. What do you think about that? [ Please keep at least *me* cc'ed - don't know whether that's that interesting for linux-tiny. ] Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)!
Re: RFC: Idea for code size reduction
On Fri, Mar 7, 2008 at 11:02 AM, Philipp Marek <[EMAIL PROTECTED]> wrote: > Hello everybody, > > I have a feature request. > > > I'd like to (manually) define some byte blocks, eg. as functions with an > identifier. Then, if GCC would emit exactly these bytes, it puts a JMP > identifier there instead. > > This would help by sharing many identical (text/code) byte sequences, to > make a smaller image - like -fmerge-constants does for data - and therefor > helps for cache locality, too. > > > I wrote some perl scripts to test this. I took a "alldefconfig" i686 > kernel, let objdump disassemble it, and on "iret", "ret", "ljmp" or "jmp" > with a 4 byte address I store the last few bytes. Another script goes > through these block-ends, and estimates the number of bytes saved, if > identical sequences get changed into a 5 byte opcode (jump with 32bit > address). > > > The original kernel has > $ size vmlinux > textdata bss dec hex filename >4802166 446554 606208 5854928 5956d0 vmlinux > > and my scripts emit space savings of about 30kB. Now that's not > that much, but for embedded systems it means another userspace > binary more. > [ If anyone's interested, I can post my scripts here ... they're not > that large. ] > > And, of course, the same can be used for other binaries too - which could > save other space as well. (blender-bin, text size 8664025, gives 97KB > savings) > > > I'd imagine the use that such: > - Built the binary > - Run my scripts, to find some common code sequences > - Give them to gcc > - Rebuild, using the optimizations > > I don't know whether some new optimize switch could be used, to do all > that internally in the compiler and linker. > > > What do you think about that? > [ Please keep at least *me* cc'ed - don't know whether that's that > interesting for linux-tiny. ] Sounds like what -frtl-abstract-sequences is trying to do. Richard.
Re: RFC: Idea for code size reduction
Hi, Philipp Marek wrote: Hello everybody, I have a feature request. and my scripts emit space savings of about 30kB. Now that's not that much, but for embedded systems it means another userspace binary more. [ If anyone's interested, I can post my scripts here ... they're not that large. ] And, of course, the same can be used for other binaries too - which could save other space as well. (blender-bin, text size 8664025, gives 97KB savings) I'd imagine the use that such: - Built the binary - Run my scripts, to find some common code sequences - Give them to gcc - Rebuild, using the optimizations I don't know whether some new optimize switch could be used, to do all that internally in the compiler and linker. What do you think about that? [ Please keep at least *me* cc'ed - don't know whether that's that interesting for linux-tiny. ] Regards, Phil Can I test your script in my embedded system? Can you send to me? Michael
Re: RFC: Idea for code size reduction
Hello Richard! [ I took linux-tiny out - it's moderated, and I don't want to spam them. ] > Sounds like what -frtl-abstract-sequences is trying to do. Yes, thank you. I didn't know that; that should be close. *But*: I think it doesn't work. $ size vmlinux-as vmlinux-Os textdata bss dec hex filename 4797637 446554 606208 5850399 59451f vmlinux-as 4802166 446554 606208 5854928 5956d0 vmlinux-Os If I don't err there's only 4500 bytes difference ... which is *a lot* different to my 30kB. That doesn't mean that my scripts are correct - they might simply be buggy ... but I verified some by hand. Well, see the other message for the scripts. Thank you for your answer! Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)!
Re: RFC: Idea for code size reduction
Hello Michael! > Can I test your script in my embedded system? > Can you send to me? Here you are. code_overlap.pl - disassembles a binary, and outputs a list (address, name, instruction, bytes) to STDOUT. bytes_saved.pl - takes such a list, and tries to estimate the amount of bytes that could be saved. I normally use them this way: #!/bin/sh perl code_overlap.pl "$@" > overlap.txt perl bytes_saved.pl Which just outputs the number of bytes. Hope that helps ... please let my know whether that works for you. Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)! bytes_saved.pl Description: Perl program code_overlap.pl Description: Perl program
Re: RFC: Idea for code size reduction
On Fri, Mar 07, 2008 at 11:10:53AM +0100, Richard Guenther wrote: > On Fri, Mar 7, 2008 at 11:02 AM, Philipp Marek <[EMAIL PROTECTED]> wrote: > > I wrote some perl scripts to test this. I took a "alldefconfig" i686 > > kernel, let objdump disassemble it, and on "iret", "ret", "ljmp" or "jmp" > > with a 4 byte address I store the last few bytes. Another script goes > > through these block-ends, and estimates the number of bytes saved, if > > identical sequences get changed into a 5 byte opcode (jump with 32bit > > address). > > Sounds like what -frtl-abstract-sequences is trying to do. Not exactly. AFAIK -frtl-abstract-sequences works at a function level, only same sequences within one function are abstracted. The above is a whole program optimization instead, and affects only tail sequences. You need to be very careful with it, as if there are any jumps into the middle of the to be abstracted tail sequences, you can't abstract them or would need to adjust also the jumps into them (if possible, which not always is). Also the tail sequence shouldn't contain any PC relative references (say you can't merge this was movl (.+0xabcd)(%rip), %eax ret which is byte identical, yet would reference different variables), but even jmp argument is relative, not absolute. You can't do this kind of optimization in the linker, as that's too late, many relocations are already relocated and lost during assembly and you need to understand the instructions anyway. Doing it in GCC would be terribly costly, if that would mean expanding everything into RTL, running all RTL passes and instead of emitting them, remember the pre-final RTL sequence for each emitted function, then do an IPA pass over all the sequences. Perhaps doing that in assembler, combined with --combine so that assembler can see everything together... Jakub
RE: Idea for code size reduction
Hello Dave! > One achitectural problem here is that GCC doesn't emit bytes. It emits > ASCII text, in the form of assembly instructions, and it's > not always easy to predict how they'll look by the time they've been > through the assembler and then had relocs applied by the > linker. (Indeed, to know what particular bytes you'd end up with you'd > need to do everything the assembler and linker does, which > is why we have an assembler and linker - the stuff GCC emits isn't > directly executable...) I know that. So maybe my current way (compile -> find duplicates -> define duplicates -> reuse them in fresh compile) is the easiest way to do that. > Shouldn't this be done in the linker instead? Well, can the linker change the instruction sequences? Ie. put a JMP instead of other code? Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)!
RE: Idea for code size reduction
Philipp Marek wrote: > I'd like to (manually) define some byte blocks, eg. as functions with > an identifier. Then, if GCC would emit exactly these bytes, it > puts a JMP identifier there instead. One achitectural problem here is that GCC doesn't emit bytes. It emits ASCII text, in the form of assembly instructions, and it's not always easy to predict how they'll look by the time they've been through the assembler and then had relocs applied by the linker. (Indeed, to know what particular bytes you'd end up with you'd need to do everything the assembler and linker does, which is why we have an assembler and linker - the stuff GCC emits isn't directly executable...) Shouldn't this be done in the linker instead? cheers, DaveK -- Can't think of a witty .sigline today
Re: RFC: Idea for code size reduction
Hello Jakub! > You need to be very careful with it, as if there are any jumps > into the middle of the to be abstracted tail sequences, you can't > abstract them or would need to adjust also the jumps into them (if > possible, which not always is). When wouldn't that possible? My script currently splits on an instruction-level -- although I would see no problem that some branch jumps into a "half" opcode of another branch, if the byte sequence matches. As I use the disassembly to start from they *have* to converge later - else I wouldn't have the same end point! So I think it's just a matter of defining another symbol at that address, and use that to jump into. > Also the tail sequence shouldn't contain any PC relative > references (say you can't merge this was > movl (.+0xabcd)(%rip), %eax > ret > which is byte identical, yet would reference different variables), That's right ... I didn't think of that. The script could "forget" the current byte sequences if it encounters %rip relative adressing. Note: I only know a bit about i686 and amd64 - for other processors that would have to be different, of course. > but even jmp argument is relative, not absolute. That's why I take only jumps with 32bit arguments - these are absolute. > You can't do this kind of optimization in the linker, as that's too > late, many relocations are already relocated and lost during assembly > and you need to understand the instructions anyway. > Doing it in GCC would be terribly costly, if that would mean > expanding everything into RTL, running all RTL passes and instead of > emitting them, remember the pre-final RTL sequence for each emitted > function, then do an IPA pass over all the sequences. > Perhaps doing that in assembler, combined with --combine so that > assembler can see everything together... Yes ... I think doing a second compile pass might be the easiest way, and not much slower than other solutions. (We could always remember which object files could be optimized, and only recompile *those*. After all, it's just an additional optimization.) Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)!
Re: RFC: Idea for code size reduction
On Fri, Mar 7, 2008 at 12:46 PM, Jakub Jelinek <[EMAIL PROTECTED]> wrote: > On Fri, Mar 07, 2008 at 11:10:53AM +0100, Richard Guenther wrote: > > On Fri, Mar 7, 2008 at 11:02 AM, Philipp Marek <[EMAIL PROTECTED]> wrote: > > > > I wrote some perl scripts to test this. I took a "alldefconfig" i686 > > > kernel, let objdump disassemble it, and on "iret", "ret", "ljmp" or > "jmp" > > > with a 4 byte address I store the last few bytes. Another script goes > > > through these block-ends, and estimates the number of bytes saved, if > > > identical sequences get changed into a 5 byte opcode (jump with 32bit > > > address). > > > > > Sounds like what -frtl-abstract-sequences is trying to do. > > Not exactly. AFAIK -frtl-abstract-sequences works at a function level, only > same sequences within one function are abstracted. Right - "trying to do" - you'd need to move this to whole-program level with LTO (preferably on the tree level), but the basic idea of outlining same sequences is the same. Richard.
Re: RFC: Idea for code size reduction
On Fri, Mar 07, 2008 at 01:05:03PM +0100, Philipp Marek wrote: > When wouldn't that possible? My script currently splits on an > instruction-level -- although I would see no problem that some branch > jumps into a "half" opcode of another branch, if the byte sequence > matches. Consider: : 0: b8 a4 00 00 00 mov$0xa4,%eax 5: ba fc 04 00 00 mov$0x4fc,%edx a: f7 e2 mul%edx c: 05 d2 04 00 00 add$0x4d2,%eax 11: c3 ret ... 00020012 : 20012: 39 d2 cmp%edx,%edx 20014: 75 07 jne2001d 20016: ba fc 04 00 00 mov$0x4fc,%edx 2001b: f7 e2 mul%edx 2001d: 05 d2 04 00 00 add$0x4d2,%eax 20022: c3 ret If you merge the mov/mul/add/ret sequences by replacing the foo tail sequence with jmp bar+5, then the jne will branch to wrong place, or if you try to adjust it, it is too far to reach the target. > > but even jmp argument is relative, not absolute. > That's why I take only jumps with 32bit arguments - these are absolute. No, they are relative. : 0: e9 05 00 02 00 jmp2000a 5: e9 00 00 02 00 jmp2000a ... 0002000a : 2000a: 90 nop See how they are encoded. > Yes ... I think doing a second compile pass might be the easiest way, and > not much slower than other solutions. > (We could always remember which object files could be optimized, and > only recompile *those*. After all, it's just an additional > optimization.) BTW, have you tried to compile the whole kernel with --combine, or at least e.g. each kernel directory with --combine? I guess that will give you bigger savings than 30K. Also, stop defining inline to inline __attribute__((always_inline)), I think Ingo also added such patch recently and it saved 120K. Jakub
Re: RFC: Idea for code size reduction
Hello Jakub! >> When wouldn't that possible? My script currently splits on an >> instruction-level -- although I would see no problem that some branch >> jumps into a "half" opcode of another branch, if the byte sequence >> matches. > > Consider: > : >0: b8 a4 00 00 00 mov$0xa4,%eax >5: ba fc 04 00 00 mov$0x4fc,%edx >a: f7 e2 mul%edx >c: 05 d2 04 00 00 add$0x4d2,%eax > 11: c3 ret > ... > > 00020012 : >20012: 39 d2 cmp%edx,%edx >20014: 75 07 jne2001d >20016: ba fc 04 00 00 mov$0x4fc,%edx >2001b: f7 e2 mul%edx >2001d: 05 d2 04 00 00 add$0x4d2,%eax >20022: c3 ret That's not an example of jumping into the *middle* of an instruction. I'd think about something like (please ignore the wrong addresses, just copy/paste): 5: ba fc 04 00 00 mov$0x4fc,%edx ---> a: f7 e2 mul%edx c: 05 d2 04 00 00 add$0x4d2,%eax 11: c3 ret ... 20016: ba 00 ba f7 e2 mov$0xe2f7ba00,%edx 2001b: f7 e2 mul%edx 2001d: 05 d2 04 00 00 add$0x4d2,%eax 20022: c3 ret Now we could place a jump at 0x4, which goes to 0x20018 - and should work, shouldn't it? > If you merge the mov/mul/add/ret sequences by replacing the foo tail > sequence with jmp bar+5, then the jne will branch to wrong place, or > if you try to adjust it, it is too far to reach the target. Yes. But see below. >> > but even jmp argument is relative, not absolute. >> That's why I take only jumps with 32bit arguments - these are absolute. > > No, they are relative. > > : >0: e9 05 00 02 00 jmp2000a >5: e9 00 00 02 00 jmp2000a > ... > > 0002000a : >2000a: 90 nop > > See how they are encoded. Yes, ok. But how does the compiler encode jumps? Via symbols, and the correct destination address gets put there by the linker. If there are (sizeof(void*)) operand bytes, there's enough space for *any* jump. (Is there some way for the linker to compress small jumps later?) > BTW, have you tried to compile the whole kernel with --combine, or at > least > e.g. each kernel directory with --combine? I guess that will give you > bigger savings than 30K. Also, stop defining inline to inline > __attribute__((always_inline)), I think Ingo also added such patch > recently > and it saved 120K. No ... but these are independent changes. I'm currently compiling with --combine. Regards, Phil -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)!
Re: RFC: Idea for code size reduction
BTW - It gets much better: $ ls -la /usr/lib/libgcj.so.90.0.0 -rw-r--r-- 1 root root 32844984 3. Feb 16:03 /usr/lib/libgcj.so.90.0.0 $ ./run /usr/lib/libgcj.so.90.0.0 Approx. 470045 bytes saved. That's 1.4% :-) If my script isn't buggy, that is -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)!
Re: Linux doesn't follow x86/x86-64 ABI wrt direction flag
Hi, On Thu, 6 Mar 2008, Andi Kleen wrote: > To be realistic it is very unlikely anybody will measure a difference > from a few more or a few less clds in a program. Only an assumption, and in fact wrong. See upthread for a benchmark. IIRC Uros also made measurements to justify the removal of cld (on P4 I think), where it helps tremendously on small memcpy loops. Ciao, Michael.
Re: Idea for code size reduction
"Philipp Marek" <[EMAIL PROTECTED]> writes: >> Shouldn't this be done in the linker instead? > Well, can the linker change the instruction sequences? Ie. put a JMP > instead of other code? Sure. The linker can do whatever it likes. The usual problem is that by the time the linker sees the code, it no longer knows about PC relative references within the same section. So if you have call foo ... sequence to remove ... foo: and the call is PC-relative, then when the linker removes the sequence of instructions it will not know that it needs to adjust the call to foo. What you are describing is a type of linker relaxation, and the same issues arise there. The usual solution is to force the assembler to emit all PC-relative relocations, so that the linker knows about them and is able to adjust them. Linker relaxation is used routinely in special sections, such as the .eh_frame section used to hold stack unwind information for throwing exceptions. It is also used for code sequences on some processors, but normally not on the i386/x86_64. Ian
Re: Idea for code size reduction
On Friday 07 March 2008 Ian Lance Taylor wrote: > "Philipp Marek" <[EMAIL PROTECTED]> writes: > >> Shouldn't this be done in the linker instead? > > > > Well, can the linker change the instruction sequences? Ie. put a JMP > > instead of other code? > > Sure. The linker can do whatever it likes. The usual problem is that > by the time the linker sees the code, it no longer knows about PC > relative references within the same section. So if you have > > call foo > ... > sequence to remove > ... > foo: > > and the call is PC-relative, then when the linker removes the sequence > of instructions it will not know that it needs to adjust the call to > foo. Right. > What you are describing is a type of linker relaxation, and the same > issues arise there. The usual solution is to force the assembler to > emit all PC-relative relocations, so that the linker knows about them > and is able to adjust them. But what we'd need above is to have the compiler make a reference to [removed_sequence + offset] instead, and that could be done by the linker again. So when the compiler removes a piece of code by a "jump ", it can use offsets in there as usual. > Linker relaxation is used routinely in special sections, such as the > .eh_frame section used to hold stack unwind information for throwing > exceptions. It is also used for code sequences on some processors, > but normally not on the i386/x86_64. Thank you very much for this information! Another idea: if we find out that such sequences are *very* common (eg. by comparing many different binaries and libraries), libc (or a libcommon or something like that) could have a set of these "abbreviations" - eg. indexed by symbol, which is defined as MD5_hex(removed section). -- Versioning your /etc, /home or even your whole installation? Try fsvs (fsvs.tigris.org)!
Re: [RFC] GCC caret diagnostics
> "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes: Manuel> Here is a patch that give us caret diagnostics in C/C++. Nice. Manuel> The third approach would be to store an offset and when Manuel> generating diagnostics, reopen the file, fseek to the offset Manuel> and print that line. I tend to favor this, provided that the performance is not too awful. But maybe this is painful due to iconv translation? Ian suggested that we delete this information after the FE is finished. This makes sense, I think, from a memory-saving perspective. But, that means we will get different kinds of error output depending on when a diagnostic is emitted, which I think is pretty unfriendly -- it exposes implementation details of gcc to the user. So, the reason I favor trying the reopen-and-seek approach is that it would let us keep this information around and be consistent in what we print. What do you think of that? Manuel> It would be nice to have a way to point directly to the Manuel> beginning of each line: multiple pointers per line_map? Anything is fine here as long as the total cost of the line map remains below the threshold of fully expanded locations. IMO. Manuel> Well, comments, ideas, code, questions, help are all welcome. How about -fshow-caret instead of -fdiagnostics-show-caret? (By analogy with -fshow-column.) With this implementation I think cpp will not emit caret diagnostics. It ought to as well, IMO -- consistency is important here, I think. Maybe now it is time to switch cpp to use gcc's diagnostic machinery... I think all the prerequisites to this have been met, though I am not sure. Tom
Re: [RFC] GCC caret diagnostics
On Fri, Mar 7, 2008 at 4:54 PM, Tom Tromey <[EMAIL PROTECTED]> wrote: > > "Manuel" == Manuel López-Ibáñez <[EMAIL PROTECTED]> writes: > > Manuel> Here is a patch that give us caret diagnostics in C/C++. > > Nice. > > Manuel> The third approach would be to store an offset and when > Manuel> generating diagnostics, reopen the file, fseek to the offset > Manuel> and print that line. > > I tend to favor this, provided that the performance is not too awful. > But maybe this is painful due to iconv translation? > > Ian suggested that we delete this information after the FE is > finished. This makes sense, I think, from a memory-saving > perspective. But, that means we will get different kinds of error > output depending on when a diagnostic is emitted, which I think is > pretty unfriendly -- it exposes implementation details of gcc to the > user. > > So, the reason I favor trying the reopen-and-seek approach is that it > would let us keep this information around and be consistent in what we > print. > > What do you think of that? I think we support input from stdin, at least qemu used to work that way ;) If you want to improve the memory situation maybe storing the input in compressed format in memory is ok. (Or compressing the cpp token stream if we want to support diagnostics on the preprocessed output, which I'd love to have in some cases) Richard.
Need link ln -s ../lib64/libgomp.spec libgomp.spec in $prefix/lib on x86_64-unknown-linux-gnu
Otherwise, the libgomp.spec, which only resides in lib64, won't be found at link time. So I applied the link by hand - however, it occurs to me a computer is the perfect tool to do this for me. Hence, why doesn't the make install machinery do this ? Kind regards, -- Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.indiv.nluug.nl/~toon/ Progress of GNU Fortran: http://gcc.gnu.org/ml/gcc/2008-01/msg9.html
gcc-4.4-20080307 is now available
Snapshot gcc-4.4-20080307 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20080307/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 133014 You'll find: gcc-4.4-20080307.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20080307.tar.bz2 C front end and core compiler gcc-ada-4.4-20080307.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20080307.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20080307.tar.bz2 C++ front end and runtime gcc-java-4.4-20080307.tar.bz2 Java front end and runtime gcc-objc-4.4-20080307.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20080307.tar.bz2The GCC testsuite Diffs from 4.4-20080229 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 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: [RFC] GCC caret diagnostics
Tom Tromey <[EMAIL PROTECTED]> writes: > Ian suggested that we delete this information after the FE is > finished. This makes sense, I think, from a memory-saving > perspective. But, that means we will get different kinds of error > output depending on when a diagnostic is emitted, which I think is > pretty unfriendly -- it exposes implementation details of gcc to the > user. I think that is mostly OK in practice because most diagnostics are issued by the front end. But I admit that some come from the middle-end, so there would be an inconsistency. Another approach would be to only use the carets for parse errors, which is where they are the most helpful. For a middle-end error like "assuming signed overflow does not occur when simplifying multiplication" a caret pointer might be more misleading than otherwise, as one thing we know for sure is that it would not point at a multiplication operator. What do other compilers do? Reopening the file doesn't work for standard input, which I admit is an unusual case. Ian
Re: [RFC] GCC caret diagnostics
On Mar 7, 2008, at 6:06 PM, Ian Lance Taylor wrote: Tom Tromey <[EMAIL PROTECTED]> writes: Ian suggested that we delete this information after the FE is finished. This makes sense, I think, from a memory-saving perspective. But, that means we will get different kinds of error output depending on when a diagnostic is emitted, which I think is pretty unfriendly -- it exposes implementation details of gcc to the user. I think that is mostly OK in practice because most diagnostics are issued by the front end. But I admit that some come from the middle-end, so there would be an inconsistency. Another approach would be to only use the carets for parse errors, which is where they are the most helpful. For a middle-end error like "assuming signed overflow does not occur when simplifying multiplication" a caret pointer might be more misleading than otherwise, as one thing we know for sure is that it would not point at a multiplication operator. An important class of middle-end warnings is use of undefined values and other dataflow warnings in GCC. What do other compilers do? Reopening the file doesn't work for standard input, which I admit is an unusual case. clang points into the original input buffer that was lexed from. This requires keeping the original files mapped into the address space of the compiler. However, clang only produces diagnostics from the front- end, not from the middle-end. -Chris
