Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp801025ybz; Wed, 22 Apr 2020 08:14:21 -0700 (PDT) X-Google-Smtp-Source: APiQypI0vXH4EjtxE6z1OsW7Qn5vYtDGso17qdzVhkubEUvTt6C0qub4FvxWuWUx65z08kyiMIeJ X-Received: by 2002:a17:906:b217:: with SMTP id p23mr25637178ejz.136.1587568461267; Wed, 22 Apr 2020 08:14:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587568461; cv=none; d=google.com; s=arc-20160816; b=ONUAEb2ff/yoURWeBkgojHCIwyo7Mk43K+F95YXUEAe/1ZRo+eyziDfOgUi5uVxs0t vBWErEWWctrHpuk57cF1JDj3Jf3icOD3lx/CB1QvXJcoFG9CTZd9EdjLEnIQvTvKNlCe S5frGO3nVi1GUzqhx1t8BDPJjqHKcP0AfAFkisJXrvvQiUv8OjPcDiMVdhpxsZq6eWfB M3YAKOIWpygQl/7XNNKAHnQj96+vZzankyR5K7YdndR38+V50nLxu01CfVUVBfSYwc1f +uLHnZ8qGivm9I9rFQyi+N8TN+lH/+TUrM+pTdibAEaiAIGAgI42PBAUdnTQLTluShoU 69Og== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=9dasqayWLRMndR5wILHTVq7V8XkEah46KuqfQueNgbY=; b=S4I6O91DHhsAqq2AfvVt1Ua8uqA+3BFVUXhn+Qr8PQ9m9cGFID0ey2NEC7HOG6mLQq aNGrXXJpUZby4FlMAFpsT2O9KIAY9N1xspiQW86aO3fA7BvSv9t3UMID9piYfMeGeSxi sH5a3qLmv+MdFgf3BsMSeP18zKBzu35hALY9vZkqKWOTLBOivPMfWsXJnd9WQg0dxO7I WGvlhwHgGv0HbggQkRi8VmxX7ae3wqFwUTZssJejpbgGsMOdX8hR5EX4uzzceA9nZfOj rPYiqZnHIRQv+pRPsGe/1ypvRf1v8cuwyreG5DMYROtPVLmuqi6rITVUkDkHVZGqW4hO jB6Q== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g12si3812898ejw.314.2020.04.22.08.13.47; Wed, 22 Apr 2020 08:14:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726450AbgDVPGj (ORCPT + 99 others); Wed, 22 Apr 2020 11:06:39 -0400 Received: from mx2.suse.de ([195.135.220.15]:60022 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726402AbgDVPGj (ORCPT ); Wed, 22 Apr 2020 11:06:39 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 80FE4AFC6; Wed, 22 Apr 2020 15:06:36 +0000 (UTC) Date: Wed, 22 Apr 2020 15:06:36 +0000 (UTC) From: Michael Matz To: =?ISO-8859-15?Q?Martin_Li=A8ka?= cc: Jakub Jelinek , Borislav Petkov , Peter Zijlstra , Nick Desaulniers , Sergei Trofimovich , LKML , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Andy Lutomirski , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , clang-built-linux Subject: Re: [PATCH v2] x86: fix early boot crash on gcc-10 In-Reply-To: <20a91f2e-0f25-8dba-e441-3233cc1ef398@suse.cz> Message-ID: References: <20200417085859.GU2424@tucnak> <20200417090909.GC7322@zn.tnic> <20200417190607.GY2424@tucnak> <20200422102309.GA26846@zn.tnic> <20200422114007.GC20730@hirez.programming.kicks-ass.net> <20200422134924.GB26846@zn.tnic> <20200422135531.GM2424@tucnak> <20a91f2e-0f25-8dba-e441-3233cc1ef398@suse.cz> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="-1609957120-295431784-1587567996=:11688" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---1609957120-295431784-1587567996=:11688 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8BIT Hello, On Wed, 22 Apr 2020, Martin Liška wrote: > One possible solution can be usage of a GCC pragma that will disable the > tail-call optimization: > > $ cat tail.c > int foo(int); > > #pragma GCC push_options > #pragma GCC optimize("-fno-optimize-sibling-calls") As we determined upthread (and the reason why we even still have this thread): the optimize attribute (and pragma) reset flags from the command line (the case in point was -fno-omit-frame-pointer). So, that's not a solution for now. > And as I talked to Boris, I would recommend to come up with a > "configure" check that a compiler does not optimize the key code > sequence: Right. I think the traditional asm (i.e. one without operands) is good enough for the forseeable future from GCCs side: it relies on documented behaviour of traditional asms, and hence would be very hard to change. Ciao, Michael. ---1609957120-295431784-1587567996=:11688--