on 2022/12/13 14:14, Michael Meissner wrote: > On Mon, Dec 12, 2022 at 06:20:14PM +0800, Kewen.Lin wrote: >> Without or with patch #1, the below ICE in libgcc exists, the ICE should have >> nothing to do with the special handling for building_libgcc in patch #1. I >> think patch #2 which makes _Float128 and __float128 use the same internal >> type fixes that ICE. >> >> I still don't get the point why we need the special handling for >> building_libgcc, >> I also tested on top of patch #1 and #2 w/ and w/o the special handling for >> building_libgcc, both bootstrapped and regress-tested. >> >> Could you have a double check? > > As long as patch #2 and #3 are installed, we don't need the special handling > for building_libgcc. Good catch. > > I will send out a replacement patch for it.
Thanks! I still feel patch #1 is independent, it helps to fix the issues as shown in its associated test case, which looks an oversight in the previous implementation to me. :) > >> Since your patch #2 (and #3) fixes ICE and some exposed problems, and >> _Float128 >> is to use the same internal type as __float128, types with >> attribute((mode(TF))) >> and attribute((mode(TC))) should be correct, I assume that this patch is just >> to make the types explicit be with _Float128 (for better readability and >> maintainance), but not for any correctness issues. > > Yes, the patch is mainly for clarity. The history is the libgcc support went > in before _Float128 went in, and I never went back to use those types when we > could use them. > > With _Float128, we can just use _Complex _Float128 and not > bother with trying to get the right KC/TC for the attribute mode stuff. > > However, if patches 1-3 aren't put in, just applying the patch to use > _Float128 > and _Complex _Float128 would fix the immediate problem (of not building GCC on > systems with IEEE 128-bit long double). However, it is a band-aid that just > works around the problem of building __mulkc3 and __divkc3. It doesn't fix > the > other problems between __float128 and _Float128 that show up in some places > that I would like to get fixed. > > So I haven't submitted the patch, because I think it is more important to get > the other issues fixed. OK, make sense, thanks for the clarification! BR, Kewen
