Re: Symbol + Constant output.
On Sun, Nov 1, 2020 at 2:04 PM Iain Sandoe wrote:
>
> Hi Uros,
>
> I was looking into the test fails for the new keylocker-* testcases.
>
> Many are because of missing “_” (which seems to happen more often than
> not). These I can fix trivially.
>
> But some are because we have:
>
> name+constant(%rip) being emitted on Linux
>
> and
>
> constant+name(%rip) being emitted on Darwin.
>
> ——
>
> The reason is that Darwin is always PIC and so outputs
> (const:DI (plus:DI (symbol_ref:DI ("h2") [flags 0x2] 0x755e3c60 h2>)
> (const_int 16 [0x10])))
>
> using - gcc/i386.c:output_pic_addr_const
>
> Linux outputs the same thing
>
> using - gcc/final.c:output_addr_const
>
>
>
> for the PLUS case final.c says:
>
>/* Some assemblers need integer constants to appear last (eg masm). */
>
>
> for the PLUS case i386.c says:
>
>/* Some assemblers need integer constants to appear first. */
>
> =
>
> So .. I could make a really tedious patch to match the different forms in the
> keylocker tests for Darwin ..
>
> .. but ISTM that maybe one of those comments is wrong / out of date - and the
> right thing would be to fix that.
I don't know which assemblers are referred to in the comment, but gas
accepts both forms:
mov k2+16(%rip), %eax
mov 16+k2(%rip), %eax
> Any insight welcome,
Maybe those scan-asm regexp are too strict and should be relaxed a
bit. Please resolve this issue with the author (CC'd).
Uros.
gcc/DATESTAMP not updated any longer
I noticed that gcc/DATESTAMP isn't updated any longer after this Friday. I doubt this is intentional... Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: gcc/DATESTAMP not updated any longer
On Mon, Nov 02, 2020 at 08:14:22PM +0100, Rainer Orth wrote: > I noticed that gcc/DATESTAMP isn't updated any longer after this > Friday. I doubt this is intentional... === Working on: master === branch pulled and checked out 74 revisions since last Daily bump writing to ./libstdc++-v3/ChangeLog writing to ./gcc/ChangeLog writing to ./gcc/testsuite/ChangeLog writing to ./gcc/testsuite/ChangeLog writing to ./gcc/cp/ChangeLog writing to ./gcc/testsuite/ChangeLog writing to ./gcc/ChangeLog writing to ./gcc/testsuite/ChangeLog writing to ./gcc/ChangeLog writing to ./libgcc/ChangeLog writing to ./gcc/ChangeLog writing to ./gcc/ChangeLog writing to ./gcc/testsuite/ChangeLog empty group "()" found:"* tree-vect-slp.c (): Update backedges in single-node cycles." Traceback (most recent call last): File "../gcc-changelog/git_update_version.py", line 143, in update_current_branch() File "../gcc-changelog/git_update_version.py", line 103, in update_current_branch not args.dry_mode) File "../gcc-changelog/git_update_version.py", line 39, in prepend_to_changelog_files raise AssertionError() AssertionError That's the Richard's commit that slipped through the verification, but upsets ChangeLog generation. Jakub
Re: gcc/DATESTAMP not updated any longer
On 11/2/20 8:43 PM, Jakub Jelinek wrote:
On Mon, Nov 02, 2020 at 08:14:22PM +0100, Rainer Orth wrote:
I noticed that gcc/DATESTAMP isn't updated any longer after this
Friday. I doubt this is intentional...
=== Working on: master ===
branch pulled and checked out
74 revisions since last Daily bump
writing to ./libstdc++-v3/ChangeLog
writing to ./gcc/ChangeLog
writing to ./gcc/testsuite/ChangeLog
writing to ./gcc/testsuite/ChangeLog
writing to ./gcc/cp/ChangeLog
writing to ./gcc/testsuite/ChangeLog
writing to ./gcc/ChangeLog
writing to ./gcc/testsuite/ChangeLog
writing to ./gcc/ChangeLog
writing to ./libgcc/ChangeLog
writing to ./gcc/ChangeLog
writing to ./gcc/ChangeLog
writing to ./gcc/testsuite/ChangeLog
empty group "()" found:" * tree-vect-slp.c (): Update backedges in single-node
cycles."
Traceback (most recent call last):
File "../gcc-changelog/git_update_version.py", line 143, in
update_current_branch()
File "../gcc-changelog/git_update_version.py", line 103, in
update_current_branch
not args.dry_mode)
File "../gcc-changelog/git_update_version.py", line 39, in
prepend_to_changelog_files
raise AssertionError()
AssertionError
That's the Richard's commit that slipped through the verification, but
upsets ChangeLog generation.
Jakub
Whoops! Sorry for that.
Please run the script manually with the following patch:
diff --git a/contrib/gcc-changelog/git_commit.py
b/contrib/gcc-changelog/git_commit.py
index 1d0860cddd8..70cd2c5c2b3 100755
--- a/contrib/gcc-changelog/git_commit.py
+++ b/contrib/gcc-changelog/git_commit.py
@@ -465,7 +465,7 @@ class GitCommit:
for needle in ('()', '[]', '<>'):
if ' ' + needle in parts[0]:
msg = f'empty group "{needle}" found'
-self.errors.append(Error(msg, line))
+# self.errors.append(Error(msg, line))
last_entry.lines.append(line)
else:
if last_entry.is_empty:
Then all should be fine as new error should not appear.
Thanks,
Martin
Re: gcc/DATESTAMP not updated any longer
On Mon, Nov 02, 2020 at 09:37:56PM +0100, Martin Liška wrote:
> > writing to ./gcc/testsuite/ChangeLog
> > empty group "()" found:"* tree-vect-slp.c (): Update backedges in
> > single-node cycles."
> > Traceback (most recent call last):
> >File "../gcc-changelog/git_update_version.py", line 143, in
> > update_current_branch()
> >File "../gcc-changelog/git_update_version.py", line 103, in
> > update_current_branch
> > not args.dry_mode)
> >File "../gcc-changelog/git_update_version.py", line 39, in
> > prepend_to_changelog_files
> > raise AssertionError()
> > AssertionError
> >
> > That's the Richard's commit that slipped through the verification, but
> > upsets ChangeLog generation.
>
> Whoops! Sorry for that.
>
> Please run the script manually with the following patch:
>
> diff --git a/contrib/gcc-changelog/git_commit.py
> b/contrib/gcc-changelog/git_commit.py
> index 1d0860cddd8..70cd2c5c2b3 100755
> --- a/contrib/gcc-changelog/git_commit.py
> +++ b/contrib/gcc-changelog/git_commit.py
> @@ -465,7 +465,7 @@ class GitCommit:
> for needle in ('()', '[]', '<>'):
> if ' ' + needle in parts[0]:
> msg = f'empty group "{needle}" found'
> -self.errors.append(Error(msg, line))
> +# self.errors.append(Error(msg,
> line))
> last_entry.lines.append(line)
> else:
> if last_entry.is_empty:
>
> Then all should be fine as new error should not appear.
It isn't that easy (because update_version_git checks the gcc trunk and
so I had to insert a sh invocation in which I've tweaked it), but it worked,
thanks. But something is really wrong with the hooks, as the gcc-cvs mail
for the trunk daily bump wasn't sent again (r10, r9 and r8 changes did).
Jakub
Mail delivery failed: returning message to sender
This message was created automatically by mail delivery software. A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: gcc@gcc.gnu.org host gcc.gnu.org [8.43.85.97] SMTP error from remote mail server after end of data: 550 5.7.1 Blocked by SpamAssassin Reporting-MTA: dns; server.pittieinnovations.com Action: failed Final-Recipient: rfc822;gcc@gcc.gnu.org Status: 5.0.0 Remote-MTA: dns; gcc.gnu.org Diagnostic-Code: smtp; 550 5.7.1 Blocked by SpamAssassin
Wrong insn scheduled by Sched1 pass
Hi, From origin insn seqs, I think the insn 'r500=unspec[r100] 300’ is in Good place because of the bypass of my pipeline description, it is not needed to schedule. But the result of Sched1 pass schedule it, I check the souce code of sched-rgn.c & haifa-sched.c From compute_priorities() I think the dependence of insn consider dependence of register Or memory first, but do not include any cpu resource conflict with defined by ‘define_cpu_unit' Is there any way to control my case ? Or my description of pipeline is not good ? My gcc version is 8.1.0 insn seqs from Origin: r80=VAL r100=unspec[r80] 200 r81=VAL r101=unspec[r81] 200 r500=unspec[r100] 300 r82=VAL r102=unspec[r82] 200 r501=unspec[r101] 300 r502=unspec[r102] 300 My pipeline like as: (define_cpu_unit "ex1, ex2” "pipe_name") (define_cpu_unit “tx” "pipe_name") Insn unspec 200 as T1, latency is 12, use ex1,2 Insn unspec 300 as T2, latency is 12, use tx (define_bypass 0 “T1” "T2") insn seqs after Sched1: r80=VAL r81=VAL r82=VAL r100=unspec[r80] 200 r101=unspec[r81] 200 r102=unspec[r82] 200 r500=unspec[r100] 300 r501=unspec[r101] 300 r502=unspec[r102] 300 Jojo
