The following testcase ICEs because loop invariant motion moves asm goto
with a single output as invariant.
Normally, jumps aren't really moved, because if they are single set,
they have their SET_DEST (pc) and pc_rtx has VOIDmode on which one of the
functions find_invariant_insn calls bails out. The code already punts on
insns that can throw or trap. And for asm goto without outputs, it isn't
single set, or asm goto with two or more outputs it isn't single set either.
2020-12-01 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/97954
* loop-invariant.c (find_invariant_insn): Punt on JUMP_P insns.
* gcc.dg/pr97954.c: New test.
The current configuration test for LEB128 support in the assembler is
(a) specific to GNU assemblers and (b) only checks that the directives
are accepted, not that they give correct output.
The patch extends the asm test to cover one failure case present in
assemblers based off an older version of GAS (where a 64 bit value with
the MSB set presented to a .uleb128 directive causes a fail).
The test is now generalized such that it does not make use of any
specific test for assembler source/version, but checks that the output
is as expected. We cater for scanning the object with objdump (either
binutils or LLVM) or Darwin otool.
gcc/ChangeLog:
* configure.ac (check leb128 support): Check that assemblers both
accept the LEB128 directives and also give the expected output.
Add a test for uleb128 with the MSB set for a 64 bit value.
* configure: Regenerated.
This fixes a regression affecting the Intel compiler. Because that
compiler defines __GNUC__ to match whatever version of GCC it finds on
the host system, it might claim to be a brand new GCC despite not
actually supporting all the built-ins that the latest GCC supports. This
means the config checks for __GNUC__ don't work. Most recently this
broke when r11-3569-g73ae6eb572515ad627b575a7fbdfdd47a4368e1c switched
us from using __is_same_as to __is_same when __GNUC__ >= 11.
Because __has_builtin is supported by all of GCC, Clang, and Intel we can
use that to reliably detect whether a given built-in is supported,
instead of hardcoding anything based on __GNUC__. The big caveat is
that for versions of Clang <= 9.0.0 and for (as far as I can tell) all
released versions of Intel icc, __has_builtin only evaluates to true for
built-ins with a name starting "__builtin_". For __is_aggregate,
__is_same, and __has_unique_object_representations it's necessary to use
__is_identifier to check if it's a valid identifeir token instead.
The solution used in this patch is to define _GLIBCXX_HAS_BUILTIN and
use that instead of using __has_builtin directly. For compilers that
define __is_identifier as well as __has_builtin we use both, so that if
__has_builtin evaluates to false we try again using !__is_identifier.
libstdc++-v3/ChangeLog:
* include/bits/c++config (_GLIBCXX_HAS_BUILTIN): Define macro to
work around different implementations of __has_builtin.
(_GLIBCXX_HAVE_BUILTIN_HAS_UNIQ_OBJ_REP)
(_GLIBCXX_HAVE_BUILTIN_IS_AGGREGATE)
(_GLIBCXX_HAVE_BUILTIN_IS_CONSTANT_EVALUATED)
(_GLIBCXX_HAVE_BUILTIN_IS_SAME, _GLIBCXX_HAVE_BUILTIN_LAUNDER):
Define using _GLIBCXX_HAS_BUILTIN.
This test should ensure that we can compile with hwasan, that such a compiled
binary runs as expected, *and* that we're running on a kernel which implements
the capability to ignore the top bytes of pointers in syscalls.
It was expected that a basic test of `int main(void) { return 0; }` would check
this, since there is a check called during `__hwasan_init` in libhwasan to
ensure that the kernel we're running on provides a `prctl` to request the
relaxed ABI.
Unfortunately, the check in libhwasan has a bug in it, and does not correctly
fail when the kernel feature is not around. This means that check is not
automatically provided by the runtime.
The sanitizer runtime will be fixed but would like to install this fix here in
case fixing the library is not quick enough for the release (and so that people
running the testsuite do not see spurious errors in the meantime).
Tested by running testsuite on an AArch64 machine with and without the required
kernel.
Observed that the test does indeed fail when the kernel feature is unavailable
and pass when the feature is available.
Note that this test is directly targetting AArch64 by using `prctl` numbers
specific to it. That's unfortunate, but once the runtime fix has gone in we
will be able to remove that requirement.
Ok for trunk?
gcc/testsuite/ChangeLog:
* lib/hwasan-dg.exp (check_effective_target_hwaddress_exec): Fix
check for correct kernel version.
This removes the reference to Objective-C++ for the warning that
attributes may not be placed before linkage specifications. It also
adds a note that they may be placed after that.
gcc/cp/ChangeLog:
* parser.c (cp_parser_declaration): Add a not about where
attributes may be placed.
This is the same as dcd2ca63ec ("Introduce can_vcond_compare_p
function"), but for vec_cmp. The reason it's needed is that since
5d9ade39b8 ("IBM Z: Fix PR97326: Enable fp compares in vec_cmp")
and 4acba48590 ("IBM Z: Restrict vec_cmp<m><n> on z13") s390's vec_cmp
expander advertises that it supports floating point comparisons except
signaling ones on z13, but the common code ignores the latter
restriction.
gcc/ChangeLog:
2020-11-25 Ilya Leoshkevich <iii@linux.ibm.com>
* optabs-tree.c (vec_cmp_icode_p): New function.
(vec_cmp_eq_icode_p): New function.
(expand_vec_cmp_expr_p): Use vec_cmp_icode_p and
vec_cmp_eq_icode_p.
(vcond_icode_p): Use get_rtx_code_1, just to be uniform with
vec_cmp_icode_p.
* optabs.c (unsigned_optab_p): New function.
(insn_predicate_matches_p): New function.
(can_vec_cmp_compare_p): New function.
(can_vcond_compare_p): Use unsigned_optab_p and
insn_predicate_matches_p.
(get_rtx_code): Use get_rtx_code_1.
(get_rtx_code_1): Version of get_rtx_code that returns UNKNOWN
instead of asserting.
* optabs.h (can_vec_cmp_compare_p): New function.
(get_rtx_code_1): New function.
gcc/ChangeLog:
PR tree-optimization/14799
PR ipa/88702
* Makefile.in: Add gimple-if-to-switch.o.
* dbgcnt.def (DEBUG_COUNTER): Add new debug counter.
* passes.def: Include new pass_if_to_switch pass.
* timevar.def (TV_TREE_IF_TO_SWITCH): New timevar.
* tree-pass.h (make_pass_if_to_switch): New.
* tree-ssa-reassoc.c (struct operand_entry): Move to the header.
(dump_range_entry): Move to header file.
(debug_range_entry): Likewise.
(no_side_effect_bb): Make it global.
* tree-switch-conversion.h (simple_cluster::simple_cluster):
Add inline for couple of functions in order to prevent error
about multiple defined symbols.
* gimple-if-to-switch.cc: New file.
* tree-ssa-reassoc.h: New file.
gcc/testsuite/ChangeLog:
PR tree-optimization/14799
PR ipa/88702
* gcc.dg/tree-ssa/pr96480.c: Disable if-to-switch conversion.
* gcc.dg/tree-ssa/reassoc-32.c: Likewise.
* g++.dg/tree-ssa/if-to-switch-1.C: New test.
* gcc.dg/tree-ssa/if-to-switch-1.c: New test.
* gcc.dg/tree-ssa/if-to-switch-2.c: New test.
* gcc.dg/tree-ssa/if-to-switch-3.c: New test.
* gcc.dg/tree-ssa/if-to-switch-4.c: New test.
* gcc.dg/tree-ssa/if-to-switch-5.c: New test.
* gcc.dg/tree-ssa/if-to-switch-6.c: New test.
* gcc.dg/tree-ssa/if-to-switch-7.c: New test.
* gcc.dg/tree-ssa/if-to-switch-8.c: New test.
Add two test cases that check for acceptable combinations of float_t and
FLT_EVAL_METHOD on s390x.
Tested against an as-is glibc and one modified so that it derives
float_t from FLT_EVAL_METHOD.
gcc/testsuite/ChangeLog:
2020-12-01 Marius Hillenbrand <mhillen@linux.ibm.com>
* gcc.target/s390/float_t-1.c: New test.
* gcc.target/s390/float_t-2.c: New test.
Historically, float_t has been defined as double on s390 and gcc would
emit double precision insns for evaluating float expressions when in
standard-compliant mode. Configure that behavior at compile-time as prep
for changes in glibc: When glibc ties float_t to double, keep the old
behavior; when glibc derives float_t from FLT_EVAL_METHOD (as on most
other archs), revert to the default behavior (i.e.,
FLT_EVAL_METHOD_PROMOTE_TO_FLOAT). Provide a configure option
--enable-s390-excess-float-precision to override the check.
gcc/ChangeLog:
2020-12-01 Marius Hillenbrand <mhillen@linux.ibm.com>
* configure.ac: Add configure option
--enable-s390-excess-float-precision and check to derive default
from glibc.
* config/s390/s390.c: Guard s390_excess_precision with an ifdef
for ENABLE_S390_EXCESS_FLOAT_PRECISION.
* doc/install.texi: Document --enable-s390-excess-float-precision.
* configure: Regenerate.
* config.in: Regenerate.
I noticed the test-case contains LIT annotation and
it is possible to reduce. I did that with compiler that
was affected by the PR.
gcc/testsuite/ChangeLog:
* g++.dg/torture/pr93347.C: Reduce and remove LIT keywords.
As mentioned in the PR, since 4656461585 implicit_section
was not set to false when set_section was called with the argument
equal to NULL.
gcc/ChangeLog:
PR ipa/98057
* symtab.c (symtab_node::set_section_for_node): Drop
implicit_section if x_section is NULL.
gcc/testsuite/ChangeLog:
PR ipa/98057
* g++.dg/ipa/pr98057.C: New test.
On the following testcase with -fpic -mcmodel=large -fno-plt we emit
call puts@GOTPCREL(%rip)
but that is not really appropriate for CM_LARGE_PIC, the .text can be larger
than 2GB in that case and the .got slot further away from %rip than what can
fit into the signed 32-bit immediate.
The following patch computes the address of the .got slot the way it is
computed for that model for function pointer loads, and calls that.
2020-12-01 Jakub Jelinek <jakub@redhat.com>
PR target/98063
* config/i386/i386-expand.c (ix86_expand_call): Handle non-plt
CM_LARGE_PIC calls.
* gcc.target/i386/pr98063.c: New test.
I have noticed that while we use DW_LANG_C_plus_plus_14 for -std=c++17 -gdwarf-5,
we use DW_LANG_C_plus_plus (aka C++98) for -std=c++20 -gdwarf-5. The
following patch makes those two match.
2020-12-01 Jakub Jelinek <jakub@redhat.com>
* dwarf2out.c (gen_compile_unit_die): Treat GNU C++20
like C++14 for -gdwarf-5.
* g++.dg/debug/dwarf2/lang-cpp17.C: New test.
* g++.dg/debug/dwarf2/lang-cpp20.C: New test.
The driver enables -dD when preprocessing when -g3 is specified, for obvious reasons
that we need the macros to be preserved somewhere for them to make up the debug
info. But it enables it even if -g3 is later overridden to -g2, -g1 or -g0,
where we in the end don't emit .debug_mac{ros,info}.
The following patch passes -dD only if we'll need it.
2020-12-01 Jakub Jelinek <jakub@redhat.com>
PR debug/97989
* gcc.c (cpp_unique_options): Add -dD if %:debug-level-gt(2)
rather than g3|ggdb3|gstabs3|gxcoff3|gvms3.
* gcc.dg/cpp/pr97989-1.c: New test.
* gcc.dg/cpp/pr97989-2.c: New test.
I broke the build with --disable-analyzer with
g:66dde7bc64b75d4a338266333c9c490b12d49825, due to:
../../src/gcc/analyzer/analyzer-pass.cc: In member function ‘virtual unsigned int {anonymous}::pass_analyzer::execute(function*)’:
../../src/gcc/analyzer/analyzer-pass.cc:86:3: error: ‘sorry_no_analyzer’ was not declared in this scope
86 | sorry_no_analyzer ();
| ^~~~~~~~~~~~~~~~~
Fixed by including the relevant header file.
Sorry about the breakage.
gcc/analyzer/ChangeLog:
* analyzer-pass.cc: Include "analyzer/analyzer.h" for the
declaration of sorry_no_analyzer; include "tree.h" and
"function.h" as these are needed by it.
The overflow checks done in growslice always reported an error for the
capacity argument, even if it was the length argument that overflowed.
This change lets the code pass the current issue4085b.go test.
Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/273806
This patch adds a new GCC plugin event: PLUGIN_ANALYZER_INIT, called
when -fanalyzer is starting, allowing for GCC plugins to register
additional state-machine-based checks within -fanalyzer. The idea
is that 3rd-party code might want to add domain-specific checks for
its own APIs - with the caveat that the analyzer is itself still
rather experimental.
As an example, the patch adds a proof-of-concept plugin to the testsuite
for checking CPython code: verifying that code that relinquishes
CPython's global interpreter lock doesn't attempt to do anything with
PyObjects in the sections where the lock isn't held. It also adds a
warning about nested releases of the lock, which is forbidden.
For example:
demo.c: In function 'foo':
demo.c:11:3: warning: use of PyObject '*(obj)' without the GIL
11 | Py_INCREF (obj);
| ^~~~~~~~~
'test': events 1-3
|
| 15 | void test (PyObject *obj)
| | ^~~~
| | |
| | (1) entry to 'test'
| 16 | {
| 17 | Py_BEGIN_ALLOW_THREADS
| | ~~~~~~~~~~~~~~~~~~~~~~
| | |
| | (2) releasing the GIL here
| 18 | foo (obj);
| | ~~~~~~~~~
| | |
| | (3) calling 'foo' from 'test'
|
+--> 'foo': events 4-5
|
| 9 | foo (PyObject *obj)
| | ^~~
| | |
| | (4) entry to 'foo'
| 10 | {
| 11 | Py_INCREF (obj);
| | ~~~~~~~~~
| | |
| | (5) PyObject '*(obj)' used here without the GIL
|
Doing so requires adding some logic for ignoring macro expansions in
analyzer diagnostics, since the insides of Py_INCREF and
Py_BEGIN_ALLOW_THREADS are not of interest to the user for these cases.
gcc/analyzer/ChangeLog:
* analyzer-pass.cc (pass_analyzer::execute): Move sorry call to...
(sorry_no_analyzer): New.
* analyzer.h (class state_machine): New forward decl.
(class logger): New forward decl.
(class plugin_analyzer_init_iface): New.
(sorry_no_analyzer): New decl.
* checker-path.cc (checker_path::fixup_locations): New.
* checker-path.h (checker_event::set_location): New.
(checker_path::fixup_locations): New decl.
* diagnostic-manager.cc
(diagnostic_manager::emit_saved_diagnostic): Call
checker_path::fixup_locations, and call fixup_location
on the primary location.
* engine.cc: Include "plugin.h".
(class plugin_analyzer_init_impl): New.
(impl_run_checkers): Invoke PLUGIN_ANALYZER_INIT callbacks.
* pending-diagnostic.h (pending_diagnostic::fixup_location): New
vfunc.
gcc/ChangeLog:
* doc/plugins.texi (Plugin callbacks): Add PLUGIN_ANALYZER_INIT.
* plugin.c (register_callback): Likewise.
(invoke_plugin_callbacks_full): Likewise.
* plugin.def (PLUGIN_ANALYZER_INIT): New event.
gcc/testsuite/ChangeLog:
* gcc.dg/plugin/analyzer_gil_plugin.c: New test.
* gcc.dg/plugin/gil-1.c: New test.
* gcc.dg/plugin/gil.h: New header.
* gcc.dg/plugin/plugin.exp (plugin_test_list): Add the new plugin
and test.
When diffing test results, there sometimes occur spurious "New tests
that PASS" / "Old tests that passed, that have disappeared" messages.
The reason is that if create_gcov is not installed, then the cached
testname_with_flags is not cleared and is carried over to the next
test.
gcc/testsuite/ChangeLog:
2020-11-26 Ilya Leoshkevich <iii@linux.ibm.com>
* lib/profopt.exp: Unset testname_with_flags if create_gcov
fails.
dse.c:find_shift_sequence tries to represent a store and load
back as a shift right followed by a truncation. It therefore
needs to find an integer mode in which to do the shift right.
The loop it uses has the form:
FOR_EACH_MODE_FROM (new_mode_iter,
smallest_int_mode_for_size (GET_MODE_BITSIZE (read_mode)))
which implicitly assumes that read_mode has an equivalent integer mode.
As shown in the testcase, not all modes have such an integer mode.
This patch just makes the code start from the smallest integer mode and
skip modes that are too small. The loop already breaks at the first
mode wider than word_mode.
gcc/
PR rtl-optimization/98037
* dse.c (find_shift_sequence): Iterate over all integers and
skip modes that are too small.
gcc/testsuite/
PR rtl-optimization/98037
* gcc.target/aarch64/sve/acle/general/pr98037.c: New test.
contrib/ChangeLog:
* gcc-changelog/git_commit.py: Suggest close file for
'unchanged file mentioned in a ChangeLog' error.
* gcc-changelog/test_email.py: Test it.
This doesn't actually have any effect unless you also change the
predefined value of __cplusplus, as it's currently 201703L. But if
somebody does want to do that, the new headers will get processed now.
libstdc++-v3/ChangeLog:
* doc/doxygen/user.cfg.in (INPUT): Add <latch> and <semaphore>.
The current default of 10 minutes is much longer than most tests need on
common hardware. The slow tests all now have a dg-timeout-factor
directive that gives them more time to run relative to the default. The
default can also be overridden in ~/.dejagnurc or DEJAGNU=site.exp, so
it seems unnecessary to have such a large default.
This reduces the default from 10 minutes to 6 minutes, which still seems
more than enough.
libstdc++-v3/ChangeLog:
* testsuite/lib/libstdc++.exp (libstdc++_init): Reduce
default tool_timeout to 360.
As in r11-5449, this adds a muliplier to the timeout for slow tests.
This covers the majority of the <regex> and PSTL tests.
libstdc++-v3/ChangeLog:
* testsuite/20_util/specialized_algorithms/pstl/*: Add
dg-timeout-factor.
* testsuite/25_algorithms/pstl/*: Likewise.
* testsuite/26_numerics/pstl/*: Likewise.
* testsuite/28_regex/*: Likewise.
gcc/fortran/ChangeLog:
PR fortran/98011
* scanner.c (skip_free_comments, skip_fixed_comments): If only
-fopenacc but not -fopenmp is used, ignore OpenMP's conditional
compilation sentinels. Fix indentation, use 'else if' for readability.
gcc/testsuite/ChangeLog:
PR fortran/98011
* gfortran.dg/goacc/sentinel-free-form.f95:
* gfortran.dg/goacc-gomp/fixed-1.f: New test.
* gfortran.dg/goacc-gomp/free-1.f90: New test.
* gfortran.dg/goacc/fixed-5.f: New test.
Options: -fopenmp and -fopenacc imply concurrent calls to a
procedure; now also -fopenacc implies -frecursive, disabling
that larger local const-size array variables use static memory.
Run-time recursion check: Always reset the check variable at the
end of the procedure; this avoids a bogus error with -fopenmp
when called twice nonconcurrently/nonrecursively. (Issue requires
using -fno-automatic or -fmax-stack-var-size= to trigger.)
gcc/fortran/ChangeLog:
PR fortran/98010
PR fortran/98013
* options.c (gfc_post_options): Also imply recursive with
-fopenacc.
* trans-decl.c (gfc_generate_function_code): Simplify condition.
gcc/ada/
* sem_ch5.adb (Set_Assignment_Type): Combine calls to Ekind
using membership test.
(Should_Transform_BIP_Assignment): Replace assignment to a
"Result" variable with simple return statements; avoid repeated
calls to Unqual_Conv by declaring a local constant.
