We crash compiling this test since r11-7993 which changed
lookup_template_class_1 so that we only call tsubst_enum when
!uses_template_parms (current_nonlambda_scope ())
But here current_nonlambda_scope () is the global NAMESPACE_DECL ::, which
doesn't have a type, therefore is considered type-dependent. So we don't
call tsubst_enum, and crash in tsubst_copy/CONST_DECL because we didn't
find the e1 enumerator.
I don't think any namespace can depend on any template parameter, so
this patch tweaks uses_template_parms.
PR c++/105398
gcc/cp/ChangeLog:
* pt.cc (uses_template_parms): Return false for any NAMESPACE_DECL.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/lambda-generic-enum2.C: New test.
On Wed, Apr 27, 2022 at 12:02:33PM +0200, Richard Biener wrote:
> I did that but the reduction result did not resemble the same failure
> mode. I've failed to manually construct a testcase as well. Possibly
> a testcase using libstdc++ but less Qt internals might be possible.
Here is a testcase that I've managed to reduce, FAILs with:
FAIL: g++.dg/warn/pr104492.C -std=gnu++14 (test for bogus messages, line 111)
FAIL: g++.dg/warn/pr104492.C -std=gnu++17 (test for bogus messages, line 111)
FAIL: g++.dg/warn/pr104492.C -std=gnu++20 (test for bogus messages, line 111)
on both x86_64-linux and i686-linux without your commit and passes with it.
2022-04-27 Jakub Jelinek <jakub@redhat.com>
PR middle-end/104492
* g++.dg/warn/pr104492.C: New test.
gcc/testsuite/ChangeLog:
PR fortran/70673
PR fortran/78054
* gfortran.dg/pr70673.f90: Remove invalid statement.
* gfortran.dg/pr70673_2.f90: New test to check that
ICE does not re-appear.
The following patch updates baseline_symbols.txt on arches where I have
latest libstdc++ builds (my ws + Fedora package builds).
I've manually excluded:
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11ItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IxEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIcSt19istreambuf_iteratorIcSt11char_traitsIcEEE14_M_extract_intB5cxx11IyEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IjEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IlEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11ImEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11ItEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IxEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
+FUNC:_ZNKSt17__gnu_cxx_ieee1287num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE14_M_extract_intB5cxx11IyEES4_S4_S4_RSt8ios_baseRSt12_Ios_IostateRT_@@GLIBCXX_IEEE128_3.4.29
additions on ppc64le as those look unexpected.
Those symbols didn't show up in Fedora 11.3.1 build with recent glibc,
while other GLIBCXX_IEEE128_3.4.29 symbols are in 11.x already.
What this patch includes are only @@GLIBCXX_3.4.30 symbol additions, same
symbols on all files, except that powerpc64 adds also
_ZNSt17__gnu_cxx_ieee12816__convert_from_vERKP15__locale_structPciPKcz@@GLIBCXX_IEEE128_3.4.30
so everything included in the patch looks right to me.
2022-04-27 Jakub Jelinek <jakub@redhat.com>
* config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Update.
* config/abi/post/i486-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Update.
* config/abi/post/powerpc64-linux-gnu/32/baseline_symbols.txt: Update.
For the atomic specializations for shared_ptr and weak_ptr we can reuse
the existing SharedPointerPrinter, with a small tweak.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (SharedPointerPrinter): Add
support for atomic<shared_ptr<T>> and atomic<weak_ptr<T>>.
(StdAtomicPrinter): New printer.
(build_libstdcxx_dictionary): Register new printer.
* testsuite/libstdc++-prettyprinters/cxx11.cc: Test std::atomic.
* testsuite/libstdc++-prettyprinters/cxx20.cc: Test atomic smart
pointers.
Commit 621cccba3f broke the Ada build for all
RTEMS targets except aarch64.
gcc/ada/
* tracebak.c: Add support for ARM RTEMS. Add support for RTEMS to PPC
ELF. Add support for RTEMS to SPARC. Merge aarch64 support of Linux
and RTEMS.
The following extends the equality compare dangling pointer diagnostics
suppression for uses following free or realloc to also cover those
following invalidation of auto variables via CLOBBERs. That avoids
diagnosing idioms like
return std::find(std::begin(candidates), std::end(candidates), s)
!= std::end(candidates);
for auto candidates which are prone to forwarding of the final
comparison across the storage invalidation as then seen by the
late run access warning pass.
2022-04-25 Richard Biener <rguenther@suse.de>
PR middle-end/104492
* gimple-ssa-warn-access.cc
(pass_waccess::warn_invalid_pointer): Exclude equality compare
diagnostics for all kind of invalidations.
(pass_waccess::check_dangling_uses): Fix post-dominator query.
(pass_waccess::check_pointer_uses): Likewise.
Starting with r12-8235-gfa5cd7102da676dcb1757b1288421f5f3439ae0e,
class descriptor types are compared to detect duplicate declarations.
This caused ICEs as the comparison of array spec supported only constant
explicit bounds, but dummy class variable descriptor types can have a
_data field with non-constant array spec bounds.
This change adds support for non-constant bounds. For that,
gfc_dep_compare_expr is used. It does probably more than strictly
necessary, but using it avoids rewriting a specific comparison function,
making mistakes and forgetting cases.
PR fortran/103662
PR fortran/105379
gcc/fortran/ChangeLog:
* array.cc (compare_bounds): Use bool as return type.
Support non-constant expressions.
(gfc_compare_array_spec): Update call to compare_bounds.
gcc/testsuite/ChangeLog:
* gfortran.dg/class_dummy_8.f90: New test.
* gfortran.dg/class_dummy_9.f90: New test.
Dummy array decls are local decls different from the argument decl
accessible through GFC_DECL_SAVED_DESCRIPTOR. If the argument decl has
a DECL_LANG_SPECIFIC set, it is copied over to the local decl at the
time the latter is created, so that the DECL_LANG_SPECIFIC object is
shared between local dummy decl and argument decl, and thus the
GFC_DECL_SAVED_DESCRIPTOR of the argument decl is the argument decl
itself.
The r12-8230-g7964ab6c364c410c34efe7ca2eba797d36525349 change introduced
the non_negative_strides_array_p predicate which recurses through
GFC_DECL_SAVED_DESCRIPTOR to avoid seeing dummy decls as purely local
decls. As the GFC_DECL_SAVED_DESCRIPTOR of the argument decl is itself,
this can cause infinite recursion.
This change adds a check to avoid infinite recursion.
PR fortran/102043
PR fortran/105381
gcc/fortran/ChangeLog:
* trans-array.cc (non_negative_strides_array_p): Inline variable
orig_decl and merge nested if conditions. Add condition to not
recurse if the next argument is the same as the current.
gcc/testsuite/ChangeLog:
* gfortran.dg/character_array_dummy_1.f90: New test.
As discussed in the PR, here is the testcase with the appropriate dg-*
directives.
Tested on arm-none-eabi with
1 -mcpu=cortex-a7/-mfloat-abi=soft/-march=armv7ve+simd
2 -mcpu=cortex-a7/-mfloat-abi=hard/-march=armv7ve+simd
3 -mthumb/-mcpu=cortex-a7/-mfloat-abi=hard/-march=armv7ve+simd
4 -mthumb/-mfloat-abi=soft/-march=armv6s-m
5 -mthumb/-mfloat-abi=soft/-march=armv7-m
6 -mthumb/-mfloat-abi=hard/-march=armv7e-m+fp
7 -mthumb/-mfloat-abi=hard/-march=armv7e-m+fp.dp
8 -mthumb/-mfloat-abi=hard/-march=armv8-m.main+fp+dsp
9 -mthumb/-mfloat-abi=hard/-march=armv8.1-m.main+mve.fp+fp.dp
10 -mthumb/-mfloat-abi=hard/-march=armv8.1-m.main+mve
The test is UNSUPPORTED with the first three ones (because of
-mcpu=cortex-a7), ignored with armv6s-m, and PASSes with all the other
ones, while it used crash without Jakub's fix (r12-8263), ie. FAIL
with options 5,6,7,8,10. The test passed without Jakub's fix with
option 9 because the problem happens only with an integer-only MVE.
2022-04-26 Christophe Lyon <christophe.lyon@arm.com>
gcc/testsuite/
PR tree-optimization/105374
* gcc.target/arm/simd/pr105374.C: New.
For IBM Z in particular there is a problem with structs like:
struct A { float a; int :0; };
Our ABI document allows passing a struct in an FPR only if it has
exactly one member. On the other hand it says that structs of 1,2,4,8
bytes are passed in a GPR. So this struct is expected to be passed in
a GPR. Since we don't return structs in registers (regardless of the
number of members) it is always returned in memory.
Situation is as follows:
All compiler versions tested return it in memory - as expected.
gcc 11, gcc 12, g++ 12, and clang 13 pass it in a GPR - as expected.
g++ 11 as well as clang++ 13 pass in an FPR
For IBM Z we stick to the current GCC 12 behavior, i.e. zero-width
bitfields are NOT ignored. A struct as above will be passed in a
GPR. Rational behind this is that not affecting the C ABI is more
important here.
A patch for clang is in progress: https://reviews.llvm.org/D122388
In addition to the usual regression test I ran the compat and
struct-layout-1 testsuites comparing the compiler before and after the
patch.
gcc/ChangeLog:
PR target/102024
* config/s390/s390-protos.h (s390_function_arg_vector): Remove
prototype.
* config/s390/s390.cc (s390_single_field_struct_p): New function.
(s390_function_arg_vector): Invoke s390_single_field_struct_p.
(s390_function_arg_float): Likewise.
gcc/testsuite/ChangeLog:
PR target/102024
* g++.target/s390/pr102024-1.C: New test.
* g++.target/s390/pr102024-2.C: New test.
* g++.target/s390/pr102024-3.C: New test.
* g++.target/s390/pr102024-4.C: New test.
* g++.target/s390/pr102024-5.C: New test.
* g++.target/s390/pr102024-6.C: New test.
On the following testcase, we have in main's frame 3 variables,
some red zone padding, 4 byte d, followed by 12 bytes of red zone padding, then
8 byte b followed by 24 bytes of red zone padding, then 40 bytes c followed
by some red zone padding.
The intended content of shadow memory for that is (note, each byte describes
8 bytes of memory):
f1 f1 f1 f1 04 f2 00 f2 f2 f2 00 00 00 00 00 f3 f3 f3 f3 f3
left red d mr b middle r c right red zone
f1 is left red zone magic
f2 is middle red zone magic
f3 is right red zone magic
00 when all 8 bytes are accessible
01-07 when only 1 to 7 bytes are accessible followed by inaccessible bytes
The -fdump-rtl-expand-details dump makes it clear that it misbehaves:
Flushing rzbuffer at offset -160 with: f1 f1 f1 f1
Flushing rzbuffer at offset -128 with: 04 f2 00 00
Flushing rzbuffer at offset -128 with: 00 00 00 f2
Flushing rzbuffer at offset -96 with: f2 f2 00 00
Flushing rzbuffer at offset -64 with: 00 00 00 f3
Flushing rzbuffer at offset -32 with: f3 f3 f3 f3
In the end we end up with
f1 f1 f1 f1 00 00 00 f2 f2 f2 00 00 00 00 00 f3 f3 f3 f3 f3
shadow bytes because at offset -128 there are 2 overlapping stores
as asan_redzone_buffer::emit_redzone_byte has flushed the temporary 4 byte
buffer in the middle.
The function is called with an offset and value. If the passed offset is
consecutive with the prev_offset + buffer size (off == offset), then
we handle it correctly, similarly if the new offset is far enough from the
old one (we then flush whatever was in the buffer and if needed add up to 3
bytes of 00 before actually pushing value.
But what isn't handled correctly is when the offset isn't consecutive to
what has been added last time, but it is in the same 4 byte word of shadow
memory (32 bytes of actual memory), like the above case where
we have consecutive 04 f2 and then skip one shadow memory byte (aka 8 bytes
of real memory) and then want to emit f2. Emitting that as a store
of little-endian 0x0000f204 followed by a store of 0xf2000000 to the same
address doesn't work, we want to emit 0xf200f204.
The following patch does that by pushing 1 or 2 00 bytes.
Additionally, as a small cleanup, instead of using
m_shadow_bytes.safe_push (value);
flush_if_full ();
in all of if, else if and else bodies it sinks those 2 stmts to the end
of function as all do the same thing.
2022-04-27 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/105396
* asan.cc (asan_redzone_buffer::emit_redzone_byte): Handle the case
where offset is bigger than off but smaller than m_prev_offset + 32
bits by pushing one or more 0 bytes. Sink the
m_shadow_bytes.safe_push (value); flush_if_full (); statements from
all cases to the end of the function.
* gcc.dg/asan/pr105396.c: New test.
As PR105271 shows, __builtin_altivec_neg_v2di requires option
-mpower8-vector as its pattern expansion relies on subv2di which
has guard VECTOR_UNIT_P8_VECTOR_P (V2DImode). This fix is to move
the related lines for __builtin_altivec_neg_v2di to the section
of stanza power8-vector.
PR target/105271
gcc/ChangeLog:
* config/rs6000/rs6000-builtins.def (NEG_V2DI): Move to [power8-vector]
stanza.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr105271.c: New test.
Here we were failing to diagnose that the initializer for the capture pack
is an unresolved overload. It turns out that the reason we didn't recognize
the deduction failure in do_auto_deduction was that the individual 'auto' in
the expansion of the capture pack was still marked as a parameter pack, so
we were deducing it to an empty pack instead of failing.
PR c++/102629
gcc/cp/ChangeLog:
* pt.cc (gen_elem_of_pack_expansion_instantiation): Clear
TEMPLATE_TYPE_PARAMETER_PACK on auto.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/lambda-pack-init7.C: New test.
We need to pass tf_decltype when instantiating a non-dependent decltype
operand, like tsubst does in the dependent case, so that we don't force
completion of a prvalue operand's class type.
PR c++/105386
gcc/cp/ChangeLog:
* semantics.cc (finish_decltype_type): Pass tf_decltype to
instantiate_non_dependent_expr_sfinae.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/decltype81.C: New test.
Properly parse OPT_fdiagnostics_urls_ and then initialize both urls
and colors for global_dc. Doing that we would follow the configure
option --with-documentation-root-url, -fdiagnostics-urls is respected.
Plus we'll print colored warning and note messages.
PR lto/105364
gcc/ChangeLog:
* lto-wrapper.cc (print_lto_docs_link): Use global_dc.
(run_gcc): Parse OPT_fdiagnostics_urls_.
(main): Initialize global_dc.
Fixes a segfault seen on Darwin when a GC scan is ran after a thread has
been destroyed. As the global emutlsArrays hash still has a reference
to the array itself, and tries to iterate all elements.
Setting the length to zero frees all allocated elements in the array,
and ensures that it is skipped when the _d_emutls_scan is called.
libphobos/ChangeLog:
* libdruntime/gcc/emutls.d (emutlsDestroyThread): Clear the per-thread
TLS array, don't call free().
This DR was approved at the February 2022 plenary.
libstdc++-v3/ChangeLog:
* include/bits/shared_ptr_atomic.h (atomic<shared_ptr>): Add
constructor for constant initialization from nullptr_t.
* testsuite/20_util/shared_ptr/atomic/atomic_shared_ptr.cc:
Check for new constructor.
This DR was approved at the February 2022 plenary.
libstdc++-v3/ChangeLog:
* include/bits/fs_path.h (hash<filesystem::path>): Define.
* testsuite/27_io/filesystem/path/nonmember/hash_value.cc:
Check std::hash specialization.
The following testcase regressed on riscv due to the splitting of critical
edges in the sink pass, similarly to x86_64 compared to GCC 11 we now swap
the edges, whether true or false edge goes to an empty forwarded bb.
From GIMPLE POV, those 2 forms are equivalent, but as can be seen here, for
some ifcvt opts it matters one way or another.
On this testcase, noce_try_store_flag_mask used to trigger and transformed
if (pseudo2) pseudo1 = 0;
into
pseudo1 &= -(pseudo2 == 0);
But with the swapped edges ifcvt actually sees
if (!pseudo2) pseudo3 = pseudo1; else pseudo3 = 0;
and noce_try_store_flag_mask punts. IMHO there is no reason why it
should punt those, it is equivalent to
pseudo3 = pseudo1 & -(pseudo2 == 0);
and especially if the target has 3 operand AND, it shouldn't be any more
costly (and even with 2 operand AND, it might very well happen that RA
can make it happen without any extra moves).
Initially I've just removed the rtx_equal_p calls from the conditions
and didn't add anything there, but that broke aarch64 bootstrap and
regressed some testcases on x86_64, where if_info->a or if_info->b could be
some larger expression that we can't force into a register.
Furthermore, the case where both if_info->a and if_info->b are constants is
better handled by other ifcvt optimizations like noce_try_store_flag
or noce_try_inverse_constants or noce_try_store_flag_constants.
So, I've restricted it to just a REG (perhaps SUBREG of REG might be ok too)
next to what has been handled previously.
2022-04-26 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/105314
* ifcvt.cc (noce_try_store_flag_mask): Don't require that the non-zero
operand is equal to if_info->x, instead use the non-zero operand
as one of the operands of AND with if_info->x as target.
* gcc.target/riscv/pr105314.c: New test.
As mentioned in the PR, we ICE because maybe_fold_*_comparisons returns
an expression with V4SImode type and we try to fold_convert it to
V4BImode, which isn't allowed.
IMHO no matter whether we change maybe_fold_*_comparisons we should
play safe on the reassoc side and punt if we can't convert like
we punt for many other reasons. This fixes the testcase on ARM.
Testcase not included, not exactly sure where and what directives it
should have in gcc.target/arm/ testsuite. Christophe, do you think you
could handle that incrementally?
2022-04-26 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/105374
* tree-ssa-reassoc.cc (eliminate_redundant_comparison): Punt if
!fold_convertible_p rather than assuming fold_convert must succeed.
This test fails on i686-linux:
Excess errors:
.../gcc/testsuite/g++.target/i386/vec-tmpl1.C:13:27: warning: SSE vector return without SSE enabled changes the ABI [-Wpsabi]
2022-04-26 Jakub Jelinek <jakub@redhat.com>
PR c++/65211
* g++.target/i386/vec-tmpl1.C: Add -Wno-psabi as
dg-additional-options.
The following testcase ICEs, because conversion between scalar float types
which have the same mode are useless in GIMPLE, but for mathfn_built_in the
exact type matters (it treats say double and _Float64 or float and _Float32
differently, using different suffixes and for the _Float* sometimes
returning NULL when float/double do have a builtin).
In ix86_veclibabi_{svml,acml} we are using mathfn_built_in just so that
we don't have to translate the combined_fn and SFmode vs. DFmode into
strings ourselfs, and we already earlier punt on anything but SFmode and
DFmode. So, this patch just uses the double or float types depending
on the modes, rather than the types we actually got and which might be
_Float64 or _Float32 etc.
2022-04-26 Jakub Jelinek <jakub@redhat.com>
PR target/105367
* config/i386/i386.cc (ix86_veclibabi_svml, ix86_veclibabi_acml): Pass
el_mode == DFmode ? double_type_node : float_type_node instead of
TREE_TYPE (type_in) as first arguments to mathfn_built_in.
* gcc.target/i386/pr105367.c: New test.
On Mon, Apr 25, 2022 at 01:38:25PM +0200, Mikael Morin wrote:
> I have just pushed the attached fix for two UNRESOLVED checks at -O0 that I
> hadn’t seen.
I don't like forcing of DSE in -O0 compilation, wouldn't it be better
to just not check the dse dump at -O0 like in the following patch?
Even better would be to check that the z._data = stores are both present
in *.optimized dump, but that doesn't really work at -O2 or above because
we inline the functions and optimize it completely away (both the stores
and corresponding reads).
The first hunk is needed so that __OPTIMIZE__ effective target works in
Fortran testsuite, otherwise one gets a pedantic error and __OPTIMIZE__
is considered not to match at all.
2022-04-26 Jakub Jelinek <jakub@redhat.com>
PR fortran/103662
* lib/target-supports.exp (check_effective_target___OPTIMIZE__): Add
a var definition to avoid pedwarn about empty translation unit.
* gfortran.dg/unlimited_polymorphic_3.f03: Remove -ftree-dse from
dg-additional-options, guard scan-tree-dump-not directives on
__OPTIMIZE__ target.
Last fall I've changed struct gomp_work_share, so that it doesn't have
__attribute__((aligned (64))) lock member in the middle unless the target has
non-emulated aligned allocator, otherwise it just makes sure the first and
second halves are 64 bytes appart for cache line reasons, but doesn't make
the struct 64-byte aligned itself and so we can use normal allocators for it.
When the struct isn't 64-byte aligned, the amount of tail padding significantly
decreases, to 0 or 4 bytes or so. The library uses that tail padding when
the ordered_teams_ids array (array of uints) and/or the memory for lastprivate
conditional temporaries (the latter wants to guarantee long long alignment).
The problem with it on ia32 darwin9 is that while the struct contains
long long members, long long is just 4 byte aligned while __alignof__(long long)
is 8. That causes problems in gomp_init_work_share, where we currently rely on
if offsetof (struct gomp_work_share, inline_ordered_team_ids) is long long
aligned, then that tail array will be aligned at runtime and so no extra
memory for dynamic realignment will be needed (that is false when the whole
struct doesn't have long long alignment). And also in the remaining hunks
causes another problem, where we compute INLINE_ORDERED_TEAM_IDS_OFF
as the above offsetof aligned up to long long boundary and subtract
sizeof (struct gomp_work_share) and INLINE_ORDERED_TEAM_IDS_OFF.
When unlucky, the former isn't multiple of 8 and the latter is 4 bigger
than that and as the subtraction is done in size_t, we end up with (size_t) -4,
so the comparison doesn't really work.
The fixes add additional conditions to make it work properly, but all of them
should be evaluated at compile time when optimizing and so shouldn't slow
anything.
2022-04-26 Jakub Jelinek <jakub@redhat.com>
PR libgomp/105358
* work.c (gomp_init_work_share): Don't mask of adjustment for
dynamic long long realignment if struct gomp_work_share has smaller
alignof than long long.
* loop.c (GOMP_loop_start): Don't use inline_ordered_team_ids if
struct gomp_work_share has smaller alignof than long long or if
sizeof (struct gomp_work_share) is smaller than
INLINE_ORDERED_TEAM_IDS_OFF.
* loop_ull.c (GOMP_loop_ull_start): Likewise.
* sections.c (GOMP_sections2_start): Likewise.
Parameter packs from the enclosing context can be used unexpanded in a
lambda that is itself part of a pack expansion, but not packs that are part
of the lambda itself. We already check for capture packs; we also need to
check for function parameter packs of the lambda call operator.
PR c++/104624
gcc/cp/ChangeLog:
* pt.cc (check_for_bare_parameter_packs): Check for lambda
function parameter pack.
gcc/testsuite/ChangeLog:
* g++.dg/cpp1y/lambda-generic-variadic22.C: New test.
Here we're crashing from verify_sequence_points for this requires-expr
condition because it contains a templated CAST_EXPR with empty operand,
and verify_tree doesn't ignore this empty operand only because the
manual tail recursion that it performs for unary expression trees skips
the NULL test.
PR c++/105304
gcc/c-family/ChangeLog:
* c-common.cc (verify_tree) [restart]: Move up to before the
NULL test.
gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/concepts-requires30.C: New test.
Here ever since r11-6483-ge2e2f3f2c9400f we're rejecting and crashing
on (respectively) two testcases that we used to accept in C++17 mode
since r8-1437-g3da557ec145823. Both testcases declare a partial
specialization of a primary template that has an NTTP with dependent
type, and the validity of these partial specializations is unclear and
the subject of PR86193 / CWG 455.
So for now, this minimal patch just aims to fix the crash in the second
testcase. During deduction, when checking whether the type of an NTTP
uses still-undeduced parameters, we were incorrectly substituting into
the previously substituted type instead of into its original type.
In passing this patch also downgrades the "not more specialized"
diagnostic from a permerror to a pedwarn.
PR c++/105289
PR c++/86193
gcc/cp/ChangeLog:
* pt.cc (process_partial_specialization): Downgrade "partial
specialization isn't more specialized" diagnostic from permerror
to an on-by-default pedwarn.
(unify) <case TEMPLATE_PARM_INDEX>: When substituting into the
NTTP type a second time, use the original type not the
substituted type.
gcc/testsuite/ChangeLog:
* g++.dg/template/partial-specialization11.C: New test.
* g++.dg/template/partial-specialization12.C: New test.
PR analyzer/104308 initially reported about a
-Wanalyzer-use-of-uninitialized-value diagnostic using UNKNOWN_LOCATION
when complaining about certain memmove operations where the source
is uninitialized.
In r12-7856-g875342766d4298 I fixed the missing location for
a stmt generated by gimple_fold_builtin_memory_op, but the reporter
then found another way to generate such a stmt with UNKNOWN_LOCATION.
I've now gone through gimple_fold_builtin_memory_op looking at all
statement creation, and found three places in which a new statement
doesn't have a location set on it (either directly via
gimple_set_location, or indirectly via gsi_replace), one of which is
the new reproducer.
This patch adds a gimple_set_location to these three cases, and adds
test coverage for one of them (the third hunk within the patch), fixing
the new reproducer for PR analyzer/104308.
gcc/ChangeLog:
PR analyzer/104308
* gimple-fold.cc (gimple_fold_builtin_memory_op): Explicitly set
the location of new_stmt in all places that don't already set it,
whether explicitly, or via a call to gsi_replace.
gcc/testsuite/ChangeLog:
PR analyzer/104308
* gcc.dg/analyzer/pr104308.c: Add test coverage.
Signed-off-by: David Malcolm <dmalcolm@redhat.com>
So that move_sese_region_to_fn works properly, OpenMP/OpenACC constructs
for which that function is invoked need an extra artificial BIND_EXPR
around their body so that we move all variables of the bodies.
The C/C++ FEs do that both for OpenMP constructs like OMP_PARALLEL, OMP_TASK
or OMP_TARGET and for OpenACC constructs that behave similarly to
OMP_TARGET, but the Fortran FE only does that for OpenMP constructs.
The following patch does that for OpenACC constructs too.
PR fortran/104717
gcc/fortran/
* trans-openmp.cc (gfc_trans_oacc_construct): Wrap construct body
in an extra BIND_EXPR.
gcc/testsuite/
* gfortran.dg/goacc/pr104717.f90: New test.
* gfortran.dg/goacc/privatization-1-compute-loop.f90: Adjust.
libgomp/
* testsuite/libgomp.oacc-fortran/privatized-ref-2.f90: Adjust.
Co-authored-by: Thomas Schwinge <thomas@codesourcery.com>
Filter out:
libcpp/lex.cc:1289:7: warning: use of the 'likely' attribute is a C++20 extension [-Wc++20-attribute-extensions]
contrib/ChangeLog:
* filter-clang-warnings.py: Filter out
-Wc++20-attribute-extensions in lex.cc.
libstdc++-v3/ChangeLog:
* include/bits/ptr_traits.h (__cpp_lib_constexpr_memory): Define
conditionally.
* include/bits/unique_ptr.h (__cpp_lib_constexpr_memory):
Define for C++23.
(default_delete, default_delete<T[]>, __uniq_ptr_impl)
(unique_ptr, unique_ptr<T[], D>): Add constexpr to all member
functions.
* include/std/version (__cpp_lib_constexpr_memory): Define new
value for C++23.
* testsuite/20_util/unique_ptr/assign/constexpr.cc: New test.
* testsuite/20_util/unique_ptr/comparison/constexpr.cc: New test.
* testsuite/20_util/unique_ptr/cons/constexpr_c++20.cc: New test.
* testsuite/20_util/unique_ptr/creation/constexpr.cc: New test.
* testsuite/20_util/unique_ptr/modifiers/constexpr.cc: New test.
* testsuite/20_util/unique_ptr/specialized_algorithms/constexpr.cc:
New test.
This change was LWG 3117.
The test is copied from 20_util/function/cons/deduction.cc
libstdc++-v3/ChangeLog:
PR libstdc++/105375
* include/std/future (packaged_task): Add deduction guides.
* testsuite/30_threads/packaged_task/cons/deduction.cc: New test.
Here we issue an error from c_build_shufflevector while parsing a template
because it got a TEMPLATE_PARM_INDEX, but this function expects INTEGER_CSTs
(except the first two arguments). It checks if any of the arguments are
type-dependent, if so, we leave the processing for later, but it should
also check value-dependency for the 3rd+ arguments, so as to avoid the
problem above.
This is not a regression -- __builtin_shufflevector was introduced in
GCC 12, but it looks safe enough.
PR c++/105353
gcc/cp/ChangeLog:
* typeck.cc (build_x_shufflevector): Use
instantiation_dependent_expression_p except for the first two
arguments.
gcc/testsuite/ChangeLog:
* g++.dg/ext/builtin-shufflevector-3.C: New test.
In commit a2a919aa50 (2003), built-ins for modf and modff were added.
In extend.texi, section "Other Builtins", "modf" was added to the paragraph
"There are also built-in versions of the ISO C99 functions [...]" and
"modf" was also added to the paragraph "The ISO C90 functions [...]".
"modff" was not added to either paragraph.
Based on the context clues about where "modfl" and other similar function
pairs like "powf/powl" appear, I believe the reference to "modf" in the
first paragraph (C99) should instead be "modff".
2022-04-25 Paul A. Clarke <pc@us.ibm.com>
gcc
* doc/extend.texi (Other Builtins): Correct reference to 'modff'.
When range_of_stmt was adjusted to avoid large recursion depth, we need to
intersect the calculated range whth the any known range to avoid losing
info. Range_of_stmt does this, but the new prefill code missed it.
PR tree-optimization/105276
gcc/
* gimple-range.cc (gimple_ranger::prefill_stmt_dependencies): Include
existing global range with calculated value.
gcc/testsuite/
* g++.dg/pr105276.C: New.
Re-using the std::span printer, this now shows the contents of the
initializer list instead of the pointer and length members.
Signed-off-by: Philipp Fent <fent@in.tum.de>
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (StdSpanPrinter._iterator):
Rename as iterator.
(StdInitializerListPrinter): Define new printer.
(build_libstdcxx_dictionary): Register new printer.
* testsuite/libstdc++-prettyprinters/cxx11.cc: Check printer for
initializer_list.
