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.129.124]) by sourceware.org (Postfix) with ESMTPS id A9C3A3857BB3 for ; Wed, 4 Oct 2023 09:12:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A9C3A3857BB3 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1696410743; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=IFAu3K5w3J7MV5st9SGwQplHYfK0raomeGfFSIUpvaw=; b=FzZ7nLUezP9jvWdUoPlN8HHmVZeCHBTtXa+A07XTsYxymTEmfjNHFbyfl6QHJYhbpMrBvn BiiPul56CeNhpv0MkRVgkb85wx0qYeKwGMEZawj6HY+AUdC9iEt2Cd6ngvgnY60iUX4f99 1SjRiD4f8fZzOoh5kTGnm1fK0/QQQFE= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-287-fpT7xhdzNVe4M4CTbZ7loA-1; Wed, 04 Oct 2023 05:12:20 -0400 X-MC-Unique: fpT7xhdzNVe4M4CTbZ7loA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A69F13C0E66C; Wed, 4 Oct 2023 09:12:19 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.17]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 1C17CC15BB8; Wed, 4 Oct 2023 09:12:19 +0000 (UTC) From: Florian Weimer To: Richard Biener Cc: Hanke Zhang , gcc@gcc.gnu.org Subject: Re: Question about merging if-else blocks References: <3bf388e5-0c20-8294-d99f-5f7c8a74607b@inria.fr> Date: Wed, 04 Oct 2023 11:12:17 +0200 In-Reply-To: (Richard Biener's message of "Wed, 4 Oct 2023 09:54:56 +0200") Message-ID: <875y3meopa.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: * Richard Biener: >> By disassembling the exe file generated by icc, I found that icc will >> merge these two blocks with the example code below. So I think there >> maybe some ways to make it. > > ... glibc for example allows user-provided printf format callbacks so > printf might call back into the current TU and modify globals in such > callback. That's a GNU extension to printf that ICC likely doesn't > support (https://www.gnu.org/software/libc/manual/html_node/Customizing-Printf.html), > so that we're currently not doing this is for correctness. > > I'm not sure if this extension is much used or if it is maybe > deprecated. There's also fopencookie, which is more widely available. The GNU C library supports assignment to stdout, so an fopencookie stream could be the target of printf, also triggering callbacks. But I'm not sure if callbacks updating global variables should prevent GCC from treating printf et al. as leaf functions. Thanks, Florian