> I assume your broad testing covers every modified file. Do you have an > idea of whether that is true. I rechecked everything and the one case I missed was supersparc-* Even the current tree has a build problem of the supersparc target with current tools due to combination of a bug in gcc specs handling and new binutils enforcements of setting the cpu ABI correctly. The issue is that gcc doesn't specify at least "v8" in the assembler invocations when -mcpu=supersparc is given so binutils complains when it sees integer multiply and divide instructions since it defaults to v7. Good that you found that!
I'll get those bugs sorted out, but at least gcc-4.6 and gcc-4.7 have this problem, and have had them for some time, so I think we should work around it. A workaround that works is to pass "-mcpu=v8 -mcpu=supersparc" instead of just plain "-mcpu=supersparc" I though -mcpu=foo -mcpu=bar would either be equivalent to just -mcpu=bar or just -mcpu=foo... > Whn testing shared libs, I have found that libtool sometimes prefers an > instaled version to the newly compiled version. That happens more often > with 32-bit libs on 64-bit systems, since libtool doesn't set > LD_32_LIBRARY_PATH. Please make sure the shared builds' libraries have > actually been tested. I've verified that this works as intended. LD_32_LIBRARY_PATH seems to be a FreeBSD invention. On Slowaris it is LD_LIBRARY_PATH_32... (But the semantics of these paths might not be the same.) > That patch looks good to me, apart from the LEA issue. > > Once you have addressed that, I would like to commit this to the main Here is the new version, thanks: Thanks, will commit shortly after a quick read-through. -- Torbjörn _______________________________________________ gmp-devel mailing list gmp-devel@gmplib.org http://gmplib.org/mailman/listinfo/gmp-devel