[r15-2196 Regression] FAIL: c-c++-common/dfp/convert-bfp-6.c -std=gnu++98 execution test on Linux/x86_64

[Jeff Law]

On 7/23/24 11:26 PM, Jiang, Haochen wrote:
> 
> 
>> -----Original Message-----
>> From: Jakub Jelinek <jakub@redhat.com>
>> Sent: Wednesday, July 24, 2024 1:09 PM
>> To: Jiang, Haochen <haochen.jiang@intel.com>
>> Cc: jlaw@ventanamicro.com; gcc-regression@gcc.gnu.org; gcc-
>> patches@gcc.gnu.org
>> Subject: Re: [r15-2196 Regression] FAIL: c-c++-common/dfp/convert-bfp-6.c
>> -std=gnu++98 execution test on Linux/x86_64
>>
>> On Wed, Jul 24, 2024 at 01:49:06AM +0000, Jiang, Haochen wrote:
>>> It might be a false positive timeout alert. Please ignore that first.
>>
>> It is not.  I'm seeing it too consistently on i686-linux:
>> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c execution test
>> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c execution test
>> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++11
>> execution test
>> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++14
>> execution test
>> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++17
>> execution test
>> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++20
>> execution test
>> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++23
>> execution test
>> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++26
>> execution test
>> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++98
>> execution test
>> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++11
>> execution test
>> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++14
>> execution test
>> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++17
>> execution test
>> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++20
>> execution test
>> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++23
>> execution test
>> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++26
>> execution test
>> obj49/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++98
>> execution test
>> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c execution test
>> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c execution test
>> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++11
>> execution test
>> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++14
>> execution test
>> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++17
>> execution test
>> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++20
>> execution test
>> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++23
>> execution test
>> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++26
>> execution test
>> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-10.c  -std=c++98
>> execution test
>> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++11
>> execution test
>> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++14
>> execution test
>> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++17
>> execution test
>> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++20
>> execution test
>> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++23
>> execution test
>> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++26
>> execution test
>> obj51/LOGT:FAIL: c-c++-common/dfp/convert-bfp-6.c  -std=gnu++98
>> execution test
>>
>> 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.

jeff