On 7/30/24 3:08 PM, Jakub Jelinek wrote:
On Tue, Jul 30, 2024 at 03:03:39PM -0600, Jeff Law wrote:
The compilation of convert-bfp-6.c itself is identical between the older (where
it didn't fail) and newer (where it fails) builds, what has changed is libgcc.a.
In particular, what matters is libgcc/bid_binarydecimal.o.
If I link all objects from libgcc from older (good libgcc) but
bid_binarydecimal.o
(that one from newer bad libgcc), convert-bfp-6 still aborts, if I link all
objects
from libgcc from newer (bad libgcc) but bid_binarydecimal.o (that one from
older good libgcc), convert-bfp-6 works.
I see. If it is not a false alarm, then it seems to me that
gcc-15-2212-gad642d2c950
from Jeff might fix the problem from the regression report. But I am not sure
if it
really fix the problem or happen to be right.
Based on Jakub's comment, I'm going to assume it's a real issue related to
the compilation of the support code in libgcc and thus I need to do another
round of trying to reproduce.
The testcases don't fail for me anymore, 20240722 (around 20:45 UTC) still
failed, 20240726
(around 13:15 UTC) already didn't. Don't have record of exact revisions.
It was almost certainly this change based comparing bid_binarydecimal
ext-dce debugging info as ext-dce was changed.
commit 679086172b84be18c55fdbb9cda7e97806e7c083 (HEAD)
Author: Jeff Law <j...@ventanamicro.com>
Date: Wed Jul 24 11:16:26 2024 -0600
[rtl-optimization/116037] Explicitly track if a destination was skipped in
ext-dce
So this has been in the hopper since the first bugs were reported against
ext-dce. It'd been holding off committing as I was finding other issues in
terms of correctness of live computations. There's still problems in that
space, but I think it's time to push this chunk forward. I'm marking it as
116037, but it may impact other bugs.
[ ... ]
Jeff
