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 AE0653857BA4 for ; Thu, 10 Aug 2023 23:13:38 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AE0653857BA4 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=1691709218; h=from:from:reply-to: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=mggt4Ur6oUQQOKZ7y5eQkKES120YoQCJrLV+58Z3RsI=; b=MVIGK2mDkROTRna8a8wuLQ9Y15Ls+U6e7ZU9qOJBOcVnZNHNbzuHMa/2oVZNhFRiYWktEJ OGWW5zM8/IRY2uhdTeZZLGAi7euMOjEAi9mBbwgeaqaOGpJBJ51D1x2m1rNOfbtHxHHvDt d+yF1ewz+gBvkwLqcssdw5j/1xs2vVQ= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-217-FKt7Ceu0P9qew1T7HwhCAg-1; Thu, 10 Aug 2023 19:13:34 -0400 X-MC-Unique: FKt7Ceu0P9qew1T7HwhCAg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 9B52E8DC660; Thu, 10 Aug 2023 23:13:34 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.45.224.42]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 44C6A40D2839; Thu, 10 Aug 2023 23:13:34 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 37ANDVsi002946 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Fri, 11 Aug 2023 01:13:32 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 37ANDUF2002945; Fri, 11 Aug 2023 01:13:30 +0200 Date: Fri, 11 Aug 2023 01:13:30 +0200 From: Jakub Jelinek To: Jason Merrill Cc: "Joseph S. Myers" , Marek Polacek , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] c, c++, v2: Accept __builtin_classify_type (typename) Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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: On Thu, Aug 10, 2023 at 05:44:20PM -0400, Jason Merrill wrote: > Hmm, you really think there's any code at all in the wild relying on > __builtin_classify_type + array/function decay? It's a (previously) Looking at the first uses of the builtin back in 90s in va*.h, it certainly relied on array/function decay there (the macros would abort e.g. on array_type_class, function_type_class and various other return values). Looking at older versions of tgmath.h, I see just checks for 8/9 (i.e. real/complex) and those woiuldn't be affected by any promotions/decay. But newer versions of tgmath.h before __builtin_tgmath do check also for 1 and they would be upset if char wasn't promoted to int (including latest glibc). systemtap macros also use __builtin_classify_type and do check for pointers but those seems to be prepared to handle even arrays. > undocumented built-in, I wouldn't expect anyone outside the project to be > using it. So at first glance I'd be inclined to fix it whether or not we > also allow it to accept a type. But I don't actually know how it's used, so > could well be wrong... The problem with changing the existing builtin after 35+ years especially when it was poorly documented: -- Macro: __builtin_classify_type (OBJECT) Since each machine has its own conventions for which data types are passed in which kind of register, your implementation of 'va_arg' has to embody these conventions. The easiest way to categorize the specified data type is to use '__builtin_classify_type' together with 'sizeof' and '__alignof__'. '__builtin_classify_type' ignores the value of OBJECT, considering only its data type. It returns an integer describing what kind of type that is--integer, floating, pointer, structure, and so on. The file 'typeclass.h' defines an enumeration that you can use to interpret the values of '__builtin_classify_type'. is that users then follow what the implementation actually does rather than what is documented (because it isn't), other compilers implemented the behavior GCC had and while as the above list shows some macros/headers could cope with, others can break. And, even if the array/function decay is avoided, one still wouldn't be able to get various type classes because of other decays/argument conversions. > > @@ -7850,6 +7851,50 @@ cp_parser_postfix_expression (cp_parser > > = parser->non_integral_constant_expression_p; > > parser->integral_constant_expression_p = false; > > } > > + else if (TREE_CODE (stripped_expression) == FUNCTION_DECL > > + && fndecl_built_in_p (stripped_expression, > > + BUILT_IN_CLASSIFY_TYPE)) > > + { > > + /* __builtin_classify_type (type) */ > > + auto cl1 = make_temp_override > > + (parser->type_definition_forbidden_message, > > + G_("types may not be defined in " > > + "%<__builtin_classify_type%> calls")); > > + auto cl2 = make_temp_override > > + (parser->type_definition_forbidden_message_arg, > > + NULL); > > + auto cl3 = make_temp_override (parser->in_type_id_in_expr_p, > > + true); > > + cp_evaluated ev; > > + ++cp_unevaluated_operand; > > + ++c_inhibit_evaluation_warnings; > > These three lines seem unnecessary for parsing a type. > > > + tentative_firewall firewall (parser); > > I think you only need a tentative_firewall if you're going to call > cp_parser_commit_to_tentative_parse yourself, which you don't. I think I've just copied this from elsewhere, will double check in the morning which ones aren't really needed. Jakub