On Thu May 5 18:53:18 UTC 2016 regis.etourmy at free.fr wrote: > Sorry, I meant gcc48, not 38.... > > ----- Mail original ----- > De: "regis etourmy" < > regis.etourmy at free.fr > > > À: > ruby at FreeBSD.org > > Cc: > freebsd-ports at freebsd.org > > Envoyé: Jeudi 5 Mai 2016 20:28:52 > Objet: ruby22 buillds with gcc38 on powerpc64 > > Hi, > > I tried to build ruby22 with gcc38 on my powermac G5 and it built (it didn't > with clang). I have not tested yet if it runs well. > > Thanks for all your work, > > Régis
Relative to clang 3.8.0 (for example). . . https://llvm.org/bugs/show_bug.cgi?id=25780 [a meta-list of powerpc64 and powerpc clang reports that block use by freebsd world and kernel] lists various powerpc and powerpc64 code-generation issues for clang 3.8.0 vs. FreeBSD. As I remember each of the following includes examples of powerpc64 code-generation issues, not just powerpc (non-64) ones. https://llvm.org/bugs/show_bug.cgi?id=26970 https://llvm.org/bugs/show_bug.cgi?id=26856 https://llvm.org/bugs/show_bug.cgi?id=26844 https://llvm.org/bugs/show_bug.cgi?id=26761 One of the types of things that is broken on powerpc64 and powerpc is C++ exception handling --and such is broken by bad code generation, independent of involved support libraries possibly adding even more issues. For powerpc (non-64) there are also stack-handling ABI violations that can, for example, mess up the stack contents when signal delivery happens. As far as I can tell depending on clang/clang++ for powerpc64 or for powerpc is risky or requires analysis that things are actually working for all the specific uses being made. But so far as I can tell clang 3.8.0 is an improvement over prior clang vintages for powerpc64 and for powerpc. === Mark Millard markmi at dsl-only.net _______________________________________________ [email protected] mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[email protected]"
