Re: reconfigured configure arg

[Joseph Myers]

On Sat, 1 Sep 2018, Jakub Jelinek wrote:

> Couldn't we do something smarter than this?
> Noticed while debugging why our bisect seed machine spends over 2 minutes in
> sed when handling config.status, and the reason apparently was that it has
> " : (reconfigured) " string in it 37753 times, so almost 700KB just in
> that.  If it is useful information how many times gcc has been reconfigured,
> can't we use a human readable form instead, where we add
> " : (reconfigured) " the first time and then just change it to
> " : (2x reconfigured) ", ..., " : (37753x reconfigured) " etc.?
> 
> Also, don't we actually add the above way $TOPLEVEL_CONFIGURE_ARGUMENTS
> multiple times (if not empty, that is)?

I think my original idea when adding this information in 
 was that, if 
reconfigured, the arguments in TOPLEVEL_CONFIGURE_ARGUMENTS might include 
synthetic ones created by config.status.  So simply using 
TOPLEVEL_CONFIGURE_ARGUMENTS (and ignoring the previous set of configure 
arguments) in the case of reconfiguration would give misleading results, 
but also not mentioning it at all would give misleading results if someone 
did in fact specify different configure options manually when 
reconfiguring.  I was not expecting 37753x reconfiguration.

Ideally the configure arguments shown would be the arguments specified 
manually (including multiple different such sets if necessary) but would 
not duplicate things for automatic reconfiguration with identical 
arguments, or with arguments identical except for whatever config.status 
adds automatically.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Even numbered register pairs restriction on some instructions

[Matthew Malcomson]

I think you can use pdp11 as an example, it does two things that are similar to 
what you're describing.

One is that it requires SImode to go into an even regno, and indicates that it 
uses two registers.  See TARGET_HARD_REGNO_MODE_OK and TARGET_HARD_REGNO_NREGS.

The other is that it has one instruction that wants an odd (!) register: 16 bit multiply.  Multiply is weird: 
if you give it an even destination register it produces a 32 bit result in that register pair, with an odd 
register number it produces a 16 bit result.  So pdp11.md defines both "mulhi3" and 
"mulsihi3" insns.  The latter has an SImode output so that uses the even numbered register, as I 
already described.  The former uses a machine-specific constraint "d".  That is defined in 
constraints.md to mean a register in class MUL_REGS.  pdp11.h defines that name and what registers it refers 
to, and pdp11.h does the reverse mapping (REGNO_REG_CLASS).

If you want even register numbers for some instructions but that's not tied to a specific 
type size (like SImode in my case), I think you'd want to use something analogous to the 
MUL_REGS thing I described.  Say, "EVEN_REGS".  REGNO_REG_CLASS would report 
even regnum to be in EVEN_REGS, odd in GENERAL_REGS.  The bitmaps for REG_CLASS_CONTENTS 
would show that EVEN_REGS contains only even numbered registers while GENERAL_REGS 
contains both odd and even.  And you'd defined a register constraint which matches 
EVEN_REGS.  Then the instructions where you want them would use that constraint.

paul




Yes, it's possible.  You can look at TDmode (128-bit decimal floating point)
on powerpc64*-linux, which is only allowed in even-odd register pairs.
It's in *all* cases though, not some of the time.

Peter



Thanks for the suggestions,
I've had a look into these, and unfortunately it seems they have the 
same problem I've been hitting before.


The use of the TARGET_HARD_REGNO_MODE_OK macro limits all uses of 
registers in a given mode (so that we wouldn't be able to use register 
pairs beginning with odd registers for other instructions), while using 
an EVEN_REGS register class won't work in modes that span more than one 
hard register (as all hard registers covered by a pseudo register must 
be in the same class).


Thanks again,
Matthew

Re: Question about gcc options '-mapcs-stack-check' and '-mapcs-frame'

[Richard Earnshaw (lists)]

On 24/08/18 14:51, Akhilesh chirlancha wrote:
> Hello All,
> 
> I'm using gcc 5.4.0 for armhf target.
> 
> I was compiling simple stack over flow test code with '-mapcs-stack-check'
> option.
> # gcc -mapcs-stack-check test.c
> test.c:1:0: warning: -mapcs-stack-check incompatible with -mno-apcs-frame
>  #include
>  ^
> 
> As per my understanding from the above warning is -mapcs-stack-check option
> depends on -mapcs-frame. Is my understanding correct?? If yes, gcc should
> work for -mapcs-frame.
> But I found this in GCC online docs(
> https://gcc.gnu.org/onlinedocs/gcc-5.4.0/gcc.pdf)
> -mapcs-frame
> Generate a stack frame that is compliant with the ARM Procedure
> Call Standard for all functions, even if this is not strictly necessary for
> correct execution of the code. Specifying '-fomit-frame-pointer' with this
> option causes the stack frames not to be generated for leaf functions. The
> default is '-mno-apcs-frame'. This option is deprecated.
> 
> Document saying '-mapcs-frame' option is deprecated. Does it mean I can't
> use -mapcs-stack-check option?
> 

It wouldn't help even if you did.  I don't think APSC-style stack
checking was ever fully implemented in GCC.

R.

> Thanks in advance,
> 
> Best Regards
> -Akhilesh
> 

Re: Even numbered register pairs restriction on some instructions

[Paul Koning]

> On Sep 3, 2018, at 12:10 PM, Matthew Malcomson  
> wrote:
> 
>> 
>> I think you can use pdp11 as an example, it does two things that are similar 
>> to what you're describing.
>> 
>> One is that it requires SImode to go into an even regno, and indicates that 
>> it uses two registers.  See TARGET_HARD_REGNO_MODE_OK and 
>> TARGET_HARD_REGNO_NREGS.
>> 
>> The other is that it has one instruction that wants an odd (!) register: 16 
>> bit multiply.  Multiply is weird: if you give it an even destination 
>> register it produces a 32 bit result in that register pair, with an odd 
>> register number it produces a 16 bit result.  So pdp11.md defines both 
>> "mulhi3" and "mulsihi3" insns.  The latter has an SImode output so that uses 
>> the even numbered register, as I already described.  The former uses a 
>> machine-specific constraint "d". That is defined in constraints.md to mean a 
>> register in class MUL_REGS.  pdp11.h defines that name and what registers it 
>> refers to, and pdp11.h does the reverse mapping (REGNO_REG_CLASS).
>> 
>> If you want even register numbers for some instructions but that's not tied 
>> to a specific type size (like SImode in my case), I think you'd want to use 
>> something analogous to the MUL_REGS thing I described.  Say, "EVEN_REGS".  
>> REGNO_REG_CLASS would report even regnum to be in EVEN_REGS, odd in 
>> GENERAL_REGS. The bitmaps for REG_CLASS_CONTENTS would show that EVEN_REGS 
>> contains only even numbered registers while GENERAL_REGS contains both odd 
>> and even.  And you'd defined a register constraint which matches EVEN_REGS.  
>> Then the instructions where you want them would use that constraint.
>> 
>>  paul
>> 
> 
>> Yes, it's possible.  You can look at TDmode (128-bit decimal floating point)
>> on powerpc64*-linux, which is only allowed in even-odd register pairs.
>> It's in *all* cases though, not some of the time.
>> 
>> Peter
>> 
> 
> Thanks for the suggestions,
> I've had a look into these, and unfortunately it seems they have the same 
> problem I've been hitting before.
> 
> The use of the TARGET_HARD_REGNO_MODE_OK macro limits all uses of registers 
> in a given mode (so that we wouldn't be able to use register pairs beginning 
> with odd registers for other instructions), while using an EVEN_REGS register 
> class won't work in modes that span more than one hard register (as all hard 
> registers covered by a pseudo register must be in the same class).

Is that so?  I don't remember that restriction, and certainly pdp11 does not do 
this.  Could that be why LRA is failing in some of my tests?  The "old" reload 
pass makes no objections.

Note though that there are two possible ways to look at this.

1. Is there a register class such that all of the hard registers for a given 
mode are in that class?

2. Is the value returned by REGNO_REG_CLASS the same for each of the hard 
registers of a register pair?

For pdp11, (1) is true (they are both members of GENERAL_REGS) while (2) is 
false (for the even register, GENERAL_REGS is returned, vs. MUL_REGS for the 
odd one).

paul

Re: Even numbered register pairs restriction on some instructions

[Matthew Malcomson]

Thanks for the suggestions,
I've had a look into these, and unfortunately it seems they have the same 
problem I've been hitting before.

The use of the TARGET_HARD_REGNO_MODE_OK macro limits all uses of registers in 
a given mode (so that we wouldn't be able to use register pairs beginning with 
odd registers for other instructions), while using an EVEN_REGS register class 
won't work in modes that span more than one hard register (as all hard 
registers covered by a pseudo register must be in the same class).

Is that so?  I don't remember that restriction, and certainly pdp11 does not do this.  
Could that be why LRA is failing in some of my tests?  The "old" reload pass 
makes no objections.

Note though that there are two possible ways to look at this.

1. Is there a register class such that all of the hard registers for a given 
mode are in that class?

2. Is the value returned by REGNO_REG_CLASS the same for each of the hard 
registers of a register pair?

For pdp11, (1) is true (they are both members of GENERAL_REGS) while (2) is 
false (for the even register, GENERAL_REGS is returned, vs. MUL_REGS for the 
odd one).

paul


Apologies, I was unclear there.

When I said "all hard registers covered by a pseudo register must be in 
the same class" I meant "in order for a register constraint to that 
class to be satisfied".


i.e. if you were to use the "d" constraint in the SI operand of the 
"mulhisi3" pattern, then that constraint would not allow any register 
pair to be used since all register pairs use an odd register.


That is why "register classes cannot be used to enforce a requirement 
for a register pair to start with an even-numbered register" as 
mentioned in https://gcc.gnu.org/onlinedocs/gccint/Register-Classes.html .


Matthew

Re: Even numbered register pairs restriction on some instructions

[Paul Koning]

> On Sep 3, 2018, at 1:25 PM, Matthew Malcomson  
> wrote:
> 
>>> 
>>> Thanks for the suggestions,
>>> I've had a look into these, and unfortunately it seems they have the same 
>>> problem I've been hitting before.
>>> 
>>> The use of the TARGET_HARD_REGNO_MODE_OK macro limits all uses of registers 
>>> in a given mode (so that we wouldn't be able to use register pairs 
>>> beginning with odd registers for other instructions), while using an 
>>> EVEN_REGS register class won't work in modes that span more than one hard 
>>> register (as all hard registers covered by a pseudo register must be in the 
>>> same class).
>> Is that so?  I don't remember that restriction, and certainly pdp11 does not 
>> do this.  Could that be why LRA is failing in some of my tests?  The "old" 
>> reload pass makes no objections.
>> 
>> Note though that there are two possible ways to look at this.
>> 
>> 1. Is there a register class such that all of the hard registers for a given 
>> mode are in that class?
>> 
>> 2. Is the value returned by REGNO_REG_CLASS the same for each of the hard 
>> registers of a register pair?
>> 
>> For pdp11, (1) is true (they are both members of GENERAL_REGS) while (2) is 
>> false (for the even register, GENERAL_REGS is returned, vs. MUL_REGS for the 
>> odd one).
>> 
>>  paul
>> 
> Apologies, I was unclear there.
> 
> When I said "all hard registers covered by a pseudo register must be in the 
> same class" I meant "in order for a register constraint to that class to be 
> satisfied".
> 
> i.e. if you were to use the "d" constraint in the SI operand of the 
> "mulhisi3" pattern, then that constraint would not allow any register pair to 
> be used since all register pairs use an odd register.
> 
> That is why "register classes cannot be used to enforce a requirement for a 
> register pair to start with an even-numbered register" as mentioned in 
> https://gcc.gnu.org/onlinedocs/gccint/Register-Classes.html 
>  .
> 
> Matthew

I see what you mean.  You want, say, SImode to be sometimes in an even/odd 
pair, and sometimes in any pair.  I'd like the same thing, in fact, or more 
generally still, I'd like SImode sometimes just to be a pair of HImode values 
that don't have to be both in registers at all, never mind in adjacent 
registers.  There doesn't seem to be a way to do that.  So pdp11, for example, 
always has SImode in even/odd pairs even though only MUL and DIV require that, 
no one else.

paul

Re: Implementing p0515 - spaceship operator

[Tim van Deurzen]

Hello Jakub,

I must confess that in the last months I've not been able to find much 
time (I do this in my spare time) to work on this. Part of the problem 
is also that my new employer hasn't yet provided a written copyright 
waiver for the FSF, though they have agreed and my contract already 
works out well in that regard.


I would very much like to continue this project, but I'm very happy to 
collaborate and join forces to get this feature further. I hang out on 
the CppSlack as vdeurzen, if you want to contact me on another platform. 
Are there other platforms for GCC development that are well suited to 
discussing this topic?



Best regards,

Tim.

On 8/30/18 8:16 PM, Marek Polacek wrote:

On Thu, Aug 30, 2018 at 08:07:05PM +0200, Jakub Jelinek wrote:

On Thu, Jan 11, 2018 at 02:06:06PM +, Joseph Myers wrote:

On Thu, 11 Jan 2018, David Brown wrote:


Maybe it is easier to say "gcc supports <=> in C++2a, and as an
extension also supports it in C and C++ of any standard" ?  I don't
believe there is any way for it to conflict with existing valid code, so
it would do no harm as a gcc extension like that - and C users can then
use it too.

As per previous IRC discussion, changing the lexing to support this
pp-token can break valid code in previous standards, e.g. code
concatenating <=> and >, then stringizing the result (the C++ proposal for
adding this feature also notes some obscure cases where the character
sequence <=> can actually occur as tokens, not just pp-tokens -
"X<&Y::operator<=>" and "x+&operator<=>y" - so of course patches adding
this feature should add testcases using such cases with older -std=
options).

Changes to cpp_avoid_paste (so that preprocessed output does not put a
pp-token starting with > immediately after <=) do not need to be
conditional on the standard version, however.

Here is a patch that attempts to implement this (in libcpp + gcc/testsuite
only so far).
It needs to be parsed and handled in the C++ FE obviously, which is missing.

Thanks.

Tim, have you had any success with this, or should I (or somebody else) feel
free to take it over?

Marek