- Nov 18, 2022
-
-
Richard Purdie authored
Code such as: #include __FILE__ can interact poorly with the *-prefix-map options when cross compiling. In general you're after to remap filenames for use in target context but the local paths should be used to find include files at compile time. Ingoring filename remapping for directives allows avoiding such failures. Fix this to improve such usage and then document this against file-prefix-map (referenced by the other *-prefix-map options) to make the behaviour clear and defined. libcpp/ChangeLog: * macro.cc (_cpp_builtin_macro_text): Don't remap filenames within directives. gcc/ChangeLog: * doc/invoke.texi: Document prefix-maps don't affect directives.
-
Jakub Jelinek authored
Aldo, replace some invalid tab + 2 spaces with just tab.
-
Harald Anlauf authored
gcc/fortran/ChangeLog: PR fortran/107576 * interface.cc (gfc_procedure_use): Reject NULL as actual argument when there is no explicit procedure interface. gcc/testsuite/ChangeLog: PR fortran/107576 * gfortran.dg/null_actual_3.f90: New test.
-
GCC Administrator authored
-
Jakub Jelinek authored
We can't handle r13-4128-g1957bedf29a1b2cc231972aba680fe80199d5498 * gcc-changelog/git_update_version.py: Add 1957bedf to ignored commits.
-
Andrew Pinski authored
The problem here is after we created a call expression in the C front-end, we replace the decl type with an error mark node. We then end up calling aggregate_value_p with the call expression with the decl with the error mark as the type and we ICE. The fix is to check the function type after we process the call expression inside aggregate_value_p to get it. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. Thanks, Andrew Pinski gcc/ChangeLog: PR middle-end/107705 * function.cc (aggregate_value_p): Return 0 if the function type was an error operand. gcc/testsuite/ChangeLog: * gcc.dg/redecl-22.c: New test.
-
Andrew Pinski authored
The problem here is the gimplifier returns GS_ERROR but in some cases we don't check that soon enough and try to do other work which could crash. So the fix in these two cases is to return GS_ERROR early if the gimplify_* functions had return GS_ERROR. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. Thanks, Andrew Pinski gcc/ChangeLog: PR c/106764 PR c/106765 PR c/107307 * gimplify.cc (gimplify_compound_lval): Return GS_ERROR if gimplify_expr had return GS_ERROR. (gimplify_call_expr): Likewise. gcc/testsuite/ChangeLog: PR c/106764 PR c/106765 PR c/107307 * gcc.dg/redecl-19.c: New test. * gcc.dg/redecl-20.c: New test. * gcc.dg/redecl-21.c: New test.
-
Yixuan Chen authored
gcc/testsuite: * gcc.dg/pr25521.c: Fix testcase for architectures that use .srodata.
-
Kyrylo Tkachov authored
... And another follow-up once I realised that the sign-extending load, of course, needs to have strictly an X-reg as a destination for DImode extensions and a W-reg for SImode ones. Tested on aarch64-none-linux. gcc/ChangeLog: * config/aarch64/atomics.md (*aarch64_atomic_load<ALLX:mode>_rcpc_sext): Use <GPI:w> for destination format. * config/aarch64/iterators.md (w_sz): Delete. gcc/testsuite/ChangeLog: * gcc.target/aarch64/ldapr-sext.c: Adjust expected output.
-
Torbjörn SVENSSON authored
For some test cases, it's required that the optional module mapper "g++-mapper-server" is built. As the server is not required, the test cases will fail if it can't be found. gcc/testsuite/ChangeLog: * lib/target-supports.exp (check_is_prog_name_available): New. * lib/target-supports-dg.exp (dg-require-prog-name-available): New. * g++.dg/modules/modules.exp: Verify avilability of module mapper. Signed-off-by:
Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
-
Kyrylo Tkachov authored
Upon some further inspection I realised I had misunderstood some intricacies of the extending loads of the RCPC feature. This patch fixes up the recent GCC support accordingly. In particular: * The sign-extending forms are a form of LDAPURS* and are actually part of FEAT_RCPC2 that is enabled with Armv8.4-a rather than the base Armv8.3-a FEAT_RCPC. The patch introduces a TARGET_RCPC2 macro and gates this combine pattern accordingly. * The assembly output for the zero-extending LDAPR instruction should always use %w formatting for its destination register. The testcase is split into zero-extending and sign-extending parts since they require different architecture pragmas. It's also straightforward to add the rest of the FEAT_RCPC2 codegen (with immediate offset addressing modes) but that can be done as a separate patch. Apologies for not catching this sooner, but it hasn't been in trunk long, so no harm done. Bootstrapped and tested on aarch64-none-linux-gnu. gcc/ChangeLog: * config/aarch64/aarch64.h (TARGET_RCPC2): Define. * config/aarch64/atomics.md (*aarch64_atomic_load<ALLX:mode>_rcpc_zext): Adjust output template. (*aarch64_atomic_load<ALLX:mode>_rcpc_sex): Guard on TARGET_RCPC2. Adjust output template. * config/aarch64/iterators.md (w_sz): New mode attr. gcc/testsuite/ChangeLog: * gcc.target/aarch64/ldapr-ext.c: Rename to... * gcc.target/aarch64/ldapr-zext.c: ... This. Fix expected assembly. * gcc.target/aarch64/ldapr-sext.c: New test.
-
Jakub Jelinek authored
The following patch implements CWG2635. 2022-11-18 Jakub Jelinek <jakub@redhat.com> * decl.cc (grokdeclarator): Implement CWG2635 - Constrained structured bindings. Emit a pedwarn on constrained auto type. Add auto_diagnostic_group for error_at and inform for non-auto type on structured bindings declaration. * g++.dg/cpp2a/decomp5.C: New test. * g++.dg/cpp2a/decomp6.C: New test. * g++.dg/cpp2a/decomp7.C: New test. * g++.dg/cpp2a/concepts-placeholder7.C: Adjust expected diagnostics. * g++.dg/cpp2a/concepts-placeholder8.C: Likewise. * g++.dg/cpp2a/concepts-placeholder9.C: New test. * g++.dg/cpp2a/concepts-placeholder10.C: New test.
-
Richard Biener authored
Only with -ffp-contract=fast we can synthesize FMA operations like vfmaddsub231ps, so properly guard the transform in SLP pattern detection. PR tree-optimization/107647 * tree-vect-slp-patterns.cc (addsub_pattern::recognize): Only allow FMA generation with -ffp-contract=fast for FP types. (complex_mul_pattern::matches): Likewise. * gcc.target/i386/pr107647.c: New testcase.
-
Jinyang He authored
We used to expand atomic_exchange_n(ptr, new, mem_order) for subword types into something like: { __typeof__(*ptr) t = atomic_load_n(ptr, mem_order); atomic_compare_exchange_n(ptr, &t, new, true, mem_order, mem_order); return t; } It's incorrect because another thread may store a different value into *ptr after atomic_load_n. Then atomic_compare_exchange_n will not store into *ptr, but atomic_exchange_n should always perform the store. gcc/ChangeLog: PR target/107713 * config/loongarch/sync.md (atomic_cas_value_exchange_7_<mode>): New define_insn. (atomic_exchange): Use atomic_cas_value_exchange_7_si instead of atomic_cas_value_cmp_and_7_si. gcc/testsuite/ChangeLog: PR target/107713 * gcc.target/loongarch/pr107713-1.c: New test. * gcc.target/loongarch/pr107713-2.c: New test.
-
Marek Polacek authored
[dcl.constinit]: "The constinit specifier shall be applied only to a declaration of a variable with static or thread storage duration." Thus, this ought to be OK: constinit void (*p)() = nullptr; but the error message I introduced when implementing constinit was not looking at funcdecl_p, so the code above was rejected. Fixed thus. I'm checking constinit_p first because I think that's far more likely to be false than funcdecl_p. PR c++/104066 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Check funcdecl_p before complaining about constinit. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/constinit18.C: New test.
-
- Nov 17, 2022
-
-
Bernhard Reutner-Fischer authored
gcc/c/ChangeLog: * c-decl.cc (start_function): Set the result decl source location to the location of the typespec.
-
Bernhard Reutner-Fischer authored
gcc/fortran/ChangeLog: PR fortran/99884 * io.cc (check_open_constraints): Remove double spaces.
-
Andrew Pinski authored
sbitmap is a simple bitmap and the memory allocated is not cleared on creation; you have to clear it or set it to all ones before using it. This is unlike bitmap which is a sparse bitmap and the entries are cleared as created. The code added in r13-4044-gdc95e1e9702f2f missed that. This patch fixes that mistake. Committed as obvious after a bootstrap and test on x86_64-linux-gnu. gcc/ChangeLog: PR middle-end/107734 * match.pd (perm + vector op pattern): Clear the sbitmap before use.
-
Aldy Hernandez authored
The threader is creating a scenario where we are trying to solve: [NEGATIVES] = abs(x) While solving this we have an intermediate value of UNDEFINED because we have no positive numbers. But then we try to union the negative pair to the final result by querying the bounds. Since neither UNDEFINED nor NAN have bounds, they need to be specially handled. PR tree-optimization/107732 gcc/ChangeLog: * range-op-float.cc (foperator_abs::op1_range): Early exit when result is undefined. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/pr107732.c: New test.
-
David Malcolm authored
PR analyzer/107711 reports an ICE since r13-4073-gd8aba860b34203 with the combination of -fanalyzer and -Wunused-macros. The issue is that in c_translation_unit::consider_macro's call to cpp_create_reader I was passing "ident_hash" for use by the the new reader, but that takes ownership of that hash_table, so that ident_hash erroneously gets freed when c_translation_unit::consider_macro calls cpp_destroy, leading to a use-after-free in -Wunused-macros, where: (gdb) p pfile->hash_table->pfile == pfile $23 = false and it's instead pointing at the freed reader from consider_macro, leading to a use-after-free ICE. Fixed thusly. gcc/c/ChangeLog: PR analyzer/107711 * c-parser.cc (ana::c_translation_unit::consider_macro): Pass NULL to cpp_create_reader, rather than ident_hash, so that the new reader gets its own hash table. gcc/testsuite/ChangeLog: PR analyzer/107711 * gcc.dg/analyzer/named-constants-Wunused-macros.c: New test. Signed-off-by:
David Malcolm <dmalcolm@redhat.com>
-
Philipp Tomsich authored
Add a split for cases where we can use two bclri (or one bclri and an andi) to clear two bits. gcc/ChangeLog: * config/riscv/bitmanip.md (*bclri<mode>_nottwobits): New pattern. (*bclridisi_nottwobits): New pattern, handling the sign-bit. * config/riscv/predicates.md (const_nottwobits_operand): New predicate. gcc/testsuite/ChangeLog: * gcc.target/riscv/zbs-bclri.c: New test.
-
Philipp Tomsich authored
Consider creating a polarity-reversed mask from a set-bit (i.e., if the bit is set, produce all-ones; otherwise: all-zeros). Using Zbb, this can be expressed as bexti, followed by an addi of minus-one. To enable the combiner to discover this opportunity, we need to split the canonical expression for "(a & (1 << BIT_NO)) ? 0 : -1" into a form combinable into bexti. Consider the function: long f(long a) { return (a & (1 << BIT_NO)) ? 0 : -1; } This produces the following sequence prior to this change: andi a0,a0,16 seqz a0,a0 neg a0,a0 ret Following this change, it results in: bexti a0,a0,4 addi a0,a0,-1 ret gcc/ChangeLog: * config/riscv/bitmanip.md: Add a splitter to generate polarity-reversed masks from a set bit using bexti + addi. gcc/testsuite/ChangeLog: * gcc.target/riscv/zbs-bexti.c: New test.
-
mtsamis authored
This commit implements the target macros (TARGET_SHRINK_WRAP_*) that enable separate shrink wrapping for function prologues/epilogues in RISC-V. Tested against SPEC CPU 2017, this change always has a net-positive effect on the dynamic instruction count. See the following table for the breakdown on how this reduces the number of dynamic instructions per workload on a like-for-like (i.e., same config file; suppressing shrink-wrapping with -fno-shrink-wrap): # dynamic instructions w/o shrink-wrap w/ shrink-wrap reduction 500.perlbench_r 1265716786593 1262156218578 3560568015 0.28% 500.perlbench_r 779224795689 765337009025 13887786664 1.78% 500.perlbench_r 724087331471 711307152522 12780178949 1.77% 502.gcc_r 204259864844 194517006339 9742858505 4.77% 502.gcc_r 244047794302 231555834722 12491959580 5.12% 502.gcc_r 230896069400 221877703011 9018366389 3.91% 502.gcc_r 192130616624 183856450605 8274166019 4.31% 502.gcc_r 258875074079 247756203226 11118870853 4.30% 505.mcf_r 662653430325 660678680547 1974749778 0.30% 520.omnetpp_r 985114167068 934191310154 50922856914 5.17% 523.xalancbmk_r 927037633578 921688937650 5348695928 0.58% 525.x264_r 490953958454 490565583447 388375007 0.08% 525.x264_r 1994662294421 1993171932425 1490361996 0.07% 525.x264_r 1897617120450 1896062750609 1554369841 0.08% 531.deepsjeng_r 1695189878907 1669304130411 25885748496 1.53% 541.leela_r 1925941222222 1897900861198 28040361024 1.46% 548.exchange2_r 2073816227944 2073816226729 1215 0.00% 557.xz_r 379572090003 379057409041 514680962 0.14% 557.xz_r 953117469352 952680431430 437037922 0.05% 557.xz_r 536859579650 536456690164 402889486 0.08% 18421773405376 18223938521833 197834883543 1.07% totals Signed-off-by:
Manolis Tsamis <manolis.tsamis@vrull.eu> gcc/ChangeLog: * config/riscv/riscv.cc (struct machine_function): Add array to store register wrapping information. (riscv_for_each_saved_reg): Skip registers that are wrapped separetely. (riscv_get_separate_components): New function. (riscv_components_for_bb): Likewise. (riscv_disqualify_components): Likewise. (riscv_process_components): Likewise. (riscv_emit_prologue_components): Likewise. (riscv_emit_epilogue_components): Likewise. (riscv_set_handled_components): Likewise. (TARGET_SHRINK_WRAP_GET_SEPARATE_COMPONENTS): Define. (TARGET_SHRINK_WRAP_COMPONENTS_FOR_BB): Likewise. (TARGET_SHRINK_WRAP_DISQUALIFY_COMPONENTS): Likewise. (TARGET_SHRINK_WRAP_EMIT_PROLOGUE_COMPONENTS): Likewise. (TARGET_SHRINK_WRAP_EMIT_EPILOGUE_COMPONENTS): Likewise. (TARGET_SHRINK_WRAP_SET_HANDLED_COMPONENTS): Likewise. gcc/testsuite/ChangeLog: * gcc.target/riscv/shrink-wrap-1.c: New test.
-
Kyrylo Tkachov authored
Add an extra safety check as suggested by Richard. Tested on aarch64-none-linux-gnu. gcc/ChangeLog: * config/aarch64/atomics.md (*aarch64_atomic_load<ALLX:mode>_rcpc_zext): Add mode size check to condition. (*aarch64_atomic_load<ALLX:mode>_rcpc_sext): Likewise.
-
Aldy Hernandez authored
It irks me that a PR named "we should track ranges for floating-point hasn't been closed in this release. This is an attempt to do just that. As mentioned in the PR, even though we track ranges for floats, it has been suggested that avoiding recursing through SSA defs in gimple_assign_nonnegative_warnv_p is also a goal. This patch uses a global range query (no on-demand lookups, just global ranges and minimal folding) to determine if the range of a statement is known to be non-negative. PR tree-optimization/68097 gcc/ChangeLog: * gimple-fold.cc (gimple_stmt_nonnegative_warnv_p): Call range_of_stmt for floats.
-
Lili Cui authored
gcc/ChangeLog: * config/i386/x86-tune.def (X86_TUNE_AVX256_MOVE_BY_PIECES): Add alderlake. (X86_TUNE_AVX256_STORE_BY_PIECES): Ditto. gcc/testsuite/ChangeLog: * gcc.target/i386/pieces-memset-50.c: New test.
-
Tamar Christina authored
At the moment when the VEC_PERMs generated by this match.pd rule is generated it creates two different SSA_NAMEs for the folded operand. Because of this it the permute switches from a single operand permute to a two operand permute and the target may no longer support a permute for this. This fixes it by ensuring we generate the same SSA_NAME for both operands. gcc/ChangeLog: PR tree-optimization/107717 * match.pd: Ensure same SSA_NAME. gcc/testsuite/ChangeLog: PR tree-optimization/107717 * gcc.target/aarch64/sve2/pr107717.c: New test.
-
Tamar Christina authored
After the fix to the addsub patch yesterday for bootstrap I had only regtested on x86. While looking today it seemed the new tests were failing, this was caused by a change in the behavior of the GET_MODE_WIDER_MODE macro on trunk. gcc/ChangeLog: * match.pd: Replace GET_MODE_WIDER_MODE with custom code.
-
Aldy Hernandez authored
gcc/ChangeLog: * range-op-float.cc (range_operator_float::fold_range): Make check for maybe_isnan more readable.
-
Kewen Lin authored
As Robin spotted, my recent commit r13-3716 caused an ICE on s390 if vector access with length is enabled there (his patch for the enablement hasn't been committed yet). The failure is caused by one stupid typo, the bias on s390 is -1, so the assertion should use tree_fits_shwi_p rather than tree_fits_uhwi_p. Thanks for Robin's catching. I just reproduced the ICE and verified the fix worked fine with a cross build, the optimized dump against the test case gcc.target/powerpc/pr107412.c looked expected. gcc/ChangeLog: * gimple-fold.cc (gimple_fold_partial_load_store_mem_ref): Use tree_fits_shwi_p rather than tree_fits_uhwi_p as bias is signed.
-
Jia-Wei Chen authored
Sometimes "step1 -= scalable_frame" will cause adjust equal to zero. And it will generate additional redundant instruction "addi sp,sp,0". Add checking segement to skip that case. This testcase mix exist spill-1.c and adding new fun to check if there have redundant addi intructions. Idea provided by Jeff Law. gcc/ChangeLog: * config/riscv/riscv.cc (riscv_expand_epilogue): Do not emit useless add sp, sp, 0 instrutions. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/spill-sp-adjust.c: New test.
-
Jeff Law authored
So my tester started showing even more regressions on the sh3/sh4 runs recently (beyond the one recently reported in BZ triggered by some DCE related changes). Bisection kept showing inconsistent results. I was starting to think memory management error, but valgrind didn't flag anything. After a bit of head-banging I was able to track it down to predicate tests called from the SH specific combiner passes. And once I started getting inside the actual code for the predicate function it became pretty obvious. The predicate routines are supposed to return a bool, fine and they dutifully set the low bit in %eax properly. The *caller* was looking at the full register. Uh-oh. Naturally we became dependent on what happened to be in the upper 31 bits of a register. That's why the bug would come and go so willy-nilly. This was ultimately chased down to an incorrect prototype in sh_treg_combine.cc for predicate functions defined via define_predicate. Removing the bogus prototypes and instead including the generated tm-preds.h fixes this problem. I also checked the other ports for similar problems (specifically looking for a extern int.*_operand, then for each of the hits looking to see if the predicate was defined via define_predicate). No other ports had similar braindamage. This fixes the most recent regressions in my tester for sh3/sh3eb and I strongly suspect sh4. It does not fix 107704, but I think Richi and I both agree that's a visitation order issue and we were just getting lucky before. gcc/ * config/sh/sh_treg_combine.cc: Include tm-preds.h. (t_reg_operand): Remove bogus prototype. (negt_reg_operand): Likewise.
-
Jonathan Wakely authored
For powerpc64le we need to be able to format both of __ieee128 and __ibm128, so we need the std::to_chars overloads for both types to be visible at once. The __ieee128 overloads are always visible in C++23 mode, because they're used to implement the _Float128 overloads. The __ibm128 overloads are only visible when long double is __ibm128. libstdc++-v3/ChangeLog: PR libstdc++/107720 * include/std/format [_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT]: Declare overloads of std::to_chars for the alternative long double type.
-
GCC Administrator authored
-
- Nov 16, 2022
-
-
David Malcolm authored
gcc/testsuite/ChangeLog: * gcc.dg/analyzer/named-constants-via-command-line.c: New test. * gcc.dg/analyzer/named-constants-via-macros-3.c: New test. * gcc.dg/analyzer/named-constants-via-macros-4.c: New test. * gcc.dg/analyzer/named-constants-via-macros-empty.c: New test. * gcc.dg/analyzer/named-constants-via-macros-gc.c: New test. * gcc.dg/analyzer/named-constants-via-macros-traditional.c: New test. * gcc.dg/analyzer/named-constants-via-macros-undef.c: New test. Signed-off-by:
David Malcolm <dmalcolm@redhat.com>
-
David Malcolm authored
PR analyzer/107711 seems to be a bug in how named constants are looked up by the analyzer in the C frontend. To help debug this, this patch extends -fdump-analyzer and -fdump-analyzer-stderr so that they dump this part of the analyzer's startup. gcc/analyzer/ChangeLog: PR analyzer/107711 * analyzer-language.cc: Include "diagnostic.h". (maybe_stash_named_constant): Add logger param and use it to log the name being looked up, and the result. (stash_named_constants): New, splitting out from... (on_finish_translation_unit): ...this function. Call get_or_create_logfile and use the result to create a logger instance, passing it to stash_named_constants. * analyzer.h (get_or_create_any_logfile): New decl. * engine.cc (dump_fout, owns_dump_fout): New globals, split out from run_checkers. (get_or_create_any_logfile): New function, split out from... (run_checkers): ...here, so that the logfile can be opened by on_finish_translation_unit. Clear the globals when closing the dump file. gcc/testsuite/ChangeLog: PR analyzer/107711 * gcc.dg/analyzer/fdump-analyzer-1.c: New test. Signed-off-by:
David Malcolm <dmalcolm@redhat.com>
-
Steve Kargl authored
gcc/fortran/ChangeLog: PR fortran/107707 * interface.cc (gfc_compare_actual_formal): Check that we actually have integer values before asking gmp_* to use them. gcc/testsuite/ChangeLog: PR fortran/107707 * gfortran.dg/pr107707.f90: New test.
-
Marek Polacek authored
This patch implements C++23 P2448, which lifts more restrictions on the constexpr keyword. It's effectively going the way of being just a hint (hello, inline!). This gist is relatively simple: in C++23, a constexpr function's return type/parameter type doesn't have to be a literal type; and you can have a constexpr function for which no invocation satisfies the requirements of a core constant expression. For example, void f(int& i); // not constexpr constexpr void g(int& i) { f(i); // unconditionally calls a non-constexpr function } is now OK, even though there isn't an invocation of 'g' that would be a constant expression. Maybe 'f' will be made constexpr soon, or maybe this depends on the version of C++ used, and similar. The patch is unfortunately not that trivial. The important bit is to use the new require_potential_rvalue_constant_expression_fncheck in maybe_save_constexpr_fundef (and where appropriate). It has a new flag that says that we're checking the body of a constexpr function, and in that case it's OK to find constructs that aren't a constant expression. Since it's useful to be able to check for problematic constructs even in C++23, this patch implements a new warning, -Winvalid-constexpr, which is a pedwarn turned on by default in C++20 and earlier, and which can be turned on in C++23 as well, in which case it's an ordinary warning. This I implemented by using the new function constexpr_error, used in p_c_e_1 and friends. (In some cases I believe fundef_p will be always false (= hard error), but it made sense to me to be consistent and use constexpr_error throughout p_c_e_1.) While working on this I think I found a bug, see constexpr-nonlit15.C and <https://gcc.gnu.org/PR107598>. This patch doesn't address that. This patch includes changes to diagnose the problem if the user doesn't use -Winvalid-constexpr and calls a constexpr function that in fact isn't constexpr-ready yet: maybe_save_constexpr_fundef registers the function if warn_invalid_constexpr is 0 and explain_invalid_constexpr_fn then gives the diagnostic. PR c++/106649 gcc/c-family/ChangeLog: * c-cppbuiltin.cc (c_cpp_builtins): Update value of __cpp_constexpr for C++23. * c-opts.cc (c_common_post_options): Set warn_invalid_constexpr depending on cxx_dialect. * c.opt (Winvalid-constexpr): New option. gcc/cp/ChangeLog: * constexpr.cc (constexpr_error): New function. (is_valid_constexpr_fn): Use constexpr_error. (maybe_save_constexpr_fundef): Call require_potential_rvalue_constant_expression_fncheck rather than require_potential_rvalue_constant_expression. Register the function if -Wno-invalid-constexpr was specified. (explain_invalid_constexpr_fn): Don't return early if a function marked 'constexpr' that isn't actually a constant expression was called. (non_const_var_error): Add a bool parameter. Use constexpr_error. (inline_asm_in_constexpr_error): Likewise. (cxx_eval_constant_expression): Adjust calls to non_const_var_error and inline_asm_in_constexpr_error. (potential_constant_expression_1): Add a bool parameter. Use constexpr_error. (require_potential_rvalue_constant_expression_fncheck): New function. * cp-tree.h (require_potential_rvalue_constant_expression_fncheck): Declare. * method.cc (struct comp_info): Call require_potential_rvalue_constant_expression_fncheck rather than require_potential_rvalue_constant_expression. gcc/ChangeLog: * doc/invoke.texi: Document -Winvalid-constexpr. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-ctor2.C: Expect an error in c++20_down only. * g++.dg/cpp0x/constexpr-default-ctor.C: Likewise. * g++.dg/cpp0x/constexpr-diag3.C: Likewise. * g++.dg/cpp0x/constexpr-ex1.C: Likewise. * g++.dg/cpp0x/constexpr-friend.C: Likewise. * g++.dg/cpp0x/constexpr-generated1.C: Likewise. * g++.dg/cpp0x/constexpr-ice5.C: Likewise. * g++.dg/cpp0x/constexpr-ice6.C: Likewise. * g++.dg/cpp0x/constexpr-memfn1.C: Likewise. * g++.dg/cpp0x/constexpr-neg2.C: Likewise. * g++.dg/cpp0x/constexpr-non-const-arg.C: Likewise. * g++.dg/cpp0x/constexpr-reinterpret1.C: Likewise. * g++.dg/cpp0x/pr65327.C: Likewise. * g++.dg/cpp1y/constexpr-105050.C: Likewise. * g++.dg/cpp1y/constexpr-89285-2.C: Likewise. * g++.dg/cpp1y/constexpr-89285.C: Likewise. * g++.dg/cpp1y/constexpr-89785-2.C: Likewise. * g++.dg/cpp1y/constexpr-neg1.C: Likewise. * g++.dg/cpp1y/constexpr-nsdmi7b.C: Likewise. * g++.dg/cpp1y/constexpr-throw.C: Likewise. * g++.dg/cpp23/constexpr-nonlit3.C: Remove dg-error. * g++.dg/cpp23/constexpr-nonlit6.C: Call the test functions. * g++.dg/cpp23/feat-cxx2b.C: Adjust the expected value of __cpp_constexpr. * g++.dg/cpp2a/consteval3.C: Remove dg-error. * g++.dg/cpp2a/constexpr-new7.C: Expect an error in c++20_down only. * g++.dg/cpp2a/constexpr-try5.C: Remove dg-error. * g++.dg/cpp2a/spaceship-constexpr1.C: Expect an error in c++20_down only. * g++.dg/cpp2a/spaceship-eq3.C: Likewise. * g++.dg/diagnostic/constexpr1.C: Remove dg-error. * g++.dg/gomp/pr79664.C: Use -Winvalid-constexpr -pedantic-errors. * g++.dg/ubsan/vptr-4.C: Likewise. * g++.dg/cpp23/constexpr-nonlit10.C: New test. * g++.dg/cpp23/constexpr-nonlit11.C: New test. * g++.dg/cpp23/constexpr-nonlit12.C: New test. * g++.dg/cpp23/constexpr-nonlit13.C: New test. * g++.dg/cpp23/constexpr-nonlit14.C: New test. * g++.dg/cpp23/constexpr-nonlit15.C: New test. * g++.dg/cpp23/constexpr-nonlit16.C: New test. * g++.dg/cpp23/constexpr-nonlit8.C: New test. * g++.dg/cpp23/constexpr-nonlit9.C: New test.
-
Jonathan Wakely authored
This is only a partial fix for the PR. libstdc++-v3/ChangeLog: PR libstdc++/107720 * include/std/format (__format::_Arg_t): Fix typo in enumerator name. (_Arg_value::_S_get): Fix missing semi-colons.
-
Jonathan Wakely authored
We can use an array instead of a std::vector, and we can avoid the binary search for the common case of a time point after the most recent leap second. On one system where I tested this, utc_clock::now() now takes about 16ns instead of 31ns. libstdc++-v3/ChangeLog: * include/std/chrono (get_leap_second_info): Optimize.
-