From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 639 invoked by alias); 1 Feb 2014 16:24:23 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 628 invoked by uid 89); 1 Feb 2014 16:24:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.2 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 01 Feb 2014 16:24:22 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s11GOLaB028095 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 1 Feb 2014 11:24:21 -0500 Received: from oldenburg.str.redhat.com (ovpn-116-39.ams2.redhat.com [10.36.116.39]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s11GOJ50030731 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sat, 1 Feb 2014 11:24:20 -0500 Message-ID: <52ED1FB2.60601@redhat.com> Date: Sat, 01 Feb 2014 16:24:00 -0000 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "Erotavlas_turbo@libero.it" , gcc-help@gcc.gnu.org Subject: Re: Behaviour of GCC with flto probably bug References: <1443552043.5919731391271466620.JavaMail.actor@webmail14> In-Reply-To: <1443552043.5919731391271466620.JavaMail.actor@webmail14> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-02/txt/msg00001.txt.bz2 On 02/01/2014 05:17 PM, Erotavlas_turbo@libero.it wrote: > So is not allowed to compile with one version and flto options and link with > an old version? Yes, this is documented: The current implementation of LTO makes no attempt to generate bytecode that is portable between different types of hosts. The bytecode files are versioned and there is a strict version check, so bytecode files generated in one version of GCC will not work with an older/newer version of GCC. It seems that the version check does not actually work, which is a bug (please report it in Bugzilla). But LTO is really sensitive to compiler and library versions, so this will not solve your original problem. -- Florian Weimer / Red Hat Product Security Team