From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x333.google.com (mail-wm1-x333.google.com [IPv6:2a00:1450:4864:20::333]) by sourceware.org (Postfix) with ESMTPS id B309E3858C50 for ; Mon, 21 Mar 2022 11:15:17 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B309E3858C50 Received: by mail-wm1-x333.google.com with SMTP id v2-20020a7bcb42000000b0037b9d960079so10142879wmj.0 for ; Mon, 21 Mar 2022 04:15:17 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DrXDJqanMlmAK8GWr7wx20L/zZ+Jr2l0ojucCDO+9qA=; b=lwzQL/xmCbA5qDypE5TfnlqCoYGScw8TPe5x+LYCjrN7OAEZdjPGe+f+MJeVnlocIL AnBXFRc4p/nkjfM8N8V8/LSe9aJX5X2fsmeNLF0lucBpjyyVUCUYZy5DQxsiqUr8DYZ/ Dm5aSu5pD+PyjzS9Uq+J+umy442mVadKKqGx2pj4A6mmeerGBotLQ6vPWMMXdJnl5BXH 6TYR9dUjL13IDMh7xx4LmMx1ACMZBB6pCbKE3CQHl2pmNGg4m5EoXnRMAr3mK9mWg5xS NX5cVdN5+HaDDYZRoEIOeyNOsPCeW4/X3MDMkV2WEbMHoXEtnhvr/2KhPJF0HktdoQOo nT5w== X-Gm-Message-State: AOAM533TjzlcUZk3cZ0VO+Pwk9+Y5LRN0ec3WKbqnGDbRriUk7y7XWVk 7uy3cZWU6jK+m02Or5ffUrofl+pmkutQkZTk+/s= X-Google-Smtp-Source: ABdhPJyglOprxv5QmEsIDv4823sRQJE2aNaHvNVliXmQVQM5wmaoeX1/i/ZtMWOddh/y1QioDk8Grr3kX7mJo4Pneok= X-Received: by 2002:a7b:c041:0:b0:38c:7c21:8ade with SMTP id u1-20020a7bc041000000b0038c7c218ademr17464957wmc.163.1647861316390; Mon, 21 Mar 2022 04:15:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Mon, 21 Mar 2022 11:15:05 +0000 Message-ID: Subject: Re: Is changing __STDCPP_DEFAULT_NEW_ALIGNMENT__ an ABI break To: Doods Pav Cc: gcc-help Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.7 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, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2022 11:15:20 -0000 On Sun, 20 Mar 2022 at 15:39, Doods Pav via Gcc-help wrote: > > Is changing the value of the predefined macro > `__STDCPP_DEFAULT_NEW_ALIGNMENT__` considered an ABI break? (in the same > way that modifying `alignof(std::max_align_t)` would be). It depends. If the OS's C library does not provide aligned_alloc or posix_memalign or memalign then it's an ABI break. If the C library doesn't provide one of those functions, then the operator new(size_t, align_val_t) function needs to do additional bookkeeping to be able to deallocate the aligned memory. The value of that macro determines whether a given object size uses operator new(size_t) or operator new(size_t, align_val_t), so if you change the value of the macro you change whether additional bookkeeping is needed for a given object size. If different parts of the program disagree, you could allocate memory using the aligned form and then try to deallocate it using the non-aligned operator delete(void*, size_t), which would have undefined behaviour. This is the case on Windows, as it only provides _aligned_malloc/_aligned_free, which are not compatible with malloc/free. It might also be the case on very old versions of newlib and other C libraries. Also, if your program replaces operator new(size_t) and/or operator new(size_t, align_val_t) and makes them incompatible, then changing the default new alignment is also an ABI break (because for the same reasons as above, different parts of the program will disagree on whether a given object size uses the overaligned new/delete or not). In the common case (the OS supports one of the libc aligned allocation functions, and you don't replace new/delete) it's not an ABI break. > I would assume that it is, but I saw this comment on a bug report ( > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77691#c33) and I'm unsure if > the value of the macro was later changed in a patch, and if so, if that was > considered an ABI break. The macro wasn't changed.