From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by sourceware.org (Postfix) with ESMTPS id 2921638319DF for ; Sun, 11 Dec 2022 12:02:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2921638319DF 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-ed1-x52e.google.com with SMTP id f7so9151867edc.6 for ; Sun, 11 Dec 2022 04:02:38 -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=VMfA779TgIF86qJI8nOuW+22JAVWzRPEl+83/h5PQ8A=; b=aWFRY/TJV4Ozxt1bljPc+vZlSr3fENFJKp8ZJdWA/uvsRTkFyagEaPzlkNYlOVr6xE 9mk+YPWzh1FCd0YBCpXDQTYMysnqs5Cltgk9XYA8PqkyY4HBzNoFkGZrf0L7GIkyQxBh GbEsZc3buYXTiL6S/IRu8arZkuom1/NhTfHIW/rhQV/jyX2PZ9dri8pap5u1s8j2U1a0 TF/gO4Z2woxNojmz42s7JqfP5JIgmPy+tT45/rLmsGY2O8u82LMHRiwUSzEu77pPJIK6 LmEMGBu3AiuNikq0yOmqElBBtNzRgtRjbHe5/qXzHQD48FXccIzQcOkCCwUpYSiKyZOy VJOQ== 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=VMfA779TgIF86qJI8nOuW+22JAVWzRPEl+83/h5PQ8A=; b=ZZ/hDl5OW+iGkvwON8syQazCAVm7GqNtdclQxjGwYPLzTSfpx+drK7Ay/WLidq05jW c+l5/GGSmP6z5dradEU1exYx1K7BTg8mR6YmAg480tUVaqAVdspPRkizo4KKFVAq5Kbt g6juay1Tc+NGJ5Arg1GKKVayfaxgAKVG1h6PoyyHDA8Hv5WOayh/6PGjcWaed9fDf/Uw ndJ7kBwvGg8+iwjcr/azxTWjn0/DCd7hsEPg3o1WLZRcuIwWIbZnSpZJKfgw9VEFbWZb dzPjUjYiw5pIetxcWDFR98xm2/U27H14CU16MPSpMb5EB3VmMSjh7XM1+8xuJOR0MtVb 1nKQ== X-Gm-Message-State: ANoB5pm/AmLs9ddbCHb5+nq6s7vNVZsCEyiifBKSIGHpaMBt61EqizMg EQv/OO0rXxxxygrJ25auhnY9DP5tntpkF98IhK4= X-Google-Smtp-Source: AA0mqf4/VbPJoV3VEz5hy1C8eP2tz5qauEQEw/nOzQkrooYuz9/9ynuctZzP+BIe6tILCCSQRDIs13hEjV94FZdwyDo= X-Received: by 2002:a05:6402:64e:b0:46c:af80:636c with SMTP id u14-20020a056402064e00b0046caf80636cmr16275549edx.129.1670760156861; Sun, 11 Dec 2022 04:02:36 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Sun, 11 Dec 2022 12:02:24 +0000 Message-ID: Subject: Re: Bug with GCC's handling of lifetimes of implicit-lifetime types To: Richard Biener Cc: Andrew Pinski , Gavin Ray , "gcc@gcc.gnu.org" Content-Type: multipart/alternative; boundary="000000000000a7985905ef8c29fc" X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: --000000000000a7985905ef8c29fc Content-Type: text/plain; charset="UTF-8" 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. --000000000000a7985905ef8c29fc--