Successful build of gcc 9.2.0 on x86_64-w64-mingw32
Testresults can be seen here: https://gcc.gnu.org/ml/gcc-testresults/2019-08/msg01595.html Complete logs of the testsuite run are available here: https://cloud.emrich-ebersheim.de/index.php/s/g9D245XdCW6GD5W signature.asc Description: OpenPGP digital signature
Re: Expansion of narrowing math built-ins into power instructions
Hello. I just wanted to make sure that I am looking at the correct code here. Except for rtl.def where I should be introducing something like float_contract (or float_narrow?) and also simplify-rtx.c, breakpoints set on functions around expr.c, cfgexpand.c where I grep for float_truncate/FLOAT_TRUNCATE did not hit. Also, in what manner should float_contract/narrow be different from float_truncate as both are trying to do similar things? (truncation from DF to SF) Thanks, Tejas On Thu, 15 Aug 2019 at 02:30, Segher Boessenkool wrote: > > On Wed, Aug 14, 2019 at 08:23:27PM +, Joseph Myers wrote: > > On Wed, 14 Aug 2019, Segher Boessenkool wrote: > > > > > Does something like > > > float d; double a, b, x; > > > ... > > > d = fadd (a + x, b - x); > > > work as wanted, with such a representation? It would simplify (does it?) > > > to > > > d = fadd (a, b); > > > but is that allowed? > > > > It's not allowed, but neither is simplifying (a + x) + (b - x) into (a + > > b), when contraction isn't allowed. > > Ah of course. And we already should not do such simplification on RTL, > when contraction is disallowed. > > So yeah it should work fine I think. A new RTL code would be best (it > would be silly to have to make an unspec for it in every port separately), > but an unspec is of course easiest for now. > > > Segher
Re: Expansion of narrowing math built-ins into power instructions
Tejas Joshi writes: > Hello. > I just wanted to make sure that I am looking at the correct code here. > Except for rtl.def where I should be introducing something like > float_contract (or float_narrow?) and also simplify-rtx.c, breakpoints > set on functions around expr.c, cfgexpand.c where I grep for > float_truncate/FLOAT_TRUNCATE did not hit. > Also, in what manner should float_contract/narrow be different from > float_truncate as both are trying to do similar things? (truncation > from DF to SF) I think the code should instead be a fused addition and truncation, a bit like FMA is a fused addition and multiplication. Describing it as a DFmode addition followed by some conversion to SF would still involve double rounding. simplify-rtx.c is probably the most important place to handle it. It would be easiest to test using the selftests at the end of the file. Thanks, Richard
Re: Expansion of narrowing math built-ins into power instructions
> I think the code should instead be a fused addition and truncation, > a bit like FMA is a fused addition and multiplication. Describing it as > a DFmode addition followed by some conversion to SF would still involve > double rounding. In that case, something like FADD. But for functions like fsub, fmul and fdiv that does similar computation, wouldn't we need more operation codes for them? Is it possible to have something generalized that does *arithmetic computation (rather than just addition)* and then *conversion (narrowing)*? just a thought. Thanks, Tejas On Thu, 15 Aug 2019 at 18:17, Richard Sandiford wrote: > > Tejas Joshi writes: > > Hello. > > I just wanted to make sure that I am looking at the correct code here. > > Except for rtl.def where I should be introducing something like > > float_contract (or float_narrow?) and also simplify-rtx.c, breakpoints > > set on functions around expr.c, cfgexpand.c where I grep for > > float_truncate/FLOAT_TRUNCATE did not hit. > > Also, in what manner should float_contract/narrow be different from > > float_truncate as both are trying to do similar things? (truncation > > from DF to SF) > > I think the code should instead be a fused addition and truncation, > a bit like FMA is a fused addition and multiplication. Describing it as > a DFmode addition followed by some conversion to SF would still involve > double rounding. > > simplify-rtx.c is probably the most important place to handle it. > It would be easiest to test using the selftests at the end of the file. > > Thanks, > Richard
Re: Indirect memory addresses vs. lra
On 8/10/19 2:05 AM, John Darrington wrote:
On Fri, Aug 09, 2019 at 01:34:36PM -0400, Vladimir Makarov wrote:
If you provide LRA dump for such test (it is better to use
-fira-verbose=15 to output full RA info into stderr), I probably could
say more.
I've attached such a dump (generated from
gcc/testsuite/gcc.c-torture/compile/pr53410-2.c).
The less regs the architecture has, thoke easier to run into such error
message if something described wrong in the back-end.?? I see your
architecture is 16-bit micro-controller with only 8 regs, some of them is
specialized.?? So your architecture is really register constrained.
That's not quite correct. It is a 24-bit micro-controller (the address
space is 24 bits wide). There are 2 address registers (plus stack
pointer and program counter) and there are 8 general purpose data
registers (of differing sizes).
J'
Thank you for providing the sources. It helped me to understand what is
going on. So the test crashes on
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c: In
function ‘f1’:
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1:
error: unable to find a register to spill
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1:
error: this is the insn:
(insn 14 49 15 2 (set (mem:SI (plus:PSI (reg/f:PSI 40 [34])
(const_int 32 [0x20])) [2 S4 A64])
(mem:SI (reg:PSI 41) [2 *p_5(D)+0 S4 A8]))
"/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c":9:9 95
{*movsi}
(expr_list:REG_DEAD (reg:PSI 41)
(expr_list:REG_DEAD (reg/f:PSI 40 [34])
(nil
Your target has only 2 non-fixed addr registers (r8, r9). One (r9) is defined
as a hard reg pointer pointer. Honestly, I never saw a target with such
register constraints.
-O0 assumes -fno-omit-frame-pointer. So in -O0 mode we have only *one* free
addr reg for insn which requires *2* of them. That is why the GCC port crashes
on this test. If you add -fomit-frame-pointer, the test succeeds.
But even if use -fomit-frame-pointer, it is not guaranteed that hard reg
pointer will be substituted by stack pointer. There are many cases where it is
not possible (e.g. in case of alloca usage).
So what can be done, imho. The simplest solution would be preventing insns
with more one memory operand. The more difficult solution would be permitting
two memory one with address pseudo and another one with stack pointer.
I think only after solving this problem, you could think about implementing
indirect memory addressing.
Re: Indirect memory addresses vs. lra
On August 15, 2019 6:29:13 PM GMT+02:00, Vladimir Makarov
wrote:
>On 8/10/19 2:05 AM, John Darrington wrote:
>> On Fri, Aug 09, 2019 at 01:34:36PM -0400, Vladimir Makarov wrote:
>>
>> If you provide LRA dump for such test (it is better to use
>> -fira-verbose=15 to output full RA info into stderr), I
>probably could
>> say more.
>>
>> I've attached such a dump (generated from
>gcc/testsuite/gcc.c-torture/compile/pr53410-2.c).
>>
>> The less regs the architecture has, thoke easier to run into
>such error
>> message if something described wrong in the back-end.?? I see
>your
>> architecture is 16-bit micro-controller with only 8 regs, some
>of them is
>> specialized.?? So your architecture is really register
>constrained.
>>
>> That's not quite correct. It is a 24-bit micro-controller (the
>address
>> space is 24 bits wide). There are 2 address registers (plus stack
>> pointer and program counter) and there are 8 general purpose data
>> registers (of differing sizes).
>>
>>
>> J'
>>
>Thank you for providing the sources. It helped me to understand what
>is
>going on. So the test crashes on
>
>/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:
>In function ‘f1’:
>/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1:
>error: unable to find a register to spill
>/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1:
>error: this is the insn:
>(insn 14 49 15 2 (set (mem:SI (plus:PSI (reg/f:PSI 40 [34])
> (const_int 32 [0x20])) [2 S4 A64])
>(mem:SI (reg:PSI 41) [2 *p_5(D)+0 S4 A8]))
>"/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c":9:9
>95 {*movsi}
> (expr_list:REG_DEAD (reg:PSI 41)
> (expr_list:REG_DEAD (reg/f:PSI 40 [34])
> (nil
>
>Your target has only 2 non-fixed addr registers (r8, r9). One (r9) is
>defined as a hard reg pointer pointer. Honestly, I never saw a target
>with such register constraints.
>
>-O0 assumes -fno-omit-frame-pointer. So in -O0 mode we have only *one*
>free addr reg for insn which requires *2* of them. That is why the GCC
>port crashes on this test. If you add -fomit-frame-pointer, the test
>succeeds.
>
>But even if use -fomit-frame-pointer, it is not guaranteed that hard
>reg pointer will be substituted by stack pointer. There are many cases
>where it is not possible (e.g. in case of alloca usage).
>
>So what can be done, imho. The simplest solution would be preventing
>insns with more one memory operand. The more difficult solution would
>be permitting two memory one with address pseudo and another one with
>stack pointer.
Couldn't we spill the frame pointer? Basically we should be able to compute the
first address into a reg, spill that, do the second (both could require the
frame pointer), spill the frame pointer, reload the first computed address from
the stack, execute the insn and then reload the frame pointer.
Maybe the frame pointer can also be implemented 'virually' in an index register
that you keep updated so that sp + reg
Is the FP. Or frame accesses can use a
Stack slot as FP and the indirect memory
Addressing... (is there an indirect lea?)
>I think only after solving this problem, you could think about
>implementing indirect memory addressing.
>
>
Re: Indirect memory addresses vs. lra
On Thu, Aug 15, 2019 at 12:29:13PM -0400, Vladimir Makarov wrote:
Thank you for providing the sources.?? It helped me to understand what is
going on.?? So the test crashes on
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c: In
function ???f1???:
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1:
error: unable to find a register to spill
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1:
error: this is the insn:
(insn 14 49 15 2 (set (mem:SI (plus:PSI (reg/f:PSI 40 [34])
(const_int 32 [0x20])) [2 S4 A64])
(mem:SI (reg:PSI 41) [2 *p_5(D)+0 S4 A8]))
"/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c":9:9 95
{*movsi}
(expr_list:REG_DEAD (reg:PSI 41)
(expr_list:REG_DEAD (reg/f:PSI 40 [34])
(nil
Thanks for taking a look.
Your target has only 2 non-fixed addr registers (r8, r9). One (r9) is
defined as a hard reg pointer pointer.
That is correct.
Honestly, I never saw a target with such register constraints.
My recollection is that MC68HC11 was the same.
So what can be done, imho. The simplest solution would be preventing
insns with more one memory operand.
I tried this solution earlier. But unfortunately it makes things worse. What
happens is it libgcc cannot
even be built -- ICEs occur on a memory from address reg insn such as:
(insn 117 2981 3697 5 (set (mem/f:PSI (plus:PSI (reg:PSI 1309)
(const_int 102 [0x66])) [3 fs_129(D)->pc+0 S4 A8])
(reg:PSI 1310))
"/home/jmd/Source/GCC2/libgcc/unwind-dw2.c":977:9 96 {movpsi}
J'
--
Avoid eavesdropping. Send strong encrypted email.
PGP Public key ID: 1024D/2DE827B3
fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3
See http://sks-keyservers.net or any PGP keyserver for public key.
Re: Indirect memory addresses vs. lra
On Thu, Aug 15, 2019 at 06:38:30PM +0200, Richard Biener wrote: Couldn't we spill the frame pointer? Basically we should be able to compute the first address into a reg, spill that, do the second (both could require the frame pointer), spill the frame pointer, reload the first computed address from the stack, execute the insn and then reload the frame pointer. Maybe the frame pointer can also be implemented 'virually' in an index register that you keep updated so that sp + reg Is the FP. Or frame accesses can use a Stack slot as FP and the indirect memory Addressing... (is there an indirect lea?) Yes. lea x, [4,x] is a valid instruction. J' -- Avoid eavesdropping. Send strong encrypted email. PGP Public key ID: 1024D/2DE827B3 fingerprint = 8797 A26D 0854 2EAB 0285 A290 8A67 719C 2DE8 27B3 See http://sks-keyservers.net or any PGP keyserver for public key.
Re: Indirect memory addresses vs. lra
On 8/15/19 1:35 PM, John Darrington wrote:
On Thu, Aug 15, 2019 at 12:29:13PM -0400, Vladimir Makarov wrote:
Thank you for providing the sources.?? It helped me to understand what is
going on.?? So the test crashes on
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c: In function ???f1???:
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1:
error: unable to find a register to spill
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1:
error: this is the insn:
(insn 14 49 15 2 (set (mem:SI (plus:PSI (reg/f:PSI 40 [34])
(const_int 32 [0x20])) [2 S4 A64])
(mem:SI (reg:PSI 41) [2 *p_5(D)+0 S4 A8]))
"/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c":9:9 95
{*movsi}
(expr_list:REG_DEAD (reg:PSI 41)
(expr_list:REG_DEAD (reg/f:PSI 40 [34])
(nil
Thanks for taking a look.
Your target has only 2 non-fixed addr registers (r8, r9). One (r9) is defined as a hard reg pointer pointer.
That is correct.
Honestly, I never saw a target with such register constraints.
My recollection is that MC68HC11 was the same.
So what can be done, imho. The simplest solution would be preventing insns with more one memory operand.
I tried this solution earlier. But unfortunately it makes things worse. What
happens is it libgcc cannot
even be built -- ICEs occur on a memory from address reg insn such as:
(insn 117 2981 3697 5 (set (mem/f:PSI (plus:PSI (reg:PSI 1309)
(const_int 102 [0x66])) [3 fs_129(D)->pc+0 S4 A8])
(reg:PSI 1310))
"/home/jmd/Source/GCC2/libgcc/unwind-dw2.c":977:9 96 {movpsi}
I see. Then for the insn, you could try to create a pattern
"memory,special memory constraint". The special memory constraint
should satisfy only spilled pseudo (pseudo with reg_renumber == -1). I
believe lra-constraints.c can spill the pseudo and the end you will have
mem[disp1 + r8|r9|sp] = mem[disp1+sp].
It might work. If it is not, we could modify LRA to do this.
Another solution would be adding unexisting register Z and for mem:psi
[psi:r] = Z you could emit an assembler insn : mem[psi:r] = a stack slot
corresponding Z.
Re: Indirect memory addresses vs. lra
On 8/15/19 12:38 PM, Richard Biener wrote:
On August 15, 2019 6:29:13 PM GMT+02:00, Vladimir Makarov
wrote:
On 8/10/19 2:05 AM, John Darrington wrote:
On Fri, Aug 09, 2019 at 01:34:36PM -0400, Vladimir Makarov wrote:
If you provide LRA dump for such test (it is better to use
-fira-verbose=15 to output full RA info into stderr), I
probably could
say more.
I've attached such a dump (generated from
gcc/testsuite/gcc.c-torture/compile/pr53410-2.c).
The less regs the architecture has, thoke easier to run into
such error
message if something described wrong in the back-end.?? I see
your
architecture is 16-bit micro-controller with only 8 regs, some
of them is
specialized.?? So your architecture is really register
constrained.
That's not quite correct. It is a 24-bit micro-controller (the
address
space is 24 bits wide). There are 2 address registers (plus stack
pointer and program counter) and there are 8 general purpose data
registers (of differing sizes).
J'
Thank you for providing the sources. It helped me to understand what
is
going on. So the test crashes on
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:
In function ‘f1’:
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1:
error: unable to find a register to spill
/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c:10:1:
error: this is the insn:
(insn 14 49 15 2 (set (mem:SI (plus:PSI (reg/f:PSI 40 [34])
(const_int 32 [0x20])) [2 S4 A64])
(mem:SI (reg:PSI 41) [2 *p_5(D)+0 S4 A8]))
"/home/jmd/Source/GCC2/gcc/testsuite/gcc.c-torture/compile/pr53410-2.c":9:9
95 {*movsi}
(expr_list:REG_DEAD (reg:PSI 41)
(expr_list:REG_DEAD (reg/f:PSI 40 [34])
(nil
Your target has only 2 non-fixed addr registers (r8, r9). One (r9) is
defined as a hard reg pointer pointer. Honestly, I never saw a target
with such register constraints.
-O0 assumes -fno-omit-frame-pointer. So in -O0 mode we have only *one*
free addr reg for insn which requires *2* of them. That is why the GCC
port crashes on this test. If you add -fomit-frame-pointer, the test
succeeds.
But even if use -fomit-frame-pointer, it is not guaranteed that hard
reg pointer will be substituted by stack pointer. There are many cases
where it is not possible (e.g. in case of alloca usage).
So what can be done, imho. The simplest solution would be preventing
insns with more one memory operand. The more difficult solution would
be permitting two memory one with address pseudo and another one with
stack pointer.
Couldn't we spill the frame pointer? Basically we should be able to compute the
first address into a reg, spill that, do the second (both could require the
frame pointer), spill the frame pointer, reload the first computed address from
the stack, execute the insn and then reload the frame pointer.
Maybe the frame pointer can also be implemented 'virually' in an index register
that you keep updated so that sp + reg
Is the FP. Or frame accesses can use a
Stack slot as FP and the indirect memory
Addressing... (is there an indirect lea?)
Yes, it could be a solution. It just needs some target maintainer
creativity. There are a lot of things (tricks) can be done in
machine-dependent code which would not require RA changes.
Re: Expansion of narrowing math built-ins into power instructions
On Thu, Aug 15, 2019 at 01:47:47PM +0100, Richard Sandiford wrote: > Tejas Joshi writes: > > Hello. > > I just wanted to make sure that I am looking at the correct code here. > > Except for rtl.def where I should be introducing something like > > float_contract (or float_narrow?) and also simplify-rtx.c, breakpoints I like that "float_narrow" name :-) > > set on functions around expr.c, cfgexpand.c where I grep for > > float_truncate/FLOAT_TRUNCATE did not hit. > > Also, in what manner should float_contract/narrow be different from > > float_truncate as both are trying to do similar things? (truncation > > from DF to SF) > > I think the code should instead be a fused addition and truncation, > a bit like FMA is a fused addition and multiplication. Describing it as > a DFmode addition followed by some conversion to SF would still involve > double rounding. How so? It would *mean* there is only single rounding, even! That's the whole point of it. > simplify-rtx.c is probably the most important place to handle it. > It would be easiest to test using the selftests at the end of the file. Segher
Re: Expansion of narrowing math built-ins into power instructions
On Thu, Aug 15, 2019 at 03:29:03PM +0530, Tejas Joshi wrote: > Also, in what manner should float_contract/narrow be different from > float_truncate as both are trying to do similar things? (truncation > from DF to SF) It's just a different name, nothing more, nothing less. Because it is a different name it can not be accidentally generated from actual truncations. Segher
Re: Indirect memory addresses vs. lra
On Thu, Aug 15, 2019 at 02:30:19PM -0400, Vladimir Makarov wrote: > >Couldn't we spill the frame pointer? Basically we should be able to > >compute the first address into a reg, spill that, do the second (both > >could require the frame pointer), spill the frame pointer, reload the > >first computed address from the stack, execute the insn and then reload > >the frame pointer. > > > >Maybe the frame pointer can also be implemented 'virually' in an index > >register that you keep updated so that sp + reg > >Is the FP. Or frame accesses can use a > >Stack slot as FP and the indirect memory > >Addressing... (is there an indirect lea?) > > > Yes, it could be a solution. It just needs some target maintainer > creativity. There are a lot of things (tricks) can be done in > machine-dependent code which would not require RA changes. You can even go as far as not having the hard frame pointer be a machine register at all. In RTL it will still be a reg, but that doesn't mean the machine code you emit should be like that; you can use a special fixed memory location for it, for example. Segher
gcc-7-20190815 is now available
Snapshot gcc-7-20190815 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190815/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch revision 274550 You'll find: gcc-7-20190815.tar.xzComplete GCC SHA256=934c86c020911e9fa63d8131dc75076252712ff541e396d1d29aa401e78017ff SHA1=f149bc4f1a4b20244262e5a994ce9e8a561d7b89 Diffs from 7-20190808 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-7 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Successful builds of GCC 9.2 on Darwin
Successful builds have been made on
i686-darwin{9,10),
powerpc-darwin9
x86_64-darwin{10,11,12,13,14,15,16,17,18}
bootstrapped with GCC (including Ada)
test results are from
https://gcc.gnu.org/ml/gcc-testresults/2019-08/msg01662.html
to
https://gcc.gnu.org/ml/gcc-testresults/2019-08/msg01673.html
and x86_64-darwin18 bootstrapped with clang (no Ada
test results:
https://gcc.gnu.org/ml/gcc-testresults/2019-08/msg01674.html
NOTES
1. *-darwin8 is currently not working with any live branch or trunk
there’s a hope to address this before 9.3
2. anything earlier than darwin8 is going to require considerable
work to build current branches, since the native installed tools do
not meet the minimum requirements for GCC build.
3. some of the build/tests were performed on VMs;
these are noted, and test timeouts should be regarded as
“not significant” there.
Iain
