Re: testsuite under wine
On Tue, Jan 10, 2023 at 9:30 PM Jacob Bachmeyer wrote:
>
> NightStrike wrote:
> > [...]
> > I did another little test to try to better understand your point. I
> > ran a linux native testsuite under a simulator that just sets SIM to "
> > ". This resulted in extra ^M's also, although many tests pass because
> > they're already looking for \r\n to accommodate windows. So I think
> > I've come around to grasp what you've been heroically re-explaining...
> >
> > So if we have to modify every test in the entire testsuite to check
> > for zero or more \r's followed by zero or more \n's, would it be
> > better to add a dg-output-line proc that does this automatically
> > everywhere?
>
> Two problems: first, you need zero-or-more \r and *one*-or-more \n.
> Second, dg-output is not defined as an anchored match, and therefore
> cannot do this automatically.
"or more" \n is valid? That would make the rust bug of \r\r\n\n pass
when I assume it shouldn't.
> > I feel like changing every output pattern test won't be
> > too maintainable. You had mentioned previously modifying ${tool}_load
> > to filter out extra \r's, but I couldn't see where or how to do that.
> >
> > For completeness, setting a random selection of tests to look for
> > \r*\n? worked (this would cover even deprecated systems that only use
> > CR as well as flagging the weird rust case of \r\r\n\n as bad).
>
> Do not worry about classic Mac OS---running DejaGnu on that platform is
> not possible, nor is it possible to run test programs remotely on that
> platform. Classic Mac OS is a pure-GUI system with no command interface
> whatsoever. Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl
> exec(n) command. Due to limitations of the platform, porting Expect to
> classic Mac OS is simply not possible. Any compatibility layer would be
> reasonably expected to translate CR<->LF, if, for example, someone wrote
> a telnet server (and associated POSIX-alike environment) for Mac OS.
>
> The later Mac OS X is a quasi-POSIX mostly compatible with the GNU
> system that uses POSIX line endings. DejaGnu should run normally there.
>
> Are there other systems that used bare CR as end-of-line? If not, the
> correct pattern is therefore {\r*\n} (here written using braces as
> quotes around the pattern).
Maybe none that matter. From
https://en.wikipedia.org/wiki/Newline#Representation:
Commodore 8-bit machines (C64, C128), Acorn BBC, ZX Spectrum, TRS-80,
Apple II series, Oberon, the classic Mac OS, MIT Lisp Machine and OS-9
The article also goes on to mention that OpenVMS and RSX-11 can be
configured to use CR.
[RISC-V] [SIG-toolchain] Meeting will be canceled (Jan 12, 2023)
Hi all, Tomorrow's RISC-V GNU Toolchain meeting will be canceled, since there are few new topics to discuss. The next RISC-V GNU Toolchain meeting is collecting topics. Please let me know if you have any topics want to discuss in the next meeting. BR Jiawei
Re: LRA produces RTL not meeting constraint
Hi Paul,
On Tue, Jan 10, 2023 at 02:39:34PM -0500, Paul Koning via Gcc wrote:
> In pdp11.md I have:
>
> (define_insn_and_split "addhi3"
> [(set (match_operand:HI 0 "nonimmediate_operand" "=rR,rR,Q,Q")
> (plus:HI (match_operand:HI 1 "general_operand" "%0,0,0,0")
>(match_operand:HI 2 "general_operand" "rRLM,Qi,rRLM,Qi")))]
> ""
> "#"
> "reload_completed"
> [(parallel [(set (match_dup 0)
> (plus:HI (match_dup 1) (match_dup 2)))
> (clobber (reg:CC CC_REGNUM))])]
> ""
> [(set_attr "length" "2,4,4,6")])
>
> While compiling libgcc2.c I see this RTL in the .ira dump file:
>
> (insn 49 48 53 5 (set (reg/f:HI 136)
> (plus:HI (reg/f:HI 5 r5)
> (const_int -8 [0xfff8])))
> "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3}
> (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
> (const_int -8 [0xfff8]))
> (nil)))
What hard register was assigned by IRA to r136? It shows this in the
.ira dump file, search for "Disposition:".
> Then in the .reload dump it appears this way:
>
> (insn 49 48 53 5 (set (reg/f:HI 5 r5 [136])
> (plus:HI (reg/f:HI 6 sp)
> (const_int 40 [0x28])))
> "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3}
> (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
> (const_int -8 [0xfff8]))
> (nil)))
>
> which obviously causes an ICE because that RTL doesn't meet the constraints.
Before reload it did not have operands[0] and operands[1] the same,
already?
> This happens only when LRA is used.
>
> I also see this in the .reload file, but I don't know what it means:
>
>Choosing alt 1 in insn 49: (0) rR (1) 0 (2) Qi {addhi3}
It chose alternative 1 in this instruction, which uses constraints rR
for operands[0], a tie to that for operands[1], and Qi for operands[2].
> 1 Non-pseudo reload: reject+=2
> 1 Non input pseudo reload: reject++
> Cycle danger: overall += LRA_MAX_REJECT
> alt=0,overall=609,losers=1,rld_nregs=2
> alt=1: Bad operand -- refuse
> alt=2: Bad operand -- refuse
> alt=3,overall=0,losers=0,rld_nregs=0
This is for the *next* instruction. There is a "Choosing alt" thing
for that right after this. That will be alt 3: 1 and 2 are refused,
0 costs 609, 3 costs 0.
Reading the LRA dumps needs some getting used to ;-)
> Any ideas? I ran into this when trying to make LRA the default for this
> target.
Please show *all* relevant things in the reload dump file? Everything
about insn 49 or any insn added to reload it, for example.
Segher
avx512erintrin.h: uninitialized variable warning (optimized build)
Hi, During GCC 12.2.0 compilation of a file that includes[1] immintrin.h with both code-optimization and uninitialized-variable-warnings enabled, a warning is emitted: /usr/lib/gcc/x86_64-linux-gnu/12/include/avx512erintrin.h:55:20: warning: ‘__W’ is used uninitialized [-Wuninitialized] The minimal repro compilation command appears to be: gcc -O -Wuninitialized -mavx512er -mavx512pf ./numpy/distutils/checks/cpu_avx512_knl.c My question is: does the warning indicate a possible bug that should be reported, or is there a reason that the relevant code[2] does not initialize the variable (for example, for performance reasons)? Thank you, James [1] - https://github.com/numpy/numpy/blob/bb2769e12a8646f3d63097e9464592aa6e20058d/numpy/distutils/checks/cpu_avx512_knl.c#L14 [2] - https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/avx512erintrin.h;h=6b3b679a17675612f45a1090f227012b80b871a6#l54
Re: LRA produces RTL not meeting constraint
> On Jan 11, 2023, at 2:52 PM, Segher Boessenkool
> wrote:
>
> Hi Paul,
>
> On Tue, Jan 10, 2023 at 02:39:34PM -0500, Paul Koning via Gcc wrote:
>> In pdp11.md I have:
>>
>> (define_insn_and_split "addhi3"
>> [(set (match_operand:HI 0 "nonimmediate_operand" "=rR,rR,Q,Q")
>> (plus:HI (match_operand:HI 1 "general_operand" "%0,0,0,0")
>> (match_operand:HI 2 "general_operand" "rRLM,Qi,rRLM,Qi")))]
>> ""
>> "#"
>> "reload_completed"
>> [(parallel [(set (match_dup 0)
>> (plus:HI (match_dup 1) (match_dup 2)))
>>(clobber (reg:CC CC_REGNUM))])]
>> ""
>> [(set_attr "length" "2,4,4,6")])
>>
>> While compiling libgcc2.c I see this RTL in the .ira dump file:
>>
>> (insn 49 48 53 5 (set (reg/f:HI 136)
>>(plus:HI (reg/f:HI 5 r5)
>>(const_int -8 [0xfff8])))
>> "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3}
>> (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
>>(const_int -8 [0xfff8]))
>>(nil)))
>
> What hard register was assigned by IRA to r136? It shows this in the
> .ira dump file, search for "Disposition:".
Disposition:
3:r25 l0 mem 40:r26 l0 4 51:r31 l0 mem 47:r35 l0 mem
42:r45 l0 2 18:r47 l0 mem 38:r52 l0 mem 34:r54 l0 mem
29:r64 l0 2 21:r80 l0 0 15:r88 l0 02:r99 l0 0
19:r102 l0 mem5:r103 l0 mem 31:r110 l0 0 44:r114 l0 0
41:r115 l0 mem 46:r116 l0 0 28:r117 l0 mem 33:r118 l0 0
20:r119 l0 2 14:r120 l0 21:r121 l0 20:r122 l0 mem
9:r123 l0 mem8:r124 l0 mem 55:r125 l0 0 53:r126 l0 mem
54:r129 l0 0 52:r135 l0 0 49:r136 l0 5 48:r137 l0 4
50:r139 l0 0 45:r145 l0 mem 43:r146 l0 0 39:r147 l0 0
36:r148 l0 5 35:r149 l0 4 37:r151 l0 0 32:r157 l0 mem
30:r158 l0 0 27:r159 l0 0 25:r160 l0 mem 26:r161 l0 0
24:r164 l0 0 22:r165 l0 mem 23:r166 l0 0 16:r170 l0 mem
17:r171 l0 0 11:r175 l0 0 13:r176 l0 2 12:r177 l0 2
10:r178 l0 06:r179 l0 mem7:r180 l0 04:r184 l0 0
so R5, if I read that correctly. Which makes sense given that the input
operand is R5.
>
>> Then in the .reload dump it appears this way:
>>
>> (insn 49 48 53 5 (set (reg/f:HI 5 r5 [136])
>>(plus:HI (reg/f:HI 6 sp)
>>(const_int 40 [0x28])))
>> "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3}
>> (expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
>>(const_int -8 [0xfff8]))
>>(nil)))
>>
>> which obviously causes an ICE because that RTL doesn't meet the constraints.
>
> Before reload it did not have operands[0] and operands[1] the same,
> already?
No, and given that it's an addhi3 pattern that is fine before reload. It's
reload that has to make them match because the machine instruction is two
operand.
>> This happens only when LRA is used.
>>
>> I also see this in the .reload file, but I don't know what it means:
>>
>> Choosing alt 1 in insn 49: (0) rR (1) 0 (2) Qi {addhi3}
>
> It chose alternative 1 in this instruction, which uses constraints rR
> for operands[0], a tie to that for operands[1], and Qi for operands[2].
>
>>1 Non-pseudo reload: reject+=2
>>1 Non input pseudo reload: reject++
>>Cycle danger: overall += LRA_MAX_REJECT
>> alt=0,overall=609,losers=1,rld_nregs=2
>>alt=1: Bad operand -- refuse
>>alt=2: Bad operand -- refuse
>> alt=3,overall=0,losers=0,rld_nregs=0
>
> This is for the *next* instruction. There is a "Choosing alt" thing
> for that right after this. That will be alt 3: 1 and 2 are refused,
> 0 costs 609, 3 costs 0.
>
> Reading the LRA dumps needs some getting used to ;-)
Indeed. So does that mean the discussion about insn 48 is the interesting one?
That goes on for a while:
Choosing alt 0 in insn 48: (0) =rR (1) RN {movhi}
1 Spill Non-pseudo into memory: reject+=3
Using memory insn operand 1: reject+=3
1 Non input pseudo reload: reject++
alt=0,overall=13,losers=1,rld_nregs=0
0 Spill pseudo into memory: reject+=3
Using memory insn operand 0: reject+=3
0 Non input pseudo reload: reject++
1 Non-pseudo reload: reject+=2
1 Non input pseudo reload: reject++
alt=1,overall=22,losers=2 -- refuse
0 Spill pseudo into memory: reject+=3
Using memory insn operand 0: reject+=3
0 Non input pseudo reload: reject++
1 Non-pseudo reload: reject+=2
1 Non input pseudo reload: reject++
alt=2,overall=22,losers=2 -- refuse
0 Spill pseudo into memory: reject+=3
Using memory insn operand 0: reject+=3
0 Non input p
Re: LRA produces RTL not meeting constraint
> On Jan 11, 2023, at 7:38 PM, Paul Koning via Gcc wrote:
>
>
>
>> On Jan 11, 2023, at 2:52 PM, Segher Boessenkool
>> wrote:
>>
>> Hi Paul,
>>
>> On Tue, Jan 10, 2023 at 02:39:34PM -0500, Paul Koning via Gcc wrote:
>>> In pdp11.md I have:
>>>
>>> (define_insn_and_split "addhi3"
>>> [(set (match_operand:HI 0 "nonimmediate_operand" "=rR,rR,Q,Q")
>>> (plus:HI (match_operand:HI 1 "general_operand" "%0,0,0,0")
>>> (match_operand:HI 2 "general_operand" "rRLM,Qi,rRLM,Qi")))]
>>> ""
>>> "#"
>>> "reload_completed"
>>> [(parallel [(set (match_dup 0)
>>>(plus:HI (match_dup 1) (match_dup 2)))
>>> (clobber (reg:CC CC_REGNUM))])]
>>> ""
>>> [(set_attr "length" "2,4,4,6")])
>>>
>>> While compiling libgcc2.c I see this RTL in the .ira dump file:
>>>
>>> (insn 49 48 53 5 (set (reg/f:HI 136)
>>> (plus:HI (reg/f:HI 5 r5)
>>> (const_int -8 [0xfff8])))
>>> "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3}
>>>(expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
>>> (const_int -8 [0xfff8]))
>>> (nil)))
>>
>> What hard register was assigned by IRA to r136? It shows this in the
>> .ira dump file, search for "Disposition:".
>
> Disposition:
>3:r25 l0 mem 40:r26 l0 4 51:r31 l0 mem 47:r35 l0 mem
> 42:r45 l0 2 18:r47 l0 mem 38:r52 l0 mem 34:r54 l0 mem
> 29:r64 l0 2 21:r80 l0 0 15:r88 l0 02:r99 l0 0
> 19:r102 l0 mem5:r103 l0 mem 31:r110 l0 0 44:r114 l0 0
> 41:r115 l0 mem 46:r116 l0 0 28:r117 l0 mem 33:r118 l0 0
> 20:r119 l0 2 14:r120 l0 21:r121 l0 20:r122 l0 mem
>9:r123 l0 mem8:r124 l0 mem 55:r125 l0 0 53:r126 l0 mem
> 54:r129 l0 0 52:r135 l0 0 49:r136 l0 5 48:r137 l0 4
> 50:r139 l0 0 45:r145 l0 mem 43:r146 l0 0 39:r147 l0 0
> 36:r148 l0 5 35:r149 l0 4 37:r151 l0 0 32:r157 l0 mem
> 30:r158 l0 0 27:r159 l0 0 25:r160 l0 mem 26:r161 l0 0
> 24:r164 l0 0 22:r165 l0 mem 23:r166 l0 0 16:r170 l0 mem
> 17:r171 l0 0 11:r175 l0 0 13:r176 l0 2 12:r177 l0 2
> 10:r178 l0 06:r179 l0 mem7:r180 l0 04:r184 l0 0
>
> so R5, if I read that correctly. Which makes sense given that the input
> operand is R5.
>>
>>> Then in the .reload dump it appears this way:
>>>
>>> (insn 49 48 53 5 (set (reg/f:HI 5 r5 [136])
>>> (plus:HI (reg/f:HI 6 sp)
>>> (const_int 40 [0x28])))
>>> "../../../../../gcc/libgcc/libgcc2.c":276:4 68 {addhi3}
>>>(expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
>>> (const_int -8 [0xfff8]))
>>> (nil)))
>>>
>>> which obviously causes an ICE because that RTL doesn't meet the constraints.
>>
>> Before reload it did not have operands[0] and operands[1] the same,
>> already?
>
> No, and given that it's an addhi3 pattern that is fine before reload. It's
> reload that has to make them match because the machine instruction is two
> operand.
It occurs to me there's a strange transformation LRA made that I don't
understand, which is the cause of the trouble.
Input:
(insn 49 48 53 5 (set (reg/f:HI 136)
(plus:HI (reg/f:HI 5 r5)
(const_int -8 [0xfff8]))) "_mulvdi3.i":38:4 68 {addhi3}
(expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
(const_int -8 [0xfff8]))
(nil)))
(insn 53 49 50 5 (set (reg/f:HI 137)
(symbol_ref:HI ("__muldi3") [flags 0x41] )) "_mulvdi3.i":38:4 25 {movhi}
(expr_list:REG_EQUIV (symbol_ref:HI ("__muldi3") [flags 0x41]
)
(nil)))
and the IRA "disposition" says it assigned R5 for R136, which is what should
happen given that operand 1 (in the plus:HI) is R5 and the constraint says that
operands 0 and 1 should match.
However, Reload shows that it is given:
(insn 49 48 53 5 (set (reg/f:HI 5 r5 [136])
(plus:HI (reg/f:HI 6 sp)
(const_int 40 [0x28]))) "_mulvdi3.i":38:4 68 {addhi3}
(expr_list:REG_EQUIV (plus:HI (reg/f:HI 5 r5)
(const_int -8 [0xfff8]))
(nil)))
In other words, R136 was replaced by R5 as expected -- but at the same time,
the source operands were replaced by something entirely different. It is a
misguided attempt to eliminate the frame pointer? R5 can be the frame pointer,
if it is needed for that purpose. And replacing an FP reference by an SP
reference is reasonable enough, but such a substitution has to verify that the
constraints are still satisfied. Is that something the target code has to
provide? I'm not aware of it.
paul
Re: testsuite under wine
NightStrike wrote:
On Tue, Jan 10, 2023 at 9:30 PM Jacob Bachmeyer wrote:
NightStrike wrote:
[...]
I did another little test to try to better understand your point. I
ran a linux native testsuite under a simulator that just sets SIM to "
". This resulted in extra ^M's also, although many tests pass because
they're already looking for \r\n to accommodate windows. So I think
I've come around to grasp what you've been heroically re-explaining...
So if we have to modify every test in the entire testsuite to check
for zero or more \r's followed by zero or more \n's, would it be
better to add a dg-output-line proc that does this automatically
everywhere?
Two problems: first, you need zero-or-more \r and *one*-or-more \n.
Second, dg-output is not defined as an anchored match, and therefore
cannot do this automatically.
"or more" \n is valid?
Only if you are ignoring blank lines. Note that you had earlier said
zero-or-more \r and zero-or-more \n, which would be a pattern that can
match with zero length.
That would make the rust bug of \r\r\n\n pass
when I assume it shouldn't.
The pattern that I suggested as correct is zero-or-more \r followed by
exactly one \n. If you are ignoring blank lines in buffered text, but
/not/ in live Expect, you can use {[\r\n]+} (any non-empty sequence of
\r and \n) but this will /not/ work with live Expect, because it can
match a prefix of the intended text.
I feel like changing every output pattern test won't be
too maintainable. You had mentioned previously modifying ${tool}_load
to filter out extra \r's, but I couldn't see where or how to do that.
For completeness, setting a random selection of tests to look for
\r*\n? worked (this would cover even deprecated systems that only use
CR as well as flagging the weird rust case of \r\r\n\n as bad).
Do not worry about classic Mac OS---running DejaGnu on that platform is
not possible, nor is it possible to run test programs remotely on that
platform. Classic Mac OS is a pure-GUI system with no command interface
whatsoever. Even the Mac port of Tcl simply /does/ /not/ /have/ the Tcl
exec(n) command. Due to limitations of the platform, porting Expect to
classic Mac OS is simply not possible. Any compatibility layer would be
reasonably expected to translate CR<->LF, if, for example, someone wrote
a telnet server (and associated POSIX-alike environment) for Mac OS.
The later Mac OS X is a quasi-POSIX mostly compatible with the GNU
system that uses POSIX line endings. DejaGnu should run normally there.
Are there other systems that used bare CR as end-of-line? If not, the
correct pattern is therefore {\r*\n} (here written using braces as
quotes around the pattern).
Maybe none that matter. From
https://en.wikipedia.org/wiki/Newline#Representation:
Commodore 8-bit machines (C64, C128), Acorn BBC, ZX Spectrum, TRS-80,
Apple II series, Oberon, the classic Mac OS, MIT Lisp Machine and OS-9
DejaGnu is not going to run on any of those, and remote testing with any
of those as targets gets ... "interesting" ... very quickly.
Oberon, similarly to classic MacOS simply does not have a command line,
although it /does/ have enough infrastructure that implementing some
kind of line-oriented command interface could be feasible and some
Oberon versions do have network capability. Nonetheless, the entire
Oberon system is written in its own language, so a testsuite for an
Oberon target would be expected to be specially written accordingly.
I already mentioned classic MacOS.
Lisp Machines evaluate similarly to Oberon, using their own language for
all software (in this case, Lisp) with the additional element of being
highly unlikely to be found outside of a computer museum, having never
been common.
OS-9 is interesting, but is an oddball nonfree system with niche uses.
Nonetheless, it does have a shell, so it fits in with the others
mentioned below.
The rest are various 8-bit systems, where some level of remote testing
might be possible over a serial line, but see stty(1) and the icrnl and
inlcr options for that case (the POSIX terminal driver can translate
incoming CR to LF and vice versa).
The article also goes on to mention that OpenVMS and RSX-11 can be
configured to use CR.
Those systems actually store each line as a separate record; the /same/
file can be read with LF or CRLF by simply asking, if I read that
article correctly.
-- Jacob
Re: avx512erintrin.h: uninitialized variable warning (optimized build)
> On 12 Jan 2023, at 00:26, James Addison via Gcc wrote: > > Hi, > > During GCC 12.2.0 compilation of a file that includes[1] immintrin.h > with both code-optimization and uninitialized-variable-warnings > enabled, a warning is emitted: > >/usr/lib/gcc/x86_64-linux-gnu/12/include/avx512erintrin.h:55:20: > warning: ‘__W’ is used uninitialized [-Wuninitialized] > > The minimal repro compilation command appears to be: > >gcc -O -Wuninitialized -mavx512er -mavx512pf > ./numpy/distutils/checks/cpu_avx512_knl.c > > My question is: does the warning indicate a possible bug that should > be reported, or is there a reason that the relevant code[2] does not > initialize the variable (for example, for performance reasons)? See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593, might be the same thing? signature.asc Description: Message signed with OpenPGP
