From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87462 invoked by alias); 18 Oct 2016 09:22:34 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 87419 invoked by uid 89); 18 Oct 2016 09:22:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1992, claim, interest, paper 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; Tue, 18 Oct 2016 09:22:31 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 962D637E71; Tue, 18 Oct 2016 09:22:30 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u9I9MTXU012040; Tue, 18 Oct 2016 05:22:29 -0400 Subject: Re: [PATCH] tilegx-tdep: Correct aliasing errors in `tilegx_analyze_prologue' To: "Maciej W. Rozycki" References: Cc: gdb-patches@sourceware.org From: Pedro Alves Message-ID: <14cb784b-8e4e-572a-7377-21af868510d1@redhat.com> Date: Tue, 18 Oct 2016 09:22:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-10/txt/msg00505.txt.bz2 On 10/18/2016 04:50 AM, Maciej W. Rozycki wrote: >> > >> > Sure, please do ahead. >> > >> > I'd be better if tilegx.h used uint32_t/uint64_t, etc, >> > but that can always be done separately by someone motivated. > The issue there is `tilegx.h' is shared with binutils which have not yet > moved past C89 I believe. Of course the use of `long long' is already > non-C89, however it's been there with some C89 compilers before `stdint.h' > types have been introduced. We could use `bfd_uint64_t' instead, but that > would make `tilegx.h' depend on a BFD header. So it's not an obvious call > and therefore I agree it's best left to someone who has an actual interest > with the target. Yeah, C89 on paper. :-) It's certainly fine to use unadorned uint64_t etc. directly nowadays. Even if the host compiler is so old that it doesn't support those, we have "bfd_stdint.h" to fill the gap: opcodes/aarch64-dis.h:23:#include "bfd_stdint.h" opcodes/nds32-dis.c:30:#include "bfd_stdint.h" opcodes/aarch64-dis.c:22:#include "bfd_stdint.h" ld/elf-hints-local.h:28:#include "bfd_stdint.h" Something like 'grep "u\?int\(8\|16\|32\|64\)_t" -rn' will show many uses of uint32_t, etc. (not bfd_uint*_t) throughout opcodes, bfd, ld, etc. I won't be surprised at all if someone missed adding bfd_stdint.h for some of them and they've been working in practice for a long while. (better than bfd_stdint.h would be to use gnulib for the whole toolchain, not just for gdb, but that's yet another matter.) As I've been suggesting in recent C++11 discussions, IMO, what we claim to support in theory matters significantly less than what we actually support in practice. And in practice, all it matters is which compilers (and their versions), not standards, people care about actually using and supporting. Standards give us guidelines, not final answers. > Committed now, thanks for your review. Thanks. Thanks, Pedro Alves