From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97818 invoked by alias); 18 Oct 2019 12:10:13 -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 97809 invoked by uid 89); 18 Oct 2019 12:10:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 spammy=wired X-HELO: mail.inka.de Received: from quechua.inka.de (HELO mail.inka.de) (193.197.184.2) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 18 Oct 2019 12:10:11 +0000 Received: from raven.inka.de (uucp@[127.0.0.1]) by mail.inka.de with uucp (rmailwrap 0.5) id 1iLR56-0002H3-Kd; Fri, 18 Oct 2019 14:10:08 +0200 Received: by raven.inka.de (Postfix, from userid 1000) id 79D1312016E; Fri, 18 Oct 2019 14:07:37 +0200 (CEST) Date: Fri, 18 Oct 2019 12:10:00 -0000 From: Josef Wolf To: gcc-help@gcc.gnu.org Subject: Re: Crash when cross compiling for ARM with GCC-8-2-0 and -ftree-loop-distribute-patterns Message-ID: <20191018120737.GH11171@raven.inka.de> Mail-Followup-To: Josef Wolf , gcc-help@gcc.gnu.org References: <20191016131759.GA11171@raven.inka.de> <5b75d9aa-9f33-2ec6-ff46-713b113b3539@gmail.com> <20191017113157.GC11171@raven.inka.de> <20191017140423.GD11171@raven.inka.de> <20191018085314.GE11171@raven.inka.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2019-10/txt/msg00078.txt.bz2 On Fri, Oct 18, 2019 at 11:25:53AM +0100, Richard Earnshaw (lists) wrote: > > Ah, yes. Looking at some libc sources it puts an explicit optimization > attribute onto the memset (and similar mem... functions) to disable > -ftree-loop-distribute-patterns for such functions. So something like > > void * > __attribute__ ((__optimize__ ("-fno-tree-loop-distribute-patterns"))) > memset (void *s, int c, size_t n) > { > int i; > for (i=0; i ((char *)s)[i] = c; > > return s; > } > > Though, of course, it's wrapped up in a macro to make it look a bit prettier > ;-) Thanks, Richard! This finally fixes the crashes! But Umm... Honestly, this solution looks pretty wired to me. When the compiler decides to replace code by a call to some function, shouldn't it make sure not to replace _all_ occurences of such code (and thus the final implementation of it) also? To me, this looks as if the compiler failed to implement the base case of the recursion. Instead, the user is expected to specify obscure attributes. What if the next -fsuper-duper-optimization flag again starts doing such replacements? > This is just one of those gotchas that you have to be aware of when > implementing the standard library. I am not implementing the standard library. I am just trying to get rid of it. I need just a couple of functions from the stdlib, and I was happy with simple/lightwight re-implementations of those functions for decades. -- Josef Wolf jw@raven.inka.de