From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129494 invoked by alias); 3 Sep 2018 13:20:15 -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 129480 invoked by uid 89); 3 Sep 2018 13:20:15 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-24.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=pulling, UD:dk, H*F:D*dk, HTo:U*hainque X-HELO: mail-lj1-f196.google.com Received: from mail-lj1-f196.google.com (HELO mail-lj1-f196.google.com) (209.85.208.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 03 Sep 2018 13:20:13 +0000 Received: by mail-lj1-f196.google.com with SMTP id p6-v6so460446ljc.5 for ; Mon, 03 Sep 2018 06:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rasmusvillemoes.dk; s=google; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=HpsYifLH/0MgUl7ir9uSfr2mL2N8VIzIA0fvVYKW844=; b=CoS98Q7emAzU2MREjcJFmD96YpHIeT/NI8N0PisQ6IYqnYBRzEFqJMXTukeqiWA70e ZtCu1S0f3tTkThitCy9A0/x/6fTuSQPQCSXFsZkIC6jR3OD65c+VfEih8UNLSrnJUisW fCG6MMgcohMQ5KEKR9AyfE16NspuAZDReGiyY= Return-Path: Received: from [172.16.11.40] ([81.216.59.226]) by smtp.gmail.com with ESMTPSA id q73-v6sm3739212lfi.86.2018.09.03.06.20.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 03 Sep 2018 06:20:09 -0700 (PDT) Subject: Re: [PATCH] fixincludes: vxworks: regs.h: Guard include of vxTypesOld.h by !_ASMLANGUAGE To: Olivier Hainque Cc: gcc-patches@gcc.gnu.org, bkorb@gnu.org References: <20180627142715.10534-1-rv@rasmusvillemoes.dk> From: Rasmus Villemoes Message-ID: Date: Mon, 03 Sep 2018 13:20:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2018-09/txt/msg00112.txt.bz2 On 2018-09-03 14:11, Olivier Hainque wrote: > Hi Rasmus, > >> On 27 Jun 2018, at 16:27, Rasmus Villemoes wrote: >> * inclhack.def (AAB_vxworks_regs_vxtypes): Guard include of >> types/vxTypesOld.h by #ifndef _ASMLANGUAGE. >> * fixincl.x: Regenerate. >> --- >> fixincludes/inclhack.def | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def >> index c1f5a13eda4..bac0079b69f 100644 >> --- a/fixincludes/inclhack.def >> +++ b/fixincludes/inclhack.def >> @@ -426,7 +426,9 @@ fix = { >> replace = <<- _EndOfHeader_ >> #ifndef _REGS_H >> #define _REGS_H >> + #ifndef _ASMLANGUAGE >> #include >> + #endif >> #include_next >> #endif >> _EndOfHeader_; > > This will really look puzzling to a reader and would > at least deserve a comment. Hm, yes, that might be a good idea. > How do we not get in assembly the problems we'd get in C > when not including vxTypesOld ? Well, I don't know why types/vxTypesOld.h got shoehorned into the fixinclude regs.h [1]. A better fix would be to remove that #include completely, making the fixinclude regs.h a pure wrapper for vxworks regs.h. However, I was afraid that might break existing C code that has come to rely on "#include " pulling in types/vxTypesOld.h (or any of the headers included from that), and it's not really possible to know if such code exists - other than trying it and waiting for emails to arrive.(*) As I wrote, including the vxworks regs.h (from assembly or C) requires that types/vxCpu.h is already included, because it contains directives such as #if CPU_FAMILY==I960 ... #if CPU_FAMILY==MC680X0 Hence my "fix" relies on the fact that any existing assembly source that includes regs.h must already have arranged for types/vxCpu.h to be included, one way or another. I could add an explicit include of that (maybe just in the _ASMLANGUAGE case), but that could easily cause problems of its own. Now, if one could rely on all existing C code having been through a non-gcc compiler, the same argument could be applied and my above worry (*) would be unfounded, but... [1] There's not much explanation in 74ee6ab5823c . Also, while since fixed, that commit added wrong definitions of UINT8_MAX et al (type promotion issue). So maybe that commit was just a bit hastily added. Rasmus