From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DAA693851C13; Sat, 13 Jun 2020 19:46:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DAA693851C13 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1592077571; bh=oh17IYbT4+rKVRlZYPAIAjA1q9P0/GKwHWGwojcOBto=; h=From:To:Subject:Date:From; b=hqMjRJqL4syU/l3w5atzlHxYTAUuwWaJbSlg1S6U2jcnkV7BrtpMuBYoVcDLpdR7b 2q7PxiJWLggs7JSlS3KiBgkL46u57hepHrEULtZQgiIWED7WK711hZbngL7onyEmip O5BqHuE5gw9ae4PFMduEtK2XhNBTzPJ/hGOVjX6I= From: "aerofeev at commvault dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c/95666] New: gcc 9.3.0 generates incorrect code with -O3 on HP-UX IA64 Date: Sat, 13 Jun 2020 19:46:11 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c X-Bugzilla-Version: 9.3.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: aerofeev at commvault dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone attachments.created Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jun 2020 19:46:12 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D95666 Bug ID: 95666 Summary: gcc 9.3.0 generates incorrect code with -O3 on HP-UX IA64 Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: aerofeev at commvault dot com Target Milestone: --- Created attachment 48726 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D48726&action=3Dedit Source code, assembly and compiled test program Hi, While upgrading our compilers from gcc-4.9.3 to gcc-9.3.0 we have found that openssl started crashing with the following stack: #0 0x40000000002bbf00:1 in x509_name_ex_d2i+0x641 () #1 0x400000000026bd40:0 in ASN1_item_ex_d2i+0x8c0 () #2 0x400000000026eea0:0 in asn1_template_noexp_d2i+0xd00 () #3 0x400000000026e110:0 in asn1_template_ex_d2i+0x590 () #4 0x400000000026d340:0 in ASN1_item_ex_d2i+0x1ec0 () #5 0x400000000026eea0:0 in asn1_template_noexp_d2i+0xd00 () #6 0x400000000026e110:0 in asn1_template_ex_d2i+0x590 () #7 0x400000000026d340:0 in ASN1_item_ex_d2i+0x1ec0 () #8 0x400000000026b330:0 in ASN1_item_d2i+0x110 () #9 0x40000000002c14c0:0 in d2i_X509+0x80 () #10 0x40000000003946b0:0 in PEM_ASN1_read_bio+0xf0 () #11 0x40000000001f9610:0 in PEM_read_bio_X509+0x50 () The stack by itself is not very relevant to this report, I'm mentioning it = here only in case if someone else runs into the same issue and tries googling the stack. The real issue lies in another file, stack.c where a function called sk_insert() corrupts OpenSSL's struct STACK by inserting a new element into STACK::data[] array at incorrect location. The corruption is caused by gcc producing incorrect assembly for the body of sk_insert() with -O3. The purpose of sk_insert(struct STACK *st, void *data, int loc) is to inser= t a new element "data" into st->data[] array at the specified location "loc". If necessary, sk_insert() can reallocate st->data[] and can shift elements in = the array to free up the space for the new element, but all of that code is not what triggers the bug. It's the simplest insertion of a new element into em= pty preallocated array at location 0 where things break, and the element ends up being inserted at location 1 instead. Regretfully, I couldn't trim the reallocation piece and the piece that moves existing elements from the function, because without them the assembly chan= ges, and the bug disappears. I have extracted sk_insert() into a separate file stack.c (attached to this report), removed some of the fat and constructed a test case demonstrating = how the code puts first element at location st->data[1] instead of location st->data[0]. If compiled with -O2, the test program will produce a single "OK" word. If compiled with -O3, the post-insertion checks yield these messages: Bad st.data[0]=3D0000000000000000 (87fffffffffff228 expected) Bad st.data[1]=3D87fffffffffff228 (0 expected) I have reviewed the assembly code and found that at line 101 r41 is incorre= ctly incremented after having been set to st->num at line 88. Later at line 133 = the value of r41 is assigned to r15. r15 is then multiplied by 8 (size of a sin= gle element in st->data[]) and is added to st->data. Finally the new element is assigned to the location pointed to by r15 at line 152. Net result is that instead of storing new element at location st->data[0], the code stores it = at location st->data[0+1]. Like I've said, the issue disappears if the code is compiled with -O2. I am= not confident however that it's related to the optimization level at all. Any change to sk_insert(), sometimes as subtle as a simple printf() or removal = of loc<0 alters assembly enough to make the bug go away. Please advise on whether this is something known and what other information= I can provide to help troubleshoot the problem.=