From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by sourceware.org (Postfix) with ESMTPS id 175023952498 for ; Sun, 11 Dec 2022 13:38:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 175023952498 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x1036.google.com with SMTP id u15-20020a17090a3fcf00b002191825cf02so9568889pjm.2 for ; Sun, 11 Dec 2022 05:38:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=qlTOYnOIuys5BXFxkyc8gMQoC2p9O/uZR3XPiJR5az4=; b=PpQKvxxpfHQAe6Ywka099GbGsKrOMrvcwEEvLDgkEV1NvCrj7IwHsMA+MdTtf+NOBH RYjazQMfhN8ZO6+iOXuRA3HdAdUInFvd/xJcZn2+Fv5uSl/2oJsWbFtgB3F9rhD3dXRl 0Vvql1WED7VFJBoSwg54ugWHwOTa/bGnPT1zpY/XMWY4Iz9s35rDLTkqE5b2OfMnoOuw Cj9FyBdUFwZ+W8y1bwqg23Af8LqQkXuZze9QC+vMJf82XQjBIvJwON2i1YDqE6NhKzGm /bM4WjdiTbFONyK94d/vPdRSKa7Cf9udcKza16PbW2Hl1IbLPKNriiR4wrFDVAlVWYzv ziBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qlTOYnOIuys5BXFxkyc8gMQoC2p9O/uZR3XPiJR5az4=; b=E9Q7pHeqOpxzY7ILgqYHck++1caA09SBplgcs+MfDqQkuGxYbILcsVPChZQN5IilDp 2D3nVbA3Zn2IsQoS5LPL/9ggzfZ9KYgPhMeASZVdrvMxGqpTS3C+Lghc5tH/zqonVxvc 6saXZaFDUF3bCHPwMZBgUSbJGBQlmO4EgsE0TCp3aBvRzOgSP5fuzGqugYCAdQdbvkB2 fSOeMyHIXr4rjH0vfuleROodDoSybp01XZMUbGJW3IiPanQPo/be52JFGeanNH0Raaxp qR9Fv7RZpalqG0PwxLvvOBy75dZhNQGtBx0abIVgULxU3GxAnH/Bm/yFOk22E20awbbt zefg== X-Gm-Message-State: ANoB5pkNxZnc5YsdOaMzcKOXmRIvWG13r4NTLxRkotYIpPbAGAmAwd28 mY5OF0ain2tUHthkM36B4lLIz5ewUJoUJpKYYbsb9rhkzGU= X-Google-Smtp-Source: AA0mqf7ggJSQioegWauqLb74qHlyEBhKZ+jEr7S+75InTJW+VeJhJIndbCIzNfaeoqE7bkJky9R7Wt7Y1fKE/0kUzIM= X-Received: by 2002:a17:902:700c:b0:18f:438a:cfe3 with SMTP id y12-20020a170902700c00b0018f438acfe3mr109777plk.124.1670765935920; Sun, 11 Dec 2022 05:38:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Gavin Ray Date: Sun, 11 Dec 2022 08:38:46 -0500 Message-ID: Subject: Re: Bug with GCC's handling of lifetimes of implicit-lifetime types To: Richard Biener Cc: Jonathan Wakely , Andrew Pinski , "gcc@gcc.gnu.org" Content-Type: multipart/alternative; boundary="0000000000001d09e605ef8d82e7" X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: --0000000000001d09e605ef8d82e7 Content-Type: text/plain; charset="UTF-8" @Richard That's some intense code, I appreciate the code-samples and explanation, thank you =) @Jonathan Maybe there was some misunderstanding? I didn't make the connection either but I also don't know that much about C++ It seems like that expression is valid then? Good to know =) As a random aside if I may -- what is the difference between placement-new of pointers in std::byte storage, and making a std::span over the storage area? std::byte storage[PAGE_SIZE * NUM_PAGES]; // A) page* pages = new (storage) page[NUM_PAGES]; // B) std::span pages_span(pages, NUM_PAGES); On Sun, Dec 11, 2022 at 8:31 AM Richard Biener wrote: > On Sun, Dec 11, 2022 at 1:02 PM Jonathan Wakely > wrote: > > > > > > > > On Sun, 11 Dec 2022, 09:12 Richard Biener, > wrote: > >> > >> On Sat, Dec 10, 2022 at 7:45 PM Andrew Pinski via Gcc > wrote: > >> > > >> > On Sat, Dec 10, 2022 at 10:36 AM Jonathan Wakely via Gcc > >> > wrote: > >> > > > >> > > On Sat, 10 Dec 2022 at 17:42, Gavin Ray via Gcc > wrote: > >> > > > > >> > > > This came up when I was asking around about what the proper way > was to: > >> > > > > >> > > > - Allocate aligned storage for a buffer pool/page cache > >> > > > - Then create pointers to "Page" structs inside of the storage > memory area > >> > > > > >> > > > I thought something like this might do: > >> > > > > >> > > > struct buffer_pool > >> > > > { > >> > > > alignas(PAGE_SIZE) std::byte storage[NUM_PAGES * PAGE_SIZE]; > >> > > > page* pages = new (storage) page[NUM_PAGES]; > >> > > > } > >> > > > > >> > > > Someone told me that this was a valid solution but not to do it, > because it > >> > > > wouldn't function properly on GCC > >> > > > They gave this as a reproduction: > >> > > > > >> > > > https://godbolt.org/z/EhzM37Gzh > >> > > > > >> > > > I'm not experienced enough with C++ to grok the connection > between this > >> > > > repro and my code, > >> > > > >> > > Me neither. I don't think there is any connection, because I don't > >> > > think the repro shows what they think it shows. > >> > > > >> > > > but I figured > >> > > > I'd post it on the mailing list in case it was useful for > others/might get > >> > > > fixed in the future =) > >> > > > > >> > > > They said it had to do with "handling of lifetimes of > implicit-lifetime > >> > > > types" > >> > > > >> > > I don't think that code is a valid implementation of > >> > > start_lifetime_as. Without a proper implementation of > >> > > start_lifetime_as (which GCC doesn't provide yet), GCC does not > allow > >> > > you to read the bytes of a float as an int, and doesn't give you the > >> > > bytes of 1.0f, it gives you 0. > >> > > > >> > > https://godbolt.org/z/dvncY9Pea works for GCC. But this has > nothing to > >> > > do your code above, as far as I can see. > >> > > >> > See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107115#c10 for what > >> > is going wrong. > >> > Basically GCC does not have a way to express this in the IR currently > >> > and there are proposals there on how to do it. > >> > >> I wouldn't call them "proposals" - basically the C++ language providing > >> holes into the TBAA system is a misdesign, it will be incredibly > difficult > >> to implement this "hole" without sacrifying optimization which means > >> people will complain endlessly why std::start_lifetime_as isn't a way > >> to circumvent TBAA without losing optimization. > > > > > > People already make holes in the type system, this just lets them do it > without UB. If it's not as fast as their UB, that's ok IMHO. > > > > > > > > But I don't see what start_lifetime_as has to do with the original > problem anyway. The placement new expression will start lifetimes: > > > > page* pages = new (storage) page[NUM_PAGES]; > > > > There's no need to mess with the type system here. > > That's true, and that should work, not sure what the problem should be > here. > > Richard. > > > > > > --0000000000001d09e605ef8d82e7--