Richard Biener [Wed, 15 Jun 2022 09:27:31 +0000 (11:27 +0200)]
tree-optimization/105971 - less surprising refs_may_alias_p_2
When DSE asks whether __real a is using __imag a it gets a surprising
result when a is a FUNCTION_DECL. The following makes sure this case
is less surprising to callers but keeping the bail-out for the
non-decl case where it is true that PTA doesn't track aliases to code
correctly.
2022-06-15 Richard Biener <rguenther@suse.de>
PR tree-optimization/105971
* tree-ssa-alias.cc (refs_may_alias_p_2): Put bail-out for
FUNCTION_DECL and LABEL_DECL refs after decl-decl disambiguation
to leak less surprising alias results.
* gcc.dg/torture/pr106971.c: New testcase.
(cherry picked from commit
8c2733e16ec1c0cdda3db4cdc5ad158a96a658e8)
Richard Biener [Wed, 15 Jun 2022 08:54:48 +0000 (10:54 +0200)]
tree-optimization/105969 - FPE with array diagnostics
For a [0][0] array we have to be careful when dividing by the element
size which is zero for the outermost dimension. Luckily the division
is only for an overflow check which is pointless for array size zero.
2022-06-15 Richard Biener <rguenther@suse.de>
PR tree-optimization/105969
* gimple-ssa-sprintf.cc (get_origin_and_offset_r): Avoid division
by zero in overflow check.
* gcc.dg/pr105969.c: New testcase.
(cherry picked from commit
edb9330c29fe8a0a0b76df6fafd6a223a4d0e41f)
Richard Biener [Tue, 14 Jun 2022 08:59:49 +0000 (10:59 +0200)]
middle-end/105965 - add missing v_c_e <{ el }> simplification
When we got the simplification of bit-field-ref to view-convert
we lost the ability to detect FMAs since we cannot look through
_1 = {_10};
_11 = VIEW_CONVERT_EXPR<float>(_1);
the following amends the (view_convert CONSTRUCTOR) pattern
to handle this case.
2022-06-14 Richard Biener <rguenther@suse.de>
PR middle-end/105965
* match.pd (view_convert CONSTRUCTOR): Handle single-element
CTOR case.
* gcc.target/i386/pr105965.c: New testcase.
(cherry picked from commit
90467f0ad649d0817f9e034596a0fb85605b55af)
Richard Biener [Tue, 14 Jun 2022 09:10:13 +0000 (11:10 +0200)]
tree-optimization/105946 - avoid accessing excess args from uninit diag
uninit diagnostics uses passing via reference and access attributes
but that iterates over function type arguments which can in some
cases appearantly outrun the actual arguments leading to ICEs.
The following simply ignores not present arguments.
2022-06-14 Richard Biener <rguenther@suse.de>
PR tree-optimization/105946
* tree-ssa-uninit.cc (maybe_warn_pass_by_reference):
Do not look at arguments not specified in the function call.
(cherry picked from commit
e07a876c07601e1f3a27420f7d055d20193c362c)
Richard Biener [Fri, 1 Jul 2022 12:11:35 +0000 (14:11 +0200)]
target/105459 - allow delayed target option node fixup
The following avoids the need to massage the target optimization
node at WPA time when we fixup the optimization node, copying
FP related flags from callee to caller. The target is already
set up to fixup, but that only works when not switching between
functions. After fixing that the fixup is then done at LTRANS
time when materializing the function.
2022-07-01 Richard Biener <rguenthert@suse.de>
PR target/105459
* config/i386/i386-options.cc (ix86_set_current_function):
Rebuild the target optimization node whenever necessary,
not only when the optimization node didn't change.
* gcc.dg/lto/pr105459_0.c: New testcase.
(cherry picked from commit
4c94382a132a4b2b9d020806549a006fa6764d1b)
GCC Administrator [Tue, 19 Jul 2022 00:19:24 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Mon, 18 Jul 2022 00:19:06 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Sun, 17 Jul 2022 00:19:13 +0000 (00:19 +0000)]
Daily bump.
Steve Kargl [Fri, 15 Jul 2022 20:07:15 +0000 (22:07 +0200)]
Fortran: do not generate conflicting results under -ff2c [PR104313]
gcc/fortran/ChangeLog:
PR fortran/104313
* trans-decl.cc (gfc_generate_return): Do not generate conflicting
fake results for functions with no result variable under -ff2c.
gcc/testsuite/ChangeLog:
PR fortran/104313
* gfortran.dg/pr104313.f: New test.
(cherry picked from commit
517fb1a78102df43f052c6934c27dd51d786aff7)
GCC Administrator [Sat, 16 Jul 2022 00:19:13 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Fri, 15 Jul 2022 00:19:21 +0000 (00:19 +0000)]
Daily bump.
Michael Meissner [Thu, 14 Jul 2022 15:16:08 +0000 (11:16 -0400)]
[BACKPORT] Disable generating load/store vector pairs for block copies.
Testing has found that using load and store vector pair for block copies
can result in a slow down on power10. This patch disables using the
vector pair instructions for block copies if we are tuning for power10.
2022-06-11 Michael Meissner <meissner@linux.ibm.com>
gcc/
* config/rs6000/rs6000.cc (rs6000_option_override_internal): Do
not generate block copies with vector pair instructions if we are
tuning for power10. Back port from master branch.
Surya Kumari Jangala [Fri, 10 Jun 2022 14:22:57 +0000 (19:52 +0530)]
regrename: Fix -fcompare-debug issue in check_new_reg_p [PR105041]
In check_new_reg_p, the nregs of a du chain is computed by obtaining the
MODE of the first element in the chain, and then calling
hard_regno_nregs() with the MODE. But the first element of the chain can
be a DEBUG_INSN whose mode need not be the same as the rest of the
elements in the du chain. This was resulting in fcompare-debug failure
as check_new_reg_p was returning a different result with -g for the same
candidate register. We can instead obtain nregs from the du chain
itself.
2022-06-10 Surya Kumari Jangala <jskumari@linux.ibm.com>
gcc/
PR rtl-optimization/105041
* regrename.cc (check_new_reg_p): Use nregs value from du chain.
gcc/testsuite/
PR rtl-optimization/105041
* gcc.target/powerpc/pr105041.c: New test.
(cherry picked from commit
3e16b4359e86b36676ed01219e6deafa95f3c16b)
GCC Administrator [Thu, 14 Jul 2022 00:19:28 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Wed, 13 Jul 2022 00:19:15 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Tue, 12 Jul 2022 00:19:05 +0000 (00:19 +0000)]
Daily bump.
Martin Jambor [Mon, 11 Jul 2022 16:43:23 +0000 (18:43 +0200)]
tree-sra: Fix union handling in build_reconstructed_reference
As the testcase in PR 105860 shows, the code that tries to re-use the
handled_component chains in SRA can be horribly confused by unions,
where it thinks it has found a compatible structure under which it can
chain the references, but in fact it found the type it was looking
for elsewhere in a union and generated a write to a completely wrong
part of an aggregate.
I don't remember whether the plan was to support unions at all in
build_reconstructed_reference but it can work, to an extent, if we
make sure that we start the search only outside the outermost union,
which is what the patch does (and the extra testcase verifies).
Additionally, this commit also contains sqashed in it a backport of
b984b84cbe4bf026edef2ba37685f3958a1dc1cf which fixes the testcase
gcc.dg/tree-ssa/alias-access-path-13.c for many 32-bit targets.
gcc/ChangeLog:
2022-07-01 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/105860
* tree-sra.cc (build_reconstructed_reference): Start expr
traversal only just below the outermost union.
gcc/testsuite/ChangeLog:
2022-07-01 Martin Jambor <mjambor@suse.cz>
PR tree-optimization/105860
* gcc.dg/tree-ssa/alias-access-path-13.c: New test.
* gcc.dg/tree-ssa/pr105860.c: Likewise.
(cherry picked from commit
b110e5283e368b5377e04766e4ff82cd52634208)
GCC Administrator [Mon, 11 Jul 2022 00:19:21 +0000 (00:19 +0000)]
Daily bump.
Xi Ruoyao [Fri, 8 Jul 2022 13:09:25 +0000 (21:09 +0800)]
loongarch: fix mulsidi3_64bit instruction
(mult (sign_extend:DI rj:SI) (sign_extend:DI rk:SI)) should be
"mulw.d.w", not "mul.d".
gcc/ChangeLog:
* config/loongarch/loongarch.md (mulsidi3_64bit): Use mulw.d.w
instead of mul.d.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/mulw_d_w.c: New test.
* gcc.c-torture/execute/mul-sext.c: New test.
(cherry picked from commit
1fa42d62140b56589771eb3d46f89c810bfc8e0a)
GCC Administrator [Sun, 10 Jul 2022 00:19:06 +0000 (00:19 +0000)]
Daily bump.
Roger Sayle [Sat, 9 Jul 2022 11:38:12 +0000 (12:38 +0100)]
PR target/105930: Split *xordi3_doubleword after reload on x86.
This is a backport of the fix for PR target/105930 from mainline to the
gcc12 release branch.
2022-07-09 Roger Sayle <roger@nextmovesoftware.com>
Uroš Bizjak <ubizjak@gmail.com>
gcc/ChangeLog
PR target/105930
* config/i386/i386.md (*<any_or>di3_doubleword): Split after
reload. Use rtx_equal_p to avoid creating memory-to-memory moves,
and emit NOTE_INSN_DELETED if operand[2] is zero (i.e. with -O0).
GCC Administrator [Sat, 9 Jul 2022 00:19:34 +0000 (00:19 +0000)]
Daily bump.
Lulu Cheng [Thu, 7 Jul 2022 10:07:28 +0000 (18:07 +0800)]
LoongArch: Modify fp_sp_offset and gp_sp_offset's calculation method when frame->mask or frame->fmask is zero.
Under the LA architecture, when the stack is dropped too far, the process
of dropping the stack is divided into two steps.
step1: After dropping the stack, save callee saved registers on the stack.
step2: The rest of it.
The stack drop operation is optimized when frame->total_size minus
frame->sp_fp_offset is an integer multiple of 4096, can reduce the number
of instructions required to drop the stack. However, this optimization is
not effective because of the original calculation method
The following case:
int main()
{
char buf[1024 * 12];
printf ("%p\n", buf);
return 0;
}
As you can see from the generated assembler, the old GCC has two more
instructions than the new GCC, lines 14 and line 24.
new old
10 main: | 11 main:
11 addi.d $r3,$r3,-16 | 12 lu12i.w $r13,-12288>>12
12 lu12i.w $r13,-12288>>12 | 13 addi.d $r3,$r3,-2032
13 lu12i.w $r5,-12288>>12 | 14 ori $r13,$r13,2016
14 lu12i.w $r12,12288>>12 | 15 lu12i.w $r5,-12288>>12
15 st.d $r1,$r3,8 | 16 lu12i.w $r12,12288>>12
16 add.d $r12,$r12,$r5 | 17 st.d $r1,$r3,2024
17 add.d $r3,$r3,$r13 | 18 add.d $r12,$r12,$r5
18 add.d $r5,$r12,$r3 | 19 add.d $r3,$r3,$r13
19 la.local $r4,.LC0 | 20 add.d $r5,$r12,$r3
20 bl %plt(printf) | 21 la.local $r4,.LC0
21 lu12i.w $r13,12288>>12 | 22 bl %plt(printf)
22 add.d $r3,$r3,$r13 | 23 lu12i.w $r13,8192>>12
23 ld.d $r1,$r3,8 | 24 ori $r13,$r13,2080
24 or $r4,$r0,$r0 | 25 add.d $r3,$r3,$r13
25 addi.d $r3,$r3,16 | 26 ld.d $r1,$r3,2024
26 jr $r1 | 27 or $r4,$r0,$r0
| 28 addi.d $r3,$r3,2032
| 29 jr $r1
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_compute_frame_info):
Modify fp_sp_offset and gp_sp_offset's calculation method,
when frame->mask or frame->fmask is zero, don't minus UNITS_PER_WORD
or UNITS_PER_FP_REG.
gcc/testsuite/ChangeLog:
* gcc.target/loongarch/prolog-opt.c: New test.
(cherry picked from commit
aa8fd7f65683ef9c3b6d2e9306bea2f28b5cadf7)
GCC Administrator [Fri, 8 Jul 2022 00:19:15 +0000 (00:19 +0000)]
Daily bump.
Jonathan Wakely [Fri, 1 Jul 2022 21:23:43 +0000 (22:23 +0100)]
libstdc++: Add missing prerequisite to generated header [PR106162]
The ${host_builddir}/largefile-config.h header can't be written until
its parent directory has been created, so it needs to have the creation
of that directory as a prerequisite.
libstdc++-v3/ChangeLog:
PR libstdc++/106162
* include/Makefile.am (largefile-config.h): Add
stamp-${host_alias} prerequisite.
* include/Makefile.in: Regenerate.
(cherry picked from commit
8a6ee426c2be3bd4359520e02c00ec60cac2fece)
Jonathan Wakely [Thu, 23 Jun 2022 13:25:49 +0000 (14:25 +0100)]
libstdc++: Properly remove temporary directories in filesystem tests
Although these tests use filesystem::remove_all to clean up, that fails
because it uses recursive_directory_iterator which is intentionally
bodged by the custom readdir defined in the test.
Just use POSIX rmdir to clean up. We don't need to use _rmdir or _wrmdir
for Windows, because we'll never reach test02() on targets where the
custom readdir doesn't interpose the one from libc.
libstdc++-v3/ChangeLog:
* testsuite/27_io/filesystem/iterators/error_reporting.cc: Use
rmdir to remove directories.
* testsuite/experimental/filesystem/iterators/error_reporting.cc:
Likewise.
(cherry picked from commit
7c1c7e120cca183671b11ba68a6350c8800823c0)
GCC Administrator [Thu, 7 Jul 2022 00:19:11 +0000 (00:19 +0000)]
Daily bump.
Jonathan Wakely [Wed, 29 Jun 2022 22:41:46 +0000 (23:41 +0100)]
c-family: Add <time.h> names to diagnostics for known headers
gcc/c-family/ChangeLog:
* known-headers.cc (get_stdlib_header_for_name): Add <time.h>
names.
gcc/testsuite/ChangeLog:
* g++.dg/spellcheck-stdlib.C: Check <ctime> types and functions.
(cherry picked from commit
d489ec082ea214109ff54071410f8cd00344e654)
Marek Polacek [Tue, 5 Jul 2022 18:22:26 +0000 (14:22 -0400)]
c-family: Prevent -Wformat warnings with u8 strings [PR105626]
The <https://gcc.gnu.org/pipermail/gcc/2022-May/238679.html> thread
seems to have concluded that -Wformat shouldn't warn about
printf((const char*) u8"test %d\n", 1);
saying "format string is not an array of type 'char'". This code
is not an aliasing violation, and there are no I/O functions for u8
strings, so the const char * cast is OK and shouldn't be disregarded.
PR c++/105626
gcc/c-family/ChangeLog:
* c-format.cc (check_format_arg): Don't emit -Wformat warnings with
u8 strings.
gcc/testsuite/ChangeLog:
* g++.dg/warn/Wformat-char8_t-1.C: New test.
(cherry picked from commit
543828e79bfa63ef26b11a2c9ea81fd7905f33aa)
GCC Administrator [Wed, 6 Jul 2022 00:19:23 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Tue, 5 Jul 2022 00:19:34 +0000 (00:19 +0000)]
Daily bump.
Andrew MacLeod [Mon, 4 Jul 2022 15:21:34 +0000 (11:21 -0400)]
Don't use gori depedencies to optimize.
The routine fold_using_range::relation_fold_and_or needs to verify that both
operands of 2 stmts are the same, and uses GORIs dependency cache for this.
This cache cannot be counted on to reflect the current contents of a
stmt, expecially in the presence of an IL changing pass. Instead, look at the
statement operands.
PR tree-optimization/106114
gcc/
* gimple-range-fold.cc (fold_using_range::relation_fold_and_or): Check
statement operands instead of GORI cache.
gcc/testsuite/
* gcc.dg/pr106114.c: New.
Iain Buclaw [Wed, 29 Jun 2022 19:52:39 +0000 (21:52 +0200)]
d: Fix error: aggregate value used where floating point was expected
Casting from vector to static array is permitted, and the frontend
generates a reinterpret cast, but casting back the other way resulted in
an error. This has been fixed to be properly handled in the code
generation pass of VectorExp, and the conversion for lvalue and rvalue
handling done in convert_expr and convert_for_rvalue respectively.
PR d/106139
gcc/d/ChangeLog:
* d-convert.cc (convert_expr): Handle casting from array to vector.
(convert_for_rvalue): Rewrite vector to array casts of the same
element type into a constructor.
(convert_for_assignment): Return calling convert_for_rvalue.
* expr.cc (ExprVisitor::visit (VectorExp *)): Handle generating a
vector expression from a static array.
* toir.cc (IRVisitor::visit (ReturnStatement *)): Call
convert_for_rvalue on return value.
gcc/testsuite/ChangeLog:
* gdc.dg/pr106139a.d: New test.
* gdc.dg/pr106139b.d: New test.
* gdc.dg/pr106139c.d: New test.
* gdc.dg/pr106139d.d: New test.
(cherry picked from commit
329bef49da30158d30fed1106002bb71674776bd)
Roger Sayle [Mon, 4 Jul 2022 12:58:37 +0000 (13:58 +0100)]
PR target/105991: Recognize PLUS and XOR forms of rldimi in rs6000.md.
This patch addresses PR target/105991 where a change to prefer representing
shifts and adds at the tree-level as multiplications, causes problems for
the rldimi patterns in the powerpc backend. The issue is that rs6000.md
models this pattern using IOR, and some variants that have the equivalent
PLUS or XOR in the RTL fail to match some *rotl<mode>4_insert patterns.
This is fixed in this patch by adding a define_insn_and_split to locally
canonicalize the PLUS and XOR forms to the backend's preferred IOR form.
Backported from master.
2022-07-04 Roger Sayle <roger@nextmovesoftware.com>
Marek Polacek <polacek@redhat.com>
Segher Boessenkool <segher@kernel.crashing.org>
Kewen Lin <linkw@linux.ibm.com>
gcc/ChangeLog
PR target/105991
* config/rs6000/rs6000.md (rotl<mode>3_insert_3): Check that
exact_log2 doesn't return -1 (or zero).
(plus_xor): New code iterator.
(*rotl<mode>3_insert_3_<code>): New define_insn_and_split.
gcc/testsuite/ChangeLog
PR target/105991
* gcc.target/powerpc/pr105991.c: New test case.
Xi Ruoyao [Sat, 2 Jul 2022 08:16:44 +0000 (16:16 +0800)]
loongarch: use -mno-check-zero-division as the default for optimized code
Integer division by zero is undefined behavior anyway, and there are
already many platforms where neither the GCC port and the hardware do
anything to trap on division by zero. So any portable program shall not
rely on SIGFPE on division by zero, in both theory and practice. As the
result, there is no real reason to cost two additional instructions just
for the trap on division by zero with a new ISA.
One remaining reason to trap on division by zero may be debugging,
especially while -fsanitize=integer-divide-by-zero is not implemented
for LoongArch yet. To make debugging easier, keep -mcheck-zero-division
as the default for -O0 and -Og, but use -mno-check-zero-division as the
default for all other optimization levels.
Backport this behavior change for 12.2, so 12.1 will be the only release
with a different default.
Co-authored-by: Lulu Cheng <chenglulu@loongson.cn>
gcc/ChangeLog:
* config/loongarch/loongarch.cc (loongarch_check_zero_div_p):
New static function.
(loongarch_idiv_insns): Use loongarch_check_zero_div_p instead
of TARGET_CHECK_ZERO_DIV.
(loongarch_output_division): Likewise.
* common/config/loongarch/loongarch-common.cc
(TARGET_DEFAULT_TARGET_FLAGS): Remove unneeded hook.
* doc/invoke.texi: Update to match the new behavior.
gcc/testsuite/ChangeLog:
* gcc.c-torture/execute/
20101011-1.c (dg-additional-options):
add -mcheck-zero-division for LoongArch targets.
(cherry picked from commit
f150dc1bd11802b70277f0fa209f2d23695a1095)
GCC Administrator [Mon, 4 Jul 2022 00:19:07 +0000 (00:19 +0000)]
Daily bump.
Harald Anlauf [Wed, 29 Jun 2022 19:36:17 +0000 (21:36 +0200)]
Fortran: error recovery on invalid CLASS(), PARAMETER declarations [PR105243]
gcc/fortran/ChangeLog:
PR fortran/103137
PR fortran/103138
PR fortran/103693
PR fortran/105243
* decl.cc (gfc_match_data_decl): Reject CLASS entity declaration
when it is given the PARAMETER attribute.
gcc/testsuite/ChangeLog:
PR fortran/103137
PR fortran/103138
PR fortran/103693
PR fortran/105243
* gfortran.dg/class_58.f90: Fix test.
* gfortran.dg/class_73.f90: New test.
Co-authored-by: Steven G. Kargl <kargl@gcc.gnu.org>
(cherry picked from commit
4c233cabbe388a6b8957c1507e129090e9267ceb)
Harald Anlauf [Tue, 28 Jun 2022 20:29:28 +0000 (22:29 +0200)]
Fortran: improve error recovery for EXTENDS_TYPE_OF() [PR106121]
gcc/fortran/ChangeLog:
PR fortran/106121
* simplify.cc (gfc_simplify_extends_type_of): Do not attempt to
simplify when one of the arguments is a CLASS variable that was
not properly declared.
gcc/testsuite/ChangeLog:
PR fortran/106121
* gfortran.dg/extends_type_of_4.f90: New test.
Co-authored-by: Steven G. Kargl <kargl@gcc.gnu.org>
(cherry picked from commit
b8f284d3673004dffae714b56ed663467c2a52a7)
Roger Sayle [Sun, 3 Jul 2022 13:01:17 +0000 (14:01 +0100)]
PR target/106122: Don't update %esp via the stack with -Oz on x86.
When optimizing for size with -Oz, setting a register can be minimized by
pushing an immediate value to the stack and popping it to the destination.
Alas the one general register that shouldn't be updated via the stack is
the stack pointer itself, where "pop %esp" can't be represented in GCC's
RTL ("use of a register mentioned in pre_inc, pre_dec, post_inc or
post_dec is not permitted within the same instruction"). This patch
fixes PR target/106122 by explicitly checking for SP_REG in the
problematic peephole2.
2022-07-O3 Roger Sayle <roger@nextmovesoftware.com>
gcc/ChangeLog
PR target/106122
* config/i386/i386.md (peephole2): Avoid generating pop %esp
when optimizing for size.
gcc/testsuite/ChangeLog
PR target/106122
* gcc.target/i386/pr106122.c: New test case.
GCC Administrator [Sun, 3 Jul 2022 00:19:11 +0000 (00:19 +0000)]
Daily bump.
Sergei Trofimovich [Mon, 27 Jun 2022 22:42:44 +0000 (23:42 +0100)]
jit: avoid calloc() poisoning on musl [PR106102]
On musl <pthread.h> uses calloc() (via <sched.h>). jit/ includes
it directly and exposes use of poisoned calloc():
/build/build/./prev-gcc/xg++ ... ../../gcc-13-
20220626/gcc/jit/jit-playback.cc
make[3]: *** [Makefile:1143: jit/libgccjit.o] Error 1
make[3]: *** Waiting for unfinished jobs....
In file included from /<<NIX>>/musl-1.2.3-dev/include/pthread.h:30,
from ../../gcc-13-
20220626/gcc/jit/jit-playback.cc:44:
/<<NIX>>/musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"
84 | void *calloc(size_t, size_t);
| ^
/<<NIX>>/musl-1.2.3-dev/include/sched.h:124:36: error: attempt to use poisoned "calloc"
124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
| ^
The change moves <pthread.h> inclusion to "system.h" under new
INCLUDE_PTHREAD_H guard and uses this mechanism in libgccjit.
gcc/
PR c++/106102
* system.h: Introduce INCLUDE_PTHREAD_H macros to include <pthread.h>.
gcc/jit/
PR c++/106102
* jit-playback.cc: Include <pthread.h> via "system.h" to avoid calloc()
poisoning.
* jit-recording.cc: Ditto.
* libgccjit.cc: Ditto.
(cherry picked from commit
49d508065bdd36fb1a9b6aad9666b1edb5e06474)
Sergei Trofimovich [Mon, 27 Jun 2022 12:27:24 +0000 (13:27 +0100)]
c++: avoid <memory> poisoning on musl [PR106102]
On musl <pthread.h> uses calloc() (via <sched.h>). <memory> includes
it indirectly and exposes use of poisoned calloc() when module code
is built:
/build/build/./prev-gcc/xg++ ... ../../gcc-13-
20220626/gcc/cp/mapper-resolver.cc
In file included from /<<NIX>>/musl-1.2.3-dev/include/pthread.h:30,
from /build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/x86_64-unknown-linux-musl/bits/gthr-default.h:35,
....
from /build/build/prev-x86_64-unknown-linux-musl/libstdc++-v3/include/memory:77,
from ../../gcc-13-
20220626/gcc/../libcody/cody.hh:24,
from ../../gcc-13-
20220626/gcc/cp/../../c++tools/resolver.h:25,
from ../../gcc-13-
20220626/gcc/cp/../../c++tools/resolver.cc:23,
from ../../gcc-13-
20220626/gcc/cp/mapper-resolver.cc:32:
/<<NIX>>/musl-1.2.3-dev/include/sched.h:84:7: error: attempt to use poisoned "calloc"
84 | void *calloc(size_t, size_t);
| ^
/<<NIX>>/musl-1.2.3-dev/include/sched.h:124:36: error: attempt to use poisoned "calloc"
124 | #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
| ^
gcc/cp/
PR c++/106102
* mapper-client.cc: Include <memory> via "system.h".
* mapper-resolver.cc: Ditto.
* module.cc: Ditto.
libcc1/
PR c++/106102
* libcc1plugin.cc: Include <memory> via "system.h".
* libcp1plugin.cc: Ditto.
(cherry picked from commit
3b21c21f3f5726823e19728fdd1571a14aae0fb3)
GCC Administrator [Sat, 2 Jul 2022 00:19:15 +0000 (00:19 +0000)]
Daily bump.
Jason Merrill [Fri, 1 Jul 2022 15:02:54 +0000 (11:02 -0400)]
c++: simpler fix for PR106024
Actually, for release branches let's just avoid the lookup for the lambdas
that are the problematic case and only make the bigger change on trunk.
PR c++/106024
gcc/cp/ChangeLog:
* parser.cc (cp_parser_lookup_name): Limit previous change to
lambdas.
Vladimir Makarov [Sat, 28 May 2022 18:08:38 +0000 (12:08 -0600)]
Fix ICE on sh
gcc/
PR target/103722
* config/sh/sh.cc (sh_register_move_cost): Avoid cost "2" (which
is special) for various scenarios.
(cherry picked from commit
ce1580252ea57de23a595e9804ea87ed4353aa6a)
Jason Merrill [Wed, 11 May 2022 18:53:26 +0000 (14:53 -0400)]
c++: lambda template in requires [PR105541]
Since the patch for PR103408, the template parameters for the lambda in this
test have level 1 instead of 2, and we were treating null template args as 1
level of arguments, so tsubst_template_parms decided it had nothing to do.
Fixed by distinguishing between <> and no args at all, which is what we have
in our "substitution" in a requires-expression.
PR c++/105541
gcc/cp/ChangeLog:
* cp-tree.h (TMPL_ARGS_DEPTH): 0 for null args.
* parser.cc (cp_parser_enclosed_template_argument_list):
Use 0-length TREE_VEC for <>.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-requires1.C: New test.
Jason Merrill [Fri, 1 Jul 2022 04:37:10 +0000 (00:37 -0400)]
c++: tweak resolve_args change
I don't know why I used tf_error instead of complain here.
PR c++/105779
gcc/cp/ChangeLog:
* call.cc (resolve_args): Use complain.
Jason Merrill [Fri, 24 Jun 2022 03:14:35 +0000 (23:14 -0400)]
c++: dependent generic lambda template-id [PR106024]
We were wrongly looking up the generic lambda op() in a dependent scope, and
then trying to look up its instantiation at substitution time, but lambdas
aren't instantiated, so we crashed. The fix is to not look into dependent
class scopes.
But this created trouble with wrongly trying to use a template from the
enclosing scope when we aren't actually looking at a template-argument-list,
in template/lookup18.C, so let's avoid that.
PR c++/106024
gcc/cp/ChangeLog:
* parser.cc (missing_template_diag): Factor out...
(cp_parser_id_expression): ...from here.
(cp_parser_lookup_name): Don't look in dependent object_type.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-generic10.C: New test.
GCC Administrator [Fri, 1 Jul 2022 00:19:20 +0000 (00:19 +0000)]
Daily bump.
Harald Anlauf [Mon, 20 Jun 2022 18:59:55 +0000 (20:59 +0200)]
Fortran: handle explicit-shape specs with constant bounds [PR105954]
gcc/fortran/ChangeLog:
PR fortran/105954
* decl.cc (variable_decl): Adjust upper bounds for explicit-shape
specs with constant bound expressions to ensure non-negative
extents.
gcc/testsuite/ChangeLog:
PR fortran/105954
* gfortran.dg/pr105954.f90: New test.
(cherry picked from commit
a312407bd715647f7c11b67e0a52effc94d0f15d)
Harald Anlauf [Tue, 21 Jun 2022 21:20:18 +0000 (23:20 +0200)]
Fortran: fix simplification of INDEX(str1,str2) [PR105691]
gcc/fortran/ChangeLog:
PR fortran/105691
* simplify.cc (gfc_simplify_index): Replace old simplification
code by the equivalent of the runtime library implementation. Use
HOST_WIDE_INT instead of int for string index, length variables.
gcc/testsuite/ChangeLog:
PR fortran/105691
* gfortran.dg/index_6.f90: New test.
(cherry picked from commit
ff35dbc02092fbcd3d814fcd9fe8e871c3f741fd)
Harald Anlauf [Fri, 24 Jun 2022 20:21:39 +0000 (22:21 +0200)]
Fortran: fix checking of arguments to UNPACK when MASK is a variable [PR105813]
gcc/fortran/ChangeLog:
PR fortran/105813
* check.cc (gfc_check_unpack): Try to simplify MASK argument to
UNPACK so that checking of the VECTOR argument can work when MASK
is a variable.
gcc/testsuite/ChangeLog:
PR fortran/105813
* gfortran.dg/unpack_vector_1.f90: New test.
(cherry picked from commit
f21f17f95c0237f4f987a5fa9f1fa9c7e0db3c40)
GCC Administrator [Thu, 30 Jun 2022 00:19:11 +0000 (00:19 +0000)]
Daily bump.
Martin Liska [Wed, 29 Jun 2022 13:28:07 +0000 (15:28 +0200)]
libsanitizer: cherry-pick
791e0d1bc85d
791e0d1bc85d: [compiler-rt] Add NO_EXEC_STACK_DIRECTIVE on s390x
(cherry picked from commit
aa87b7541b4c11f59c521154513f844ea6b5c977)
Richard Biener [Wed, 11 May 2022 08:47:34 +0000 (10:47 +0200)]
bootstrap/105551 - restore nvptx build
The following makes sure to disable var-tracking if only
dwarf2-line debuginfo is present.
2022-05-11 Richard Biener <rguenther@suse.de>
PR bootstrap/105551
* opts.cc (finish_options): Also disable var-tracking if
!DWARF2_DEBUGGING_INFO.
(cherry picked from commit
e7d9fdf5e0ee4c34a880139254340b4165016289)
Lulu Cheng [Mon, 27 Jun 2022 08:26:25 +0000 (16:26 +0800)]
LoongArch: Remove undefined behavior from code [PR 106097]
C++2017 and previous standard description:
The value of E1 << E2 is E1 left-shifted E2 bit positions;
vacated bits are zero-filled. If E1 has an unsigned type,
the value of the result is E1×2E2, reduced modulo one more
than the maximum value representable inthe result type.
Otherwise, if E1 has a signed type and non-negative value,
and E1×2E2 is representablein the corresponding unsigned
type of the result type, then that value, converted to the
result type, is the resulting value; otherwise, the behavior
is undefined.
The value of E1 >> E2 is E1 right-shifted E2 bit positions.
If E1 has an unsigned type or if E1 has a signed type and
a non-negative value, the value of the result is the integral
part of the quotient of E1/2E2. If E1 has a signed type and
a negative value, the resulting value is implementation-defined.
gcc/ChangeLog:
PR target/106097
* config/loongarch/loongarch.cc (loongarch_build_integer):
Remove undefined behavior from code.
(cherry picked from commit
43653547e7c8da2cd861bceb4a3e4bd338787ced)
GCC Administrator [Wed, 29 Jun 2022 00:19:26 +0000 (00:19 +0000)]
Daily bump.
Jakub Jelinek [Tue, 21 Jun 2022 09:40:16 +0000 (11:40 +0200)]
ifcvt: Don't introduce trapping or faulting reads in noce_try_sign_mask [PR106032]
noce_try_sign_mask as documented will optimize
if (c < 0)
x = t;
else
x = 0;
into x = (c >> bitsm1) & t;
The optimization is done if either t is unconditional
(e.g. for
x = t;
if (c >= 0)
x = 0;
) or if it is cheap. We already check that t doesn't have side-effects,
but if t is conditional, we need to punt also if it may trap or fault,
as we make it unconditional.
I've briefly skimmed other noce_try* optimizations and didn't find one that
would suffer from the same problem.
2022-06-21 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/106032
* ifcvt.cc (noce_try_sign_mask): Punt if !t_unconditional, and
t may_trap_or_fault_p, even if it is cheap.
* gcc.c-torture/execute/pr106032.c: New test.
(cherry picked from commit
a0c30fe3b888f20215f3e040d21b62b603804ca9)
Jakub Jelinek [Tue, 21 Jun 2022 09:38:59 +0000 (11:38 +0200)]
expand: Fix up expand_cond_expr_using_cmove [PR106030]
If expand_cond_expr_using_cmove can't find a cmove optab for a particular
mode, it tries to promote the mode and perform the cmove in the promoted
mode.
The testcase in the patch ICEs on arm because in that case we pass temp which
has the promoted mode (SImode) as target to expand_operands where the
operands have the non-promoted mode (QImode).
Later on the function uses paradoxical subregs:
if (GET_MODE (op1) != mode)
op1 = gen_lowpart (mode, op1);
if (GET_MODE (op2) != mode)
op2 = gen_lowpart (mode, op2);
to change the operand modes.
The following patch fixes it by passing NULL_RTX as target if it has
promoted mode.
2022-06-21 Jakub Jelinek <jakub@redhat.com>
PR middle-end/106030
* expr.cc (expand_cond_expr_using_cmove): Pass NULL_RTX instead of
temp to expand_operands if mode has been promoted.
* gcc.c-torture/compile/pr106030.c: New test.
(cherry picked from commit
2df1df945fac85d7b3d084001414a66a2709d8fe)
Jakub Jelinek [Tue, 21 Jun 2022 15:51:08 +0000 (17:51 +0200)]
libgomp: Fix up target-31.c test [PR106045]
The i variable is used inside of the parallel in:
#pragma omp simd safelen(32) private (v)
for (i = 0; i < 64; i++)
{
v = 3 * i;
ll[i] = u1 + v * u2[0] + u2[1] + x + y[0] + y[1] + v + h[0] + u3[i];
}
where i is predetermined linear (so while inside of the body
it is safe, private per SIMD lane var) the final value is written to
the shared variable, and in:
for (i = 0; i < 64; i++)
if (ll[i] != u1 + 3 * i * u2[0] + u2[1] + x + y[0] + y[1] + 3 * i + 13 + 14 + i)
#pragma omp atomic write
err = 1;
which is a normal loop and so it isn't in any way privatized there.
So we have a data race, fixed by adding private (i) clause to the
parallel.
2022-06-21 Jakub Jelinek <jakub@redhat.com>
Paul Iannetta <piannetta@kalrayinc.com>
PR libgomp/106045
* testsuite/libgomp.c/target-31.c: Add private (i) clause.
(cherry picked from commit
85d613da341b76308edea48359a5dbc7061937c4)
Xi Ruoyao [Tue, 28 Jun 2022 08:00:14 +0000 (16:00 +0800)]
loongarch: exclude LARCH_PROLOGUE_TEMP from SIBCALL_REGS [PR 106096]
The epilogue may clobber LARCH_PROLOGUE_TEMP ($r13/$t1), so it cannot be
used for sibcalls.
gcc/ChangeLog:
PR target/106096
* config/loongarch/loongarch.h (REG_CLASS_CONTENTS): Exclude
$r13 from SIBCALL_REGS.
* config/loongarch/loongarch.cc (loongarch_regno_to_class):
Change $r13 to JIRL_REGS.
gcc/testsuite/ChangeLog:
PR target/106096
* g++.target/loongarch/loongarch.exp: New test support file.
* g++.target/loongarch/pr106096.C: New test.
(cherry picked from commit
020b7d98589bbc928b5a66b1ed56b42af8791355)
Martin Liska [Tue, 28 Jun 2022 08:34:56 +0000 (10:34 +0200)]
libgomp: fix typo in mold linker detection
libgomp/ChangeLog:
* acinclude.m4: Fix typo in mold linker detection.
* Makefile.in: Regenerate.
* configure: Regenerate.
(cherry picked from commit
6835baee7196eeb03f24f6e650c0d37cbb295647)
GCC Administrator [Tue, 28 Jun 2022 00:19:29 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Mon, 27 Jun 2022 00:19:05 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Sun, 26 Jun 2022 00:18:48 +0000 (00:18 +0000)]
Daily bump.
GCC Administrator [Sat, 25 Jun 2022 00:19:16 +0000 (00:19 +0000)]
Daily bump.
Iain Buclaw [Wed, 22 Jun 2022 17:11:20 +0000 (19:11 +0200)]
tilegx: Fix infinite loop in gen-mul-tables generator
Since around GCC 10, the condition `j < (INTMAX_MAX / 10)' will get
optimized into `j !=
922337203685477580', which will result in an
infinite loop for certain inputs of `j'.
Copy the condition already used by the -DTILEPRO generator code, which
doesn't fall into this trap.
gcc/ChangeLog:
* config/tilepro/gen-mul-tables.cc (tilegx_emit): Adjust loop
condition to avoid overflow.
(cherry picked from commit
c0ad48527c314a1e9354b7c26718b56ed4abc92c)
Patrick Palka [Thu, 23 Jun 2022 20:36:43 +0000 (16:36 -0400)]
c++: constexpr folding in unevaluated context [PR105931]
Changing the type of N from int to unsigned in decltype82.C (from
r13-986-g0ecb6b906f215e) reveals another spot where we perform constexpr
evaluation in an unevaluated context for sake of warnings, this time
from the call to shorten_compare in cp_build_binary_op, which calls
fold_for_warn.
We could (and probably should) suppress the shorten_compare warnings
when in an unevaluated context, but there's probably other callers of
fold_for_warn that are similarly affected. So this patch takes the
approach of directly suppressing fold_for_warn when in an unevaluated
context.
PR c++/105931
gcc/cp/ChangeLog:
* expr.cc (fold_for_warn): Don't fold when in an unevaluated
context.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/decltype82a.C: New test.
(cherry picked from commit
b00b95198e6720eb23a2618870d67800f6180fdd)
GCC Administrator [Fri, 24 Jun 2022 00:18:59 +0000 (00:18 +0000)]
Daily bump.
Jason Merrill [Thu, 23 Jun 2022 20:04:02 +0000 (16:04 -0400)]
c++: anon union designated init [PR105925]
This testcase was failing because CONSTRUCTOR_IS_DESIGNATED_INIT wasn't
getting set on the introduced CONSTRUCTOR for the anonymous union, and
build_aggr_conv uses that flag to decide whether to pay attention to the
indexes of the CONSTRUCTOR. So set the flag when we see a designator rather
than relying on copying it from another CONSTRUCTOR.
PR c++/105925
gcc/cp/ChangeLog:
* decl.cc (reshape_init_array_1): Set
CONSTRUCTOR_IS_DESIGNATED_INIT here.
(reshape_init_class): And here.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/desig26.C: New test.
Jason Merrill [Thu, 23 Jun 2022 03:50:23 +0000 (23:50 -0400)]
c++: -Waddress and value-dependent expr [PR105885]
We already suppress various warnings for code that would be tautological if
written directly, but not when it's the result of template substitution. It
seems we need to do this for -Waddress as well.
PR c++/105885
gcc/cp/ChangeLog:
* pt.cc (tsubst_copy_and_build): Also suppress -Waddress for
comparison of dependent operands.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/constexpr-if37.C: New test.
Martin Liska [Wed, 18 May 2022 13:07:53 +0000 (15:07 +0200)]
ipa-icf: skip variables with body_removed
Similarly to cgraph_nodes, it may happen that body_removed is set
during merging of symbols.
PR ipa/105600
gcc/ChangeLog:
* ipa-icf.cc (sem_item_optimizer::filter_removed_items):
Skip variables with body_removed.
(cherry picked from commit
31ce821a790caec8a2849dd67a9847e78a33d14c)
Siddhesh Poyarekar [Tue, 21 Jun 2022 06:45:07 +0000 (12:15 +0530)]
tree-object-size: Don't let error_mark_node escape for ADDR_EXPR [PR105736]
The addr_expr computation does not check for error_mark_node before
returning the size expression. This used to work in the constant case
because the conversion to uhwi would end up causing it to return
size_unknown, but that won't work for the dynamic case.
Modify the control flow to explicitly return size_unknown if the offset
computation returns an error_mark_node.
gcc/ChangeLog:
PR tree-optimization/105736
* tree-object-size.cc (addr_object_size): Return size_unknown
when object offset computation returns an error.
gcc/testsuite/ChangeLog:
PR tree-optimization/105736
* gcc.dg/builtin-dynamic-object-size-0.c (TV4): New struct.
(val3): New variable.
(test_pr105736): New test.
(main): Call it.
Signed-off-by: Siddhesh Poyarekar <siddhesh@gotplt.org>
(cherry picked from commit
70454c50b4592fe6876ecca13268264e395e058f)
Jason Merrill [Wed, 22 Jun 2022 22:19:11 +0000 (18:19 -0400)]
c++: dependence of baselink [PR105964]
helper<token>::c isn't dependent just because we haven't deduced its return
type yet. type_dependent_expression_p already knows how to deal with that
for bare FUNCTION_DECL, but needs to learn to look through a BASELINK.
PR c++/105964
gcc/cp/ChangeLog:
* pt.cc (type_dependent_expression_p): Look through BASELINK.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1z/nontype-auto21.C: New test.
Jason Merrill [Wed, 22 Jun 2022 18:57:21 +0000 (14:57 -0400)]
c++: class scope function lookup [PR105908]
In r12-1273 for PR91706, I removed the code in get_class_binding that
stripped BASELINK. This testcase demonstrates that we still need to strip
it in outer_binding before putting the overload set in IDENTIFIER_BINDING,
for compatibility with bindings added directly for declarations.
PR c++/105908
gcc/cp/ChangeLog:
* name-lookup.cc (outer_binding): Strip BASELINK.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/trailing16.C: New test.
Richard Sandiford [Wed, 15 Jun 2022 10:12:51 +0000 (11:12 +0100)]
aarch64: Revert bogus fix for PR105254
In
f2ebf2d98efe0ac2314b58cf474f44cb8ebd5244 I'd forced the
chosen unroll factor to be a factor of the VF, in order to
work around an exact_div ICE in PR105254. This was completely
bogus -- clearly I didn't look in enough detail at why we ended
up with an unrolled VF that wasn't a multiple of the UF.
Kewen has since fixed the bug properly for PR105940, so this
patch reverts my earlier attempt. Sorry for the stupidity.
gcc/
PR tree-optimization/105254
PR tree-optimization/105940
Revert:
* config/aarch64/aarch64.cc
(aarch64_vector_costs::determine_suggested_unroll_factor): Take a
loop_vec_info as argument. Restrict the unroll factor to values
that divide the VF.
(aarch64_vector_costs::finish_cost): Update call accordingly.
gcc/testsuite/
* gcc.target/aarch64/sve/cost_model_14.c: New test.
(cherry picked from commit
2636660b6f35423e0cfbf53bfad5c5fed6ae6471)
Kewen Lin [Tue, 14 Jun 2022 05:57:01 +0000 (00:57 -0500)]
vect: Move suggested_unroll_factor applying [PR105940]
As PR105940 shown, when rs6000 port tries to assign
m_suggested_unroll_factor by 4 or so, there will be ICE on:
exact_div (LOOP_VINFO_VECT_FACTOR (loop_vinfo),
loop_vinfo->suggested_unroll_factor);
In function vect_analyze_loop_2, the current place of
suggested_unroll_factor applying can't guarantee it's
applied for all cases. As the case shows, vectorizer
could retry with SLP forced off, the vf is reset by
saved_vectorization_factor which isn't applied with
suggested_unroll_factor before. It means it can end
up with one vf which neglects suggested_unroll_factor.
I think it's off design, we should move the applying
of suggested_unroll_factor after start_over.
PR tree-optimization/105940
gcc/ChangeLog:
* tree-vect-loop.cc (vect_analyze_loop_2): Move the place of
applying suggested_unroll_factor after start_over.
(cherry picked from commit
f907cf4c07cf51863dadbe90894e2ae3382bada5)
GCC Administrator [Thu, 23 Jun 2022 00:19:39 +0000 (00:19 +0000)]
Daily bump.
GCC Administrator [Wed, 22 Jun 2022 00:19:10 +0000 (00:19 +0000)]
Daily bump.
H.J. Lu [Tue, 14 Jun 2022 15:20:16 +0000 (08:20 -0700)]
i386: Disallow sibcall for calling ifunc functions with PIC register
Disallow siball when calling ifunc functions with PIC register so that
PIC register can be restored.
gcc/
PR target/105960
* config/i386/i386.cc (ix86_function_ok_for_sibcall): Return
false if PIC register is used when calling ifunc functions.
gcc/testsuite/
PR target/105960
* gcc.target/i386/pr105960.c: New test.
(cherry picked from commit
fe9765c0b97e6b4ce2cd226631d329fc05ba2aa5)
GCC Administrator [Tue, 21 Jun 2022 00:19:12 +0000 (00:19 +0000)]
Daily bump.
Uros Bizjak [Fri, 17 Jun 2022 15:19:44 +0000 (17:19 +0200)]
alpha: Introduce target specific store_data_bypass_p function [PR105209]
This patch introduces alpha-specific version of store_data_bypass_p that
ignores TRAP_IF that would result in assertion failure (and internal
compiler error) in the generic store_data_bypass_p function.
While at it, also remove ev4_ist_c reservation, store_data_bypass_p
can handle the patterns with multiple sets since some time ago.
2022-06-17 Uroš Bizjak <ubizjak@gmail.com>
gcc/ChangeLog:
PR target/105209
* config/alpha/alpha-protos.h (alpha_store_data_bypass_p): New.
* config/alpha/alpha.cc (alpha_store_data_bypass_p): New function.
(alpha_store_data_bypass_p_1): Ditto.
* config/alpha/ev4.md: Use alpha_store_data_bypass_p instead
of generic store_data_bypass_p.
(ev4_ist_c): Remove insn reservation.
gcc/testsuite/ChangeLog:
PR target/105209
* gcc.target/alpha/pr105209.c: New test.
(cherry picked from commit
cc378e655740e93743e7f43e14faaff707aef6c1)
Uros Bizjak [Fri, 17 Jun 2022 15:01:31 +0000 (17:01 +0200)]
i386: Fix assert in ix86_function_arg [PR105970]
The mode of pointer argument should equal ptr_mode, not Pmode.
2022-06-17 Uroš Bizjak <ubizjak@gmail.com>
gcc/ChangeLog:
PR target/105970
* config/i386/i386.cc (ix86_function_arg): Assert that
the mode of pointer argumet is equal to ptr_mode, not Pmode.
gcc/testsuite/ChangeLog:
PR target/105970
* gcc.target/i386/pr105970.c: New test.
(cherry picked from commit
1f8278bfcfc7f7157bf2b405471e67dd5097636b)
GCC Administrator [Mon, 20 Jun 2022 00:18:49 +0000 (00:18 +0000)]
Daily bump.
Jakub Jelinek [Sat, 18 Jun 2022 09:07:13 +0000 (11:07 +0200)]
varasm: Fix up ICE in narrowing_initializer_constant_valid_p [PR105998]
The following testcase ICEs because there is NON_LVALUE_EXPR (location
wrapper) around a VAR_DECL and has TYPE_MODE V2SImode and
SCALAR_INT_TYPE_MODE on that ICEs. Or for -m32 -march=i386 TYPE_MODE
is DImode, but SCALAR_INT_TYPE_MODE still uses the raw V2SImode and ICEs
too.
2022-06-18 Jakub Jelinek <jakub@redhat.com>
PR middle-end/105998
* varasm.cc (narrowing_initializer_constant_valid_p): Check
SCALAR_INT_MODE_P instead of INTEGRAL_MODE_P, also break on
! INTEGRAL_TYPE_P and do the same check also on op{0,1}'s type.
* c-c++-common/pr105998.c: New test.
(cherry picked from commit
ef662120177d39af5f88ffc622d90bb6ae0ca1d3)
Jakub Jelinek [Fri, 17 Jun 2022 15:40:49 +0000 (17:40 +0200)]
c++: Use fold_non_dependent_expr rather than maybe_constant_value in __builtin_shufflevector handling [PR106001]
In this case the STATIC_CAST_EXPR expressions in the call aren't
type nor value dependent, but maybe_constant_value still ICEs on those
when processing_template_decl. Calling fold_non_dependent_expr on it
instead fixes the ICE and folds them to INTEGER_CSTs.
2022-06-17 Jakub Jelinek <jakub@redhat.com>
PR c++/106001
* typeck.cc (build_x_shufflevector): Use fold_non_dependent_expr
instead of maybe_constant_value.
* g++.dg/ext/builtin-shufflevector-4.C: New test.
(cherry picked from commit
a284fadcce8ef443cc3cc047a8017745efb51758)
Jakub Jelinek [Thu, 16 Jun 2022 08:58:58 +0000 (10:58 +0200)]
expand: Fix up IFN_ATOMIC_{BIT*,*CMP_0} expansion [PR105951]
Both IFN_ATOMIC_BIT_TEST_AND_* and IFN_ATOMIC_*_FETCH_CMP_0 ifns
are matched if their corresponding optab is implemented for the particular
mode. The fact that those optabs are implemented doesn't guarantee
they will succeed though, they can just FAIL in their expansion.
The expansion in that case uses expand_atomic_fetch_op as fallback, but
as has been reported and and can be reproduced on the testcases,
even those can fail and we didn't have any fallback after that.
For IFN_ATOMIC_BIT_TEST_AND_* we actually have such calls. One is
done whenever we lost lhs of the ifn at some point in between matching
it in tree-ssa-ccp.cc and expansion. The following patch for that case
just falls through and expands as if there was a lhs, creates a temporary
for it. For the other expand_atomic_fetch_op call in the same expander
and for the only expand_atomic_fetch_op call in the other, this falls
back the hard way, by constructing a CALL_EXPR to the call from which
the ifn has been matched and expanding that. Either it is lucky and manages
to expand inline, or it emits a libatomic API call.
So that we don't have to rediscover which builtin function to call in the
fallback, we record at tree-ssa-ccp.cc time gimple_call_fn (call) in
an extra argument to the ifn.
2022-06-16 Jakub Jelinek <jakub@redhat.com>
PR middle-end/105951
* tree-ssa-ccp.cc (optimize_atomic_bit_test_and,
optimize_atomic_op_fetch_cmp_0): Remember gimple_call_fn (call)
as last argument to the internal functions.
* builtins.cc (expand_ifn_atomic_bit_test_and): Adjust for the
extra call argument to ifns. If expand_atomic_fetch_op fails for the
lhs == NULL_TREE case, fall through into the optab code with
gen_reg_rtx (mode) as target. If second expand_atomic_fetch_op
fails, construct a CALL_EXPR and expand that.
(expand_ifn_atomic_op_fetch_cmp_0): Adjust for the extra call argument
to ifns. If expand_atomic_fetch_op fails, construct a CALL_EXPR and
expand that.
* gcc.target/i386/pr105951-1.c: New test.
* gcc.target/i386/pr105951-2.c: New test.
(cherry picked from commit
6a27c430468cb85454b19cef881a1422580657ff)
Jan Hubicka [Tue, 14 Jun 2022 12:05:53 +0000 (14:05 +0200)]
Fix ipa-cp wrt volatile loads
Check for volatile flag to ipa_load_from_parm_agg.
gcc/ChangeLog:
2022-06-10 Jan Hubicka <hubicka@ucw.cz>
PR ipa/105739
* ipa-prop.cc (ipa_load_from_parm_agg): Punt on volatile loads.
gcc/testsuite/ChangeLog:
2022-06-10 Jan Hubicka <hubicka@ucw.cz>
* gcc.dg/ipa/pr105739.c: New test.
(cherry picked from commit
8f6c317b3a16350698f3c9e0accb43a9b4acb4ae)
Jakub Jelinek [Thu, 9 Jun 2022 15:42:31 +0000 (17:42 +0200)]
c++: Fix up ICE on __builtin_shufflevector constexpr evaluation [PR105871]
As the following testcase shows, BIT_FIELD_REF result doesn't have to have
just integral type, it can also have vector type. And in that case
cxx_eval_bit_field_ref just ICEs on it because it is unprepared for that
case, creates the initial value with build_int_cst (sure, that one could be
easily replaced with build_zero_cst) and then expects it can through shifts,
ands and ors come up with the final value, but that doesn't work for
vectors.
We already call fold_ternary if whole is a VECTOR_CST, this patch does the
same if the result doesn't have integral type. And, there is no guarantee
fold_ternary will succeed and the callers certainly don't expect NULL
being returned, so it also diagnoses those as non-constant and returns
original t in that case.
2022-06-09 Jakub Jelinek <jakub@redhat.com>
PR c++/105871
* constexpr.cc (cxx_eval_bit_field_ref): For BIT_FIELD_REF with
non-integral result type use fold_ternary too like for BIT_FIELD_REFs
from VECTOR_CST. If fold_ternary returns NULL, diagnose non-constant
expression, set *non_constant_p and return t, instead of returning
NULL.
* g++.dg/pr105871.C: New test.
(cherry picked from commit
4c334e0e4ff05d3a7ca9ebb832428c446cd0ae8d)
GCC Administrator [Sun, 19 Jun 2022 00:18:54 +0000 (00:18 +0000)]
Daily bump.
GCC Administrator [Sat, 18 Jun 2022 00:18:44 +0000 (00:18 +0000)]
Daily bump.
GCC Administrator [Fri, 17 Jun 2022 12:17:57 +0000 (12:17 +0000)]
Daily bump.
Richard Earnshaw [Wed, 15 Jun 2022 15:07:20 +0000 (16:07 +0100)]
arm: big-endian issue in gen_cpymem_ldrd_strd [PR105981]
The code in gen_cpymem_ldrd_strd has been incorrect for big-endian
since r230663. The problem is that we use gen_lowpart, etc. to split
the 64-bit quantity, but fail to account for the fact that these
routines are really dealing with 64-bit /values/ and in big-endian the
ordering of the sub-registers changes.
To fix this, I've renamed the conceptually misnamed low_reg and hi_reg
as first_reg and second_reg, and then used different logic for
big-endian targets to initialize these values. This makes the logic
clearer than trying to think about high bits and low bits.
gcc/ChangeLog:
PR target/105981
* config/arm/arm.cc (gen_cpymem_ldrd_strd): Rename low_reg and hi_reg
to first_reg and second_reg respectively. Initialize them correctly
when generating big-endian code.
(cherry picked from commit
8aaa948059a8b5f0a62ad010d0aa6346b7ac9cd3)
GCC Administrator [Thu, 16 Jun 2022 00:19:13 +0000 (00:19 +0000)]
Daily bump.
Simon Wright [Sun, 12 Jun 2022 16:01:22 +0000 (17:01 +0100)]
Darwin: Truncate kernel-provided version to OS major for Darwin >= 20.
In common with system tools, GCC uses a version obtained from the kernel as
the prevailing macOS target, when that is not overridden by command line or
environment versions (i.e. mmacosx-version-min=, MACOSX_DEPLOYMENT_TARGET).
Presently, GCC assumes that if the OS version is >= 20, the value used should
include both major and minium version identifiers. However the system tools
(for those versions) truncate the value to the major version - this leads to
link errors when combining objects built with clang and GCC for example:
ld: warning: object file (null.o) was built for newer macOS version (12.2)
than being linked (12.0)
The change here truncates the values GCC uses to the major version.
gcc/ChangeLog:
PR target/104871
* config/darwin-driver.cc (darwin_find_version_from_kernel): If the OS
version is darwin20 (macOS 11) or greater, truncate the version to the
major number.
(cherry picked from commit
add1adaa17a294ea25918ffb4fdd40f115362632)
Mark Mentovai [Fri, 10 Jun 2022 14:56:42 +0000 (15:56 +0100)]
Darwin: Future-proof -mmacosx-version-min
f18cbc1ee1f4 (2021-12-18) updated various parts of gcc to not impose a
Darwin or macOS version maximum of the current known release. Different
parts of gcc accept, variously, Darwin version numbers matching
darwin2*, and macOS major version numbers up to 99. The current released
version is Darwin 21 and macOS 12, with Darwin 22 and macOS 13 expected
for public release later this year. With one major OS release per year,
this strategy is expected to provide another 8 years of headroom.
However,
f18cbc1ee1f4 missed config/darwin-c.c (now .cc), which
continued to impose a maximum of macOS 12 on the -mmacosx-version-min
compiler driver argument. This was last updated from 11 to 12 in
11b967577483 (2021-10-27), but kicking the can down the road one year at
a time is not a viable strategy, and is not in line with the more recent
technique from
f18cbc1ee1f4.
Prior to
556ab5125912 (2020-11-06), config/darwin-c.c did not impose a
maximum that needed annual maintenance, as at that point, all macOS
releases had used a major version of 10. The stricter approach imposed
since then was valuable for a time until the particulars of the new
versioning scheme were established and understood, but now that they
are, it's prudent to restore a more permissive approach.
gcc/ChangeLog:
* config/darwin-c.cc: Make -mmacosx-version-min more future-proof.
Signed-off-by: Mark Mentovai <mark@mentovai.com>
(cherry picked from commit
6725f186cb70d48338f69456864bf469a12ee5be)
Iain Sandoe [Sun, 29 May 2022 15:14:32 +0000 (16:14 +0100)]
Darwin: Fix empty g++ command lines [PR105599].
An empty g++ command line should produce a diagnostic that there are no
inputs. The PR is that currently Darwin produces a dignostic about missing
link items instead - this is because (errnoeously), for this driver, we are
creating a link job for empty command lines.
The problem occurs in four stages:
The g++ driver appends -shared-libgcc to the command line.
The Darwin driver_init code in the backend does not see this (it sees an
empty command line).
When the back end driver code driver sees an empty command line, it does not
add any supplementary flags (e.g. asm-macosx-version-min) - precisely to
avoid anything being claimed as an input_file and therefore triggering a link
line.
Since we do not have a value for asm-macosx-version-min when processing the
driver specs, we unconditionally inject 'multiply_defined suppress' which is
used with shared libgcc (but only intended on very old Darwin). This then
causes the generation of a link job.
The solution, for the present, is to move version-specific link params to the
LINK_SPEC so that they are only processed when a link job has already been
decided.
Signed-off-by: Iain Sandoe <iain@sandoe.co.uk>
PR target/105599
gcc/ChangeLog:
* config/darwin.h: Move versions-specific handling of multiply_defined
from SUBTARGET_DRIVER_SELF_SPECS to LINK_SPEC.
(cherry picked from commit
794737976b9a6418eab817f143bb4eb2d0c834d2)
Iain Buclaw [Wed, 15 Jun 2022 11:20:15 +0000 (13:20 +0200)]
d: Set TYPE_ARTIFICIAL on internal TypeInfo types
Prevents them from triggering warnings when compiling with `-Wpadded'.
gcc/d/ChangeLog:
* typeinfo.cc (make_internal_typeinfo): Set TYPE_ARTIFICIAL.
gcc/testsuite/ChangeLog:
* gdc.dg/Wpadded.d: New test.
(cherry picked from commit
57b2adae536a6399ed7d2c881b1bc0d4b88e936a)
liuhongt [Tue, 14 Jun 2022 08:27:04 +0000 (16:27 +0800)]
Fix ICE in extract_insn, at recog.cc:2791
(In reply to Uroš Bizjak from comment #1)
> Instruction does not accept memory operand for operand 3:
>
> (define_insn_and_split
> "*<sse4_1>_blendv<ssefltmodesuffix><avxsizesuffix>_ltint"
> [(set (match_operand:<ssebytemode> 0 "register_operand" "=Yr,*x,x")
> (unspec:<ssebytemode>
> [(match_operand:<ssebytemode> 1 "register_operand" "0,0,x")
> (match_operand:<ssebytemode> 2 "vector_operand" "YrBm,*xBm,xm")
> (subreg:<ssebytemode>
> (lt:VI48_AVX
> (match_operand:VI48_AVX 3 "register_operand" "Yz,Yz,x")
> (match_operand:VI48_AVX 4 "const0_operand")) 0)]
> UNSPEC_BLENDV))]
>
> The problematic insn is:
>
> (define_insn_and_split "*avx_cmp<mode>3_ltint_not"
> [(set (match_operand:VI48_AVX 0 "register_operand")
> (vec_merge:VI48_AVX
> (match_operand:VI48_AVX 1 "vector_operand")
> (match_operand:VI48_AVX 2 "vector_operand")
> (unspec:<avx512fmaskmode>
> [(subreg:VI48_AVX
> (not:<ssebytemode>
> (match_operand:<ssebytemode> 3 "vector_operand")) 0)
> (match_operand:VI48_AVX 4 "const0_operand")
> (match_operand:SI 5 "const_0_to_7_operand")]
> UNSPEC_PCMP)))]
>
> which gets split to the above pattern.
>
> In the preparation statements we have:
>
> if (!MEM_P (operands[3]))
> operands[3] = force_reg (<ssebytemode>mode, operands[3]);
> operands[3] = lowpart_subreg (<MODE>mode, operands[3], <ssebytemode>mode);
>
> Which won't fly when operand 3 is memory operand...
>
gcc/ChangeLog:
PR target/105953
* config/i386/sse.md (*avx_cmp<mode>3_ltint_not): Force_reg
operands[3].
gcc/testsuite/ChangeLog:
* g++.target/i386/pr105953.C: New test.
GCC Administrator [Wed, 15 Jun 2022 00:19:12 +0000 (00:19 +0000)]
Daily bump.