From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12b.google.com (mail-lf1-x12b.google.com [IPv6:2a00:1450:4864:20::12b]) by sourceware.org (Postfix) with ESMTPS id D39903890879 for ; Sun, 11 Dec 2022 09:12:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D39903890879 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-lf1-x12b.google.com with SMTP id 1so13761629lfz.4 for ; Sun, 11 Dec 2022 01:12:08 -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=JuOTIt7bVrfaZ7d+ltlamifQkyzpLV/f+kPHcUEnqSE=; b=hP6beTzm3H2A/XR4qGgPP1pXJvc11Cea3V1GrdaiFfUzcyjA/cWkWZSjO7YHDga260 fkkTCgJ2GCEfB+M9UWTK2+3sJKqgqYqwp6RMJWbiIioQaffQ4iH76XtbgPcI97wkm2dJ vOMguiNc9ocHdHiEH2KXVUui5vBnPCeu720qVQubxeDobPC/zaq+5GUw7AdF6dqwhVgW adeDDqtfqKGrishPT3R4HWwlh90xxI70/1NWt3YTO13ZrvkhczySJZQ1kPzXZ2v28eeR ciXF1W2A3O0zmsOZqlDlCtbGR38VImYwS0IIW0+ThjaEnZnxUwFOgvOrHtHEhJrolwdT nEbA== 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=JuOTIt7bVrfaZ7d+ltlamifQkyzpLV/f+kPHcUEnqSE=; b=JhNcdb5VcngYiP7YvZWwjTfL0n4+jYzQ0+jRC9Kdv1wTdyadxxKUCtstFxpKuC7RgW HJ+tDsw77ixcsXATF63MJ+RuwJ8EvQH+7BN7Ku6O6C4Da4a1a35mSR3EL6rHXNDc2p+8 S7s42bRmaL5j+pF3r6R9QX73Mf5CwhpQm4bqQDFROLa1okSdUNg3ILAGgzCFg/Brl0xy vzaz1CmZkOtVFvLH/3T46aeC0TBcZ+393gKnq+7DzcgzpaanAkhMkMa+3UVnZcvbKvYd G+ZnuFL5Jz+X3J40wLu+qxdA1J028fbSE8RNspXyZLtC4ogQapU0slzZQDNSzrDu3swK z54Q== X-Gm-Message-State: ANoB5pkNoXcM+LuF1n4XoGBSdA6irj04Xg7rC15KFMU6vma85+osZbtQ HEMryXHzz2KVgYOBcEpp/8TxSY/iSP1WAR5fFso= X-Google-Smtp-Source: AA0mqf7wYpF+HZ4ofvEAyUZ16sejA2BONe3CnOogtsrVNlgpoSfhyN7szbnDRQhuF8Mrxy4oHNEWtHJZaTTQ19I0efE= X-Received: by 2002:a05:6512:3a96:b0:4b4:f5da:fb28 with SMTP id q22-20020a0565123a9600b004b4f5dafb28mr21292309lfu.169.1670749927219; Sun, 11 Dec 2022 01:12:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Sun, 11 Dec 2022 10:11:54 +0100 Message-ID: Subject: Re: Bug with GCC's handling of lifetimes of implicit-lifetime types To: Andrew Pinski Cc: Jonathan Wakely , Gavin Ray , gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.1 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 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. But yes, I think std::start_lifetime_as needs to be implemented in the C++ frontend and not in the library. As a band-aid that works you can use template auto start_lifetime_as(void* p) noexcept -> T* { __asm__ volatile ("" : : "g" (p) : "memory"); return std::launder((T*)p); } that will a) force what is pointed to be by 'p' addressable and b) make all aliased memory considered clobbered (including *p). Have fun with that. In the end we'd need something like this, for less optimization effect maybe with a way to specify that only *(T *)p is clobbered. template auto start_lifetime_as(void* p) noexcept -> T* { typedef T Tp __attribute__((may_alias)); __asm__ volatile ("" : "=m" (*(Tp *)p) : "g" (p), "m" (*(Tp *)p)); return std::launder((T*)p); } might work, but the typedef/casting/dereferencing might be problematic for some 'T'. Note on the GIMPLE level asms with memory inputs/outputs are hard barriers for everything. Richard. > Thanks, > Andrew Pinski