Michael Meissner [Wed, 18 Jan 2023 16:19:20 +0000 (11:19 -0500)]
PR target/107299: Fix build issue when long double is IEEE 128-bit
This patch updates the IEEE 128-bit types used in libgcc.
At the moment, we cannot build GCC when the target uses IEEE 128-bit long
doubles, such as building the compiler for a native Fedora 36 system. The
build dies when it is trying to build the _mulkc3.c and _divkc3 modules.
This patch changes libgcc to use long double for the IEEE 128-bit base type if
long double is IEEE 128-bit, and it uses _Float128 otherwise. The built-in
functions are adjusted to be the correct version based on the IEEE 128-bit base
type used.
While it is desirable to ultimately have __float128 and _Float128 use the same
internal type and mode within GCC, at present if you use the option
-mabi=ieeelongdouble, the __float128 type will use the long double type and not
the _Float128 type. We get an internal compiler error if we combine the
signbitf128 built-in with a long double type.
I've gone through several iterations of trying to fix this within GCC, and
there are various problems that have come up. I developed this alternative
patch that changes libgcc so that it does not tickle the issue. I hope we can
fix the compiler at some point, but right now, this is preventing people on
Fedora 36 systems from building compilers where the default long double is IEEE
128-bit.
2023-01-18 Michael Meissner <meissner@linux.ibm.com>
PR target/107299
* config/rs6000/_divkc3.c (COPYSIGN): Use the correct built-in based on
whether long double is IBM or IEEE.
(INFINITY): Likewise.
(FABS): Likewise.
* config/rs6000/_mulkc3.c (COPYSIGN): Likewise.
(INFINITY): Likewise.
* config/rs6000/quad-float128.h (TF): Remove definition.
(TFtype): Define to be long double or _Float128.
(TCtype): Define to be _Complex long double or _Complex _Float128.
* libgcc2.h (TFtype): Allow machine config files to override this.
(TCtype): Likewise.
* soft-fp/quad.h (TFtype): Likewise.
Michael Meissner [Wed, 18 Jan 2023 08:55:17 +0000 (03:55 -0500)]
PR target/107299: Fix build issue when long double is IEEE 128-bit
This patch updates the IEEE 128-bit types used in libgcc.
At the moment, we cannot build GCC when the target uses IEEE 128-bit long
doubles, such as building the compiler for a native Fedora 36 system. The
build dies when it is trying to build the _mulkc3.c and _divkc3 modules.
This patch creates special types for declaring complex IEEE 128-bit multiply and
divide support to use either _Float128 or long double, depending on whether long
double is IBM or IEEE.
It also uses the correct built-in functions in the libgcc complex IEEE 128-bit
multiply and divide support. This fixes the problems when long double types are
used with explicit f128 built-in functions.
While it is desirable to ultimately have __float128 and _Float128 use the same
internal type and mode within GCC, at present if you use the option
-mabi=ieeelongdouble, the __float128 type will use the long double type and not
the _Float128 type. We get an internal compiler error if we combine the
signbitf128 built-in with a long double type.
I've gone through several iterations of trying to fix this within GCC, and
there are various problems that have come up. I developed this alternative
patch that changes libgcc so that it does not tickle the issue. I hope we can
fix the compiler at some point, but right now, this is preventing people on
Fedora 36 systems from building compilers where the default long double is IEEE
128-bit.
I changed the three functions that deal with complex multiply and complex divide
support (_mulkc3, _divkc3, and float128-ifunc) to always be compiled with IEEE
128-bit long double. This is to be type correct, and avoid mismatch declaration
errors from the compiler.
2023-01-18 Michael Meissner <meissner@linux.ibm.com>
PR target/107299
* config/rs6000/_divkc3.c (COPYSIGN): Use the correct built-in based on
whether long double is IBM or IEEE.
(INFINITY): Likewise.
(FABS): Likewise.
(__divkc3): Use either _Float128 or long double for the types to match
whether long double is IBM or IEEE.
* config/rs6000/_mulkc3.c (COPYSIGN): Use the correct built-in based on
whether long double is IBM or IEEE.
(INFINITY): Likewise.
(__mulkc3): Use either _Float128 or long double for the types to match
whether long double is IBM or IEEE.
* config/rs6000/float128-ifunc.c (__mulkc3): Use either _Float128 or
long double for the types to match whether long double is IBM or IEEE.
(__divkc3): Likewise.
* config/rs6000/quad-float128.h (TC): Define to switch complex IEEE
128-bit type in machine independent code via mode attribute.
(TFtype_cmuldiv): New macro.
(TCtype_cmuldiv): Likewise.
(__mulkc3_sw): Use TFtype_cmuldiv and TCtype_cmuldiv.
(__divkc3_sw): Likewise.
(__mulkc3_hw): Likewise.
(__divkc3_hw): Likewise.
(__mulkc3): Likewise.
(__divkc3): Likewise.
Michael Meissner [Wed, 18 Jan 2023 06:10:55 +0000 (01:10 -0500)]
PR target/107299: Update IEEE 128-bit types in PowerPC libgcc.
This patch updates the IEEE 128-bit types in libgcc.
At the moment, we cannot build GCC when the target uses IEEE 128-bit long
doubles, such as building the compiler for a native Fedora 36 system. The
build dies when it is trying to build the _mulkc3.c and _divkc3 modules.
This patch changes the IEEE 128-bit type (TFtype) in the IEEE 128-bit support
to use either _Float128 or long double. Previously we would use the __float128
type. In addition, the TCtype will use the same type along with _Complex.
While it is desirable to ultimately have __float128 and _Float128 use the same
internal type and mode within GCC, at present if you use the option
-mabi=ieeelongdouble, the __float128 type will use the long double type. We
get an internal compiler error if we combine the signbitf128 built-in with a
long double type.
I've gone through several iterations of trying to fix this within GCC, and
there are various problems that have come up. I developed this alternative
patch that changes libgcc so that it does not tickle the issue. I hope we can
fix the compiler at some point, but right now, this is preventing people on
Fedora 36 systems from building compilers where the default long double is IEEE
128-bit.
I changed the three functions that deal with complex multiply and complex divide
support (_mulkc3, _divkc3, and float128-ifunc) to always be compiled with IEEE
128-bit long double. This is to be type correct, and avoid mismatch declaration
errors from the compiler.
2023-01-18 Michael Meissner <meissner@linux.ibm.com>
PR target/107299
* config/rs6000/_divkc3.c (top level): Require that long double is IEEE
128-bit.
(COPYSIGN): Use long double built-in.
(INFINITY): Likewise.
(FABS): Likewise.
(RBIG): Use TFmode constants, not KFmode.
(RMIN): Likewise.
(RMIN2): Likewise.
(RMINSCAL): Likewise.
(RMAX2): Likewise.
* config/rs6000/_mulkc3.c (top level): Require that long double is IEEE
128-bit.
(COPYSIGN): Use long double built-in.
(INFINITY): Likewise.
* config/rs6000/quad-float128.h (TF): Remove definition.
(TFtype): New macro, use _Float128 or long double.
(TCtype): Change to macro, use _Complex _Float128 or _Complex long
double.
(__mulkc3_sw): Only declare if long double is IEEE 128-bit.
(__divkc3_sw): Likewise.
(__mulkc3_hw): Likewise.
(__divkc3_hw): Likewise.
(__mulkc3): Likewise.
(__divkc3): Likewise.
* config/rs6000/t-rs6000 (fp128_cmuldiv): Add support to build IEEE
128-bit complex multiply/divide with explicit IEEE-128 long double.
(fp128_cmuldiv_static_obj): Likewise.
(fp128_cmuldiv_shared_obj): Likewise.
(fp128_cmuldiv_obj): Likewise.
(fp128_ppc_funcs): Likewise.
(FP128_CFLAGS_CMULDIV): Likewise.
* config/rs6000/t-rs6000-hw (fp128_hardfp_src): Delete, unused.
(fp128_cmuldiv_funcs): Add support to build IEEE 128-bit complex
multiply/divide with explicit IEEE-128 long double.
(fp128_cmuldiv_static_obj): Likewise.
(fp128_cmuldiv_shared_obj): Likewise.
(fp128_cmuldiv_obj): Likewise.
(fp128_hw_funcs): Likewise.
(fp128_ifunc_funcs): Delete, unused.
(fp128_ifunc_src): Likewise.
* libgcc2.h (TFtype): Allow md files to override this.
(TCtype): Likewise.
* soft-fp/quad.h (TFtype): Likewise.
Michael Meissner [Wed, 18 Jan 2023 02:37:15 +0000 (21:37 -0500)]
PR target/107299: Update IEEE 128-bit types in PowerPC libgcc.
This patch updates the IEEE 128-bit types in libgcc.
At the moment, we cannot build GCC when the target uses IEEE 128-bit long
doubles, such as building the compiler for a native Fedora 36 system. The
build dies when it is trying to build the _mulkc3.c and _divkc3 modules.
This patch changes the IEEE 128-bit type (TFtype) in the IEEE 128-bit support
to use either _Float128 or long double. Previously we would use the __float128
type. In addition, the TCtype will use the same type along with _Complex.
While it is desirable to ultimately have __float128 and _Float128 use the same
internal type and mode within GCC, at present if you use the option
-mabi=ieeelongdouble, the __float128 type will use the long double type. We
get an internal compiler error if we combine the signbitf128 built-in with a
long double type.
I've gone through several iterations of trying to fix this within GCC, and
there are various problems that have come up. I developed this alternative
patch that changes libgcc so that it does not tickle the issue. I hope we can
fix the compiler at some point, but right now, this is preventing people on
Fedora 36 systems from building compilers where the default long double is IEEE
128-bit.
I changed the three functions that deal with complex multiply and complex divide
support (_mulkc3, _divkc3, and float128-ifunc) to always be compiled with IEEE
128-bit long double. This is to be type correct, and avoid mismatch declaration
errors from the compiler.
2023-01-17 Michael Meissner <meissner@linux.ibm.com>
PR target/107299
* config/rs6000/_divkc3.c (top level): Require that long double is IEEE
128-bit.
(COPYSIGN): Use long double built-in.
(INFINITY): Likewise.
(FABS): Likewise.
(RBIG): Use TFmode constants, not KFmode.
(RMIN): Likewise.
(RMIN2): Likewise.
(RMINSCAL): Likewise.
(RMAX2): Likewise.
* config/rs6000/_mulkc3.c (top level): Require that long double is IEEE
128-bit.
(COPYSIGN): Use long double built-in.
(INFINITY): Likewise.
* config/rs6000/quad-float128.h (TF): Remove definition.
(TFtype): New macro, use _Float128 or long double.
(TCtype): Change to macro, use _Complex _Float128 or _Complex long
double.
(__mulkc3_sw): Only declare if long double is IEEE 128-bit.
(__divkc3_sw): Likewise.
(__mulkc3_hw): Likewise.
(__divkc3_hw): Likewise.
(__mulkc3): Likewise.
(__divkc3): Likewise.
* libgcc2.h (TFtype): Allow md files to override this.
(TCtype): Likewise.
* soft-fp/quad.h (TFtype): Likewise.
Michael Meissner [Fri, 13 Jan 2023 00:02:44 +0000 (19:02 -0500)]
PR target/107299: Update IEEE 128-bit types for PowerPC libgcc
This patch updates the IEEE 128-bit types in libgcc.
At the moment, we cannot build GCC when the target uses IEEE 128-bit long
doubles, such as building the compiler for a native Fedora 36 system. The
build dies when it is trying to build the _mulkc3.c and _divkc3 modules.
This patch changes the IEEE 128-bit type (TFtype) in the IEEE 128-bit support
to use either _Float128 or long double. Previously we would use the __float128
type. In addition, the TCtype will use the same type along with _Complex.
I changed the libgcc build so that the IEEE 128-bit support is now compiled
with -mabi=ieeelongdouble. For the _mulkc3 and _divkc3, I explicitly use long
double and long double _Complex to avoid type mismatch errors.
While it is desirable to ultimately have __float128 and _Float128 use the same
internal type and mode within GCC, at present if you use the option
-mabi=ieeelongdouble, the __float128 type will use the long double type. We
get an internal compiler error if we combine the signbitf128 built-in with a
long double type.
I've gone through several iterations of trying to fix this within GCC, and
there are various problems that have come up. I developed this alternative
patch that changes libgcc so that it does not tickle the issue. I hope we can
fix the compiler at some point, but right now, this is preventing people on
Fedora 36 systems from building compilers where the default long double is IEEE
128-bit.
2023-01-12 Michael Meissner <meissner@linux.ibm.com>
PR target/107299
* config/rs6000/_divkc3.c (toplevel): Add assertion for building with
-mabi=ieeelongdouble. Remove code supporting -mabi=ibmlongdouble.
(COPYSIGN): Use the long double built-in.
(INFINITY): Likewise.
(FABS): Likewise.
* config/rs6000/_mulkc3.c (toplevel): Add assertion for building with
-mabi=ieeelongdouble.
(COPYSIGN): Use the long double built-in.
(INFINITY): Likewise.
* config/rs6000/float128-ifunc.c (toplevel): Add assertion for building
with -mabi=ieeelongdouble.
* config/rs6000/quad-float128.h (TF): Delete macro.
(TFtype): Define to be _Float128 or long double.
(TCtype): Define to be _Complex _Float128 or _Complex long double.
(__mulkc3_sw): Only declare function if -mabi=ieeelongdouble.
(__divkc3_sw): Likewise.
(__mulkc3_hw): Likewise.
(__divkc3_hw): Likewise.
(__mulkc3): Likewise.
(__divkc3): Likewise.
* config/rs6000/t-float128 (FP128_CFLAGS_SW): Add -mabi=ieeelongdouble.
* config/rs6000/t-float128-hw (FP128_CFLAGS_HW): Likewise.
* libgcc2.h (TFtype): Allow MD code to override definition.
(TCtype): Likewise.
* soft-fp/quad.h (TFtype): Likewise.
Roger Sayle [Thu, 12 Jan 2023 21:47:40 +0000 (21:47 +0000)]
PR tree-optimization/92342: Optimize b & -(a==c) in match.pd
This patch is an update/tweak of Andrew Pinski's two patches for
PR tree-optimization/92342, that were originally posted by in November:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585111.html
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585112.html
Technically, the first of those was approved by Richard Biener, though
never committed, and my first thought was to simply push it for Andrew,
but the review of the second piece expressed concerns over comparisons
in non-integral modes, where the result may not be zero-one valued.
Indeed both transformations misbehave in the presence of vector mode
comparisons (these transformations are already implemented for
vec_cond elsewhere in match.pd), so my minor contribution is to limit
these new transformations to scalars, by testing that both the operands
and results are INTEGRAL_TYPE_P.
2023-01-12 Andrew Pinski <apinski@marvell.com>
Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog:
PR tree-optimization/92342
* match.pd ((m1 CMP m2) * d -> (m1 CMP m2) ? d : 0):
Use tcc_comparison and :c for the multiply.
(b & -(a CMP c) -> (a CMP c)?b:0): New pattern.
gcc/testsuite/ChangeLog:
PR tree-optimization/92342
* gcc.dg/tree-ssa/andnegcmp-1.c: New test.
* gcc.dg/tree-ssa/andnegcmp-2.c: New test.
* gcc.dg/tree-ssa/multcmp-1.c: New test.
* gcc.dg/tree-ssa/multcmp-2.c: New test.
Christophe Lyon [Fri, 25 Nov 2022 13:35:11 +0000 (13:35 +0000)]
aarch64: Fix bit-field alignment in param passing [PR105549]
While working on enabling DFP for AArch64, I noticed new failures in
gcc.dg/compat/struct-layout-1.exp (t028) which were not actually
caused by DFP types handling. These tests are generated during 'make
check' and enabling DFP made generation different (not sure if new
non-DFP tests are generated, or if existing ones are generated
differently, the tests in question are huge and difficult to compare).
Anyway, I reduced the problem to what I attach at the end of the new
gcc.target/aarch64/aapcs64/va_arg-17.c test and rewrote it in the same
scheme as other va_arg* AArch64 tests. Richard Sandiford further
reduced this to a non-vararg function, added as a second testcase.
This is a tough case mixing bit-fields and alignment, where
aarch64_function_arg_alignment did not follow what its descriptive
comment says: we want to use the natural alignment of the bit-field
type only if the user didn't reduce the alignment for the bit-field
itself.
The patch also adds a comment and assert that would help someone who
has to look at this area again.
The fix would be very small, except that this introduces a new ABI
break, and we have to warn about that. Since this actually fixes a
problem introduced in GCC 9.1, we keep the old computation to detect
when we now behave differently.
This patch adds two new tests (va_arg-17.c and
pr105549.c). va_arg-17.c contains the reduced offending testcase from
struct-layout-1.exp for reference. We update some tests introduced by
the previous patch, where parameters with bit-fields and packed
attribute now emit a different warning.
2022-11-28 Christophe Lyon <christophe.lyon@arm.com>
Richard Sandiford <richard.sandiford@arm.com>
gcc/
PR target/105549
* config/aarch64/aarch64.cc (aarch64_function_arg_alignment):
Check DECL_PACKED for bitfield.
(aarch64_layout_arg): Warn when parameter passing ABI changes.
(aarch64_function_arg_boundary): Do not warn here.
(aarch64_gimplify_va_arg_expr): Warn when parameter passing ABI
changes.
Christophe Lyon [Tue, 14 Jun 2022 21:08:33 +0000 (21:08 +0000)]
aarch64: fix warning emission for ABI break since GCC 9.1
While looking at PR 105549, which is about fixing the ABI break
introduced in GCC 9.1 in parameter alignment with bit-fields, we
noticed that the GCC 9.1 warning is not emitted in all the cases where
it should be. This patch fixes that and the next patch in the series
fixes the GCC 9.1 break.
We split this into two patches since patch #2 introduces a new ABI
break starting with GCC 13.1. This way, patch #1 can be back-ported
to release branches if needed to fix the GCC 9.1 warning issue.
The main idea is to add a new global boolean that indicates whether
we're expanding the start of a function, so that aarch64_layout_arg
can emit warnings for callees as well as callers. This removes the
need for aarch64_function_arg_boundary to warn (with its incomplete
information). However, in the first patch there are still cases where
we emit warnings were we should not; this is fixed in patch #2 where
we can distinguish between GCC 9.1 and GCC.13.1 ABI breaks properly.
The fix in aarch64_function_arg_boundary (replacing & with &&) looks
like an oversight of a previous commit in this area which changed
'abi_break' from a boolean to an integer.
We also take the opportunity to fix the comment above
aarch64_function_arg_alignment since the value of the abi_break
parameter was changed in a previous commit, no longer matching the
description.
2022-11-28 Christophe Lyon <christophe.lyon@arm.com>
Richard Sandiford <richard.sandiford@arm.com>
* gcc.target/aarch64/bitfield-abi-warning-align16-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align16-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning-align32-O2-extra.c: New
test.
* gcc.target/aarch64/bitfield-abi-warning-align8-O2.c: New test.
* gcc.target/aarch64/bitfield-abi-warning.h: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align16-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning-align32-O2-extra.C: New
test.
* g++.target/aarch64/bitfield-abi-warning-align8-O2.C: New test.
* g++.target/aarch64/bitfield-abi-warning.h: New test.
Richard Biener [Thu, 12 Jan 2023 10:18:22 +0000 (11:18 +0100)]
tree-optimization/99412 - reassoc and reduction chains
With -ffast-math we end up associating reduction chains and break
them - this is because of old code that tries to rectify reductions
into a shape likened by the vectorizer. Nowadays the rank compute
produces correct association for reduction chains and the vectorizer
has robust support to fall back to a regular reductions (via
reduction path) when it turns out to be not a proper reduction chain.
So this patch removes the special code in reassoc which makes
the TSVC s352 vectorized with -Ofast (it is already without
-ffast-math).
This branch instruction has short encoding if EQ/NE comparison against
immediate zero when the Code Density Option is enabled, but its "length"
attribute was only for normal encoding. This patch fixes it.
This patch also prevents undesireable replacement the comparison immediate
zero of the instruction (short encoding, as mentioned above) with a
register that has value of zero (normal encoding) by the postreload pass.
gcc/ChangeLog:
* config/xtensa/xtensa.md (*btrue):
Correct value of the attribute "length" that depends on
TARGET_DENSITY and operands, and add '?' character to the register
constraint of the compared operand.
Jonathan Wakely [Thu, 5 Jan 2023 20:23:26 +0000 (20:23 +0000)]
libstdc++: Use lock-free type for __platform_wait_t
For non-futex targets the __platform_wait_t type is currently uint64_t,
but that requires a lock in libatomic for some 32-bit targets. We don't
really need a 64-bit type, so use unsigned long if that is lock-free,
and int otherwise. This should mean it's lock-free on a wider set of
targets.
libstdc++-v3/ChangeLog:
* include/bits/atomic_wait.h (__detail::__platform_wait_t):
Define as unsigned long if always lock-free, and unsigned int
otherwise.
Lewis Hyatt [Thu, 29 Dec 2022 21:55:21 +0000 (16:55 -0500)]
preprocessor: Don't register pragmas in directives-only mode [PR108244]
libcpp's directives-only mode does not expect deferred pragmas to be
registered, but to date the c-family registration process has not checked for
this case. That issue became more visible since r13-1544, which added the
commonly used GCC diagnostic pragmas to the set of those registered in
preprocessing modes. Fix it by checking for directives-only mode in
c-family/c-pragma.cc.
gcc/c-family/ChangeLog:
PR preprocessor/108244
* c-pragma.cc (c_register_pragma_1): Don't attempt to register any
deferred pragmas if -fdirectives-only.
(init_pragma): Likewise.
gcc/testsuite/ChangeLog:
* c-c++-common/cpp/pr108244-1.c: New test.
* c-c++-common/cpp/pr108244-2.c: New test.
* c-c++-common/gomp/pr108244-3.c: New test.
David Malcolm [Wed, 11 Jan 2023 21:27:06 +0000 (16:27 -0500)]
analyzer: fix leak false positives on "*UNKNOWN = PTR;" [PR108252]
PR analyzer/108252 reports a false positive from -Wanalyzer-malloc-leak on
code like this:
*ptr_ptr = strdup(EXPR);
where ptr_ptr is an UNKNOWN_VALUE.
When we handle:
*UNKNOWN = PTR;
store::set_value normally marks *PTR as having escaped, and this means
we don't report PTR as leaking when the last usage of PTR is lost.
However this only works for cases where PTR is a region_svalue.
In the example in the bug, it's a conjured_svalue, rather than a
region_svalue. A similar problem can arise for FDs, which aren't
pointers.
This patch fixes the bug by updating store::set_value to mark any
values stored via *UNKNOWN = VAL as not leaking.
Additionally, sm-malloc.cc's known_allocator_p hardcodes strdup and
strndup as allocators (and thus transitioning their result to
"unchecked"), but we don't implement known_functions for these, leading
to the LHS being a CONJURED_SVALUE, rather than a region_svalue to a
heap-allocated region. A similar issue happens with functions marked
with __attribute__((malloc)). As part of a "belt and braces" fix, the
patch also updates the handling of these functions, so that they use
heap-allocated regions.
gcc/analyzer/ChangeLog:
PR analyzer/108252
* kf.cc (class kf_strdup): New.
(class kf_strndup): New.
(register_known_functions): Register them.
* region-model.cc (region_model::on_call_pre): Use
&HEAP_ALLOCATED_REGION for the default result of an external
function with the "malloc" attribute, rather than CONJURED_SVALUE.
(region_model::get_or_create_region_for_heap_alloc): Allow
"size_in_bytes" to be NULL.
* store.cc (store::set_value): When handling *UNKNOWN = VAL,
mark VAL as "maybe bound".
gcc/testsuite/ChangeLog:
PR analyzer/108252
* gcc.dg/analyzer/attr-malloc-pr108252.c: New test.
* gcc.dg/analyzer/fd-leak-pr108252.c: New test.
* gcc.dg/analyzer/flex-with-call-summaries.c: Remove xfail from
warning false +ve directives.
* gcc.dg/analyzer/pr103217-2.c: Add -Wno-analyzer-too-complex.
* gcc.dg/analyzer/pr103217-3.c: Likewise.
* gcc.dg/analyzer/strdup-pr108252.c: New test.
* gcc.dg/analyzer/strndup-pr108252.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Jakub Jelinek [Wed, 11 Jan 2023 21:18:42 +0000 (22:18 +0100)]
c: Don't emit DEBUG_BEGIN_STMTs for K&R function argument declarations [PR105972]
K&R function parameter declarations are handled by calling
recursively c_parser_declaration_or_fndef in a loop, where each such
call will add_debug_begin_stmt at the start.
Now, if the K&R function definition is not a nested function,
building_stmt_list_p () is false and so we don't emit the DEBUG_BEGIN_STMTs
anywhere, but if it is a nested function, we emit it in the containing
function at the point of the nested function definition.
As the following testcase shows, it can cause ICEs if the containing
function has var-tracking disabled but nested function has them enabled,
as the DEBUG_BEGIN_STMTs are added to the containing function which
shouldn't have them but MAY_HAVE_DEBUG_MARKER_STMTS is checked already
for the nested function, or just wrong experience in the debugger.
The following patch ensures we don't emit any such DEBUG_BEGIN_STMTs for the
K&R function parameter declarations even in nested functions.
2023-01-11 Jakub Jelinek <jakub@redhat.com>
PR c/105972
* c-parser.cc (c_parser_declaration_or_fndef): Disable debug non-bind
markers for K&R function parameter declarations of nested functions.
Roger Sayle [Wed, 11 Jan 2023 16:54:58 +0000 (16:54 +0000)]
PR tree-optimization/71343: Value number X<<2 as X*4.
This patch is the second part of a fix for PR tree-optimization/71343,
that implements Richard Biener's suggestion of using tree-ssa's value
numbering instead of match.pd. The change is that when assigning a
value number for the expression X<<C, we actually look-up or insert
the value number for the multiplication X*(1<<C). This elegantly
handles the fact that we (intentionally) don't canonicalize these as
equivalent in GIMPLE, and the optimization/equivalence in PR 71343 now
happens by (tree-ssa SCCVN) magic.
2023-01-11 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR tree-optimization/71343
* tree-ssa-sccvn.cc (visit_nary_op) <case LSHIFT_EXPR>: Make
the value number of the expression X << C the same as the value
number for the multiplication X * (1<<C).
gcc/testsuite/ChangeLog
PR tree-optimization/71343
* gcc.dg/pr71343-2.c: New test case.
David Faust [Tue, 10 Jan 2023 18:53:12 +0000 (10:53 -0800)]
bpf: correct bpf_print_operand for floats [PR108293]
The existing logic in bpf_print_operand was only correct for integral
CONST_DOUBLEs, and emitted garbage for floating point modes. Fix it so
floating point mode operands are correctly handled.
PR target/108293
gcc/
* config/bpf/bpf.cc (bpf_print_operand): Correct handling for
floating point modes.
gcc/testsuite/
* gcc.target/bpf/double-1.c: New test.
* gcc.target/bpf/double-2.c: New test.
* gcc.target/bpf/float-1.c: New test.
Kewen Lin [Wed, 11 Jan 2023 12:59:24 +0000 (06:59 -0600)]
rs6000/test: Make ppc-fortran.exp only available for PowerPC target
When testing one patch which adds a fortran test case into
test bucket powerpc/ppc-fortran/, I found one unexpected
failure on a non-PowerPC target. It's due to that
ppc-fortran.exp does not exit early if the testing target
isn't a PowerPC target. This patch is to make it exit
immediately if the testing target isn't a PowerPC target.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/ppc-fortran/ppc-fortran.exp: Exit immediately if
the testing target isn't a PowerPC target.
Kewen Lin [Wed, 11 Jan 2023 12:59:08 +0000 (06:59 -0600)]
rs6000: Make P10_FUSION honour tuning setting
We noticed this issue when Segher reviewed the patch for
PR104024. When there is no explicit setting for option
-mpower10-fusion, we enable OPTION_MASK_P10_FUSION for
TARGET_POWER10. But it's not right, it should honour
tuning setting instead.
This patch is to fix it accordingly, it's bootstrapped
, and regtested on powerpc64-linux-gnu P8 and
powerpc64le-linux-gnu P9.
But on powerpc64le-linux-gnu P10 it had one regression
failure against the test case gcc.target/powerpc/pr105586.c.
I looked into it and confirmed that a latent bug was
exposed and filed one separated bug PR108273 instead.
Richard Biener [Mon, 9 Jan 2023 08:42:22 +0000 (09:42 +0100)]
tree-optimization/107767 - not profitable switch conversion
When the CFG has not merged equal PHI defs in a switch stmt the
cost model from switch conversion gets off and we prefer a
jump table over branches. The following fixes that by recording
cases that will be merged later and more appropriately counting
unique values.
Jakub Jelinek [Wed, 11 Jan 2023 12:06:14 +0000 (13:06 +0100)]
testsuite: Enable pr108308.c test on all int32 targets [PR108308]
This test seems to rely on 32-bit int (and uses a wider constant
which shouldn't fit into int), I've initially enabled it on ilp32+lp64
target, but apparently it works on llp64 too, so I've changed it to
int32.
2023-01-11 Jakub Jelinek <jakub@redhat.com>
PR target/108308
* gcc.dg/pr108308.c: Use int32 target rather than { ilp32 || lp64 }.
Martin Liska [Wed, 28 Dec 2022 08:11:40 +0000 (09:11 +0100)]
switch expansion: limit JT growth param values
Currently, one can request a huge jump table creation which
leads to a non-sensual huge output. Moreover, use auto_vec rather
than a stack-allocated array.
PR middle-end/107976
gcc/ChangeLog:
* params.opt: Limit JT params.
* stmt.cc (emit_case_dispatch_table): Use auto_vec.
The following relaxes a heuristic that prevents creating irreducible
loops from FSM threads not covering multi-way branches. Instead of
allowing threads that adhere to
with reasoning "We also consider it worth creating an irreducible inner loop if
the number of copied statement is low relative to the length of the path --
in that case there's little the traditional loop optimizer would have done
anyway, so an irreducible loop is not so bad." that I cannot make much
sense of the following patch changes that to only allow those after
loop optimization and when they are (scaled) short:
This allows us to get rid of --param fsm-scale-path-blocks which
previous to the bisected revision allowed an enlarged path covering
the original allowance (but we do not consider that enlarged path
now because enlarging it doesn't add any information).
Richard Biener [Wed, 11 Jan 2023 08:32:36 +0000 (09:32 +0100)]
tree-optimization/108353 - copyprop iteration order
After recent improvements to copyprop to catch more constants
it shows that the current iteration order prefering forward
progress over iterating doesn't make much sense for an SSA
propagator. The following instead first iterates cycles which
makes sure to not start with optimistically constant PHIs out
of cycles that optimistically do not exit.
Jakub Jelinek [Wed, 11 Jan 2023 09:40:54 +0000 (10:40 +0100)]
fortran: Fix up function types for realloc and sincos{,f,l} builtins [PR108349]
As reported in the PR, the FUNCTION_TYPE for __builtin_realloc in the
Fortran FE is wrong since r0-100026-gb64fca63690ad which changed
- tmp = tree_cons (NULL_TREE, pvoid_type_node, void_list_node);
- tmp = tree_cons (NULL_TREE, size_type_node, tmp);
- ftype = build_function_type (pvoid_type_node, tmp);
+ ftype = build_function_type_list (pvoid_type_node,
+ size_type_node, pvoid_type_node,
+ NULL_TREE);
gfc_define_builtin ("__builtin_realloc", ftype, BUILT_IN_REALLOC,
"realloc", false);
The return type is correct, void *, but the first argument should be
void * too and only second one size_t, while the above change changed
realloc to be void *__builtin_realloc (size_t, void *);
I went through all other changes from that commit and found that
__builtin_sincos{,f,l} got broken as well, instead of the former
void __builtin_sincos{,f,l} (ftype, ftype *, ftype *);
where ftype is {double,float,long double} it is now incorrectly
void __builtin_sincos{,f,l} (ftype *, ftype *);
The following patch fixes that, plus some formatting issues around
the spots I've changed.
2023-01-11 Jakub Jelinek <jakub@redhat.com>
PR fortran/108349
* f95-lang.cc (gfc_init_builtin_function): Fix up function types
for BUILT_IN_REALLOC and BUILT_IN_SINCOS{F,,L}. Formatting fixes.
xtensa: Make instruction cost estimation for size more accurate
Until now, we applied COSTS_N_INSNS() (multiplying by 4) after dividing
the instruction length by 3, so we couldn't express the difference less
than modulo 3 in insn cost for size (e.g. 11 Bytes and 12 bytes cost the
same).
* config/xtensa/xtensa.cc (xtensa_insn_cost):
Let insn cost for size be obtained by applying COSTS_N_INSNS()
to instruction length and then dividing by 3.
Gaius Mulley [Tue, 10 Jan 2023 17:25:49 +0000 (17:25 +0000)]
[PATCH, Modula2] PR-108142 Many empty directories created in the build directory
PR-108142 Modula-2 configure generates many subdirectories in the top
build directory. This patch dynamically creates subdirectories under
gcc/m2 if and when required.
Richard Biener [Tue, 10 Jan 2023 12:48:51 +0000 (13:48 +0100)]
tree-optimization/106293 - missed DSE with virtual LC PHI
Degenerate virtual PHIs can break DSEs fragile heuristic as to what
defs it can handle for further processing. The following enhances
it to look through degenerate PHIs by means of a worklist, processing
the degenerate PHI defs uses to the defs array. The rewrite of
virtuals into loop-closed SSA caused this to issue appear more often.
The patch itself is mostly re-indenting the new loop body.
PR tree-optimization/106293
* tree-ssa-dse.cc (dse_classify_store): Use a worklist to
process degenerate PHI defs.
Roger Sayle [Tue, 10 Jan 2023 14:05:46 +0000 (14:05 +0000)]
PR rtl-optimization/106421: ICE in bypass_block from non-local goto.
This patch fixes PR rtl-optimization/106421, an ICE-on-valid (but
undefined) regression. The fix, as proposed by Richard Biener, is to
defend against BLOCK_FOR_INSN returning NULL in cprop's bypass_block.
2023-01-10 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR rtl-optimization/106421
* cprop.cc (bypass_block): Check that DEST is local to this
function (non-NULL) before calling find_edge.
gcc/testsuite/ChangeLog
PR rtl-optimization/106421
* gcc.dg/pr106421.c: New test case.
The problem in PR 108110 is that elements describing the same base
parameter in ipa_param_body_adjustments::m_replacements are not
adjacent to each other, which is something that
ipa_param_body_adjustments::modify_call_stmt when it gathers all
replacements for a parameter.
One option would be to simply always keep looking until the end of the
vector (see bugzilla comment 15 for a one-line fix) but the correct
thing to do is to keep the elements of the vector sorted and thus make
such elements adjacent again. This patch does that and then also
modifies the look-ups to take advantage of it.
Since the one user of ipa_param_body_adjustments that is not
tree-inline.cc, which is OpenMP declare SIMD cloning code, also
registers its own replacements and in theory pointers to elements of
the m_replacements vector can leak through public method
get_expr_replacement, I decided that in those cases it is the
responsibility of the user of the class to call the sorting method
between the replacement registrations and the first lookup. That is
why the patch also adds a line to omp-simd-clone.cc.
gcc/ChangeLog:
2023-01-09 Martin Jambor <mjambor@suse.cz>
PR ipa/108110
* ipa-param-manipulation.h (ipa_param_body_adjustments): New members
sort_replacements, lookup_first_base_replacement and
m_sorted_replacements_p.
* ipa-param-manipulation.cc: Define INCLUDE_ALGORITHM.
(ipa_param_body_adjustments::register_replacement): Set
m_sorted_replacements_p to false.
(compare_param_body_replacement): New function.
(ipa_param_body_adjustments::sort_replacements): Likewise.
(ipa_param_body_adjustments::common_initialization): Call
sort_replacements.
(ipa_param_body_adjustments::ipa_param_body_adjustments): Initialize
m_sorted_replacements_p.
(ipa_param_body_adjustments::lookup_replacement_1): Rework to use
std::lower_bound.
(ipa_param_body_adjustments::lookup_first_base_replacement): New
function.
(ipa_param_body_adjustments::modify_call_stmt): Use
lookup_first_base_replacement.
* omp-simd-clone.cc (ipa_simd_modify_function_body): Call
adjustments->sort_replacements.
Richard Biener [Tue, 10 Jan 2023 09:42:21 +0000 (10:42 +0100)]
tree-optimization/108314 - avoid BIT_NOT optimization for extract-last
The extract-last reduction internal function expects the then and
else clause as vector and scalar and thus we cannot perform optimization
of the inversion of the condition by swapping the then/else clauses.
PR tree-optimization/108314
* tree-vect-stmts.cc (vectorizable_condition): Do not
perform BIT_NOT_EXPR optimization for EXTRACT_LAST_REDUCTION.
Xianmiao Qu [Tue, 10 Jan 2023 15:00:32 +0000 (23:00 +0800)]
C-SKY: Define SYSROOT_SUFFIX_SPEC.
The earlier patch
https://gcc.gnu.org/pipermail/gcc-patches/2021-July/575418.html
refine the way to generate sysroot suffix, but it can't find the
right path for all CPUs. The SYSROOT_SUFFIX_SPEC should be defined
to fix it.
Xianmiao Qu [Tue, 10 Jan 2023 14:48:21 +0000 (22:48 +0800)]
C-SKY: Fix float abi option in MULTILIB_DEFAULTS.
The msoft-float is alias of mfloat-abi=soft, use mfloat-abi=soft
in MULTILIB_DEFAULTS to correspond to the option in MULTILIB_OPTIONS,
otherwise it will find the wrong path.
gcc/
* config/csky/csky.h (MULTILIB_DEFAULTS): Fix float abi option.
Xianmiao Qu [Tue, 10 Jan 2023 13:48:15 +0000 (21:48 +0800)]
C-SKY: Fix patterns' condition for ck802 smart mode.
Ck802 smart mode should not be treated as ck801.
It do only allocate r0-r8 registers like ck801,
but support 32-bits intructions.
This bug will cause ICE when compiler pr43164.c for ck802 big-endian,
/src/gcc/gcc/testsuite/gcc.c-torture/compile/pr43164.c:16:1: error: insn does not satisfy its constraints:
(insn 48 28 30 2 (set (reg:SI 0 a0 [230])
(ior:SI (reg:SI 2 a2 [222])
(ashift:SI (const_int 1 [0x1])
(const_int 24 [0x18])))) "/src/gcc/gcc/testsuite/gcc.c-torture/compile/pr43164.c":15:10 224 {smart_bseti}
(expr_list:REG_DEAD (reg:SI 2 a2 [222])
(nil)))
Xianmiao Qu [Tue, 1 Nov 2022 07:49:03 +0000 (15:49 +0800)]
C-SKY: Skip other CPUs if the testcases are only for ck801.
Refine some testcases for ck801, if the testcase is only for
ck801, add the filename prefix "ck801-", and add dg-skip-if
to skip other CPUs.
gcc/testsuite/
* gcc.target/csky/and3a.c: Rename to ...
* gcc.target/csky/ck801-and.c: ... this.
* gcc.target/csky/constpool-3.c: Rename to ...
* gcc.target/csky/constpool-2.c: ... this, Rename to ...
* gcc.target/csky/constpool-1.c: ... this, Rename to ...
* gcc.target/csky/ck801-constpool.c: ... this, and skip
if the CPU is not ck801.
* gcc.target/csky/ck801-branch.c: Skip if the CPU is not ck801.
Xianmiao Qu [Thu, 27 Oct 2022 09:26:54 +0000 (17:26 +0800)]
C-SKY: Add conditions for ceil etc patterns.
The ceil etc functions can be only inlined as instruction when
they can raise the "inexact" exception. Without the adding
conditions, it will cause the "gcc.dg/torture/builtin-fp-int-inexact-c2x.c"
etc cases fails.
gcc/
* config/csky/csky_insn_fpuv3.md (l<frm_pattern><fixsuop><mode>si2): Test
flag_fp_int_builtin_inexact || !flag_trapping_math.
(<frm_pattern><mode>2): Likewise.
Jonathan Wakely [Mon, 9 Jan 2023 10:45:31 +0000 (10:45 +0000)]
libstdc++: Fix some algos for 16-bit size_t [PR108221]
Some standard algorithms fail to compile when size_t or ptrdiff_t is
narrower than int. The __lg helper function is ambiguous if ptrdiff_t is
short or __int20, so replace it with a function template that works for
those types as well as signed/unsigned int/long/long long. The helpers
for stable_sort perform arithmetic on size values and assume the types
won't change, which isn't true if the type promotes to int.
libstdc++-v3/ChangeLog:
PR libstdc++/108221
* include/bits/stl_algobase.h (__lg): Replace six overloads with
a single function template for all integer types.
* include/bits/stl_algo.h (__merge_adaptive_resize): Cast
arithmetic results back to _Distance.
Jonathan Wakely [Mon, 9 Jan 2023 10:45:31 +0000 (10:45 +0000)]
libstdc++: Fix std::span constraint for sizeof(size_t) < sizeof(int) [PR108221]
The default constructor has a constraint that is always false if
arithmetic on size_t values promotes to int. Rewrite the constraint
exactly as written in the standard, which works correctly.
libstdc++-v3/ChangeLog:
PR libstdc++/108221
* include/std/span (span::span()): Un-simplify constraint to
work for size_t of lesser rank than int.
Eric Botcazou [Mon, 9 Jan 2023 22:50:43 +0000 (23:50 +0100)]
Modula-2: fix documentation layout
The Modula-2 documentation is rejected by older versions of Makeinfo because
the web of @node markers is fairly broken, apparently some subsections were
moved around, most notably between the Overview and Using sections, and the
@node markers were not (properly) adjusted.
gcc/
* doc/gm2.texi (Overview): Fix @node markers.
(Using): Likewise. Remove subsections that were moved to Overview
from the menu and move others around.
Jakub Jelinek [Mon, 9 Jan 2023 22:41:20 +0000 (23:41 +0100)]
c++: Only do maybe_init_list_as_range optimization if !processing_template_decl [PR108047]
The last testcase in this patch ICEs, because
maybe_init_list_as_range -> maybe_init_list_as_array
calls maybe_constant_init in:
/* Don't do this if the conversion would be constant. */
first = maybe_constant_init (first);
if (TREE_CONSTANT (first))
return NULL_TREE;
but maybe_constant_init shouldn't be called when processing_template_decl.
While we could replace that call with fold_non_dependent_init, my limited
understanding is that this is an optimization and even if we don't optimize
it when processing_template_decl, build_user_type_conversion_1 will be
called again during instantiation with !processing_template_decl if it is
every instantiated and we can do the optimization only then.
Joseph Myers [Mon, 9 Jan 2023 21:56:34 +0000 (21:56 +0000)]
c: Check for modifiable static compound literals in inline definitions
The C rule against modifiable objects with static storage duration in
inline definitions should apply to compound literals (using the C2x
feature of storage-class specifiers for compound literals) just as to
variables. Add a call to record_inline_static for compound literals
to make sure this case is detected.
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
Eric Botcazou [Sun, 25 Dec 2022 21:25:21 +0000 (22:25 +0100)]
ada: Simplify finalization of temporaries created for interface objects
The expansion of (class-wide) interface objects generates a temporary that
holds the actual data and the objects are rewritten as the renaming of the
dereference at the interface tag present in it. These temporaries may need
to be finalized and this is currently done through the renamings, by using
pattern matching to recognize the original source constructs.
Now these temporaries may also need to be adjusted and this is currently
done "naturally", i.e. by using the standard machinery for them, so there
is no fundamental reason why the finalization cannot be done this way too.
Therefore this changes removes the special machinery implemented for their
finalization and let them be handled by the standard one instead.
gcc/ada/
* exp_util.ads (Is_Tag_To_Class_Wide_Conversion): Delete.
(Is_Displacement_Of_Object_Or_Function_Result): Likewise.
* exp_util.adb (Is_Tag_To_Class_Wide_Conversion): Rename to...
(Is_Temporary_For_Interface_Object): ...this.
(Is_Finalizable_Transient): Adjust call to above renaming.
(Is_Displacement_Of_Object_Or_Function_Result): Delete.
(Requires_Cleanup_Actions): Remove special handling of the
temporaries created for interface objects.
* exp_ch7.adb (Build_Finalizer): Likewise.
Jakub Jelinek [Mon, 9 Jan 2023 12:36:22 +0000 (13:36 +0100)]
calls: Fix up TYPE_NO_NAMED_ARGS_STDARG_P handling [PR107453]
On powerpc64le-linux, the following patch fixes
-FAIL: gcc.dg/c2x-stdarg-4.c execution test
-FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O0 execution test
-FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O1 execution test
-FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O2 execution test
-FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O2 -flto -fno-use-linker-plugin -flto-partition=none execution test
-FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects execution test
-FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -O3 -g execution test
-FAIL: gcc.dg/torture/c2x-stdarg-split-1a.c -Os execution test
The problem is mismatch between the caller and callee side.
On the callee side, we do:
/* NAMED_ARG is a misnomer. We really mean 'non-variadic'. */
if (!cfun->stdarg)
data->arg.named = 1; /* No variadic parms. */
else if (DECL_CHAIN (parm))
data->arg.named = 1; /* Not the last non-variadic parm. */
else if (targetm.calls.strict_argument_naming (all->args_so_far))
data->arg.named = 1; /* Only variadic ones are unnamed. */
else
data->arg.named = 0; /* Treat as variadic. */
which is later passed to the target hooks to determine if a particular
argument is named or not. Now, cfun->stdarg is determined from the stdarg_p
call, which for the new C2X TYPE_NO_NAMED_ARGS_STDARG_P function types
(rettype fn (...)) returns true. Such functions have no named arguments,
so data->arg.named will be 0 in function.cc. But on the caller side,
as TYPE_NO_NAMED_ARGS_STDARG_P function types have TYPE_ARG_TYPES NULL,
we instead treat those calls as unprototyped even when they are prototyped
- /* If we know nothing, treat all args as named. */ n_named_args = num_actuals;
in 2 spots. We need to treat the TYPE_NO_NAMED_ARGS_STDARG_P cases as
prototyped with no named arguments.
2023-01-09 Jakub Jelinek <jakub@redhat.com>
PR target/107453
* calls.cc (expand_call): For calls with
TYPE_NO_NAMED_ARGS_STDARG_P (funtype) use zero for n_named_args.
Formatting fix.
Richard Biener [Mon, 9 Jan 2023 11:46:28 +0000 (12:46 +0100)]
middle-end/69482 - not preserving volatile accesses
The following addresses a long standing issue with not preserving
accesses to non-volatile objects through volatile qualified
pointers in the case that object gets expanded to a register. The
fix is to treat accesses to an object with a volatile qualified
access as forcing that object to memory. This issue got more
exposed recently so it regressed more since GCC 11.
PR middle-end/69482
* cfgexpand.cc (discover_nonconstant_array_refs_r): Volatile
qualified accesses also force objects to memory.
* gcc.target/i386/pr69482-1.c: New testcase.
* gcc.target/i386/pr69482-2.c: Likewise.
This patch optimizes the operation of cutting and splicing two register
values at a specified bit position, in other words, combining (bitwise
ORing) bits 0 through (C-1) of the register with bits C through 31
of the other, where C is the specified immediate integer 17 through 31.
This typically applies to signed copy of floating point number and
__builtin_return_address() if the windowed register ABI, and saves one
instruction compared to four shifts and a bitwise OR by the default RTL
combination pass.
gcc/ChangeLog:
* config/xtensa/xtensa.md (*splice_bits):
New insn_and_split pattern.
This patch introduces a convenient helper function for integer immediate
addition with scratch register as needed, that splits and emits either
up to two ADDI/ADDMI machine instructions or an addition by register
following an integer immediate load (which may later be transformed by
constantsynth).
By using the helper function, it makes stack frame adjustment logic
simplified and instruction count less in some cases.
gcc/ChangeLog:
* config/xtensa/xtensa.cc
(xtensa_split_imm_two_addends, xtensa_emit_add_imm):
New helper functions.
(xtensa_set_return_address, xtensa_output_mi_thunk):
Change to use the helper function.
(xtensa_emit_adjust_stack_ptr): Ditto.
And also change to try reusing the content of scratch register
A9 if the register is not modified in the function body.
LIU Hao [Fri, 6 Jan 2023 15:18:15 +0000 (23:18 +0800)]
Always define `WIN32_LEAN_AND_MEAN` before <windows.h>
Recently, mingw-w64 has got updated <msxml.h> from Wine which is included
indirectly by <windows.h> if `WIN32_LEAN_AND_MEAN` is not defined. The
`IXMLDOMDocument` class has a member function named `abort()`, which gets
affected by our `abort()` macro in "system.h".
`WIN32_LEAN_AND_MEAN` should, nevertheless, always be defined. This
can exclude 'APIs such as Cryptography, DDE, RPC, Shell, and Windows
Sockets' [1], and speed up compilation of these files a bit.
Jonathan Wakely [Fri, 6 Jan 2023 20:54:23 +0000 (20:54 +0000)]
libstdc++: Suppress -Waddress warning in tzdb.cc [PR108228]
For some tarets the weak symbol is always defined, so we get a warning
that its address is never null. The warning isn't useful in this case,
so suppress it.
Abstract the atomic counter used to synchronize access to time_zone
infos behind a Lockable class API, and use atomic_signed_lock_free
instead of atomic<int_least32_t>, as that should be the most efficient
type. (For futex-supporting targets it makes no difference, but might
benefit other targets in future.)
The new API allows the calling code to be simpler, without needing to
repeat the same error prone preprocessor conditions in multiple places.
It also allows using template metaprogramming to decide whether to use
the atomic or a mutex, which gives us more flexibility than only using
preprocessor conditions. That allows us to choose the mutex
implementation for targets such as hppa-hp-hpux11.11 where 32-bit
atomics are not lock-free and so would introduce an unwanted dependency
on libatomic.
libstdc++-v3/ChangeLog:
PR libstdc++/108235
* src/c++20/tzdb.cc (time_zone::_Impl::RulesCounter): New class
template and partial specialization for synchronizing access to
time_zone::_Impl::infos.
(time_zone::_M_get_sys_info, reload_tzdb): Adjust uses of
rules_counter.
Joseph Myers [Fri, 6 Jan 2023 19:31:26 +0000 (19:31 +0000)]
c: C2x semantics for __builtin_tgmath
__builtin_tgmath implements <tgmath.h> semantics for integer generic
arguments that handle cases involving _FloatN / _FloatNx types as
specified in TS 18661-3 plus some defect fixes.
C2x has further changes to the semantics for <tgmath.h> macros with
such types, which should also be considered defect fixes (although
handled through the integration of TS 18661-3 in C2x rather than
through an issue tracking process). Specifically, the rules were
changed because of problems raised with using the macros with the
evaluation format types such as float_t and _Float32_t: the older
version of the rules didn't allow passing _FloatN / _FloatNx types to
the narrowing macros returning float or double, or passing float /
double / long double to the narrowing macros returning _FloatN /
_FloatNx, which was a problem with the evaluation format types which
could be either kind of type depending on the value of
FLT_EVAL_METHOD.
Thus the new rules allow cases of mixing types which were not allowed
before - which is not itself a problem for __builtin_tgmath - and, as
part of the changes, the handling of integer arguments was also
changed: if there is any _FloatNx generic argument, integer generic
arguments are treated as _Float32x (not double), while the rule about
treating integer arguments to narrowing macros returning _FloatN or
_FloatNx as _Float64 not double was removed (no longer needed now
double is a valid argument to such macros).
Implement the changes for __builtin_tgmath. (The changes also added a
rule that if any argument is _DecimalNx, integer arguments are treated
as _Decimal64x, but GCC doesn't support _DecimalNx types so nothing is
done about that.)
I have a corresponding glibc patch to update glibc test expectations
for C2x and also ensure that appropriate semantics are followed when
GCC 7 through 12 are used with <tgmath.h> (avoiding __builtin_tgmath
in cases where it doesn't match the C2x semantics).
Bootstrapped with no regressions for x86_64-pc-linux-gnu.
gcc/
* doc/extend.texi (__builtin_tgmath): Do not restate standard rule
for handling real integer types.
gcc/c/
* c-parser.cc (c_parser_postfix_expression): Handle integer
generic arguments to functions passed to __builtin_tgmath as
_Float32x if any argument has _FloatNx or _Complex _FloatNx type.
Do not handle integer arguments to some narrowing functions as
_Float64.
gcc/testsuite/
* gcc.dg/builtin-tgmath-3.c: Update expectations and add more
tests.
Jonathan Wakely [Fri, 6 Jan 2023 13:42:07 +0000 (13:42 +0000)]
libstdc++: Fix misuse of alloca in std::bitset [PR108214]
The use of alloca in a constructor is wrong, because the memory is gone
after the constructor returns, and will be overwritten by a subsequent
function call. This didn't show up in testing because function inlining
alters the stack usage.
libstdc++-v3/ChangeLog:
PR libstdc++/108214
* include/std/bitset (operator>>): Use alloca in the right
scope, not in a constructor.
* testsuite/20_util/bitset/io/input.cc: Check case from PR.
git://gcc.gnu.org / gcc.git / log