Re: Designs for better debug info in GCC
On Dec 20, 2007, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > I'm addressing this in a bit more detail in a revised version of the > spec, that I intend to publish in the GCC wiki RSN. http://gcc.gnu.org/wiki/Var_Tracking_Assignments Here's a diff between the version I posted a couple of days ago and the one before I started adjusting formatting for better rendering in the wiki. Index: debug-var-loc.txt === RCS file: /home/aoliva/.cvs/txt/free-software/gcc/debug-var-loc.txt,v retrieving revision 1.2 retrieving revision 1.4 diff -u -p -d -u -p -r1.2 -r1.4 --- debug-var-loc.txt 18 Dec 2007 08:03:42 - 1.2 +++ debug-var-loc.txt 20 Dec 2007 07:32:56 - 1.4 @@ -34,54 +34,66 @@ optimization passes discard information emit correct and complete variable location lists. Coalescing, scalarizing, substituting, propagating, and many other -transformations prevent the late-running variable tracker from doing -an accurate job. By the time it runs, many variables no longer show -up in the retained annotations, although they're still conceptually -available. +transformations prevent the late-running variable tracker from doing a +complete or even accurate job. By the time it runs, many variables no +longer show up in the retained annotations, although they're still +conceptually available. -The variable tracker can't tell when a user variable overlaps with -another, and it can't tell when a variable is overwritten, if the -assignment is optimized away. These limitations are inherent to a -model based on inspecting actual code and trying to make inferences -from that. In order to be able to represent not only what remained in -the code, but also what was optimized, combined or otherwise -apparently-removed, additional information needs to be kept around. +The variable tracker can't handle sharing of a location by multiple +user variables, multiple active locations for the same variable, and +it can't tell when a variable is overwritten, if the assignment is +optimized away. This last limitations is inherent to a model based on +inspecting only actual code, and trying to make inferences from that. +In order to be able to represent not only what remained in the code, +but also what was optimized, combined or otherwise apparently-removed, +additional information needs to be kept around. This paper describes an approach to maintain this information. == Goals -* Ensure that, for every user variable for which we emit debug -information, the information is correct, i.e., if it says the value of -a variable at a certain instruction is at certain locations, or is a -known constant, then the variable must not be at any other location at -that point, and the locations or values must match reasonable -expectations based on source code inspection. +=== Correctness -* Defining "reasonable expectations" is tricky, for code reordering -typical of optimization can make room for numerous surprises. I don't -have a precise definition for this yet, but very clearly to me saying -that a variable holds a value that it couldn't possibly hold (e.g., -because it is only assigned that value in a code path that is -knowingly not taken) is a very clear indication that something is -amiss. The general guiding rule is, if we aren't sure the information -is correct (or we're sure it isn't), we shouldn't pretend that it is. +Ensure that, for every user variable for which we emit debug +information, the information is correct, i.e., if it provides +locations or value expressions for a variable in a certain range of +instructions, then, for all instructions in that range, the values +specified in the debug information must match the value the user +variable is bound to. -* Try to ensure that, if the value of a variable is a known constant +We say a variable is bound to a value when control flow crosses a +theoretical instruction placed at the point of the program in which +the user variable is, or should be have been, assigned that value. +This theoretical instruction is maintained roughly in place regardless +of optimizations that move, remove or otherwise optimize any code +generated to implement the source-level variable modification. More +details below, in the "scheduling and reordering" section. + + +=== Completeness + +Try to ensure that, if the value of a variable is a known constant at +a certain point in the program, this information is present in debug +information. + +Try to ensure that, if the value of a variable is available at any +location, or computable from values available at any other locations at a certain point in the program, this information is present in debug information. -* Try to ensure that, if the value of a variable is available or -computable at any location at a certain point in the program, this -information is present in debug information. -* Stop missing optimizations for the sake of preserving debug
Re: DEBUG_INSN that is not an insn
On Nov 5, 2007, "Steven Bosscher" <[EMAIL PROTECTED]> wrote: > Alex, maybe you could add a Wiki page about this project Done, at last! :-) http://gcc.gnu.org/wiki/Var_Tracking_Assignments -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
[www] get VTA branch entry to refer to design document
I'm checking this in... --- svn.html16 Nov 2007 11:11:59 -0200 1.69 +++ svn.html20 Dec 2007 06:02:39 -0200 @@ -156,7 +156,8 @@ list therefore provides only some repres - var-tracking-assignments-branch + http://gcc.gnu.org/wiki/Var_Tracking_Assignments";> + var-tracking-assignments-branch This branch aims at improving debug information by annotating assignments early in the compilation, and carrying over such annotations throughout optimization passes and representations. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: DEBUG_INSN that is not an insn
On Dec 20, 2007 9:00 AM, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Nov 5, 2007, "Steven Bosscher" <[EMAIL PROTECTED]> wrote: > > > Alex, maybe you could add a Wiki page about this project > > Done, at last! :-) > > http://gcc.gnu.org/wiki/Var_Tracking_Assignments Very nice. Thanks! Gr. Steven
Re: [RFC] WHOPR - A whole program optimizer framework for GCC
Hi, > > Jan, wrt the optimization plan coming out of the analysis phase, and the > various pieces of header/summary information, what do you think are the > major pieces we need? The cgraph used to be organized on a separate analysis, propagation and modify stages and the passes in implemented fall quite naturally into those pieces. Naturally it is limiting ellement, but not that bad and for some fancier passes I am sure we can arrange interesting things to be compiled at once or something like that. As discussed with Kenny in the past, there are ordering issues - ie one pass might invalidate info of other so there is a lot of interference that makes it more challenging to order the IPA pass queue than for all-in-memory IPA consisting of couple of completely independent passes. We will need better memory management for Gimple, have effective way to load function body into memory and actually cheaply release it when it is no longer needed that is quite challenging with GGC. I would hope that in longer term we can move tupleized gimple into pools. I also have sort of implementation plan TODO, I never got around putting it into wiki well, but I will try to check how much ours differ and update it. One area that is quite nasty WRT LTO is debug info. Honza > > In terms of branch mechanics, I'm initially tempted to do this > implementation on a branch separate from tuples and lto. This will > allow us to merge both lto and tuples separately, as the rest of the > optimizer is still a long ways away. What do folks think? > > > Thanks. Diego.
RE: A proposal to align GCC stack
Ye, Joey writes: >> This proposal values correctness at first place. So when compile can't >> make sure a function is only called from functions with the same or bigger >> preferred-stack-boundary, it will conservatively align the stack. One >> optimization is to set INCOMING = PREFERRED for local functions. Do you >> think it more acceptable? Ross Ridge wrote: > Not really. It might reduce the amount of unnecessary stack adjustment, > but the performance regression would remain. Changing the behaviour of > -fpreferred-stack-boundary doesn't make it more correct. It supposed > to change the ABI, it works as documented and, yes, if it's misused it > will cause problems. So will any number of GCC's ABI changing options. > Look at it another way. Lets say you were compiling x86_64 code with > -fpreferred-stack-boundary=3, an 8-byte PREFERRED alignment. As you > know, this is different from the standard x86_64 ABI which requires a > 16-byte alignment. Now with your proposal, GCC's behaviour of won't > change, because it's safe to assume that incoming stack is at least > 8-byte aligned. There should be no change in the code GCC generates, > with or without your proposal. However, the outgoing stack won't be > 16-byte aligned as the x86_64 ABI requires. In this case, what also > doesn't change is the fact that mixing code compiled with different > -fpreferred-stack-boundary values doesn't work. It's just as problematic > and unsafe as it was before. > So when you said "this proposal values correctness at first place", > that really isn't true. The proposal only addresses safety when > preferred alignment is raised from the standard ABI's alignment. You're > conservatively aligning the incoming stack, but not the outgoing stack. > You don't seem to be concerned about the problems that can arise when > the preferred is raised above the ABI's. Why? My guess is that because > "correctness" in this case would cause unacceptable regressions when > compiling the x86_64 Linux kernel. You are right. My proposal doesn't guarantee 100% correctness. In case of PREFERRED < ABI, we hope the author knows what will happen. > If you can understand why it would be unacceptable to change how > -fpreferred-stack-boundary behaves when compiling the Linux kernel, > then maybe you can understand why I don't find it acceptable for it to > change when compiling my code. I think I understand now. My updated version proposal sets INCOMING == PREFERRED, and -fpreferred-stack-boundary works the same as before. Thanks - Joey
RE: A proposal to align GCC stack
Andrew, My proposal is supposed not limited to i386/x86_64. Would do please spend some time review it and see if it can really solve problem in PowerPC? Your comments is welcome. Thanks - Joey -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Pinski Sent: 2007年12月19日 18:07 To: Ross Ridge Cc: gcc@gcc.gnu.org Subject: Re: A proposal to align GCC stack On 12/18/07, Ross Ridge <[EMAIL PROTECTED]> wrote: > Look at it another way. Lets say you were compiling x86_64 code with > -fpreferred-stack-boundary=3, an 8-byte PREFERRED alignment. Can we stop talking about x86/x86_64 specifics issues here? I have an use case for the PowerPC side of the Cell BE for variables greater than the normal stack boundary alignment of 16bytes. They need to be 128byte aligned for DMA transfering to the SPUs. I already proposed a patch [1] to fix this use case but I have not seen many replies yet. Thanks, Andrew Pinski [1] http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01167.html
Re: Strange error message from gdb
Alexandre Oliva writes: > On Dec 19, 2007, Andrew Haley <[EMAIL PROTECTED]> wrote: > > > Right, so read_type_die() doesn't know how to handle > > DW_TAG_interface_type. The weird thing is that I have never seen > > this error mesage before today, and AFAIAA gcj has been > > generating these interface types for a long while. > > For very small values of "long while" :-) > > This was added by: > > 2007-12-15 Alexandre Oliva <[EMAIL PROTECTED]> > > PR debug/7081 > * lang.c (java_classify_record): New. > (LANG_HOOKS_CLASSIFY_RECORD): Override. Yeah, I discovered this today. Because your patch hadn't been flagged as affecting Java and no Java maintainer approved it, I hadn't noticed. > Sorry, I didn't check whether GDB or other debug information > consumers supported this tag. I just ASSumed they did, given how > long they've been specified (today Dwarf 3 turns 2 :-) and how > noisy a failure would be should one run into such a tag without > supporting it. Well, that was a bad thing to do. > What now, revert until GDB et al are fixed, or leave it in, for > it's the right thing to do, and it serves as an additional > incentive for debug information consumers to support new Dwarf 3 > features? Please revert it, right now. It is impossible for anyone to debug gcj code at the moment. Once gdb support is in and widely distributed, then we can change gcc. Realistically, at least a year or two. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: Strange error message from gdb
On Dec 20, 2007, Andrew Haley <[EMAIL PROTECTED]> wrote: > Alexandre Oliva writes: >> PR debug/7081 >> * lang.c (java_classify_record): New. >> (LANG_HOOKS_CLASSIFY_RECORD): Override. > Yeah, I discovered this today. Because your patch hadn't been flagged > as affecting Java and no Java maintainer approved it, I hadn't > noticed. Sorry. >> What now, revert until GDB et al are fixed, or leave it in, for >> it's the right thing to do, and it serves as an additional >> incentive for debug information consumers to support new Dwarf 3 >> features? > Please revert it, right now. How about this patch, instead? It will restore debuggability to Java while at the same time maintaining the progress of using the long-supported-by-GDB DW_TAG_class_type in both C++ and Java. for gcc/java/ChangeLog from Alexandre Oliva <[EMAIL PROTECTED]> * lang.c (java_classify_record): Don't return RECORD_IS_INTERFACE for now. Index: gcc/java/lang.c === --- gcc/java/lang.c.orig 2007-12-15 18:18:56.0 -0200 +++ gcc/java/lang.c 2007-12-20 12:17:26.0 -0200 @@ -965,7 +965,9 @@ java_classify_record (tree type) if (! CLASS_P (type)) return RECORD_IS_STRUCT; - if (CLASS_INTERFACE (TYPE_NAME (type))) + /* ??? GDB does not support DW_TAG_interface_type as of December, + 2007. Re-enable this at a later time. */ + if (0 && CLASS_INTERFACE (TYPE_NAME (type))) return RECORD_IS_INTERFACE; return RECORD_IS_CLASS; -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Strange error message from gdb
Alexandre Oliva writes: > > How about this patch, instead? It will restore debuggability to Java > while at the same time maintaining the progress of using the > long-supported-by-GDB DW_TAG_class_type in both C++ and Java. > > for gcc/java/ChangeLog > from Alexandre Oliva <[EMAIL PROTECTED]> > > * lang.c (java_classify_record): Don't return > RECORD_IS_INTERFACE for now. > OK, thanks. Andrew. -- Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, UK Registered in England and Wales No. 3798903
Re: -Wparentheses lumps too much together
> My untested (and consequently firmly > held) hypothesis is that > > 1) most combinations of && and || don't need parentheses because > > (a && b) || (c && d) > > is by far more common than > > a && (b || c) && d > > and, moreover, broken code fails at runtime, and I dispute these claims. The former may be statistically more common, but I'd be surprised if the difference is that big. I can think of several fairly common situations where both would be used. Any time you've got any sort of nontrivial condition, I always find it better to include the explicit parentheses. Especially if a, b, c, and d are relatively complex relational expressions rather than simple variables. Code failing at runtime is way too late. By that time it's already been burned onto the device, and may be half way to the moon :-) Coverage testing never tests everything, and there's a fair chance that your complex condition will only break in an exceptional case which is, by definition, hard to predict, test and reproduce. > 2) Most programmers know (because they need to know) that && comes > before ||. I don't really believe that either. Most *good* programmers know operator precedence rules (or will at least look it up). However there are a lot of distinctly average programmers, and even the good programmers get confused or have bad days. As someone else mentioned precedence of arithmetic operators is taught in school from a fairly early age. Precedence of logical operators is (to me at least) much less well conditioned. I have no objection to splitting -Wparentheses into finer grained options. I just think they should remain enabled by -Wall. Paul
Re: Designs for better debug info in GCC
Alexandre Oliva <[EMAIL PROTECTED]> writes: > > How do i know i need to change this DEBUG expression. > > As reassoc looks for sets of variables it can freely mess with, it > should take note of variables that are used in debug annotations in > addition to the kind of single (?) non-debug uses it's interested in, > such that, when it modifies these variables, the annotations can be > compensated for. The question is how it finds them efficiently, without doing a scan of all instructions. Ian
Re: Designs for better debug info in GCC
Alexandre Oliva <[EMAIL PROTECTED]> writes: > On Dec 19, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > > For some things, sure, but we are just talking about the values in > > user visible variables stored in registers. There is no way we can > > make that information be correct between line notes. > > Err... I think there is, and one way to do it is with the design I've > proposed. Do you have anything to back up your implied assertion that > the design can't accomplish this? It is technically feasible but problematic for other reasons. i = i * m + ((i / j) + k) / n; On a two register machine like the x86 i will change several times during that calculation. You could issue debug notes making it correct at every machine instruction. But that would balloon the amount of debug info that we generate, for near-zero gain in real usability of the debugger. We already generate huge amounts of debug info--a typical C++ executable has more debug info than text and data combined. Increasing the amount of debug info significantly, for little gain, is contraindicated. Ian
Re: Designs for better debug info in GCC
Alexandre Oliva <[EMAIL PROTECTED]> writes: > > And it will avoid the problem of turning the testsuite into a > > regression testsuite rather than an accuracy testsuite. > > Sorry, I don't understand what you mean here. It's not a major point. When one adds a testsuite to working code, it is natural to write tests that expect to see what the code generates. The risk is that any change to the code causes the test to fail. This is the essence of a regression testsuite. For an example, see the linker testsuite in the binutils. Practically any change to the linker, correct or not, causes some tests to fail. An accuracy testsuite is one written independently of the code. It tests for the specific features that are desired, rather than testing for what the code currently does. Of course you can write an accuracy testsuite with working code. It's just much easier to write a regression testsuite, and it's easy to backslide into that. Ian
Re: -Wparentheses lumps too much together
"James K. Lowden" <[EMAIL PROTECTED]> writes: > > That particular warning happened to find dozens of real errors when I > > ran it over a large code base. It may be noise for you, but I know > > from personal experience that it is very useful. > > I would like to hear more about that, if you wouldn't mind. I'm really > quite surprised. Honestly. I'm not free to share actual details, and I don't have the real percentages anyhow. The warning triggered many false positives. But there were also a number of true positives, far more than I expected. A typical true positive looked more or less like if (a && b || c) often with a more complex condition. The indentation would express the intent, so it was easy to read the code and assume that it meant what it appeared to mean. But, of course, it didn't. Ian
RFC: New mangling for java resources.
In: http://gcc.gnu.org/ml/gcc-patches/2007-12/msg00979.html I propose a new mangling for embedded java resource files. Quoting from that message: > The mangling is as follows: > > The resource name is broken into path components by '/' characters. Each > component then has an '_' prepended and all '.' -> "$_" and '$' -> > "$$". The length of each component is then prepended to this and all > are concatenated together and preceeded by "_ZGr". "Gr" being an unused > special-name designator that could be thought of as representing > GNU-resource. For example: > > "java/util/iso4217.properties" mangles as: > "_ZGr5_java5_util20_iso4217$_properties" > > These symbols seem to pass through the demangler unaffected (GNU nm > 2.17.50.0.6-5.fc6 20061020 from FC6). > The java resource names differ from identifiers in languages like C,C++, and java in that there is no restriction on the position of digits in the name, really any character can appear anywhere in the name. One other thing I didn't mention in the original message, is that all characters that are not ISALNUM() are encoded with a __U_ sequence. I am looking from feedback from mangling gurus on this. Does this seem acceptable? Are there changes that you would recommend? I will prepare a demangler patch to accompany the java patch when the mangling scheme is deemed to be good. Thanks, David Daney
Re: Designs for better debug info in GCC
On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > Alexandre Oliva <[EMAIL PROTECTED]> writes: >> > How do i know i need to change this DEBUG expression. >> >> As reassoc looks for sets of variables it can freely mess with, it >> should take note of variables that are used in debug annotations in >> addition to the kind of single (?) non-debug uses it's interested in, >> such that, when it modifies these variables, the annotations can be >> compensated for. > The question is how it finds them efficiently, without doing a scan of > all instructions. It must keep track of variables it can mess with, so it might as well take notes about those it has to be more careful about. *Or* it can just introduce new temporaries, rename the uses and leave the original sets behind for "garbage collection" AKA dead code elimination, like I said. One is more implementation work, the other is potentially more wasteful in terms of memory use. None look particularly hard to me. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Designs for better debug info in GCC
On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > It is technically feasible but problematic for other reasons. > i = i * m + ((i / j) + k) / n; > On a two register machine like the x86 i will change several times > during that calculation. No. The register used to hold its initial value will. Keep in mind the separation between user variables and implementation locations. The user variable 'i' is only supposed to change when assignment operation is performed, (even if only in a theoretical level), when the final value of the RHS is available and stored in the location then assigned to hold the value of variable 'i'. Now, it is possible that the previous value of 'i' becomes unavailable while the expression is evaluated. Then, in order to represent this correctly, we just have to note that 'i' is no longer available as soon as all locations holding its original value are clobbered, and that it's available again when its new location holds the assigned value. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Designs for better debug info in GCC
Alexandre Oliva <[EMAIL PROTECTED]> writes: > On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > > It is technically feasible but problematic for other reasons. > > i = i * m + ((i / j) + k) / n; > > On a two register machine like the x86 i will change several times > > during that calculation. > > No. The register used to hold its initial value will. Keep in mind > the separation between user variables and implementation locations. > The user variable 'i' is only supposed to change when assignment > operation is performed, (even if only in a theoretical level), when > the final value of the RHS is available and stored in the location > then assigned to hold the value of variable 'i'. OK, fair enough. > Now, it is possible that the previous value of 'i' becomes unavailable > while the expression is evaluated. Then, in order to represent this > correctly, we just have to note that 'i' is no longer available as > soon as all locations holding its original value are clobbered, and > that it's available again when its new location holds the assigned > value. Right, which will significantly increase debugging size as you add two more notes around many lines. Ian
Re: Designs for better debug info in GCC
On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > Right, which will significantly increase debugging size as you add two > more notes around many lines. If that's the price to avoid debug information consumers getting incorrect values... Would you argue for a position such as: we can't go on expanding C++ templates for every conceivable type users instatiate them, this would make applications too large. let's try to figure out some way to reuse template expansions, even if some programs break, because it's more important to keep programs small than to enable them to behave correctly ? Why would code, essential for debug information consumers that are part of larger systems to work correctly, deserve any less attention to correctness? -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer [EMAIL PROTECTED], gcc.gnu.org} Free Software Evangelist [EMAIL PROTECTED], gnu.org}
Re: Designs for better debug info in GCC
Alexandre Oliva wrote: On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: Right, which will significantly increase debugging size as you add two more notes around many lines. If that's the price to avoid debug information consumers getting incorrect values... It may be an unacceptable price, the cost of an executable going from 50 megabytes to 80 megabytes can be the difference between handling the situation being practical and impractical.
compiling failed.
I tried to compile gcc4.2.x on Ubuntu, and there is an error message as the following. "make[3]: *** No rule to make target `../../../srcdir/fixincludes/../gcc/BASE-VER', needed by `mkheaders'. Stop. make[3]: Leaving directory `/home/paul/gcc/gcc-4.2.0/objdir/build-i686-pc-linux-gnu/fixincludes' make[2]: *** [all-build-fixincludes] Error 2 make[2]: Leaving directory `/home/paul/gcc/gcc-4.2.0/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/paul/gcc/gcc-4.2.0/objdir' make: *** [all] Error 2" (srcdir is the directory where the source code is. ) Thanks, Paul
Re: Designs for better debug info in GCC
Alexandre Oliva <[EMAIL PROTECTED]> writes: > On Dec 20, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote: > > > Right, which will significantly increase debugging size as you add two > > more notes around many lines. > > If that's the price to avoid debug information consumers getting > incorrect values... > > Would you argue for a position such as: > > we can't go on expanding C++ templates for every conceivable type > users instatiate them, this would make applications too large. > let's try to figure out some way to reuse template expansions, even > if some programs break, because it's more important to keep programs > small than to enable them to behave correctly > > ? No, that would be an obviously stupid position to take. I don't understand why you even say such a thing. > Why would code, essential for debug information consumers that are > part of larger systems to work correctly, deserve any less attention > to correctness? Because for most people the use of debug information is to use it in a debugger. And for those people, correct information at line positions suffices. Even the use you mentioned of doing backtraces only requires adding the notes around function calls, not around every line, unless you enable -fnon-call-exceptions. If you want to work on supporting this controlled by an option (-g4?), that is fine with me. Ian
Re: -Wparentheses lumps too much together
Ian Lance Taylor wrote: > A typical true positive looked more or less like > > if (a && > b || c) http://www.jetcafe.org/jim/c-style.html It's funny you should mention that. A warning about whitespace indentation that's inconsistent with the expressed logic *would* be helpful (and consistent with the if/else part of -Wparentheses). --jkl
Where to find the sources implementing GCC DFA pipeline hazard recognizer
Hi, Could someone give some hints of where to find the sources and algorithms of implementing the DFA pipeline hazard recognizer in GCC, which files and functions? Thanks advance. Qing
Re: Where to find the sources implementing GCC DFA pipeline hazard recognizer
Qing Wei <[EMAIL PROTECTED]> writes: > Could someone give some hints of where to find the sources and > algorithms of implementing > the DFA pipeline hazard recognizer in GCC, which files and functions? The files haifa-sched.c, sched-*.[ch] . Ian
