RFC -- targets with unsigned bifields

RFC -- targets with unsigned bifields

[Jeff Law]

So mcore-elf is the slowest target to test with a simulator.  Not 
because it's simulator is particularly bad, but because some tests 
timeout as they've gotten into infinite loops.  This causes the 
mcore-elf port to take about 2X longer than most other gdbsim ports.

I tracked this down to the port unconditionally adding 
-funsigned-bitfields to CC1_SPEC.  According to the comment it's how the 
ABI is defined for the mcore targets.

It'd be nice to get reasonable results from mcore-elf in a reasonable 
amount of time.  The question is how.

I *could* just disable the -funsigned-bitfields within the tester.  We 
certainly have the ability to carry forward patches like this which 
exist only to help the testing effort.

Another approach would be to add an explicit -fsigned-bifields to the 
arguments for the affected tests.  I'd guess it's on the order of around 
35 distinct tests that would need to be updated.

A third approach would be to grub around and see if there's a way to add 
a -fsigned-bitfields using dejagnu, perhaps in the baseboards file.

Looking for suggestions/recommendations here.

Jeff

Re: RFC -- targets with unsigned bifields

[Richard Biener]

> Am 17.12.2023 um 04:29 schrieb Jeff Law <jlaw@ventanamicro.com>:
> 
> 
> So mcore-elf is the slowest target to test with a simulator.  Not because it's simulator is particularly bad, but because some tests timeout as they've gotten into infinite loops.  This causes the mcore-elf port to take about 2X longer than most other gdbsim ports.
> 
> I tracked this down to the port unconditionally adding -funsigned-bitfields to CC1_SPEC.  According to the comment it's how the ABI is defined for the mcore targets.
> 
> It'd be nice to get reasonable results from mcore-elf in a reasonable amount of time.  The question is how.
> 
> I *could* just disable the -funsigned-bitfields within the tester.  We certainly have the ability to carry forward patches like this which exist only to help the testing effort.
> 
> Another approach would be to add an explicit -fsigned-bifields to the arguments for the affected tests.  I'd guess it's on the order of around 35 distinct tests that would need to be updated.
> 
> A third approach would be to grub around and see if there's a way to add a -fsigned-bitfields using dejagnu, perhaps in the baseboards file.

When the testcases are simply invalid with unsigned bitfields then I suggest to add a dg effective target we could require?  Or are the testcases actually miscompiled?

I suppose neither -f[un]signed-bitfields is the standard behavior but bitfield signedness is determined by the underlying type?  Or is this flag about sth else?

I could imagine a test needing the default behavior?

Richard 

> Looking for suggestions/recommendations here.
> 
> Jeff

Re: RFC -- targets with unsigned bifields

[Joseph Myers]

On Sat, 16 Dec 2023, Jeff Law wrote:

> I tracked this down to the port unconditionally adding -funsigned-bitfields to
> CC1_SPEC.  According to the comment it's how the ABI is defined for the mcore
> targets.

We explicitly document (under Non-bugs in trouble.texi) that we don't do 
this, and -funsigned-bitfields is also incompatible with C++14 and later.  
So stopping adding -funsigned-bitfields like that, and telling users of 
this port to pass that option explicitly if they want its effects in 
future, would seem the obvious thing to do.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: RFC -- targets with unsigned bifields

[Jeff Law]

On 12/18/23 11:32, Joseph Myers wrote:
> On Sat, 16 Dec 2023, Jeff Law wrote:
> 
>> I tracked this down to the port unconditionally adding -funsigned-bitfields to
>> CC1_SPEC.  According to the comment it's how the ABI is defined for the mcore
>> targets.
> 
> We explicitly document (under Non-bugs in trouble.texi) that we don't do
> this, and -funsigned-bitfields is also incompatible with C++14 and later.
> So stopping adding -funsigned-bitfields like that, and telling users of
> this port to pass that option explicitly if they want its effects in
> future, would seem the obvious thing to do.
I'm not even sure there's any more users for this port.  So this may be 
the best solution in the end.  Change, document and forget :-)

Any objections to make that change in gcc-14?  It's a one-liner.

jeff