From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) by sourceware.org (Postfix) with ESMTPS id 7A47D3850B0D for ; Sun, 11 Dec 2022 13:31:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7A47D3850B0D 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-lj1-x229.google.com with SMTP id g14so5822482ljh.10 for ; Sun, 11 Dec 2022 05:31:43 -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=0PCDUJB02BCmFbg79D8bXHXlc9Vqdt18mEUO//OcOuE=; b=D/nJWvZ5uM2PAo1jjcDmNo1yXOVKXUrpSvyiQszJJOLTm8IQwcneb57LfLNT19FeJG auhTczhS7P76WNLJkTW66hUCu5KUgdxxpyAA8FBvAW19GYwjaMv2uZz9G6s75SkxrrL9 DnFyaecsW0Zjyc3ULnYmsFh97RoSoWXy7T0V0rVE41hVRN6n5k60a45H/6/JQwMqzBq9 GOrymbeGOilXbQ/F2HGOfduoVBzORVRiGkmpSlm7zyARfIK9NdgKU93tAGV+PIuWhTFf frWb6FdWq3qqcscLSQHV+x1c9sAjSTQTGXjxGc7LFrM4+YVOzYpyb9Hve+2tf/RwwiRy WoLw== 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=0PCDUJB02BCmFbg79D8bXHXlc9Vqdt18mEUO//OcOuE=; b=shJ6GlrApJSaCAWJwu4euRgTNeSfswb9lSrpYxD8O4wU9k6UI7ZuPDK9OgQcLG11/X rgzhwjTOyz/MBqU98JN+o7Jc9054sVtWP+LhZKaojkeoieeAzLoxIFZ5BCZpMP/S6Z2k YC/El5EVcTIa/FaCTNfZYPMdrw3mNJIslS0hpzym5H+ejQfXTLeifrvFL+mXqV60JfQg Ys11eHJkWmFyZ3CVin8h5+vmsU0BLF7Us4agj9FW4h777nJwn5yLKH12+EVJUx3f4bdj iIahHbuAR3XYVj5mYYx7SDuAOWMG4Rf3SoLj5W/vPwIrBBivn0XyfMSMe/rePyYMScti cZsA== X-Gm-Message-State: ANoB5pm8gVdwOstbWcPTn6zxI4T9d6BHEekgPHkYHN8IC7Hnfapx0Dnv l2LDTxukSJca1c5WFde6StV04EJZkZSARBmCXhU= X-Google-Smtp-Source: AA0mqf7BSJ3rfcu57I6JTLVMLhe7RUDC91bYAyUEr1P+8e4kvT/Ia8VFEnvSRKAinnb5TQX3nSGHx43HPy9GNaQjk6M= X-Received: by 2002:a05:651c:19ab:b0:276:66a4:47c3 with SMTP id bx43-20020a05651c19ab00b0027666a447c3mr24426140ljb.49.1670765501779; Sun, 11 Dec 2022 05:31:41 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Sun, 11 Dec 2022 14:31:29 +0100 Message-ID: Subject: Re: Bug with GCC's handling of lifetimes of implicit-lifetime types To: Jonathan Wakely Cc: Andrew Pinski , Gavin Ray , "gcc@gcc.gnu.org" Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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: 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. > >