From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from fx306.security-mail.net (smtpout30.security-mail.net [85.31.212.36]) by sourceware.org (Postfix) with ESMTPS id A20AB3858CDA for ; Thu, 10 Nov 2022 14:08:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A20AB3858CDA Authentication-Results: sourceware.org; dmarc=fail (p=quarantine dis=none) header.from=kalrayinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kalray.eu Received: from localhost (fx306.security-mail.net [127.0.0.1]) by fx306.security-mail.net (Postfix) with ESMTP id 3B0DB3118E7 for ; Thu, 10 Nov 2022 15:08:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kalrayinc.com; s=sec-sig-email; t=1668089328; bh=kYIlVSOMDl70ylUQ5JFcy7S4xcMwTyzubkrrn+cIY70=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=WeixIooWxzffEXjQmirKFwStd90/o2JUHmESvG/HyRj3LuIGD0UUNdZG/ce5AfKDM KIxxvYdHNdrha4yvGwb2+ibnrka1lv88VcCzcAPu7lUeiVuG5xUtg6QXvqf4rbo7IG tYotWPw0hGE8nUHM7HkL0dBWyahvXhhfM+QKy2gI= Received: from fx306 (fx306.security-mail.net [127.0.0.1]) by fx306.security-mail.net (Postfix) with ESMTP id 12D29311836; Thu, 10 Nov 2022 15:08:48 +0100 (CET) Received: from zimbra2.kalray.eu (unknown [217.181.231.53]) by fx306.security-mail.net (Postfix) with ESMTPS id 7D55731175A; Thu, 10 Nov 2022 15:08:47 +0100 (CET) Received: from zimbra2.kalray.eu (localhost [127.0.0.1]) by zimbra2.kalray.eu (Postfix) with ESMTPS id 5D77F27E031D; Thu, 10 Nov 2022 15:08:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zimbra2.kalray.eu (Postfix) with ESMTP id 4496627E0322; Thu, 10 Nov 2022 15:08:47 +0100 (CET) Received: from zimbra2.kalray.eu ([127.0.0.1]) by localhost (zimbra2.kalray.eu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OWDLnIuAUBLY; Thu, 10 Nov 2022 15:08:47 +0100 (CET) Received: from localhost (unknown [192.168.37.51]) by zimbra2.kalray.eu (Postfix) with ESMTPSA id 273E027E031D; Thu, 10 Nov 2022 15:08:47 +0100 (CET) X-Virus-Scanned: E-securemail Secumail-id: <3036.636d05ef.7bbd3.0> DKIM-Filter: OpenDKIM Filter v2.10.3 zimbra2.kalray.eu 4496627E0322 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kalrayinc.com; s=4F334102-7B72-11EB-A74E-42D0B9747555; t=1668089327; bh=CqAgIKOlPZ7eQUZ/lhC+6baZKYqcC7P6ahBAS7ewibk=; h=Date:From:To:Message-ID:MIME-Version; b=MmZUwVI2riXpFzPB9TtlVqF+BLicxiV+MQQ9J8VdJPqIxGlgNOk/9z2AisqTL6qiG FhLL+pvKyMvlUREuCh9ErlOuyX+OIlb/kl9xZbt1xwOwvXWaTxhn9y0rdQ+B9cjmwp L+hwbqGyag10XZw3tsLrtAXYz5hU7cVnGFv7eJ5SeE3UO2yjfDQreciL5Tzt5Vttdx xgpy17IasRngTpg7SX8fbrzmZnnPRzDDzOZp+Br2DmPzZCkXQyQhPtSkwbv4t9l17t 075cG83kC7P0wOnDwLaHS804nJ9okWO4hQ64xlD58/IZJmWMTClw6lJNVbJCQND8Tr ApJarJUHgbb5A== Date: Thu, 10 Nov 2022 15:08:38 +0100 From: Paul Iannetta To: Georg-Johann Lay Cc: Jason Merrill , gcc-patches@gcc.gnu.org Subject: Re: [PATCH v3] c++: parser - Support for target address spaces in C++ Message-ID: <20221110140838.7uupbxeretumhugk@ws2202.lin.mbt.kalray.eu> References: <20221013160227.sdlv6yaw5gr4zcvd@ws2202.lin.mbt.kalray.eu> <20221013215643.o2bymrmffwbtuppu@ws2202.lin.mbt.kalray.eu> <4026cae9-e371-a2ee-2b36-7abc9224afa1@redhat.com> <20221018073731.wj2expjfmk5uhmp3@ws2202.lin.mbt.kalray.eu> <07d4c9ba-594a-d3f8-3df3-5ef5d18a6e97@redhat.com> <20221018170135.zpkmyebmpcvqx7ky@ws2202.lin.mbt.kalray.eu> <20221026071837.l3de5hkxujvqqztr@ws2202.lin.mbt.kalray.eu> <49b9d82e-3252-9e58-f064-b74f059d8b7d@gjlay.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <49b9d82e-3252-9e58-f064-b74f059d8b7d@gjlay.de> User-Agent: NeoMutt/20171215 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-ALTERMIMEV2_out: done X-Spam-Status: No, score=-4.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,KAM_ASCII_DIVIDERS,KAM_SHORT,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Nov 03, 2022 at 02:38:39PM +0100, Georg-Johann Lay wrote: > > [PATCH v3] c++: parser - Support for target address spaces in C++ > > First of all, it is great news that GCC is going to implement named address > spaces for C++. > > I have some questions: > > 1. How is name-mangling going to work? > ====================================== > > Clang supports address spaces in C++, and for address-space 1 it does > generate code like the following: > > #define __flash __attribute__((__address_space__(1))) > > char get_p (const __flash char *p) > { > return *p; > } > > > _Z5get_pPU3AS1Kc: > ... > > I.e. address-space 1 is mangled as "AS1". > > (Notice that Clang's attribute actually works like a qualifier here, one > could not get this to work with GCC attributes.) > Currently, the __address_space__ attribute does not exist in GCC, and the definition of address-spaces as well as how they are laid-out can only modified in the back-end. I agree that this is a convenient attribute to define address-spaces on the fly, but this lacks the flexibility of specifying which address-spaces are subsets of others and how they should be promoted. The mangling will be done with the extended qualifiers extension, for example, your example would be mangled into "_Z5get_pPU7__flashKc". > > 2. Will it work with compound literals? > ======================================= > > Currently, the following C code works for target avr: > > const __flash char *pHallo = (const __flash char[]) { "Hallo" }; > > This is a pointer in RAM (AS0) that holds the address of a string in flash > (AS1) and is initialized with that address. Unfortunately, this does not > work locally: > > const __flash char* get_hallo (void) > { > [static] const __flash char *p2 = (const __flash char[]) { "Hallo2" }; > return p2; > } > > foo.c: In function 'get_hallo': > foo.c: error: compound literal qualified by address-space qualifier > > Is there any way to make this work now? Would be great! > Currently, I implement the same restrictions as the C front-end, but I think that this restriction could be lifted. > > 3. Will TARGET_ADDR_SPACE_DIAGNOSE_USAGE still work? > ==================================================== > > Currently there is target hook TARGET_ADDR_SPACE_DIAGNOSE_USAGE. > I did not see it in your patches, so maybe I just missed it? See > https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gccint/Named-Address-Spaces.html#index-TARGET_005fADDR_005fSPACE_005fDIAGNOSE_005fUSAGE > That was a point I overlooked in my previous patch. This will be in my new revision where I also add implicit conversion between address spaces and also expose TARGET_ADDR_SPACE_CONVERT. > > 4. Will it be possible to put C++ virtual tables in ASs, and how? > ================================================================= > Currently, I do not allow the declaration of instances of classes in an address space, mainly to not have to cope with the handling of the this pointer. That is, __flash Myclass *t; does not work. Nevertheless, I admit that this is would be nice to have. > One big complaint about avr-g++ is that there is no way to put vtables in > flash (address-space 1) and to access them accordingly. How can this be > achieved with C++ address spaces? Do you want only the vtables in the flash address space or do you want to be able to have the whole class content. 1. If you only want the vtables, I think that a target hook called at vtable creation would do the trick. 2. If you want to be able to have pointer to classes in __flash, I will need to further the support I have currently implemented to support the pointer this qualified with an address space. Retrospectively, I think this have to be implemented. Paul > > Background: The AVR architecture has non-linear address space, and you > cannot tell from the numeric value of an address whether it's in RAM or > flash. You will have to use different instructions depending on the > location. > > This means that .rodata must be located in RAM, because otherwise one would > not know whether const char* pointed to RAM or flash, but to de-reference > you's need different instructions. > > One way out is named address spaces, so we could finally fix > > https://gcc.gnu.org/PR43745 > > > Regards, > > Johann >