summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Daily bump.HEADtrunkmasterGCC Administrator2023-05-1810-1/+400
|
* c: Handle printf %B like %b for C2xJoseph Myers2023-05-183-17/+15
| | | | | | | | | | | | | | | | | | WG14 decided to change the printf %B format from a recommended extension to an optional feature defined in normative text. Thus, change the format checking to handle %B like %b, so not diagnosing it with -Wformat -std=c2x -pedantic, just as with other optional normatively defined features (such as decimal floating point and its associated formats, for example). Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c-family/ * c-format.cc (print_char_table): Handle %B like %b. gcc/testsuite/ * gcc.dg/format/c2x-printf-1.c: Test %B here. * gcc.dg/format/ext-9.c: Do not test %B here.
* Fix type error of 'switch (SUBREG_BYTE (op)).'Jin Ma2023-05-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | For example: (define_insn "mov_lowpart_sidi2" [(set (match_operand:SI 0 "register_operand" "=r") (subreg:SI (match_operand:DI 1 "register_operand" " r") 0))] "TARGET_64BIT" "mov\t%0,%1") (define_insn "mov_highpart_sidi2" [(set (match_operand:SI 0 "register_operand" "=r") (subreg:SI (match_operand:DI 1 "register_operand" " r") 1))] "TARGET_64BIT" "movh\t%0,%1") When defining the above patterns, the generated file insn-recog.cc will appear 'switch (SUBREG_BYTE (op))', but since the return value of SUBREG_BYTE is poly_uint16_pod, the following error will occur: "error: switch quantity not an integer". gcc/ChangeLog: * genrecog.cc (print_nonbool_test): Fix type error of switch (SUBREG_BYTE (op))'.
* RISC-V: Remove trailing spaces on lines.Jin Ma2023-05-174-7/+7
| | | | | | | | | | gcc/ChangeLog: * common/config/riscv/riscv-common.cc: Remove trailing spaces on lines. * config/riscv/riscv.cc (riscv_legitimize_move): Likewise. * config/riscv/riscv.h (enum reg_class): Likewise. * config/riscv/riscv.md: Likewise.
* Add clear_cache expander.John David Anglin2023-05-171-0/+17
| | | | | | | | 2023-05-17 John David Anglin <danglin@gcc.gnu.org> gcc/ChangeLog: * config/pa/pa.md (clear_cache): New.
* doc: Fix a pinch of typos in extend.texiArsen Arsenović2023-05-171-3/+3
| | | | | | | | gcc/ChangeLog: * doc/extend.texi (C++ Concepts) <forall>: Remove extraneous parenthesis. Fix misnamed index entry. <concept>: Fix misnamed index entry.
* Fortran: set shape of initializers of zero-sized arrays [PR95374,PR104352]Harald Anlauf2023-05-172-2/+29
| | | | | | | | | | | | | | | gcc/fortran/ChangeLog: PR fortran/95374 PR fortran/104352 * decl.cc (add_init_expr_to_sym): Set shape of initializer also for zero-sized arrays, so that bounds violations can be detected later. gcc/testsuite/ChangeLog: PR fortran/95374 PR fortran/104352 * gfortran.dg/zero_sized_13.f90: New test.
* libstdc++: Fix up some <cmath> templates [PR109883]Jakub Jelinek2023-05-172-117/+229
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As can be seen on the following testcase, for std::{atan2,fmod,pow,copysign,fdim,fmax,fmin,hypot,nextafter,remainder,remquo,fma} if one operand type is std::float{16,32,64,128}_t or std::bfloat16_t and another one some integral type or some other floating point type which promotes to the other operand's type, we can end up with endless recursion. This is because of a declaration ordering problem in <cmath>, where the float, double and long double overloads of those functions come before the templates which use __gnu_cxx::__promote_{2,3}, but the std::float{16,32,64,128}_t and std::bfloat16_t overloads come later in the file. If the result of those promotions is _Float{16,32,64,128} or __gnu_cxx::__bfloat16_t, say std::pow(_Float64, int) calls std::pow(_Float64, _Float64) and the latter calls itself. The following patch fixes that by moving those templates later in the file, so that the calls from those templates see also the other overloads. I think other templates in the file like e.g. isgreater etc. shouldn't be a problem, because those just use __builtin_isgreater etc. in their bodies. 2023-05-17 Jakub Jelinek <jakub@redhat.com> PR libstdc++/109883 * include/c_global/cmath (atan2, fmod, pow): Move __gnu_cxx::__promote_2 using templates after _Float{16,32,64,128} and __gnu_cxx::__bfloat16_t overloads. (copysign, fdim, fmax, fmin, hypot, nextafter, remainder, remquo): Likewise. (fma): Move __gnu_cxx::__promote_3 using template after _Float{16,32,64,128} and __gnu_cxx::__bfloat16_t overloads. * testsuite/26_numerics/headers/cmath/constexpr_std_c++23.cc: New test.
* libstdc++: Uncomment checks for <limits> enumeration typesJonathan Wakely2023-05-171-2/+0
| | | | | | | | | I don't know why these checks are disabled. libstdc++-v3/ChangeLog: * testsuite/18_support/headers/limits/synopsis.cc: Uncomment checks for float_round_style and float_denorm_style.
* RISC-V: Remove masking third operand of rotate instructionsJivan Hakobyan2023-05-1712-111/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rotate instructions do not need to mask the third operand. For example, RV64 the following code: unsigned long foo1(unsigned long rs1, unsigned long rs2) { long shamt = rs2 & (64 - 1); return (rs1 << shamt) | (rs1 >> ((64 - shamt) & (64 - 1))); } Compiles to: foo1: andi a1,a1,63 rol a0,a0,a1 ret This patch removes unnecessary masking. Besides, I have merged masking insns for shifts that were written before. gcc/ChangeLog: * config/riscv/riscv.md (*<optab><GPR:mode>3_mask): New pattern, combined from ... (*<optab>si3_mask, *<optab>di3_mask): Here. (*<optab>si3_mask_1, *<optab>di3_mask_1): And here. * config/riscv/bitmanip.md (*<bitmanip_optab><GPR:mode>3_mask): New pattern. (*<bitmanip_optab>si3_sext_mask): Likewise. * config/riscv/iterators.md (shiftm1): Use const_si_mask_operand and const_di_mask_operand. (bitmanip_rotate): New iterator. (bitmanip_optab): Add rotates. * config/riscv/predicates.md (const_si_mask_operand): Renamed from const31_operand. Generalize to handle more mask constants. (const_di_mask_operand): Similarly. gcc/testsuite/ChangeLog: * gcc.target/riscv/shift-and-2.c: Fixed test * gcc.target/riscv/zbb-rol-ror-01.c: New test * gcc.target/riscv/zbb-rol-ror-02.c: New test * gcc.target/riscv/zbb-rol-ror-03.c: New test * gcc.target/riscv/zbb-rol-ror-04.c: New test * gcc.target/riscv/zbb-rol-ror-05.c: New test * gcc.target/riscv/zbb-rol-ror-06.c: New test * gcc.target/riscv/zbb-rol-ror-07.c: New test
* libstdc++: Add system_header pragma to <bits/c++config.h>Jonathan Wakely2023-05-171-0/+2
| | | | | | | | | | | | | | | | | | | | | | Without this change many tests that depend on an effective-target will fail when compiled with -pedantic -std=c++98. This happens because the preprocessor check done by v3_check_preprocessor_condition uses -Werror and includes <bits/c++config.h> directly (rather than via another header like <string>). If <bits/c++config.h> is not a system header then this pedwarn is not suppressed, and the effective-target check fails: bits/c++config.h:220: error: anonymous variadic macros were introduced in C++11 [-Werror=variadic-macros] cc1plus: all warnings being treated as errors compiler exited with status 1 UNSUPPORTED: 18_support/headers/limits/synopsis.cc We could consider also changing proc v3_check_preprocessor_condition so that it includes a real header, rather than just <bits/c++config.h>, but that's not necessary for now. libstdc++-v3/ChangeLog: * include/bits/c++config: Add system_header pragma.
* libstdc++: Implement LWG 3877 for std::expected monadic opsJonathan Wakely2023-05-172-24/+88
| | | | | | | | | | | | | | | This was approved in Issaquah 2023. As well as fixing the value categories, this fixes the fact that we were incorrectly testing E instead of T in the or_else constraints. libstdc++-v3/ChangeLog: * include/std/expected (expected::and_then, expected::or_else) (expected::transform, expected::transform_error): Fix exception specifications as per LWG 3877. (expected<void, E>::and_then, expected<void, E>::transform): Likewise. * testsuite/20_util/expected/lwg3877.cc: New test.
* i386: Fix up types in __builtin_{inf,huge_val,nan{,s},fabs,copysign}q ↵Jakub Jelinek2023-05-172-1/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | builtins [PR109884] When _Float128 support has been added to C++ for 13.1, float128t_type_node tree has been added - in C float128_type_node and float128t_type_node is the same and represents both _Float128 and __float128, but in C++ they are distinct types which have different handling in the FEs. When doing that change, I mistakenly forgot to change FLOAT128 primitive type, which is used for the __builtin_{inf,huge_val,nan{,s},fabs,copysign}q builtins results and some of their arguments (and nothing else). The following patch fixes that. On ia64 we already use float128t_type_node for those builtins, pa while it has __float128 that type is the same as long double and so those builtins have long double types and on powerpc seems we don't have these builtins but instead define macros which map them to __builtin_*f128. That will not work properly in C++, perhaps we should change those macros to be function-like and cast to __float128. 2023-05-17 Jakub Jelinek <jakub@redhat.com> PR c++/109884 * config/i386/i386-builtin-types.def (FLOAT128): Use float128t_type_node rather than float128_type_node. * c-c++-common/pr109884.c: New test.
* tree-ssa-math-opts: correct -ffp-contract= checkAlexander Monakov2023-05-171-1/+1
| | | | | | | | | | | | | Since tree-ssa-math-opts may freely contract across statement boundaries we should enable it only for -ffp-contract=fast instead of disabling it for -ffp-contract=off. No functional change, since -ffp-contract=on is not exposed yet. gcc/ChangeLog: * tree-ssa-math-opts.cc (convert_mult_to_fma): Enable only for FP_CONTRACT_FAST (no functional change).
* i386: Adjust emulated integer vector mode multiplication costsUros Bizjak2023-05-171-28/+44
| | | | | | | | | | | | | | | Returned integer vector mode costs of emulated modes in ix86_multiplication_cost are wrong and do not reflect generated instruction sequences. Rewrite handling of different integer vector modes and different target ABIs to return real instruction counts in order to calcuate better costs of various emulated modes. gcc/ChangeLog: * config/i386/i386.cc (ix86_multiplication_cost): Correct calcuation of integer vector mode costs to reflect generated instruction sequences of different integer vector modes and different target ABIs.
* WriteInt in the ISO libraries should not emit '+' for positive valuesGaius Mulley2023-05-174-12/+12
| | | | | | | | | | | | | | | | | | This trivial patch changes the default behaviour for WriteInt so that '+' is not emitted when writing positive values. gcc/m2/ChangeLog: * gm2-libs-iso/LongWholeIO.mod (WriteInt): Only request a sign if the value is < 0. * gm2-libs-iso/ShortWholeIO.mod (WriteInt): Only request a sign if the value is < 0. * gm2-libs-iso/WholeIO.mod (WriteInt): Only request a sign if the value is < 0. * gm2-libs-iso/WholeStr.mod (WriteInt): Only request a sign if the value is < 0. Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
* libstdc++: use __bool_constant instead of integral_constantKen Matsui2023-05-171-16/+16
| | | | | | | | | | | | | | In the type_traits header, both integral_constant<bool> and __bool_constant are used. This patch unifies those usages into __bool_constant. libstdc++-v3/ChangeLog: * include/std/type_traits: Use __bool_constant instead of integral_constant. Signed-off-by: Ken Matsui <kmatsui@cs.washington.edu> Reviewed-by: Jonathan Wakely <jwakely@redhat.com> Reviewed-by: Patrick Palka <ppalka@redhat.com>
* RISC-V: Add mode switching target hook to insert rounding mode config for ↵Juzhe-Zhong2023-05-1710-2/+249
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fixed-point instructions Hi, this patch support the new coming fixed-point intrinsics: https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/222 Insert fixed-point rounding mode configuration by mode switching target hook. Mode switching target hook is implemented applying LCM (Lazy code Motion). So the performance && correctness can be well trusted. Here is the example: void f (void * in, void *out, int32_t x, int n, int m) { for (int i = 0; i < n; i++) { vint32m1_t v = __riscv_vle32_v_i32m1 (in + i, 4); vint32m1_t v2 = __riscv_vle32_v_i32m1_tu (v, in + 100 + i, 4); vint32m1_t v3 = __riscv_vaadd_vx_i32m1 (v2, 0, VXRM_RDN, 4); v3 = __riscv_vaadd_vx_i32m1 (v3, 3, VXRM_RDN, 4); __riscv_vse32_v_i32m1 (out + 100 + i, v3, 4); } for (int i = 0; i < n; i++) { vint32m1_t v = __riscv_vle32_v_i32m1 (in + i + 1000, 4); vint32m1_t v2 = __riscv_vle32_v_i32m1_tu (v, in + 100 + i + 1000, 4); vint32m1_t v3 = __riscv_vaadd_vx_i32m1 (v2, 0, VXRM_RDN, 4); v3 = __riscv_vaadd_vx_i32m1 (v3, 3, VXRM_RDN, 4); __riscv_vse32_v_i32m1 (out + 100 + i + 1000, v3, 4); } } ASM: ... csrwi vxrm,2 vsetivli zero,4,e32,m1,tu,ma ... Loop 1 ... Loop 2 mode switching can global recognize both Loop 1 and Loop 2 are using RDN rounding mode and hoist such single "csrwi vxrm,2" to dominate both Loop 1 and Loop 2. Besides, I have add correctness check sanity tests in this patch too. Ok for trunk ? gcc/ChangeLog: * config/riscv/riscv-opts.h (enum riscv_entity): New enum. * config/riscv/riscv.cc (riscv_emit_mode_set): New function. (riscv_mode_needed): Ditto. (riscv_mode_after): Ditto. (riscv_mode_entry): Ditto. (riscv_mode_exit): Ditto. (riscv_mode_priority): Ditto. (TARGET_MODE_EMIT): New target hook. (TARGET_MODE_NEEDED): Ditto. (TARGET_MODE_AFTER): Ditto. (TARGET_MODE_ENTRY): Ditto. (TARGET_MODE_EXIT): Ditto. (TARGET_MODE_PRIORITY): Ditto. * config/riscv/riscv.h (OPTIMIZE_MODE_SWITCHING): Ditto. (NUM_MODES_FOR_MODE_SWITCHING): Ditto. * config/riscv/riscv.md: Add csrwvxrm. * config/riscv/vector.md (rnu,rne,rdn,rod,none): New attribute. (vxrmsi): New pattern. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/vxrm-10.c: New test. * gcc.target/riscv/rvv/base/vxrm-6.c: New test. * gcc.target/riscv/rvv/base/vxrm-7.c: New test. * gcc.target/riscv/rvv/base/vxrm-8.c: New test. * gcc.target/riscv/rvv/base/vxrm-9.c: New test.
* RISC-V: Introduce rounding mode operand into fixed-point intrinsicsJuzhe-Zhong2023-05-1752-426/+543
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | According to new comming fixed-point API: https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/222 Introduce vxrm argument: - vint32m1_t __riscv_vsadd_vv_i32m1 (vint32m1_t op1, vint32m1_t op2, size_t vl); + vint32m1_t __riscv_vsadd_vv_i32m1 (vint32m1_t op1, vint32m1_t op2, size_t vxrm, size_t vl); This patch doesn't insert vxrm csrw configuration instruction yet. Will support automatically insert csrw vxrm instruction in the next patch. This patch does this following: 1. Only extend the vxrm argument. 2. Check vxrm argument is invalid immediate and report error message if it is invalid. gcc/ChangeLog: * config/riscv/riscv-vector-builtins-bases.cc: Introduce rounding mode. * config/riscv/riscv-vector-builtins-shapes.cc (struct alu_def): Ditto. (struct narrow_alu_def): Ditto. * config/riscv/riscv-vector-builtins.cc (function_builder::apply_predication): Ditto. (function_expander::use_exact_insn): Ditto. * config/riscv/riscv-vector-builtins.h (function_checker::arg_num): New function. (function_base::has_rounding_mode_operand_p): New function. gcc/testsuite/ChangeLog: * g++.target/riscv/rvv/base/bug-11.C: Adapt testcase. * g++.target/riscv/rvv/base/bug-12.C: Ditto. * g++.target/riscv/rvv/base/bug-14.C: Ditto. * g++.target/riscv/rvv/base/bug-15.C: Ditto. * g++.target/riscv/rvv/base/bug-16.C: Ditto. * g++.target/riscv/rvv/base/bug-17.C: Ditto. * g++.target/riscv/rvv/base/bug-18.C: Ditto. * g++.target/riscv/rvv/base/bug-19.C: Ditto. * g++.target/riscv/rvv/base/bug-20.C: Ditto. * g++.target/riscv/rvv/base/bug-21.C: Ditto. * g++.target/riscv/rvv/base/bug-22.C: Ditto. * g++.target/riscv/rvv/base/bug-23.C: Ditto. * g++.target/riscv/rvv/base/bug-3.C: Ditto. * g++.target/riscv/rvv/base/bug-5.C: Ditto. * g++.target/riscv/rvv/base/bug-6.C: Ditto. * g++.target/riscv/rvv/base/bug-8.C: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-100.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-101.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-102.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-103.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-104.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-105.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-106.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-107.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-108.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-109.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-110.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-111.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-112.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-113.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-114.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-115.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-116.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-117.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-118.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-119.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-122.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-97.c: Ditto. * gcc.target/riscv/rvv/base/binop_vx_constraint-98.c: Ditto. * gcc.target/riscv/rvv/base/merge_constraint-1.c: Ditto. * gcc.target/riscv/rvv/base/narrow_constraint-6.c: Ditto. * gcc.target/riscv/rvv/base/narrow_constraint-7.c: Ditto. * gcc.target/riscv/rvv/base/narrow_constraint-8.c: Ditto. * gcc.target/riscv/rvv/base/narrow_constraint-9.c: Ditto. * gcc.target/riscv/rvv/base/vxrm-2.c: New test. * gcc.target/riscv/rvv/base/vxrm-3.c: New test. * gcc.target/riscv/rvv/base/vxrm-4.c: New test. * gcc.target/riscv/rvv/base/vxrm-5.c: New test.
* Fix PR 106900: array-bounds warning inside simplify_builtin_callAndrew Pinski2023-05-171-2/+2
| | | | | | | | | | | | | | | | | | The problem here is that VRP cannot figure out isize could not be 0 due to using integer_zerop. This patch removes the use of integer_zerop and instead checks for 0 directly after converting the tree to an unsigned HOST_WIDE_INT. This allows VRP to figure out isize is not 0 and `isize - 1` will always be >= 0. This patch is just to avoid the warning that GCC could produce sometimes and does not change any code generation or even VRP. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. gcc/ChangeLog: * tree-ssa-forwprop.cc (simplify_builtin_call): Check against 0 instead of calling integer_zerop.
* RISC-V: Add rounding mode enum for fixed-point intrinsicsJuzhe-Zhong2023-05-173-0/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | Hi, since fixed-point with modeling rounding mode intrinsics are coming: https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/222 I am adding vxrm rounding mode enum to user first before the API intrinsic. This patch is simple && obvious. Ok for trunk ? gcc/ChangeLog: * config/riscv/riscv-vector-builtins.cc (register_vxrm): New function. (DEF_RVV_VXRM_ENUM): New macro. (handle_pragma_vector): Add vxrm enum register. * config/riscv/riscv-vector-builtins.def (DEF_RVV_VXRM_ENUM): New macro. (RNU): Ditto. (RNE): Ditto. (RDN): Ditto. (ROD): Ditto. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/vxrm-1.c: New test.
* Add Value_Range::operator=.Aldy Hernandez2023-05-171-0/+25
| | | | | | gcc/ChangeLog: * value-range.h (Value_Range::operator=): New.
* Provide support for copying unsupported ranges.Aldy Hernandez2023-05-172-1/+16
| | | | | | | | | | | | | | | | | | The unsupported_range class is provided for completness sake. It is a way to set VARYING/UNDEFINED ranges for unsupported ranges (currently anything not float, integer, or pointer). You can't do anything with them, except set_varying, and set_undefined. We will trap on any other operation. This patch provides a way to copy them, just in case they creep in. This could happen in IPA under certain circumstances. gcc/ChangeLog: * value-range.cc (vrange::operator=): Add a stub to copy unsupported ranges. * value-range.h (is_a <unsupported_range>): New. (Value_Range::operator=): Support copying unsupported ranges.
* Add support for vrange streaming.Aldy Hernandez2023-05-173-0/+109
| | | | | | | | | | | | | | | | | | I think it's time for the ranger folk to start owning range streaming instead of passes (IPA, etc) doing their own thing. I have plans for overhauling the IPA code later this cycle to support generic ranges, and I'd like to start cleaning up the streaming and hashing interface. This patch adds generic streaming support for vrange. gcc/ChangeLog: * data-streamer-in.cc (streamer_read_real_value): New. (streamer_read_value_range): New. * data-streamer-out.cc (streamer_write_real_value): New. (streamer_write_vrange): New. * data-streamer.h (streamer_write_vrange): New. (streamer_read_value_range): New.
* doc: Describe behaviour of enums with fixed underlying type [PR109532]Jonathan Wakely2023-05-171-0/+4
| | | | | | | | | | | gcc/ChangeLog: PR c++/109532 * doc/invoke.texi (Code Gen Options): Note that -fshort-enums is ignored for a fixed underlying type. (C++ Dialect Options): Likewise for -fstrict-enums. Reviewed-by: Marek Polacek <polacek@redhat.com>
* Fortran/OpenMP: Fix mapping of array descriptors and deferred-length stringsTobias Burnus2023-05-1713-140/+1877
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, array descriptors might have been mapped as 'alloc' instead of 'to' for 'alloc', not updating the array bounds. The 'alloc' could also appear for 'data exit', failing with a libgomp assert. In some cases, either array descriptors or deferred-length string's length variable was not mapped. And, finally, some offset calculations with array-sections mappings went wrong. Additionally, the patch now unmaps for scalar allocatables/pointers the GOMP_MAP_POINTER, avoiding stale mappings. The testcases contain some comment-out tests which require follow-up work and for which PR exist. Those mostly relate to deferred-length strings which have several issues beyong OpenMP support. gcc/fortran/ChangeLog: * trans-decl.cc (gfc_get_symbol_decl): Add attributes such as 'declare target' also to hidden artificial variable for deferred-length character variables. * trans-openmp.cc (gfc_trans_omp_array_section, gfc_trans_omp_clauses, gfc_trans_omp_target_exit_data): Improve mapping of array descriptors and deferred-length string variables. gcc/ChangeLog: * gimplify.cc (gimplify_scan_omp_clauses): Remove Fortran special case. libgomp/ChangeLog: * testsuite/libgomp.fortran/target-enter-data-3.f90: Uncomment 'target exit data'. * testsuite/libgomp.fortran/target-enter-data-4.f90: New test. * testsuite/libgomp.fortran/target-enter-data-5.f90: New test. * testsuite/libgomp.fortran/target-enter-data-6.f90: New test. * testsuite/libgomp.fortran/target-enter-data-7.f90: New test. gcc/testsuite/ * gfortran.dg/goacc/finalize-1.f: Update dg-tree; shows a fix for 'finalize' as a ptr is now 'delete' instead of 'release'. * gfortran.dg/gomp/pr78260-2.f90: Likewise as elem-size calc moved to if (allocated) block * gfortran.dg/gomp/target-exit-data.f90: Likewise as a var is now a replaced by a MEM< _25 > expression. * gfortran.dg/gomp/map-9.f90: Update dg-scan-tree-dump. * gfortran.dg/gomp/map-10.f90: New test.
* libstdc++: Regenerate configureJonathan Wakely2023-05-171-0/+1
| | | | | | | | I added a comment to configure.ac and forgot to regenerate configure. libstdc++-v3/ChangeLog: * configure: Regenerate.
* s390: Implement TARGET_ATOMIC_ALIGN_FOR_MODEStefan Schulze Frielinghaus2023-05-174-0/+74
| | | | | | | | | | | | | | | | | | | | | | So far atomic objects are aligned according to their default alignment. For 128 bit scalar types like int128 or long double this results in an 8 byte alignment which is wrong and must be 16 byte. libstdc++ already computes a correct alignment, though, still adding a test case in order to make sure that both implementations are compatible. gcc/ChangeLog: * config/s390/s390.cc (TARGET_ATOMIC_ALIGN_FOR_MODE): New. (s390_atomic_align_for_mode): New. gcc/testsuite/ChangeLog: * g++.target/s390/atomic-align-1.C: New test. * gcc.target/s390/atomic-align-1.c: New test. * gcc.target/s390/atomic-align-2.c: New test.
* wide-int: Fix up function commentJakub Jelinek2023-05-171-1/+1
| | | | | | | | | | | When looking into _BitInt support, I've noticed unterminated parens in a function comment. Fixing thusly. 2023-05-17 Jakub Jelinek <jakub@redhat.com> * wide-int.cc (wi::from_array): Add missing closing paren in function comment.
* c++: Don't try to initialize zero width bitfields in zero initialization ↵Jakub Jelinek2023-05-172-6/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | [PR109868] My GCC 12 change to avoid removing zero-sized bitfields as they are important for ABI and are needed for layout compatibility traits apparently causes zero sized bitfields to be initialized in the IL, which at least in 13+ results in ICEs in the ranger which is upset about zero precision types. I think we could even avoid initializing other unnamed bitfields, but unfortunately !CONSTRUCTOR_NO_CLEARING doesn't mean in the middle-end clearing of padding bits and until we have some new flag that represents the request to clear padding bits, I think it is better to keep zeroing non-zero sized unnamed bitfields. In addition to skipping those fields, I have changed the logic how UNION_TYPEs are handled, the current code was a little bit weird in that e.g. if first non-static data member had error_mark_node type, we'd happily zero initialize the second non-static data member, etc. 2023-05-17 Jakub Jelinek <jakub@redhat.com> PR c++/109868 * init.cc (build_zero_init_1): Don't initialize zero-width bitfields. For unions only initialize the first FIELD_DECL. * g++.dg/init/pr109868.C: New test.
* vect: Don't retry if the previous analysis failsKewen Lin2023-05-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | When working on a cost tweaking patch, I found that a newly added test case has different dumpings with stage-1 and bootstrapped gcc. By looking into it, the apparent reason is vect_analyze_loop_2 doesn't get slp_done_for_suggested_uf set expectedly, the following retrying will use the garbage slp_done_for_suggested_uf instead. In fact, the setting of slp_done_for_suggested_uf only happens when the previous analysis succeeds, for the mentioned test case, its previous analysis does fail, it's unexpected to use the value of slp_done_for_suggested_uf any more. In function vect_analyze_loop_1, we only return success when res is true, which is the result of 1st analysis. It means we never try to vectorize with unroll_vinfo if the previous analysis fails. So this patch shouldn't break anything, and just stop some useless analysis early. gcc/ChangeLog: * tree-vect-loop.cc (vect_analyze_loop_1): Don't retry analysis with suggested unroll factor once the previous analysis fails.
* RISC-V: Support RVV VREINTERPRET from v{u}int*_t to vbool1_tPan Li2023-05-177-0/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch support the RVV VREINTERPRET from the int to the vbool1_t. Aka: vbool1_t __riscv_vreinterpret_xx_xx(v{u}int[8|16|32|64]_t); These APIs help the users to convert vector LMUL=1 integer to vbool1_t. According to the RVV intrinsic SPEC as below, the reinterpret intrinsics only change the types of the underlying contents. https://github.com/riscv-non-isa/rvv-intrinsic-doc/blob/master/rvv-intrinsic-rfc.md#reinterpret-vbool-o-vintm1 For example, given below code. vbool1_t test_vreinterpret_v_i8m1_b1(vint8m1_t src) { return __riscv_vreinterpret_v_i8m1_b1(src); } It will generate the assembly code similar as below: vsetvli a5,zero,e8,m8,ta,ma vlm.v v1,0(a1) vsm.v v1,0(a0) ret The rest intrinsic bool size APIs will be prepared in other PATCH. Signed-off-by: Pan Li <pan2.li@intel.com> gcc/ChangeLog: * config/riscv/genrvv-type-indexer.cc (BOOL_SIZE_LIST): New macro. (main): Add bool1 to the type indexer. * config/riscv/riscv-vector-builtins-functions.def (vreinterpret): Register vbool1 interpret function. * config/riscv/riscv-vector-builtins-types.def (DEF_RVV_BOOL1_INTERPRET_OPS): New macro. (vint8m1_t): Add the type to bool1_interpret_ops. (vint16m1_t): Ditto. (vint32m1_t): Ditto. (vint64m1_t): Ditto. (vuint8m1_t): Ditto. (vuint16m1_t): Ditto. (vuint32m1_t): Ditto. (vuint64m1_t): Ditto. * config/riscv/riscv-vector-builtins.cc (DEF_RVV_BOOL1_INTERPRET_OPS): New macro. (required_extensions_p): Add bool1 interpret case. * config/riscv/riscv-vector-builtins.def (bool1_interpret): Add bool1 interpret to base type. * config/riscv/vector.md (@vreinterpret<mode>): Add new expand with VB dest for vreinterpret. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/misc_vreinterpret_vbool_vint.c: New test.
* Disable warnings as errors for STAGEautofeedback.Eugene Rozenfeld2023-05-161-2/+3
| | | | | | | | | | | | | | Compilation during STAGEautofeedback produces additional warnings since inlining decisions with -fauto-profile are different from other builds. This patches disables warnings as errors for STAGEautofeedback. Tested on x86_64-pc-linux-gnu. ChangeLog: * Makefile.in: Disable warnings as errors for STAGEautofeedback
* rs6000: use lis;xoris to build constantJiufu Guo2023-05-172-1/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | For constant C: If '(c & 0xFFFFFFFF0000FFFFULL) == 0xFFFFFFFF00000000' or say: 32(1) || 1(0) || 15(x) || 16(0), we could use "lis; xoris" to build. Here N(M) means N continuous bit M, x for M means it is ok for either 1 or 0; '||' means concatenation. This patch update rs6000_emit_set_long_const to support those constants. Compare with previous version: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608292.html This patch updates test function names only. Bootstrap and regtest pass on ppc64{,le}. PR target/106708 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Support building constants through "lis; xoris". gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr106708.c: Add test function.
* Daily bump.GCC Administrator2023-05-1710-1/+558
|
* c: Remove restrictions on declarations in 'for' loops for C2XJoseph Myers2023-05-1613-30/+142
| | | | | | | | | | | | | | | | | | | | | | | | | | C2X removes a restriction that the only declarations in the declaration part of a 'for' loop are declarations of objects with storage class auto or register. Implement this change, making the diagnostics into pedwarn_c11 calls instead of errors (as usual for features added in a new standard version that were invalid code in a previous version), so now pedwarn-if-pedantic for older standards and diagnosed also with -Wc11-c2x-compat. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c/ * c-decl.cc (check_for_loop_decls): Use pedwarn_c11 for diagnostics. gcc/testsuite/ * gcc.dg/c11-fordecl-1.c, gcc.dg/c11-fordecl-2.c, gcc.dg/c11-fordecl-3.c, gcc.dg/c11-fordecl-4.c, gcc.dg/c2x-fordecl-1.c, gcc.dg/c2x-fordecl-2.c, gcc.dg/c2x-fordecl-3.c, gcc.dg/c2x-fordecl-4.c: New tests. * gcc.dg/c99-fordecl-2.c: Test diagnostic for typedef declaration in for loop here. * gcc.dg/pr67784-2.c, gcc.dg/pr68320.c, objc.dg/foreach-7.m: Do not expect errors for typedef declaration in for loop.
* PR modula2/109879 WholeIO.ReadCard and ReadInt should consume leading spaceGaius Mulley2023-05-1717-75/+243
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Read{TYPE} procedures in LongIO, LongWholeIO, RealIO, ShortWholeIO and WholeIO all require skip space functionality. A new module TextUtil is supplied with this functionality and the previous modules have been changed to call SkipSpaces. gcc/m2/ChangeLog: PR modula2/109879 * gm2-libs-iso/LongIO.mod (ReadReal): Call SkipSpaces. * gm2-libs-iso/LongWholeIO.mod (ReadInt): Call SkipSpaces. (ReadCard): Call SkipSpaces. * gm2-libs-iso/RealIO.mod (ReadReal): Call SkipSpaces. * gm2-libs-iso/ShortWholeIO.mod: (ReadInt): Call SkipSpaces. (ReadCard): Call SkipSpaces. * gm2-libs-iso/TextIO.mod: Import SkipSpaces. * gm2-libs-iso/WholeIO.mod (ReadInt): Call SkipSpaces. (ReadCard): Call SkipSpaces. * gm2-libs-iso/TextUtil.def: New file. * gm2-libs-iso/TextUtil.mod: New file. libgm2/ChangeLog: PR modula2/109879 * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * libm2cor/Makefile.in: Regenerate. * libm2iso/Makefile.am (M2DEFS): Add TextUtil.def. (M2MODS): Add TextUtil.mod. * libm2iso/Makefile.in: Regenerate. * libm2log/Makefile.in: Regenerate. * libm2min/Makefile.in: Regenerate. * libm2pim/Makefile.in: Regenerate. gcc/testsuite/ChangeLog: PR modula2/109879 * gm2/isolib/run/pass/testreadint.mod: New test. Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
* c++: -Wdangling-reference not suppressed in template [PR109774]Marek Polacek2023-05-162-3/+26
| | | | | | | | | | | | | | | | | In check_return_expr, we suppress the -Wdangling-reference warning when we're sure it would be a false positive. It wasn't working in a template, though, because the suppress_warning call was never reached. PR c++/109774 gcc/cp/ChangeLog: * typeck.cc (check_return_expr): In a template, return only after suppressing -Wdangling-reference. gcc/testsuite/ChangeLog: * g++.dg/warn/Wdangling-reference13.C: New test.
* libstdc++: Disable cacheline alignment for DJGPP [PR109741]Jonathan Wakely2023-05-165-2/+86
| | | | | | | | | | | | | | | | | | | | | | DJGPP (and maybe other targets) uses MAX_OFILE_ALIGNMENT=16 which means that globals (and static objects) can't have alignment greater than 16. This causes an error for the locks defined in src/c++11/shared_ptr.cc because we try to align them to the cacheline size, to avoid false sharing. Add a configure check for the increased alignment, and live with false sharing where we can't increase the alignment. libstdc++-v3/ChangeLog: PR libstdc++/109741 * acinclude.m4 (GLIBCXX_CHECK_ALIGNAS_CACHELINE): Define. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Use GLIBCXX_CHECK_ALIGNAS_CACHELINE. * src/c++11/shared_ptr.cc (__gnu_internal::get_mutex): Do not align lock table if not supported. use __GCC_DESTRUCTIVE_SIZE instead of hardcoded 64.
* c++: desig init in presence of list ctor [PR109871]Patrick Palka2023-05-162-8/+24
| | | | | | | | | | | | | | | | | | | | | add_list_candidates has logic to reject designated initialization of a non-aggregate type, but this is inadvertently being suppressed if the type has a list constructor due to the order of case analysis, which in the below testcase leads to us incorrectly treating the initializer list as if it's non-designated. This patch fixes this by making us check for invalid designated initialization sooner. PR c++/109871 gcc/cp/ChangeLog: * call.cc (add_list_candidates): Check for invalid designated initialization sooner and even for types that have a list constructor. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/desig27.C: New test.
* rs6000: Enable REE pass by default“Ajit Kumar Agarwal”2023-05-162-2/+4
| | | | | | | | | | | | | Add ree pass as a default pass for rs6000 target for O2 and above. 2023-05-16 Ajit Kumar Agarwal <aagarwa1@linux.ibm.com> gcc/ChangeLog: * common/config/rs6000/rs6000-common.cc: Add REE pass as a default rs6000 target pass for O2 and above. * doc/invoke.texi: Document -free
* RISC-V: Fix wrong select_kind in riscv_compute_multilibKito Cheng2023-05-161-3/+3
| | | | | | | | | | Seems like I screw up bare-metal toolchian multi lib selection during finxing linux multi-lib selction... gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_compute_multilib): Fix wrong select_kind...
* rs6000: Fix test int_128bit-runnable.c instruction countsCarl Love2023-05-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The test reports two failures on Power 10LE: FAIL: .../int_128bit-runnable.c scan-assembler-times \\\\mvdivsq\\\\M 1 FAIL: .../int_128bit-runnable.c scan-assembler-times \\\\mvextsd2q\\\\M 6 The current counts are : vdivsq 3 vextsd2q 4 The counts changed with commit: commit 852b11da11a181df517c0348df044354ff0656d6 Author: Michael Meissner <meissner@linux.ibm.com> Date: Wed Jul 7 21:55:38 2021 -0400 Generate 128-bit int divide/modulus on power10. This patch adds support for the VDIVSQ, VDIVUQ, VMODSQ, and VMODUQ instructions to do 128-bit arithmetic. 2021-07-07 Michael Meissner <meissner@linux.ibm.com> The code generation changed significantly. There are two places where the vextsd2q is "replaced" by a vdivsq instruction thus increasing the vdivsq count from 1 to 3. The first case is: expected_result = vec_arg1[0]/4; 10000af8: 60 01 df e8 ld r6,352(r31) 10000afc: 68 01 ff e8 ld r7,360(r31) 10000b00: 76 fe e9 7c sradi r9,r7,63 10000b04: 67 4b 00 7c mtvsrdd vs32,0,r9 10000b08: 02 06 1b 10 vextsd2q v0,v0 <---- 10000b0c: 03 00 40 39 li r10,3 10000b10: 00 00 60 39 li r11,0 10000b14: 67 00 09 7c mfvrd r9,v0 10000b18: 67 02 08 7c mfvsrld r8,vs32 10000b1c: 38 50 08 7d and r8,r8,r10 10000b20: 38 58 29 7d and r9,r9,r11 10000b24: 78 4b 2b 7d mr r11,r9 10000b28: 78 43 0a 7d mr r10,r8 10000b2c: 14 30 4a 7f addc r26,r10,r6 10000b30: 14 39 6b 7f adde r27,r11,r7 10000b34: 46 f0 69 7b sldi r9,r27,62 10000b38: 82 f0 58 7b srdi r24,r26,2 10000b3c: 78 c3 38 7d or r24,r9,r24 10000b40: 74 16 79 7f sradi r25,r27,2 10000b44: 30 00 1f fb std r24,48(r31) 10000b48: 38 00 3f fb std r25,56(r31) To: expected_result = vec_arg1[0]/4; 10000af8: 69 01 1f f4 lxv vs32,352(r31) 10000afc: 04 00 20 39 li r9,4 10000b00: 00 00 40 39 li r10,0 10000b04: 67 4b 2a 7c mtvsrdd vs33,r10,r9 10000b08: 0b 09 00 10 vdivsq v0,v0,v1 <---- 10000b0c: 3d 00 1f f4 stxv vs32,48(r31) The second case were a vexts2q instruction is replaced with vdivsq: From: expected_result = arg1/16; 10000c24: 40 00 df e8 ld r6,64(r31) 10000c28: 48 00 ff e8 ld r7,72(r31) 10000c2c: 76 fe e9 7c sradi r9,r7,63 10000c30: 67 4b 00 7c mtvsrdd vs32,0,r9 10000c34: 02 06 1b 10 vextsd2q v0,v0 <--- 10000c38: 0f 00 40 39 li r10,15 10000c3c: 00 00 60 39 li r11,0 10000c40: 67 00 09 7c mfvrd r9,v0 10000c44: 67 02 08 7c mfvsrld r8,vs32 10000c48: 38 50 08 7d and r8,r8,r10 10000c4c: 38 58 29 7d and r9,r9,r11 10000c50: 78 4b 2b 7d mr r11,r9 10000c54: 78 43 0a 7d mr r10,r8 10000c58: 14 30 ca 7e addc r22,r10,r6 10000c5c: 14 39 eb 7e adde r23,r11,r7 10000c60: c6 e0 e9 7a sldi r9,r23,60 10000c64: 02 e1 d4 7a srdi r20,r22,4 10000c68: 78 a3 34 7d or r20,r9,r20 10000c6c: 74 26 f5 7e sradi r21,r23,4 10000c70: 30 00 9f fa std r20,48(r31) 10000c74: 38 00 bf fa std r21,56(r31) To: expected_result = arg1/16; 10000be8: 49 00 1f f4 lxv vs32,64(r31) 10000bec: 10 00 20 39 li r9,16 10000bf0: 00 00 40 39 li r10,0 10000bf4: 67 4b 2a 7c mtvsrdd vs33,r10,r9 10000bf8: 0b 09 00 10 vdivsq v0,v0,v1 <--- 10000bfc: 3d 00 1f f4 stxv vs32,48(r31) The patch has been tested on Power10LE with no regressions. gcc/testsuite/ * gcc.target/powerpc/int_128bit-runnable.c: Update expected instruction counts.
* rs6000: Fix test gc.target/powerpc/rs600-fpint.c test optionsCarl Love2023-05-161-2/+1
| | | | | | | | | | | | | | | The test compile option rs6000-*-* is outdated and no longer supported. The powerpc*-*-* is the defualt, so it doesn't need to be specified. The dg-options needs to specify an older processor to get the desired behavior on recent processors, since gfxopt is only off for very old CPUs, we don't guard stfiwx under it for recent processors and don't want to. This patch updates the test specifications so the test will run properly on Power10LE. Tested on Power10 LE system with no regression test failures. gcc/testsuite/: * gcc.target/powerpc/rs6000-fpint.c: Update dg-options, drop dg-do compile specifier.
* PR modula2/108344 disable default opening of /dev/ttyGaius Mulley2023-05-162-27/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes removes the static initialisation code for KeyBoardLEDs.cc. The module is only initialised if one of the exported functions is called. This is useful as the module will access /dev/tty which might not be available. TimerHandler.mod has also been changed to disable the scroll lock LED as a sign of life. gcc/m2/ChangeLog: PR modula2/108344 * gm2-libs-coroutines/TimerHandler.mod (EnableLED): New constant. (Timer): Test EnableLED before switching on the scroll LED. libgm2/ChangeLog: PR modula2/108344 * libm2cor/KeyBoardLEDs.cc (initialize_module): New function. (SwitchScroll): Call initialize_module. (SwitchNum): Call initialize_module. (SwitchCaps): Call initialize_module. (SwitchLEDs): Call initialize_module. (M2EXPORT): Remove initialization code. Signed-off-by: Gaius Mulley <gaiusmod2@gmail.com>
* aarch64: Allow moves after tied-register intrinsics (2nd edition)Richard Sandiford2023-05-162-0/+20
| | | | | | | | | | | | | I missed these two in g:4ff89f10ca0d41f9cfa76 because I was testing on a system that didn't support big-endian compilation. Testing on aarch64_be-elf shows no other related failures (although the overall results are worse than for little-endian). gcc/testsuite/ * gcc.target/aarch64/advsimd-intrinsics/bfdot-2.c: Allow mves to occur after the intrinsic instruction, rather than requiring them to happen before. * gcc.target/aarch64/advsimd-intrinsics/vdot-3-2.c: Likewise.
* libstdc++: Stop using TR1 macros in <cctype> and <cfenv>Jonathan Wakely2023-05-166-6/+157
| | | | | | | | | | | | | | | | | | | | | | | | | As with the two commits before this, the _GLIBCXX_USE_C99_CTYPE_TR1 and _GLIBCXX_USE_C99_FENV_TR1 macros are misleading when they are also used for <cctype> and <cfenv>, not only for TR1 headers. It is also wrong, because the configure checks for TR1 use -std=c++98 and a target might define the C99 features for C++11 but not for C++98. Add separate configure checks for the <ctype.h> and <fenv.h> features using -std=c++11 for the checks. Use the new macros defined by those checks in the C++11-specific parts of <cctype>, <cfenv>, and <fenv.h>. libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_USE_C99): Check for isblank in C++11 mode and define _GLIBCXX_USE_C99_CTYPE. Check for <fenv.h> functions in C++11 mode and define _GLIBCXX_USE_C99_FENV. * config.h.in: Regenerate. * configure: Regenerate. * include/c_compatibility/fenv.h: Check _GLIBCXX_USE_C99_FENV instead of _GLIBCXX_USE_C99_FENV_TR1. * include/c_global/cfenv: Likewise. * include/c_global/cctype: Check _GLIBCXX_USE_C99_CTYPE instead of _GLIBCXX_USE_C99_CTYPE_TR1.
* libstdc++: Stop using _GLIBCXX_USE_C99_STDINT_TR1 in <cstdint>Jonathan Wakely2023-05-1614-19/+372
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The _GLIBCXX_USE_C99_STDINT_TR1 macro (and the comments about it in acinclude.m4 and config.h) are misleading when it is also used for <stdint>, not only <tr1/stdint>. It is also wrong, because the configure checks for TR1 use -std=c++98 and a target might define uint32_t etc. for C++11 but not for C++98. Add a separate configure check for the <stdint.h> types using -std=c++11 for the checks. Use the result of that separate check in <cstdint> and most other places that still depend on the macro (many uses of that macro have been removed already). The remaining uses of the STDINT_TR1 macro are really for TR1, or are in the src/c++11/compatibility-*.cc files, where we don't want/need to change the condition they depend on (if those symbols were only exported when <stdint.h> types were available for -std=c++98, then that's the condition we should continue to use for whether to export the compat symbols now). Make similar changes for the related _GLIBCXX_USE_C99_INTTYPES_TR1 and _GLIBCXX_USE_C99_INTTYPES_WCHAR_T_TR1 macros, adding new macros for non-TR1 uses. libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_USE_C99): Check for <stdint.h> types in C++11 mode and define _GLIBCXX_USE_C99_STDINT. Check for <inttypes.h> features in C++11 mode and define _GLIBCXX_USE_C99_INTTYPES and _GLIBCXX_USE_C99_INTTYPES_WCHAR_T. * config.h.in: Regenerate. * configure: Regenerate. * doc/doxygen/user.cfg.in (PREDEFINED): Add new macros. * include/bits/chrono.h: Check _GLIBCXX_USE_C99_STDINT instead of _GLIBCXX_USE_C99_STDINT_TR1. * include/c_compatibility/inttypes.h: Check _GLIBCXX_USE_C99_INTTYPES and _GLIBCXX_USE_C99_INTTYPES_WCHAR_T instead of _GLIBCXX_USE_C99_INTTYPES_TR1 and _GLIBCXX_USE_C99_INTTYPES_WCHAR_T_TR1. * include/c_compatibility/stdatomic.h: Check _GLIBCXX_USE_C99_STDINT instead of _GLIBCXX_USE_C99_STDINT_TR1. * include/c_compatibility/stdint.h: Likewise. * include/c_global/cinttypes: Check _GLIBCXX_USE_C99_INTTYPES and _GLIBCXX_USE_C99_INTTYPES_WCHAR_T instead of _GLIBCXX_USE_C99_INTTYPES_TR1 and _GLIBCXX_USE_C99_INTTYPES_WCHAR_T_TR1. * include/c_global/cstdint: Check _GLIBCXX_USE_C99_STDINT instead of _GLIBCXX_USE_C99_STDINT_TR1. * include/std/atomic: Likewise. * src/c++11/cow-stdexcept.cc: Likewise. * testsuite/29_atomics/headers/stdatomic.h/c_compat.cc: Likewise. * testsuite/lib/libstdc++.exp (check_v3_target_cstdint): Likewise.
* libstdc++: Stop using _GLIBCXX_USE_C99_COMPLEX_TR1 in <complex>Jonathan Wakely2023-05-165-7/+103
| | | | | | | | | | | | | | | | | | | | | | The _GLIBCXX_USE_C99_COMPLEX_TR1 macro (and the comments about it in acinclude.m4 and config.h) are misleading when it is also used for <complex>, not only <tr1/complex>. It is also wrong, because the configure checks for TR1 use -std=c++98 and a target might define cacos etc. for C++11 but not for C++98. Add a separate configure check for the inverse trigonometric functions that are covered by _GLIBCXX_USE_C99_COMPLEX_TR1, but using -std=c++11 for the checks. Use the result of that separate check in <complex>. libstdc++-v3/ChangeLog: * acinclude.m4 (GLIBCXX_USE_C99): Check for complex inverse trig functions in C++11 mode and define _GLIBCXX_USE_C99_COMPLEX_ARC. * config.h.in: Regenerate. * configure: Regenerate. * doc/doxygen/user.cfg.in (PREDEFINED): Add new macro. * include/std/complex: Check _GLIBCXX_USE_C99_COMPLEX_ARC instead of _GLIBCXX_USE_C99_COMPLEX_TR1.
* libstdc++: Add assertion to debug_allocator testJonathan Wakely2023-05-161-1/+2
| | | | | | | libstdc++-v3/ChangeLog: * testsuite/ext/debug_allocator/check_deallocate_null.cc: Add assertion to ensure expected exception is throw.
View Lorry Controller Status