From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14994 invoked by alias); 22 Nov 2015 14:39:59 -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 14982 invoked by uid 89); 22 Nov 2015 14:39:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Sun, 22 Nov 2015 14:39:57 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id 3F1C735230DC; Sun, 22 Nov 2015 15:39:54 +0100 (CET) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vbkruinCBGwk; Sun, 22 Nov 2015 15:39:54 +0100 (CET) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 1447535230C9; Sun, 22 Nov 2015 15:39:53 +0100 (CET) From: Eric Botcazou To: Jan Hubicka Cc: gcc-patches@gcc.gnu.org Subject: Re: Fix lto-symtab ICE during Ada LTO bootstrap Date: Sun, 22 Nov 2015 14:46:00 -0000 Message-ID: <1690140.OfB3ATH0FC@polaris> User-Agent: KMail/4.14.9 (Linux/3.16.7-29-desktop; KDE/4.14.9; x86_64; ; ) In-Reply-To: <20151121182122.GB23225@kam.mff.cuni.cz> References: <20151121182122.GB23225@kam.mff.cuni.cz> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-SW-Source: 2015-11/txt/msg02608.txt.bz2 > this patch fixes an ICE seen with Ada LTO bootstrap in reporting type > mismatches and it also makes us to stop complaining about C++ ODR > violation. The warnings are however correct. I looked at few: >=20 > ../../libiberty/xstrerror.c:40:14: warning: type of =EF=BF=BDstrerror=EF= =BF=BD does not > match original declaration [-Wlto-type-mismatch] extern char *strerror > (int); > ^ >=20 > ../../gcc/ada/s-os_lib.adb:1007:16: note: return value type mismatch > function strerror (errnum : Integer) return System.Address; > ^ >=20 > ../../gcc/ada/s-os_lib.adb:1007:16: note: > =EF=BF=BDsystem__os_lib__errno_message__strerror=EF=BF=BD was previously = declared here >=20 > Here we have function returning pointer WRT function returning integer: This one is on purpose and cannot be easily changed. Pointer types (or acc= ess=20 types as called in Ada) are avoided as much as possible in the runtime beca= use=20 they drag the accessibility machinery, which is the machinery present in th= e=20 language to eliminate dangling references and is heavy; so they are usually= =20 imported as System.Address instead. > : warning: type of =EF=BF=BD__builtin_strlen=EF=BF=BD does not = match original > declaration [-Wlto-type-mismatch] ../../gcc/ada/osint.adb:422:19: note: > return value type mismatch > ../../gcc/ada/osint.adb:422:19: note: type =EF=BF=BDinteger=EF=BF=BD shou= ld match type =EF=BF=BDlong > unsigned int=EF=BF=BD >=20 > Here the signedness of integer does not match: Yes, it's clearly incorrect on the Ada side and should be fixed in osint.ad= b. > ../../gcc/ada/s-os_lib.ads:1053:4: warning: type of > =EF=BF=BDsystem__os_lib__directory_separator=EF=BF=BD does not match orig= inal declaration > [-Wlto-type-mismatch] Directory_Separator : constant Character; > ^ >=20 > ../../gcc/ada/adaint.c:225:6: note: type =EF=BF=BDchar=EF=BF=BD should ma= tch type =EF=BF=BDvolatile > character=EF=BF=BD char __gnat_dir_separator =3D DIR_SEPARATOR; > ^ >=20 > Here we get difference in signedness and volatility: The signedness issue for Character is known and we plan to address it; the= =20 volatility issue was overlooked but looks fixable too. > All those types will lead to wrong code if ever written to same memory > location because of TBAA. Eric, does Ada need all this types to be TBAA > compatible? If so, we need to implement more strict globbing as we did for > Fortran and we probably finally need to make the globbing aware of > languages involved (we definitly don't want to glob pointers and integers > for C/C++ programs) I think that we can fix all the problems on the Ada side except for the=20 pointer/System.Address duality (which can be even more problematic on=20 architectures that use different calling conventions for them). > Eric, it would be great to have a stand alone testcases in style of > gcc/testsuite/gfortran.dg/lto/bind_c-* > which stores and reads the same memory location in same alias set and thus > trigger the undefined behvaiour. OK, I'll think about that, thanks. --=20 Eric Botcazou