Fix a typo in __gthr_win32_abs_to_rel_time that caused it to return a
relative time in seconds instead of milliseconds. As a consequence,
__gthr_win32_cond_timedwait called SleepConditionVariableCS with a
1000x shorter timeout; this caused ~1000x more spurious wakeups in
CV timed waits such as std::condition_variable::wait_for or wait_until,
resulting generally in much higher CPU usage.
This can be demonstrated by this sample program:
```
int main() {
std::condition_variable cv;
std::mutex mx;
bool pass = false;
auto thread_fn = [&](bool timed) {
int wakeups = 0;
using sc = std::chrono::system_clock;
auto before = sc::now();
std::unique_lock<std::mutex> ml(mx);
if (timed) {
cv.wait_for(ml, std::chrono::seconds(2), [&]{
++wakeups;
return pass;
});
} else {
cv.wait(ml, [&]{
++wakeups;
return pass;
});
}
printf("pass: %d; wakeups: %d; elapsed: %d ms\n", pass, wakeups,
int((sc::now() - before) / std::chrono::milliseconds(1)));
pass = false;
};
{
// timed wait, let expire
std::thread t(thread_fn, true);
t.join();
}
{
// timed wait, wake up explicitly after 1 second
std::thread t(thread_fn, true);
std::this_thread::sleep_for(std::chrono::seconds(1));
{
std::unique_lock<std::mutex> ml(mx);
pass = true;
}
cv.notify_all();
t.join();
}
{
// non-timed wait, wake up explicitly after 1 second
std::thread t(thread_fn, false);
std::this_thread::sleep_for(std::chrono::seconds(1));
{
std::unique_lock<std::mutex> ml(mx);
pass = true;
}
cv.notify_all();
t.join();
}
return 0;
}
```
On builds based on non-affected threading models (e.g. POSIX on Linux,
or winpthreads or MCF on Win32) the output is something like
```
pass: 0; wakeups: 2; elapsed: 2000 ms
pass: 1; wakeups: 2; elapsed: 991 ms
pass: 1; wakeups: 2; elapsed: 996 ms
```
while with the Win32 threading model we get
```
pass: 0; wakeups: 1418; elapsed: 2000 ms
pass: 1; wakeups: 479; elapsed: 988 ms
pass: 1; wakeups: 2; elapsed: 992 ms
```
(notice the huge number of wakeups in the timed wait cases only).
This commit fixes the conversion, adjusting the final division by
NSEC100_PER_SEC to use NSEC100_PER_MSEC instead (already defined in the
file and not used in any other place, so probably just a typo).
libgcc/ChangeLog:
PR libgcc/113850
* config/i386/gthr-win32-cond.c (__gthr_win32_abs_to_rel_time):
fix absolute timespec to relative milliseconds count
conversion (it incorrectly returned seconds instead of
milliseconds); this avoids spurious wakeups in
__gthr_win32_cond_timedwait
As noticed by Marek Polacek in https://gcc.gnu.org/pipermail/gcc-patches/2024-February/645836.html,
this testcase was not failing before without -Wstrict-aliasing so let's add that option.
Committed as obvious after testing to make sure the test is now testing with `-Wstrict-aliasing` and `-flto`.
gcc/testsuite/ChangeLog:
* g++.dg/torture/vector-struct-1.C: Add -Wstrict-aliasing.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
I noticed we don't implement the "unless the overriding function is
defined as deleted" wording added to [except.spec] via CWG 1351.
DR 1351
gcc/cp/ChangeLog:
* search.cc (maybe_check_overriding_exception_spec): Don't error about
a looser exception specification if the overrider is deleted.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/noexcept82.C: New test.
This testcase was fixed by r14-5934-gf26d68d5d128c8 but we should add
one to make sure it does not regress again.
Committed as obvious after a quick test on the testcase.
PR c++/97990
gcc/testsuite/ChangeLog:
* g++.dg/torture/vector-struct-1.C: New test.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
There is currently no support for matching at least x lines of assembly
(only scan-assembler-times). This patch would allow setting upper or lower
bounds.
Use case: using different scheduler descriptions and/or cost models will change
assembler output. Testing common functionality across tunes would require a
separate testcase per tune since each assembly output would be different. If we
know a base number of lines should appear across all tunes (i.e. testing return
values: we expect at minimum n stores into register x), we can lower-bound the
test to search for scan-assembler-bound {RE for storing into register x} >= n.
This avoids artificially inflating the scan-assembler-times expected count due
to the assembler choosing to perform extra stores into register x (using it as
a temporary register).
The testcase would be more robust to cpu/tune changes at the cost of not being
as granular towards specific cpu tuning.
gcc/ChangeLog:
* doc/sourcebuild.texi: add scan-assembler-bound
gcc/testsuite/ChangeLog:
* lib/scanasm.exp: add scan-assembler-bound
Signed-off-by: Edwin Lu <ewlu@rivosinc.com>
Here we have
template<class T>
auto is_throwable(T t) -> decltype(throw t, true) { ... }
where we didn't properly mark 't' as IMPLICIT_RVALUE_P, which caused
the wrong overload to have been chosen. Jason figured out it's because
we don't correctly implement [expr.prim.id.unqual]#4.2, which post-P2266
says that an id-expression is move-eligible if
"the id-expression (possibly parenthesized) is the operand of
a throw-expression, and names an implicitly movable entity that belongs
to a scope that does not contain the compound-statement of the innermost
lambda-expression, try-block, or function-try-block (if any) whose
compound-statement or ctor-initializer contains the throw-expression."
I worked out that it's trying to say that given
struct X {
X();
X(const X&);
X(X&&) = delete;
};
the following should fail: the scope of the throw is an sk_try, and it's
also x's scope S, and S "does not contain the compound-statement of the
*try-block" so x is move-eligible, so we move, so we fail.
void f ()
try {
X x;
throw x; // use of deleted function
} catch (...) {
}
Whereas here:
void g (X x)
try {
throw x;
} catch (...) {
}
the throw is again in an sk_try, but x's scope is an sk_function_parms
which *does* contain the {} of the *try-block, so x is not move-eligible,
so we don't move, so we use X(const X&), and the code is fine.
The current code also doesn't seem to handle
void h (X x) {
void z (decltype(throw x, true));
}
where there's no enclosing lambda or sk_try so we should move.
I'm not doing anything about lambdas because we shouldn't reach the
code at the end of the function: the DECL_HAS_VALUE_EXPR_P check
shouldn't let us go further.
PR c++/113789
PR c++/113853
gcc/cp/ChangeLog:
* typeck.cc (treat_lvalue_as_rvalue_p): Update code to better
reflect [expr.prim.id.unqual]#4.2.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/sfinae69.C: Remove dg-bogus.
* g++.dg/cpp0x/sfinae70.C: New test.
* g++.dg/cpp0x/sfinae71.C: New test.
* g++.dg/cpp0x/sfinae72.C: New test.
* g++.dg/cpp2a/implicit-move4.C: New test.
For template parameters, the optional this specifier is in the grammar
template-parameter-list -> template-parameter -> parameter-declaration,
just [dcl.fct/6] says that it is only valid in parameter-list of certain
functions. So, unlike the case of decl-specifier-seq used in non-terminals
other than parameter-declaration, I think it is better not to fix this
by
cp_parser_decl_specifier_seq (parser,
- flags | CP_PARSER_FLAGS_PARAMETER,
+ flags | (template_parameter_p ? 0
+ : CP_PARSER_FLAGS_PARAMETER),
&decl_specifiers,
&declares_class_or_enum);
which would be pretending it isn't in the grammar, but by diagnosing it
separately, which is what the following patch does.
2024-02-16 Jakub Jelinek <jakub@redhat.com>
PR c++/113929
* parser.cc (cp_parser_parameter_declaration): Diagnose this specifier
on template parameter declaration.
* g++.dg/parse/pr113929.C: New test.
Recent python complains about this pattern with
SyntaxWarning: invalid escape sequence '\s'
because \s in a regular string just means 's'; for it to mean whitespace,
you need \\ or for the pattern to be a raw string.
Curiously, break-on-pass completion works for me either with or without this
change, but at least this avoids the warning.
gcc/ChangeLog:
* gdbhooks.py: Fix regex syntax.
c-c++-common/asan/swapcontext-test-1.c FAILs on Solaris/SPARC:
FAIL: c-c++-common/asan/swapcontext-test-1.c -O0 execution test
FAIL: c-c++-common/asan/swapcontext-test-1.c -O1 execution test
FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 execution test
FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 -flto execution test
FAIL: c-c++-common/asan/swapcontext-test-1.c -O2 -flto -flto-partition=none
execution test
FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -fomit-frame-pointer
-funroll-loops -fpeel-loops -ftracer -finline-functions execution test
FAIL: c-c++-common/asan/swapcontext-test-1.c -O3 -g execution test
FAIL: c-c++-common/asan/swapcontext-test-1.c -Os execution test
As detailed in PR sanitizer/113785, this happens because an ABI change
in Solaris 10/SPARC caused the external symbol for makecontext to be
changed to __makecontext_v2, which isn't intercepted.
The following patch, submitted upstream at
https://github.com/llvm/llvm-project/pull/81588, fixes that.
Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11.
2024-02-16 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
libsanitizer:
PR sanitizer/113785
* asan/asan_interceptors.cpp: Cherry-pick llvm-project revision
8c2033719a843a1880427a5e8caa5563248bce78.
The following addresses consistency check fails in copy_reference_ops_from_ref
when we are handling out-of-bound array accesses (it's almost impossible
to identically mimic the get_ref_base_and_extent behavior). It also
addresses the case where an out-of-bound constant offset computes to a
-1 off which is the special value for "unknown". This patch basically
turns off verification in those cases.
PR tree-optimization/113895
* tree-ssa-sccvn.cc (copy_reference_ops_from_ref): Disable
consistency checking when there are out-of-bound array
accesses. Allow -1 off when from an array reference with
constant index.
* gcc.dg/torture/pr113895-2.c: New testcase.
* gcc.dg/torture/pr113895-3.c: Likewise.
* gcc.dg/torture/pr113895-4.c: Likewise.
The configure option is no longer necessary.
libstdc++-v3/ChangeLog:
* doc/xml/manual/debug_mode.xml: Update docs for backtraces.
* doc/html/manual/debug_mode_using.html: Regenerate.
*sge<u>_<X:mode><GPR:mode> pattern has referenced operand[2] which is
invalid...it should just use `slti<u>` rather than `slti%i2<u>`.
gcc/ChangeLog:
PR target/106543
* config/riscv/riscv.md (*sge<u>_<X:mode><GPR:mode>): Fix asm
pattern.
gcc.dg/lto/modref-3 etc. FAIL on Solaris with the native linker:
FAIL: gcc-dg-lto-modref-3-01.exe scan-wpa-ipa-dump modref "parm 1 flags: no_direct_clobber no_direct_escape"
FAIL: gcc-dg-lto-modref-4-01.exe scan-wpa-ipa-dump modref "parm 1 flags: no_direct_clobber no_direct_escape"
FAIL: gcc.dg/lto/modref-3 c_lto_modref-3_0.o-c_lto_modref-3_1.o execute -O2 -flto-partition=max -fdump-ipa-modref -fno-ipa-sra -fno-ipa-cp -flto
FAIL: gcc.dg/lto/modref-4 c_lto_modref-4_0.o-c_lto_modref-4_1.o execute -O2 -flto-partition=max -fdump-ipa-modref -fno-ipa-sra -flto
The issue is that the tests require the linker plugin, which isn't
available with Solaris ld. Thus, it also FAILs when gcc is configured
with --disable-lto-plugin.
This patch thus declares the requirement. As it turns out, there's an
undocumented dg-require-linker-plugin already, but I introduce and use
the corresponding effective-target keyword and document both.
Given that the effective-target form is more flexible, I'm tempted to
remove dg-require-* with an empty arg as already mentioned in
sourcebuild.texi. That is not this patch, however.
Tested on i386-pc-solaris2.11 with ld and gld.
2024-02-14 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE>
gcc/testsuite:
PR ipa/98237
* lib/target-supports.exp (is-effective-target): Handle
linker_plugin.
* gcc.dg/lto/modref-3_0.c: Require linker_plugin support.
* gcc.dg/lto/modref-4_0.c: Likewise.
gcc:
* doc/sourcebuild.texi (Effective-Target Keywords, Other
attribugs): Document linker_plugin.
(Require Support): Document dg-require-linker-plugin.
The output of -march=help is like below:
```
All available -march extensions for RISC-V:
Name Version
i 2.0, 2.1
e 2.0
m 2.0
a 2.0, 2.1
f 2.0, 2.2
d 2.0, 2.2
...
```
Also support -print-supported-extensions and --print-supported-extensions for
clang compatibility.
gcc/ChangeLog:
PR target/109349
* common/config/riscv/riscv-common.cc (riscv_arch_help): New.
* config/riscv/riscv-protos.h (RISCV_MAJOR_VERSION_BASE): New.
(RISCV_MINOR_VERSION_BASE): Ditto.
(RISCV_REVISION_VERSION_BASE): Ditto.
* config/riscv/riscv-c.cc (riscv_ext_version_value): Use enum
rather than magic number.
* config/riscv/riscv.h (riscv_arch_help): New.
(EXTRA_SPEC_FUNCTIONS): Add riscv_arch_help.
(DRIVER_SELF_SPECS): Handle -march=help, -print-supported-extensions and
--print-supported-extensions.
* config/riscv/riscv.opt (march=help): New.
(print-supported-extensions): New.
(-print-supported-extensions): New.
* doc/invoke.texi (RISC-V Options): Document -march=help.
Reviewed-by: Christoph Müllner <christoph.muellner@vrull.eu>
This patch fixes a bug that causes indirect calls in PAC-enabled functions
to be tailcalled incorrectly when all argument registers R0-R3 are used.
2024-02-07 Tejas Belagod <tejas.belagod@arm.com>
PR target/113780
* config/arm/arm.cc (arm_function_ok_for_sibcall): Don't allow tailcalls
for indirect calls with 4 or more arguments in pac-enabled functions.
* lib/target-supports.exp (v8_1m_main_pacbti): Add __ARM_FEATURE_PAUTH.
* gcc.target/arm/pac-sibcall.c: New.
Support for indirect calls to procedures/functions in offloaded target
regions is now available for C, C++ and Fortran.
2024-02-15 Kwok Cheung Yeung <kcyeung@baylibre.com>
libgomp/
* libgomp.texi (OpenMP 5.1): Mark indirect call support as fully
implemented.
PR analyzer/111266 reports a missing -Wanalyzer-out-of-bounds when
accessing relative to a concrete byte offset.
Root cause is that offset_region::get_{byte,bit}_size_sval were
attempting to compute the size that's valid to access, rather than the
size of the access attempt.
Fixed by removing these vfunc overrides from offset_region as the
base class implementation does the right thing.
gcc/analyzer/ChangeLog:
PR analyzer/111266
* region.cc (offset_region::get_byte_size_sval): Delete.
(offset_region::get_bit_size_sval): Delete.
* region.h (region::get_byte_size): Add comment clarifying that
this relates to the size of the access, rather than the size
that's valid to access.
(region::get_bit_size): Likewise.
(region::get_byte_size_sval): Likewise.
(region::get_bit_size_sval): Likewise.
(offset_region::get_byte_size_sval): Delete.
(offset_region::get_bit_size_sval): Delete.
gcc/testsuite/ChangeLog:
PR analyzer/111266
* c-c++-common/analyzer/out-of-bounds-pr111266.c: New test.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
Old reload doesn't support asm goto with output operands.
We have lra effective target (though, strangely it returns
0 just for 2 targets out of at least 16 targets with no LRA support),
so this patch uses it, similarly how it is done in other asm goto
tests with output operands.
2024-02-15 Jakub Jelinek <jakub@redhat.com>
PR middle-end/107385
* gcc.dg/pr107385.c: Require lra effective target.
The testcase gcc.target/aarch64/vect_ctz_1.c fails execution when running
with -march=armv9-a due to the testcase calls __builtin_ctz with a value of 0.
The testcase should not depend on undefined behavior of __builtin_ctz. So this
changes it to use the g form with the 2nd argument of 32. Now the execution part
of the testcase work. It still has a scan-assembler failure which should be fixed
seperately.
Tested on aarch64-linux-gnu.
gcc/testsuite/ChangeLog:
* gcc.target/aarch64/vect_ctz_1.c (TEST): Use g form of the builtin and pass 32
as the value expected at 0.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
As the tests assume that fileno() is visible (only part of POSIX),
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/fileno-1.c, -std=c++98
.../fileno-1.c: In function 'int test_pass_through(FILE*)':
.../fileno-1.c:5:10: error: 'fileno' was not declared in this scope
FAIL: c-c++-common/analyzer/fileno-1.c -std=c++98 (test for excess errors)
Patch has been verified on Linux.
gcc/testsuite/ChangeLog:
PR testsuite/113278
* c-c++-common/analyzer/fileno-1.c: Define _POSIX_SOURCE.
* c-c++-common/analyzer/flex-with-call-summaries.c: Same.
* c-c++-common/analyzer/flex-without-call-summaries.c: Same.
Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
Commit 77d0f9ec38 inadvertently changed
the normal asm dialect instruction template for zero_extendqidi2 from
ldxb to ldxh. Fix that.
gcc/
* config/bpf/bpf.md (zero_extendqidi2): Correct asm template to
use ldxb instead of ldxh.
This testcase has been fixed by the PR113921 fix, but unlike testcase
in there this one is not target specific.
2024-02-15 Jakub Jelinek <jakub@redhat.com>
PR middle-end/107385
* gcc.dg/pr107385.c: New test.
The Linux kernel and the following testcase distilled from it is
miscompiled, because tree-outof-ssa.cc (eliminate_phi) emits some
fixups on some of the edges (but doesn't commit edge insertions).
Later expand_asm_stmt emits further instructions on the same edge.
Now the problem is that expand_asm_stmt uses insert_insn_on_edge
to add its own fixups, but that function appends to the existing
sequence on the edge if any. And the bug triggers when the
fixup sequence emitted by eliminate_phi uses a pseudo which the
fixup sequence emitted by expand_asm_stmt later on sets.
So, we end up with
(set (reg A) (asm_operands ...))
and on one of the edges queued sequence
(set (reg C) (reg B)) // added by eliminate_phi
(set (reg B) (reg A)) // added by expand_asm_stmt
That is wrong, what we emit by expand_asm_stmt needs to be as close
to the asm_operands as possible (they aren't known until expand_asm_stmt
is called, the PHI fixup code assumes it is reg B which holds the right
value) and the PHI adjustments need to be done after it.
So, the following patch introduces a prepend_insn_to_edge function and
uses it from expand_asm_stmt, so that we queue
(set (reg B) (reg A)) // added by expand_asm_stmt
(set (reg C) (reg B)) // added by eliminate_phi
instead and so the value from the asm_operands output propagates correctly
to the PHI result.
2024-02-15 Jakub Jelinek <jakub@redhat.com>
PR middle-end/113921
* cfgrtl.h (prepend_insn_to_edge): New declaration.
* cfgrtl.cc (insert_insn_on_edge): Clarify behavior in function
comment.
(prepend_insn_to_edge): New function.
* cfgexpand.cc (expand_asm_stmt): Use prepend_insn_to_edge instead of
insert_insn_on_edge.
* gcc.target/i386/pr113921.c: New test.
The following fixes the omission of failing to look at pattern
stmts when we need to dissolve SLP only groups.
PR tree-optimization/111156
* tree-vect-loop.cc (vect_dissolve_slp_only_groups): Look
at the pattern stmt if any.
This patch marks a rev16 test as XFAIL for architectures having only
Thumb1 support. The generated code is functionally correct, but the
optimization is disabled when -mthumb is equivalent to Thumb1. Fixing
the root issue would requires changes that are not suitable for GCC14
stage 4. More information at
https://linaro.atlassian.net/browse/GNU-1141
gcc/testsuite/ChangeLog:
* gcc.target/arm/rev16_2.c: XFAIL when compiled with Thumb1.
The -mmcu=avrtiny cores have no ADIW and SBIW instructions. This was
implemented by clearing all regs out of regclass ADDW_REGS so that
constraint "w" never matched. This corrupted the subset relations of
the register classes as they appear in enum reg_class.
This patch keeps ADDW_REGS like for all other cores, i.e. it contains
R24...R31. Instead of tests like test_hard_reg_class (ADDW_REGS, *)
the code now uses avr_adiw_reg_p (*). And all insns with constraint "w"
get "isa" insn attribute value of "adiw".
Plus, a new built-in macro __AVR_HAVE_ADIW__ is provided, which is more
specific than __AVR_TINY__.
gcc/
PR target/113927
* config/avr/avr.h (AVR_HAVE_ADIW): New macro.
* config/avr/avr-protos.h (avr_adiw_reg_p): New proto.
* config/avr/avr.cc (avr_adiw_reg_p): New function.
(avr_conditional_register_usage) [AVR_TINY]: Don't clear ADDW_REGS.
Replace test_hard_reg_class (ADDW_REGS, ...) with calls to
* config/avr/avr.md: Same.
(attr "isa") <tiny, no_tiny>: Remove.
<adiw, no_adiw>: Add.
(define_insn, define_insn_and_split): When an alternative has
constraint "w", then set attribute "isa" to "adiw".
* config/avr/avr-c.cc (avr_cpu_cpp_builtins) [AVR_HAVE_ADIW]:
Built-in define __AVR_HAVE_ADIW__.
* doc/invoke.texi (AVR Options): Document it.
The RDNA architecture has limited support for permute operations. This should
allow use of the permutations that do work, and fall back to linear code for
other cases.
gcc/ChangeLog:
* config/gcn/gcn-valu.md
(vec_extract<V_MOV:mode><V_MOV_ALT:mode>): Add conditions for RDNA.
* config/gcn/gcn.cc (gcn_vectorize_vec_perm_const): Check permutation
details are supported on RDNA devices.
On Fri, Feb 09, 2024 at 11:03:38AM +0100, Jakub Jelinek wrote:
> On Wed, Feb 07, 2024 at 12:43:59PM +0100, arthur.cohen@embecosm.com wrote:
> > This patch introduces one regression because generics are getting better
> > understood over time. The code here used to apply generics with the same
> > symbol from previous segments which was a bit of a hack with out limited
> > inference variable support. The regression looks like it will be related
> > to another issue which needs to default integer inference variables much
> > more aggresivly to default integer.
> >
> > Fixes#2723
> > * rust/compile/issue-1773.rs: Moved to...
> > * rust/compile/issue-1773.rs.bak: ...here.
>
> Please don't use such suffixes in the testsuite.
> Either delete the testcase, or xfail it somehow until the bug is fixed.
To be precise, I have scripts to look for backup files in the tree (*~,
*.bak, *.orig, *.rej etc.) and this stands in the way several times a day.
Here is a fix for that in patch form, tested on x86_64-linux with
make check-rust RUNTESTFLAGS='compile.exp=issue-1773.rs'
2024-02-15 Jakub Jelinek <jakub@redhat.com>
* rust/compile/issue-1773.rs.bak: Rename to ...
* rust/compile/issue-1773.rs: ... this. Add dg-skip-if directive.
In some of the standard pattern names, it is not obvious which mode is being used in the pattern
name. Is it operand 0, 1, or 2? Is it the wider mode or the narrower mode?
This fixes that so there is no confusion by adding a sentence to some of them.
Built the documentation to make sure that it builds.
gcc/ChangeLog:
PR middle-end/113508
* doc/md.texi (sdot_prod@var{m}, udot_prod@var{m},
usdot_prod@var{m}, ssad@var{m}, usad@var{m}, widen_usum@var{m}3,
smulhs@var{m}3, umulhs@var{m}3, smulhrs@var{m}3, umulhrs@var{m}3):
Add sentence about what the mode m is.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
Currently these use `@var{m3}` but the 3 here is a literal 3
and not part of the mode itself so it should not be inside
the var. Fixed as such.
Built the documentation to make sure it looks correct now.
gcc/ChangeLog:
* doc/md.texi (widen_ssum, widen_usum, smulhs, umulhs,
smulhrs, umulhrs, sdiv_pow2): Move the 3 outside of the
var.
Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
The unused bits in the high word are already zero before this operation.
Shifting the used bits to the right cannot affect the unused bits, so we
don't need to sanitize them.
libstdc++-v3/ChangeLog:
PR libstdc++/113806
* include/std/bitset (bitset::operator>>=): Remove redundant
call to _M_do_sanitize.
As pointed out in the PR we already do this for reset().
libstdc++-v3/ChangeLog:
PR libstdc++/113807
* include/std/bitset (bitset::set()): Use memset instead of a
loop over the individual words.
Signed 64-bit division is much slower than unsigned, so cast the n and
k values to unsigned before doing n %= k. We know this is safe because
neither value can be negative.
libstdc++-v3/ChangeLog:
PR libstdc++/113811
* include/bits/stl_algo.h (__rotate): Use unsigned values for
division.
The call to __valarray_copy constructs an _Array object to refer to
this->_M_data but that means that accesses to this->_M_data are through
a restrict-qualified pointer. This leads to undefined behaviour when
copying from an _Expr object that actually aliases this->_M_data.
Replace the call to __valarray_copy with a plain loop. I think this
removes the only use of that overload of __valarray_copy, so it could
probably be removed. I haven't done that here.
libstdc++-v3/ChangeLog:
PR libstdc++/99117
* include/std/valarray (valarray::operator=(const _Expr&)):
Use loop to copy instead of __valarray_copy with _Array.
* testsuite/26_numerics/valarray/99117.cc: New test.
Import the new 2024a tzdata.zi file. The leapseconds file was also
updated to have a new expiry (no new leap seconds were added).
libstdc++-v3/ChangeLog:
* src/c++20/tzdata.zi: Import new file from 2024a release.
* src/c++20/tzdb.cc (tzdb_list::_Node::_S_read_leap_seconds)
Update expiry date for leap seconds list.
For 32-bit targets without __int128 we need to implement the LCG
transition function by hand using 64-bit types.
We can also slightly simplify the __mod function by using if-constexpr
unconditionally, disabling -Wc++17-extensions warnings with diagnostic
pragmas.
libstdc++-v3/ChangeLog:
PR libstdc++/87744
* include/bits/random.h [!__SIZEOF_INT128__] (_Select_uint_least_t):
Define specialization for 64-bit generators with
non-power-of-two modulus and large constants.
(__mod): Use if constexpr unconditionally.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error
line number.
* testsuite/26_numerics/random/linear_congruential_engine/87744.cc:
New test.
The test guality/ipa-sra-1.c stopped working after
r14-5628-g53ba8d669550d3 because the variable from which the values of
removed parameters could be calculated is also removed with it. Fixed
with this patch which stops a function from returning a constant.
I have also noticed that the XFAILed test passes at -O0 -O1 and -Og on
all (three) targets I have tried, not just aarch64, so I extended the
xfail exception accordingly.
gcc/testsuite/ChangeLog:
2024-02-14 Martin Jambor <mjambor@suse.cz>
* gcc.dg/guality/ipa-sra-1.c (get_val1): Move up in the file.
(get_val2): Likewise.
(bar): Do not return a constant. Extend xfail exception for all
targets.
The build_bitint_stmt_ssa_conflicts hook has a special case for
multiplication, division and modulo, where to ensure there is no overlap
between lhs and rhs1/rhs2 arrays we make the lhs conflict with the
operands.
On the following testcase, we have
# a_1(ab) = PHI <a_2(D)(0), a_3(ab)(3)>
lab:
a_3(ab) = a_1(ab) % 3;
before lowering and this special case causes a_3(ab) and a_1(ab) to
conflict, but the PHI requires them not to conflict, so we ICE because we
can't find some partitioning that will work.
The following patch fixes this by special casing such statements before
the partitioning, force the inputs of the multiplication/division which
have large/huge _BitInt (ab) lhs into new non-(ab) SSA_NAMEs initialized
right before the multiplication/division. This allows the partitioning
to work then, as it has the possibility to use a different partition for
the */% operands.
2024-02-15 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113567
* gimple-lower-bitint.cc (gimple_lower_bitint): For large/huge
_BitInt multiplication, division or modulo with
SSA_NAME_OCCURS_IN_ABNORMAL_PHI lhs and at least one of rhs1 and rhs2
force the affected inputs into a new SSA_NAME.
* gcc.dg/bitint-90.c: New test.
The following removes the TBAA violation present in iterative_hash.
As we eventually LTO that it's important to fix. This also improves
code generation for the >= 12 bytes loop by using | to compose the
4 byte words as at least GCC 7 and up can recognize that pattern
and perform a 4 byte load while the variant with a + is not
recognized (not on trunk either), I think we have an enhancement bug
for this somewhere.
Given we reliably merge and the bogus "optimized" path might be
only relevant for archs that cannot do misaligned loads efficiently
I've chosen to keep a specialization for aligned accesses.
libiberty/
* hashtab.c (iterative_hash): Remove TBAA violating handling
of aligned little-endian case in favor of just keeping the
aligned case special-cased. Use | for composing a larger word.
GCC Administrator