On 8/10/23 11:35, Jakub Jelinek wrote:
Hi!
I'd like to ping this patch. Reposting it as I found a typo in the
documentation - s/builtin-in/built-in/. Bootstrapped/regtested again
on x86_64-linux and i686-linux, ok for trunk?
On Mon, Jun 12, 2023 at 09:57:17PM +0200, Jakub Jelinek via Gcc-patches wrote:
As mentioned in my stdckdint.h mail, __builtin_classify_type has
a problem that argument promotion (the argument is passed to ...
prototyped builtin function) means that certain type classes will
simply never appear.
I think it is too late to change how it behaves, lots of code in the
wild might rely on the current behavior.
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)
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...
--- gcc/cp/parser.cc.jj 2023-06-06 20:02:35.631211230 +0200
+++ gcc/cp/parser.cc 2023-06-12 16:19:04.892202240 +0200
@@ -48,6 +48,7 @@ along with GCC; see the file COPYING3.
#include "c-family/known-headers.h"
#include "contracts.h"
#include "bitmap.h"
+#include "builtins.h"
/* The lexer. */
@@ -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.
Jason
