Re: New Bugzilla keyword for memory model bugs?
Hello Steven, Steven Bosscher wrote: Can someone please add a BZ keyword for the C11/C++11 memory model? I think it would be good to tag missed-optimizations or wrong-code bugs for the memory model with such a special keyword to have a BZ search find them quickly. Adding a keyword is simple, if you have a normal @gcc.gnu.org bugzilla account. Simply go to http://gcc.gnu.org/bugzilla/editkeywords.cgi However, I don't know what's the policy regarding such changes; although, adding a keyword should provoke little controversy. Tobias
Re: macro's and local variables
Hi, If you look at them more closely, you will see that the two different macro's give different answers to the same problem. If you like, I will retry at gcc-h...@gcc.gnu.org, although I suppose binut...@sourceware.org should be having a copy too. Thanks, Mischa. On 10/13/2012 02:03 AM, Jonathan Wakely wrote: On 12 October 2012 22:43, Mischa Baars wrote: Hi All, Who can take a first look at this in the morning? Hi, I looked, they seem to be some files. Nice. If you want people to look at them properly you should probably send them to the gcc-help list and explain why you want people to look at them.
Re: Normalizing the bitmap APIs.
Hi, On Sat, 13 Oct 2012, Lawrence Crowl wrote: > > > I have no problem in always returning a status change, if you are OK > > > with that. > > > > I am ok with that. > > There is some rationale for being concerned about performance, as the > checking routines need to read memory locations that they otherwise > would only write. If the destination is one of the sources there will be a read anyway. If it's not there will be a small penalty if it isn't in cache yet, though it will be soon because of the write. > I haven't done any performance measures, but I take as evidence that > someone thought there was enough of a performance difference to make it > worth the extra work of writing a second set of routines. Nope. It was valgrind that caused the introduction of the sbitmap _cg functions. If the destination was no input and wasn't initialized the computation of the changed flag (and it's comparison with zero) depended on uninitialized memory, sometimes flagged by valgrind also when the return value wasn't used. I think it should have been handled by valgrind suppressions, not by introducing another interface. Given this, and that the other bitmap interfaces mostly return a changed flag, we should opt for the simpler API, always returning it. That includes the few remaining bitmap.h functions that aren't already doing so. Ciao, Michael.
bounds checking in STL containers
Hi All, It appears that operator[] in STL containers (e.g. vector, deque) does not check bounds any more (g++ 4.7.2). Two-three generations ago g++ was very cautious about consistency checking but not now. I would appeal to developers to reconsider this pretty tough decision. I have recently experienced a problem with operator[]. The vector instance had its capacity larger than the size. Mistakenly addressing element beyond the true range did not cause immediate crash rather the output of a complex signal processing application was "strange". This is a pretty common situation (when capacity > size), which is very hard to track, especially if the elements beyond the valid range have accidentally the "reasonable" values. I believe that a simple bounds checking in DEBUG mode (say, assert(first + n < last)) would rule out most of potentially dangerous situations like aforementioned one. Otherwise we get back to C-style arrays. Sincerely, Albert
Re: bounds checking in STL containers
On 15 October 2012 18:14, Ахриев Альберт wrote: > Hi All, > > It appears that operator[] in STL containers (e.g. vector, deque) does not > check bounds any more (g++ 4.7.2). If you want to discuss the C++ library then you should mail the libstd...@gcc.gnu.org list. > Two-three generations ago g++ was very cautious about consistency checking > but not now. > > I would appeal to developers to reconsider this pretty tough decision. We haven't removed any bounds checking.
Re: Normalizing the bitmap APIs.
On 10/15/12, Michael Matz wrote: > On Sat, 13 Oct 2012, Lawrence Crowl wrote: > > > > I have no problem in always returning a status change, > > > > if you are OK with that. > > > > > > I am ok with that. > > > > There is some rationale for being concerned about performance, > > as the checking routines need to read memory locations that > > they otherwise would only write. > > If the destination is one of the sources there will be a read > anyway. If it's not there will be a small penalty if it isn't > in cache yet, though it will be soon because of the write. I agree that if the destination is a source, there is little cause for concern. However, there are routines in which the definition is write only. > > I haven't done any performance measures, but I take as evidence > > that someone thought there was enough of a performance difference > > to make it worth the extra work of writing a second set of > > routines. > > Nope. It was valgrind that caused the introduction of the > sbitmap _cg functions. If the destination was no input and > wasn't initialized the computation of the changed flag (and it's > comparison with zero) depended on uninitialized memory, sometimes > flagged by valgrind also when the return value wasn't used. > > I think it should have been handled by valgrind suppressions, > not by introducing another interface. Agreed. > Given this, and that the other bitmap interfaces mostly return a > changed flag, we should opt for the simpler API, always returning > it. That includes the few remaining bitmap.h functions that > aren't already doing so. Does anyone have objections to this plan? -- Lawrence Crowl
Re: Normalizing the bitmap APIs.
On 2012-10-15 13:21 , Lawrence Crowl wrote: Given this, and that the other bitmap interfaces mostly return a changed flag, we should opt for the simpler API, always returning it. That includes the few remaining bitmap.h functions that aren't already doing so. Does anyone have objections to this plan? Plan looks good to me. Diego.
AArch64 port
I am pleased to announce that the GCC Steering Committee has accepted the AArch64 port for inclusion in GCC and appointed Richard Earnshaw and Marcus Shawcroft as co-maintainers. Happy hacking! David
Re: What happened to the IRA interprocedural reg-alloc work? (function_used_regs and friends)
On 12-10-15 7:14 AM, Steven Bosscher wrote: Hi Vlad, While browsing through old yara/ira patches, I came across this patch of yours from several years ago: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg01625.html That work was in your IRA presentation at the GCC summit in 2007, and it was also part of the initial merge request for IRA. But it's not currently in the trunk and it doesn't appear to ever have been there (nothing in the ChangeLogs about removing/adding this). What happened to the patch? As I remember, the performance improvement from this optimization was very small. There were problems in reviewing IRA and I decided to simplify this task. May be it is worth to return to this work.
