This is the mail archive of the
mailing list for the GCC project.
Re: Another AIX Bootstrap failure
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: David Edelsohn <dje dot gcc at gmail dot com>
- Cc: Jan Hubicka <hubicka at ucw dot cz>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 16 Jun 2014 17:08:01 +0200
- Subject: Re: Another AIX Bootstrap failure
- Authentication-results: sourceware.org; auth=none
- References: <CAGWvnykZKOiQhM-N6TTCPa_E0d0TCK_PYs9bL_YZTJ7E193eUQ at mail dot gmail dot com> <20140616043557 dot GA6530 at kam dot mff dot cuni dot cz> <CAGWvnyn2ewzYhaAY=KAixxaqwsfzk9f9ScVkNeCVg+yVe6NRqA at mail dot gmail dot com>
> Thanks for reverting the patch. I will check if this resolves the
> current bootstrap problem.
> I was suggesting that you create a branch for all of the visibility
> changes to make it easier to track the various original patches and
> later correction patches from you.
> I don't know if the gen* programs hang because of the visibility
> changes or because of the change in sections. The change in sections
> could conflict with the GCC code to handle AIX XCOFF CSECTs for
> AIX recently added support for ELF-like visibility. AIX previously
> supported the equivalent of visibility through "export" files. The
> recent problems could be due to issues with assembly file ordering,
> but they also could be related to the visibility changes affecting the
> way that GCC emits code to branch to global functions.
I comitted the revert now (my original testing got struct on ICE in
auto-inc-dec pass that is unrelated). I probably won't have time to analye
what went wrong until Wednesday. The patch did not really play with
ELF visibilities it was again related to bringing symbols local.
I tried a case disabling the new conditional on clearning user section
but that did not help. The patch basically collected few cleanups
and fixes of corner case. Last change is fix in the inline heuristics
to not try to enale DECL_ONE_ONLY section sharing on targets not supporting
it. Obviously it should not lead to wrong code, since any inlining decision
change should not, but I am testing it independnely now.