On Tue, Sep 02, 2014 at 10:02:38AM +0800, Bin.Cheng wrote: > >> >Archaeology suggests this check is because the clobber might be an > >> >earlyclobber. Which seems silly: how can it be a valid insn at all > >> >in that case? It seems to me the check can just be removed. That > >> >will hide your issue, maybe even solve it (but I doubt it). > >> Silly for other reasons, namely that earlyclobber doesn't come into play > >> until after combine (register allocation and later). > > > > The last change to this code was by Ulrich (cc:ed); in that thread (June > > 2004, mostly not threaded in the mail archive, broken MUAs :-( ) it was > > said that any clobber should be considered an earlyclobber (an RTL insn > > can expand to multiple machine instructions, for example). But I don't > > see how that can matter for "dest" here (the dest of "insn", that's 76 > > in the example), only for "src". > > > > The version of "flags" set in 76 obviously dies in 77 (it clobbers the > > reg after all), but there is no way it could clobber it before it uses > > it, that just makes no sense. And in the combined insn that version of > > flags does not exist at all. > Agreed, otherwise it would be another uninitialized use problem. > Maybe the check is too strict here? Do you have some archived page > address for that, just saving us some time for digging.
http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00994.html (and look in that month's archives for the rest of the messages). > My only concern is, logic in dictribute_notes should also be revisited > under this BZ. I think the issue will be hidden by changes we are > talking about in can_combine_p. Yes. Unless we disallow all combinations that *would* cause problems :-) Segher
