From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [205.139.110.120]) by sourceware.org (Postfix) with ESMTP id 51CA0388A029 for ; Fri, 3 Apr 2020 18:47:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 51CA0388A029 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-152-XTlwnDD8ONGcECsU-YJg-g-1; Fri, 03 Apr 2020 14:47:46 -0400 X-MC-Unique: XTlwnDD8ONGcECsU-YJg-g-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 7D5A4107ACCA for ; Fri, 3 Apr 2020 18:47:45 +0000 (UTC) Received: from ovpn-113-250.phx2.redhat.com (ovpn-113-250.phx2.redhat.com [10.3.113.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id 50E1C18A85 for ; Fri, 3 Apr 2020 18:47:45 +0000 (UTC) Message-ID: Subject: [committed] Fix m32r target bug exposed by Jakub's cselib.c changes From: Jeff Law Reply-To: law@redhat.com To: gcc-patches List Date: Fri, 03 Apr 2020 12:47:44 -0600 Organization: Red Hat User-Agent: Evolution 3.34.4 (3.34.4-1.fc31) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="=-t5c+Sr5kz9T97CptWh2B" X-Spam-Status: No, score=-26.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Apr 2020 18:47:53 -0000 --=-t5c+Sr5kz9T97CptWh2B Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit va-arg-22.c started failing on the m32r target (-O1 only) after Jakub's recent cselib changes. The m32r port has this pattern: (define_insn "cpymemsi_internal" [(set (mem:BLK (match_operand:SI 0 "register_operand" "r")) ;; destination (mem:BLK (match_operand:SI 1 "register_operand" "r"))) ;; source (use (match_operand:SI 2 "m32r_block_immediate_operand" "J"));; # bytes to move (set (match_operand:SI 3 "register_operand" "=0") (plus:SI (minus (match_dup 2) (const_int 4)) (match_dup 0))) (set (match_operand:SI 4 "register_operand" "=1") (plus:SI (match_dup 1) (match_dup 2))) (clobber (match_scratch:SI 5 "=&r")) ;; temp1 (clobber (match_scratch:SI 6 "=&r"))] ;; temp2 Note how it updates operand0/operand3 and operand1/operand4. In simplest terms it adds the # bytes copied to each operand. When we output the assembly code for the pattern it has some smarts to avoid doing half-word and byte loads to handle residuals -- instead it loads a full word. That's all fine and good, except the loads occur with post-increment addressing so after we're done with the actual memory copies the source pointer can actually point 1, 2 or 3 bytes beyond where it should. To compound the problem we then incorrectly manually adjust the operand to account for residuals resulting in the source pointer pointing 2, 4 or 6 bytes past where it should. In va-arg-22.c, when compiled with -O1, it turns out we want to use the adjusted source pointer in a subsequent insn. AFAICT, cselib didn't discover the equivalence before, but does so now and with the bugs in the m32r port noted above the pointer has the wrong value and all hell breaks loose. This patch fixes the assembly code we generate for cpymemsi_internal. Naturally this fixes va-arg-22.c at -O1. It doesn't fix any of the other long standing failures though. Committing to the trunk, Jeff --=-t5c+Sr5kz9T97CptWh2B Content-Disposition: attachment; filename="P" Content-Transfer-Encoding: base64 Content-Type: text/plain; name="P"; charset="UTF-8" Y29tbWl0IGI5NDlmOGUyYWNiNDkyNzNiMmYwOGVjYWEzYmM3MTI4YmFhYWQ4NTAKQXV0aG9yOiBK ZWZmIExhdyA8bGF3QHJlZGhhdC5jb20+CkRhdGU6ICAgRnJpIEFwciAzIDEyOjQ2OjEzIDIwMjAg LTA2MDAKCiAgICBGaXggdmEtYXJnLTIyLmMgYXQgLU8xIG9uIG0zMnIuCiAgICAKICAgICAgICAg ICAgUFIgcnRsLW9wdGltaXphdGlvbi85MjI2NAogICAgICAgICAgICAqIGNvbmZpZy9tMzJyL20z MnIuYyAobTMycl9vdXRwdXRfYmxvY2tfbW92ZSk6IFByb3Blcmx5IGFjY291bnQgZm9yCiAgICAg ICAgICAgIHBvc3QtaW5jcmVtZW50IGFkZHJlc3Npbmcgb2Ygc291cmNlIG9wZXJhbmRzIGFzIHdl bGwgYXMgcmVzaWR1YWxzCiAgICAgICAgICAgIHdoZW4gY29tcHV0aW5nIGFueSBhZGp1c3RtZW50 cyB0byB0aGUgaW5wdXQgcG9pbnRlci4KCmRpZmYgLS1naXQgYS9nY2MvQ2hhbmdlTG9nIGIvZ2Nj L0NoYW5nZUxvZwppbmRleCA3MDgzYmJiOWNjZS4uZTlkZmE3MWVjMGUgMTAwNjQ0Ci0tLSBhL2dj Yy9DaGFuZ2VMb2cKKysrIGIvZ2NjL0NoYW5nZUxvZwpAQCAtMSwzICsxLDEwIEBACisyMDIwLTA0 LTAzICBKZWZmIExhdyAgPGxhd0ByZWRoYXQuY29tPgorCisJUFIgcnRsLW9wdGltaXphdGlvbi85 MjI2NAorCSogY29uZmlnL20zMnIvbTMyci5jIChtMzJyX291dHB1dF9ibG9ja19tb3ZlKTogUHJv cGVybHkgYWNjb3VudCBmb3IKKwlwb3N0LWluY3JlbWVudCBhZGRyZXNzaW5nIG9mIHNvdXJjZSBv cGVyYW5kcyBhcyB3ZWxsIGFzIHJlc2lkdWFscworCXdoZW4gY29tcHV0aW5nIGFueSBhZGp1c3Rt ZW50cyB0byB0aGUgaW5wdXQgcG9pbnRlci4KKwogMjAyMC0wNC0wMyAgSmFrdWIgSmVsaW5layAg PGpha3ViQHJlZGhhdC5jb20+CiAKIAlQUiB0YXJnZXQvOTQ0NjAKZGlmZiAtLWdpdCBhL2djYy9j b25maWcvbTMyci9tMzJyLmMgYi9nY2MvY29uZmlnL20zMnIvbTMyci5jCmluZGV4IDFjMDE1NjA5 NTI0Li4yN2ZiNDk1ZWQxNyAxMDA2NDQKLS0tIGEvZ2NjL2NvbmZpZy9tMzJyL20zMnIuYworKysg Yi9nY2MvY29uZmlnL20zMnIvbTMyci5jCkBAIC0yNjc2LDcgKzI2NzYsNyBAQCBtMzJyX291dHB1 dF9ibG9ja19tb3ZlIChydHggaW5zbiBBVFRSSUJVVEVfVU5VU0VELCBydHggb3BlcmFuZHNbXSkK IAkgICAgIGRlc3RpbmF0aW9uIHBvaW50ZXIuICAqLwogCSAgaW50IGRzdF9pbmNfYW1vdW50ID0g ZHN0X29mZnNldCArIGJ5dGVzIC0gNDsKIAkgIC8qIFRoZSBzYW1lIGZvciB0aGUgc291cmNlIHBv aW50ZXIuICAqLwotCSAgaW50IHNyY19pbmNfYW1vdW50ID0gYnl0ZXM7CisJICBpbnQgc3JjX2lu Y19hbW91bnQgPSBieXRlcyAtIChnb3RfZXh0cmEgPyA0IDogMCk7CiAJICBpbnQgbGFzdF9zaGlm dDsKIAkgIHJ0eCBteV9vcGVyYW5kc1szXTsKIAo= --=-t5c+Sr5kz9T97CptWh2B--