From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from spam02.hesby.net (spam01.hesby.net [81.29.32.152]) by sourceware.org (Postfix) with ESMTP id CC9143858017 for ; Tue, 21 Dec 2021 17:05:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CC9143858017 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hesbynett.no Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hesbynett.no Received: from [192.168.0.63] (unknown [79.161.10.130]) by spam02.hesby.net (Halon) with ESMTPSA id 39514d89-6280-11ec-8d7a-506b8dfa0e58; Tue, 21 Dec 2021 18:05:39 +0100 (CET) Subject: Re: broken code only when optimized "-O2" To: Stefan Ring , Adrian Moreno Cc: gcc-help References: From: David Brown Message-ID: Date: Tue, 21 Dec 2021 18:05:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3033.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP 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: Tue, 21 Dec 2021 17:05:44 -0000 On 21/12/2021 17:05, Stefan Ring via Gcc-help wrote: > On Tue, Dec 21, 2021 at 4:40 PM Adrian Moreno via Gcc-help > wrote: >> >> I'd really appreciate any hint or idea to try to understand this problem. > > I guess the compiler doesn't like the dereferencing of uninitialized > pointers (in the sizeof expressions). I am not 100% sure that this > counts as dereferencing, but I would assume so. Because of this the > compiler will be free to behave however it likes to. > The operand of a sizeof expression is not evaluated (unless it is a VLA). So there is no problem with the "member1 = malloc(sizeof *member1);" lines. (Which is fortunate, because it is a very common idiom!) I think the next step would be to start pulling in some of the definitions for the various macros here, and then trying to reduce the code further to get a smaller test case.