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.
As Jason analyzed, Solaris <string.h> declares memchr for C++ as returning
const void * as specified by the C++ standard, while gcc expects the return
type to be void * like in C.
So this patch xfails the test for C++ on Solaris.
Tested on sparc-sun-solaris2.11 and x86_64-pc-linux-gnu.
Tobias Burnus [Tue, 13 Feb 2024 19:55:26 +0000 (20:55 +0100)]
OpenMP: Reject non-const 'condition' trait in Fortran
OpenMP 5.0 only permits constant expressions for the 'condition' trait
in context selectors; this is relaxed in 5.2 but not implemented. In order
to avoid wrong code, it is now rejected.
Additionally, in Fortran, 'condition' should not accept an integer
expression, which is now ensured. Additionally, as 'device_num' should be
a conforming device number, there is now a check on the value.
PR middle-end/113904
gcc/c/ChangeLog:
* c-parser.cc (c_parser_omp_context_selector): Handle splitting of
OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
gcc/cp/ChangeLog:
* parser.cc (cp_parser_omp_context_selector): Handle splitting of
OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
gcc/fortran/ChangeLog:
* trans-openmp.cc (gfc_trans_omp_declare_variant): Handle splitting of
OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
* openmp.cc (gfc_match_omp_context_selector): Likewise; rejects
non-const device_num/condition; improve diagnostic.
gcc/ChangeLog:
* omp-general.cc (struct omp_ts_info): Update for splitting of
OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
* omp-selectors.h (enum omp_tp_type): Replace
OMP_TRAIT_PROPERTY_EXPR by OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR.
Patrick Palka [Tue, 13 Feb 2024 19:26:48 +0000 (14:26 -0500)]
c++/modules: use optimized crc32 from zlib
The current implementation of bytes::calc_crc computes the checksum one
byte at a time which turns out to be quite slow, accounting for 15% of
streaming in time for a modular Hello World. We have a crc32_unsigned
version that processes 4 bytes at a time which we could use here, but
since we bundle zlib we might as well use its highly optimized crc
routines that can process up to 32 bytes at a time.
So this patch makes us use zlib's crc32 in this hot code path. This
reduces stream in time for a modular Hello World by around 15% for me
with a release compiler.
gcc/cp/ChangeLog:
* Make-lang.in (CFLAGS-cp/module.o): Add $(ZLIBINC).
* module.cc: Include <zlib.h>.
(bytes::calc_crc): Use crc32 from zlib.
(bytes_out::set_crc): Use crc32_combine from zlib.
Patrick Palka [Tue, 13 Feb 2024 19:26:40 +0000 (14:26 -0500)]
c++/modules: ICEs with modular fmtlib
Building modular fmtlib triggered two small modules bugs in C++23 and
C++26 mode respectively (due to libstdc++ header differences).
The first is that a TEMPLATE_DECL having DECL_LANG_SPECIFIC doesn't
necessarily imply that its DECL_TEMPLATE_RESULT has DECL_LANG_SPECIFIC.
So in add_specializations we need to use STRIP_TEMPLATE consistently;
this is a follow-up to r12-7187-gdb84f382ae3dc2.
The second is that get_originating_module_decl was ICEing on class-scope
enumerators injected via using-enum. I suppose we should handle them
like a class-scope entity rather than a non-using-enum enumerator.
gcc/cp/ChangeLog:
* module.cc (depset::hash::add_specializations): Use
STRIP_TEMPLATE consistently.
(get_originating_module_decl): Handle class-scope CONST_DECL.
gcc/testsuite/ChangeLog:
* g++.dg/modules/friend-6_a.C: New test.
* g++.dg/modules/using-enum-3_a.C: New test.
* g++.dg/modules/using-enum-3_b.C: New test.
Patrick Palka [Tue, 13 Feb 2024 19:26:37 +0000 (14:26 -0500)]
c++/modules: reduce lazy loading recursion
It turns out that with modules we can call mangle_decl recursively
which is bad because the global mangling state isn't recursion aware.
The recursion happens from write_closure_type_name, which calls
lambda_function, which performs name lookup, which can trigger lazy
loading, which can call maybe_clone_body for a newly loaded cdtor, which
can inspect DECL_ASSEMBLER_NAME, which enters mangling. This was
observed when using fmtlib as a module with trunk and it leads to a
bogus "mangling conflicts with a previous mangle error" followed by an
ICE from cdtor_comdat_group due to a mangling mismatch.
This patch fixes this by sidestepping lazy loading when performing the
op() lookup in lambda_function, so that we don't accidentally end up
entering mangling recursively. This should be safe since the lazy load
should still get triggered by some other name lookup.
In passing it was noticed that lazy loading can get excessively recursive
ultimately due to the name lookups performed from check_local_shadow,
which may trigger lazy loading, which cause us to instantiate/clone
things, which end up calling check_local_shadow. This patch mitigates
this by implementating an optimization suggested by Jason:
> I think we shouldn't bother with check_local_shadow in a clone or
> instantiation, only when actually parsing.
This reduces the maximum depth of lazy loading recursion for a simple
modular Hello World from ~115 to ~12.
gcc/cp/ChangeLog:
* lambda.cc (lambda_function): Call get_class_binding_direct
instead of lookup_member to sidestep lazy loading.
* name-lookup.cc (check_local_shadow): Punt if we're in a
function context that's not actual parsing.
Harald Anlauf [Tue, 13 Feb 2024 19:19:10 +0000 (20:19 +0100)]
Fortran: fix passing of optional dummies to bind(c) procedures [PR113866]
PR fortran/113866
gcc/fortran/ChangeLog:
* trans-expr.cc (gfc_conv_procedure_call): When passing an optional
dummy argument to an optional dummy argument of a bind(c) procedure
and the dummy argument is passed via a CFI descriptor, no special
presence check and passing of a default NULL pointer is needed.
If register_specialization finds a previous declaration and throws the new
one away, we shouldn't still add the new one to
DECL_TEMPLATE_SPECIALIZATIONS.
PR c++/113612
gcc/cp/ChangeLog:
* pt.cc (process_partial_specialization): Return early
on redeclaration.
Marek Polacek [Sat, 10 Feb 2024 15:52:18 +0000 (10:52 -0500)]
c++: SFINAE-unfriendly error on throwing pointer [PR112436]
On the heels of r14-8903, this patch adds further complain parameters
so that we don't emit "invalid use of incomplete type" from inside
a concept.
PR c++/112436
gcc/cp/ChangeLog:
* except.cc (expand_start_catch_block): Pass tf_warning_or_error to
is_admissible_throw_operand_or_catch_parameter.
(build_throw): Pass complain to
is_admissible_throw_operand_or_catch_parameter.
(complete_ptr_ref_or_void_ptr_p): Add a tsubst_flags_t parameter. Use
it. Return bool. Call complete_type_or_maybe_complain instead of
complete_type_or_else.
(is_admissible_throw_operand_or_catch_parameter): Add a tsubst_flags_t
parameter. Use it. Guard error calls.
Richard Biener [Tue, 13 Feb 2024 10:10:57 +0000 (11:10 +0100)]
tree-optimization/113895 - copy_reference_ops_from_ref vs. bitfields
The recent enhancement to discover constant array indices by range
info used by get_ref_base_and_extent doesn't work when the outermost
component reference is to a bitfield because we track the running
offset in the reference ops as bytes. The following does as
ao_ref_init_from_vn_reference and recovers that manually, tracking
the offset for the purpose of discovering the constant array index
in bits instead.
PR tree-optimization/113895
* tree-ssa-sccvn.cc (copy_reference_ops_from_ref): Track
offset to discover constant array indices in bits, handle
COMPONENT_REF to bitfields.
Rainer Orth [Tue, 13 Feb 2024 12:24:43 +0000 (13:24 +0100)]
libgm2: Fix libm2iso/wraptime.cc compilation on Solaris
As it turned out, my patch to complete the libgm2 autoconf macros works
on both Linux/sparc64 and Linux/x86_64, but breaks Solaris bootstrap:
/vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc: In function 'int
m2iso_wraptime_gettimeofday(void*, timezone*)':
/vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc:148:24: error:
invalid conversion from 'void*' to 'timeval*' [-fpermissive]
148 | return gettimeofday (tv, tz);
| ^~
| |
| void*
In file included from /usr/include/sys/select.h:27,
from /usr/include/sys/types.h:665,
from /vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc:35:
/usr/include/sys/time.h:444:18: note: initializing argument 1 of 'int gettimeofday(timeval*, void*)'
444 | int gettimeofday(struct timeval *_RESTRICT_KYWD, void *_RESTRICT_KYWD);
| ^
/vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc: In function 'int
m2iso_wraptime_settimeofday(void*, timezone*)':
/vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc:165:24: error:
invalid conversion from 'void*' to 'timeval*' [-fpermissive]
165 | return settimeofday (tv, tz);
| ^~
| |
| void*
/usr/include/sys/time.h:431:18: note: initializing argument 1 of 'int
settimeofday(timeval*, void*)'
431 | int settimeofday(struct timeval *, void *);
| ^~~~~~~~~~~~~~~~
This happens because on Linux only HAVE_[GS]ETTIMEOFDAY is defined,
while Solaris has both that and HAVE_STRUCT_TIMEZONE, selecting
different implementations.
Fixed by casting tv to struct timeval *.
I thought about changing the signatures instead to take a struct timeval
* instead, but that seemed risky given that there's a
HAVE_STRUCT_TIMEVAL, so would probably break other targets.
Bootstrapped without regressions on i386-pc-solaris2.11,
sparc-sun-solaris2.11, and x86_64-pc-linux-gnu.
Richard Biener [Tue, 13 Feb 2024 10:38:48 +0000 (11:38 +0100)]
tree-optimization/113902 - fix VUSE update in move_early_exit_stmts
The following adjusts move_early_exit_stmts to track the last seen
VUSE instead of getting it from the last store which could be a PHI
where gimple_vuse doesn't work.
PR tree-optimization/113902
* tree-vect-loop.cc (move_early_exit_stmts): Track
last_seen_vuse for VUSE updating.
Tamar Christina [Tue, 13 Feb 2024 11:04:38 +0000 (11:04 +0000)]
middle-end: update vector loop upper bounds when early break vect [PR113734]
When doing early break vectorization we should treat the final iteration as
possibly being partial. This so that when we calculate the vector loop upper
bounds we take into account that final iteration could have done some work.
The attached testcase shows that if we don't then cunroll may unroll the loop an
if the upper bound is wrong we lose a vector iteration.
This is similar to how we adjust the scalar loop bounds for the PEELED case.
gcc/ChangeLog:
PR tree-optimization/113734
* tree-vect-loop.cc (vect_transform_loop): Treat the final iteration of
an early break loop as partial.
gcc/testsuite/ChangeLog:
PR tree-optimization/113734
* gcc.dg/vect/vect-early-break_117-pr113734.c: New test.
When __has_feature was introduced for GCC 14, I included the feature
cxx_constexpr_string_builtins, since of the relevant string builtins
that GCC implements, it seems to support constexpr evaluation of those
builtins.
However, as the PR shows, GCC doesn't implement the full list of
builtins in the clang documentation. After enumerating the builtins,
the clang docs [1] say:
> Support for constant expression evaluation for the above builtins can
> be detected with __has_feature(cxx_constexpr_string_builtins).
and a strict reading of this would suggest we can't really support
constexpr evaluation of a builtin if we don't implement the builtin in
the first place.
So the conservatively correct thing to do seems to be to stop
advertising the feature altogether to avoid failing to build code which
assumes the presence of this feature implies the presence of all the
builtins listed in the clang documentation.
Jakub Jelinek [Tue, 13 Feb 2024 09:33:08 +0000 (10:33 +0100)]
libgcc: Fix UB in FP_FROM_BITINT
As I wrote earlier, I was seeing
FAIL: gcc.dg/torture/bitint-24.c -O0 execution test
FAIL: gcc.dg/torture/bitint-24.c -O2 execution test
with the ia32 _BitInt enablement patch on i686-linux. I thought
floatbitintxf.c was miscompiled with -O2 -march=i686 -mtune=generic, but it
turned out to be UB in it.
If a signed _BitInt to be converted to binary floating point has
(after sign extension from possible partial limb to full limb) one or
more most significant limbs equal to all ones and then in the limb below
(the most significant non-~(UBILtype)0 limb) has the most significant limb
cleared, like for 32-bit limbs
0x81582c05U, 0x0a8b01e4U, 0xc1b8b18fU, 0x2aac2a08U, -1U, -1U
then bitint_reduce_prec can't reduce it to that 0x2aac2a08U limb, so
msb is all ones and precision is negative (so it reduced precision from
161 to 192 bits down to 160 bits, in theory could go as low as 129 bits
but that wouldn't change anything on the following behavior).
But still iprec is negative, -160 here.
For that case (i.e. where we are dealing with an negative input), the
code was using 65 - __builtin_clzll (~msb) to compute how many relevant
bits we have from the msb. Unfortunately that invokes UB for msb all ones.
The right number of relevant bits in that case is 1 though (like for
-2 it is 2 and -4 or -3 3 as already computed) - all we care about from that
is that the most significant bit is set (i.e. the number is negative) and
the bits below that should be supplied from the limbs below.
So, the following patch fixes it by special casing it not to invoke UB.
For msb 0 we already have a special case from before (but that is also
different because msb 0 implies the whole number is 0 given the way
bitint_reduce_prec works - even if we have limbs like ..., 0x80000000U, 0U
the reduction can skip the most significant limb and msb then would be
the one below it), so if iprec > 0, we already don't call __builtin_clzll
on 0.
2024-02-13 Jakub Jelinek <jakub@redhat.com>
* soft-fp/bitint.h (FP_FROM_BITINT): If iprec < 0 and msb is all ones,
just set n to 1 instead of using __builtin_clzll (~msb).
Jakub Jelinek [Tue, 13 Feb 2024 09:32:01 +0000 (10:32 +0100)]
hwint: Fix up preprocessor conditions for GCC_PRISZ/fmt_size_t
Using unsigned long long int for fmt_size_t and "ll" for GCC_PRISZ
as broke the gengtype on i686-linux before the libiberty fix is certainly
unexpected. size_t is there unsigned int, so expected fmt_size_t is
unsigned int (or some other 32-bit type).
The problem was that I was comparing SIZE_MAX against signed maxima,
but SIZE_MAX is unsigned maximum.
2024-02-13 Jakub Jelinek <jakub@redhat.com>
* hwint.h (GCC_PRISZ, fmt_size_t): Fix preprocessor conditions,
instead of comparing SIZE_MAX against INT_MAX and LONG_MAX compare
it against UINT_MAX and ULONG_MAX.
David Malcolm [Tue, 13 Feb 2024 02:02:09 +0000 (21:02 -0500)]
diagnostics: unbreak 'make gcc.pot'
As noted by Joseph, I broke "make gcc.pot" in r14-6057-g12b67d1e13b3cf
by adding an overloaded format API with the format string in a different
position, leading to this failure:
emit_diagnostic_valist used incompatibly as both --keyword=emit_diagnostic_valist:4
--flag=emit_diagnostic_valist:4:gcc-internal-format and --keyword=emit_diagnostic_valist:5
--flag=emit_diagnostic_valist:5:gcc-internal-format
Fix by replacing the overloaded function with one with a different name.
gcc/analyzer/ChangeLog:
* pending-diagnostic.cc (diagnostic_emission_context::warn):
Update for renaming of emit_diagnostic_valist overload to
emit_diagnostic_valist_meta.
(diagnostic_emission_context::inform): Likewise.
Jerry DeLisle [Mon, 12 Feb 2024 21:12:08 +0000 (13:12 -0800)]
libgfortran: Adjust bytes_left and pos for access="STREAM".
During tab edits, the pos (position) and bytes_used
Variables were not being set correctly for stream I/O.
Since stream I/O does not have 'real' records, the
format buffer active length must be used instead of
the record length variable.
PR libgfortran/109358
libgfortran/ChangeLog:
* io/transfer.c (formatted_transfer_scalar_write): Adjust
bytes_used and pos variable for stream access.
Paul Keir [Mon, 12 Feb 2024 18:15:49 +0000 (18:15 +0000)]
libstdc++: Fix constexpr basic_string union member [PR113294]
A call to `basic_string::clear()` in the std::string move assignment
operator leads to a constexpr error from an access of inactive union
member `_M_local_buf` in the added test (`test_move()`). Changing
`__str._M_local_buf` to `__str._M_use_local_data()` in
`operator=(basic_string&& __str)` fixes this.
PR libstdc++/113294
libstdc++-v3/ChangeLog:
* include/bits/basic_string.h (basic_string::operator=): Use
_M_use_local_data() instead of _M_local_buf on the moved-from
string.
* testsuite/21_strings/basic_string/modifiers/constexpr.cc
(test_move): New test.
Signed-off-by: Paul Keir <paul.keir@uws.ac.uk> Reviewed-by: Patrick Palka <ppalka@redhat.com> Reviewed-by: Jonathan Wakely <jwakely@redhat.com>
Jakub Jelinek [Mon, 12 Feb 2024 19:46:04 +0000 (20:46 +0100)]
lower-bitint: Fix handle_cast when used e.g. in comparisons of precisions multiple of limb_prec [PR113849]
handle_cast handles the simple way all narrowing large/huge bitint to
large/huge bitint conversions and also such widening conversions if we can
assume that the most significant limb is processed using constant index
and both lhs and rhs have same number of limbs.
But, the condition whether we can rely on the most significant limb
being processed using constant index is incorrect.
For m_upwards_2limb it was correct (m_upwards_2limb then is the number
of limbs handled by the loop, so if lhs_type has larger precision than
that, it is handled with constant index), similarly if m_var_msb is set
(on left shifts), it is never handled with constant idx. But in other
cases, like right shifts or non-equality comparisons, or bitquery operations
which operate from most significant to least significant limb, all those
can handle even the most significant limb in a loop when lhs_type has
precision which is a multiple of limb_prec.
So, the following patch punts on the optimization in that case and goes for
the conditionals in the loop for that case.
2024-02-12 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/113849
* gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Don't use
fast path for widening casts where !m_upwards_2limb and lhs_type
has precision which is a multiple of limb_prec.
The C and C++ FEs when parsing attributes already canonicalize them
(i.e. if they start with __ and end with __ substrings, we remove those).
lookup_attribute already verifies in gcc_assert that the first character
of name is not an underscore, and even lookup_scoped_attribute_spec doesn't
attempt to canonicalize the namespace it is passed. But for some historic
reason it was canonicalizing the name argument, which misbehaves when
an attribute starts with ____ and ends with ____.
I believe it is just wrong to try to canonicalize
lookup_scope_attribute_spec name attribute, it should have been
canonicalized already, in other spots where it is called it is already
canonicalized before.
2024-02-12 Jakub Jelinek <jakub@redhat.com>
PR c++/113674
* attribs.cc (extract_attribute_substring): Remove.
(lookup_scoped_attribute_spec): Don't call it.
Jakub Jelinek [Mon, 12 Feb 2024 17:51:25 +0000 (18:51 +0100)]
testsuite: Fix up gcc.dg/pr113693.c for ia32
As I wrote earlier and we've discussed on IRC, with the ia32 _BitInt
enablement patch this testcase FAILs on ia32, there is nothing vectorized in
there, even with -mavx512{vl,bw,dq}, so no dbgcnt messages are emitted.
The following patch instead prunes it.
2024-02-12 Jakub Jelinek <jakub@redhat.com>
* gcc.dg/pr113693.c: Guard _BitInt(837) use with
__BITINT_MAXWIDTH__ >= 837. Use dg-prune-output instead of
dg-message for dbgcnt message.
Jakub Jelinek [Mon, 12 Feb 2024 17:50:16 +0000 (18:50 +0100)]
libiberty: Fix up libiberty_vprintf_buffer_size
When writing the HOST_SIZE_T_PRINT_UNSIGNED incremental patch,
my first bootstrap failed on i686-linux. That is because I've also had
@@ -1344,8 +1344,10 @@ adjust_field_rtx_def (type_p t, options_
}
subfields = create_field (subfields, t,
- xasprintf (".fld[%lu].%s",
- (unsigned long) aindex,
+ xasprintf (".fld["
+ HOST_SIZE_T_PRINT_UNSIGNED
+ "].%s",
+ (fmt_size_t) aindex,
subname));
subfields->opt = nodot;
if (t == note_union_tp)
hunk in gengtype.cc. While sprintf obviously can print in this case %llu
with fmt_size_t being unsigned long long (that is another bug I'll fix
incrementally), seems libiberty_vprintf_buffer_size
can't deal with that, it ignores h, hh, l, ll and L modifiers and
unconditionally, estimates 30 chars as upper bounds for integers (that is
fine) and then uses (void) va_arg (ap, int); to skip over the argument
regardless if it was %d, %ld, %lld, %hd, %hhd etc.
Now, on x86_64 that happens to work fine probably for all of those,
on ia32 for everything but %lld, because it then skips just one half
of the long long argument; now as there is %s after it, it will try to
compute strlen not from the pointer argument corresponding to %s, but
from the most significant half of the previous long long argument.
So, the following patch attempts not to completely ignore the modifiers,
but figure out from them whether to va_arg an int (used for h and hh as
well), or long, or long long, or size_t, or ptrdiff_t - added support for
z and t there, plus for Windows I64. And also %Lf etc. for long double.
2024-02-12 Jakub Jelinek <jakub@redhat.com>
* vprintf-support.c (libiberty_vprintf_buffer_size): Handle
properly l, ll, z, t or on _WIN32 I64 modifiers for diouxX
and L modifier for fFgGeE.
Iain Buclaw [Sun, 4 Feb 2024 21:04:14 +0000 (22:04 +0100)]
d: Fix callee destructor call invalidates the live object [PR113758]
When generating the argument, check the isCalleeDestroyingArgs hook, and
force a TARGET_EXPR to be created if true, so that a reference to the
live object isn't passed directly to the function that runs dtors.
When instead dealing with caller running destructors, two temporaries
were being generated, one explicit temporary generated by the D
front-end, and another implicitly by the code generator. This has been
reduced to one by setting DECL_VALUE_EXPR on the explicit temporary to
bind it to the implicit slot created for the TARGET_EXPR, as that has
the shorter lifetime of the two.
PR d/113758
gcc/d/ChangeLog:
* d-codegen.cc (d_build_call): Force a TARGET_EXPR when callee
destorys its arguments.
* decl.cc (DeclVisitor::visit (VarDeclaration *)): Set
SET_DECL_VALUE_EXPR on the temporary variable to make it a placeholder
for the TARGET_EXPR_SLOT.
Christophe Lyon [Sat, 10 Feb 2024 21:17:08 +0000 (21:17 +0000)]
gcc/Makefile.in: Always check info dependencies
BUILD_INFO is currently a byproduct of checking makeinfo
presence/version. INSTALL_INFO used to be defined similarly, but was
removed in 2000 (!) by commit 17db658241d18cf6db59d31bc2d6eac96e9257df
(svn r38141).
In order to save build time, our CI overrides MAKEINFO=echo, which
works when invoking 'make all' but not for 'make install' in case some
info files need an update.
I noticed this while testing a patch posted on the gcc-patches list,
leading to an error at 'make install' time after updating tm.texi (the
build reported 'new text' in tm.texi and stopped). This is because
'install' depends on 'install-info', which depends on
$(DESTDIR)$(infodir)/gccint.info (among others).
As discussed, it is better to detect this problem during 'make all'
rather than 'make install', and we still want to detect it even if
makeinfo is not available.
This patch makes configure set BUILD_INFO=no-info in case makeinfo is
missing/too old, which effectively makes the build rules no-ops
(x$(BUILD_INFO) != xinfo), and updates Makefile.in so that 'info'
dependencies are still checked.
git://gcc.gnu.org / gcc.git / log