From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47002 invoked by alias); 10 Apr 2015 07:56:52 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 46990 invoked by uid 89); 10 Apr 2015 07:56:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-lb0-f173.google.com Received: from mail-lb0-f173.google.com (HELO mail-lb0-f173.google.com) (209.85.217.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 10 Apr 2015 07:56:51 +0000 Received: by lbbqq2 with SMTP id qq2so7754485lbb.3 for ; Fri, 10 Apr 2015 00:56:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.112.98.234 with SMTP id el10mr313021lbb.28.1428652608068; Fri, 10 Apr 2015 00:56:48 -0700 (PDT) Received: by 10.152.45.3 with HTTP; Fri, 10 Apr 2015 00:56:48 -0700 (PDT) In-Reply-To: <20150410062812.GQ19273@tucnak.redhat.com> References: <1428607654-16888-1-git-send-email-rep.dot.nop@gmail.com> <20150409194135.GO19273@tucnak.redhat.com> <20150409200929.GP19273@tucnak.redhat.com> <552762BF.6000501@free.fr> <20150410062812.GQ19273@tucnak.redhat.com> Date: Fri, 10 Apr 2015 07:56:00 -0000 Message-ID: Subject: Re: [PATCH] PR target/55143: undefined reference to `c_default_pointer_mode' From: Bernhard Reutner-Fischer To: Jakub Jelinek Cc: Tristan Gingold , GCC Patches , Douglas Rupp Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-04/txt/msg00435.txt.bz2 On 10 April 2015 at 08:28, Jakub Jelinek wrote: > On Fri, Apr 10, 2015 at 07:42:23AM +0200, Tristan Gingold wrote: >> On 09/04/15 22:09, Jakub Jelinek wrote: >> >> > The c_default_pointer_mode is very ugly hack, but guess at least for >> > now it is ok for trunk. >> > >> > Jakub >> >> Could you suggest a better approach ? > > Perhaps a target hook (maybe just a variable in the target hooks)? I leave that to the maintainers to fix properly. The workaround was now committed as r221968 to trunk to unbreak the build of ia64-hp-vms in config-list.mk. thanks,