Re: Strange behavior of libstdc++ regression test
"Terry Guo" writes: > make[1]: *** [check-recursive] Error 1 > make[1]: Target `check' not remade because of errors. > make[1]: Leaving directory > `/home/build/gcc-4-7-daily-test/build-linux/gcc-final/arm-none-eabi/libstdc+ > +-v3' > make: *** [check-target-libstdc++-v3] Error 2 > make: Target `check-target' not remade because of errors. You had unexpected failures/successes. Look at the first error, not the last one. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
RE: Strange behavior of libstdc++ regression test
> > "Terry Guo" writes: > > > make[1]: *** [check-recursive] Error 1 > > make[1]: Target `check' not remade because of errors. > > make[1]: Leaving directory > > `/home/build/gcc-4-7-daily-test/build-linux/gcc-final/arm-none- > eabi/libstdc+ > > +-v3' > > make: *** [check-target-libstdc++-v3] Error 2 > > make: Target `check-target' not remade because of errors. > > You had unexpected failures/successes. Look at the first error, not > the > last one. > Ah, you are right. I just thought the "make -k" should keep going and omit all the errors. Now I think I should use "make -k -i" to do it. Thanks for the help. BR, Terry
Re: Why does lower-subreg mark copied pseudos as "decomposable"?
Richard Sandiford writes:
>> In fact, the only examples of a pseudo-pseudo copy that won't be
>> eliminated by fwprop et al would be to do with loops and conditionals,
>> and I don't understand why they should be special.
>
> Not just those, because loads, stores, calls, volatiles, etc.,
> can't be moved freely. E.g. code like:
>
> uint64_t foo (uint64_t *x, uint64_t z)
> {
> uint64_t y = *x;
> *x = z;
> return y;
> }
>
> benefits too, because y must be a pseudo.
Er, please ignore this bit :-) There obviously doesn't need to be
a pseudo copy here. The later stuff still applies though.
Richard
Re: Strange behavior of libstdc++ regression test
"Terry Guo" writes: > Ah, you are right. I just thought the "make -k" should keep going It does. > and omit all the errors. It reports _all_ (independent) errors, not just the first one. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: dwz-0.1 - DWARF compression tool
On Wed, Apr 18, 2012 at 09:36:57AM +0200, Jakub Jelinek wrote:
> I'd like to announce dwz-0.1, a DWARF compression tool I've spent this
> April hacking on. It is currently (see below) written as standalone tool,
> with minimal dependencies (though time hasn't been spent on portability
> yet, so assumes glibc host), in particular just a small amount of code
> in it depends on libelf (tested with elfutils only), in C.
> The tool parses DWARF2+ debug info, finds matching DIEs between different
> CUs that might be moved to new CUs with DW_TAG_partial_unit, estimates
> whether it is worthwhile, if it is, moves it there and adds
> DW_TAG_imported_unit DIEs (a tree of them) to make sure every CU includes
> all the needed DIEs. DW_TAG_imported_unit DIEs created by this tool
> will only be direct children of DW_TAG_{compile,partial}_unit DIEs, if
> something from a named namespace/module can be shared, the DW_TAG_namespace
> or DW_TAG_module DIE with the same DW_AT_name is added in the partial unit
> as well.
FYI, Frank Eigler has been so kind to create git repo for this, so the
0.1 release plus all bugfixes and improvements since then are in the
http://sourceware.org/git/?p=dwz.git;a=summary
repository.
Jakub
Announce - Thread safety annotations no longer supported in GCC
We have decided to terminate the thread safety annotation project in GCC. The current implementation is in the branch google/main for those interested in using it. We will not be pursuing a merge into trunk. Instead, we have started implementing the same functionality in Clang. I've updated the wiki page and moved the branch out of the active development branches in svn.html. Diego.
Re: Announce - Thread safety annotations no longer supported in GCC
On Thu, Apr 19, 2012 at 7:15 AM, Diego Novillo wrote: > > We have decided to terminate the thread safety annotation project in > GCC. > > The current implementation is in the branch google/main for those > interested in using it. We will not be pursuing a merge into trunk. > Instead, we have started implementing the same functionality in Clang. What went into making this decision? I know lot of folks will almost never go over to using clang since it means supporting one extra front-end. I am thinking of the embedded folks here where they cannot afford supporting something as new as clang for their customers. Thanks, Andrew Pinski > > I've updated the wiki page and moved the branch out of the active > development branches in svn.html. > > > Diego.
Mpfr/Mpc developer meeting 2012 - 2nd try
Following the success of the 2011 meeting, we plan to hold another joint Mpfr/Mpc developer meeting. Mpfr and Mpc are libraries for real and complex floating point arithmetic at arbitrary precision with correct rounding of the result. They are prerequisites for building gcc. Date 25 June 2012, 14:00 to 27 June 2012, 12:00 Venue Institut de Mathématiques de Bordeaux, University of Bordeaux, France The goal of this meeting is to discuss future developments of the Gnu Mpfr and Gnu Mpc libraries. It is open to everyone interested in contributing to Gnu Mpfr and/or Gnu Mpc, be it by writing new code or by contributing new ideas. There is no registration fee, but please inform andreas.e...@inria.fr if you intend to participate, and indicate whether you agree that your name be mentioned on our website. If you are unable to come, but wish to contribute ideas or suggestions for topics we should treat, please feel free to voice them on our mailing list. Some travel support will be available upon request. More details to come at http://www.multiprecision.org/index.php?prog=mpc&page=workshop2012 Andreas
Re: Announce - Thread safety annotations no longer supported in GCC
The gcc version has been difficult to support and maintain, due mainly to the fact that the GIMPLE intermediate language was never designed for static analysis. The abstract syntax tree provided by Clang is an easier data structure to work with for front-end analyses of this kind. Moreover, the gcc implementation of annotalysis has some issues that make an eventual merge into trunk somewhat unlikely, and annotalysis is of little use to people outside of google as long as it stays in google/main. The clang implementation has been in trunk from the beginning. Hope that explains it a bit better, -DeLesley On Thu, Apr 19, 2012 at 8:15 AM, Andrew Pinski wrote: > On Thu, Apr 19, 2012 at 7:15 AM, Diego Novillo wrote: >> >> We have decided to terminate the thread safety annotation project in >> GCC. >> >> The current implementation is in the branch google/main for those >> interested in using it. We will not be pursuing a merge into trunk. >> Instead, we have started implementing the same functionality in Clang. > > What went into making this decision? I know lot of folks will almost > never go over to using clang since it means supporting one extra > front-end. I am thinking of the embedded folks here where they cannot > afford supporting something as new as clang for their customers. > > Thanks, > Andrew Pinski > >> >> I've updated the wiki page and moved the branch out of the active >> development branches in svn.html. >> >> >> Diego. -- DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315
Re: Announce - Thread safety annotations no longer supported in GCC
On Thu, Apr 19, 2012 at 8:44 AM, Delesley Hutchins wrote: > The gcc version has been difficult to support and maintain, due mainly > to the fact that the GIMPLE intermediate language was never designed > for static analysis. The abstract syntax tree provided by Clang is an > easier data structure to work with for front-end analyses of this > kind. Moreover, the gcc implementation of annotalysis has some issues > that make an eventual merge into trunk somewhat unlikely, and > annotalysis is of little use to people outside of google as long as it > stays in google/main. The clang implementation has been in trunk from > the beginning. > > Hope that explains it a bit better, No, that it does not help at all. This seems like a high level issue of the problem rather than describing the reasons why GIMPLE will never work correctly for your usage. Maybe we can expand it for your usage but we need to better understand what it is lacking. Thanks, Andrew Pinski > > -DeLesley > > On Thu, Apr 19, 2012 at 8:15 AM, Andrew Pinski wrote: >> On Thu, Apr 19, 2012 at 7:15 AM, Diego Novillo wrote: >>> >>> We have decided to terminate the thread safety annotation project in >>> GCC. >>> >>> The current implementation is in the branch google/main for those >>> interested in using it. We will not be pursuing a merge into trunk. >>> Instead, we have started implementing the same functionality in Clang. >> >> What went into making this decision? I know lot of folks will almost >> never go over to using clang since it means supporting one extra >> front-end. I am thinking of the embedded folks here where they cannot >> afford supporting something as new as clang for their customers. >> >> Thanks, >> Andrew Pinski >> >>> >>> I've updated the wiki page and moved the branch out of the active >>> development branches in svn.html. >>> >>> >>> Diego. > > > > -- > DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315
Re: Why does lower-subreg mark copied pseudos as "decomposable"?
On 18/04/12 21:47, Richard Sandiford wrote: I don't think the idea is that these cases are special in themselves. What we're looking for are pseudos that _may_ be decomposed into separate registers. If one of the pseudos in the move is only used in decomposable contexts (including nonvolatile loads and stores, as well as copies to and from hard registers, etc.), then we may be able to completely replace the original pseudo with two smaller ones. E.g.: (set (reg:DI X) (mem:DI ...)) ... (set (reg:DI Y) (reg:DI X)) In this case, X can be completely replaced by two SImode registers. What isn't clear to me is why we don't seem to do the same for: (set (reg:DI X) (mem:DI ...)) (set (mem:DI ...) (reg:DI X)) My reading would be: if the backend wanted to lower these then it would have expanded the load differently in the first place. The fact that the machine description says "reg:DI", rather than "subreg:SI (reg:DI" shows that the 64-bit load is the more-optimal method (at least in the view of the author). (I have the same complaint about the lower-subreg zero-extend special-handling: if the backend wanted it lowered that way, why didn't it code it that way?) Look at pr43137; the old code was sub-optimal and was replaced with a pre-lowered version. (Admittedly, it was the pseudo-to-pseudo bug that highlighted the problem.) Now, I want to indicate the opposite, when NEON is available: that preferred form for and extend is the non-lowered form, but this mysterious copy-rule has defeated me. Perhaps we do and I'm just misreading the code. Or perhaps it's just too hard to get the costs right. Splitting that would be moving even further from what you want though :-) No, I don't think you misunderstood it: in the example, X is used as "reg:DI" and that should prohibit lowering (even if there's a subreg use somewhere else). Here's another example that worries me: (set (reg:DI X) (mem:DI ...)) ... (set (reg:DI Y) (reg:DI X)) ... (set (...) (...:SI (subreg:SI (reg:DI Y) 0))) (set (...) (...:SI (subreg:SI (reg:DI Y) 4))) Without the copy, there would be no lowering in this example. With the copy (and let's remember that they're not added deliberately; they're just artefacts of the expand process) the Y register will be lowered, but the X not. I worries me that these "optimizations" are relying on "undocumented"/"undefined"/unsomethinged behaviour (at best). In this example it probably won't make any difference to the register allocation, but in pr43137 is was this pattern and the combination of hard-regs and sign_extend being known to only modify one of the subregs caused the trouble. The result of this extra feature is that if I copy the output of a DImode insn *directly* to a DImode hard reg (say a return value) then there's no decomposition, but if the expand pass happens to have put an intermediate pseudo register (as it does do) then this extra rule decomposes it most unhelpfully (ok, there's only actually a problem if the compiler can reason that one subreg or the other is unchanged, as is the case with sign_extend). But remember that this pass is not designed for targets like NEON that have lots of native double-word operations. It's designed for targets that don't. I think you said earlier that your testcase was handled correctly for non-NEON, which is the point: decomposing in that case _may_ be a benefit (if we end up being able to replace all uses of a doubleword pseudo with uses of 2 word pseudos) and should be no worse otherwise. True, but there ought to be a way to achieve the goal that doesn't penalize targets that have a few doubleword operations? I'm coming to the conclusion that this (and the zero_extend/shift special-handling) is some attempt to paper over the short-comings of some backends (ok, probably all, somewhere) that don't expand to say what they mean, but instead rely on split, or have insns that output multiple instructions. Lowering a register that is only accessed via (subreg:SI (reg:DI ..)) is, of course, a useful thing to do (it's what the machine description is *asking* for), and we should do that after both expand and split, but these extra "smarts" are deeply suspicious. So, after having thought all this through again, unless somebody can show why not, I propose that we remove this mis-feature entirely, or at least disable it in the first pass. I still prefer the idea of disabling in the first pass. It'll need to be tested on something like non-NEON ARM to see whether it makes things worse or better there. (I think size testing would be fine.) I'll have a go, and see what happens. Andrew
Re: Announce - Thread safety annotations no longer supported in GCC
I can give you detailed technical reasons why GIMPLE was not working for us if you like, but I'm not sure it would be all that constructive. We have already made the decision to switch to clang for annotalysis users within google, for reasons that are only partly technical. The only reason to support the gcc version would be if there was sufficient interest in annotalysis outside of google to warrant the effort of moving it to trunk. Given that the annotalysis branch stopped tracking trunk almost a year ago, and has been disabled in even in google/main for the past 6 months, I would be surprised to find any such users. Since the estimated number of users is currently zero, there seems little point in maintaining the software. Moreover, although I appreciate your offer to try and expand GIMPLE, I don't think it makes a lot of sense. GIMPLE works just fine for its intended use case, which is an intermediate language for compiler optimization. Changing GIMPLE would be a major effort, and it would only be warranted if there were enough users to make it worthwhile. -DeLesley On Thu, Apr 19, 2012 at 9:25 AM, Andrew Pinski wrote: > On Thu, Apr 19, 2012 at 8:44 AM, Delesley Hutchins > wrote: >> The gcc version has been difficult to support and maintain, due mainly >> to the fact that the GIMPLE intermediate language was never designed >> for static analysis. The abstract syntax tree provided by Clang is an >> easier data structure to work with for front-end analyses of this >> kind. Moreover, the gcc implementation of annotalysis has some issues >> that make an eventual merge into trunk somewhat unlikely, and >> annotalysis is of little use to people outside of google as long as it >> stays in google/main. The clang implementation has been in trunk from >> the beginning. >> >> Hope that explains it a bit better, > > No, that it does not help at all. This seems like a high level issue > of the problem rather than describing the reasons why GIMPLE will > never work correctly for your usage. Maybe we can expand it for your > usage but we need to better understand what it is lacking. > > Thanks, > Andrew Pinski > > >> >> -DeLesley >> >> On Thu, Apr 19, 2012 at 8:15 AM, Andrew Pinski wrote: >>> On Thu, Apr 19, 2012 at 7:15 AM, Diego Novillo wrote: We have decided to terminate the thread safety annotation project in GCC. The current implementation is in the branch google/main for those interested in using it. We will not be pursuing a merge into trunk. Instead, we have started implementing the same functionality in Clang. >>> >>> What went into making this decision? I know lot of folks will almost >>> never go over to using clang since it means supporting one extra >>> front-end. I am thinking of the embedded folks here where they cannot >>> afford supporting something as new as clang for their customers. >>> >>> Thanks, >>> Andrew Pinski >>> I've updated the wiki page and moved the branch out of the active development branches in svn.html. Diego. >> >> >> >> -- >> DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315 -- DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315
Re: Announce - Thread safety annotations no longer supported in GCC
On Thu, Apr 19, 2012 at 10:30 AM, Delesley Hutchins wrote: > I can give you detailed technical reasons why GIMPLE was not working > for us if you like, but I'm not sure it would be all that > constructive. We have already made the decision to switch to clang > for annotalysis users within google, for reasons that are only partly > technical. The only reason to support the gcc version would be if > there was sufficient interest in annotalysis outside of google to > warrant the effort of moving it to trunk. Given that the annotalysis > branch stopped tracking trunk almost a year ago, and has been disabled > in even in google/main for the past 6 months, I would be surprised to > find any such users. Since the estimated number of users is currently > zero, there seems little point in maintaining the software. > > Moreover, although I appreciate your offer to try and expand GIMPLE, I > don't think it makes a lot of sense. GIMPLE works just fine for its > intended use case, which is an intermediate language for compiler > optimization. Changing GIMPLE would be a major effort, and it would > only be warranted if there were enough users to make it worthwhile. How do you know it is a major effort? Has any issues related to changing Tuple/front-ends AST been raised to the mailing list and asked for help on how to implement these changes? This is why this decision is such a disappointment here because I have not seen one message about what needs to change to help support the future development of static analyzer in GCC. Yes people have said it can't be done fully currently because the AST but that does not mean asking the right question and answering how can we change GCC to allow for a better job of doing this kind of development. Being quiet about it and then saying it can't be done without any reasoning behind why moving away from GCC is seems a bit out of place. Thanks, Andrew Pinski > > -DeLesley > > On Thu, Apr 19, 2012 at 9:25 AM, Andrew Pinski wrote: >> On Thu, Apr 19, 2012 at 8:44 AM, Delesley Hutchins >> wrote: >>> The gcc version has been difficult to support and maintain, due mainly >>> to the fact that the GIMPLE intermediate language was never designed >>> for static analysis. The abstract syntax tree provided by Clang is an >>> easier data structure to work with for front-end analyses of this >>> kind. Moreover, the gcc implementation of annotalysis has some issues >>> that make an eventual merge into trunk somewhat unlikely, and >>> annotalysis is of little use to people outside of google as long as it >>> stays in google/main. The clang implementation has been in trunk from >>> the beginning. >>> >>> Hope that explains it a bit better, >> >> No, that it does not help at all. This seems like a high level issue >> of the problem rather than describing the reasons why GIMPLE will >> never work correctly for your usage. Maybe we can expand it for your >> usage but we need to better understand what it is lacking. >> >> Thanks, >> Andrew Pinski >> >> >>> >>> -DeLesley >>> >>> On Thu, Apr 19, 2012 at 8:15 AM, Andrew Pinski wrote: On Thu, Apr 19, 2012 at 7:15 AM, Diego Novillo wrote: > > We have decided to terminate the thread safety annotation project in > GCC. > > The current implementation is in the branch google/main for those > interested in using it. We will not be pursuing a merge into trunk. > Instead, we have started implementing the same functionality in Clang. What went into making this decision? I know lot of folks will almost never go over to using clang since it means supporting one extra front-end. I am thinking of the embedded folks here where they cannot afford supporting something as new as clang for their customers. Thanks, Andrew Pinski > > I've updated the wiki page and moved the branch out of the active > development branches in svn.html. > > > Diego. >>> >>> >>> >>> -- >>> DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315 > > > > -- > DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315
Re: Announce - Thread safety annotations no longer supported in GCC
On 4/19/12 4:14 PM, Andrew Pinski wrote: How do you know it is a major effort? Has any issues related to changing Tuple/front-ends AST been raised to the mailing list and asked for help on how to implement these changes? The kind of analysis that Annotalysis needs cannot be catered by GIMPLE, the same way that LLVM's bitcode could not cater to it. Both representations are geared towards code transformations, not source code analysis. It's not an implementation issue, but a design one. It simply does not make sense for GIMPLE or LLVM's bitcode to try to be a source code analysis framework. Annotalysis needs a high-fidelity representation of the original source code. Today, that high-fidelity representation is provided exclusively by Clang. Additionally, we are already supporting Clang as a front end to provide syntax and semantic analysis. Given that Clang provides a much more flexible framework for static analysis, the decision was a relatively simple one. This is not to say that Clang provides everything needed by Annotalysis. There is some need to use dataflow information which needs to be incorporated in Clang. However, a large fraction of the support required was already available in Clang. Diego.
Re: Announce - Thread safety annotations no longer supported in GCC
> How do you know it is a major effort? Changing the intermediate language is *always* a major effort, especially in a large, complex, and mature compiler. Moreover, it's not necessarily Gimple itself, it's the way the front-end lowers code from C++ to Gimple, it's the way in which optimizations are structured and scheduled, etc. In other words, the entire compiler architecture. The actual analysis we do is relatively simple, so re-implementing it in clang was by far the easier path. Moreover, although I can describe the problems I had doing static analysis in gcc, I can't point to any reasonable solutions. Gcc is good at what it does, and most of the things that were roadblocks for me are actually important to gcc's core mission -- which is to compile C++ programs into fast, high-quality machine code. It's not that we were deliberately keeping quiet, it's that these are not problems that can be easily fixed without breaking something far more important. Again, I would be happy to share some of our experiences with you if you are interested. But it's not going to change our decision. -DeLesley Has any issues related to > changing Tuple/front-ends AST been raised to the mailing list and > asked for help on how to implement these changes? > > This is why this decision is such a disappointment here because I have > not seen one message about what needs to change to help support the > future development of static analyzer in GCC. Yes people have said it > can't be done fully currently because the AST but that does not mean > asking the right question and answering how can we change GCC to allow > for a better job of doing this kind of development. > > Being quiet about it and then saying it can't be done without any > reasoning behind why moving away from GCC is seems a bit out of place. > > Thanks, > Andrew Pinski > >> >> -DeLesley >> >> On Thu, Apr 19, 2012 at 9:25 AM, Andrew Pinski wrote: >>> On Thu, Apr 19, 2012 at 8:44 AM, Delesley Hutchins >>> wrote: The gcc version has been difficult to support and maintain, due mainly to the fact that the GIMPLE intermediate language was never designed for static analysis. The abstract syntax tree provided by Clang is an easier data structure to work with for front-end analyses of this kind. Moreover, the gcc implementation of annotalysis has some issues that make an eventual merge into trunk somewhat unlikely, and annotalysis is of little use to people outside of google as long as it stays in google/main. The clang implementation has been in trunk from the beginning. Hope that explains it a bit better, >>> >>> No, that it does not help at all. This seems like a high level issue >>> of the problem rather than describing the reasons why GIMPLE will >>> never work correctly for your usage. Maybe we can expand it for your >>> usage but we need to better understand what it is lacking. >>> >>> Thanks, >>> Andrew Pinski >>> >>> -DeLesley On Thu, Apr 19, 2012 at 8:15 AM, Andrew Pinski wrote: > On Thu, Apr 19, 2012 at 7:15 AM, Diego Novillo > wrote: >> >> We have decided to terminate the thread safety annotation project in >> GCC. >> >> The current implementation is in the branch google/main for those >> interested in using it. We will not be pursuing a merge into trunk. >> Instead, we have started implementing the same functionality in Clang. > > What went into making this decision? I know lot of folks will almost > never go over to using clang since it means supporting one extra > front-end. I am thinking of the embedded folks here where they cannot > afford supporting something as new as clang for their customers. > > Thanks, > Andrew Pinski > >> >> I've updated the wiki page and moved the branch out of the active >> development branches in svn.html. >> >> >> Diego. -- DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315 >> >> >> >> -- >> DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315 -- DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315
Re: Announce - Thread safety annotations no longer supported in GCC
Diego is right. Clang maintains an accurate C++ AST, and then layers additional data structures, like the control flow graph, on top of that, so you don't get the same kind of lowering artifacts that have plagued the gcc implementation of annotalysis. That architecture makes Clang a much better platform for static analysis. However, I want to point out that Gimple is actually designed pretty well, especially considering the fact that it was never intended to be a source code analysis framework. Certain parts of our analysis were much easier to do in Gimple than in Clang, because we could leverage the work of previous transformations (e.g. lowering to SSA). However, those same transformations made some other parts of the analysis nearly impossible. There is no such thing as a perfect intermediate language that will satisfy everyone. -DeLesley considering that Gimple was never intended to be a source code analysis On Thu, Apr 19, 2012 at 1:20 PM, Diego Novillo wrote: > On 4/19/12 4:14 PM, Andrew Pinski wrote: > >> How do you know it is a major effort? Has any issues related to >> changing Tuple/front-ends AST been raised to the mailing list and >> asked for help on how to implement these changes? > > > The kind of analysis that Annotalysis needs cannot be catered by GIMPLE, the > same way that LLVM's bitcode could not cater to it. Both representations > are geared towards code transformations, not source code analysis. It's not > an implementation issue, but a design one. It simply does not make sense > for GIMPLE or LLVM's bitcode to try to be a source code analysis framework. > > Annotalysis needs a high-fidelity representation of the original source > code. Today, that high-fidelity representation is provided exclusively by > Clang. > > Additionally, we are already supporting Clang as a front end to provide > syntax and semantic analysis. Given that Clang provides a much more > flexible framework for static analysis, the decision was a relatively simple > one. > > This is not to say that Clang provides everything needed by Annotalysis. > There is some need to use dataflow information which needs to be > incorporated in Clang. However, a large fraction of the support required > was already available in Clang. > > > Diego. -- DeLesley Hutchins | Software Engineer | deles...@google.com | 505-206-0315
gcc-4.5-20120419 is now available
Snapshot gcc-4.5-20120419 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120419/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_5-branch revision 186600 You'll find: gcc-4.5-20120419.tar.bz2 Complete GCC MD5=cec6db886b56a1cf9938ac261c25b508 SHA1=6ce9dc543d8a08983294be5df29c095a2cc62ba5 Diffs from 4.5-20120412 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.5 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.
Dwarf location list base address entry
Hi, Under what circumstances does gcc emit a base address selection entry for a dwarf location list? I've looked at the code, and think the answer is "never", but perhaps I'm missing something, and I want to be sure. Thanks, Sterling
Re: Announce - Thread safety annotations no longer supported in GCC
Delesley Hutchins writes: > I can give you detailed technical reasons why GIMPLE was not working > for us if you like, but I'm not sure it would be all that > constructive. Why wouldn't it be constructive? Even if it's impractical for gcc to change to the degree needed to fit your particular project (especially in the short term), hearing the details of how gcc's representations fell short, and how others may have done things better, seems useful. Understanding is almost always a good thing, even if it can't always be put to immediate use... Things will evolve over time (yes, even gcc!), and such input plays a very useful part in guiding this evolution. Of course, such an explanation entails work on your part, so it's understandable if you're a bit skeptical as to whether it's worth the effort, but still, in the abstract... Thanks, -Miles -- People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- Donald Knuth
Re: Dwarf location list base address entry
On Thu, Apr 19, 2012 at 04:37:22PM -0700, Sterling Augustine wrote: > Hi, > > Under what circumstances does gcc emit a base address selection entry > for a dwarf location list? > > I've looked at the code, and think the answer is "never", but perhaps > I'm missing something, and I want to be sure. I think never is the right answer. If !have_multiple_function_sections DW_AT_low_pc of the CUs is non-zero and .debug_loc addresses are based on that, if have_multiple_function_sections, then DW_AT_low_pc is 0, the CU has DW_AT_ranges and .debug_loc list are absolute. Jakub
