From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 40BF43858033 for ; Wed, 22 Dec 2021 09:24:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 40BF43858033 Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-58-I7QjOQkFOImgOjxJtGPkKg-1; Wed, 22 Dec 2021 04:24:32 -0500 X-MC-Unique: I7QjOQkFOImgOjxJtGPkKg-1 Received: by mail-wr1-f71.google.com with SMTP id n22-20020adf8b16000000b001a22f61b29cso556693wra.23 for ; Wed, 22 Dec 2021 01:24:31 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=o21qwz3zj60D0Ci/cLmmZQkQqpr+zeJNF+RMJPk2+Bg=; b=7aMRnnu/3KXQzG3orJiWkcpHwAEAsE8oWcqp2sef7gNT6NjAwoiXqlv6zzCYZ6YIQN LVpQhHywf/5Ebo5iMJWJU6Ia9oyx8RepKdbu5rrd7yI4bvs2qsZUaxoG6VOa0um8wVQY +daH2Vk8+AABzKc+d+29vBuvjxQCsy9ph5Swu1FzWdeb9pIwB+gKJEw6UxUeeefXg2Sd uEyX588T2btYwVr7asczRuf18VecalDvfyRIG9feuAfCRYad4w4qyyIAQJItV+RQmrpt Jg1pI3gxLmci3KoEF+9cfrkwkDnAiS093gh2WuB/CT7Hyrn3JmMmGFSm7XSlAbm1EghZ 6SoA== X-Gm-Message-State: AOAM530WZDKTj57ENdrJV8IvM+NX9Fr6xb1IfJL0kqOAqApK2IbyaZb8 DadVDEziJxnp+iB9ywx7nSLVvqiBZkt6iFWyq9SX3qyQ4yz47FaF21Z+pfydpRIP2z9xwGBFWRe s3CL0JRPUQbdrCg== X-Received: by 2002:a5d:4c88:: with SMTP id z8mr1454838wrs.136.1640165070846; Wed, 22 Dec 2021 01:24:30 -0800 (PST) X-Google-Smtp-Source: ABdhPJyl6o9OoPY2ldbsM1Ui+WfZa/xj72O85R4AHr/kgZ45Wp0SevE3Yb9iLiEie8fwDzHZBjtQYg== X-Received: by 2002:a5d:4c88:: with SMTP id z8mr1454824wrs.136.1640165070568; Wed, 22 Dec 2021 01:24:30 -0800 (PST) Received: from [192.168.0.129] ([81.0.47.68]) by smtp.gmail.com with ESMTPSA id k31sm1220752wms.21.2021.12.22.01.24.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 22 Dec 2021 01:24:29 -0800 (PST) Message-ID: <9b28799e-71f8-2ef9-1cc9-01345993cc11@redhat.com> Date: Wed, 22 Dec 2021 10:24:28 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.0 Subject: Re: broken code only when optimized "-O2" To: David Brown , Stefan Ring Cc: gcc-help References: From: Adrian Moreno In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, 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: Wed, 22 Dec 2021 09:24:35 -0000 On 12/21/21 18:05, David Brown wrote: > 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. > Yes, that's the road I'm taking. Thanks for the suggestion. One of the things that originally felt smelly was that the fact that the macros that iterate the list elements assume the "struct ovs_list" element is embedded into another "struct member": struct member *pos = 0; for ((((pos) = ((struct member *) (void *) ((uintptr_t)(void *)((&start)->next) - __builtin_offsetof (struct member, elem))))); &(pos)->elem != (&start); ((pos) = ((struct member *) (void *) ((uintptr_t)(void *)((pos)->elem.next) - __builtin_offsetof (struct member , elem) )))) { [... use pos ] however, the beginning of the list is a "struct ovs_list" defined in the stack and not embedded into a "struct member". Therefore, "(&start)->next - __builtin_offsetof (struct member, elem)" actually points to somewhere in the stack that contains who knows what. (Note: initially start->next = start) In fact, if I make the struct offsets zero: struct member { struct ovs_list elem; [ ... ] int order; }; ... the code works. However if I use: struct member { int padding[10]; struct ovs_list elem; [ ... ] int order; }; ... the code fails. Does anything of what I'm saying make sense so far? If the code inside the loop just made use of "pos" through "(&pos->elem)" then the compiler could(?) be ok with it but the loop actually contains: if (member->order > pos->order) { break; } So here I do not know what the compiler would think about "pos" if it happens to point to some invalid stack address. Thanks for the help. -- Adrián Moreno