Iain Sandoe [Fri, 16 Feb 2024 14:42:53 +0000 (14:42 +0000)]
libiberty: Fix error return value in pex_unix_exec_child [PR113957].
r14-5310-g879cf9ff45d940 introduced some new handling for spawning sub
processes. The return value from the generic exec_child is examined
and needs to be < 0 to signal an error. However, the unix flavour of
this routine is returning the PID value set from the posix_spawn{p}.
This latter value is undefined per the manual pages for both Darwin
and Linux, and it seems Darwin, at least, sets the value to some
usually positive number (presumably the PID that would have been used
if the fork had succeeded).
The fix proposed here is to set the pid = -1 in the relevant error
paths.
PR other/113957
libiberty/ChangeLog:
* pex-unix.c (pex_unix_exec_child): Set pid = -1 in the error
paths, since that is used to signal an erroneous outcome for
the routine.
Iain Sandoe [Tue, 30 Jan 2024 11:04:59 +0000 (11:04 +0000)]
aarch64: Register rng builtins with uint64_t pointers.
Currently, these are registered as unsigned_intDI_type_node which is not
necessarily the same type definition as uint64_t. On platforms where these
differ that causes fails in consuming the arm_acle.h header.
gcc/ChangeLog:
* config/aarch64/aarch64-builtins.cc (aarch64_init_rng_builtins):
Register these builtins with a pointer to uint64_t rather than unsigned
DI mode.
Thomas Schwinge [Fri, 16 Feb 2024 12:04:00 +0000 (13:04 +0100)]
GCN: Conditionalize 'define_expand "reduc_<fexpander>_scal_<mode>"' on '!TARGET_RDNA2_PLUS' [PR113615]
On top of commit c7ec7bd1c6590cf4eed267feab490288e0b8d691
"amdgcn: add -march=gfx1030 EXPERIMENTAL" conditionalizing
'define_expand "reduc_<reduc_op>_scal_<mode>"' on
'!TARGET_RDNA2' (later: '!TARGET_RDNA2_PLUS'), we then did similar in
commit 7cc2262ec9a410dc56d1c1c6b950c922e14f621d
"gcn/gcn-valu.md: Disable fold_left_plus for TARGET_RDNA2_PLUS [PR113615]"
to conditionalize 'define_expand "fold_left_plus_<mode>"' on
'!TARGET_RDNA2_PLUS', but I found we also need to conditionalize the related
'define_expand "reduc_<fexpander>_scal_<mode>"' on '!TARGET_RDNA2_PLUS', to
avoid ICEs like:
Similar for 'gcc.dg/vect/vect-fmax-2.c', 'gcc.dg/vect/vect-fmin-2.c', and
'UNSPEC_SMAX_DPP_SHR' for 'gcc.dg/vect/vect-fmax-1.c', and
'UNSPEC_SMIN_DPP_SHR' for 'gcc.dg/vect/vect-fmin-1.c', when running 'vect.exp'
for 'check-gcc-c'.
When partially substituting a requires-expr, we don't want to perform
any additional checks beyond the substitution itself so as to minimize
checking requirements out of order. So don't check the return-type-req
of a compound-requirement during partial substitution. And don't check
the noexcept condition either since we can't do that on templated trees.
PR c++/113966
gcc/cp/ChangeLog:
* constraint.cc (tsubst_compound_requirement): Don't check
the noexcept condition or the return-type-requirement when
partially substituting.
The following tries to address the PHI insertion compile-time hog in
RTL fwprop observed with the PR54052 testcase where the loop computing
the "unfiltered" set of variables possibly needing PHI nodes for each
block exhibits quadratic compile-time and memory-use.
It does so by pruning the local DEFs with LR_OUT of the block, removing
regs that can never be LR_IN (defined by this block) in the dominance
frontier.
PR rtl-optimization/54052
* rtl-ssa/blocks.cc (function_info::place_phis): Filter
local defs by LR_OUT.
Gaius Mulley [Mon, 19 Feb 2024 12:59:36 +0000 (12:59 +0000)]
PR modula2/113889 Incorrect constant string value if declared in a definition module
This patch fixes a bug exposed when a constant string is declared in a
definition module and imported by a program module. The bug fix
was to defer the string assignment and concatenation until quadruples
were generated. The conststring symbol has a known field which
must be checked prior to retrieving the string contents.
gcc/m2/ChangeLog:
PR modula2/113889
* gm2-compiler/M2ALU.mod (StringFitsArray): Add tokeno parameter
to GetStringLength.
(InitialiseArrayOfCharWithString): Add tokeno parameter to
GetStringLength.
(CheckGetCharFromString): Add tokeno parameter to GetStringLength.
* gm2-compiler/M2Const.mod (constResolveViaMeta): Replace
PutConstString with PutConstStringKnown.
* gm2-compiler/M2GCCDeclare.mod (DeclareCharConstant): Add tokenno
parameter and add assert. Use tokenno to generate location.
(DeclareStringConstant): Add tokenno and add asserts.
Add tokenno parameter to calls to GetStringLength.
(PromoteToString): Add assert and add tokenno parameter to
GetStringLength.
(PromoteToCString): Add assert and add tokenno parameter to
GetStringLength.
(DeclareConstString): New procedure function.
(TryDeclareConst): Remove size local variable.
Check IsConstStringKnown.
Call DeclareConstString.
(PrintString): New procedure.
(PrintVerboseFromList): Call PrintString.
(CheckResolveSubrange): Check IsConstStringKnown before creating
subrange for char or issuing an error.
* gm2-compiler/M2GenGCC.mod (ResolveConstantExpressions): Add
StringLengthOp, StringConvertM2nulOp, StringConvertCnulOp case
clauses.
(FindSize): Add assert IsConstStringKnown.
(StringToChar): New variable tokenno.
Add tokenno parameter to GetStringLength.
(FoldStringLength): New procedure.
(FoldStringConvertM2nul): New procedure.
(FoldStringConvertCnul): New procedure.
(CodeAddr): Add tokenno parameter.
Replace CurrentQuadToken with tokenno.
Add tokenno parameter to GetStringLength.
(PrepareCopyString): Rewrite.
(IsConstStrKnown): New procedure function.
(FoldAdd): Detect conststring op2 and op3 which are known and
concat. Place result into op1.
(FoldStandardFunction): Pass tokenno as a parameter to
GetStringLength.
(CodeXIndr): Rewrite comment.
Rename op1 to left, op3 to right.
Pass rightpos to GetStringLength.
* gm2-compiler/M2Quads.def (QuadrupleOp): Add
StringConvertCnulOp, StringConvertM2nulOp and StringLengthOp.
* gm2-compiler/M2Quads.mod (import): Remove MakeConstLitString.
Add CopyConstString and PutConstStringKnown.
(IsInitialisingConst): Add StringConvertCnulOp,
StringConvertM2nulOp and StringLengthOp.
(callRequestDependant): Replace MakeConstLitString with
MakeConstString.
(DeferMakeConstStringCnul): New procedure function.
(DeferMakeConstStringM2nul): New procedure function.
(CheckParameter): Add early return if the string const is unknown.
(DescribeType): Add token parameter to GetStringLength.
Check for IsConstStringKnown.
(ManipulateParameters): Use DeferMakeConstStringCnul and
DeferMakeConstStringM2nul.
(MakeLengthConst): Remove and replace with...
(DeferMakeLengthConst): ... this.
(doBuildBinaryOp): Create ConstString and set it to contents
unknown.
Check IsConstStringKnown before generating error message.
(WriteQuad): Add StringConvertCnulOp, StringConvertM2nulOp and
StringLengthOp.
(WriteOperator): Add StringConvertCnulOp, StringConvertM2nulOp and
StringLengthOp.
* gm2-compiler/M2SymInit.mod (CheckReadBeforeInitQuad): Add
StringConvertCnulOp, StringConvertM2nulOp and StringLengthOp.
* gm2-compiler/NameKey.mod (LengthKey): Allow NulName to return 0.
* gm2-compiler/P2SymBuild.mod (BuildString): Replace
MakeConstLitString with MakeConstString.
(DetermineType): Replace PutConstString with PutConstStringKnown.
* gm2-compiler/SymbolTable.def (MakeConstVar): Tidy up comment.
(MakeConstLitString): Remove.
(MakeConstString): New procedure function.
(MakeConstStringCnul): New procedure function.
(MakeConstStringM2nul): New procedure function.
(PutConstStringKnown): New procedure.
(CopyConstString): New procedure.
(IsConstStringKnown): New procedure function.
(IsConstStringM2): New procedure function.
(IsConstStringC): New procedure function.
(IsConstStringM2nul): New procedure function.
(IsConstStringCnul): New procedure function.
(GetStringLength): Add token parameter.
(PutConstString): Remove.
(GetConstStringM2): Remove.
(GetConstStringC): Remove.
(GetConstStringM2nul): Remove.
(GetConstStringCnul): Remove.
(MakeConstStringC): Remove.
* gm2-compiler/SymbolTable.mod (SymConstString): Remove
M2Variant, NulM2Variant, CVariant, NulCVariant.
Add Known.
(CheckAnonymous): Replace $$ with __anon.
(IsNameAnonymous): Replace $$ with __anon.
(MakeConstVar): Detect whether the name is nul and treat as
a temporary constant.
(MakeConstLitString): Remove.
(BackFillString): Remove.
(InitConstString): Rewrite.
(GetConstStringM2): Remove.
(GetConstStringC): Remove.
(GetConstStringContent): New procedure function.
(GetConstStringM2nul): Remove.
(GetConstStringCnul): Remove.
(MakeConstStringCnul): Rewrite.
(MakeConstStringM2nul): Rewrite.
(MakeConstStringC): Remove.
(MakeConstString): Rewrite.
(PutConstStringKnown): New procedure.
(CopyConstString): New procedure.
(PutConstString): Remove.
(IsConstStringKnown): New procedure function.
(IsConstStringM2): New procedure function.
(IsConstStringC): Rewrite.
(IsConstStringM2nul): Rewrite.
(IsConstStringCnul): Rewrite.
(GetConstStringKind): New procedure function.
(GetString): Check Known.
(GetStringLength): Add token parameter and check Known.
gcc/testsuite/ChangeLog:
PR modula2/113889
* gm2/pim/run/pass/pim-run-pass.exp: Add filter for
constdef.mod.
* gm2/extensions/run/pass/callingc2.mod: New test.
* gm2/extensions/run/pass/callingc3.mod: New test.
* gm2/extensions/run/pass/callingc4.mod: New test.
* gm2/extensions/run/pass/callingc5.mod: New test.
* gm2/extensions/run/pass/callingc6.mod: New test.
* gm2/extensions/run/pass/callingc7.mod: New test.
* gm2/extensions/run/pass/callingc8.mod: New test.
* gm2/extensions/run/pass/fixedarray.mod: New test.
* gm2/extensions/run/pass/fixedarray2.mod: New test.
* gm2/pim/run/pass/constdef.def: New test.
* gm2/pim/run/pass/constdef.mod: New test.
* gm2/pim/run/pass/testimportconst.mod: New test.
Iain Buclaw [Mon, 19 Feb 2024 10:33:16 +0000 (11:33 +0100)]
d: Add UTF BOM tests to gdc.dg testsuite
Some of these are part of the upstream DMD `gdc.test' testsuite, but
they had been omitted because they get mangled by the lib/gdc-utils.exp
helpers when parsing and staging the tests. Translate them over to the
gdc.dg testsuite instead.
gcc/testsuite/ChangeLog:
* gdc.dg/bom_UTF16BE.d: New test.
* gdc.dg/bom_UTF16LE.d: New test.
* gdc.dg/bom_UTF32BE.d: New test.
* gdc.dg/bom_UTF32LE.d: New test.
* gdc.dg/bom_UTF8.d: New test.
* gdc.dg/bom_characters.d: New test.
* gdc.dg/bom_error_UTF8.d: New test.
* gdc.dg/bom_infer_UTF16BE.d: New test.
* gdc.dg/bom_infer_UTF16LE.d: New test.
* gdc.dg/bom_infer_UTF32BE.d: New test.
* gdc.dg/bom_infer_UTF32LE.d: New test.
* gdc.dg/bom_infer_UTF8.d: New test.
Jakub Jelinek [Mon, 19 Feb 2024 08:42:22 +0000 (09:42 +0100)]
match.pd: Fix ICE on BIT_INSERT_EXPR of BIT_FIELD_REF folding [PR113967]
The following testcase ICEs, because BIT_FIELD_REF's position is not
multiple of the vector element's bit size and the code uses exact_div
to divide those 2 values.
For BIT_INSERT_EXPR, the tree-cfg.cc verification verifies the position
is a multiple of the inserted bit size when inserting into vectors,
but for BIT_FIELD_REF the position can be arbitrary if within the range.
The following patch fixes that.
2024-02-19 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113967
* match.pd (bit_insert @0 (BIT_FIELD_REF @1 ..) ..): Require
in condition that @rpos is multiple of vector element size.
Juzhe-Zhong [Thu, 1 Feb 2024 09:02:52 +0000 (17:02 +0800)]
RISC-V: Suppress the vsetvl fusion for conflict successors
Update in v2: Add dump information.
This patch fixes the following ineffective vsetvl insertion:
void f (int32_t * restrict in, int32_t * restrict out, size_t n, size_t cond, size_t cond2)
{
for (size_t i = 0; i < n; i++)
{
if (i == cond) {
vint8mf8_t v = *(vint8mf8_t*)(in + i + 100);
*(vint8mf8_t*)(out + i + 100) = v;
} else if (i == cond2) {
vfloat32mf2_t v = *(vfloat32mf2_t*)(in + i + 200);
*(vfloat32mf2_t*)(out + i + 200) = v;
} else if (i == (cond2 - 1)) {
vuint16mf2_t v = *(vuint16mf2_t*)(in + i + 300);
*(vuint16mf2_t*)(out + i + 300) = v;
} else {
vint8mf4_t v = *(vint8mf4_t*)(in + i + 400);
*(vint8mf4_t*)(out + i + 400) = v;
}
}
}
Dimitar Dimitrov [Thu, 15 Feb 2024 19:02:37 +0000 (21:02 +0200)]
testsuite: Mark non-optimized variants as expensive
When not optimized for speed, the test for PR112344 takes several
seconds to execute on native x86_64, and 15 minutes on PRU target
simulator. Thus mark those variants as expensive. The -O2 variant
which originally triggered the PR is not expensive, hence it is
still run by default.
PR middle-end/112344
gcc/testsuite/ChangeLog:
* gcc.dg/torture/pr112344.c: Run non-optimized variants only
if expensive tests are allowed.
Jerry DeLisle [Sat, 17 Feb 2024 17:24:58 +0000 (09:24 -0800)]
libgfortran: [PR105473] Fix checks for decimal='comma'.
PR libfortran/105473
libgfortran/ChangeLog:
* io/list_read.c (eat_separator): Reject comma as a
seprator when it is being used as a decimal point.
(parse_real): Reject a '.' when is should be a comma.
(read_real): Likewise.
* io/read.c (read_f): Add more checks for ',' and '.'
conditions.
The r14-870 changes broke xtb package tests (reduced testcase is the first
one below) and caused ICEs on a test derived from that (the second one).
For the
x = T(u = trim (us(1)))
statement, before that change gfortran used to emit weird code with
2 trim calls:
_gfortran_string_trim (&len.2, (void * *) &pstr.1, 20, &us[0]);
if (len.2 > 0)
{
__builtin_free ((void *) pstr.1);
}
D.4275 = len.2;
t.0.u = (character(kind=1)[1:0] *) __builtin_malloc (MAX_EXPR <(sizetype) D.4275, 1>);
t.0._u_length = D.4275;
_gfortran_string_trim (&len.4, (void * *) &pstr.3, 20, &us[0]);
(void) __builtin_memcpy ((void *) t.0.u, (void *) pstr.3, (unsigned long) NON_LVALUE_EXPR <len.4>);
if (len.4 > 0)
{
__builtin_free ((void *) pstr.3);
}
That worked at runtime, though it is wasteful.
That commit changed it to:
slen.3 = len.2;
t.0.u = (character(kind=1)[1:0] *) __builtin_malloc (MAX_EXPR <(sizetype) slen.3, 1>);
t.0._u_length = slen.3;
_gfortran_string_trim (&len.2, (void * *) &pstr.1, 20, &us[0]);
(void) __builtin_memcpy ((void *) t.0.u, (void *) pstr.1, (unsigned long) NON_LVALUE_EXPR <len.2>);
if (len.2 > 0)
{
__builtin_free ((void *) pstr.1);
}
which results in -Wuninitialized warning later on and if one is unlucky and
the uninitialized len.2 variable is smaller than the trimmed length, it
results in heap overflow and often crashes later on.
The bug above is clear, len.2 is only initialized in the
_gfortran_string_trim (&len.2, (void * *) &pstr.1, 20, &us[0]);
call, but used before that. Now, the
slen.3 = len.2;
t.0.u = (character(kind=1)[1:0] *) __builtin_malloc (MAX_EXPR <(sizetype) slen.3, 1>);
t.0._u_length = slen.3;
statements come from the alloc_scalar_allocatable_subcomponent call,
while
_gfortran_string_trim (&len.2, (void * *) &pstr.1, 20, &us[0]);
from the gfc_conv_expr (&se, expr); call which is done before the
alloc_scalar_allocatable_subcomponent call, but is only appended later on
with gfc_add_block_to_block (&block, &se.pre);
Now, obviously the alloc_scalar_allocatable_subcomponent emitted statements
can depend on the se.pre sequence statements which can compute variables
used by alloc_scalar_allocatable_subcomponent like the length.
On the other side, I think the se.pre sequence really shouldn't depend
on the changes done by alloc_scalar_allocatable_subcomponent, that is
initializing the FIELD_DECLs of the destination allocatable subcomponent
only, the gfc_conv_expr statements are already created, so all they could
in theory depend above is on t.0.u or t.0._u_length, but I believe if the
rhs dependened on the lhs content (which is allocated by those statements
but really uninitialized), it would need to be discovered by the dependency
analysis and forced into a temporary.
So, in order to fix the first testcase, the second hunk of the patch just
emits the se.pre block before the alloc_scalar_allocatable_subcomponent
changes rather than after it.
The second problem is an ICE on the second testcase. expr in the caller
(expr2 inside of alloc_scalar_allocatable_subcomponent) has
expr2->ts.u.cl->backend_decl already set, INTEGER_CST 20, but
alloc_scalar_allocatable_subcomponent overwrites it to a new VAR_DECL
which it assigns a value to before the malloc. That can work if the only
places the expr2->ts is ever used are in the same local block or its
subblocks (and only if it is dominated by the code emitted by
alloc_scalar_allocatable_subcomponent, so e.g. not if that call is inside
of a conditional code and use later unconditional), but doesn't work
if expr2->ts is used before that block or after it. So, the exact ICE is
because of:
slen.1 = 20;
static character(kind=1) us[1][1:20] = {"foo "};
x.u = 0B;
x._u_length = 0;
{
struct t t.0;
struct t D.4308;
{
integer(kind=8) slen.1;
slen.1 = 20;
t.0.u = (character(kind=1)[1:0] *) __builtin_malloc (MAX_EXPR <(sizetype) slen.1, 1>);
t.0._u_length = slen.1;
(void) __builtin_memcpy ((void *) t.0.u, (void *) &us[0], 20);
}
where the first slen.1 = 20; is emitted because it sees us has a VAR_DECL
ts.u.cl->backend_decl and so it wants to initialize it to the actual length.
This is invalid GENERIC, because the slen.1 variable is only declared inside
of a {} later on and so uses outside of it are wrong. Similarly wrong would
be if it is used later on. E.g. in the same testcase if it has
type(T) :: x, y
x = T(u = us(1))
y%u = us(1)
then there is
{
integer(kind=8) slen.1;
slen.1 = 20;
t.0.u = (character(kind=1)[1:0] *) __builtin_malloc (MAX_EXPR <(sizetype) slen.1, 1>);
t.0._u_length = slen.1;
(void) __builtin_memcpy ((void *) t.0.u, (void *) &us[0], 20);
}
...
if (y.u != 0B) goto L.1;
y.u = (character(kind=1)[1:0] *) __builtin_malloc (MAX_EXPR <(sizetype) slen.1, 1>);
i.e. another use of slen.1, this time after slen.1 got out of scope.
I really don't understand why the code modifies
expr2->ts.u.cl->backend_decl, expr2 isn't used there anywhere except for
expr2->ts.u.cl->backend_decl expressions, so hacks like save the previous
value, overwrite it temporarily over some call that will use expr2 and
restore afterwards aren't needed - there are no such calls, so the
following patch fixes it just by not messing up with
expr2->ts.u.cl->backend_decl, only set it to size variable and overwrite
that with a temporary if needed.
2024-02-17 Jakub Jelinek <jakub@redhat.com>
PR fortran/113503
* trans-expr.cc (alloc_scalar_allocatable_subcomponent): Don't
overwrite expr2->ts.u.cl->backend_decl, instead set size to
expr2->ts.u.cl->backend_decl first and use size instead of
expr2->ts.u.cl->backend_decl.
(gfc_trans_subcomponent_assign): Emit se.pre into block
before calling alloc_scalar_allocatable_subcomponent instead of
after it.
* gfortran.dg/pr113503_1.f90: New test.
* gfortran.dg/pr113503_2.f90: New test.
Marek Polacek [Thu, 15 Feb 2024 22:07:43 +0000 (17:07 -0500)]
c++: wrong looser excep spec for dep noexcept [PR113158]
Here we find ourselves in maybe_check_overriding_exception_spec in
a template context where we can't instantiate a dependent noexcept.
That's OK, but we have to defer the checking otherwise we give wrong
errors.
PR c++/113158
gcc/cp/ChangeLog:
* search.cc (maybe_check_overriding_exception_spec): Defer checking
when a noexcept couldn't be instantiated & evaluated to false/true.
std::__niter_base is used in _GLIBCXX_DEBUG mode to remove _Safe_iterator<>
wrapper on random access iterators. But doing so it should also preserve original
behavior to remove __normal_iterator wrapper.
libstdc++-v3/ChangeLog:
* include/bits/stl_algobase.h (std::__niter_base): Redefine the overload
definitions for __gnu_debug::_Safe_iterator.
* include/debug/safe_iterator.tcc (std::__niter_base): Adapt declarations.
Jakub Jelinek [Sat, 17 Feb 2024 08:25:59 +0000 (09:25 +0100)]
testsuite: Fix up lra effective target
Given the recent discussions on IRC started with Andrew P. mentioning that
an asm goto outputs test should have { target lra } and the lra effective
target in GCC 11/12 only returning 0 for PA and in 13/14 for PA/AVR, while
we clearly have 14 other targets which don't support LRA and a couple of
further ones which have an -mlra/-mno-lra switch (whatever default they
have), seems to me the effective target is quite broken.
The following patch rewrites it, such that it has a fast path for heavily
used targets which are for years known to use only LRA (just an
optimization) plus determines whether it is a LRA target or reload target
by scanning the -fdump-rtl-reload-details dump on an empty function,
LRA has quite a few always emitted messages in that case while reload has
none of those.
Tested on x86_64-linux and cross to s390x-linux, for the latter with both
make check-gcc RUNTESTFLAGS='--target_board=unix/-mno-lra dg.exp=pr107385.c'
where the test is now UNSUPPORTED and
make check-gcc RUNTESTFLAGS='--target_board=unix/-mlra dg.exp=pr107385.c'
where it fails because I don't have libc around.
There is one special case, NVPTX, which is a TARGET_NO_REGISTER_ALLOCATION
target. I think claiming for it that it is a lra target is strange (even
though it effectively returns true for targetm.lra_p ()), unsure if it
supports asm goto with outputs or not, if it does and we want to test it,
perhaps we should introduce asm_goto_outputs effective target and use
lra || nvptx-*-* for that?
2024-02-17 Jakub Jelinek <jakub@redhat.com>
* lib/target-supports.exp (check_effective_target_lra): Rewrite
to list some heavily used always LRA targets and otherwise check the
-fdump-rtl-reload-details dump for messages specific to LRA.
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.
{
// 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
Andrew Pinski [Fri, 16 Feb 2024 21:26:30 +0000 (13:26 -0800)]
Add -Wstrict-aliasing to vector-struct-1.C testcase
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`.
Edwin Lu [Mon, 12 Feb 2024 19:38:15 +0000 (11:38 -0800)]
testsuite: Add support for scanning assembly with comparitor
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.
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.
Jakub Jelinek [Fri, 16 Feb 2024 16:42:32 +0000 (17:42 +0100)]
c++: Diagnose this specifier on template parameters [PR113929]
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.
Jason Merrill [Mon, 5 Feb 2024 16:49:41 +0000 (11:49 -0500)]
gdbhooks: regex syntax error
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.
Rainer Orth [Fri, 16 Feb 2024 13:06:24 +0000 (14:06 +0100)]
libsanitizer: Intercept __makecontext_v2 on Solaris/SPARC [PR113785]
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.
Richard Biener [Fri, 16 Feb 2024 09:08:43 +0000 (10:08 +0100)]
tree-optimization/113895 - consistency check fails in copy_reference_ops_from_ref
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 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.
Tejas Belagod [Thu, 25 Jan 2024 10:35:36 +0000 (16:05 +0530)]
Arm: Fix incorrect tailcall-generation for indirect calls [PR113780]
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.
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>
Jakub Jelinek [Thu, 15 Feb 2024 19:04:01 +0000 (20:04 +0100)]
testsuite: Require lra effective target for pr107385.c
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.
Andrew Pinski [Fri, 2 Feb 2024 21:13:58 +0000 (13:13 -0800)]
aarch64: Fix undefined code in vect_ctz_1.c
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>
testsuite: Define _POSIX_SOURCE for tests [PR113278]
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)
David Faust [Wed, 14 Feb 2024 22:29:43 +0000 (14:29 -0800)]
bpf: fix zero_extendqidi2 ldx template
Commit 77d0f9ec3809b4d2e32c36069b6b9239d301c030 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.
Jakub Jelinek [Thu, 15 Feb 2024 14:53:01 +0000 (15:53 +0100)]
expand: Fix handling of asm goto outputs vs. PHI argument adjustments [PR113921]
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.
Matthieu Longo [Thu, 8 Feb 2024 18:13:49 +0000 (18:13 +0000)]
arm: testuite: Missing optimization pattern for rev16 with thumb1
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.
Andrew Stubbs [Wed, 14 Feb 2024 15:12:43 +0000 (15:12 +0000)]
amdgcn: Disallow unsupported permute on RDNA devices
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.
Jakub Jelinek [Thu, 15 Feb 2024 12:55:49 +0000 (13:55 +0100)]
gccrs: Avoid *.bak suffixed tests - use dg-skip-if instead
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'
Andrew Pinski [Wed, 14 Feb 2024 22:29:22 +0000 (14:29 -0800)]
doc: Add documentation of which operand matches the mode of the standard pattern name [PR113508]
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>
Jonathan Wakely [Thu, 8 Feb 2024 15:47:19 +0000 (15:47 +0000)]
libstdc++: Remove redundant zeroing in std::bitset::operator>>= [PR113806]
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.
Jonathan Wakely [Thu, 8 Feb 2024 15:40:32 +0000 (15:40 +0000)]
libstdc++: Use unsigned division in std::rotate [PR113811]
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.
Jonathan Wakely [Thu, 8 Feb 2024 13:59:42 +0000 (13:59 +0000)]
libstdc++: Avoid aliasing violation in std::valarray [PR99117]
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.
Jonathan Wakely [Fri, 12 Jan 2024 16:57:41 +0000 (16:57 +0000)]
libstdc++: Update tzdata to 2024a
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.
Jonathan Wakely [Wed, 7 Feb 2024 11:31:10 +0000 (11:31 +0000)]
libstdc++: Use 128-bit arithmetic for std::linear_congruential_engine [PR87744]
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.
Martin Jambor [Thu, 15 Feb 2024 10:50:34 +0000 (11:50 +0100)]
testsuite: Fix guality/ipa-sra-1.c to work with return IPA-VRP
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.
Jakub Jelinek [Thu, 15 Feb 2024 08:52:47 +0000 (09:52 +0100)]
lower-bitint: Ensure we don't get coalescing ICEs for (ab) SSA_NAMEs used in mul/div/mod [PR113567]
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.
Richard Biener [Wed, 14 Feb 2024 13:00:23 +0000 (14:00 +0100)]
[libiberty] remove TBAA violation in iterative_hash, improve code-gen
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.
Steve Kargl [Wed, 14 Feb 2024 22:40:16 +0000 (14:40 -0800)]
Fortran: namelist-object-name renaming.
PR fortran/105847
gcc/fortran/ChangeLog:
* trans-io.cc (transfer_namelist_element): When building the
namelist object name, if the use rename attribute is set, use
the local name specified in the use statement.
Uros Bizjak [Wed, 14 Feb 2024 20:09:35 +0000 (21:09 +0100)]
testsuite: Fix a couple of x86 issues in gcc.dg/vect testsuite
A compile-time test can use -march=skylake-avx512 for all x86 targets,
but a runtime test needs to check avx512f effective target if the
instructions can be assembled.
The runtime test also needs to check if the target machine supports
instruction set we have been compiled for. The testsuite uses check_vect
infrastructure, but handling of AVX512F+ ISAs was missing there.
Add detection of __AVX512F__ and __AVX512VL__, which is enough to handle
all currently mentioned target processors in the gcc.dg/vect testsuite.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/pr113576.c (dg-additional-options):
Use -march=skylake-avx512 for avx512f effective target.
* gcc.dg/vect/pr98308.c (dg-additional-options):
Use -march=skylake-avx512 for all x86 targets.
* gcc.dg/vect/tree-vect.h (check_vect): Handle __AVX512F__
and __AVX512VL__.
H.J. Lu [Tue, 13 Feb 2024 16:40:52 +0000 (08:40 -0800)]
x86: Support x32 and IBT in heap trampoline
Add x32 and IBT support to x86 heap trampoline implementation with a
testcase.
2024-02-13 Jakub Jelinek <jakub@redhat.com>
H.J. Lu <hjl.tools@gmail.com>
libgcc/
PR target/113855
* config/i386/heap-trampoline.c (trampoline_insns): Add IBT
support and pad to the multiple of 4 bytes. Use movabsq
instead of movabs in comments. Add -mx32 variant.
gcc/testsuite/
PR target/113855
* gcc.dg/heap-trampoline-1.c: New test.
* lib/target-supports.exp (check_effective_target_heap_trampoline):
New.
* gcc.target/i386/pr113871-1a.c: New test.
* gcc.target/i386/pr113871-1b.c: New test.
* gcc.target/i386/pr113871-2a.c: New test.
* gcc.target/i386/pr113871-2b.c: New test.
* gcc.target/i386/pr113871-3a.c: New test.
* gcc.target/i386/pr113871-3b.c: New test.
* gcc.target/i386/pr113871-4a.c: New test.
Roger Sayle [Wed, 14 Feb 2024 19:09:51 +0000 (19:09 +0000)]
PR other/113336: Fix libatomic testsuite regressions on ARM.
This patch is a revised version of the fix for PR other/113336.
Bootstrapping GCC on arm-linux-gnueabihf with --with-arch=armv6 currently
has a large number of FAILs in libatomic (regressions since last time I
attempted this). The failure mode is related to IFUNC handling with the
file tas_8_2_.o containing an unresolved reference to the function
libat_test_and_set_1_i2.
The following one line change, to build tas_1_2_.o when building tas_8_2_.o,
resolves the problem for me and restores the libatomic testsuite to 44
expected passes and 5 unsupported tests [from 22 unexpected failures
and 22 unresolved testcases].
`
2024-02-14 Roger Sayle <roger@nextmovesoftware.com>
Victor Do Nascimento <victor.donascimento@arm.com>
Nathaniel Shead [Wed, 14 Feb 2024 01:26:03 +0000 (12:26 +1100)]
c++: Defer emitting inline variables [PR113708]
Inline variables are vague-linkage, and may or may not need to be
emitted in any TU that they are part of, similarly to e.g. template
instantiations.
Currently 'import_export_decl' assumes that inline variables have
already been emitted when it comes to end-of-TU processing, and so
crashes when importing non-trivially-initialised variables from a
module, as they have not yet been finalised.
This patch fixes this by ensuring that inline variables are always
deferred till end-of-TU processing, unifying the behaviour for module
and non-module code.
* g++.dg/debug/dwarf2/inline-var-1.C: Reference 'a' to ensure it
is emitted.
* g++.dg/debug/dwarf2/inline-var-3.C: Likewise.
* g++.dg/modules/init-7_a.H: New test.
* g++.dg/modules/init-7_b.C: New test.
In the second testcase below, during ahead of time checking of the
non-dependent new-expr we synthesize B's copy ctor, which we expect to
get defined as deleted since A's copy ctor is inaccessible. But during
access checking thereof, enforce_access incorrectly decides to defer it
since we're in a template context according to current_template_parms
(before r14-557 it checked processing_template_decl which got cleared
from implicitly_declare_fn), which leads to the access check leaking out
to the template context that triggered the synthesization, and B's copy
ctor getting declared as non-deleted.
This patch fixes this by using maybe_push_to_top_level to clear the
context (including current_template_parms) before proceeding with the
synthesization. We could do this from implicitly_declare_fn, but it's
better to do it more generally from synthesized_method_walk for sake of
its other callers.
This turns out to fix PR113332 as well: there the lambda context
triggering synthesization was causing maybe_dummy_object to misbehave,
but now synthesization is sufficiently context-independent.
PR c++/113908
PR c++/113332
gcc/cp/ChangeLog:
* method.cc (synthesized_method_walk): Use maybe_push_to_top_level.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/lambda/lambda-nsdmi11.C: New test.
* g++.dg/template/non-dependent31.C: New test.
Richard Biener [Wed, 14 Feb 2024 11:33:13 +0000 (12:33 +0100)]
tree-optimization/113910 - huge compile time during PTA
For the testcase in PR113910 we spend a lot of time in PTA comparing
bitmaps for looking up equivalence class members. This points to
the very weak bitmap_hash function which effectively hashes set
and a subset of not set bits.
The major problem with it is that it simply truncates the
BITMAP_WORD sized intermediate hash to hashval_t which is
unsigned int, effectively not hashing half of the bits.
This reduces the compile-time for the testcase from tens of minutes
to 42 seconds and PTA time from 99% to 46%.
PR tree-optimization/113910
* bitmap.cc (bitmap_hash): Mix the full element "hash" to
the hashval_t hash.
Rainer Orth [Wed, 14 Feb 2024 13:52:54 +0000 (14:52 +0100)]
testsuite: gdc: Require ucn in gdc.test/runnable/mangle.d etc. [PR104739]
gdc.test/runnable/mangle.d and two other tests come out UNRESOLVED on
Solaris with the native assembler:
UNRESOLVED: gdc.test/runnable/mangle.d compilation failed to produce executable
UNRESOLVED: gdc.test/runnable/mangle.d -shared-libphobos compilation failed
to produce executable
UNRESOLVED: gdc.test/runnable/testmodule.d compilation failed to produce
executable
UNRESOLVED: gdc.test/runnable/testmodule.d -shared-libphobos compilation
failed to produce executable
UNRESOLVED: gdc.test/runnable/ufcs.d compilation failed to produce executable
UNRESOLVED: gdc.test/runnable/ufcs.d -shared-libphobos compilation failed
to produce executable
Assembler: mangle.d
"/var/tmp//cci9q2Sc.s", line 115 : Syntax error
Near line: " movzbl test_эльфийские_письмена_9, %eax"
"/var/tmp//cci9q2Sc.s", line 115 : Syntax error
Near line: " movzbl test_эльфийские_письмена_9, %eax"
"/var/tmp//cci9q2Sc.s", line 115 : Syntax error
Near line: " movzbl test_эльфийские_письмена_9, %eax"
"/var/tmp//cci9q2Sc.s", line 115 : Syntax error
Near line: " movzbl test_эльфийские_письмена_9, %eax"
"/var/tmp//cci9q2Sc.s", line 115 : Syntax error
[...]
since /bin/as lacks UCN support.
Iain recently added UNICODE_NAMES: annotations to the affected tests and
those recently were imported into trunk.
This patch handles the DejaGnu side of things, adding
{ dg-require-effective-target ucn }
to those tests on the fly.
Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11 (as and gas each),
and x86_64-pc-linux-gnu.
Andrew Pinski [Tue, 13 Feb 2024 21:39:16 +0000 (13:39 -0800)]
vect/testsuite: Fix vect-simd-clone-1[02].c when dg-do default is compile [PR113899]
The vect testsuite will chose the dg-do default based on if it knows the
running target does not support running with the vector extensions enabled
(for easy of testing). The problem is when it is decided the default is compile
instead of run, dg-additional-sources does not work. So the fix is to set
dg-do on these two testcases to run explicitly.
Tested on x86_64 with a hack to check_vect_support_and_set_flags to set the dg-default
to compile.
Jakub Jelinek [Wed, 14 Feb 2024 13:36:44 +0000 (14:36 +0100)]
testsuite: Add %[zt][diox] tests to gcc.dg/format/
On Mon, Feb 12, 2024 at 04:10:33PM +0000, Joseph Myers wrote:
> Please also add some tests of format checking for these modifiers in
> gcc.dg/format/gcc_*.c.
The following patch does that.
Haven't added tests for bad type (but I think we don't have them in
c99-printf* either) for these because it is hard to figure out what
type from {,unsigned }{int,long,long long} size_t/ptrdiff_t certainly
is not, guess one could do that with preprocessor conditionals, e.g.
comparing __PTRDIFF_MAX__ with __INT_MAX__, __LONG_MAX__ and
__LONG_LONG_MAX__ and pick up the one which is different; but we'd need
to find out corresponding effective targets for the expected diagnostics.
2024-02-14 Jakub Jelinek <jakub@redhat.com>
* gcc.dg/format/gcc_diag-1.c (foo): Add tests for z and t modifiers.
* gcc.dg/format/gcc_gfc-1.c (foo): Add tests for ll, z and t modifiers.
Jakub Jelinek [Wed, 14 Feb 2024 13:35:32 +0000 (14:35 +0100)]
pretty-print: Fix up ptrdiff handling for %tu, %to, %tx
This is IMHO more of a theoretical case, I believe my current code
doesn't handle %tu or %to or %tx correctly if ptrdiff_t is not one of
int, long int or long long int. For size_t and %zd or %zi I'm
using va_arg (whatever, ssize_t) and hope that ssize_t is the signed
type corresponding to size_t which C99 talks about.
For ptrdiff_t there is no type for unsigned type corresponding to
ptrdiff_t and I'm not aware of a portable way on the host to get
such a type (the fmt tests use hacks like
#define signed /* Type might or might not have explicit 'signed'. */
typedef unsigned __PTRDIFF_TYPE__ unsigned_ptrdiff_t;
#undef signed
but that only works with compilers which predefine __PTRDIFF_TYPE__),
std::make_unsigned<ptrdiff_t> I believe only works reliably if
ptrdiff_t is one of char, signed char, short, int, long or long long,
but won't work e.g. for __int20__ or whatever other weird ptrdiff_t
the host might have.
The following patch assumes host is two's complement (I think we
rely on it pretty much everywhere anyway) and prints unsigned type
corresponding to ptrdiff_t as unsigned long long printing of
ptrdiff_t value masked with 2ULL * PTRDIFF_MAX + 1. So the only
actual limitation is that it doesn't support ptrdiff_t wider than
long long int.
2024-02-14 Jakub Jelinek <jakub@redhat.com>
* pretty-print.cc (PTRDIFF_MAX): Define if not yet defined.
(pp_integer_with_precision): For unsigned ptrdiff_t printing
with u, o or x print ptrdiff_t argument converted to
unsigned long long and masked with 2ULL * PTRDIFF_MAX + 1.
* error.cc (error_print): For u printing of ptrdiff_t,
print ptrdiff_t argument converted to unsigned long long and
masked with 2ULL * PTRDIFF_MAX + 1.
Richard Biener [Fri, 9 Feb 2024 07:15:44 +0000 (08:15 +0100)]
middle-end/113576 - zero padding of vector bools when expanding compares
The following zeros paddings of vector bools when expanding compares
and the mode used for the compare is an integer mode. In that case
targets cannot distinguish between a 4 element and 8 element vector
compare (both get to the QImode compare optab) so we have to do the
job in the middle-end.
PR middle-end/113576
* expr.cc (do_store_flag): For vector bool compares of vectors
with padding zero that.
* dojump.cc (do_compare_and_jump): Likewise.
Nathaniel Shead [Mon, 12 Feb 2024 01:40:15 +0000 (12:40 +1100)]
c++: Fix error recovery when redeclaring enum in different module [PR99573]
This ensures that with modules enabled, redeclaring an enum in the wrong
module or with the wrong underlying type no longer ICEs.
The patch also rearranges the order of the checks a little because I
think it's probably more important to note that you can't redeclare the
enum all before complaining about mismatched underlying types etc.
As a drive by this patch also adds some missing diagnostic groups, and
rewords the module redeclaration error message to more closely match the
wording used in other places this check is done.
PR c++/99573
gcc/cp/ChangeLog:
* decl.cc (start_enum): Reorder check for redeclaring in module.
Add missing auto_diagnostic_groups.
gcc/testsuite/ChangeLog:
* g++.dg/modules/enum-12.C: New test.
Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
Rainer Orth [Wed, 14 Feb 2024 10:39:12 +0000 (11:39 +0100)]
testsuite: i386: Skip gcc.target/i386/pr113689-1.c etc. on Solaris [PR113909]
gcc.target/i386/pr113689-[1-3].c FAIL on 64-bit Solaris/x86:
FAIL: gcc.target/i386/pr113689-1.c (test for excess errors)
UNRESOLVED: gcc.target/i386/pr113689-1.c compilation failed to produce executable
FAIL: gcc.target/i386/pr113689-2.c (test for excess errors)
UNRESOLVED: gcc.target/i386/pr113689-2.c compilation failed to produce executable
FAIL: gcc.target/i386/pr113689-3.c (test for excess errors)
UNRESOLVED: gcc.target/i386/pr113689-3.c compilation failed to produce executable
with
Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/pr113689-1.c:43:1: sorry, unimplemented: no register available for profiling '-mcmodel=large'
Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/pr113689-2.c:26:1: sorry, unimplemented: profiling '-mcmodel=large' with PIC is not supported
Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/pr113689-3.c:15:1: sorry, unimplemented: profiling '-mcmodel=large' with PIC is not supported
This happens because i386/sol2.h doesn't define NO_PROFILE_COUNTERS.
projects / thirdparty / gcc.git / log
