------- Additional Comments From jh at suse dot cz 2004-12-02 09:02 ------- Subject: Re: [4.0 Regression] -march=pentium4 generates word fetch instead of byte fetch
> > ------- Additional Comments From neroden at gcc dot gnu dot org 2004-12-02 > 03:35 ------- > Jan's message quoted in the previous comment seems to be orthogonal to the > main problem in this bug. The problem is that a word fetch is being > generated > which *reads out of bounds memory*. > > If the last byte in a page is being fetched, you must not extend that to > fetch > the next byte; if the first byte in a page is being fetched, you must not > extend that to fetch the previous byte. Those are the key failure situations > which must be prevented, regardless of whether this is -Os, -O2, or -O0. > > It doesn't appear to me that the changes proposed in Jan's message actually > address that, since none of them seem to feature a alignment or other type of > correctness check before converting a QImode move into a (possibly illegal) > SImode move. We don't need to check that since the code always use zero extension conversion (unless it hit the buggy -Os conditional) and zero extension still reads byte, just writes whole register. It is not good idea to use full sized read even for aligned sources since we will get partial memory stalls. We use full sized moves only for register to register moves where it is safe. I will prepare the patch later today. Honza > > In particular, this statement looks like it's wrong: > >while for > >TARGET_PARTIAL_REG_STALL/TARGET_PARTIAL_REG_DEPENDENCY we can still use > >the full moves as long as they don't encode longer. > > I believe a check is required that the full moves don't cause a segmentation > violation. An alignment check would be sufficient (it would prohibit more > cases than strictly necessary, but this is a correctness issue, and I haven't > thought of a better check). > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019 > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18019
