aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
2022-10-06Ensure uniqueness on Path probe'sPhilip Herron5-66/+58
When we lookup names in paths such as Foo::bar, foo is a type we resolve and then we lookup 'bar' based on what type Foo is which includes probing relevant bounds of this type. We currently return a vector of possible candidates and this patch changes it so that we return a set of unique items based on DefId. Addresses #1555
2022-10-06Track DefId on ADT variantsPhilip Herron3-13/+22
We must track the DefID on variants for algebraic data types as this will allow us to enforce unique'ness on path queries relating to this.
2022-10-06Merge #1564bors[bot]3-108/+156
1564: builtins: Move implementation into source file r=CohenArthur a=CohenArthur Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
2022-10-06Merge #1547bors[bot]4-4/+53
1547: Dump item visibility r=CohenArthur a=CohenArthur Co-authored-by: Arthur Cohen <arthur.cohen@embecosm.com>
2022-10-06Merge #1554bors[bot]1-0/+18
1554: testing: try loop in const function r=philberty a=abbasfaisal Co-authored-by: Faisal Abbas <faisal.abbas@elastica.co>
2022-10-06builtins: Move implementation into source fileArthur Cohen3-108/+156
2022-10-05ast: dump If expressionsDavid Faust1-3/+19
2022-10-05ast: dump assignment and compound assignment exprDavid Faust1-2/+54
2022-10-03testing: try loop in const functionFaisal Abbas1-0/+18
Signed-off-by: Faisal Abbas <90.abbasfaisal@gmail.com>
2022-09-30Add catch for recusive type queriesPhilip Herron3-2/+25
When we have a type query where by generic substitution occurs we can hit the case where we need to Probe the bounds of the substited item to determine whether the the bounds are compatible this can cause us to end up querying the same type recursively. Fixes #1550
2022-09-28dump: Emit visibility when dumping itemsArthur Cohen2-2/+51
2022-09-28visibility: Rename get_public_vis_type -> get_vis_typeArthur Cohen2-2/+2
2022-09-27Merge #1546bors[bot]268-3132/+6704
1546: Merge remote-tracking branch 'mainline/master' into ibuclaw/merge_mainline r=philberty a=ibuclaw Fixes: #1544 Co-authored-by: Jonathan Wakely <jwakely@redhat.com> Co-authored-by: GCC Administrator <gccadmin@gcc.gnu.org> Co-authored-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com> Co-authored-by: Mikael Morin <mikael@gcc.gnu.org> Co-authored-by: Harald Anlauf <anlauf@gmx.de> Co-authored-by: liuhongt <hongtao.liu@intel.com> Co-authored-by: Kewen Lin <linkw@linux.ibm.com> Co-authored-by: Hu, Lin1 <lin1.hu@intel.com> Co-authored-by: Martin Liska <mliska@suse.cz> Co-authored-by: Eric Botcazou <ebotcazou@adacore.com> Co-authored-by: Piotr Trojanek <trojanek@adacore.com> Co-authored-by: Boris Yakobowski <yakobowski@adacore.com> Co-authored-by: Justin Squirek <squirek@adacore.com> Co-authored-by: Tucker Taft <taft@adacore.com> Co-authored-by: Kévin Le Gouguec <legouguec@adacore.com>
2022-09-27Merge #1545bors[bot]39-1245/+1058
1545: Refactor TypeResolution to be a simple query based system r=philberty a=philberty This patch refactors the type resolution system to introduce a new interface bool query_type (HirId, TyTy::BaseType** result) This is needed in order to properly support forward declared items. Our name resolution system has two parts: 1. Toplevel scan 2. Item resolution The toplevel scan gathers all the nesseacry 'names' into their respective namespace by doing a full toplevel scan and generate canonical paths for each item. The second pass is responsible for drilling down into each structure or function to resolve each field or variable etc. This means our name resolution system supports forward decalred items but our type resolution system did not. This patch removes the toplevel scan from our type resolution pass which is not able to handle all cases such as a function with return type and the type is decalred after the fact or a type alias to a type declared after the fact. The name resolution mappings are resolved so when errors occured here we got errors such as unable to lookup HirId 1234, which meant yes we have 'resolved' this reference to this HirId but we are unable to find any type information for it. This means we needed a new way to figure out the type in a query based way. This is where the new query_type inferface comes in so when we have an HirId we want to resolve the mappings class allows us to figure out what item this is such as: 1. HIR::Item (normal HIR::Function, Struct, TypeAlias, ...) 2. HIR::ImplItem (function, constant, ... within an impl-block) 3. HIR::ImplBlock (Self type on an impl-block) 4. HIR::ExternalItem (extern-block item) The mappings class allows us to simply lookup these HIR nodes and then call the relevant resolver class to compute the type. This patch does not add support for self-referencial types but is the starting point to be able to support such types. Fixes #1455 Fixes #1006 Fixes #1073 Fixes #1272 Co-authored-by: Philip Herron <philip.herron@embecosm.com>
2022-09-27Merge remote-tracking branch 'mainline/master' into ibuclaw/merge_mainlineIain Buclaw268-3132/+6704
Fixes: #1544
2022-09-27Fix missing dead code analysis ICE on local enum definitionPhilip Herron5-2/+44
When resolving local enum's within a Block the name resolution info is not at the top of the stack so this patch introduces a new mappings class for miscellaneous name resolutions which can be used during path analaysis. Fixes #1272
2022-09-27Add testcase to show forward declared items work via TypeAliasPhilip Herron1-0/+4
Fixes #1073
2022-09-27Add testcase to show forward declared items workPhilip Herron1-0/+10
Fixes #1006
2022-09-27Refactor TypeResolution to be a simple query based systemPhilip Herron29-1223/+952
This patch refactors the type resolution system to introduce a new interface bool query_type (HirId, TyTy::BaseType** result) This is needed in order to properly support forward declared items. Our name resolution system has two parts: 1. Toplevel scan 2. Item resolution The toplevel scan gathers all the nesseacry 'names' into their respective namespace by doing a full toplevel scan and generate canonical paths for each item. The second pass is responsible for drilling down into each structure or function to resolve each field or variable etc. This means our name resolution system supports forward decalred items but our type resolution system did not. This patch removes the toplevel scan from our type resolution pass which is not able to handle all cases such as a function with return type and the type is decalred after the fact or a type alias to a type declared after the fact. The name resolution mappings are resolved so when errors occured here we got errors such as unable to lookup HirId 1234, which meant yes we have 'resolved' this reference to this HirId but we are unable to find any type information for it. This means we needed a new way to figure out the type in a query based way. This is where the new query_type inferface comes in so when we have an HirId we want to resolve the mappings class allows us to figure out what item this is such as: 1. HIR::Item (normal HIR::Function, Struct, TypeAlias, ...) 2. HIR::ImplItem (function, constant, ... within an impl-block) 3. HIR::ImplBlock (Self type on an impl-block) 4. HIR::ExternalItem (extern-block item) The mappings class allows us to simply lookup these HIR nodes and then call the relevant resolver class to compute the type. This patch does not add support for self-referencial types but is the starting point to be able to support such types. Fixes #1455
2022-09-27Fix duplicated function generation on higher ranked trait boundsPhilip Herron2-7/+28
Deuplicate function elimination can fail when we compile helpers during higher ranked trait bound monomorphization. This because the TyTy::BaseType info can be lost/reset during the compilation process. This adds a second mechanism to match based on the manged names which is a bit more reliable. This patch is required since the query based refactor of the type system so this issue was likely hidden to to using duplicated type info for higher ranked trait bounds.
2022-09-27Make constexpr constructors type-checking more permissivePhilip Herron1-8/+8
2022-09-27Cleanup formatting of backend expression visitorPhilip Herron1-5/+12
2022-09-27d: Merge upstream dmd d579c467c1, phobos 88aa69b14.Iain Buclaw104-1375/+1829
D front-end changes: - Throwing from contracts of `nothrow' functions has been deprecated, as this breaks the guarantees of `nothrow'. - Added language support for initializing the interior pointer of associative arrays using `new' keyword. Phobos changes: - The std.digest.digest module has been removed. - The std.xml module has been removed. gcc/d/ChangeLog: * dmd/MERGE: Merge upstream dmd d579c467c1. * decl.cc (layout_struct_initializer): Update for new front-end interface. * expr.cc (ExprVisitor::visit (AssignExp *)): Remove lowering of array assignments. (ExprVisitor::visit (NewExp *)): Add new lowering of new'ing associative arrays to an _aaNew() library call. * runtime.def (ARRAYSETASSIGN): Remove. (AANEW): Define. libphobos/ChangeLog: * libdruntime/MERGE: Merge upstream druntime d579c467c1. * libdruntime/Makefile.am (DRUNTIME_DSOURCES): Remove rt/arrayassign.d. * libdruntime/Makefile.in: Regenerate. * src/MERGE: Merge upstream phobos 88aa69b14. * src/Makefile.am (PHOBOS_DSOURCES): Remove std/digest/digest.d, std/xml.d. * src/Makefile.in: Regenerate.
2022-09-27irange: keep better track of powers of 2.Aldy Hernandez2-0/+25
When setting the nonzero bits to a mask containing only one bit, set the range immediately, as it can be devined from the mask. This helps us keep better track of powers of two. For example, with this patch a nonzero mask of 0x8000 is set to a range of [0,0][0x8000,0x8000] with a nonzero mask of 0x8000. gcc/ChangeLog: * value-range.cc (irange::set_nonzero_bits): Set range when known. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/popcount6.c: New test.
2022-09-27Add an irange setter for wide_ints.Aldy Hernandez1-0/+9
Just the same way as we have real_value setters for franges, we should have a wide_int version for irange. This matches the irange constructor for wide_ints, and paves the way for the eventual conversion of irange to wide ints. gcc/ChangeLog: * value-range.h (irange::set): New version taking wide_int_ref.
2022-09-27c++: Implement C++23 P1169R4 - static operator() [PR106651]Jakub Jelinek14-33/+235
The following patch attempts to implement C++23 P1169R4 - static operator() paper's compiler side (there is some small library side too not implemented yet). This allows static members as user operator() declarations and static specifier on lambdas without lambda capture. The synthetized conversion operator changes for static lambdas as it can just return the operator() static method address, doesn't need to create a thunk for it. The change in call.cc (joust) is to avoid ICEs because we assumed that len could be different only if both candidates are direct calls but it can be one direct and one indirect call, and to implement the [over.match.best.general]/1 and [over.best.ics.general] changes from the paper (implemented always as Jason is sure it doesn't make a difference in C++20 and earlier unless static member function operator() or static lambda which we accept with pedwarn in earlier standards too appears and my testing confirmed that). 2022-09-27 Jakub Jelinek <jakub@redhat.com> PR c++/106651 gcc/c-family/ * c-cppbuiltin.cc (c_cpp_builtins): Predefine __cpp_static_call_operator=202207L for C++23. gcc/cp/ * cp-tree.h (LAMBDA_EXPR_STATIC_P): Implement C++23 P1169R4 - static operator(). Define. * parser.cc (CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR): Document that it also allows static. (cp_parser_lambda_declarator_opt): Handle static lambda specifier. (cp_parser_decl_specifier_seq): Allow RID_STATIC for CP_PARSER_FLAGS_ONLY_MUTABLE_OR_CONSTEXPR. * decl.cc (grok_op_properties): If operator() isn't a method, use a different error wording, if it is static member function, allow it (for C++20 and older with a pedwarn unless it is a lambda function or template instantiation). * call.cc (joust): Don't ICE if one candidate is static member function and the other is an indirect call. If the parameter conversion on the other candidate is user defined conversion, ellipsis or bad conversion, make static member function candidate a winner for that parameter. * lambda.cc (maybe_add_lambda_conv_op): Handle static lambdas. * error.cc (dump_lambda_function): Print static for static lambdas. gcc/testsuite/ * g++.dg/template/error30.C: Adjust expected diagnostics. * g++.dg/cpp1z/constexpr-lambda13.C: Likewise. * g++.dg/cpp23/feat-cxx2b.C: Test __cpp_static_call_operator. * g++.dg/cpp23/static-operator-call1.C: New test. * g++.dg/cpp23/static-operator-call2.C: New test. * g++.old-deja/g++.jason/operator.C: Adjust expected diagnostics.
2022-09-27reassoc: Handle OFFSET_TYPE like POINTER_TYPE in ↵Jakub Jelinek2-5/+35
optimize_range_tests_cmp_bitwise [PR107029[ As the testcase shows, OFFSET_TYPE needs the same treatment as POINTER_TYPE/REFERENCE_TYPE, otherwise we fail the same during the newly added verification. OFFSET_TYPE is signed though, so unlike POINTER_TYPE/REFERENCE_TYPE it can also trigger with the x < 0 && y < 0 && z < 0 to (x | y | z) < 0 optimization. 2022-09-27 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/107029 * tree-ssa-reassoc.cc (optimize_range_tests_cmp_bitwise): Treat OFFSET_TYPE like POINTER_TYPE, except that OFFSET_TYPE may be signed and so can trigger even the (b % 4) == 3 case. * g++.dg/torture/pr107029.C: New test.
2022-09-27openmp: Add OpenMP assume, assumes and begin/end assumes supportJakub Jelinek29-67/+1075
The following patch implements OpenMP 5.1 #pragma omp assume #pragma omp assumes and #pragma omp begin assumes #pragma omp end assumes directive support for C and C++. Currently it doesn't remember anything from the assumption clauses for later, so is mainly to support the directives and diagnose errors in their use. If the recently posted C++23 [[assume (cond)]]; support makes it in, the intent is that this can be easily adjusted at least for the #pragma omp assume directive with holds clause(s) to use the same infrastructure. Now, C++23 portable assumptions are slightly different from OpenMP 5.1 assumptions' holds clause in that C++23 assumption holds just where it appears, while OpenMP 5.1 assumptions hold everywhere in the scope of the directive. For assumes directive which can appear at file or namespace scope it is the whole TU and everything that functions from there call at runtime, for begin assumes/end assumes pair all the functions in between those directives and everything they call and for assume directive the associated (currently structured) block. I have no idea how to represents such holds to be usable for optimizers, except to make #pragma omp assume holds (cond) block; expand essentially to [[assume (cond)]]; block; or [[assume (cond)]]; block; [[assume (cond)]]; for now. Except for holds clause, the other assumptions are OpenMP related, I'd say we should brainstorm where it would be useful to optimize based on such information (I guess e.g. in target regions it easily could) and only when we come up with something like that think about how to propagate the assumptions to the optimizers. 2022-09-27 Jakub Jelinek <jakub@redhat.com> gcc/c-family/ * c-pragma.h (enum pragma_kind): Add PRAGMA_OMP_ASSUME, PRAGMA_OMP_ASSUMES and PRAGMA_OMP_BEGIN. Rename PRAGMA_OMP_END_DECLARE_TARGET to PRAGMA_OMP_END. * c-pragma.cc (omp_pragmas): Add assumes and begin. For end rename PRAGMA_OMP_END_DECLARE_TARGET to PRAGMA_OMP_END. (omp_pragmas_simd): Add assume. * c-common.h (c_omp_directives): Declare. * c-omp.cc (omp_directives): Rename to ... (c_omp_directives): ... this. No longer static. Uncomment assume, assumes, begin assumes and end assumes entries. In end declare target entry rename PRAGMA_OMP_END_DECLARE_TARGET to PRAGMA_OMP_END. (c_omp_categorize_directive): Adjust for omp_directives to c_omp_directives renaming. gcc/c/ * c-lang.h (current_omp_begin_assumes): Declare. * c-parser.cc: Include bitmap.h. (c_parser_omp_end_declare_target): Rename to ... (c_parser_omp_end): ... this. Handle also end assumes. (c_parser_omp_begin, c_parser_omp_assumption_clauses, c_parser_omp_assumes, c_parser_omp_assume): New functions. (c_parser_translation_unit): Also diagnose #pragma omp begin assumes without corresponding #pragma omp end assumes. (c_parser_pragma): Use %s in may only be used at file scope diagnostics to decrease number of translatable messages. Handle PRAGMA_OMP_BEGIN and PRAGMA_OMP_ASSUMES. Handle PRAGMA_OMP_END rather than PRAGMA_OMP_END_DECLARE_TARGET and call c_parser_omp_end for it rather than c_parser_omp_end_declare_target. (c_parser_omp_construct): Handle PRAGMA_OMP_ASSUME. * c-decl.cc (current_omp_begin_assumes): Define. gcc/cp/ * cp-tree.h (struct omp_begin_assumes_data): New type. (struct saved_scope): Add omp_begin_assumes member. * parser.cc: Include bitmap.h. (cp_parser_omp_assumption_clauses, cp_parser_omp_assume, cp_parser_omp_assumes, cp_parser_omp_begin): New functions. (cp_parser_omp_end_declare_target): Rename to ... (cp_parser_omp_end): ... this. Handle also end assumes. (cp_parser_omp_construct): Handle PRAGMA_OMP_ASSUME. (cp_parser_pragma): Handle PRAGMA_OMP_ASSUME, PRAGMA_OMP_ASSUMES and PRAGMA_OMP_BEGIN. Handle PRAGMA_OMP_END rather than PRAGMA_OMP_END_DECLARE_TARGET and call cp_parser_omp_end for it rather than cp_parser_omp_end_declare_target. * pt.cc (apply_late_template_attributes): Also temporarily clear omp_begin_assumes. * semantics.cc (finish_translation_unit): Also diagnose #pragma omp begin assumes without corresponding #pragma omp end assumes. gcc/testsuite/ * c-c++-common/gomp/assume-1.c: New test. * c-c++-common/gomp/assume-2.c: New test. * c-c++-common/gomp/assume-3.c: New test. * c-c++-common/gomp/assumes-1.c: New test. * c-c++-common/gomp/assumes-2.c: New test. * c-c++-common/gomp/assumes-3.c: New test. * c-c++-common/gomp/assumes-4.c: New test. * c-c++-common/gomp/begin-assumes-1.c: New test. * c-c++-common/gomp/begin-assumes-2.c: New test. * c-c++-common/gomp/begin-assumes-3.c: New test. * c-c++-common/gomp/begin-assumes-4.c: New test. * c-c++-common/gomp/declare-target-6.c: New test. * g++.dg/gomp/attrs-1.C (bar): Add n1 and n2 arguments, add tests for assume directive. * g++.dg/gomp/attrs-2.C (bar): Likewise. * g++.dg/gomp/attrs-9.C: Add n1 and n2 variables, add tests for begin assumes directive. * g++.dg/gomp/attrs-15.C: New test. * g++.dg/gomp/attrs-16.C: New test. * g++.dg/gomp/attrs-17.C: New test.
2022-09-27c++: Improve diagnostics about conflicting specifiersJakub Jelinek7-42/+71
On Sat, Sep 17, 2022 at 01:23:59AM +0200, Jason Merrill wrote: > I wonder why we don't give an error when setting the > conflicting_specifiers_p flag in cp_parser_set_storage_class? We should be > able to give a better diagnostic at that point. I didn't have time to update the whole patch last night, but this part seems to be independent and I've managed to test it. The diagnostics then looks like: a.C:1:9: error: ‘static’ specifier conflicts with ‘typedef’ 1 | typedef static int a; | ~~~~~~~ ^~~~~~ a.C:2:8: error: ‘typedef’ specifier conflicts with ‘static’ 2 | static typedef int b; | ~~~~~~ ^~~~~~~ a.C:3:8: error: duplicate ‘static’ specifier 3 | static static int c; | ~~~~~~ ^~~~~~ a.C:4:8: error: ‘extern’ specifier conflicts with ‘static’ 4 | static extern int d; | ~~~~~~ ^~~~~~ 2022-09-27 Jakub Jelinek <jakub@redhat.com> gcc/cp/ * parser.cc (cp_parser_lambda_declarator_opt): Don't diagnose conflicting specifiers here. (cp_storage_class_name): New variable. (cp_parser_decl_specifier_seq): When setting conflicting_specifiers_p for the first time, diagnose which exact specifiers conflict. (cp_parser_set_storage_class): Likewise. Move storage_class computation earlier. * decl.cc (grokdeclarator): Don't diagnose conflicting specifiers here, just return error_mark_node. gcc/testsuite/ * g++.dg/diagnostic/conflicting-specifiers-1.C: Adjust expected diagnostics. * g++.dg/parse/typedef8.C: Likewise. * g++.dg/parse/crash39.C: Likewise. * g++.dg/other/mult-stor1.C: Likewise. * g++.dg/cpp2a/constinit3.C: Likewise.
2022-09-27Fix ICEs due to recent jump-to-return optimizationJeff Law1-1/+2
gcc/ * cfgrtl.cc (fixup_reorder_chain): Verify that simple_return and return are available before trying to use them.
2022-09-27c++: Implement P1467R9 - Extended floating-point types and standard names ↵Jakub Jelinek32-100/+1573
compiler part except for bfloat16 [PR106652] The following patch implements the compiler part of C++23 P1467R9 - Extended floating-point types and standard names compiler part by introducing _Float{16,32,64,128} as keywords and builtin types like they are implemented for C already since GCC 7, with DF{16,32,64,128}_ mangling. It also introduces _Float{32,64,128}x for C++ with the https://github.com/itanium-cxx-abi/cxx-abi/pull/147 proposed mangling of DF{32,64,128}x. The patch doesn't add anything for bfloat16_t support, as right now __bf16 type refuses all conversions and arithmetic operations. The patch wants to keep backwards compatibility with how __float128 has been handled in C++ before, both for mangling and behavior in binary operations, overload resolution etc. So, there are some backend changes where for C __float128 and _Float128 are the same type (float128_type_node and float128t_type_node are the same pointer), but for C++ they are distinct types which mangle differently and _Float128 is treated as extended floating-point type while __float128 is treated as non-standard floating point type. The various C++23 changes about how floating-point types are changed are actually implemented as written in the spec only if at least one of the types involved is _Float{16,32,64,128,32x,64x,128x} (_FloatNx are also treated as extended floating-point types) and kept previous behavior otherwise. For float/double/long double the rules are actually written that they behave the same as before. There is some backwards incompatibility at least on x86 regarding _Float16, because that type was already used by that name and with the DF16_ mangling (but only since GCC 12 and I think it isn't that widely used in the wild yet). E.g. config/i386/avx512fp16intrin.h shows the issues, where in C or in GCC 12 in C++ one could pass 0.0f to a builtin taking _Float16 argument, but with the changes that is not possible anymore, one needs to either use 0.0f16 or (_Float16) 0.0f. We have also a problem with glibc headers, where since glibc 2.27 math.h and complex.h aren't compilable with these changes. One gets errors like: In file included from /usr/include/math.h:43, from abc.c:1: /usr/include/bits/floatn.h:86:9: error: multiple types in one declaration 86 | typedef __float128 _Float128; | ^~~~~~~~~~ /usr/include/bits/floatn.h:86:20: error: declaration does not declare anything [-fpermissive] 86 | typedef __float128 _Float128; | ^~~~~~~~~ In file included from /usr/include/bits/floatn.h:119: /usr/include/bits/floatn-common.h:214:9: error: multiple types in one declaration 214 | typedef float _Float32; | ^~~~~ /usr/include/bits/floatn-common.h:214:15: error: declaration does not declare anything [-fpermissive] 214 | typedef float _Float32; | ^~~~~~~~ /usr/include/bits/floatn-common.h:251:9: error: multiple types in one declaration 251 | typedef double _Float64; | ^~~~~~ /usr/include/bits/floatn-common.h:251:16: error: declaration does not declare anything [-fpermissive] 251 | typedef double _Float64; | ^~~~~~~~ This is from snippets like: /* The remaining of this file provides support for older compilers. */ # if __HAVE_FLOAT128 /* The type _Float128 exists only since GCC 7.0. */ # if !__GNUC_PREREQ (7, 0) || defined __cplusplus typedef __float128 _Float128; # endif where it hardcodes that C++ doesn't have _Float{16,32,64,128,32x,64x,128x} support nor {f,F}{16,32,64,128}{,x} literal suffixes nor _Complex _Float{16,32,64,128,32x,64x,128x}. The patch fixincludes this for now and hopefully if this is committed, then glibc can change those. The patch changes those # if !__GNUC_PREREQ (7, 0) || defined __cplusplus conditions to # if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0)) Another thing is mangling, as said above, Itanium C++ ABI specifies DF <number> _ as _Float{16,32,64,128} mangling, but GCC was implementing a mangling incompatible with that starting with DF for fixed point types. Fixed point was never supported in C++ though, I believe the reason why the mangling has been added was that due to a bug it would leak into the C++ FE through decltype (0.0r) etc. But that has been shortly after the mangling was added fixed (I think in the same GCC release cycle), so we now reject 0.0r etc. in C++. If we ever need the fixed point mangling, I think it can be readded but better with a different prefix so that it doesn't conflict with the published standard manglings. So, this patch also kills the fixed point mangling and implements the DF <number> _ demangling. The patch predefines __STDCPP_FLOAT{16,32,64,128}_T__ macros when those types are available, but only for C++23, while the underlying types are available in C++98 and later including the {f,F}{16,32,64,128} literal suffixes (but those with a pedwarn for C++20 and earlier). My understanding is that it needs to be predefined by the compiler, on the other side predefining even for older modes when <stdfloat> is a new C++23 header would be weird. One can find out if _Float{16,32,64,128,32x,64x,128x} is supported in C++ by __GNUC__ >= 13 && defined(__FLT{16,32,64,128,32X,64X,128X}_MANT_DIG__) (but that doesn't work well with older G++ 13 snapshots). As for std::bfloat16_t, three targets (aarch64, arm and x86) apparently "support" __bf16 type which has the bfloat16 format, but isn't really usable, e.g. {aarch64,arm,ix86}_invalid_conversion disallow any conversions from or to type with BFmode, {aarch64,arm,ix86}_invalid_unary_op disallows any unary operations on those except for ADDR_EXPR and {aarch64,arm,ix86}_invalid_binary_op disallows any binary operation on those. So, I think we satisfy: "If the implementation supports an extended floating-point type with the properties, as specified by ISO/IEC/IEEE 60559, of radix (b) of 2, storage width in bits (k) of 16, precision in bits (p) of 8, maximum exponent (emax) of 127, and exponent field width in bits (w) of 8, then the typedef-name std::bfloat16_t is defined in the header <stdfloat> and names such a type, the macro __STDCPP_BFLOAT16_T__ is defined, and the floating-point literal suffixes bf16 and BF16 are supported." because we don't really support those right now. 2022-09-27 Jakub Jelinek <jakub@redhat.com> PR c++/106652 PR c++/85518 gcc/ * tree-core.h (enum tree_index): Add TI_FLOAT128T_TYPE enumerator. * tree.h (float128t_type_node): Define. * tree.cc (build_common_tree_nodes): Initialize float128t_type_node. * builtins.def (DEF_FLOATN_BUILTIN): Adjust comment now that _Float<N> is supported in C++ too. * config/i386/i386.cc (ix86_mangle_type): Only mangle as "g" float128t_type_node. * config/i386/i386-builtins.cc (ix86_init_builtin_types): Use float128t_type_node for __float128 instead of float128_type_node and create it if NULL. * config/i386/avx512fp16intrin.h (_mm_setzero_ph, _mm256_setzero_ph, _mm512_setzero_ph, _mm_set_sh, _mm_load_sh): Use 0.0f16 instead of 0.0f. * config/ia64/ia64.cc (ia64_init_builtins): Use float128t_type_node for __float128 instead of float128_type_node and create it if NULL. * config/rs6000/rs6000-c.cc (is_float128_p): Also return true for float128t_type_node if non-NULL. * config/rs6000/rs6000.cc (rs6000_mangle_type): Don't mangle float128_type_node as "u9__ieee128". * config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Use float128t_type_node for __float128 instead of float128_type_node and create it if NULL. gcc/c-family/ * c-common.cc (c_common_reswords): Change _Float{16,32,64,128} and _Float{32,64,128}x flags from D_CONLY to 0. (shorten_binary_op): Punt if common_type returns error_mark_node. (shorten_compare): Likewise. (c_common_nodes_and_builtins): For C++ record _Float{16,32,64,128} and _Float{32,64,128}x builtin types if available. For C++ clear float128t_type_node. * c-cppbuiltin.cc (c_cpp_builtins): Predefine __STDCPP_FLOAT{16,32,64,128}_T__ for C++23 if supported. * c-lex.cc (interpret_float): For q/Q suffixes prefer float128t_type_node over float128_type_node. Allow {f,F}{16,32,64,128} suffixes for C++ if supported with pedwarn for C++20 and older. Allow {f,F}{32,64,128}x suffixes for C++ with pedwarn. Don't call excess_precision_type for C++. gcc/cp/ * cp-tree.h (cp_compare_floating_point_conversion_ranks): Implement P1467R9 - Extended floating-point types and standard names except for std::bfloat16_t for now. Declare. (extended_float_type_p): New inline function. * mangle.cc (write_builtin_type): Mangle float{16,32,64,128}_type_node as DF{16,32,64,128}_. Mangle float{32,64,128}x_type_node as DF{32,64,128}x. Remove FIXED_POINT_TYPE mangling that conflicts with that. * typeck2.cc (check_narrowing): If one of ftype or type is extended floating-point type, compare floating-point conversion ranks. * parser.cc (cp_keyword_starts_decl_specifier_p): Handle CASE_RID_FLOATN_NX. (cp_parser_simple_type_specifier): Likewise and diagnose missing _Float<N> or _Float<N>x support if not supported by target. * typeck.cc (cp_compare_floating_point_conversion_ranks): New function. (cp_common_type): If both types are REAL_TYPE and one or both are extended floating-point types, select common type based on comparison of floating-point conversion ranks and subranks. (cp_build_binary_op): Diagnose operation with floating point arguments with unordered conversion ranks. * call.cc (standard_conversion): For floating-point conversion, if either from or to are extended floating-point types, set conv->bad_p for implicit conversion from larger to smaller conversion rank or with unordered conversion ranks. (convert_like_internal): Emit a pedwarn on such conversions. (build_conditional_expr): Diagnose operation with floating point arguments with unordered conversion ranks. (convert_arg_to_ellipsis): Don't promote extended floating-point types narrower than double to double. (compare_ics): Implement P1467R9 [over.ics.rank]/4 changes. gcc/testsuite/ * g++.dg/cpp23/ext-floating1.C: New test. * g++.dg/cpp23/ext-floating2.C: New test. * g++.dg/cpp23/ext-floating3.C: New test. * g++.dg/cpp23/ext-floating4.C: New test. * g++.dg/cpp23/ext-floating5.C: New test. * g++.dg/cpp23/ext-floating6.C: New test. * g++.dg/cpp23/ext-floating7.C: New test. * g++.dg/cpp23/ext-floating8.C: New test. * g++.dg/cpp23/ext-floating9.C: New test. * g++.dg/cpp23/ext-floating10.C: New test. * g++.dg/cpp23/ext-floating.h: New file. * g++.target/i386/float16-1.C: Adjust expected diagnostics. libcpp/ * expr.cc (interpret_float_suffix): Allow {f,F}{16,32,64,128} and {f,F}{32,64,128}x suffixes for C++. include/ * demangle.h (enum demangle_component_type): Add DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE. (struct demangle_component): Add u.s_extended_builtin member. libiberty/ * cp-demangle.c (d_dump): Handle DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE. Don't handle DEMANGLE_COMPONENT_FIXED_TYPE. (d_make_extended_builtin_type): New function. (cplus_demangle_builtin_types): Add _Float entry. (cplus_demangle_type): For DF demangle it as _Float<N> or _Float<N>x rather than fixed point which conflicts with it. (d_count_templates_scopes): Handle DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE. Just break; for DEMANGLE_COMPONENT_FIXED_TYPE. (d_find_pack): Handle DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE. Don't handle DEMANGLE_COMPONENT_FIXED_TYPE. (d_print_comp_inner): Likewise. * cp-demangle.h (D_BUILTIN_TYPE_COUNT): Bump. * testsuite/demangle-expected: Replace _Z3xxxDFyuVb test with _Z3xxxDF16_DF32_DF64_DF128_CDF16_Vb. Add _Z3xxxDF32xDF64xDF128xCDF32xVb test. fixincludes/ * inclhack.def (glibc_cxx_floatn_1, glibc_cxx_floatn_2, glibc_cxx_floatn_3): New fixes. * tests/base/bits/floatn.h: New file. * fixincl.x: Regenerated.
2022-09-26testsuite/rust: add a testcase for testing ...liushuyu1-0/+21
... builtin macro and decl macro mixed expansion
2022-09-26testsuite: adapt existing testcasesliushuyu2-3/+2
2022-09-26expand: eager evaluate macros inside builtin macrosliushuyu5-49/+181
2022-09-27Daily bump.GCC Administrator6-1/+303
2022-09-26docs: add missing dash in option nameMartin Liska1-1/+1
gcc/ChangeLog: * doc/invoke.texi: Add missing dash for Wanalyzer-exposure-through-uninit-copy.
2022-09-26c++: P2513R4, char8_t Compatibility and Portability Fix [PR106656]Marek Polacek8-9/+72
P0482R6, which added char8_t, didn't allow const char arr[] = u8"howdy"; because it said "Declarations of arrays of char may currently be initialized with UTF-8 string literals. Under this proposal, such initializations would become ill-formed." This caused too many issues, so P2513R4 alleviates some of those compatibility problems. In particular, "Arrays of char or unsigned char may now be initialized with a UTF-8 string literal." This restriction has been lifted for initialization only, not implicit conversions. Also, my reading is that 'signed char' was excluded from the allowable conversions. This is supposed to be treated as a DR in C++20. PR c++/106656 gcc/c-family/ChangeLog: * c-cppbuiltin.cc (c_cpp_builtins): Update value of __cpp_char8_t for C++20. gcc/cp/ChangeLog: * typeck2.cc (array_string_literal_compatible_p): Allow initializing arrays of char or unsigned char by a UTF-8 string literal. gcc/testsuite/ChangeLog: * g++.dg/cpp23/feat-cxx2b.C: Adjust. * g++.dg/cpp2a/feat-cxx2a.C: Likewise. * g++.dg/ext/char8_t-feature-test-macro-2.C: Likewise. * g++.dg/ext/char8_t-init-2.C: Likewise. * g++.dg/cpp2a/char8_t3.C: New test. * g++.dg/cpp2a/char8_t4.C: New test.
2022-09-26Optimize [0 = x & MASK] in range-ops.Aldy Hernandez1-0/+18
For [0 = x & MASK], we can determine that x is ~MASK. This is something we're picking up in DOM thanks to maybe_set_nonzero_bits, but is something we should handle natively. This is a good example of how much easier to maintain the range-ops entries are versus the ad-hoc pattern matching stuff we had to do before. For the curious, compare the changes to range-op here, versus maybe_set_nonzero_bits. I'm leaving the call to maybe_set_nonzero_bits until I can properly audit it to make sure we're catching it all in range-ops. It won't hurt, since both set_range_info() and set_nonzero_bits() are intersect operations, so we'll never lose information if we do both. PR tree-optimization/107009 gcc/ChangeLog: * range-op.cc (operator_bitwise_and::op1_range): Optimize 0 = x & MASK. (range_op_bitwise_and_tests): New test.
2022-09-26c++: Instantiate less when evaluating __is_convertibleMarek Polacek3-8/+33
Jon reported that evaluating __is_convertible in a test led to instantiating something ill-formed and so we failed to compile the test. __is_convertible doesn't and shouldn't need to instantiate so much, so let's limit it with a cp_unevaluated guard. Use a helper function to implement both built-ins. PR c++/106784 gcc/cp/ChangeLog: * method.cc (is_convertible_helper): New. (is_convertible): Use it. (is_nothrow_convertible): Likewise. gcc/testsuite/ChangeLog: * g++.dg/ext/is_convertible3.C: New test. * g++.dg/ext/is_nothrow_convertible3.C: New test.
2022-09-26c++ modules: variable template partial spec fixes [PR107033]Patrick Palka8-62/+82
In r13-2775-g32d8123cd6ce87 I missed that we need to adjust the call to add_mergeable_specialization in the MK_partial case to correctly handle variable template partial specializations (it currently assumes we're always dealing with one for a class template). This fixes an ICE when converting the testcase from that commit to use an importable header instead of a named module. PR c++/107033 gcc/cp/ChangeLog: * module.cc (trees_in::decl_value): In the MK_partial case for a variable template partial specialization, pass decl_p=true to add_mergeable_specialization, and set spec to the VAR_DECL not the TEMPLATE_DECL. * pt.cc (add_mergeable_specialization): For a variable template partial specialization, set the TREE_TYPE of the new DECL_TEMPLATE_SPECIALIZATIONS node to the TREE_TYPE of the VAR_DECL not the VAR_DECL itself. gcc/testsuite/ChangeLog: * g++.dg/modules/partial-2.cc, g++.dg/modules/partial-2.h: New files, factored out from ... * g++.dg/modules/partial-2_a.C, g++.dg/modules/partial-2_b.C: ... these. * g++.dg/modules/partial-2_c.H: New test. * g++.dg/modules/partial-2_d.C: New test.
2022-09-26Set ranges from unreachable edges for all known ranges.Aldy Hernandez2-17/+33
In the conversion of DOM+evrp to DOM+ranger, we missed that evrp was exporting ranges for unreachable edges for all SSA names for which we have ranges for. Instead we have only been exporting ranges for the SSA name in the final conditional to the BB involving the unreachable edge. This patch adjusts adjusts DOM to iterate over the exports, similarly to what evrp was doing. Note that I also noticed that we don't calculate the nonzero bit mask for op1, when 0 = op1 & MASK. This isn't needed for this PR, since maybe_set_nonzero_bits() is chasing the definition and parsing the bitwise and on its own. However, I'll be adding the functionality for completeness sake, plus we could probably drop the maybe_set_nonzero_bits legacy call entirely. PR tree-optimization/107009 gcc/ChangeLog: * tree-ssa-dom.cc (dom_opt_dom_walker::set_global_ranges_from_unreachable_edges): Iterate over exports. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr107009.c: New test.
2022-09-26nvptx: Allow '--with-arch' to override the default '-misa'Thomas Schwinge5-6/+93
gcc/ * config.gcc (with_arch) [nvptx]: Allow '--with-arch' to override the default. * config/nvptx/gen-multilib-matches.sh: New. * config/nvptx/t-nvptx (MULTILIB_OPTIONS, MULTILIB_MATCHES) (MULTILIB_EXCEPTIONS): Handle this. * doc/install.texi (Specific) <nvptx-*-none>: Document this. * doc/invoke.texi (Nvidia PTX Options): Likewise.
2022-09-26nvptx: Introduce dummy multilib option for default '-misa=sm_30'Thomas Schwinge2-1/+20
... primarily in preparation for later changes. gcc/ * config.gcc (TM_MULTILIB_CONFIG) [nvptx]: Set to '$with_arch'. * config/nvptx/t-nvptx (MULTILIB_OPTIONS, MULTILIB_MATCHES) (MULTILIB_EXCEPTIONS): Handle it.
2022-09-26nvptx: Make default '-misa=sm_30' explicitThomas Schwinge4-1/+25
... primarily in preparation for later changes. gcc/ * config.gcc (with_arch) [nvptx]: Set to 'sm_30'. * config/nvptx/nvptx.cc (nvptx_option_override): Assert that '-misa' appeared. * config/nvptx/nvptx.h (OPTION_DEFAULT_SPECS): Define. * config/nvptx/nvptx.opt (misa=): Remove 'Init'.
2022-09-26nvptx: forward '-v' command-line option to assemblerThomas Schwinge1-0/+4
For example, for offloading compilation with '-save-temps -v', before vs. after word-diff then looks like: [...] [...]/build-gcc-offload-nvptx-none/gcc/as {+-v -v+} -o ./a.xnvptx-none.mkoffload.o ./a.xnvptx-none.mkoffload.s {+Verifying sm_30 code with sm_35 code generation.+} {+ ptxas -c -o /dev/null ./a.xnvptx-none.mkoffload.o --gpu-name sm_35 -O0+} [...] (This depends on <https://github.com/MentorEmbedded/nvptx-tools/pull/37> "Put '-v' verbose output onto stderr instead of stdout".) gcc/ * config/nvptx/nvptx.h (ASM_SPEC): Define.
2022-09-26[RFA] Minor improvement to coremark, avoid unconditional jump to returnJeff Law4-2/+71
gcc/ * cfgcleanup.cc (bb_is_just_return): No longer static. * cfgcleanup.h (bb_is_just_return): Add prototype. * cfgrtl.cc (fixup_reorder_chain): Do not create an unconditional jump to a return block. Conditionally remove unreachable blocks. gcc/testsuite/ * gcc.target/riscv/ret-1.c: New test.
2022-09-26OpenACC: Fix reduction tree-sharing issue [PR106982]Tobias Burnus3-8/+45
The tree for var == incoming == outgound was 'MEM <double[5]> [(double *)&reduced]' which caused the ICE "incorrect sharing of tree nodes". PR middle-end/106982 gcc/ChangeLog: * omp-low.cc (lower_oacc_reductions): Add some unshare_expr. gcc/testsuite/ChangeLog: * c-c++-common/goacc/reduction-7.c: New test. * c-c++-common/goacc/reduction-8.c: New test.
2022-09-26s390: fix wrong refactoringMartin Liska1-8/+7
Since r13-2251-g1930c5d05ceff2, the refactoring is not 1:1 and we end up with a wrong rtx type. gcc/ChangeLog: * config/s390/s390.cc (s390_rtx_costs): Remove dest variable and use only dst.
2022-09-26Merge #1542bors[bot]1300-128171/+127455
1542: Merge GCC mainline/master into gccrs/master r=philberty a=ibuclaw As per title, pull in the latest and greatest from gcc development. Co-authored-by: Tim Lange <mail@tim-lange.me> Co-authored-by: GCC Administrator <gccadmin@gcc.gnu.org> Co-authored-by: Martin Liska <mliska@suse.cz> Co-authored-by: Javier Miranda <miranda@adacore.com> Co-authored-by: Bob Duff <duff@adacore.com> Co-authored-by: Patrick Bernardi <bernardi@adacore.com> Co-authored-by: Steve Baird <baird@adacore.com> Co-authored-by: Gary Dismukes <dismukes@adacore.com> Co-authored-by: Eric Botcazou <ebotcazou@adacore.com> Co-authored-by: Justin Squirek <squirek@adacore.com> Co-authored-by: Piotr Trojanek <trojanek@adacore.com> Co-authored-by: Joffrey Huguet <huguet@adacore.com> Co-authored-by: Yannick Moy <moy@adacore.com>
2022-09-26aarch64: Add -march support for Armv9.1-A, Armv9.2-A, Armv9.3-AKyrylo Tkachov3-0/+24
This is a straightforward patch that allows targeting the architecture revisions mentioned in the subject through -march. These are already supported in binutils. Bootstrapped and tested on aarch64-none-linux-gnu. gcc/ChangeLog: * config/aarch64/aarch64-arches.def (armv9.1-a): Define. (armv9.2-a): Likewise. (armv9.3-a): Likewise. * config/aarch64/aarch64.h (AARCH64_FL_V9_1): Likewise. (AARCH64_FL_V9_2): Likewise. (AARCH64_FL_V9_3): Likewise. (AARCH64_FL_FOR_ARCH9_1): Likewise. (AARCH64_FL_FOR_ARCH9_2): Likewise. (AARCH64_FL_FOR_ARCH9_3): Likewise. (AARCH64_ISA_V9_1): Likewise. (AARCH64_ISA_V9_2): Likewise. (AARCH64_ISA_V9_3): Likewise. * doc/invoke.texi (AArch64 Options): Document armv9.1-a, armv9.2-a, armv9.3-a values to -march.