On Thu, Feb 11, 2010 at 10:49:44AM -0800, Linus Torvalds wrote: > > > On Thu, 11 Feb 2010, Mel Gorman wrote: > > > > Tony posted the assember files (KCFLAGS=-save-temps) from > > the broken and working compilers which a copy of is available at > > http://www.csn.ul.ie/~mel/postings/bug-20100211/ . Have you any suggestions > > on what the best way to go about finding where the badly generated code > > might be so a warning can be added for gcc 4.1? My strongest suspicion is > > that the problem is in the assembler that looks up the struct page from a > > PFN in sparsemem but I'm failing to prove it. > > Try contacting the gcc people. They are (well, _some_ of them are) much > more used to walking through asm differences, and may have more of a clue > about where the difference is likely to be for those compiler versions. > Ok, thanks. Will get on to them if the other suggestions don't work out. > I'm personally very comfortable with x86 assembly, but having tried to > find compiler bugs in the past I can also say that despite my x86 comfort > I've almost always failed. The trivial stupid differences tend to always > just totally overwhelm the actual real difference that causes the bug. > I don't feel quite as bad then. I was hoping it would be "obvious" but was getting tripped up by reordering and slightly-different ways of achieving the same end result. > One thing to try is to see if the buggy compiler version can be itself > triggered to create a non-buggy asm listing by using some compiler flag. > That way the "trivial differences" tend to be smaller, and the bug stands > out more. > > For example, that's how we found the problem with "-fwrapv" - testing the > same compiler version with different flags (see commit a137802ee83). > The compiler of interest is still available so I should be able to reproduce the problem locally once I get an old distro installed. > Sometimes if the trivial differences are mostly register allocation, you > can get a "feel" for the differences by replacing all register names with > just the string "REG" (and "[0-9x](%e[sb]p)" with "STACKSLOT", and try to > do the diff that way. If everything else is roughly the same, you then see > the place where the code is _really_ different. > Will try this first, then installing and old distro before resorting to the gcc people. There is a good chance their response will be "go away" once they realise it'd fixed in later compilers. > But when the compiler actually re-orders basic blocks etc, then diffs are > basically impossible to get anything sane out of. > Thanks for the suggestions. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>