Jakub Jelinek [Wed, 20 Mar 2024 16:00:08 +0000 (17:00 +0100)]
nios2: Fix up nios2_setup_incoming_varargs [PR114175]
Like for x86-64, alpha or rs6000, nios2 seems to be affected too.
Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/nios2/nios2.cc (nios2_setup_incoming_varargs): Only skip
nios2_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Jakub Jelinek [Wed, 20 Mar 2024 15:59:56 +0000 (16:59 +0100)]
nds32: Fix up nds32_setup_incoming_varargs [PR114175]
Like for x86-64, alpha or rs6000, nds32 seems to be affected too.
Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/nds32/nds32.cc (nds32_setup_incoming_varargs): Only skip
function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Jakub Jelinek [Wed, 20 Mar 2024 15:59:43 +0000 (16:59 +0100)]
m32r: Fix up m32r_setup_incoming_varargs [PR114175]
Like for x86-64, alpha or rs6000, m32r seems to be affected too.
Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/m32r/m32r.cc (m32r_setup_incoming_varargs): Only skip
function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Jakub Jelinek [Wed, 20 Mar 2024 15:59:32 +0000 (16:59 +0100)]
ft32: Fix up ft32_setup_incoming_varargs [PR114175]
Like for x86-64, alpha or rs6000, ft32 seems to be affected too.
Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/ft32/ft32.cc (ft32_setup_incoming_varargs): Only skip
function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Jakub Jelinek [Wed, 20 Mar 2024 15:59:21 +0000 (16:59 +0100)]
epiphany: Fix up epiphany_setup_incoming_varargs [PR114175]
Like for x86-64, alpha or rs6000, epiphany seems to be affected too.
Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/epiphany/epiphany.cc (epiphany_setup_incoming_varargs): Only
skip function arg advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Jakub Jelinek [Wed, 20 Mar 2024 15:59:08 +0000 (16:59 +0100)]
csky: Fix up csky_setup_incoming_varargs [PR114175]
Like for x86-64, alpha or rs6000, csky seems to be affected too.
Just visually checked differences in c23-stdarg-9.c assembly in a cross
without/with the patch, committed to trunk.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/csky/csky.cc (csky_setup_incoming_varargs): Only skip
csky_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Jakub Jelinek [Wed, 20 Mar 2024 10:46:07 +0000 (11:46 +0100)]
Use integer_{zero,one}_node some more
When looking at the analyzer MEM_REF invalid second arg issue, I've noticed
tons of build_int_cst (integer_type_node, {0,1}) or build_zero_cst
(integer_type_node) cases.
That just wastes compile time (albeit not very much).
The following patch fixes what my sed script found.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
gcc/analyzer/
* constraint-manager.cc (test_range, test_constraint_conditions,
test_constant_comparisons, test_constraint_impl, test_purging,
test_bits): Use integer_zero_node instead of
build_zero_cst (integer_type_node) or
build_int_cst (integer_type_node, 0) and integer_one_node instead of
build_int_cst (integer_type_node, 1).
* region-model.cc (region_model::get_store_value,
append_interesting_constants, test_array_1,
test_get_representative_tree, test_unique_constants, test_assignment,
test_stack_frames, test_constraint_merging, test_widening_constraints,
test_iteration_1, test_array_2): Likewise.
gcc/cp/
* coroutines.cc (expand_one_await_expression): Use
integer_zero_node instead of build_int_cst (integer_type_node, 0)
and integer_one_node instead of build_int_cst (integer_type_node, 1).
gcc/fortran/
* trans-array.cc (structure_alloc_comps): Use integer_zero_node
instead of build_zero_cst (integer_type_node) or
build_int_cst (integer_type_node, 0) and integer_one_node instead of
build_int_cst (integer_type_node, 1).
* trans-expr.cc (conv_scalar_char_value): Likewise.
* trans-stmt.cc (gfc_trans_form_team, gfc_trans_change_team,
gfc_trans_sync_team, gfc_trans_sync): Likewise.
* trans-decl.cc (create_main_function): Likewise.
* trans-intrinsic.cc (trans_this_image, conv_intrinsic_move_alloc):
Likewise.
* trans.cc (gfc_allocate_using_caf_lib, gfc_deallocate_with_status):
Likewise.
gcc/objc/
* objc-next-runtime-abi-02.cc (build_v2_class_ro_t_initializer): Use
integer_zero_node instead of build_int_cst (integer_type_node, 0).
Jakub Jelinek [Wed, 20 Mar 2024 09:55:07 +0000 (10:55 +0100)]
bitint: Fix handling of conditional bitfield loads [PR114365]
For the m_var_msb (aka left shift) case of large/huge _BitInt bitfield loads
handle_load adds a PHI node, but I forgot to actually update the temporary
the code later on uses, so the PHI result was unused and the code
incorrectly used something that wasn't valid SSA form.
In particular, we emitted
if (_29 != 2)
goto <bb 4>; [80.00%]
else
goto <bb 5>; [20.00%]
Jakub Jelinek [Wed, 20 Mar 2024 09:34:51 +0000 (10:34 +0100)]
system.h: rename vec_step to workaround powerpc/clang bug [PR114369]
On Sat, Jul 20, 2019 at 05:26:57PM +0100, Richard Sandiford wrote:
> Gerald Pfeifer <gerald@pfeifer.com> writes:
> > I have seen an increasing number of reports of GCC failing to
> > build with clang on powerpc (on FreeBSD, though that's probably
> > immaterial).
> >
> > Turns out that clang has vec_step as a reserved word on powerpc
> > with AltiVec.
> >
> > We OTOH use vec_step s as a variable name in gcc/tree-vect-loop.c.
> >
> >
> > The best approach I can see is to rename vec_step. Before I prepare
> > a patch: what alternate name/spelling would you prefer?
>
> Would it work to #define vec_step to vec_step_ or something on affected
> hosts, say in system.h?
>
> I'd prefer that to renmaing since "vec_step" does seem the most natural
> name for the variable. The equivalent scalar variable is "step" and
> other vector values in the surrounding code also use the "vec_" prefix.
So like this?
If/when clang finally fixes https://github.com/llvm/llvm-project/issues/85579
on their side, we can then limit it to clang versions which still have the
bug.
I've git grepped for vec_set and appart from altivec.h it is just used in
tree-vect-loop.cc, some Ada files which aren't preprocessed, ChangeLogs,
rs6000-vecdefines.h (but that header is only included from altivec.h and
vec_step is then redefined to the function-like macro) and in rs6000-overload.def
but that file is processed with a generator, not included in C/C++ sources.
2024-03-20 Jakub Jelinek <jakub@redhat.com>
PR bootstrap/114369
* system.h (vec_step): Define to vec_step_ when compiling
with clang on PowerPC.
Richard Biener [Tue, 19 Mar 2024 14:25:16 +0000 (15:25 +0100)]
middle-end/113396 - int128 array index and value-ranges
The following fixes bogus truncation of a value-range for an int128
array index when computing the maximum extent for a variable array
reference. Instead of possibly slowing things down by using
widest_int the following makes sure the range bounds fit within
the constraints offset_int were designed for.
PR middle-end/113396
* tree-dfa.cc (get_ref_base_and_extent): Use index range
bounds only if they fit within the address-range constraints
of offset_int.
Lewis Hyatt [Wed, 8 Nov 2023 21:13:14 +0000 (16:13 -0500)]
diagnostics: Fix behavior of permerror options after diagnostic pop [PR111918]
When a diagnostic pragma changes the classification of a given diagnostic,
the global options flags (such as warn_narrowing, etc.) may get changed too.
Specifically, if a warning was not enabled initially and was later enabled
by a pragma, then the corresponding global flag will change from false to
true when the pragma is processed. That change is permanent and is not
undone by a subsequent `#pragma GCC diagnostic pop'; the warning flag needs
to remain enabled since a diagnostic could be generated later on for a
source location prior to the pop.
So in order to support popping to the initial classification, given that the
global options flags no longer reflect that state, the diagnostic_context
object itself remembers the way things were before it changed anything. The
current implementation works fine for diagnostics that are always errors or
always warnings, but it doesn't do the right thing for diagnostics that
could be either, such as -Wnarrowing. The classification of that diagnostic
(or any permerror diagnostic) depends on the state of -fpermissive; for the
particular case of -Wnarrowing it also matters whether a compile-time or
run-time narrowing is being diagnosed.
The problem is that the current implementation insists on recording whether
an enabled diagnostic should be a DK_WARNING or a DK_ERROR, and then, after
popping to the initial state, it overrides it always to that type only. Fix
that up by adding a new internal diagnostic type DK_ANY. This just indicates
that the diagnostic is enabled without mandating exactly what type of
diagnostic it should be. Then the diagnostic can be emitted with whatever
type the frontend asks for.
Incidentally, while making this change, I noticed that classify_diagnostic()
spends some time computing a return value (the old classification kind) that
is not used anywhere. The computed value seems to have some problems, mainly
that it does not take into account `#pragma GCC diagnostic pop' at all, and
so the returned value doesn't seem like it could make sense in many
contexts. Given it would also not be desirable to leak the new internal-only
DK_ANY type to outside callers, I think it would make sense in a subsequent
cleanup patch to remove the return value altogether.
gcc/ChangeLog:
PR c++/111918
* diagnostic-core.h (enum diagnostic_t): Add DK_ANY special flag.
* diagnostic.cc (diagnostic_option_classifier::classify_diagnostic):
Make use of DK_ANY to indicate a diagnostic was initially enabled.
(diagnostic_context::diagnostic_enabled): Do not change the type of
a diagnostic if the saved classification is type DK_ANY.
gcc/testsuite/ChangeLog:
PR c++/111918
* g++.dg/cpp0x/Wnarrowing21a.C: New test.
* g++.dg/cpp0x/Wnarrowing21b.C: New test.
* g++.dg/cpp0x/Wnarrowing21c.C: New test.
* g++.dg/cpp0x/Wnarrowing21d.C: New test.
Martin Jambor [Tue, 19 Mar 2024 21:33:27 +0000 (22:33 +0100)]
ipa: Fix C++ member ptr indirect inlining (PR 114254, PR 108802)
Even though we have had code to handle creation of indirect call graph
edges (so that these calls can than be made direct as part of IPA-CP
and inlining and eventually also inlined) for C++ member pointers for
many years, it turns out that it does not work for lambdas and that it
has been severely broken since GCC 10 when the base class has virtual
functions.
Lambdas don't work because the code cannot work with structures
representing member function pointers because they are passed by
reference instead by value and the code was not ready for that.
The presence of virtual methods broke thinks because at some point C++
FE got clever and stopped emitting the check for virtual methods when
the base class does not have any and that in turn made our existing
testcases not test the necessary pattern matching code. The pattern
matcher had a small bug which did not matter before r10-917-g3b47da42de621c but did afterwards.
This patch changes the pattern matcher to match both of these cases.
gcc/ChangeLog:
2024-03-06 Martin Jambor <mjambor@suse.cz>
PR ipa/108802
PR ipa/114254
* ipa-prop.cc (ipa_get_stmt_member_ptr_load_param): Fix case looking
at COMPONENT_REFs directly from a PARM_DECL, also recognize loads from
a pointer parameter.
(ipa_analyze_indirect_call_uses): Also recognize loads from a pointer
parameter, also recognize the case when pfn pointer is loaded in its
own BB.
Marek Polacek [Tue, 19 Mar 2024 21:15:38 +0000 (17:15 -0400)]
testsuite: fix target for linkage-1.C
This test fails in C++11 due to:
linkage-1.C:3:8: error: 'f' function uses 'auto' type specifier without trailing return type
3 | inline auto f() {
| ^~~~
linkage-1.C:3:8: note: deduced return type only available with '-std=c++14' or '-std=gnu++14'
LRA removed insn setting equivalence to memory whose output was
reloaded. This resulted in writing an uninitiated value to the memory
which triggered assert in LRA code checking the final generated code.
This patch fixes the problem. Comment in the patch contains more
details about the problem and its solution.
gcc/ChangeLog:
PR target/99829
* lra-constraints.cc (lra_constraints): Prevent removing insn
with reverse equivalence to memory if the memory was reloaded.
Jakub Jelinek [Tue, 19 Mar 2024 20:06:13 +0000 (16:06 -0400)]
analyzer: fix ICE due to corrupt MEM_REFs [PR113505]
gcc/analyzer/ChangeLog
PR analyzer/113505
* region-model.cc (get_tree_for_byte_offset,
region_model::get_representative_path_var_1,
test_mem_ref, test_POINTER_PLUS_EXPR_then_MEM_REF): Use
char __attribute__((may_alias)) * as type of MEM_REF second argument.
gcc/testsuite/ChangeLog
PR analyzer/113505
* gcc.dg/analyzer/pr113505.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
David Malcolm [Tue, 19 Mar 2024 17:57:35 +0000 (13:57 -0400)]
diagnostics: fix corrupt json/SARIF on stderr [PR114348]
Various values of -fdiagnostics-format= request machine-readable output
on stderr, using JSON, but in various places we use fnotice to write
free-form text to stderr, such as "compilation terminated", leading to
corrupt JSON.
Fix by having fnotice skip the output for such cases.
gcc/ChangeLog:
PR middle-end/114348
* diagnostic-format-json.cc
(json_stderr_output_format::machine_readable_stderr_p): New.
(json_file_output_format::machine_readable_stderr_p): New.
* diagnostic-format-sarif.cc
(sarif_stream_output_format::machine_readable_stderr_p): New.
(sarif_file_output_format::machine_readable_stderr_p): New.
* diagnostic.cc (diagnostic_context::action_after_output): Move
"fnotice" to before "finish" call, so that we still have the
diagnostic_context.
(fnotice): Bail out if the user requested one of the
machine-readable diagnostic output formats on stderr.
* diagnostic.h
(diagnostic_output_format::machine_readable_stderr_p): New pure
virtual function.
(diagnostic_text_output_format::machine_readable_stderr_p): New.
(diagnostic_context::get_output_format): New accessor.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Edwin Lu [Tue, 12 Mar 2024 21:31:40 +0000 (14:31 -0700)]
RISC-V: Update test expectancies with recent scheduler change
Given the recent change with adding the scheduler pipeline descriptions,
many scan-dump failures emerged. Relax the expected assembler output
conditions on the affected tests to reduce noise.
Edwin Lu [Mon, 18 Mar 2024 18:43:41 +0000 (11:43 -0700)]
RISC-V: Fix C23 (...) functions returning large aggregates [PR114175]
We assume that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments and
there is nothing to advance, but that is not the case for (...) functions
returning by hidden reference which have one such artificial argument.
This causes gcc.dg/c23-stdarg-[68].c to fail
PR target/114175
* config/riscv/riscv.cc (riscv_setup_incoming_varargs): Only skip
riscv_funciton_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL
Jonathan Wakely [Mon, 18 Mar 2024 13:22:17 +0000 (13:22 +0000)]
libstdc++: Fix infinite loop in std::binomial_distribution [PR114359]
The multiplication (4 * _M_t * __1p) can wraparound to zero if _M_t is
unsigned and 4 * _M_t wraps to zero. The third operand has type double,
so do the second multiplication first, so that we aren't multiplying
integers.
libstdc++-v3/ChangeLog:
PR libstdc++/114359
* include/bits/random.tcc (binomial_distribution::param_type):
Ensure arithmetic is done as type double.
* testsuite/26_numerics/random/binomial_distribution/114359.cc: New test.
Jonathan Wakely [Thu, 29 Feb 2024 17:13:49 +0000 (17:13 +0000)]
libstdc++: Suppress deprecation messages from <tbb/task.h> [PR101228]
libstdc++-v3/ChangeLog:
PR libstdc++/101228
* include/pstl/parallel_backend_tbb.h (TBB_SUPPRESS_DEPRECATED_MESSAGES):
Define before including <tbb/task.h> then undef afterwards.
Jonathan Wakely [Fri, 1 Mar 2024 11:20:51 +0000 (11:20 +0000)]
libstdc++: Regenerate <bits/version.h> in maintainer mode
This is a generated header but regenerating it requires the manual step
of running 'make -C include update-version' in the libstdc++ build dir.
Make it regenerate automatically when --enable-maintainer-mode is used.
Jonathan Wakely [Tue, 19 Mar 2024 12:58:27 +0000 (12:58 +0000)]
libstdc++: Update docs on build process and generated files
There are several more sub-directories below 'src' now, with lots more
conveience libraries. Document them all as of GCC 14.
Also document how to regenerate the generated headers under include/bits
and how to update the tzdata.zi file.
libstdc++-v3/ChangeLog:
* doc/xml/manual/build_hacking.xml: Document generated files.
Update list of convenience libraries and sub-directories under
the src directory.
* doc/html/*: Regenerate.
Jonathan Wakely [Tue, 19 Mar 2024 12:43:29 +0000 (12:43 +0000)]
libstdc++: Fix Python scripts to output the correct filename
These scripts both print "generated by $file, do not edit" header but
one of them prints the wrong filename. Use the built-in __file__
attribute to ensure it's correct.
contrib/ChangeLog:
* unicode/gen_libstdcxx_unicode_data.py: Fix header of generated
file to name the correct script.
libstdc++-v3/ChangeLog:
* include/bits/text_encoding-data.h: Regenerate.
* include/bits/unicode-data.h: Regenerate.
* scripts/gen_text_encoding_data.py: Fix header of generated
file to name the correct script.
Jonathan Wakely [Mon, 18 Mar 2024 13:00:17 +0000 (13:00 +0000)]
libstdc++: Begin lifetime of storage in std::vector<bool> [PR114367]
This doesn't cause a problem with GCC, but Clang correctly diagnoses a
bug in the code. The objects in the allocated storage need to begin
their lifetime before we start using them.
This change uses the allocator's construct function instead of using
std::construct_at directly, in order to support fancy pointers.
libstdc++-v3/ChangeLog:
PR libstdc++/114367
* include/bits/stl_bvector.h (_M_allocate): Use allocator's
construct function to begin lifetime of words.
David Malcolm [Tue, 19 Mar 2024 13:06:45 +0000 (09:06 -0400)]
analyzer: fixes to __atomic_{exchange,load,store} [PR114286]
In r14-1497-gef768035ae8090 I added some support to the analyzer for
__atomic_ builtins (enough to fix false positives I was seeing in
my integration tests).
Unfortunately I messed up the implementation of
__atomic_{exchange,load,store}, leading to ICEs seen in
PR analyzer/114286.
Fixed thusly, fixing the ICEs. Given that we're in stage 4, the patch
doesn't add support for any of the various __atomic_compare_exchange
builtins, so that these continue to fall back to the analyzer's
"anything could happen" handling of unknown functions.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
gcc/analyzer/ChangeLog:
PR analyzer/114286
* kf.cc (class kf_atomic_exchange): Reimplement based on signature
seen in gimple, rather than user-facing signature.
(class kf_atomic_load): Likewise.
(class kf_atomic_store): New.
(register_atomic_builtins): Register kf_atomic_store.
gcc/testsuite/ChangeLog:
PR analyzer/114286
* c-c++-common/analyzer/atomic-builtins-pr114286.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Iain Sandoe [Mon, 18 Mar 2024 10:06:44 +0000 (10:06 +0000)]
testsuite, Darwin: Use the IOKit framework in framework-1.c [PR114049].
The intent of the test is to show that we find a framework that
is installed in /System/Library/Frameworks when the user has added
a '-F' option. The trick is to choose some header that is present
for all the Darwin versions we support and that does not contain any
content we cannot parse. We had been using the Kernel framework for
this, but recent SDK versions have revealed that this is not suitable.
Replacing with a use of IOKit.
PR target/114049
gcc/testsuite/ChangeLog:
* gcc.dg/framework-1.c: Use an IOKit header instead of a
Kernel one.
Iain Sandoe [Mon, 18 Mar 2024 09:57:33 +0000 (09:57 +0000)]
libstdc++: Sync the atomic_link_flags implementation with GCC.
For Darwin, in order to allow uninstalled testing, we need to provide
a '-B' option pointing to each path containing an uninstalled library
that we are using (these get appended to the embedded runpaths).
This updates the version of the atomic_link_flags proc in the libstdc++
testsuite to do the same as the one in the GCC testsuite.
libstdc++-v3/ChangeLog:
* testsuite/lib/dg-options.exp (atomic_link_flags): Emit a -B
option for the path to the uninstalled libatomic.
Iain Sandoe [Tue, 19 Mar 2024 10:40:50 +0000 (10:40 +0000)]
libstdc++, Darwin: Do not use dev/null as the file for executables.
Darwin has a separate debug linker, which is invoked when the command
line contains source files and debug is enabled.
Using /dev/null as the executable name does not, therefore, work when
debug is enabled, since the debug linker does not accept /dev/null as
a valid executable name.
The leads to incorrectly UNSUPPORTED testcases because of the unintended
error result from the test compilation.
The solution here is to use a temporary file that is deleted at the
end of the test (which is the mechanism used elsewhere)
libstdc++-v3/ChangeLog:
* testsuite/lib/libstdc++.exp (v3_target_compile): Instead of
/dev/null, use a temporary file for test executables on Darwin.
Richard Biener [Tue, 19 Mar 2024 11:24:08 +0000 (12:24 +0100)]
tree-optimization/114151 - revert PR114074 fix
The following reverts the chrec_fold_multiply fix and only keeps
handling of constant overflow which keeps the original testcase
fixed. A better solution might involve ranger improvements or
tracking of assumptions during SCEV analysis similar to what niter
analysis does.
PR tree-optimization/114151
PR tree-optimization/114269
PR tree-optimization/114322
PR tree-optimization/114074
* tree-chrec.cc (chrec_fold_multiply): Restrict the use of
unsigned arithmetic when actual overflow on constant operands
is observed.
Jakub Jelinek [Tue, 19 Mar 2024 08:49:59 +0000 (09:49 +0100)]
arc: Fix up arc_setup_incoming_varargs [PR114175]
Like for x86-64, alpha or rs6000, arc seems to be affected too.
2024-03-19 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/arc/arc.cc (arc_setup_incoming_varargs): Only skip
arc_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Xi Ruoyao [Mon, 18 Mar 2024 09:18:34 +0000 (17:18 +0800)]
LoongArch: Fix C23 (...) functions returning large aggregates [PR114175]
We were assuming TYPE_NO_NAMED_ARGS_STDARG_P don't have any named
arguments and there is nothing to advance, but that is not the case
for (...) functions returning by hidden reference which have one such
artificial argument. This is causing gcc.dg/c23-stdarg-6.c and
gcc.dg/c23-stdarg-8.c to fail.
Fix the issue by checking if arg.type is NULL, as r14-9503 explains.
gcc/ChangeLog:
PR target/114175
* config/loongarch/loongarch.cc
(loongarch_setup_incoming_varargs): Only skip
loongarch_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P
functions if arg.type is NULL.
Christophe Lyon [Fri, 15 Mar 2024 19:55:43 +0000 (19:55 +0000)]
arm: [MVE intrinsics] Fix support for loads [PR target/114323]
The testcase in this PR shows that we would load from an uninitialized
location, because the vld1 instrinsics are reported as "const". This
is because function_instance::reads_global_state_p() does not take
CP_READ_MEMORY into account. Fixing this gives vld1 the "pure"
attribute instead, and solves the problem.
Like in the r14-9503 change on x86-64, I think Alpha also needs to
function_arg_advance after the hidden return pointer argument if
any.
At least, the following patch changes the assembly of s1-s6 functions
on the https://gcc.gnu.org/pipermail/gcc-patches/2024-March/647956.html
c23-stdarg-9.c testcase, and eyeballing the assembly for int f8 (...)
the ... args are passed in 16..21 registers and then on the stack,
while for struct S s8 (...) have hidden return pointer passed in 16
register and ... args in 17..21 registers and then on the stack, and
seems without this patch the incoming varargs setup does the wrong thing
(but I can't test on alpha easily).
Many targets seem to be unaffected, e.g. aarch64, arm, s390*, so I'm not
trying to change all targets together because such a change clearly isn't
needed e.g. for targets which use special register for the hidden return
pointer.
2024-03-19 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/alpha/alpha.cc (alpha_setup_incoming_varargs): Only skip
function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Jakub Jelinek [Tue, 19 Mar 2024 08:13:32 +0000 (09:13 +0100)]
rs6000: Fix up setup_incoming_varargs [PR114175]
The c23-stdarg-8.c test (as well as the new test below added to cover even
more cases) FAIL on powerpc64le-linux and presumably other powerpc* targets
as well.
Like in the r14-9503-g218d174961 change on x86-64 we need to advance
next_cum after the hidden return pointer argument even in case where
there are no user arguments before ... in C23.
The following patch does that.
There is another TYPE_NO_NAMED_ARGS_STDARG_P use later on:
if (!TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (current_function_decl))
&& targetm.calls.must_pass_in_stack (arg))
first_reg_offset += rs6000_arg_size (TYPE_MODE (arg.type), arg.type);
but I believe it was added there in r13-3549-g4fe34cdc unnecessarily,
when there is no hidden return pointer argument, arg.type is NULL and
must_pass_in_stack_var_size as well as must_pass_in_stack_var_size_or_pad
return false in that case, and for the TYPE_NO_NAMED_ARGS_STDARG_P
case with hidden return pointer argument that argument should have pointer
type and it is the first argument, so must_pass_in_stack shouldn't be true
for it either.
2024-03-19 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/rs6000/rs6000-call.cc (setup_incoming_varargs): Only skip
rs6000_function_arg_advance_1 for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
Jakub Jelinek [Tue, 19 Mar 2024 08:10:26 +0000 (09:10 +0100)]
openmp: Make c_omp_check_loop_binding_exprs diagnostics translatable [PR114364]
c_omp_check_loop_binding_exprs with check_loop_binding_expr was composing
diagnostics from a format string with %s that provided additional words (but not
keywords). That is a big no no for translations, both because the translator
can't choose a different word order and because the %s part wasn't translated
at all (would need to use _("...") to get translated), so this patch rewrites it
such that the whole messages are in the format strings.
2024-03-19 Jakub Jelinek <jakub@redhat.com>
PR c/114364
* c-omp.cc (enum check_loop_binding_expr_ctx): New type.
(check_loop_binding_expr): Remove context argument, add ctx
argument with check_loop_binding_expr_ctx type at the end. Don't
create diagnostic message from multiple pieces.
(c_omp_check_loop_binding_exprs): Adjust callers.
Richard Biener [Mon, 18 Mar 2024 11:39:03 +0000 (12:39 +0100)]
tree-optimization/114375 - disallow SLP discovery of permuted mask loads
We cannot currently handle permutations of mask loads in code generation
or permute optimization. But we simply drop any permutation on the
floor, so the following instead rejects the SLP build rather than
producing wrong-code. I've also made sure to reject them in
vectorizable_load for completeness.
PR tree-optimization/114375
* tree-vect-slp.cc (vect_build_slp_tree_2): Compute the
load permutation for masked loads but reject it when any
such is necessary.
* tree-vect-stmts.cc (vectorizable_load): Reject masked
VMAT_ELEMENTWISE and VMAT_STRIDED_SLP as those are not
supported.
Contributors:
Mary Bennett <mary.bennett@embecosm.com>
Nandni Jamnadas <nandni.jamnadas@embecosm.com>
Pietra Ferreira <pietra.ferreira@embecosm.com>
Charlie Keaney
Jessica Mills
Craig Blackmore <craig.blackmore@embecosm.com>
Simon Cook <simon.cook@embecosm.com>
Jeremy Bennett <jeremy.bennett@embecosm.com>
Helene Chelin <helene.chelin@embecosm.com>
gcc/ChangeLog:
* common/config/riscv/riscv-common.cc: Create XCVbi extension
support.
* config/riscv/riscv.opt: Likewise.
* config/riscv/corev.md: Implement cv_branch<mode> pattern
for cv.beqimm and cv.bneimm.
* config/riscv/riscv.md: Add CORE-V branch immediate to RISC-V
branch instruction pattern.
* config/riscv/constraints.md: Implement constraints
cv_bi_s5 - signed 5-bit immediate.
* config/riscv/predicates.md: Implement predicate
const_int5s_operand - signed 5 bit immediate.
* doc/sourcebuild.texi: Add XCVbi documentation.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/cv-bi-beqimm-compile-1.c: New test.
* gcc.target/riscv/cv-bi-beqimm-compile-2.c: New test.
* gcc.target/riscv/cv-bi-bneimm-compile-1.c: New test.
* gcc.target/riscv/cv-bi-bneimm-compile-2.c: New test.
* lib/target-supports.exp: Add proc for XCVbi.
This patch add XiangShan Nanhu cpu microarchitecture,
Nanhu is a 6-issue, superscalar, out-of-order processor.
More details see: https://xiangshan-doc.readthedocs.io/zh-cn/latest/arch
gcc/ChangeLog:
* config/riscv/riscv-cores.def (RISCV_TUNE): New def.
(RISCV_CORE): Ditto.
* config/riscv/riscv-opts.h (enum riscv_microarchitecture_type): New
option.
* config/riscv/riscv.cc: New def.
* config/riscv/riscv.md: New include.
* config/riscv/xiangshan.md: New file.
gcc/testsuite/ChangeLog:
* gcc.target/riscv/mcpu-xiangshan-nanhu.c: New test.
Nathaniel Shead [Sat, 16 Mar 2024 11:00:29 +0000 (22:00 +1100)]
c++: Fix handling of no-linkage decls for modules
When testing the changes for PR c++/112631 we discovered that currently
we don't emit definitions of block-scope function declarations if
they're not used in the module interface TU, which causes issues if they
are used by importers.
This patch fixes the handling of no-linkage declarations for C++20. In
particular, a type declared in a function with vague linkage or declared
in a module CMI could potentially be accessible outside its defining TU,
and as such we can't assume that function declarations using that type
can never be defined in another TU.
A complication with handling this is that we're only strictly interested
in declarations with a module CMI, but when parsing the global module
fragment we don't yet know whether or not this module will have a CMI
until we reach the "export module" line (or not). Since this case is
IFNDR anyway (by [basic.def.odr] p11) we just tentatively assume while
parsing the GMF that this module will have a CMI; once we see (or don't
see) an 'export module' declaration we can commit to that knowledge for
future declarations.
gcc/cp/ChangeLog:
* cp-tree.h (module_maybe_has_cmi_p): New function.
* decl.cc (grokfndecl): Mark block-scope functions as public if
they could be visible in other TUs.
* decl2.cc (no_linkage_error): Don't error for declarations that
could be defined in other TUs since C++20. Suppress duplicate
errors from 'check_global_declaration'.
* tree.cc (no_linkage_check): In relaxed mode, don't consider
types in a module CMI to have no linkage.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/linkage-1.C: New test.
* g++.dg/modules/block-decl-3.h: New test.
* g++.dg/modules/block-decl-3_a.C: New test.
* g++.dg/modules/block-decl-3_b.C: New test.
* g++.dg/modules/block-decl-3_c.C: New test.
* g++.dg/modules/linkage-1_a.C: New test.
* g++.dg/modules/linkage-1_b.C: New test.
* g++.dg/modules/linkage-1_c.C: New test.
* g++.dg/modules/linkage-2.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
David Malcolm [Mon, 18 Mar 2024 22:44:34 +0000 (18:44 -0400)]
analyzer: fix ICEs due to sloppy types in bounds-checking [PR110902,PR110928,PR111305,PR111441]
Various analyzer ICEs in our bugzilla relate to sloppy use of types
within bounds-checking.
The bounds-checking code works by comparing symbolic *bit* offsets, and
we don't have a good user-facing type that can represent such an offset
(ptrdiff_type_node is for *byte* offsets).
ana::svalue doesn't enforce valid combinations of types for things like
binary operations. When I added the access diagrams for GCC 14, this
could lead to attempts to generate trees for such svalues, leading to
trees with invalid combinations of types (e.g. PLUS_EXPR or MULT_EXPR of
incompatible types), leading to ICEs inside the tree folding logic.
I tried two approaches to fixing this.
My first approach was to fix the type-handling throughout the
bounds-checking code to use correct types, using size_type_node for
sizes, ptrdiff_type_node for byte offsets, and trying ptrdiff_type_node
for bit offsets. I implemented this, and it fixed the crashes, but
unfortunately it led to:
(a) numerous false negatives from the bounds-checking code, due to it
becoming unable to be sure that the accessed offset was beyond the valid
bounds, due to the expressions involved gaining complicated sets of
nested casts.
(b) ugly access diagrams full of nested casts (for capacities, gap
measurements, etc)
So my second approach, implemented in this patch, is to accept that we
don't have a tree type for representing bit offsets. The patch
represents bit offsets using "typeless" symbolic values i.e. ones for
which get_type () is NULL_TREE, and implements enough support for basic
arithemetic as if these are mathematical integers (albeit ones for which
concrete values within an expression must fit within a signed wide int).
Such values can't be converted to tree, so the patch avoids such
conversions, instead implementing a new svalue::maybe_print_for_user for
printing them to a pretty_printer. The patch uses ptrdiff_type_node for
byte offsets.
Doing so fixes the crashes, whilst appearing to preserve the behavior of
-Wanalyzer-out-of-bounds in my testing.
gcc/analyzer/ChangeLog:
PR analyzer/110902
PR analyzer/110928
PR analyzer/111305
PR analyzer/111441
* access-diagram.cc: Include "analyzer/analyzer-selftests.h".
(get_access_size_str): Reimplement for conversion of
implmementation of bit_size_expr from tree to const svalue &. Use
svalue::maybe_print_for_user rather than tree printing routines.
(remove_ssa_names): Make non-static.
(bit_size_expr::get_formatted_str): Rename to...
(bit_size_expr::maybe_get_formatted_str): ...this, adding "model"
param and converting return type to a unique_ptr. Update for
conversion of implementation of bit_size_expr from tree to
const svalue &. Use svalue::maybe_print_for_user rather than tree
printing routines.
(bit_size_expr::print): Rename to...
(bit_size_expr::maybe_print_for_user): ...this, adding "model"
param and converting return type to bool. Update for
conversion of implementation of bit_size_expr from tree to
const svalue &. Use svalue::maybe_print_for_user rather than tree
printing routines.
(bit_size_expr::maybe_get_as_bytes): Add "mgr" param and convert
return type from tree to const svalue *; reimplement.
(access_range::access_range): Call strip_types when on region_offset
intializations.
(access_range::get_size): Update for conversion of implementation
of bit_size_expr from tree to const svalue &.
(access_operation::get_valid_bits): Pass manager to access_range
ctor.
(access_operation::maybe_get_invalid_before_bits): Likewise.
(access_operation::maybe_get_invalid_after_bits): Likewise.
(boundaries::add): Likewise.
(bit_to_table_map::populate): Add "mgr" param and pass it to
access_range ctor.
(access_diagram_impl::access_diagram_impl): Pass manager to
bit_to_table_map::populate.
(access_diagram_impl::maybe_add_gap): Use svalue rather than tree
for symbolic bit offsets. Port to new bit_size_expr
representation.
(access_diagram_impl::add_valid_vs_invalid_ruler): Port to new
bit_size_expr representation.
(selftest::assert_eq_typeless_integer): New.
(ASSERT_EQ_TYPELESS_INTEGER): New.
(selftest::test_bit_size_expr_to_bytes): New.
(selftest::analyzer_access_diagram_cc_tests): New.
* access-diagram.h (class bit_size_expr): Reimplement, converting
implementation from tree to const svalue &.
(access_range::access_range): Add "mgr" param. Call strip_types
on region_offset initializations.
(access_range::get_size): Update decl for reimplementation.
* analyzer-selftests.cc (selftest::run_analyzer_selftests): Call
selftest::analyzer_access_diagram_cc_tests.
* analyzer-selftests.h
(selftest::analyzer_checker_script_cc_tests): Delete this stray
typo.
(selftest::analyzer_access_diagram_cc_tests): New decl.
* analyzer.h (print_expr_for_user): New decl.
(calc_symbolic_bit_offset): Update decl for reimplementation.
(strip_types): New decls.
(remove_ssa_names): New decl.
* bounds-checking.cc (strip_types): New.
(region_model::check_symbolic_bounds): Use typeless svalues.
* region-model-manager.cc
(region_model_manager::get_or_create_constant_svalue): Add "type"
param. Add overload with old signature.
(region_model_manager::get_or_create_int_cst): Support type being
NULL_TREE.
(region_model_manager::maybe_fold_unaryop): Gracefully reject folding
of casts to NULL_TREE type.
(get_code_for_cast): Use NOP_EXPR for "casting" svalues to
NULL_TREE type.
(region_model_manager::get_or_create_cast): Support "casting"
svalues to NULL_TREE type.
(region_model_manager::maybe_fold_binop): Don't crash on inputs
with NULL_TREE type. Handle folding of binops on constants with
NULL_TREE type. Add missing cast from PR analyzer/110902.
Support enough folding of other ops on NULL_TREE type to support
bounds checking.
(region_model_manager::get_or_create_const_fn_result_svalue):
Remove assertion that type is nonnull.
* region-model-manager.h
(region_model_manager::get_or_create_constant_svalue): Add
overloaded decl taking a type.
(region_model_manager::maybe_fold_binop): Make public.
(region_model_manager::constants_map_t): Use
constant_svalue::key_t for the key, rather than just tree.
* region-model.cc (print_expr_for_user): New.
(selftest::test_array_2): Handle casts.
* region.cc (region_offset::calc_symbolic_bit_offset): Return
const svalue & rather than tree, and reimplement accordingly.
(region::calc_offset): Use ptrdiff_type_node for types of byte
offsets.
(region::maybe_print_for_user): New.
(element_region::get_relative_symbolic_offset): Use NULL_TREE for
types of bit offsets.
(offset_region::get_bit_offset): Likewise.
(sized_region::get_bit_size_sval): Likewise for bit sizes.
* region.h (region::maybe_print_for_user): New decl.
* svalue.cc (class auto_add_parens): New.
(svalue::maybe_print_for_user): New.
(svalue::cmp_ptr): Support typeless constant svalues.
(tristate_from_boolean_tree_node): New, taken from...
(constant_svalue::eval_condition): ...here. Handle comparison of
typeless integer svalue constants.
* svalue.h (svalue::maybe_print_for_user): New decl.
(class constant_svalue): Support the type of the svalue being
NULL_TREE.
(struct default_hash_traits<constant_svalue::key_t>): New.
François Dumont [Sun, 17 Mar 2024 18:06:55 +0000 (19:06 +0100)]
libstdc++: Fix N3344 behavior on _Safe_iterator::_M_can_advance
We shall be able to advance from a 0 offset a value-initialized iterator.
libstdc++-v3/ChangeLog:
* include/debug/safe_iterator.tcc (_Safe_iterator<>::_M_can_advance):
Accept 0 offset advance on value-initialized iterator.
* testsuite/23_containers/vector/debug/n3644.cc: New test case.
Unordered container local_iterator range shall not contain any singular
iterator unless both iterators are both value-initialized.
libstdc++-v3/ChangeLog:
* include/debug/safe_local_iterator.tcc
(_Safe_local_iterator::_M_valid_range): Add _M_value_initialized and
_M_singular checks.
* testsuite/23_containers/unordered_set/debug/114316.cc: New test case.
Recent PR111822 fix implemented REG_EH_REGION note copying to a STV converted
preload instruction in general_scalar_chain::convert_op. However, the same
issue remains in timode_scalar_chain::convert_op. Instead of copying the
newly introduced code to timode_scalar_chain::convert_op, the patch unifies
both functions to a common function.
PR target/111822
gcc/ChangeLog:
* config/i386/i386-features.cc (smode_convert_cst): New function
to handle SImode, DImode and TImode immediates, generalized from
timode_convert_cst.
(timode_convert_cst): Remove.
(scalar_chain::convert_op): Unify from
general_scalar_chain::convert_op and timode_scalar_chain::convert_op.
(general_scalar_chain::convert_op): Remove.
(timode_scalar_chain::convert_op): Remove.
(timode_scalar_chain::convert_insn): Update the call to
renamed timode_convert_cst.
* config/i386/i386-features.h (class scalar_chain):
Redeclare convert_op as protected class member.
(class general_calar_chain): Remove convert_op.
(class timode_scalar_chain): Ditto.
gcc/testsuite/ChangeLog:
* g++.target/i386/pr111822.C (dg-do): Compile only for ia32 targets.
(dg-options): Add -march=x86-64.
testsuite: Turn errors back into warnings in arm/acle/cde-mve-error-2.c
Since commit 2c3db94d9fd ("c: Turn int-conversion warnings into
permerrors") the test fails with errors such as:
FAIL: gcc.target/arm/acle/cde-mve-error-2.c -O0 (test for errors, line 32)
FAIL: gcc.target/arm/acle/cde-mve-error-2.c -O0 (test for errors, line 33)
FAIL: gcc.target/arm/acle/cde-mve-error-2.c -O0 (test for errors, line 34)
FAIL: gcc.target/arm/acle/cde-mve-error-2.c -O0 (test for errors, line 35)
â‹®
FAIL: gcc.target/arm/acle/cde-mve-error-2.c -O0 (test for excess errors)
There's a total of 1016 errors. Here's a sample of the excess errors:
Excess errors:
/path/gcc.git/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c:117:31: error: passing argument 2 of '__builtin_arm_vcx1qv16qi' makes integer from pointer without a cast [-Wint-conversion]
/path/gcc.git/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c:119:3: error: passing argument 3 of '__builtin_arm_vcx1qav16qi' makes integer from pointer without a cast [-Wint-conversion]
/path/gcc.git/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c:121:3: error: passing argument 3 of '__builtin_arm_vcx2qv16qi' makes integer from pointer without a cast [-Wint-conversion]
/path/gcc.git/gcc/testsuite/gcc.target/arm/acle/cde-mve-error-2.c:123:3: error: passing argument 3 of '__builtin_arm_vcx2qv16qi' makes integer from pointer without a cast [-Wint-conversion]
The test expects these messages to be warnings, not errors. My first
try was to change it to expect them as errors instead. This didn't
work, IIUC because the error prevents the compiler from continuing
processing the file and thus other errors which are expected by the
test don't get emitted.
Therefore, add -fpermissive so that the test behaves as it did
previously. Because of the additional line in the header, the line
numbers of the expected warnings don't match anymore so replace them
with ".-1" as suggested by Richard Earnshaw.
Tested on armv8l-linux-gnueabihf.
gcc/testsuite/ChangeLog:
* gcc.target/arm/acle/cde-mve-error-2.c: Add -fpermissive. Use
relative offsets for line numbers.
Jonathan Wakely [Fri, 1 Mar 2024 16:46:29 +0000 (16:46 +0000)]
gcc_update: Add missing generated files
I'm seeing errors for --enable-maintainer-mode builds due to incorrectly
regenerating these files. They should be touched by gcc_update so they
aren't regenerated incorrectly.
contrib/ChangeLog:
* gcc_update: Add more generated files in libcc1, lto-plugin,
fixincludes, and libstdc++-v3.
Nathaniel Shead [Fri, 15 Mar 2024 13:11:25 +0000 (00:11 +1100)]
testsuite: Fix excess errors for new modules testcases on powerpc [PR114320]
On some configurations, PowerPC emits -Wpsabi warnings when using IEEE
long doubles on a machine configured with IBM long double by default.
This patch suppresses these warnings for this testcase.
Georg-Johann Lay [Mon, 18 Mar 2024 07:50:02 +0000 (08:50 +0100)]
avr.md - Tweak xor insn constraints.
xor insn can handle some more values without the requirement of a
scratch register. This patch adds a new constraint alternative for
such values. The output function avr_out_bitop already handles
these cases, so no change is needed there.
As the tests assume that strndup() is visible (only part of
POSIX.1-2008) define the guard to ensure that it's visible. Currently,
glibc appears to always have this defined in C++, newlib does not.
Without this patch, fails like this can be seen:
Testing analyzer/strndup-1.c, -std=c++98
.../strndup-1.c: In function 'void test_1(const char*)':
.../strndup-1.c:11:13: error: 'strndup' was not declared in this scope; did you mean 'strncmp'?
.../strndup-1.c: In function 'void test_2(const char*)':
.../strndup-1.c:16:13: error: 'strndup' was not declared in this scope; did you mean 'strncmp'?
.../strndup-1.c: In function 'void test_3(const char*)':
.../strndup-1.c:21:13: error: 'strndup' was not declared in this scope; did you mean 'strncmp'?
hppa: Improve handling of REG+D addresses when generating PA 2.0 code
In looking at PR 112415, it became clear that improvements could be
made in the handling of loads and stores using REG+D addresses. A
change in 2002 conflated two issues:
1) We can't generate insns with 14-bit displacements before reload
completes when generating PA 1.x code since floating-point loads and
stores only support 5-bit offsets in PA 1.x.
2) The GNU ELF 32-bit linker lacks relocation support for PA 2.0
floating point instructions with 14-bit displacements. These
relocations affect instructions with symbolic references.
The result of the change was to block creation of PA 2.0 instructions
with 14-bit REG_D displacements for SImode, DImode, SFmode and DFmode
on the GNU linux target before reload. This was unnecessary as these
instructions don't need relocation.
This change revises the INT14_OK_STRICT define to allow creation
of instructions with 14-bit REG+D addresses before reload when
generating PA 2.0 code.
2024-03-17 John David Anglin <danglin@gcc.gnu.org>
gcc/ChangeLog:
PR rtl-optimization/112415
* config/pa/pa.cc (pa_emit_move_sequence): Revise condition
for symbolic memory operands.
(pa_legitimate_address_p): Revise LO_SUM condition.
* config/pa/pa.h (INT14_OK_STRICT): Revise define. Move
comment about GNU linker to predicates.md.
* config/pa/predicates.md (floating_point_store_memory_operand):
Revise condition for symbolic memory operands. Update
comment.
François Dumont [Thu, 14 Mar 2024 21:13:57 +0000 (22:13 +0100)]
libstdc++: Implement N3644 on _Safe_iterator<> [PR114316]
Consider range of value-initialized iterators as valid and empty.
libstdc++-v3/ChangeLog:
PR libstdc++/114316
* include/debug/safe_iterator.tcc (_Safe_iterator<>::_M_valid_range):
First check if both iterators are value-initialized before checking if
singular.
* testsuite/23_containers/set/debug/114316.cc: New test case.
* testsuite/23_containers/vector/debug/114316.cc: New test case.
Gaius Mulley [Sun, 17 Mar 2024 14:49:23 +0000 (14:49 +0000)]
PR modula2/114296 ICE when attempting to create a constant set with a variable element
This patch corrects the virtual token creation for the aggregate constant
and also corrects tokens for constructor components.
gcc/m2/ChangeLog:
PR modula2/114296
* gm2-compiler/M2ALU.mod (ElementsSolved): Add tokenno parameter.
Add constant checks and generate error messages.
(EvalSetValues): Pass tokenno parameter to ElementsSolved.
* gm2-compiler/M2LexBuf.mod (stop): New procedure.
(MakeVirtualTok): Call stop if caret = BadTokenNo.
* gm2-compiler/M2Quads.def (BuildNulExpression): Add tokpos
parameter.
(BuildSetStart): Ditto.
(BuildEmptySet): Ditto.
(BuildConstructorEnd): Add startpos parameter.
(BuildTypeForConstructor): Add tokpos parameter.
* gm2-compiler/M2Quads.mod (BuildNulExpression): Add tokpos
parameter and push tokpos to the quad stack.
(BuildSetStart): Add tokpos parameter and push tokpos.
(BuildSetEnd): Rewrite.
(BuildEmptySet): Add tokpos parameter and push tokpos with
the set type.
(BuildConstructorStart): Pop typepos.
(BuildConstructorEnd): Add startpos parameter.
Create valtok from startpos and cbratokpos.
(BuildTypeForConstructor): Add tokpos parameter.
* gm2-compiler/M2Range.def (InitAssignmentRangeCheck): Rename
d to des and e to expr.
Add destok and exprtok parameters.
* gm2-compiler/M2Range.mod (InitAssignmentRangeCheck): Rename
d to des and e to expr.
Add destok and exprtok parameters.
Save destok and exprtok into range record.
(FoldAssignment): Pass exprtok to TryDeclareConstant.
* gm2-compiler/P3Build.bnf (ComponentValue): Rewrite.
(Constructor): Rewrite.
(ConstSetOrQualidentOrFunction): Rewrite.
(SetOrQualidentOrFunction): Rewrite.
* gm2-compiler/PCBuild.bnf (ConstSetOrQualidentOrFunction): Rewrite.
(SetOrQualidentOrFunction): Rewrite.
* gm2-compiler/PHBuild.bnf (Constructor): Rewrite.
(ConstSetOrQualidentOrFunction): Rewrite.
gcc/testsuite/ChangeLog:
PR modula2/114296
* gm2/pim/fail/badtype2.mod: New test.
Jakub Jelinek [Sat, 16 Mar 2024 14:16:33 +0000 (15:16 +0100)]
i386: Fix setup of incoming varargs for (...) functions which return large aggregates [PR114175]
The c23-stdarg-6.c testcase I've added recently apparently works fine with
-O0 but aborts with -O1 and higher on x86_64-linux.
The problem is in setup of incoming varargs.
Like function.cc before r14-9249 even ix86_setup_incoming_varargs assumes
that TYPE_NO_NAMED_ARGS_STDARG_P don't have any named arguments and there
is nothing to advance, but that is not the case for (...) functions
returning by hidden reference which have one such artificial argument.
If the setup_incoming_varargs hook is called from the
if (TYPE_NO_NAMED_ARGS_STDARG_P (TREE_TYPE (fndecl))
&& fnargs.is_empty ())
{
struct assign_parm_data_one data = {};
assign_parms_setup_varargs (&all, &data, false);
}
spot, i.e. where there is no hidden return argument passed, arg.type
is always NULL, while when it is called in the
if (cfun->stdarg && !DECL_CHAIN (parm))
assign_parms_setup_varargs (&all, &data, false);
spot, even when it is TYPE_NO_NAMED_ARGS_STDARG_P arg.type will be non-NULL.
The tree-stdarg.cc pass in f in c23-stdarg-6.cc at -O1 or higher determines
that va_arg is used on integral types at most twice (loads 2 words),
and because ix86_setup_incoming_varargs doesn't advance, the code saves
just the %rdi and %rsi registers to the save area. But that isn't correct,
it should save %rsi and %rdx because %rdi is the hidden return argument.
With -O0 tree-stdarg.cc doesn't attempt to optimize and we save all the
registers, so it works fine in that case.
Now, I think we'll need the same fix also on
aarch64, alpha, arc, csky, ia64, loongarch, mips, mmix, nios2, riscv, visium
which have pretty much the similarly looking snippet in their hooks
changed by the r13-3549 commit.
Then arm, epiphany, fr30, frv, ft32, m32r, mcore, nds32, rs6000, sh
have different changes but most likely need something similar too.
I don't have access to most of those, could test aarch64 and rs6000 I guess.
2024-03-16 Jakub Jelinek <jakub@redhat.com>
PR target/114175
* config/i386/i386.cc (ix86_setup_incoming_varargs): Only skip
ix86_function_arg_advance for TYPE_NO_NAMED_ARGS_STDARG_P functions
if arg.type is NULL.
* gcc.dg/c23-stdarg-7.c: New test.
* gcc.dg/c23-stdarg-8.c: New test.
Jakub Jelinek [Sat, 16 Mar 2024 14:15:29 +0000 (15:15 +0100)]
bitint: Fix up stores to large/huge _BitInt bitfields [PR114329]
The verifier requires BIT_FIELD_REFs with INTEGRAL_TYPE_P first operand
to have mode precision. In most cases for the large/huge _BitInt bitfield
stores the code uses bitfield representatives, which are typically arrays
of chars, but if the bitfield starts at byte boundary on big endian,
the code uses as nlhs in lower_mergeable_store COMPONENT_REF of the
bitfield FIELD_DECL instead, which is fine for the limb accesses,
but when used for the most significant limb can result in invalid
BIT_FIELD_REF because the first operand then has BITINT_TYPE and
usually VOIDmode.
The following patch adds a helper method for the 4 creatikons of
BIT_FIELD_REF which when needed adds a VIEW_CONVERT_EXPR.
2024-03-16 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/114329
* gimple-lower-bitint.cc (struct bitint_large_huge): Declare
build_bit_field_ref method.
(bitint_large_huge::build_bit_field_ref): New method.
(bitint_large_huge::lower_mergeable_stmt): Use it.
Nathaniel Shead [Tue, 12 Mar 2024 12:24:27 +0000 (23:24 +1100)]
c++: Check module attachment instead of just purview when necessary [PR112631]
Block-scope declarations of functions or extern values are not allowed
when attached to a named module. Similarly, class member functions are
not inline if attached to a named module. However, in both these cases
we currently only check if the declaration is within the module purview;
it is possible for such a declaration to occur within the module purview
but not be attached to a named module (e.g. in an 'extern "C++"' block).
This patch makes the required adjustments.
PR c++/112631
gcc/cp/ChangeLog:
* cp-tree.h (named_module_attach_p): New function.
* decl.cc (start_decl): Check for attachment not purview.
(grokmethod): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/modules/block-decl-1_a.C: New test.
* g++.dg/modules/block-decl-1_b.C: New test.
* g++.dg/modules/block-decl-2.C: New test.
Jakub Jelinek [Fri, 15 Mar 2024 18:04:33 +0000 (19:04 +0100)]
libgcc: Fix quotient and/or remainder negation in __divmodbitint4 [PR114327]
While for __mulbitint3 we actually don't negate anything and perform the
multiplication in unsigned style always, for __divmodbitint4 if the operands
aren't unsigned and are negative, we negate them first and then try to
negate them as needed at the end.
quotient is negated if just one of the operands was negated and the other
wasn't or vice versa, and remainder is negated if the first operand was
negated.
The case which doesn't work correctly is if due to limited range of the
operands we perform the division/modulo in some smaller number of limbs
and then extend it to the desired precision of the quotient and/or
remainder results. If they aren't negated, the extension is done with
memset to 0, if they are negated, the extension was done with memset
to -1. The problem is that if the quotient or remainder is zero,
then bitint_negate negates it again to zero (that is ok), but we should
then extend with memset to 0, not memset to -1.
The following patch achieves that by letting bitint_negate also check if
the negated operand is zero and changes the memset argument based on that.
2024-03-15 Jakub Jelinek <jakub@redhat.com>
PR libgcc/114327
* libgcc2.c (bitint_negate): Return UWtype bitwise or of all the limbs
before negation rather than void.
(__divmodbitint4): Determine whether to fill in the upper limbs after
negation based on whether bitint_negate returned 0 or non-zero, rather
then always filling with -1.
Jakub Jelinek [Fri, 15 Mar 2024 11:20:04 +0000 (12:20 +0100)]
lower-subreg, edit-context: Fix comment typos
When backporting r14-9315 to 13 branch, I've noticed I've missed
one letter in a comment. And grepping for similar issues I found
one word with too many.
Jakub Jelinek [Fri, 15 Mar 2024 09:46:47 +0000 (10:46 +0100)]
i386: Fix a pasto in ix86_expand_int_sse_cmp [PR114339]
In r13-3803-gfa271afb58 I've added an optimization for LE/LEU/GE/GEU
comparison against CONST_VECTOR. As the comments say:
/* x <= cst can be handled as x < cst + 1 unless there is
wrap around in cst + 1. */
...
/* For LE punt if some element is signed maximum. */
...
/* For LEU punt if some element is unsigned maximum. */
and
/* x >= cst can be handled as x > cst - 1 unless there is
wrap around in cst - 1. */
...
/* For GE punt if some element is signed minimum. */
...
/* For GEU punt if some element is zero. */
Apparently I wrote the GE/GEU (second case) first and then
copied/adjusted it for LE/LEU, most of the adjustments look correct, but
I've left if (code == GE) comparison when testing if it should punt for
signed maximum. That condition is never true, because this is in
switch (code) { ... case LE: case LEU: block and we really meant to
be what the comment says, for LE punt if some element is signed maximum,
as then cst + 1 wraps around.
The following patch fixes the pasto.
2024-03-15 Jakub Jelinek <jakub@redhat.com>
PR target/114339
* config/i386/i386-expand.cc (ix86_expand_int_sse_cmp) <case LE>: Fix
a pasto, compare code against LE rather than GE.
The x86-64 and aarch64 psABIs (and the unwritten ia64 psABI part) say that
the padding bits of _BitInt are undefined, while the expansion internally
typically assumes that non-mode precision integers are sign/zero extended
and extends after operations. We handle that mismatch with EXTEND_BITINT
done when reading from untrusted sources like function arguments, reading
_BitInt from memory etc. but otherwise keep relying on stuff being extended
internally (say in pseudos).
The return value of a function is an ABI boundary though too and we need
to extend that too.
2024-03-15 Jakub Jelinek <jakub@redhat.com>
PR middle-end/114332
* expr.cc (expand_expr_real_1): EXTEND_BITINT also CALL_EXPR results.
Jakub Jelinek [Fri, 15 Mar 2024 09:01:41 +0000 (10:01 +0100)]
testsuite: Fix up pr104601.C for recent libstdc++ changes
r14-9478 added [[nodiscard]] to various <algorithm> APIs including find_if
the pr104601.C testcase uses. As it is an optimization bug fix testcase,
haven't tried to adjust the testcase to use the find_if result, but instead
have added -Wno-unused-result flag to quiet the warning.
2024-03-15 Jakub Jelinek <jakub@redhat.com>
* g++.dg/torture/pr104601.C: Add -Wno-unused-result to dg-options.
Jakub Jelinek [Fri, 15 Mar 2024 08:16:43 +0000 (09:16 +0100)]
bitint: Fix up adjustment of large/huge _BitInt arguments of returns_twice calls [PR113466]
This patch (on top of the just posted gsi_safe_insert* fixes patch)
fixes the instrumentation of large/huge _BitInt SSA_NAME arguments of
returns_twice calls.
In this case it isn't just a matter of using gsi_safe_insert_before instead
of gsi_insert_before, we need to do more.
One thing is that unlike the asan/ubsan instrumentation which does just some
checking, here we want the statement before the call to load into a SSA_NAME
which is passed to the call. With another edge we need to add a PHI,
with one PHI argument the loaded SSA_NAME, another argument an uninitialized
warning free SSA_NAME and a result and arrange for all 3 SSA_NAMEs to be
preserved (i.e. stay as is, be no longer lowered afterwards).
Unfortunately, edge_before_returns_twice_call can create new SSA_NAMEs using
copy_ssa_name and while we can have a reasonable partition for them (same
partition as PHI result correspoding to the PHI argument newly added), adding
SSA_NAMEs into a partition after the partitions are finalized is too ugly.
So, this patch takes a different approach suggested by Richi, just emit
the argument loads before the returns_twice call normally (i.e. temporarily
create invalid IL) and just remember that we did that, and when the bitint
lowering is otherwise done fix this up, gsi_remove those statements,
gsi_safe_insert_before and and create the needed new PHIs.
2024-03-15 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113466
* gimple-lower-bitint.cc (bitint_large_huge): Add m_returns_twice_calls
member.
(bitint_large_huge::bitint_large_huge): Initialize it.
(bitint_large_huge::~bitint_large_huge): Release it.
(bitint_large_huge::lower_call): Remember ECF_RETURNS_TWICE call stmts
before which at least one statement has been inserted.
(gimple_lower_bitint): Move argument loads before ECF_RETURNS_TWICE
calls to a different block and add corresponding PHIs.
Paul Thomas [Fri, 15 Mar 2024 06:52:59 +0000 (06:52 +0000)]
Fortran: Fix class/derived/complex function associate selectors [PR87477]
2024-03-15 Paul Thomas <pault@gcc.gnu.org>
gcc/fortran
PR fortran/87477
PR fortran/89645
PR fortran/99065
PR fortran/114141
PR fortran/114280
* class.cc (gfc_change_class): New function needed for
associate names, when rank changes or a derived type is
produced by resolution
* dump-parse-tree.cc (show_code_node): Make output for SELECT
TYPE more comprehensible.
* expr.cc (find_inquiry_ref): Do not simplify expressions of
an inferred type.
* gfortran.h : Add 'gfc_association_list' to structure
'gfc_association_list'. Add prototypes for
'gfc_find_derived_types', 'gfc_fixup_inferred_type_refs' and
'gfc_change_class'. Add macro IS_INFERRED_TYPE.
* match.cc (copy_ts_from_selector_to_associate): Add bolean arg
'select_type' with default false. If this is a select type name
and the selector is a inferred type, build the class type and
apply it to the associate name.
(build_associate_name): Pass true to 'select_type' in call to
previous.
* parse.cc (parse_associate): If the selector is inferred type
the associate name is too. Make sure that function selector
class and rank, if known, are passed to the associate name. If
a function result exists, pass its typespec to the associate
name.
* primary.cc (resolvable_fcns): New function to check that all
the function references are resolvable.
(gfc_match_varspec): If a scalar derived type select type
temporary has an array reference, match the array reference,
treating this in the same way as an equivalence member. Do not
set 'inquiry' if applied to an unknown type the inquiry name
is ambiguous with the component of an accessible derived type.
Check that resolution of the target expression is OK by testing
if the symbol is declared or is an operator expression, then
using 'resolvable_fcns' recursively. If all is well, resolve
the expression. If this is an inferred type with a component
reference, call 'gfc_find_derived_types' to find a suitable
derived type. If there is an inquiry ref and the symbol either
is of unknown type or is inferred to be a derived type, set the
primary and symbol TKR appropriately.
* resolve.cc (resolve_variable): Call new function below.
(gfc_fixup_inferred_type_refs): New function to ensure that the
expression references for a inferred type are consistent with
the now fixed up selector.
(resolve_assoc_var): Ensure that derived type or class function
selectors transmit the correct arrayspec to the associate name.
(resolve_select_type): If the selector is an associate name of
inferred type and has no component references, the associate
name should have its typespec. Simplify the conversion of a
class array to class scalar by calling 'gfc_change_class'.
Make sure that a class, inferred type selector with an array
ref transfers the typespec from the symbol to the expression.
* symbol.cc (gfc_set_default_type): If an associate name with
unknown type has a selector expression, try resolving the expr.
(find_derived_types, gfc_find_derived_types): New functions
that search for a derived type with a given name.
* trans-expr.cc (gfc_conv_variable): Some inferred type exprs
escape resolution so call 'gfc_fixup_inferred_type_refs'.
* trans-stmt.cc (trans_associate_var): Tidy up expression for
'class_target'. Finalize and free class function results.
Correctly handle selectors that are class functions and class
array references, passed as derived types.
gcc/testsuite/
PR fortran/87477
PR fortran/89645
PR fortran/99065
* gfortran.dg/associate_64.f90 : New test
* gfortran.dg/associate_66.f90 : New test
* gfortran.dg/associate_67.f90 : New test
PR fortran/114141
* gfortran.dg/associate_65.f90 : New test
PR fortran/114280
* gfortran.dg/associate_68.f90 : New test
YunQiang Su [Fri, 15 Mar 2024 06:33:58 +0000 (14:33 +0800)]
MIPS: Add -m(no-)strict-align option
We support options -m(no-)unaligned-access 2 years ago, while
currently most of other ports prefer -m(no-)strict-align.
Let's support -m(no-)strict-align, and keep -m(no-)unaligned-access
as alias.
gcc
* config/mips/mips.opt: Support -mstrict-align, and use
TARGET_STRICT_ALIGN as the flag; keep -m(no-)unaligned-access
as alias.
* config/mips/mips.h: Use TARGET_STRICT_ALIGN.
* config/mips/mips.opt.urls: Regenerate.
* doc/invoke.texi: Document -m(no-)strict-algin for MIPSr6.
Tejas Belagod [Wed, 6 Mar 2024 10:00:26 +0000 (15:30 +0530)]
vect: Call vect_convert_output with the right vecitype [PR114108]
This patch fixes a bug where vect_recog_abd_pattern called vect_convert_output
with the incorrect vecitype for the corresponding pattern_stmt.
vect_convert_output expects vecitype to be the vector form of the scalar type
of the LHS of pattern_stmt, but we were passing in the vector form of the LHS
of the new impending conversion statement. This caused a skew in ABD's
pattern_stmt having the vectype of the following gimple pattern_stmt.
2024-03-06 Tejas Belagod <tejas.belagod@arm.com>
gcc/ChangeLog:
PR middle-end/114108
* tree-vect-patterns.cc (vect_recog_abd_pattern): Call
vect_convert_output with the correct vecitype.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/pr114108.c: New test.
Chenghui Pan [Thu, 14 Mar 2024 01:26:54 +0000 (09:26 +0800)]
LoongArch: Remove masking process for operand 3 of xvpermi.q.
The behavior of non-zero unused bits in xvpermi.q instruction's
third operand is undefined on LoongArch, according to our
discussion (https://github.com/llvm/llvm-project/pull/83540),
we think that keeping original insn operand as unmodified
state is better solution.
Jason Merrill [Thu, 22 Feb 2024 10:06:27 +0000 (10:06 +0000)]
tree-core: clarify clobber comments
It came up on the mailing list that OBJECT_BEGIN/END are described as
marking object lifetime, but mark the beginning of the constructor and end
of the destructor, whereas the C++ notion of lifetime is between the end of
the constructor and beginning of the destructor. So let's fix the comments.
Gaius Mulley [Thu, 14 Mar 2024 19:09:34 +0000 (19:09 +0000)]
PR modula2/114294 expression causes ICE
This patch fixes an ICE when encountering an expression:
1 + HIGH (a[0]). The fix was to assign a type to the constant
created by BuildConstHighFromSym in M2Quads.mod.
gcc/m2/ChangeLog:
PR modula2/114294
* gm2-compiler/M2Quads.mod (BuildConstHighFromSym):
Call PutConst to assign the type Cardinal in the result
constant.
gcc/testsuite/ChangeLog:
PR modula2/114294
* gm2/pim/pass/log: Removed.
* gm2/pim/pass/highexp.mod: New test.
When generating PA 1.x code or code for GNU ld, floating-point
accesses only support 5-bit displacements but integer accesses
support 14-bit displacements. I mistakenly assumed reload
could fix an invalid 14-bit displacement in a floating-point
access but this is not the case.
2024-03-14 John David Anglin <danglin@gcc.gnu.org>
gcc/ChangeLog:
PR target/114288
* config/pa/pa.cc (pa_legitimate_address_p): Don't allow
14-bit displacements before reload for modes that may use
a floating-point load or store.
David Faust [Thu, 14 Mar 2024 16:05:38 +0000 (09:05 -0700)]
bpf: define INT8_TYPE as signed char
Change the BPF backend to define INT8_TYPE with an explicit sign, rather
than a plain char. This is in line with other targets and removes the
risk of int8_t being affected by the signedness of the plain char type
of the host system.
The motivation for this change is that even if `char' is defined to be
signed in BPF targets, some BPF programs use the (mal)practice of
including internal libc headers, either directly or indirectly via
kernel headers, which in turn may trigger compilation errors regarding
redefinitions of types.
gcc/
* config/bpf/bpf.h (INT8_TYPE): Change to signed char.
Max Filippov [Thu, 14 Mar 2024 11:20:36 +0000 (04:20 -0700)]
gcc: xtensa: reorder movsi_internal patterns for better code generation during LRA
After switching to LRA xtensa backend generates the following code for
saving/loading registers:
movi a9, 0x190
add a9, a9, sp
s32i.n a3, a9, 0
instead of the shorter and more efficient
s32i a3, a9, 0x190
E.g. the following code can be used to reproduce it:
int f1(int a, int b, int c, int d, int e, int f, int *p);
int f2(int a, int b, int c, int d, int e, int f, int *p);
int f3(int a, int b, int c, int d, int e, int f, int *p);
int foo(int a, int b, int c, int d, int e, int f)
{
int g[100];
return
f1(a, b, c, d, e, f, g) +
f2(a, b, c, d, e, f, g) +
f3(a, b, c, d, e, f, g);
}
This happens in the LRA pass because s32i.n and l32i.n are listed before
the s32i and l32i in the movsi_internal pattern and alternative
consideration loop stops early.
gcc/
* config/xtensa/xtensa.md (movsi_internal): Move l32i and s32i
patterns ahead of the l32i.n and s32i.n.
git://gcc.gnu.org / gcc.git / log