[Bug target/112959] install.tex needs updates on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112959 --- Comment #2 from GCC Commits --- The trunk branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:507f3ce34c55e78b23eeaf57bc4d927a1f25f8fb commit r15-24-g507f3ce34c55e78b23eeaf57bc4d927a1f25f8fb Author: Gerald Pfeifer Date: Sun Apr 28 14:59:14 2024 +0200 doc: Remove references to FreeBSD 7 and older FreeBSD 7 has been end of life for years and current GCC most likely would not build there anymore anyways. gcc: PR target/69374 PR target/112959 * doc/install.texi (Specific) <*-*-freebsd*>: Remove references to FreeBSD 7 and older.
[Bug target/69374] install.texi is bit-rotten
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69374 --- Comment #7 from GCC Commits --- The trunk branch has been updated by Gerald Pfeifer : https://gcc.gnu.org/g:507f3ce34c55e78b23eeaf57bc4d927a1f25f8fb commit r15-24-g507f3ce34c55e78b23eeaf57bc4d927a1f25f8fb Author: Gerald Pfeifer Date: Sun Apr 28 14:59:14 2024 +0200 doc: Remove references to FreeBSD 7 and older FreeBSD 7 has been end of life for years and current GCC most likely would not build there anymore anyways. gcc: PR target/69374 PR target/112959 * doc/install.texi (Specific) <*-*-freebsd*>: Remove references to FreeBSD 7 and older.
[Bug target/58684] powerpc uses only unordered floating-point compares
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58684 --- Comment #11 from GCC Commits --- The master branch has been updated by Alexandre Oliva : https://gcc.gnu.org/g:6e95dca31c6b4688e0f0a25c9c3aa8a0bedc9056 commit r15-20-g6e95dca31c6b4688e0f0a25c9c3aa8a0bedc9056 Author: Alexandre Oliva Date: Sun Apr 28 04:30:24 2024 -0300 xfail fetestexcept test - ppc always uses fcmpu gcc.dg/torture/pr91323.c tests that a compare with NaNf doesn't set an exception using builtin compare intrinsics, and that it does when using regular compare operators. That doesn't seem to be expected to work on powerpc targets. It fails on GNU/Linux, it's marked to be skipped on AIX, and a similar test, gcc.dg/torture/pr93133.c, has the execution test xfailed for all of powerpc*-*-*. In this test, the functions that use intrinsics for the compare end up with the same code as the one that uses compare operators, using fcmpu, a floating compare that, unlike fcmpo, does not set the invalid operand exception for quiet NaN. I couldn't find any evidence that the rs6000 backend ever outputs fcmpo. Therefore, I'm adding the same execution xfail marker to this test. for gcc/testsuite/ChangeLog PR target/58684 * gcc.dg/torture/pr91323.c: Expect execution fail on powerpc*-*-*.
[Bug target/95782] [s390] ICE in _cpp_pop_context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95782 --- Comment #4 from GCC Commits --- The master branch has been updated by Jiu Fu Guo : https://gcc.gnu.org/g:83bc41e8364360b63eaa59c88e2fb499a6751233 commit r15-14-g83bc41e8364360b63eaa59c88e2fb499a6751233 Author: Jiufu Guo Date: Wed Mar 27 14:15:40 2024 +0800 s390: avoid peeking eof after __vector Same like PR101168, it is need for s390 to avoid peeking eof after vector keyword. And similar test case is also ok for s390. PR target/95782 gcc/ChangeLog: * config/s390/s390-c.cc (s390_macro_to_expand): Avoid empty identifier. gcc/testsuite/ChangeLog: * g++.target/s390/pr95782.C: New test.
[Bug target/113822] aarch64_evpc_reencode could/should use new_shrunk_vector instead of manually doing it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113822 --- Comment #3 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:f91569e779041e2723be23d31c2a79f1861efc7f commit r15-12-gf91569e779041e2723be23d31c2a79f1861efc7f Author: Andrew Pinski Date: Mon Feb 12 15:48:48 2024 -0800 aarch64: Use vec_perm_indices::new_shrunk_vector in aarch64_evpc_reencode While working on PERM related stuff, I can across that aarch64_evpc_reencode was manually figuring out if we shrink the perm indices instead of using vec_perm_indices::new_shrunk_vector; shrunk was added after reencode was added. Built and tested for aarch64-linux-gnu with no regressions. gcc/ChangeLog: PR target/113822 * config/aarch64/aarch64.cc (aarch64_evpc_reencode): Use vec_perm_indices::new_shrunk_vector instead of manually going through the indices. Signed-off-by: Andrew Pinski
[Bug target/114861] [14/15 Regression] LoongArch: ICE building the kernel with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861
--- Comment #8 from GCC Commits ---
The releases/gcc-14 branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:3e04b6f6ba568e6183e8aa8223d4156234503843
commit r14-10142-g3e04b6f6ba568e6183e8aa8223d4156234503843
Author: Xi Ruoyao
Date: Fri Apr 26 15:59:11 2024 +0800
LoongArch: Add constraints for bit string operation define_insn_and_split's
[PR114861]
Without the constrants, the compiler attempts to use a stack slot as the
target, causing an ICE building the kernel with -Os:
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:3144:1:
error: could not split insn
(insn:TI 1764 67 1745
(set (mem/c:DI (reg/f:DI 3 $r3) [707 %sfp+-80 S8 A64])
(and:DI (reg/v:DI 28 $r28 [orig:422 raster_config ] [422])
(const_int -50331649 [0xfcff])))
"drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c":1386:21 111
{*bstrins_di_for_mask}
(nil))
Add these constrants to fix the issue.
gcc/ChangeLog:
PR target/114861
* config/loongarch/loongarch.md (bstrins__for_mask): Add
constraints for operands.
(bstrins__for_ior_mask): Likewise.
gcc/testsuite/ChangeLog:
PR target/114861
* gcc.target/loongarch/pr114861.c: New test.
(cherry picked from commit 140124ad54eef88ca87909f63aedc8aaeacefc65)
[Bug target/114861] [14/15 Regression] LoongArch: ICE building the kernel with -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114861
--- Comment #7 from GCC Commits ---
The master branch has been updated by Xi Ruoyao :
https://gcc.gnu.org/g:140124ad54eef88ca87909f63aedc8aaeacefc65
commit r15-11-g140124ad54eef88ca87909f63aedc8aaeacefc65
Author: Xi Ruoyao
Date: Fri Apr 26 15:59:11 2024 +0800
LoongArch: Add constraints for bit string operation define_insn_and_split's
[PR114861]
Without the constrants, the compiler attempts to use a stack slot as the
target, causing an ICE building the kernel with -Os:
drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c:3144:1:
error: could not split insn
(insn:TI 1764 67 1745
(set (mem/c:DI (reg/f:DI 3 $r3) [707 %sfp+-80 S8 A64])
(and:DI (reg/v:DI 28 $r28 [orig:422 raster_config ] [422])
(const_int -50331649 [0xfcff])))
"drivers/gpu/drm/amd/amdgpu/gfx_v6_0.c":1386:21 111
{*bstrins_di_for_mask}
(nil))
Add these constrants to fix the issue.
gcc/ChangeLog:
PR target/114861
* config/loongarch/loongarch.md (bstrins__for_mask): Add
constraints for operands.
(bstrins__for_ior_mask): Likewise.
gcc/testsuite/ChangeLog:
PR target/114861
* gcc.target/loongarch/pr114861.c: New test.
[Bug fortran/103716] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15964 since r9-3803-ga5fbc2f36a291cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103716 --- Comment #11 from GCC Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:b482968801158116dd8ba3b15a4c29143b2a423a commit r12-10398-gb482968801158116dd8ba3b15a4c29143b2a423a Author: Paul Thomas Date: Tue May 23 06:46:37 2023 +0100 Fortran: Fix assumed length chars and len inquiry [PR103716] 2023-05-23 Paul Thomas gcc/fortran PR fortran/103716 * resolve.cc (gfc_resolve_ref): Conversion of array_ref into an element should be done for all characters without a len expr, not just deferred lens, and for integer expressions. * trans-expr.cc (conv_inquiry): For len and kind inquiry refs, set the se string_length to NULL_TREE. gcc/testsuite/ PR fortran/103716 * gfortran.dg/pr103716.f90 : New test. (cherry picked from commit 842a432b02238361ecc601d301ac400a7f30f4fa)
[Bug target/114272] SCHEDULER_IDENT incorrect for Cortex-A520 and Cortex-A510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114272 --- Comment #6 from GCC Commits --- The releases/gcc-12 branch has been updated by Richard Ball : https://gcc.gnu.org/g:751a0f54345b7e037db7f0389c19c1f87e0ae4de commit r12-10397-g751a0f54345b7e037db7f0389c19c1f87e0ae4de Author: Richard Ball Date: Fri Apr 26 18:21:07 2024 +0100 aarch64: Fix SCHEDULER_IDENT for Cortex-A510 The SCHEDULER_IDENT for this CPU was incorrectly set to cortexa55. This can cause sub-optimal asm to be generated. gcc/ChangeLog: PR target/114272 * config/aarch64/aarch64-cores.def (AARCH64_CORE): Change SCHEDULER_IDENT from cortexa55 to cortexa53 for Cortex-A510.
[Bug target/114272] SCHEDULER_IDENT incorrect for Cortex-A520 and Cortex-A510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114272 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Ball : https://gcc.gnu.org/g:28b3b8a2fe55521a43f3710cf6ced1ab63f1ea03 commit r13-8654-g28b3b8a2fe55521a43f3710cf6ced1ab63f1ea03 Author: Richard Ball Date: Fri Apr 26 18:15:23 2024 +0100 aarch64: Fix SCHEDULER_IDENT for Cortex-A510 The SCHEDULER_IDENT for this CPU was incorrectly set to cortexa55. This can cause sub-optimal asm to be generated. gcc/ChangeLog: PR target/114272 * config/aarch64/aarch64-cores.def (AARCH64_CORE): Change SCHEDULER_IDENT from cortexa55 to cortexa53 for Cortex-A510.
[Bug fortran/102003] [PDT] Length of character component not simplified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102003 --- Comment #7 from GCC Commits --- The releases/gcc-12 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:8ad460ca8824f7e29e38a63f9cb4a9a3b96d506f commit r12-10396-g8ad460ca8824f7e29e38a63f9cb4a9a3b96d506f Author: Andre Vehreschild Date: Wed Jul 12 12:51:30 2023 +0200 gfortran: Allow ref'ing PDT's len() in parameter-initializer. Fix declaring a parameter initialized using a pdt_len reference not simplifying the reference to a constant. 2023-07-12 Andre Vehreschild gcc/fortran/ChangeLog: PR fortran/102003 * expr.cc (find_inquiry_ref): Replace len of pdt_string by constant. (simplify_ref_chain): Ensure input to find_inquiry_ref is NULL. (gfc_match_init_expr): Prevent PDT analysis for function calls. (gfc_pdt_find_component_copy_initializer): Get the initializer value for given component. * gfortran.h (gfc_pdt_find_component_copy_initializer): New function. * simplify.cc (gfc_simplify_len): Replace len() of PDT with pdt component ref or constant. gcc/testsuite/ChangeLog: * gfortran.dg/pdt_33.f03: New test. (cherry picked from commit f9182da3213aa57c16dd0b52862126de4a259f6a)
[Bug libstdc++/114863] std::format applying grouping to nan's and inf's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114863 --- Comment #3 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a0bc71e480132a528a4869c1cd7863f709768c53 commit r15-5-ga0bc71e480132a528a4869c1cd7863f709768c53 Author: Jonathan Wakely Date: Fri Apr 26 11:42:26 2024 +0100 libstdc++: Do not apply localized formatting to NaN and inf [PR114863] We don't want to add grouping to strings like "-inf", and there is no radix character to replace either. libstdc++-v3/ChangeLog: PR libstdc++/114863 * include/std/format (__formatter_fp::format): Only use _M_localized for finite values. * testsuite/std/format/functions/format.cc: Check localized formatting of NaN and initiny.
[Bug target/110621] x86_64: Test gcc.target/i386/pr105354-2.c fails with -fstack-protector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110621 --- Comment #2 from GCC Commits --- The releases/gcc-13 branch has been updated by Haochen Jiang : https://gcc.gnu.org/g:7425436b5382a04f3eb28c7c7912f4d9a1cad0bd commit r13-8652-g7425436b5382a04f3eb28c7c7912f4d9a1cad0bd Author: Haochen Jiang Date: Fri Apr 26 16:48:29 2024 +0800 i386: Fix array index overflow in pr105354-2.c The array index should not be over 8 for v8hi, or it will fail under -O0 or using -fstack-protector. gcc/testsuite/ChangeLog: PR target/110621 * gcc.target/i386/pr105354-2.c: As mentioned.
[Bug target/110621] x86_64: Test gcc.target/i386/pr105354-2.c fails with -fstack-protector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110621 --- Comment #1 from GCC Commits --- The master branch has been updated by Haochen Jiang : https://gcc.gnu.org/g:4a2e55b3ada20fe6457466bb687a66c8d03e056e commit r14-10137-g4a2e55b3ada20fe6457466bb687a66c8d03e056e Author: Haochen Jiang Date: Fri Apr 26 16:48:29 2024 +0800 i386: Fix array index overflow in pr105354-2.c The array index should not be over 8 for v8hi, or it will fail under -O0 or using -fstack-protector. gcc/testsuite/ChangeLog: PR target/110621 * gcc.target/i386/pr105354-2.c: As mentioned.
[Bug fortran/102003] [PDT] Length of character component not simplified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102003 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:e207b67fcde224f2be0c79bf2a24f7fc75b6f481 commit r13-8651-ge207b67fcde224f2be0c79bf2a24f7fc75b6f481 Author: Andre Vehreschild Date: Wed Jul 12 12:51:30 2023 +0200 gfortran: Allow ref'ing PDT's len() in parameter-initializer. Fix declaring a parameter initialized using a pdt_len reference not simplifying the reference to a constant. 2023-07-12 Andre Vehreschild gcc/fortran/ChangeLog: PR fortran/102003 * expr.cc (find_inquiry_ref): Replace len of pdt_string by constant. (simplify_ref_chain): Ensure input to find_inquiry_ref is NULL. (gfc_match_init_expr): Prevent PDT analysis for function calls. (gfc_pdt_find_component_copy_initializer): Get the initializer value for given component. * gfortran.h (gfc_pdt_find_component_copy_initializer): New function. * simplify.cc (gfc_simplify_len): Replace len() of PDT with pdt component ref or constant. gcc/testsuite/ChangeLog: * gfortran.dg/pdt_33.f03: New test. (cherry picked from commit f9182da3213aa57c16dd0b52862126de4a259f6a)
[Bug target/111610] Cannot build cross compiler to darwin targets after r14-4108-g47346acb72b50d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111610 --- Comment #7 from GCC Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:1fd4db58480a518b05dd835157e59b2ed9fd2bc1 commit r11-11371-g1fd4db58480a518b05dd835157e59b2ed9fd2bc1 Author: Iain Sandoe Date: Wed Sep 27 11:05:31 2023 +0100 Darwin, configure: Allow for an unrecognisable dsymutil [PR111610]. We had a catch-all configuration case for missing or unrecognised dsymutil but it was setting the dsymutil source to "UNKNOWN" which is not usable in this context (since it clashes with an existing enum). We rename this to DET_UNKNOWN (for Darwin External Toolchain). PR target/111610 gcc/ChangeLog: * configure: Regenerate. * configure.ac: Rename the missing dsymutil case to "DET_UNKNOWN". Signed-off-by: Iain Sandoe (cherry picked from commit 2ecab2f32b9e9a75bf563f80752d5b44dcd26b98)
[Bug c++/111284] [11/12/13/14 Regression] Some passing-by-value parameters are mishandled since GCC 9, affecting libstdc++'s constexpr std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111284 --- Comment #10 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:f541757ba4632e204169dd08a5f10c782199af42 commit r14-10134-gf541757ba4632e204169dd08a5f10c782199af42 Author: Jakub Jelinek Date: Thu Apr 25 20:45:04 2024 +0200 c++: Fix constexpr evaluation of parameters passed by invisible reference [PR111284] My r9-6136 changes to make a copy of constexpr function bodies before genericization modifies it broke the constant evaluation of non-POD arguments passed by value. In the callers such arguments are passed as reference to usually a TARGET_EXPR, but on the callee side until genericization they are just direct uses of a PARM_DECL with some class type. In cxx_bind_parameters_in_call I've used convert_from_reference to pretend it is passed by value and then cxx_eval_constant_expression is called there and evaluates that as an rvalue, followed by adjust_temp_type if the types don't match exactly (e.g. const Foo argument and passing to it reference to Foo TARGET_EXPR). The reason this doesn't work is that when the TARGET_EXPR in the caller is constant initialized, this for it is the address of the TARGET_EXPR_SLOT, but if the code later on pretends the PARM_DECL is just initialized to the rvalue of the constant evaluation of the TARGET_EXPR, it is as if there is a bitwise copy of the TARGET_EXPR to the callee, so this in the callee is then address of the PARM_DECL in the callee. The following patch attempts to fix that by constexpr evaluation of such arguments in the caller as an lvalue instead of rvalue, and on the callee side when seeing such a PARM_DECL, if we want an lvalue, lookup the value (lvalue) saved in ctx->globals (if any), and if wanting an rvalue, recursing with vc_prvalue on the looked up value (because it is there as an lvalue, nor rvalue). adjust_temp_type doesn't work for lvalues of non-scalarish types, for such types it relies on changing the type of a CONSTRUCTOR, but on the other side we know what we pass to the argument is addressable, so the patch on type mismatch takes address of the argument value, casts to reference to the desired type and dereferences it. 2024-04-25 Jakub Jelinek PR c++/111284 * constexpr.cc (cxx_bind_parameters_in_call): For PARM_DECLs with TREE_ADDRESSABLE types use vc_glvalue rather than vc_prvalue for cxx_eval_constant_expression and if it doesn't have the same type as it should, cast the reference type to reference to type before convert_from_reference and instead of adjust_temp_type take address of the arg, cast to reference to type and then convert_from_reference. (cxx_eval_constant_expression) : For lval case on parameters with TREE_ADDRESSABLE types lookup result in ctx->globals if possible. Otherwise if lookup in ctx->globals was successful for parameter with TREE_ADDRESSABLE type, recurse with vc_prvalue on the returned value. * g++.dg/cpp1z/constexpr-111284.C: New test. * g++.dg/cpp1y/constexpr-lifetime7.C: Expect one error on a different line.
[Bug lto/113208] [14 Regression] lto1: error: Alias and target's comdat groups differs since r14-5979-g99d114c15523e0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113208
--- Comment #34 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c39654e7a431992773b48d61f804494b0d70855f
commit r14-10132-gc39654e7a431992773b48d61f804494b0d70855f
Author: Jakub Jelinek
Date: Thu Apr 25 20:37:10 2024 +0200
c++: Retry the aliasing of base/complete cdtor optimization at
import_export_decl time [PR113208]
When expand_or_defer_fn is called at_eof time, it calls import_export_decl
and then maybe_clone_body, which uses DECL_ONE_ONLY and comdat name in a
couple of places to try to optimize cdtors which are known to have the
same body by making the complete cdtor an alias to base cdtor (and in
that case also uses *[CD]5* as comdat group name instead of the normal
comdat group names specific to each mangled name).
Now, this optimization depends on DECL_ONE_ONLY and DECL_INTERFACE_KNOWN,
maybe_clone_body and can_alias_cdtor use:
if (DECL_ONE_ONLY (fn))
cgraph_node::get_create (clone)->set_comdat_group (cxx_comdat_group
(clone));
...
bool can_alias = can_alias_cdtor (fn);
...
/* Tell cgraph if both ctors or both dtors are known to have
the same body. */
if (can_alias
&& fns[0]
&& idx == 1
&& cgraph_node::get_create (fns[0])->create_same_body_alias
(clone, fns[0]))
{
alias = true;
if (DECL_ONE_ONLY (fns[0]))
{
/* For comdat base and complete cdtors put them
into the same, *[CD]5* comdat group instead of
*[CD][12]*. */
comdat_group = cdtor_comdat_group (fns[1], fns[0]);
cgraph_node::get_create (fns[0])->set_comdat_group
(comdat_group);
if (symtab_node::get (clone)->same_comdat_group)
symtab_node::get (clone)->remove_from_same_comdat_group ();
symtab_node::get (clone)->add_to_same_comdat_group
(symtab_node::get (fns[0]));
}
}
and
/* Don't use aliases for weak/linkonce definitions unless we can put both
symbols in the same COMDAT group. */
return (DECL_INTERFACE_KNOWN (fn)
&& (SUPPORTS_ONE_ONLY || !DECL_WEAK (fn))
&& (!DECL_ONE_ONLY (fn)
|| (HAVE_COMDAT_GROUP && DECL_WEAK (fn;
The following testcase regressed with Marek's r14-5979 change,
when pr113208_0.C is compiled where the ctor is marked constexpr,
we no longer perform this optimization, where
_ZN6vectorI12QualityValueEC2ERKS1_ was emitted in the
_ZN6vectorI12QualityValueEC5ERKS1_ comdat group and
_ZN6vectorI12QualityValueEC1ERKS1_ was made an alias to it,
instead we emit _ZN6vectorI12QualityValueEC2ERKS1_ in
_ZN6vectorI12QualityValueEC2ERKS1_ comdat group and the same
content _ZN6vectorI12QualityValueEC1ERKS1_ as separate symbol in
_ZN6vectorI12QualityValueEC1ERKS1_ comdat group.
Now, the linker seems to somehow cope with that, eventhough it
probably keeps both copies of the ctor, but seems LTO can't cope
with that and Honza doesn't know what it should do in that case
(linker decides that the prevailing symbol is
_ZN6vectorI12QualityValueEC2ERKS1_ (from the
_ZN6vectorI12QualityValueEC2ERKS1_ comdat group) and
_ZN6vectorI12QualityValueEC1ERKS1_ alias (from the other TU,
from _ZN6vectorI12QualityValueEC5ERKS1_ comdat group)).
Note, the case where some constructor is marked constexpr in one
TU and not in another one happens pretty often in libstdc++ when
one mixes -std= flags used to compile different compilation units.
The reason the optimization doesn't trigger when the constructor is
constexpr is that expand_or_defer_fn is called in that case much earlier
than when it is not constexpr; in the former case it is called when we
try to constant evaluate that constructor. But DECL_INTERFACE_KNOWN
is false in that case and comdat_linkage hasn't been called either
(I think it is desirable, because comdat group is stored in the cgraph
node and am not sure it is a good idea to create cgraph nodes for
something that might not be needed later on at all), so maybe_clone_body
clones the bodies, but doesn't make them as aliases.
The following patch is an attempt to redo this optimization when
import_export_decl is called at_eof time on the base/complete cdtor
(or deleting dtor). It will not do anything if maybe_clone_body
hasn't been called uyet (the TREE_ASM_WRITTEN check on the
DECL_MAYBE_IN_CHARGE_CDTOR_P), or when one or both of the base/complete
cdtors have been lowered already, or when maybe_clone_body called
maybe_thunk_body and it was successful. Otherwise retries the
can_alias_cdtor check and makes
[Bug fortran/114825] [11/12/13/14 Regression] Compiler error using gfortran and OpenMP since r5-1190
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114825 --- Comment #5 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:14d48516e588ad2b35e2007b3970bdcb1b3f145c commit r14-10130-g14d48516e588ad2b35e2007b3970bdcb1b3f145c Author: Jakub Jelinek Date: Thu Apr 25 20:09:35 2024 +0200 openmp: Copy DECL_LANG_SPECIFIC and DECL_LANG_FLAG_? to tree-nested decl copy [PR114825] tree-nested.cc creates in 2 spots artificial VAR_DECLs, one of them is used both for debug info and OpenMP/OpenACC lowering purposes, the other solely for OpenMP/OpenACC lowering purposes. When the decls are used in OpenMP/OpenACC lowering, the OMP langhooks (mostly Fortran, C just a little and C++ doesn't have nested functions) then inspect the flags on the vars and based on that decide how to lower the corresponding clauses. Unfortunately we weren't copying DECL_LANG_SPECIFIC and DECL_LANG_FLAG_?, so the langhooks made decisions on the default flags on those instead. As the original decl isn't necessarily a VAR_DECL, could be e.g. PARM_DECL, using copy_node wouldn't work properly, so this patch just copies those flags in addition to other flags it was copying already. And I've removed code duplication by introducing a helper function which does copying common to both uses. 2024-04-25 Jakub Jelinek PR fortran/114825 * tree-nested.cc (get_debug_decl): New function. (get_nonlocal_debug_decl): Use it. (get_local_debug_decl): Likewise. * gfortran.dg/gomp/pr114825.f90: New test.
[Bug modula2/114836] error messages should be translatable and follow locale convention
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114836 --- Comment #1 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:d0e1e1291b10372d71ad3d6cb66b333ea91097e7 commit r14-10124-gd0e1e1291b10372d71ad3d6cb66b333ea91097e7 Author: Gaius Mulley Date: Thu Apr 25 18:31:55 2024 +0100 PR modula2/114836 Avoid concatenation of error strings to aid error locale translation This patch avoids a concatenation of error strings making locale translation of the error message easier. gcc/m2/ChangeLog: PR modula2/114836 * gm2-compiler/M2Range.mod (FoldTypeAssign): Avoid error string concatenation. Signed-off-by: Gaius Mulley
[Bug target/114837] [11/12/13] Fix to security weaknesses in arm PCS for CMSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837 --- Comment #6 from GCC Commits --- The releases/gcc-11 branch has been updated by Richard Ball : https://gcc.gnu.org/g:dabd742cc25f8992c24e639510df0965dbf14f21 commit r11-11364-gdabd742cc25f8992c24e639510df0965dbf14f21 Author: Richard Ball Date: Thu Apr 25 15:30:42 2024 +0100 arm: Zero/Sign extends for CMSE security Co-Authored by: Andre Simoes Dias Vieira This patch makes the following changes: 1) When calling a secure function from non-secure code then any arguments smaller than 32-bits that are passed in registers are zero- or sign-extended. 2) After a non-secure function returns into secure code then any return value smaller than 32-bits that is passed in a register is zero- or sign-extended. This patch addresses the following CVE-2024-0151. gcc/ChangeLog: PR target/114837 * config/arm/arm.c (cmse_nonsecure_call_inline_register_clear): Add zero/sign extend. (arm_expand_prologue): Add zero/sign extend. gcc/testsuite/ChangeLog: * gcc.target/arm/cmse/extend-param.c: New test. * gcc.target/arm/cmse/extend-return.c: New test. (cherry picked from commit ad45086178d833254d66fab518b14234418f002b)
[Bug target/114837] [11/12/13] Fix to security weaknesses in arm PCS for CMSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837 --- Comment #5 from GCC Commits --- The releases/gcc-12 branch has been updated by Richard Ball : https://gcc.gnu.org/g:441e194abcf3211de647d74c892f90879ae9ca8c commit r12-10394-g441e194abcf3211de647d74c892f90879ae9ca8c Author: Richard Ball Date: Thu Apr 25 15:30:42 2024 +0100 arm: Zero/Sign extends for CMSE security Co-Authored by: Andre Simoes Dias Vieira This patch makes the following changes: 1) When calling a secure function from non-secure code then any arguments smaller than 32-bits that are passed in registers are zero- or sign-extended. 2) After a non-secure function returns into secure code then any return value smaller than 32-bits that is passed in a register is zero- or sign-extended. This patch addresses the following CVE-2024-0151. gcc/ChangeLog: PR target/114837 * config/arm/arm.cc (cmse_nonsecure_call_inline_register_clear): Add zero/sign extend. (arm_expand_prologue): Add zero/sign extend. gcc/testsuite/ChangeLog: * gcc.target/arm/cmse/extend-param.c: New test. * gcc.target/arm/cmse/extend-return.c: New test. (cherry picked from commit ad45086178d833254d66fab518b14234418f002b)
[Bug target/114837] [11/12/13] Fix to security weaknesses in arm PCS for CMSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Richard Ball : https://gcc.gnu.org/g:5550214b58e95320b54e42ef0e37c6479e04b27b commit r13-8647-g5550214b58e95320b54e42ef0e37c6479e04b27b Author: Richard Ball Date: Thu Apr 25 15:30:42 2024 +0100 arm: Zero/Sign extends for CMSE security Co-Authored by: Andre Simoes Dias Vieira This patch makes the following changes: 1) When calling a secure function from non-secure code then any arguments smaller than 32-bits that are passed in registers are zero- or sign-extended. 2) After a non-secure function returns into secure code then any return value smaller than 32-bits that is passed in a register is zero- or sign-extended. This patch addresses the following CVE-2024-0151. gcc/ChangeLog: PR target/114837 * config/arm/arm.cc (cmse_nonsecure_call_inline_register_clear): Add zero/sign extend. (arm_expand_prologue): Add zero/sign extend. gcc/testsuite/ChangeLog: * gcc.target/arm/cmse/extend-param.c: New test. * gcc.target/arm/cmse/extend-return.c: New test. (cherry picked from commit ad45086178d833254d66fab518b14234418f002b)
[Bug target/114837] [11/12/13/14] Fix to security weaknesses in arm PCS for CMSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114837 --- Comment #2 from GCC Commits --- The master branch has been updated by Richard Ball : https://gcc.gnu.org/g:ad45086178d833254d66fab518b14234418f002b commit r14-10122-gad45086178d833254d66fab518b14234418f002b Author: Richard Ball Date: Thu Apr 25 15:30:42 2024 +0100 arm: Zero/Sign extends for CMSE security Co-Authored by: Andre Simoes Dias Vieira This patch makes the following changes: 1) When calling a secure function from non-secure code then any arguments smaller than 32-bits that are passed in registers are zero- or sign-extended. 2) After a non-secure function returns into secure code then any return value smaller than 32-bits that is passed in a register is zero- or sign-extended. This patch addresses the following CVE-2024-0151. gcc/ChangeLog: PR target/114837 * config/arm/arm.cc (cmse_nonsecure_call_inline_register_clear): Add zero/sign extend. (arm_expand_prologue): Add zero/sign extend. gcc/testsuite/ChangeLog: * gcc.target/arm/cmse/extend-param.c: New test. * gcc.target/arm/cmse/extend-return.c: New test.
[Bug tree-optimization/114792] [14 Regression] ICE on valid code at -O1 with "-fno-tree-ccp -fno-tree-copy-prop" on x86_64-linux-gnu: in get_loop_body, at cfgloop.cc:903
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114792 --- Comment #7 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:59ff81835fee22a9d4c9a481a4d1814583aae945 commit r14-10120-g59ff81835fee22a9d4c9a481a4d1814583aae945 Author: Richard Biener Date: Thu Apr 25 08:08:24 2024 +0200 tree-optimization/114792 - order loops to unloops in CH When we use unloop_loops we have to make sure to have loops ordered inner to outer as otherwise we can wreck inner loop structure where unlooping relies on that being intact. The following re-sorts the vector of to unloop loops after copy-header as that adds to the vector in two places and the wrong order. PR tree-optimization/114792 * tree-ssa-loop-ch.cc (ch_order_loops): New function. (ch_base::copy_headers): Sort loops to unloop inner-to-outer. * gcc.dg/torture/pr114792.c: New testcase.
[Bug target/114416] calling convention incompatibility with vendor compiler for V9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114416 --- Comment #20 from GCC Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:1d238c84025aaef1641e4000bd2a8f4328b474dd commit r14-10119-g1d238c84025aaef1641e4000bd2a8f4328b474dd Author: Eric Botcazou Date: Thu Apr 25 12:44:14 2024 +0200 Fix calling convention incompatibility with vendor compiler For the 20th anniversary of https://gcc.gnu.org/gcc-3.4/sparc-abi.html, a new calling convention incompatibility with the vendor compiler (and the ABI) has been discovered in 64-bit mode, affecting small structures containing arrays of floating-point components. The decision has been made to fix it on Solaris only at this point. gcc/ PR target/114416 * config/sparc/sparc.h (SUN_V9_ABI_COMPATIBILITY): New macro. * config/sparc/sol2.h (SUN_V9_ABI_COMPATIBILITY): Redefine it. * config/sparc/sparc.cc (fp_type_for_abi): New predicate. (traverse_record_type): Use it to spot floating-point types. (compute_fp_layout): Also deal with array types. gcc/testsuite/ * gcc.target/sparc/small-struct-1.c: New test. * gcc.target/sparc/pr105573.c: Rename to... * gcc.target/sparc/20230425-1.c: ...this. * gcc.target/sparc/pr109541.c: Rename to... * gcc.target/sparc/20230607-1.c: ...this
[Bug target/114714] [RISC-V][RVV] ICE: insn does not satisfy its constraints (postreload)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114714 --- Comment #7 from GCC Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:af7d981ba40f145256f6f6d3409451e8fa647f75 commit r14-10118-gaf7d981ba40f145256f6f6d3409451e8fa647f75 Author: Pan Li Date: Thu Apr 25 15:04:02 2024 +0800 RISC-V: Add test cases for insn does not satisfy its constraints [PR114714] We have one ICE when RVV register overlap is enabled. We reverted this feature as it is in stage 4 and there is no much time to figure a better solution for this. Thus, for now add the related test cases which will trigger ICE when register overlap enabled. This will gate the RVV register overlap support in GCC-15. PR target/114714 gcc/testsuite/ChangeLog: * g++.target/riscv/rvv/base/pr114714-1.C: New test. * g++.target/riscv/rvv/base/pr114714-2.C: New test. Signed-off-by: Pan Li Co-Authored-by: Kito Cheng
[Bug fortran/93678] [11/12/13/14 Regression] ICE with TRANSFER and typebound procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678 --- Comment #15 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:c058105bc47a0701e157d1028e60f48554561f9f commit r14-10116-gc058105bc47a0701e157d1028e60f48554561f9f Author: Paul Thomas Date: Thu Apr 25 06:56:10 2024 +0100 Fortran: Fix ICE in gfc_trans_create_temp_array from bad type [PR93678] 2024-04-25 Paul Thomas gcc/fortran PR fortran/93678 * trans-expr.cc (gfc_conv_procedure_call): Use the interface, where possible, to obtain the type of character procedure pointers of class entities. gcc/testsuite/ PR fortran/93678 * gfortran.dg/pr93678.f90: New test.
[Bug fortran/89462] [11/12/13/14 Regression] gfortran loops in code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89462 --- Comment #14 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:1fd5a07444776d76cdd6a2eee7df0478201197a5 commit r14-10115-g1fd5a07444776d76cdd6a2eee7df0478201197a5 Author: Paul Thomas Date: Thu Apr 25 06:52:31 2024 +0100 Fortran: Generate new charlens for shared symbol typespecs [PR89462] 2024-04-25 Paul Thomas Jakub Jelinek gcc/fortran PR fortran/89462 * decl.cc (build_sym): Add an extra argument 'elem'. If 'elem' is greater than 1, gfc_new_charlen is called to generate a new charlen, registered in the symbol namespace. (variable_decl, enumerator_decl): Set the new argument in the calls to build_sym. gcc/testsuite/ PR fortran/89462 * gfortran.dg/pr89462.f90: New test.
[Bug target/88309] [11/12/13/14 Regression] ICE: Floating point exception (in is_miss_rate_acceptable), target assigning alignent of 4 bits(!) to vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88309 --- Comment #10 from GCC Commits --- The releases/gcc-11 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:02f1b5361188c9d833cef39caf723d31d44ba5d5 commit r11-11363-g02f1b5361188c9d833cef39caf723d31d44ba5d5 Author: Kewen Lin Date: Mon Apr 8 21:01:36 2024 -0500 rs6000: Fix wrong align passed to build_aligned_type [PR88309] As the comments in PR88309 show, there are two oversights in rs6000_gimple_fold_builtin that pass align in bytes to build_aligned_type but which actually requires align in bits, it causes unexpected ICE or hanging in function is_miss_rate_acceptable due to zero align_unit value. This patch is to fix them by converting bytes to bits, add an assertion on positive align_unit value and notes function build_aligned_type requires align measured in bits in its function comment. PR target/88309 Co-authored-by: Andrew Pinski gcc/ChangeLog: * config/rs6000/rs6000-call.c (rs6000_gimple_fold_builtin): Fix wrong align passed to function build_aligned_type. * tree-ssa-loop-prefetch.c (is_miss_rate_acceptable): Add an assertion to ensure align_unit should be positive. * tree.c (build_qualified_type): Update function comments. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr88309.c: New test. (cherry picked from commit 26eb5f8fd173e2425ae7505528fc426de4b7e34c)
[Bug target/88309] [11/12/13/14 Regression] ICE: Floating point exception (in is_miss_rate_acceptable), target assigning alignent of 4 bits(!) to vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88309 --- Comment #9 from GCC Commits --- The releases/gcc-12 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:43c8cb0e003996b3a7a9f98923f602561f3f0ec7 commit r12-10393-g43c8cb0e003996b3a7a9f98923f602561f3f0ec7 Author: Kewen Lin Date: Mon Apr 8 21:01:36 2024 -0500 rs6000: Fix wrong align passed to build_aligned_type [PR88309] As the comments in PR88309 show, there are two oversights in rs6000_gimple_fold_builtin that pass align in bytes to build_aligned_type but which actually requires align in bits, it causes unexpected ICE or hanging in function is_miss_rate_acceptable due to zero align_unit value. This patch is to fix them by converting bytes to bits, add an assertion on positive align_unit value and notes function build_aligned_type requires align measured in bits in its function comment. PR target/88309 Co-authored-by: Andrew Pinski gcc/ChangeLog: * config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_builtin): Fix wrong align passed to function build_aligned_type. * tree-ssa-loop-prefetch.cc (is_miss_rate_acceptable): Add an assertion to ensure align_unit should be positive. * tree.cc (build_qualified_type): Update function comments. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr88309.c: New test.
[Bug target/88309] [11/12/13/14 Regression] ICE: Floating point exception (in is_miss_rate_acceptable), target assigning alignent of 4 bits(!) to vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88309 --- Comment #8 from GCC Commits --- The releases/gcc-13 branch has been updated by Kewen Lin : https://gcc.gnu.org/g:a9f174f01f25fa6df989707dc2fec29ef78aad24 commit r13-8646-ga9f174f01f25fa6df989707dc2fec29ef78aad24 Author: Kewen Lin Date: Mon Apr 8 21:01:36 2024 -0500 rs6000: Fix wrong align passed to build_aligned_type [PR88309] As the comments in PR88309 show, there are two oversights in rs6000_gimple_fold_builtin that pass align in bytes to build_aligned_type but which actually requires align in bits, it causes unexpected ICE or hanging in function is_miss_rate_acceptable due to zero align_unit value. This patch is to fix them by converting bytes to bits, add an assertion on positive align_unit value and notes function build_aligned_type requires align measured in bits in its function comment. PR target/88309 Co-authored-by: Andrew Pinski gcc/ChangeLog: * config/rs6000/rs6000-builtin.cc (rs6000_gimple_fold_builtin): Fix wrong align passed to function build_aligned_type. * tree-ssa-loop-prefetch.cc (is_miss_rate_acceptable): Add an assertion to ensure align_unit should be positive. * tree.cc (build_qualified_type): Update function comments. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr88309.c: New test.
[Bug c++/114709] [12/13/14 Regression] Incorrect handling of inactive union member access via pointer to member in constant evaluated context since r12-6425
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114709 --- Comment #3 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:0844170e9ef60a8b2f6fba6786672f30ce1c2749 commit r14-10110-g0844170e9ef60a8b2f6fba6786672f30ce1c2749 Author: Patrick Palka Date: Wed Apr 24 17:49:56 2024 -0400 c++: constexpr union member access folding [PR114709] The object/offset canonicalization performed in cxx_fold_indirect_ref is undesirable for union member accesses because it loses information about the member being accessed which we may later need to diagnose an inactive-member access. So this patch restricts the canonicalization accordingly. PR c++/114709 gcc/cp/ChangeLog: * constexpr.cc (cxx_fold_indirect_ref): Restrict object/offset canonicalization to RECORD_TYPE member accesses. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-union8.C: New test. Reviewed-by: Jason Merrill
[Bug libstdc++/51906] thread lock test failures on darwin11 under Xcode 4.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51906 --- Comment #59 from GCC Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:17212f5912d8f57b3757633444ae64c9831aa8f7 commit r11-11356-g17212f5912d8f57b3757633444ae64c9831aa8f7 Author: Iain Sandoe Date: Sat Dec 3 17:09:35 2022 + libstdc++, Darwin: Limit recursive mutex init to OS versions needing it. The problem described in pr 51906 was fixed in the next OS release. Limit the workaround to systems that need it. Signed-off-by: Iain Sandoe libstdc++-v3/ChangeLog: * config/os/bsd/darwin/os_defines.h (_GTHREAD_USE_RECURSIVE_MUTEX_INIT_FUNC): Limit use of this macro to OS versions that need it. (cherry picked from commit a044c9d25972b22c6b4c8ec27f2de5fd622573cc)
[Bug target/105599] g++ by itself is not producing "fatal error: no input files" for darwin target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105599 --- Comment #9 from GCC Commits --- The releases/gcc-11 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:3bb14f6ed5bc70e25381c67963c90eaab91eca22 commit r11-11353-g3bb14f6ed5bc70e25381c67963c90eaab91eca22 Author: Iain Sandoe Date: Sun May 29 16:14:32 2022 +0100 Darwin: Fix empty g++ command lines [PR105599]. An empty g++ command line should produce a diagnostic that there are no inputs. The PR is that currently Darwin produces a dignostic about missing link items instead - this is because (errnoeously), for this driver, we are creating a link job for empty command lines. The problem occurs in four stages: The g++ driver appends -shared-libgcc to the command line. The Darwin driver_init code in the backend does not see this (it sees an empty command line). When the back end driver code driver sees an empty command line, it does not add any supplementary flags (e.g. asm-macosx-version-min) - precisely to avoid anything being claimed as an input_file and therefore triggering a link line. Since we do not have a value for asm-macosx-version-min when processing the driver specs, we unconditionally inject 'multiply_defined suppress' which is used with shared libgcc (but only intended on very old Darwin). This then causes the generation of a link job. The solution, for the present, is to move version-specific link params to the LINK_SPEC so that they are only processed when a link job has already been decided. Signed-off-by: Iain Sandoe PR target/105599 gcc/ChangeLog: * config/darwin.h: Move versions-specific handling of multiply_defined from SUBTARGET_DRIVER_SELF_SPECS to LINK_SPEC. (cherry picked from commit 794737976b9a6418eab817f143bb4eb2d0c834d2)
[Bug other/114738] [14 Regression] Default DOCUMENTATION_ROOT_URL vs. release branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114738
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:97a54c05b8e338e673e1f7fb72c0e23abb571c60
commit r14-10109-g97a54c05b8e338e673e1f7fb72c0e23abb571c60
Author: Jakub Jelinek
Date: Wed Apr 24 18:29:12 2024 +0200
v2: DOCUMENTATION_ROOT_URL vs. release branches [PR114738]
This patch moves the documentation root URL infix for release branches
from get_option_url/make_doc_url to configure, such that only the default
changes and when users specify a custom documentation root URL, they don't
have to add gcc-MAJOR.MINOR.0 subdirectories for release branches.
Tested by checking
../configure --disable-bootstrap --enable-languages=c --disable-multilib
built trunk on
void
foo (int x)
{
__builtin_printf ("%ld\n", x);
}
testcase and looking for the URL in there, then repeating that after
changing gcc/BASE-VER to 14.1.0 and again after changing it to 14.1.1,
plus normal bootstrap/regtest.
2024-04-24 Jakub Jelinek
PR other/114738
* opts.cc (get_option_url): Revert 2024-04-17 changes.
* gcc-urlifier.cc: Don't include diagnostic-core.h.
(gcc_urlifier::make_doc_url): Revert 2024-04-17 changes.
* configure.ac (documentation-root-url): On release branches
append gcc-MAJOR.MINOR.0/ to the default DOCUMENTATION_ROOT_URL.
* doc/install.texi (--with-documentation-root-url=): Document
the change of the default.
* configure: Regenerate.
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #40 from GCC Commits --- The releases/gcc-11 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:09910b6753427eeb3f6dded4fae3578851da7422 commit r11-11352-g09910b6753427eeb3f6dded4fae3578851da7422 Author: Jakub Jelinek Date: Tue Mar 26 11:06:15 2024 +0100 tsan: Don't instrument non-generic AS accesses [PR111736] Similar to the asan and ubsan changes, we shouldn't instrument non-generic address space accesses with tsan, because we just have library functions which take address of the objects as generic address space pointers, so they can't handle anything else. 2024-03-26 Jakub Jelinek gcc/ChangeLog: PR sanitizer/111736 * tsan.c (instrument_expr): Punt on non-generic address space accesses. gcc/testsuite/ChangeLog: * gcc.dg/tsan/pr111736.c: New test. (cherry picked from commit 471967ab8b4c49338ba77defbe24b06cc51c0093)
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #39 from GCC Commits --- The releases/gcc-11 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:624c3bb9ff762f196852dc77233610d1cdf7d7be commit r11-11351-g624c3bb9ff762f196852dc77233610d1cdf7d7be Author: Jakub Jelinek Date: Fri Mar 22 09:23:44 2024 +0100 ubsan: Don't -fsanitize=null instrument __seg_fs/gs pointers [PR111736] On x86 and avr some address spaces allow 0 pointers (on avr actually even generic as, but libsanitizer isn't ported to it and I'm not convinced we should completely kill -fsanitize=null in that case). The following patch makes sure those aren't diagnosed for -fsanitize=null, though they are still sanitized for -fsanitize=alignment. 2024-03-22 Jakub Jelinek gcc/ChangeLog: PR sanitizer/111736 * ubsan.c (ubsan_expand_null_ifn, instrument_mem_ref): Avoid SANITIZE_NULL instrumentation for non-generic address spaces for which targetm.addr_space.zero_address_valid (as) is true. gcc/testsuite/ChangeLog: * gcc.dg/ubsan/pr111736.c: New test. (cherry picked from commit ddd4a3ca87410886b039cc225907b4f6e650082e)
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #37 from GCC Commits --- The releases/gcc-11 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:b86b523fb53f5ffb0e3f3236fc526a587944d9ea commit r11-11349-gb86b523fb53f5ffb0e3f3236fc526a587944d9ea Author: Richard Biener Date: Tue Dec 5 14:00:43 2023 +0100 sanitizer/111736 - skip ASAN for globals in alternate address-space gcc/ChangeLog: PR sanitizer/111736 * asan.c (asan_protect_global): Do not protect globals in non-generic address-space. (cherry picked from commit 7e40497805c0831596334fe474112f991276e11b)
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #38 from GCC Commits --- The releases/gcc-11 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:b4e1aee01a2fa617cf74ab04cf0ab574761aaaea commit r11-11350-gb4e1aee01a2fa617cf74ab04cf0ab574761aaaea Author: Richard Biener Date: Thu Mar 21 08:30:39 2024 +0100 tree-optimization/111736 - avoid address sanitizing of __seg_gs The following more thoroughly avoids address sanitizing accesses to non-generic address-spaces. gcc/ChangeLog: PR tree-optimization/111736 * asan.c (instrument_derefs): Do not instrument accesses to non-generic address-spaces. gcc/testsuite/ChangeLog: * gcc.target/i386/pr111736.c: New testcase. (cherry picked from commit 134ef2a8cac1a5cc718739bd7d3b3472947c80d6)
[Bug target/114172] [13 only] RISC-V: ICE with riscv rvv VSETVL intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114172
--- Comment #3 from GCC Commits ---
The releases/gcc-13 branch has been updated by Kito Cheng :
https://gcc.gnu.org/g:67e50daa5bd05f16d98c2dc651af2d6fa8335186
commit r13-8644-g67e50daa5bd05f16d98c2dc651af2d6fa8335186
Author: Kito Cheng
Date: Wed Apr 24 16:54:44 2024 +0800
RISC-V: Fix recursive vsetvli checking [PR114172]
extract_single_source will recursive checking the sources to
make sure if it's single source, however it may cause infinite
recursive when the source is come from itself, so it should just skip
first source to prevent that.
NOTE: This logic has existing on trunk/GCC 14, but it included in a big
vsetvli improvement patch, which is not backport to GCC 13.
```
void saxpy_rvv_m8(float *y, long vl)
{
for (;;)
{
vl = __riscv_vsetvl_e32m8(vl); //ICE
vfloat32m8_t y_vec;
__riscv_vse32_v_f32m8(y, y_vec, vl);
}
}
```
gcc/ChangeLog:
PR target/114172
* config/riscv/riscv-vsetvl.cc (extract_single_source):
Skip first set.
gcc/testsuite/ChangeLog:
PR target/114172
* gcc.target/riscv/rvv/vsetvl/pr114172.c: New.
[Bug tree-optimization/114832] [14 Regression] ICE at -O{2,3} with "-fno-tree-loop-if-convert -fno-tree-loop-distribute-patterns -ftree-vectorize" on x86_64-linux-gnu: in verify_dominators, at dominan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114832 --- Comment #4 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:e28e8ab1a92e9b49f7c4045377577c8dc17751b7 commit r14-10105-ge28e8ab1a92e9b49f7c4045377577c8dc17751b7 Author: Richard Biener Date: Wed Apr 24 06:24:22 2024 +0200 tree-optimization/114832 - wrong dominator info with vect peeling When we update the dominator of the redirected exit after peeling we check whether the immediate dominator was the loop header rather than the exit source when we later want to just update it to the new source. The following fixes this oversight. PR tree-optimization/114832 * tree-vect-loop-manip.cc (slpeel_tree_duplicate_loop_to_edge_cfg): Fix dominance check. * gcc.dg/vect/pr114832.c: New testcase.
[Bug tree-optimization/114787] [13/14 Regression] wrong code at -O1 on x86_64-linux-gnu (the generated code hangs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114787 --- Comment #16 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:cc48418cfc2e555d837ae9138cbfac23acb3cdf9 commit r14-10106-gcc48418cfc2e555d837ae9138cbfac23acb3cdf9 Author: Richard Biener Date: Wed Apr 24 08:42:40 2024 +0200 tree-optimization/114787 - more careful loop update with CFG cleanup When CFG cleanup removes a backedge we have to be more careful with loop update. In particular we need to clear niter info and estimates and if we remove the last backedge of a loop we have to also mark it for removal to prevent a following basic block merging to associate loop info with an unrelated header. PR tree-optimization/114787 * tree-cfg.cc (remove_edge_and_dominated_blocks): When removing a loop backedge clear niter info and when removing the last backedge of a loop mark that loop for removal. * gcc.dg/torture/pr114787.c: New testcase.
[Bug rtl-optimization/114810] [14 Regression] internal compiler error: in lra_split_hard_reg_for, at lra-assigns.cc:1868 (unable to find a register to spill) {*andndi3_doubleword_bmi} with -m32 -msta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114810 --- Comment #15 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:628c2221d38715a64f828e3635317293d150e001 commit r14-10099-g628c2221d38715a64f828e3635317293d150e001 Author: Jakub Jelinek Date: Tue Apr 23 23:30:27 2024 +0200 i386: Avoid =,r,r andn double-word alternative for ia32 [PR114810] As discussed in the PR, on ia32 with its 8 GPRs, where 1 is always fixed and other 2 often are as well having an alternative which needs 3 double-word registers is just too much for RA. The following patch splits that alternative into two, one with o is used even on ia32, but one with the 3x r is used just for -m64/-mx32. Tried to reduce the testcase further, but it wasn't easily possible. 2024-04-23 Jakub Jelinek PR target/114810 * config/i386/i386.md (*andn3_doubleword_bmi): Split the =,r,ro alternative into =,r,r enabled only for x64 and =,r,o. * g++.target/i386/pr114810.C: New test.
[Bug fortran/103496] [F2018][TS29113] C_SIZEOF – rejects now valid args with 'must be an interoperable data entity'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103496 --- Comment #6 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:0bf94da59feab2c72a02c91df310a36d33dfd1f7 commit r14-10097-g0bf94da59feab2c72a02c91df310a36d33dfd1f7 Author: Harald Anlauf Date: Tue Apr 23 20:21:43 2024 +0200 Fortran: check C_SIZEOF on additions from TS29113/F2018 [PR103496] gcc/testsuite/ChangeLog: PR fortran/103496 * gfortran.dg/c_sizeof_8.f90: New test.
[Bug c++/114795] internal compiler error: in finish_member_declaration after module import in gcc 14.0.1 snapshot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114795 --- Comment #8 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:4f9401d1a802325e5dfa2db841945e1a9c59a980 commit r14-10096-g4f9401d1a802325e5dfa2db841945e1a9c59a980 Author: Patrick Palka Date: Tue Apr 23 14:01:22 2024 -0400 c++/modules: deduced return type merging [PR114795] When merging an imported function template specialization with an existing one, if the existing one has an undeduced return type and the imported one's is already deduced, we need to propagate the deduced type since once we install the imported definition we won't get a chance to deduce it by normal means. So this patch makes is_matching_decl propagate the deduced return type alongside our propagation of the exception specification. Another option would be to propagate it later when installing the imported definition from read_function_def, but it seems preferable to do it sooner rather than later. PR c++/114795 gcc/cp/ChangeLog: * module.cc (trees_in::is_matching_decl): Propagate deduced function return type. gcc/testsuite/ChangeLog: * g++.dg/modules/auto-4_a.H: New test. * g++.dg/modules/auto-4_b.C: New test. Reviewed-by: Jason Merrill
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #35 from GCC Commits --- The releases/gcc-12 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:d6c62e4fb9a6d395599b7c78c831bace4bc7ff8f commit r12-10389-gd6c62e4fb9a6d395599b7c78c831bace4bc7ff8f Author: Jakub Jelinek Date: Fri Mar 22 09:23:44 2024 +0100 ubsan: Don't -fsanitize=null instrument __seg_fs/gs pointers [PR111736] On x86 and avr some address spaces allow 0 pointers (on avr actually even generic as, but libsanitizer isn't ported to it and I'm not convinced we should completely kill -fsanitize=null in that case). The following patch makes sure those aren't diagnosed for -fsanitize=null, though they are still sanitized for -fsanitize=alignment. 2024-03-22 Jakub Jelinek PR sanitizer/111736 * ubsan.cc (ubsan_expand_null_ifn, instrument_mem_ref): Avoid SANITIZE_NULL instrumentation for non-generic address spaces for which targetm.addr_space.zero_address_valid (as) is true. * gcc.dg/ubsan/pr111736.c: New test. (cherry picked from commit ddd4a3ca87410886b039cc225907b4f6e650082e)
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #36 from GCC Commits --- The releases/gcc-12 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:48fd1c5791b47717dcd4fa5615bc07cf54e964a7 commit r12-10390-g48fd1c5791b47717dcd4fa5615bc07cf54e964a7 Author: Jakub Jelinek Date: Tue Mar 26 11:06:15 2024 +0100 tsan: Don't instrument non-generic AS accesses [PR111736] Similar to the asan and ubsan changes, we shouldn't instrument non-generic address space accesses with tsan, because we just have library functions which take address of the objects as generic address space pointers, so they can't handle anything else. 2024-03-26 Jakub Jelinek PR sanitizer/111736 * tsan.cc (instrument_expr): Punt on non-generic address space accesses. * gcc.dg/tsan/pr111736.c: New test. (cherry picked from commit 471967ab8b4c49338ba77defbe24b06cc51c0093)
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #34 from GCC Commits --- The releases/gcc-12 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:e89b5ed62a5a06fb8918ffa1616f0f37c8d359c3 commit r12-10388-ge89b5ed62a5a06fb8918ffa1616f0f37c8d359c3 Author: Richard Biener Date: Thu Mar 21 08:30:39 2024 +0100 tree-optimization/111736 - avoid address sanitizing of __seg_gs The following more thoroughly avoids address sanitizing accesses to non-generic address-spaces. PR tree-optimization/111736 * asan.cc (instrument_derefs): Do not instrument accesses to non-generic address-spaces. * gcc.target/i386/pr111736.c: New testcase. (cherry picked from commit 134ef2a8cac1a5cc718739bd7d3b3472947c80d6)
[Bug sanitizer/111736] Address sanitizer is not compatible with named address spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736 --- Comment #33 from GCC Commits --- The releases/gcc-12 branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:61d1962e7c3c32da6962d9cb20f6fd996501f3f2 commit r12-10387-g61d1962e7c3c32da6962d9cb20f6fd996501f3f2 Author: Richard Biener Date: Tue Dec 5 14:00:43 2023 +0100 sanitizer/111736 - skip ASAN for globals in alternate address-space PR sanitizer/111736 * asan.cc (asan_protect_global): Do not protect globals in non-generic address-space. (cherry picked from commit 7e40497805c0831596334fe474112f991276e11b)
[Bug objc/101666] Objective-C frontend crashes with `-fobjc-nilcheck`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101666
--- Comment #9 from GCC Commits ---
The releases/gcc-11 branch has been updated by Iain D Sandoe
:
https://gcc.gnu.org/g:87431b4a81e9dc5988509399704a7352800c6a77
commit r11-11339-g87431b4a81e9dc5988509399704a7352800c6a77
Author: Iain Sandoe
Date: Sat Aug 14 12:27:55 2021 +0100
Objective-C: fix crash with -fobjc-nilcheck
When -fobjc-nilcheck is enabled, messages that result in a struct type
should
yield a zero-initialized struct when sent to nil. Currently, the frontend
crashes when it encounters this situation. This patch fixes the crash by
generating the tree for the `{}` initializer.
Signed-off-by: Iain Sandoe
Co-authored-by: Matt Jacobson
PR objc/101666
gcc/objc/ChangeLog:
* objc-act.c (objc_build_constructor): Handle empty constructor
lists.
* objc-next-runtime-abi-02.c (build_v2_objc_method_fixup_call):
Handle nil receivers.
(build_v2_build_objc_method_call): Likewise.
gcc/testsuite/ChangeLog:
* obj-c++.dg/pr101666-0.mm: New test.
* obj-c++.dg/pr101666-1.mm: New test.
* obj-c++.dg/pr101666.inc: New.
* objc.dg/pr101666-0.m: New test.
* objc.dg/pr101666-1.m: New test.
* objc.dg/pr101666.inc: New.
(cherry picked from commit d2aa4e0b3b5053df8f5853d9ed29022ff0d3ecf6)
[Bug fortran/102597] ICE in gfc_get_extern_function_decl, at fortran/trans-decl.c:2243 since r8-3365-gb89a63b916340ef2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102597 --- Comment #4 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:ca00bf02dcc37f9ff1028ca1d90e8b8d95d69683 commit r14-10089-gca00bf02dcc37f9ff1028ca1d90e8b8d95d69683 Author: Paul Thomas Date: Tue Apr 23 10:22:48 2024 +0100 Fortran: Check that the ICE does not reappear [PR102597] 2024-04-23 Paul Thomas gcc/testsuite/ PR fortran/102597 * gfortran.dg/pr102597.f90: New test.
[Bug tree-optimization/114799] [14 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in useless_type_conversion_p, at gimple-expr.cc:85 with -O2 -fno-vect-cost-model
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114799 --- Comment #8 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:18e8e55487238237f37f621668fdee316624981a commit r14-10088-g18e8e55487238237f37f621668fdee316624981a Author: Richard Biener Date: Tue Apr 23 08:39:03 2024 +0200 tree-optimization/114799 - SLP and patterns The following plugs a hole with computing whether a SLP node has any pattern stmts which is important to know when we want to replace it by a CTOR from external defs. PR tree-optimization/114799 * tree-vect-slp.cc (vect_get_and_check_slp_defs): Properly update ->any_pattern when swapping operands. * gcc.dg/vect/bb-slp-pr114799.c: New testcase.
[Bug target/114676] [12/13/14 Regression] DSE removes assignment that is used later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676 --- Comment #17 from GCC Commits --- The master branch has been updated by Andreas Krebbel : https://gcc.gnu.org/g:42189f21b22c43ac8ab46edf5f6a7b4d99bc86a5 commit r14-10087-g42189f21b22c43ac8ab46edf5f6a7b4d99bc86a5 Author: Andreas Krebbel Date: Tue Apr 23 10:05:46 2024 +0200 s390x: Fix vec_xl/vec_xst type aliasing [PR114676] The requirements of the vec_xl/vec_xst intrinsincs wrt aliasing of the pointer argument are not really documented. As it turns out, users are likely to get it wrong. With this patch we let the pointer argument alias everything in order to make it more robust for users. gcc/ChangeLog: PR target/114676 * config/s390/s390-c.cc (s390_expand_overloaded_builtin): Use a MEM_REF with an addend of type ptr_type_node. gcc/testsuite/ChangeLog: PR target/114676 * gcc.target/s390/zvector/pr114676.c: New test. Suggested-by: Jakub Jelinek
[Bug ipa/114784] [14 Regression] Inlining fails for always_inline inheriting constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114784 --- Comment #7 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:aa73eb97a1e3c84564fa71158d09f9c5582c4d2e commit r14-10086-gaa73eb97a1e3c84564fa71158d09f9c5582c4d2e Author: Jakub Jelinek Date: Tue Apr 23 08:36:15 2024 +0200 c++: Copy over DECL_DISREGARD_INLINE_LIMITS flag to inheriting ctors [PR114784] The following testcase is rejected with error: inlining failed in call to 'always_inline' '...': call is unlikely and code size would grow errors. The problem is that starting with the r14-2149 change we try to copy most of the attributes from the inherited to inheriting ctor, but don't copy associated flags that decl_attributes sets. Now, the other clone_attrs user, cp/optimize.cc (maybe_clone_body) copies over DECL_COMDAT (clone) = DECL_COMDAT (fn); DECL_WEAK (clone) = DECL_WEAK (fn); if (DECL_ONE_ONLY (fn)) cgraph_node::get_create (clone)->set_comdat_group (cxx_comdat_group (clone)); DECL_USE_TEMPLATE (clone) = DECL_USE_TEMPLATE (fn); DECL_EXTERNAL (clone) = DECL_EXTERNAL (fn); DECL_INTERFACE_KNOWN (clone) = DECL_INTERFACE_KNOWN (fn); DECL_NOT_REALLY_EXTERN (clone) = DECL_NOT_REALLY_EXTERN (fn); DECL_VISIBILITY (clone) = DECL_VISIBILITY (fn); DECL_VISIBILITY_SPECIFIED (clone) = DECL_VISIBILITY_SPECIFIED (fn); DECL_DLLIMPORT_P (clone) = DECL_DLLIMPORT_P (fn); DECL_DISREGARD_INLINE_LIMITS (clone) = DECL_DISREGARD_INLINE_LIMITS (fn); The following patch just copies DECL_DISREGARD_INLINE_LIMITS to fix this exact bug, not really sure which other flags should be copied and which shouldn't. Plus there are tons of other flags, some of which might need to be copied too, some of which might not, perhaps in both places, like: DECL_UNINLINABLE, maybe DECL_PRESERVE_P, TREE_USED, maybe DECL_USER_ALIGN/DECL_ALIGN, maybe DECL_WEAK, maybe DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT, DECL_NO_LIMIT_STACK. TREE_READONLY, DECL_PURE_P, TREE_THIS_VOLATILE (for const, pure and noreturn attributes) probably makes no sense, DECL_IS_RETURNS_TWICE neither (returns_twice ctor?). What about TREE_NOTHROW? DECL_FUNCTION_SPECIFIC_OPTIMIZATION, DECL_FUNCTION_SPECIFIC_TARGET... Anyway, another problem is that if inherited_ctor is a TEMPLATE_DECL, as also can be seen in the using D::D; case in the testcase, then DECL_ATTRIBUTES (fn) = clone_attrs (DECL_ATTRIBUTES (inherited_ctor)); attempts to copy the attributes from the TEMPLATE_DECL which doesn't have them. The following patch copies them from STRIP_TEMPLATE (inherited_ctor) which does. E.g. DECL_DECLARED_CONSTEXPR_P works fine as the macro itself uses STRIP_TEMPLATE too, but not 100% sure about other macros used on inherited_ctor earlier. 2024-04-23 Jakub Jelinek PR c++/114784 * method.cc (implicitly_declare_fn): Call clone_attrs on DECL_ATTRIBUTES on STRIP_TEMPLATE (inherited_ctor) rather than inherited_ctor. Also copy DECL_DISREGARD_INLINE_LIMITS flag from it. * g++.dg/cpp0x/inh-ctor39.C: New test.
[Bug c++/114078] operator new and operator delete are incorrectly acceptable as explicit object member functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114078 --- Comment #2 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:cf51fe706ea0219beb5bb85e81606d372ca9635e commit r14-10085-gcf51fe706ea0219beb5bb85e81606d372ca9635e Author: Nathaniel Shead Date: Sat Apr 20 15:08:02 2024 +1000 c++: Check if allocation functions are xobj members [PR114078] A class allocation member function is implicitly 'static' by [class.free] p3, so cannot have an explicit object parameter. PR c++/114078 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Check allocation functions for xobj parameters. gcc/testsuite/ChangeLog: * g++.dg/cpp23/explicit-obj-ops-alloc.C: New test. Signed-off-by: Nathaniel Shead
[Bug modula2/114811] iso/fail/badexpression.mod and iso/fail/badexpression2.mod ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114811 --- Comment #3 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:b909daa5b67317e46543a7b2ed76e82298645cf6 commit r14-10080-gb909daa5b67317e46543a7b2ed76e82298645cf6 Author: Gaius Mulley Date: Mon Apr 22 20:34:11 2024 +0100 PR modula2/114811 string set incl ICE bugfix This patch corrects gm2-torture.exp to recognize an ICE in the fail case as a negative result. The patch also fixes FoldBinarySet so that the types are only checked once the operands have been resolved. Without this patch gcc/testsuite/gm2/iso/fail/badexpression2.mod would cause an ICE. gcc/m2/ChangeLog: PR modula2/114811 * gm2-compiler/M2GenGCC.mod (FoldBinarySet): Add condition checking to ensure op2 and op3 are fully resolved before type checking is performed. gcc/testsuite/ChangeLog: PR modula2/114811 * lib/gm2-torture.exp: Correct regexp checking for internal compiler error strings in compiler output. Signed-off-by: Gaius Mulley
[Bug libstdc++/114803] simd conversion to [[gnu::vector_size(N)]] type hits invalid code in experimental/bits/simd_builtin.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114803 --- Comment #1 from GCC Commits --- The master branch has been updated by Matthias Kretz : https://gcc.gnu.org/g:7ef139146a8923a8719873ca3fdae175668e8d63 commit r14-10079-g7ef139146a8923a8719873ca3fdae175668e8d63 Author: Matthias Kretz Date: Mon Apr 22 16:12:34 2024 +0200 libstdc++: Fix conversion of simd to vector builtin Signed-off-by: Matthias Kretz libstdc++-v3/ChangeLog: PR libstdc++/114803 * include/experimental/bits/simd_builtin.h (_SimdBase2::operator __vector_type_t): There is no __builtin() function in _SimdWrapper, instead use its conversion operator. * testsuite/experimental/simd/pr114803_vecbuiltin_cvt.cc: New test.
[Bug testsuite/114034] Failure of tests gcov-dump-{1,2}.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114034 --- Comment #6 from GCC Commits --- The releases/gcc-12 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:6a4824a8bc86fcbcb8f51bab4c24d72ffd00715e commit r12-10385-g6a4824a8bc86fcbcb8f51bab4c24d72ffd00715e Author: Iain Sandoe Date: Sun Mar 31 11:22:58 2024 +0100 testsuite: Remove duplicate -lgcov [PR114034] Duplicate library entries now cause linker warnings with newer linker versions on Darwin which leads to these tests regressing. The library is already added by the test flags so there is no need to put an extra one in the options. PR testsuite/114034 gcc/testsuite/ChangeLog: * g++.dg/gcov/gcov-dump-1.C: Remove extra -lgcov. * g++.dg/gcov/gcov-dump-2.C: Likewise. Signed-off-by: Iain Sandoe (cherry picked from commit 799a056cf804f433ce0050a5a6bf900f7a01ecb1)
[Bug modula2/114807] badpointer3.mod causes an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114807 --- Comment #3 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:b0469e35dbcc9a93a2cb50e3c0445edc3db174be commit r14-10077-gb0469e35dbcc9a93a2cb50e3c0445edc3db174be Author: Gaius Mulley Date: Mon Apr 22 18:19:32 2024 +0100 PR modula2/114807 badpointer3.mod causes an ICE This patch fixes an ICE caused when a constant string is built and attempted to be passed into a procedure with an opaque type. gcc/m2/ChangeLog: PR modula2/114807 * gm2-compiler/M2Check.mod (checkUnbounded): Remove unused local variables. (constCheckMeta): Include check for IsReallyPointer in the failure case. * gm2-compiler/M2Quads.mod (MoveWithMode): Remove CopyConstString. * gm2-compiler/SymbolTable.def (IsHiddenReallyPointer): Export. * gm2-compiler/SymbolTable.mod (SkipHiddenType): Remove. (IsReallyPointer): Include IsHiddenReallyPointer test. gcc/testsuite/ChangeLog: PR modula2/114807 * gm2/pim/fail/badproctype.mod: Change MYSHORTREAL to SHORTREAL. * gm2/pim/fail/badprocbool.mod: New test. * gm2/pim/fail/badproccard.mod: New test. * gm2/pim/fail/badprocint.mod: New test. * gm2/pim/fail/badprocint2.mod: New test. * gm2/pim/pass/goodproccard2.mod: New test. * gm2/pim/pass/goodprocint.mod: New test. * gm2/pim/pass/goodprocint3.mod: New test. * gm2/pim/run/pass/genconststr.mod: New test. Signed-off-by: Gaius Mulley
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #39 from GCC Commits --- The releases/gcc-13 branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:b55a35bcc80a7402576556c2f9d161229fb220ef commit r13-8640-gb55a35bcc80a7402576556c2f9d161229fb220ef Author: Jerry DeLisle Date: Sun Apr 21 20:50:26 2024 -0700 libfortran: Fix handling of formatted separators. Backport from mainline. PR libfortran/114304 PR libfortran/105473 libgfortran/ChangeLog: * io/list_read.c (eat_separator): Add logic to handle spaces preceding a comma or semicolon such that that a 'null' read occurs without error at the end of comma or semicolon terminated input lines. Add check and error message for ';'. Accept tab as alternative to space. (list_formatted_read_scalar): Treat comma as a decimal point when specified by the decimal mode on the first item. gcc/testsuite/ChangeLog: * gfortran.dg/pr105473.f90: Modify for revised checks. * gfortran.dg/pr114304-2.f90: New test. * gfortran.dg/pr114304.f90: New test.
[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 --- Comment #34 from GCC Commits --- The releases/gcc-13 branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:b55a35bcc80a7402576556c2f9d161229fb220ef commit r13-8640-gb55a35bcc80a7402576556c2f9d161229fb220ef Author: Jerry DeLisle Date: Sun Apr 21 20:50:26 2024 -0700 libfortran: Fix handling of formatted separators. Backport from mainline. PR libfortran/114304 PR libfortran/105473 libgfortran/ChangeLog: * io/list_read.c (eat_separator): Add logic to handle spaces preceding a comma or semicolon such that that a 'null' read occurs without error at the end of comma or semicolon terminated input lines. Add check and error message for ';'. Accept tab as alternative to space. (list_formatted_read_scalar): Treat comma as a decimal point when specified by the decimal mode on the first item. gcc/testsuite/ChangeLog: * gfortran.dg/pr105473.f90: Modify for revised checks. * gfortran.dg/pr114304-2.f90: New test. * gfortran.dg/pr114304.f90: New test.
[Bug fortran/103471] [11/12/13/14 Regression] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1114
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103471 --- Comment #11 from GCC Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:f17d31e709af9b2d488adecd6cd040dfc1f23b04 commit r14-10059-gf17d31e709af9b2d488adecd6cd040dfc1f23b04 Author: Paul Thomas Date: Sun Apr 21 17:24:24 2024 +0100 Fortran: Detect 'no implicit type' error in right place [PR103471] 2024-04-21 Paul Thomas gcc/fortran PR fortran/103471 * resolve.cc (resolve_actual_arglist): Catch variables silently set as untyped, resetting the flag so that gfc_resolve_expr can generate the no implicit type error. (gfc_resolve_index_1): Block index expressions of unknown type from being converted to default integer, avoiding the fatal error in trans-decl.cc. * symbol.cc (gfc_set_default_type): Remove '(symbol)' from the 'no IMPLICIT type' error message. * trans-decl.cc (gfc_get_symbol_decl): Change fatal error locus to that of the symbol declaration. (gfc_trans_deferred_vars): Remove two trailing tabs. gcc/testsuite/ PR fortran/103471 * gfortran.dg/pr103471.f90: New test.
[Bug target/114036] Test failure of gcov-14.c on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114036 --- Comment #7 from GCC Commits --- The releases/gcc-12 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:ed046c2cc0f0a2d00cc77e5e9ce5d8f71e2278c6 commit r12-10379-ged046c2cc0f0a2d00cc77e5e9ce5d8f71e2278c6 Author: Iain Sandoe Date: Sun Mar 31 11:27:53 2024 +0100 testsuite, Darwin: Allow for an undefined symbol [PR114036]. Darwin's linker defaults to requiring all symbols to be defined at static link time (unless specifically noted or dynamic lookuo is enabled). For this test, we just need to note that the symbol is expected to be undefined. PR testsuite/114036 gcc/testsuite/ChangeLog: * gcc.misc-tests/gcov-14.c: Allow for 'Foo' to be undefined on Darwin link lines. Signed-off-by: Iain Sandoe (cherry picked from commit ad8e34eaa870608e2b07b4e7147e6ef2944bb8b5)
[Bug target/112397] Two persistent libstdc++ test failures on x86_64-apple-darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112397 --- Comment #13 from GCC Commits --- The releases/gcc-12 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:77f17e405a0669db9a6c8af69bde6eb1170f48bd commit r12-10376-g77f17e405a0669db9a6c8af69bde6eb1170f48bd Author: Iain Sandoe Date: Thu Feb 8 17:54:31 2024 + libstdc++, Darwin: Handle a linker warning [PR112397]. Darwin's linker warns when we make a direct branch to code that is in a weak definition (citing that if a different implementation of the weak function is chosen by the dynamic linker this would be an error). As the analysis in the PR shows, this can happen when we have hot/ cold partitioning and there is an error path that is primarily cold but makes use of epilogue code in the hot section. In this simple case, we can easily deduce that the code is in fact safe; however that is not something we can realistically implement in the linker. Since the user-replaceable allocators are implemented using weak definitions, this is a warning that is frequently flagged up in both the testsuite and end-user code. The chosen solution here is to suppress the hot/cold partitioning for these cases (it is unlikely to impact performance much c.f. the actual allocation). PR target/112397 libstdc++-v3/ChangeLog: * configure: Regenerate. * configure.ac: Detect if we are building for Darwin. * libsupc++/Makefile.am: If we are building for Darwin, then suppress hot/cold partitioning for the array allocators. * libsupc++/Makefile.in: Regenerated. Signed-off-by: Iain Sandoe Co-authored-by: Jonathan Wakely (cherry picked from commit 1609fdff16f17ead37666f6d0e801800ee3d04d2)
[Bug target/114049] gcc.dg/framework-1.c FAILs with Xcode 15.3 beta 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114049 --- Comment #12 from GCC Commits --- The releases/gcc-12 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:4c8d37badaa42e85218eb9b89aef3e4f6cf4486e commit r12-10375-g4c8d37badaa42e85218eb9b89aef3e4f6cf4486e Author: Iain Sandoe Date: Mon Mar 18 10:06:44 2024 + testsuite, Darwin: Use the IOKit framework in framework-1.c [PR114049]. The intent of the test is to show that we find a framework that is installed in /System/Library/Frameworks when the user has added a '-F' option. The trick is to choose some header that is present for all the Darwin versions we support and that does not contain any content we cannot parse. We had been using the Kernel framework for this, but recent SDK versions have revealed that this is not suitable. Replacing with a use of IOKit. PR target/114049 gcc/testsuite/ChangeLog: * gcc.dg/framework-1.c: Use an IOKit header instead of a Kernel one. Signed-off-by: Iain Sandoe (cherry picked from commit 4adb1a5839e7a3310a127c1776f1f95d7edaa6ff)
[Bug testsuite/112297] Failure of pr100936.c on x86_64-apple-darwin21
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112297 --- Comment #5 from GCC Commits --- The releases/gcc-12 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:0eb6f8874047f7e7f13027aaac14d3de276c5e69 commit r12-10370-g0eb6f8874047f7e7f13027aaac14d3de276c5e69 Author: Francois-Xavier Coudert Date: Mon Dec 11 09:26:23 2023 +0100 Testsuite: restrict test to nonpic targets The test is currently failing on x86_64-apple-darwin. gcc/testsuite/ChangeLog: PR testsuite/112297 * gcc.target/i386/pr100936.c: Require nonpic target. (cherry picked from commit 02f562484c17522d79a482ac702a5fa3c2dfdd10)
[Bug target/114794] [avr] Speed up udivmodqi4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114794 --- Comment #2 from GCC Commits --- The releases/gcc-13 branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:7bd8428da72a0a1d3bef4e50be4b60b981ed540d commit r13-8638-g7bd8428da72a0a1d3bef4e50be4b60b981ed540d Author: Georg-Johann Lay Date: Sun Apr 21 14:33:50 2024 +0200 AVR: target/114794 - Tweak __udivmodqi4 libgcc/ PR target/114794 * config/avr/lib1funcs.S (__udivmodqi4): Tweak. (cherry picked from commit a44d16efa7a508f8b8f303417d0714c39f159725)
[Bug target/114794] [avr] Speed up udivmodqi4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114794 --- Comment #1 from GCC Commits --- The master branch has been updated by Georg-Johann Lay : https://gcc.gnu.org/g:a44d16efa7a508f8b8f303417d0714c39f159725 commit r14-10058-ga44d16efa7a508f8b8f303417d0714c39f159725 Author: Georg-Johann Lay Date: Sun Apr 21 14:33:50 2024 +0200 AVR: target/114794 - Tweak __udivmodqi4 libgcc/ PR target/114794 * config/avr/lib1funcs.S (__udivmodqi4): Tweak.
[Bug rtl-optimization/114768] Volatile reads can be optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768 --- Comment #10 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ab3b83afc149edda11fa3c7cbb3815606731003b commit r13-8636-gab3b83afc149edda11fa3c7cbb3815606731003b Author: Jakub Jelinek Date: Fri Apr 19 08:47:53 2024 +0200 rtlanal: Fix set_noop_p for volatile loads or stores [PR114768] On the following testcase, combine propagates the mem/v load into mem store with the same address and then removes it, because noop_move_p says it is a no-op move. If it was the other way around, i.e. mem/v store and mem load, or both would be mem/v, it would be kept. The problem is that rtx_equal_p never checks any kind of flags on the rtxes (and I think it would be quite dangerous to change it at this point), and set_noop_p checks side_effects_p on just one of the operands, not both. In the MEM <- MEM set, it only checks it on the destination, in store to ZERO_EXTRACT only checks it on the source. The following patch adds the missing side_effects_p checks. 2024-04-19 Jakub Jelinek PR rtl-optimization/114768 * rtlanal.cc (set_noop_p): Don't return true for MEM <- MEM sets if src has side-effects or for stores into ZERO_EXTRACT if ZERO_EXTRACT operand has side-effects. * gcc.dg/pr114768.c: New test. (cherry picked from commit 9f295847a9c32081bdd0fe908ffba58e830a24fb)
[Bug middle-end/114753] from_chars aborts with -m32 -ftrapv when passed -9223372036854775808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
--- Comment #10 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:10f689596ad1633f4f5de1852c8f82a993fe948e
commit r13-8635-g10f689596ad1633f4f5de1852c8f82a993fe948e
Author: Jakub Jelinek
Date: Thu Apr 18 09:45:14 2024 +0200
internal-fn: Temporarily disable flag_trapv during .{ADD,SUB,MUL}_OVERFLOW
etc. expansion [PR114753]
__builtin_{add,sub,mul}_overflow{,_p} builtins are well defined
for all inputs even for -ftrapv, and the -fsanitize=signed-integer-overflow
ifns shouldn't abort in libgcc but emit the desired ubsan diagnostics
or abort depending on -fsanitize* setting regardless of -ftrapv.
The expansion of these internal functions uses expand_expr* in various
places (e.g. MULT_EXPR at least in 2 spots), so temporarily disabling
flag_trapv in all those spots would be hard.
The following patch disables it around the bodies of 3 functions
which can do the expand_expr calls.
If it was in the C++ FE, I'd use some RAII sentinel, but I don't think
we have one in the middle-end.
2024-04-18 Jakub Jelinek
PR middle-end/114753
* internal-fn.cc (expand_mul_overflow): Save flag_trapv and
temporarily clear it for the duration of the function, then
restore previous value.
(expand_vector_ubsan_overflow): Likewise.
(expand_arith_overflow): Likewise.
* gcc.dg/pr114753.c: New test.
(cherry picked from commit 6c152c9db3b5b9d43e12846fb7a44977c0b65fc2)
[Bug middle-end/110027] [11/12/13 regression] Stack objects with extended alignments (vectors etc) misaligned on detect_stack_use_after_return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110027 --- Comment #24 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a16d90ec302e588dab5d7d31ccdd7b3fd5c6214e commit r13-8630-ga16d90ec302e588dab5d7d31ccdd7b3fd5c6214e Author: Jakub Jelinek Date: Thu Apr 11 11:12:11 2024 +0200 asan, v3: Fix up handling of > 32 byte aligned variables with -fsanitize=address -fstack-protector* [PR110027] On Tue, Mar 26, 2024 at 02:08:02PM +0800, liuhongt wrote: > > > So, try to add some other variable with larger size and smaller alignment > > > to the frame (and make sure it isn't optimized away). > > > > > > alignb above is the alignment of the first partition's var, if > > > align_frame_offset really needs to depend on the var alignment, it probably > > > should be the maximum alignment of all the vars with alignment > > > alignb * BITS_PER_UNIT <=3D MAX_SUPPORTED_STACK_ALIGNMENT > > > > > In asan_emit_stack_protection, when it allocated fake stack, it assume > bottom of stack is also aligned to alignb. And the place violated this > is the first var partition. which is 32 bytes offsets, it should be > BIGGEST_ALIGNMENT / BITS_PER_UNIT. > So I think we need to use MAX (BIGGEST_ALIGNMENT / > BITS_PER_UNIT, ASAN_RED_ZONE_SIZE) for the first var partition. Your first patch aligned offsets[0] to maximum of alignb and ASAN_RED_ZONE_SIZE. But as I wrote in the reply to that mail, alignb there is the alignment of just a single variable which is the first one to appear in the sorted list and is placed in the highest spot in the stack frame. That is not necessarily the largest alignment, the sorting ensures that it is a variable with the largest size in the frame (and only if several of them have equal size, largest alignment from the same sized ones). Your second patch used maximum of BIGGEST_ALIGNMENT / BITS_PER_UNIT and ASAN_RED_ZONE_SIZE. That doesn't change anything at all when using -mno-avx512f - offsets[0] is still just 32-byte aligned in that case relative to top of frame, just changes the -mavx512f case to be 64-byte aligned offsets[0] (aka offsets[0] is then either 0 or -64 instead of either 0 or -32). That will not help if any variable in the frame needs 128-byte, 256-byte, 512-byte ... 4096-byte alignment. If you want to fix the bug in the spot you've touched, you'd need to walk all the stack_vars[stack_vars_sorted[si2]] for si2 [si + 1, n - 1] and for those where the loop would do anything (i.e. stack_vars[i2].representative == i2 && TREE_CODE (decl2) == SSA_NAME ? SA.partition_to_pseudo[var_to_partition (SA.map, decl2)] == NULL_RTX : DECL_RTL (decl2) == pc_rtx and the pred applies (but that means also walking the earlier ones! because with -fstack-protector* the vars can be processed in several calls) and alignb2 * BITS_PER_UNIT <= MAX_SUPPORTED_STACK_ALIGNMENT and compute maximum of those alignments. That maximum is already computed, data->asan_alignb = MAX (data->asan_alignb, alignb); computes that, but you get the final result only after you do all the expand_stack_vars calls. You'd need to compute it before. Though, that change would be still in the wrong place. The thing is, it would be a waste of the precious stack space when it isn't needed at all (e.g. when asan will not at compile time do the use after return checking, or if it won't do it at runtime, or even if it will do at runtime it will waste the space on the stack). The following patch fixes it solely for the __asan_stack_malloc_N allocations, doesn't enlarge unnecessarily further the actual stack frame. Because asan is only supported on FRAME_GROWS_DOWNWARD architectures (mips, rs6000 and xtensa are conditional FRAME_GROWS_DOWNWARD arches, which for -fsanitize=address or -fstack-protector* use FRAME_GROWS_DOWNWARD 1, otherwise 0, others supporting asan always just use 1), the assumption for the dynamic stack realignment is that the top of the stack frame (aka offset 0) is aligned to alignb passed to the function (which is the maximum of alignb of all the vars in the frame). As checked by the assertion in the patch, offsets[0] is 0 most of the time and so that assumption is correct, the only case when it is not 0 is if -fstack-protector* is on together with -fsanitize=address and cfgexpand.cc (create_stack_guard) created a stack guard. That is the only variable which is allocated in the stack frame right away, for all others with -fsanitize=address defer_stack_allocation (or -fstack-protector*) returns true and so they aren't allocated immediately but handled during the frame layout phases. So, the original frame_offset of 0 is changed because of the stack guard to -pointer_size_in_bytes and later
[Bug c++/114580] Bogus warning on if constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114580 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ae3b6dea0445f9650cf1a684527efac06497f1b4 commit r13-8629-gae3b6dea0445f9650cf1a684527efac06497f1b4 Author: Jakub Jelinek Date: Tue Apr 9 09:31:42 2024 +0200 c++: Fix up maybe_warn_for_constant_evaluated calls [PR114580] When looking at maybe_warn_for_constant_evaluated for the trivial infinite loops patch, I've noticed that it can emit weird diagnostics for if constexpr in templates, first warn that std::is_constant_evaluted() always evaluates to false (because the function template is not constexpr) and then during instantiation warn that std::is_constant_evaluted() always evaluates to true (because it is used in if constexpr condition). Now, only the latter is actually true, even when the if constexpr is in a non-constexpr function, it will still always evaluate to true. So, the following patch fixes it to call maybe_warn_for_constant_evaluated always with IF_STMT_CONSTEXPR_P (if_stmt) as the second argument rather than true if it is if constexpr with non-dependent condition etc. 2024-04-09 Jakub Jelinek PR c++/114580 * semantics.cc (finish_if_stmt_cond): Call maybe_warn_for_constant_evaluated with IF_STMT_CONSTEXPR_P (if_stmt) as the second argument, rather than true/false depending on if it is if constexpr with non-dependent constant expression with bool type. * g++.dg/cpp2a/is-constant-evaluated15.C: New test. (cherry picked from commit cfed80b9e4f562c99679739548df9369117dd791)
[Bug tree-optimization/114566] [11/12/13 Regression] Misaligned vmovaps when compiling with stack-protector-strong for znver4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114566 --- Comment #18 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:38af0d59043da4cc07cd62c17da599e43668e3be commit r13-8628-g38af0d59043da4cc07cd62c17da599e43668e3be Author: Jakub Jelinek Date: Fri Apr 5 14:56:14 2024 +0200 vect: Don't clear base_misaligned in update_epilogue_loop_vinfo [PR114566] The following testcase is miscompiled, because in the vectorized epilogue the vectorizer assumes it can use aligned loads/stores (if the base decl gets alignment increased), but it actually doesn't increase that. This is because r10-4203-g97c1460367 added the hunk following patch removes. The explanation feels reasonable, but actually it is not true as the testcase proves. The thing is, we vectorize the main loop with 64-byte vectors and the corresponding data refs have base_alignment 16 (the a array has DECL_ALIGN 128) and offset_alignment 32. Now, because of the offset_alignment 32 rather than 64, we need to use unaligned loads/stores in the main loop (and ditto in the first load/store in vectorized epilogue). But the second load/store in the vectorized epilogue uses only 32-byte vectors and because it is a multiple of offset_alignment, it checks if we could increase alignment of the a VAR_DECL, the function returns true, sets base_misaligned = true and says the access is then aligned. But when update_epilogue_loop_vinfo clears base_misaligned with the assumption that the var had to have the alignment increased already, the update of DECL_ALIGN doesn't happen anymore. Now, I'd think this base_alignment = false was needed before r10-4030-gd2db7f7901 change was committed where it incorrectly overwrote DECL_ALIGN even if it was already larger, rather than just always increasing it. But with that change in, it doesn't make sense to me anymore. Note, the testcase is latent on the trunk, but reproduces on the 13 branch. 2024-04-05 Jakub Jelinek PR tree-optimization/114566 * tree-vect-loop.cc (update_epilogue_loop_vinfo): Don't clear base_misaligned. * gcc.target/i386/avx512f-pr114566.c: New test. (cherry picked from commit a844095e17c1a5aada1364c6f6eaade87ead463c)
[Bug c++/114691] [11/12/13 Regression] Bogus ignoring loop annotation warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114691 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ed7be7ba6f125cfda7ad07263213cbe02b7e7ced commit r13-8632-ged7be7ba6f125cfda7ad07263213cbe02b7e7ced Author: Jakub Jelinek Date: Fri Apr 12 20:53:10 2024 +0200 c++: Fix bogus warnings about ignored annotations [PR114691] The middle-end warns about the ANNOTATE_EXPR added for while/for loops if they declare a var inside of the loop condition. This is because the assumption is that ANNOTATE_EXPR argument is used immediately in a COND_EXPR (later GIMPLE_COND), but simplify_loop_decl_cond wraps the ANNOTATE_EXPR inside of a TRUTH_NOT_EXPR, so it no longer holds. The following patch fixes that by adding the TRUTH_NOT_EXPR inside of the ANNOTATE_EXPR argument if any. 2024-04-12 Jakub Jelinek PR c++/114691 * semantics.cc (simplify_loop_decl_cond): Use cp_build_unary_op with TRUTH_NOT_EXPR on ANNOTATE_EXPR argument (if any) rather than ANNOTATE_EXPR itself. * g++.dg/ext/pr114691.C: New test. (cherry picked from commit 91146346f57cc54dfeb2669347edd0eb3d13af7f)
[Bug c/114780] Using C23 nullptr as sentinel gives missing sentinel warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114780
--- Comment #4 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:e802786436851b1f5efca21a14d4f41c83c83f4f
commit r13-8637-ge802786436851b1f5efca21a14d4f41c83c83f4f
Author: Jakub Jelinek
Date: Sat Apr 20 00:12:36 2024 +0200
c-family: Allow arguments with NULLPTR_TYPE as sentinels [PR114780]
While in C++ the ellipsis argument conversions include
"An argument that has type cv std::nullptr_t is converted to type void*"
in C23 a nullptr_t argument is not promoted in any way, but va_arg
description says:
"the type of the next argument is nullptr_t and type is a pointer type that
has the same
representation and alignment requirements as a pointer to a character
type."
So, while in C++ check_function_sentinel will never see NULLPTR_TYPE, for
C23 it can see that and currently we incorrectly warn about those.
The only question is whether we should warn on any argument with
nullptr_t type or just about nullptr (nullptr_t argument with integer_zerop
value). Through undefined behavior guess one could pass non-NULL pointer
that way, say by union { void *p; nullptr_t q; } u; u.p =
and pass u.q to ..., but valid code should always pass something that will
read as (char *) 0 when read using va_arg (ap, char *), so I think it is
better not to warn rather than warn in those cases.
Note, clang seems to pass (void *)0 rather than expression of nullptr_t
type to ellipsis in C23 mode as if it did the C++ ellipsis argument
conversions, in that case guess not warning about that would be even safer,
but what GCC does I think follows the spec more closely, even when in a
valid program one shouldn't be able to observe the difference.
2024-04-20 Jakub Jelinek
PR c/114780
* c-common.cc (check_function_sentinel): Allow as sentinel any
argument of NULLPTR_TYPE.
* gcc.dg/format/sentinel-2.c: New test.
(cherry picked from commit 2afdecccbaf5c5b1c7a235509b37092540906c02)
[Bug c++/114572] [OpenMP] "internal compiler error: in assign_temp" with assignment operator and lastprivate clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114572 --- Comment #5 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:910fa4d9df8f72d16279324cca2bf1f2649aa68b commit r13-8627-g910fa4d9df8f72d16279324cca2bf1f2649aa68b Author: Jakub Jelinek Date: Fri Apr 5 09:31:28 2024 +0200 c++: Fix ICE with weird copy assignment operator [PR114572] While ctors/dtors don't return anything (undeclared void or this pointer on arm) and copy assignment operators normally return a reference to *this, it isn't invalid to return uselessly some class object which might need destructing, but the OpenMP clause handling code wasn't expecting that. The following patch fixes that. 2024-04-05 Jakub Jelinek PR c++/114572 * cp-gimplify.cc (cxx_omp_clause_apply_fn): Call build_cplus_new on build_call_a result if it has class type. * testsuite/libgomp.c++/pr114572.C: New test. (cherry picked from commit 592536eb3c0a97a55b1019ff0216ef77e6ca847e)
[Bug sanitizer/114687] [13 Regression] ICE: in edge_before_returns_twice_call, at gimple-iterator.cc:981
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114687 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:7a1a52934a2ab9ac9205a3a4d5b82a672fefba7e commit r13-8631-g7a1a52934a2ab9ac9205a3a4d5b82a672fefba7e Author: Jakub Jelinek Date: Fri Apr 12 10:59:54 2024 +0200 Limit special asan/ubsan/bitint returns_twice handling to calls in bbs with abnormal pred [PR114687] The tree-cfg.cc verifier only diagnoses returns_twice calls preceded by non-label/debug stmts if it is in a bb with abnormal predecessor. The following testcase shows that if a user lies in the attributes (a function which never returns can't be pure, and can't return twice when it doesn't ever return at all), when we figure it out, we can remove the abnormal edges to the "returns_twice" call and perhaps whole .ABNORMAL_DISPATCHER etc. edge_before_returns_twice_call then ICEs because it can't find such an edge. The following patch limits the special handling to calls in bbs where the verifier requires that. 2024-04-12 Jakub Jelinek PR sanitizer/114687 * gimple-iterator.cc (gsi_safe_insert_before): Only use edge_before_returns_twice_call if bb_has_abnormal_pred. (gsi_safe_insert_seq_before): Likewise. * gcc.dg/asan/pr114687.c: New test. (cherry picked from commit c9e94ae448ba309dba74de3ee1974a3ed9248889)
[Bug sanitizer/114743] ICE in build_check_stmt at asan.cc:2707 while compiling gcc.dg/ubsan/pr112709-2.c with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114743 --- Comment #4 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cd8e2137462d9ae1723fa193b6062ec65d164457 commit r13-8634-gcd8e2137462d9ae1723fa193b6062ec65d164457 Author: Jakub Jelinek Date: Wed Apr 17 10:24:18 2024 +0200 asan: Don't instrument .ABNORMAL_DISPATCHER [PR114743] .ABNORMAL_DISPATCHER is currently the only internal function with ECF_NORETURN, and asan likes to instrument ECF_NORETURN calls by adding some builtin call before them, which breaks the .ABNORMAL_DISPATCHER discovery added in gsi_safe_*. The following patch fixes asan not to instrument .ABNORMAL_DISPATCHER calls, like it doesn't instrument a couple of specific builtin calls as well. 2024-04-17 Jakub Jelinek PR sanitizer/114743 * asan.cc (maybe_instrument_call): Don't instrument calls to .ABNORMAL_DISPATCHER. * gcc.dg/asan/pr112709-2.c (freddy): New function from gcc.dg/ubsan/pr112709-2.c version of the test. (cherry picked from commit 299d14a54672a4d12c1abbe4031a732bb56cddaa)
[Bug c++/114634] [11/12/13 Regression] Crash Issue Encountered in GCC Compilation of Template Code with Aligned Attribute since r9-1745
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114634 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2c85e8def0efd4b0d9d312a1f0cbbee332b4e0d1 commit r13-8633-g2c85e8def0efd4b0d9d312a1f0cbbee332b4e0d1 Author: Jakub Jelinek Date: Mon Apr 15 10:25:22 2024 +0200 attribs: Don't crash on NULL TREE_TYPE in diag_attr_exclusions [PR114634] The enumerator still doesn't have TREE_TYPE set but diag_attr_exclusions assumes that all decls must have types. I think it is better in something as unimportant as diag_attr_exclusions to be more robust, if there is no type, it can just diagnose exclusions on the DECL_ATTRIBUTES, like for types it only diagnoses it on TYPE_ATTRIBUTES. 2024-04-15 Jakub Jelinek PR c++/114634 * attribs.cc (diag_attr_exclusions): Set attrs[1] to NULL_TREE for decls with NULL TREE_TYPE. * g++.dg/ext/attrib68.C: New test. (cherry picked from commit 7ec54f5fdfec298812a749699874db4d6a7246bb)
[Bug c++/114537] bit_cast does not work NSDMI of bitfields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114537 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a297f9bbb9611414fe48f6d61a8829bf5808bd2c commit r13-8626-ga297f9bbb9611414fe48f6d61a8829bf5808bd2c Author: Jakub Jelinek Date: Thu Apr 4 10:47:52 2024 +0200 fold-const: Handle NON_LVALUE_EXPR in native_encode_initializer [PR114537] The following testcase is incorrectly rejected. The problem is that for bit-fields native_encode_initializer expects the corresponding CONSTRUCTOR elt value must be INTEGER_CST, but that isn't the case here, it is wrapped into NON_LVALUE_EXPR by maybe_wrap_with_location. We could STRIP_ANY_LOCATION_WRAPPER as well, but as all we are looking for is INTEGER_CST inside, just looking through NON_LVALUE_EXPR seems easier. 2024-04-04 Jakub Jelinek PR c++/114537 * fold-const.cc (native_encode_initializer): Look through NON_LVALUE_EXPR if val is INTEGER_CST. * g++.dg/cpp2a/bit-cast16.C: New test. (cherry picked from commit 1baec8deb014b8a7da58879a407a4c00cdeb5a09)
[Bug middle-end/114552] [13 Regression] wrong code at -O1 and above on x86_64-linux-gnu since r13-990
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114552 --- Comment #9 from GCC Commits --- The releases/gcc-13 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ba6fd407891fd83648ad803c85b607dc09e23be4 commit r13-8624-gba6fd407891fd83648ad803c85b607dc09e23be4 Author: Jakub Jelinek Date: Wed Apr 3 09:59:45 2024 +0200 expr: Fix up emit_push_insn [PR114552] r13-990 added optimizations in multiple spots to optimize during expansion storing of constant initializers into targets. In the load_register_parameters and expand_expr_real_1 cases, it checks it has a tree as the source and so knows we are reading that whole decl's value, so the code is fine as is, but in the emit_push_insn case it checks for a MEM from which something is pushed and checks for SYMBOL_REF as the MEM's address, but still assumes the whole object is copied, which as the following testcase shows might not always be the case. In the testcase, k is 6 bytes, then 2 bytes of padding, then another 4 bytes, while the emit_push_insn wants to store just the 6 bytes. The following patch simply verifies it is the whole initializer that is being stored, I think that is best thing to do so late in GCC 14 cycle as well for backporting. For GCC 15, perhaps the code could stop requiring it must be at offset zero, nor that the size is equal, but could use get_symbol_constant_value/fold_ctor_reference gimple-fold APIs to actually extract just part of the initializer if we e.g. push just some subset (of course, still verify that it is a subset). For sizes which are power of two bytes and we have some integer modes, we could use as type for fold_ctor_reference corresponding integral types, otherwise dunno, punt or use some structure (e.g. try to find one in the initializer?), whatever. But even in the other spots it could perhaps handle loading of COMPONENT_REFs or MEM_REFs from the .rodata vars. 2024-04-03 Jakub Jelinek PR middle-end/114552 * expr.cc (emit_push_insn): Only use store_constructor for immediate_const_ctor_p if int_expr_size matches size. * gcc.c-torture/execute/pr114552.c: New test. (cherry picked from commit 03039744f368a24a452e4ea8d946e9c2cedaf1aa)
[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533
--- Comment #13 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:cc39bd532d4de1ba0b2785246fb6fdd63ec2e92c
commit r13-8625-gcc39bd532d4de1ba0b2785246fb6fdd63ec2e92c
Author: Jakub Jelinek
Date: Wed Apr 3 10:02:35 2024 +0200
libquadmath: Don't assume the storage for __float128 arguments is aligned
[PR114533]
With the
register_printf_type/register_printf_modifier/register_printf_specifier
APIs the C library is just told the size of the argument and is provided
with
a callback to fetch the argument from va_list using va_arg into C library
provided
memory. The C library isn't told what alignment requirement it has, but we
were
using direct load of a __float128 value from that memory which assumes
__alignof (__float128) alignment.
The following patch fixes that by using memcpy instead.
I haven't been able to reproduce an actual crash, tried
#include
#include
#include
int main ()
{
__float128 r;
int prec = 20;
int width = 46;
char buf[128];
r = 2.0q;
r = sqrtq (r);
int n = quadmath_snprintf (buf, sizeof buf, "%+-#*.20Qe", width, r);
if ((size_t) n < sizeof buf)
printf ("%s\n", buf);
/* Prints: +1.41421356237309504880e+00 */
quadmath_snprintf (buf, sizeof buf, "%Qa", r);
if ((size_t) n < sizeof buf)
printf ("%s\n", buf);
/* Prints: 0x1.6a09e667f3bcc908b2fb1366ea96p+0 */
n = quadmath_snprintf (NULL, 0, "%+-#46.*Qe", prec, r);
if (n > -1)
{
char *str = malloc (n + 1);
if (str)
{
quadmath_snprintf (str, n + 1, "%+-#46.*Qe", prec, r);
printf ("%s\n", str);
/* Prints: +1.41421356237309504880e+00 */
}
free (str);
}
printf ("%+-#*.20Qe\n", width, r);
printf ("%Qa\n", r);
printf ("%+-#46.*Qe\n", prec, r);
printf ("%d %Qe %d %Qe %d %Qe\n", 1, r, 2, r, 3, r);
return 0;
}
In any case, I think memcpy for loading from it is right.
2024-04-03 Simon Chopin
Jakub Jelinek
PR libquadmath/114533
* printf/printf_fp.c (__quadmath_printf_fp): Use memcpy to copy
__float128 out of args.
* printf/printf_fphex.c (__quadmath_printf_fphex): Likewise.
Signed-off-by: Simon Chopin
(cherry picked from commit 8455d6f6cd43b7b143ab9ee19437452fceba9cc9)
[Bug bootstrap/106472] No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106472
--- Comment #39 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:cb277dea557aaa25fdced201f7c45c753c709dfa
commit r13-8623-gcb277dea557aaa25fdced201f7c45c753c709dfa
Author: Jakub Jelinek
Date: Tue Apr 2 13:40:27 2024 +0200
Fix up postboot dependencies [PR106472]
On Wed, Mar 13, 2024 at 10:13:37AM +0100, Jakub Jelinek wrote:
> While the first Makefile.tpl hunk looks obviously ok, the others look
> completely wrong to me.
> There is nothing special about libgo vs. libbacktrace/libatomic
> compared to any other target library which is not bootstrapped vs. any
> of its dependencies which are in the bootstrapped set.
> So, Makefile.tpl shouldn't hardcode such dependencies.
Here is my version of the fix.
The dependencies in the toplevel Makefile simply didn't take into account
that some target modules could be in a bootstrapped build built in some
configurations as bootstrap modules (typically as dependencies of other
target bootstrap modules), while in other configurations just as
dependencies of non-bootstrap target modules and so not built during the
bootstrap, but after it.
Makefile.tpl arranges for those postboot target module -> target module
dependencies to be emitted only inside of an @unless gcc-bootstrap block,
while for @if gcc-bootstrap it just emits
configure-target-whatever: stage_last
dependencies which ensure those postbootstrap target modules are only built
after everything that is bootstrapped has been.
Now, the libbacktrace/libatomic target modules have bootstrap=true
target_modules = { module= libbacktrace; bootstrap=true; };
target_modules = { module= libatomic; bootstrap=true; lib_path=.libs; };
because those modules are dependencies of libphobos target module, so
when d is included among bootstrapped languages, those are all bootstrapped
and everything works correctly.
While if d is not included, libphobos target module is disabled,
libbacktrace/libatomic target modules aren't bootstrapped, nothing during
bootstrap needs them, but post bootstrap libgo target module depends on
the libatomic and libbacktrace target modules, libgfortran target module
depends on the libbacktrace target module and libgm2 target module depends
on the libatomic target module, but those dependencies were emitted only
@unless gcc-bootstrap. There is a similar theoretical problem for zlib
target module if GCJ would be ressurected, libphobos as bootstrap target
module depends on the zlib target module, but if d is not configured,
fastjar also depends on it.
The following patch arranges for the @if gcc-bootstrap case to emit also
target module -> target module dependencies, but conditionally on the
on dependency not being bootstrapped.
In the generated Makefile.in you can see what the Makefile.tpl change
produces and that it just adds extra dependencies which weren't there
before in the @if gcc-bootstrap case.
I've bootstrapped without this patch with
../configure --enable-languages=c,c++,go; make
on x86_64-linux (note, make -j2 or higher usually worked) which failed
as described in the PR, then with this patch with the same command which
built fine and the Makefile difference between the two builds being
diff -up obj40{a,b}/Makefile
--- obj40a/Makefile 2024-03-31 00:35:22.243791499 +0100
+++ obj40b/Makefile 2024-03-31 22:40:38.143299144 +0200
@@ -29376,6 +29376,14 @@ configure-bison: stage_last
configure-flex: stage_last
configure-m4: stage_last
+configure-target-fastjar: maybe-configure-target-zlib
+all-target-fastjar: maybe-all-target-zlib
+all-target-libgo: maybe-all-target-libbacktrace
+all-target-libgo: maybe-all-target-libatomic
+all-target-libgm2: maybe-all-target-libatomic
+configure-target-libgfortran: maybe-all-target-libbacktrace
+configure-target-libgo: maybe-all-target-libbacktrace
+
# Dependencies for target modules on other target modules are
# described by lang_env_dependencies; the defaults apply to anything
which I believe are exactly the extra dependencies we want.
Plus I've done normal x86_64-linux and i686-linux bootstraps/regtests
which in my case include
--enable-languages=default,ada,obj-c++,lto,go,d,rust,m2
for x86_64 and the same except ada for i686; those with my usual make -j32.
The Makefile difference in those builds vs. unpatched case
is just an extra empty line.
2024-04-02 Jakub Jelinek
PR bootstrap/106472
* Makefile.tpl (make-postboot-target-dep): New lambda.
Use it to add --enable-bootstrap dependencies of target modules
on other target modules if the latter aren't bootstrapped.
* Makefile.in: Regenerate.
[Bug analyzer/104042] Four memcpy/memset analyzer failures on darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 --- Comment #8 from GCC Commits --- The releases/gcc-12 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:c2cb625eb141cacd0bee6c6ce5888d673ac38ca4 commit r12-10361-gc2cb625eb141cacd0bee6c6ce5888d673ac38ca4 Author: Francois-Xavier Coudert Date: Sat Aug 19 23:22:06 2023 +0200 Testsuite: fix analyzer tests on Darwin On macOS, system headers redefine by default some macros (memcpy, memmove, etc) to checked versions, which defeats the analyzer. We want to turn this off. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104042 gcc/testsuite/ChangeLog: PR analyzer/104042 * gcc.dg/analyzer/analyzer.exp: Pass -D_FORTIFY_SOURCE=0 on Darwin. (cherry picked from commit ce33bbfcbc7dd3afc6c96fb48a19ed00f0c598ce)
[Bug modula2/112893] gm2 fails to detect procedure address actual parameter is incompatible with cardinal formal parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112893 --- Comment #9 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:f9a48fe7032d9894e88d0d121ba6f75b08ea5dcb commit r14-10053-gf9a48fe7032d9894e88d0d121ba6f75b08ea5dcb Author: Gaius Mulley Date: Sat Apr 20 14:35:18 2024 +0100 PR modula2/112893 full type checking between proctype and procedure not implemented This patch implements full type checking between proctype and procedures. The change implements an associated proc type built for each procedure. M2Check.mod will request GetProcedureProcType if it encounters a procedure. Before this patch a procedure was associated with the type ADDRESS in the type checking module M2Check. The gm2/pim/pass/proccard.mod have been corrected now this assumption has been removed. gcc/m2/ChangeLog: PR modula2/112893 * gm2-compiler/M2Check.mod (GetProcedureProcType): Import. (getType): Return value using GetProcedureProcType if sym is a procedure. * gm2-compiler/M2Range.mod (FoldTypeExpr): Remove quad if expression is type compatible. * gm2-compiler/SymbolTable.def (GetProcedureProcType): New procedure function. * gm2-compiler/SymbolTable.mod (Procedure): Add ProcedureType. (MakeProcedure): Initialize ProcedureType. (PutParam): Call AddProcedureProcTypeParam. (PutVarParam): Call AddProcedureProcTypeParam. (AddProcedureProcTypeParam): New procedure. (GetProcedureProcType): New procedure function. gcc/testsuite/ChangeLog: PR modula2/112893 * gm2/pim/pass/another.mod: Correct bug exposed by type checker. Swap ProcA and ProcB assignments. * gm2/pim/pass/proccard.mod: Use VAL to convert procedure into a cardinal. * gm2/iso/const/fail/castproctype.mod: New test. * gm2/pim/fail/badproctype.mod: New test. Signed-off-by: Gaius Mulley
[Bug target/114783] [14 Regression] Equality compares of vector builtins spill one operand to the stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114783
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c23db3ebb65ba357155be85ef56d037403eaee36
commit r14-10047-gc23db3ebb65ba357155be85ef56d037403eaee36
Author: Jakub Jelinek
Date: Sat Apr 20 00:13:49 2024 +0200
i386: Fix up *avx2_eq3 constraints [PR114783]
The r14-4456 change (part of APX EGPR support) seems to have mistakenly
changed in the
@@ -16831,7 +16831,7 @@ (define_insn "*avx2_eq3"
[(set (match_operand:VI_256 0 "register_operand" "=x")
(eq:VI_256
(match_operand:VI_256 1 "nonimmediate_operand" "%x")
- (match_operand:VI_256 2 "nonimmediate_operand" "xm")))]
+ (match_operand:VI_256 2 "nonimmediate_operand" "jm")))]
"TARGET_AVX2 && !(MEM_P (operands[1]) && MEM_P (operands[2]))"
"vpcmpeq\t{%2, %1, %0|%0, %1, %2}"
[(set_attr "type" "ssecmp")
hunk the xm constraint to jm, while in many other spots it changed
correctly
xm to xjm. The instruction doesn't require the last operand to be in
memory, it can handle 3 256-bit registers just fine, just it is a VEX only
encoded instruction and so can't allow APX EGPR regs in the memory operand.
The following patch fixes it, so that we don't force one of the == operands
into memory all the time.
2024-04-20 Jakub Jelinek
PR target/114783
* config/i386/sse.md (*avx2_eq3): Change last operand's
constraint from "jm" to "xjm".
* gcc.target/i386/avx2-pr114783.c: New test.
[Bug c/114780] Using C23 nullptr as sentinel gives missing sentinel warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114780
--- Comment #2 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2afdecccbaf5c5b1c7a235509b37092540906c02
commit r14-10046-g2afdecccbaf5c5b1c7a235509b37092540906c02
Author: Jakub Jelinek
Date: Sat Apr 20 00:12:36 2024 +0200
c-family: Allow arguments with NULLPTR_TYPE as sentinels [PR114780]
While in C++ the ellipsis argument conversions include
"An argument that has type cv std::nullptr_t is converted to type void*"
in C23 a nullptr_t argument is not promoted in any way, but va_arg
description says:
"the type of the next argument is nullptr_t and type is a pointer type that
has the same
representation and alignment requirements as a pointer to a character
type."
So, while in C++ check_function_sentinel will never see NULLPTR_TYPE, for
C23 it can see that and currently we incorrectly warn about those.
The only question is whether we should warn on any argument with
nullptr_t type or just about nullptr (nullptr_t argument with integer_zerop
value). Through undefined behavior guess one could pass non-NULL pointer
that way, say by union { void *p; nullptr_t q; } u; u.p =
and pass u.q to ..., but valid code should always pass something that will
read as (char *) 0 when read using va_arg (ap, char *), so I think it is
better not to warn rather than warn in those cases.
Note, clang seems to pass (void *)0 rather than expression of nullptr_t
type to ellipsis in C23 mode as if it did the C++ ellipsis argument
conversions, in that case guess not warning about that would be even safer,
but what GCC does I think follows the spec more closely, even when in a
valid program one shouldn't be able to observe the difference.
2024-04-20 Jakub Jelinek
PR c/114780
* c-common.cc (check_function_sentinel): Allow as sentinel any
argument of NULLPTR_TYPE.
* gcc.dg/format/sentinel-2.c: New test.
[Bug lto/114574] [14 regression] ICE when building curl with LTO (fld_incomplete_type_of, at ipa-free-lang-data.cc:257) since r14-9763
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114574 --- Comment #34 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a39983bf58d3097c472252f6989d19b60909dd9a commit r14-10045-ga39983bf58d3097c472252f6989d19b60909dd9a Author: Jakub Jelinek Date: Sat Apr 20 00:05:21 2024 +0200 c: Fix ICE with -g and -std=c23 related to incomplete types [PR114361] We did not update TYPE_CANONICAL for incomplete variants when completing a structure. We now set for flag_isoc23 TYPE_STRUCTURAL_EQUALITY_P for incomplete structure and union types and then update TYPE_CANONICAL later, though update it only for the variants and derived pointer types which can be easily discovered. Other derived types created while the type was still incomplete will remain TYPE_STRUCTURAL_EQUALITY_P. See PR114574 for discussion. 2024-04-20 Martin Uecker Jakub Jelinek PR lto/114574 PR c/114361 gcc/c/ * c-decl.cc (shadow_tag_warned): For flag_isoc23 and code not ENUMERAL_TYPE use SET_TYPE_STRUCTURAL_EQUALITY. (parser_xref_tag): Likewise. (start_struct): For flag_isoc23 use SET_TYPE_STRUCTURAL_EQUALITY. (c_update_type_canonical): New function. (finish_struct): Put NULL as second == operand rather than first. Assert TYPE_STRUCTURAL_EQUALITY_P. Call c_update_type_canonical. * c-typeck.cc (composite_type_internal): Use SET_TYPE_STRUCTURAL_EQUALITY. Formatting fix. gcc/testsuite/ * gcc.dg/pr114574-1.c: New test. * gcc.dg/pr114574-2.c: New test. * gcc.dg/pr114361.c: New test. * gcc.dg/c23-tag-incomplete-1.c: New test. * gcc.dg/c23-tag-incomplete-2.c: New test.
[Bug c/114361] ICE with c23 related to completion of incomplete structure types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114361 --- Comment #8 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:a39983bf58d3097c472252f6989d19b60909dd9a commit r14-10045-ga39983bf58d3097c472252f6989d19b60909dd9a Author: Jakub Jelinek Date: Sat Apr 20 00:05:21 2024 +0200 c: Fix ICE with -g and -std=c23 related to incomplete types [PR114361] We did not update TYPE_CANONICAL for incomplete variants when completing a structure. We now set for flag_isoc23 TYPE_STRUCTURAL_EQUALITY_P for incomplete structure and union types and then update TYPE_CANONICAL later, though update it only for the variants and derived pointer types which can be easily discovered. Other derived types created while the type was still incomplete will remain TYPE_STRUCTURAL_EQUALITY_P. See PR114574 for discussion. 2024-04-20 Martin Uecker Jakub Jelinek PR lto/114574 PR c/114361 gcc/c/ * c-decl.cc (shadow_tag_warned): For flag_isoc23 and code not ENUMERAL_TYPE use SET_TYPE_STRUCTURAL_EQUALITY. (parser_xref_tag): Likewise. (start_struct): For flag_isoc23 use SET_TYPE_STRUCTURAL_EQUALITY. (c_update_type_canonical): New function. (finish_struct): Put NULL as second == operand rather than first. Assert TYPE_STRUCTURAL_EQUALITY_P. Call c_update_type_canonical. * c-typeck.cc (composite_type_internal): Use SET_TYPE_STRUCTURAL_EQUALITY. Formatting fix. gcc/testsuite/ * gcc.dg/pr114574-1.c: New test. * gcc.dg/pr114574-2.c: New test. * gcc.dg/pr114361.c: New test. * gcc.dg/c23-tag-incomplete-1.c: New test. * gcc.dg/c23-tag-incomplete-2.c: New test.
[Bug libstdc++/114770] std::chrono::locate_zone("Asia/Chungking") fails on Debian Sid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114770
--- Comment #1 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:eed7fb1b2fe72150cd6af10dd3b8f7fc4f0a4da1
commit r14-10043-geed7fb1b2fe72150cd6af10dd3b8f7fc4f0a4da1
Author: Jonathan Wakely
Date: Thu Apr 18 12:14:41 2024 +0100
libstdc++: Support link chains in std::chrono::tzdb::locate_zone [PR114770]
Since 2022 the TZif format defined in the zic(8) man page has said that
links can refer to other links, rather than only referring to a zone.
This isn't supported by the C++20 spec, which assumes that the target()
for a chrono::time_zone_link always names a chrono::time_zone, not
another chrono::time_zone_link.
This hasn't been a problem until now, because there are no entries in
the tzdata file that chain links together. However, Debian Sid has
changed the target of the Asia/Chungking link from the Asia/Shanghai
zone to the Asia/Chongqing link, creating a link chain. The libstdc++
code is unable to handle this, so chrono::locate_zone("Asia/Chungking")
will fail with the tzdata.zi file from Debian Sid.
It seems likely that the C++ spec will need a change to allow link
chains, so that the original structure of the IANA database can be fully
represented by chrono::tzdb. The alternative would be for chrono::tzdb
to flatten all chains when loading the data, so that a link's target is
always a zone, but this means throwing away information present in the
tzdata.zi input file.
In anticipation of a change to the spec, this commit adds support for
chained links to libstdc++. When a name is found to be a link, we try to
find its target in the list of zones as before, but now if the target
isn't the name of a zone we don't fail. Instead we look for another link
with that name, and keep doing that until we reach the end of the chain
of links, and then look up the last target as a zone.
This new logic would get stuck in a loop if the tzdata.zi file is buggy
and defines a link chain that contains a cycle, e.g. two links that
refer to each other. To deal with that unlikely case, we use the
tortoise and hare algorithm to detect cycles in link chains, and throw
an exception if we detect a cycle. Cycles in links should never happen,
and it is expected that link chains will be short (if they occur at all)
and so the code is optimized for short chains without cycles. Longer
chains (four or more links) and cycles will do more work, but won't fail
to resolve a chain or get stuck in a loop.
The new test file checks various forms of broken links and cycles.
Also add a new check in the testsuite that every element in the
get_tzdb().zones and get_tzdb().links sequences can be successfully
found using locate_zone.
libstdc++-v3/ChangeLog:
PR libstdc++/114770
* src/c++20/tzdb.cc (do_locate_zone): Support links that have
another link as their target.
* testsuite/std/time/tzdb/1.cc: Check that all zones and links
can be found by locate_zone.
* testsuite/std/time/tzdb/links.cc: New test.
[Bug middle-end/114753] from_chars aborts with -m32 -ftrapv when passed -9223372036854775808
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753 --- Comment #9 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:33bf8e5385099c2963f278bff38e4f917eddf1d8 commit r14-10041-g33bf8e5385099c2963f278bff38e4f917eddf1d8 Author: Jakub Jelinek Date: Fri Apr 19 18:15:39 2024 +0200 internal-fn: Fix up expand_arith_overflow [PR114753] During backporting I've noticed I've missed one return spot for the restoration of the original flag_trapv flag value. 2024-04-19 Jakub Jelinek PR middle-end/114753 * internal-fn.cc (expand_arith_overflow): Add one missing restore of flag_trapv before return.
[Bug tree-optimization/113964] [11/12/13/14/15 Regression] repeat copy of struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113964 --- Comment #6 from GCC Commits --- The releases/gcc-13 branch has been updated by Martin Jambor : https://gcc.gnu.org/g:5c3238b0d55ec13a2430aa606e2bfed9432e97ac commit r13-8620-g5c3238b0d55ec13a2430aa606e2bfed9432e97ac Author: Martin Jambor Date: Fri Apr 19 16:48:12 2024 +0200 ipa: Force args obtined through pass-through maps to the expected type (PR 113964) Interactions of IPA-CP and IPA-SRA on the same data is a rather big source of issues, I'm afraid. PR 113964 is a situation where IPA-CP propagates an unsigned short in a union parameter into a function which itself calls a different function which has a same union parameter and both these union parameters are split with IPA-SRA. The leaf function however uses a signed short member of the union. In the calling function, we get the unsigned constant as the replacement for the union and it is then passed in the call without any type compatibility checks. Apparently on riscv64 it matters whether the parameter is signed or unsigned short and so the leaf function can see different values. Fixed by using useless_type_conversion_p at the appropriate place and if it fails, use force_value_to type as elsewhere in similar situations. gcc/ChangeLog: 2024-04-04 Martin Jambor PR ipa/113964 * ipa-param-manipulation.cc (ipa_param_adjustments::modify_call): Force values obtined through pass-through maps to the expected split type. gcc/testsuite/ChangeLog: 2024-04-04 Patrick O'Neill Martin Jambor PR ipa/113964 * gcc.dg/ipa/pr114247.c: New test. (cherry picked from commit 8cd0d29270d4ed86c69b80c08de66dcb6c1e22fe)
[Bug ipa/111571] [13 Regression] ICE in modify_call, at ipa-param-manipulation.cc:656
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111571 --- Comment #7 from GCC Commits --- The releases/gcc-13 branch has been updated by Martin Jambor : https://gcc.gnu.org/g:8a3784adf5cd873ca295a5a011d8623338ff3976 commit r13-8619-g8a3784adf5cd873ca295a5a011d8623338ff3976 Author: Martin Jambor Date: Fri Apr 19 16:48:12 2024 +0200 ipa: Avoid duplicate replacements in IPA-SRA transformation phase When the analysis part of IPA-SRA figures out that it would split out a scalar part of an aggregate which is known by IPA-CP to contain a known constant, it skips it knowing that the transformation part looks at IPA-CP aggregate results too and does the right thing (which can include doing the propagation in GIMPLE because that is the last moment the parameter exists). However, when IPA-SRA wants to split out a smaller aggregate out of an aggregate, which happens to be of the same size as a known scalar constant at the same offset, the transformation bit fails to recognize the situation, tries to do both splitting and constant propagation and in PR 111571 testcase creates a nonsensical call statement on which the call redirection then ICEs. Fixed by making sure we don't try to do two replacements of the same part of the same parameter. The look-up among replacements requires these are sorted and this patch just sorts them if they are not already sorted before each new look-up. The worst number of sortings that can happen is number of parameters which are both split and have aggregate constants times param_ipa_max_agg_items (default 16). I don't think complicating the source code to optimize for this unlikely case is worth it but if need be, it can of course be done. gcc/ChangeLog: 2024-03-15 Martin Jambor PR ipa/111571 * ipa-param-manipulation.cc (ipa_param_body_adjustments::common_initialization): Avoid creating duplicate replacement entries. gcc/testsuite/ChangeLog: 2024-03-15 Martin Jambor PR ipa/111571 * gcc.dg/ipa/pr111571.c: New test. (cherry picked from commit ca56b43105fc09021ec445f1978a17cd85ae5e0c)
[Bug tree-optimization/114769] [14 Regression] Suspicious code in vect_recog_sad_pattern() since r14-1832
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114769 --- Comment #4 from GCC Commits --- The master branch has been updated by Tamar Christina : https://gcc.gnu.org/g:1216460e7023cd8ec49933866107417c70e933c9 commit r14-10040-g1216460e7023cd8ec49933866107417c70e933c9 Author: Tamar Christina Date: Fri Apr 19 15:22:13 2024 +0100 middle-end: refactory vect_recog_absolute_difference to simplify flow [PR114769] Hi All, As the reporter in PR114769 points out the control flow for the abd detection is hard to follow. This is because vect_recog_absolute_difference has two different ways it can return true. 1. It can return true when the widening operation is matched, in which case unprom is set, half_type is not NULL and diff_stmt is not set. 2. It can return true when the widening operation is not matched, but the stmt being checked is a minus. In this case unprom is not set, half_type is set to NULL and diff_stmt is set. This because to get to diff_stmt you have to dig through the abs statement and any possible promotions. This however leads to complicated uses of the function at the call sites as the exact semantic needs to be known to use it safely. vect_recog_absolute_difference has two callers: 1. vect_recog_sad_pattern where if you return true with unprom not set, then *half_type will be NULL. The call to vect_supportable_direct_optab_p will always reject it since there's no vector mode for NULL. Note that if looking at the dump files, the convention in the dump files have always been that we first indicate that a pattern could possibly be recognize and then check that it's supported. This change somewhat incorrectly makes the diagnostic message get printed for "invalid" patterns. 2. vect_recog_abd_pattern, where if half_type is NULL, it then uses diff_stmt to set them. This refactors the code, it now only has 1 success condition, and diff_stmt is always set to the minus statement in the abs if there is one. The function now only returns success if the widening minus is found, in which case unprom and half_type set. This then leaves it up to the caller to decide if they want to do anything with diff_stmt. Thanks, Tamar gcc/ChangeLog: PR tree-optimization/114769 * tree-vect-patterns.cc: (vect_recog_absolute_difference): Have only one success condition. (vect_recog_abd_pattern): Handle further checks if vect_recog_absolute_difference fails.
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522 --- Comment #18 from GCC Commits --- The releases/gcc-12 branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:b9ee0c8830592212678c402aed8a6b11ef8d2640 commit r12-10348-gb9ee0c8830592212678c402aed8a6b11ef8d2640 Author: Iain Sandoe Date: Sat Jan 6 10:52:38 2024 + Darwin: Fix constant CFString code-gen [PR105522]. Although this only fires for one of the Darwin sub-ports, it is latent elsewhere, it is also a regression c.f. the Darwin system compiler. In the code we imported from an earlier branch, CFString objects (which are constant aggregates) are constructed as CONST_DECLs. Although our current documentation suggests that these are reserved for enumeration values, in fact they are used elsewhere in the compiler for constants. This includes Objective-C where they are used to form NSString constants. In the particular case, we take the address of the constant and that triggers varasm.cc:decode_addr_constant, which does not currently support CONST_DECL. If there is a general intent to allow/encourage wider use of CONST_DECL, then we should fix decode_addr_constant to look through these and evaluate the initializer (a two-line patch, but I'm not suggesting it for stage-4). We also need to update the GCC internals documentation to allow for the additional uses. This patch is Darwin-local and fixes the problem by making the CFString constants into regular variable but TREE_CONSTANT+TREE_READONLY. I plan to back-port this to the open branches once it has baked a while on trunk. Since, for Darwin, the Objective-C default is to construct constant NSString objects as CFStrings; this will also cover the majority of cases there (this patch does not make any changes to Objective-C NSStrings). PR target/105522 gcc/ChangeLog: * config/darwin.cc (machopic_select_section): Handle C and C++ CFStrings. (darwin_rename_builtins): Move this out of the CFString code. (darwin_libc_has_function): Likewise. (darwin_build_constant_cfstring): Create an anonymous var to hold each CFString. * config/darwin.h (ASM_OUTPUT_LABELREF): Handle constant CFstrings. Signed-off-by: Iain Sandoe (cherry picked from commit aecc0d4ba73d0810334b351da1e67232cea450d3)
[Bug rtl-optimization/114768] Volatile reads can be optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768
--- Comment #9 from GCC Commits ---
The trunk branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:9451b6c0a941dc44ca6f14ff8565d74fe56cca59
commit r14-10039-g9451b6c0a941dc44ca6f14ff8565d74fe56cca59
Author: Thomas Schwinge
Date: Fri Apr 19 12:32:03 2024 +0200
Enable 'gcc.dg/pr114768.c' for nvptx target [PR114768]
Follow-up to commit 9f295847a9c32081bdd0fe908ffba58e830a24fb
"rtlanal: Fix set_noop_p for volatile loads or stores [PR114768]": nvptx
does
behave in the exactly same way as expected; see 'diff' of before vs. after
the
'gcc/rtlanal.cc' code changes:
PASS: gcc.dg/pr114768.c (test for excess errors)
[-FAIL:-]{+PASS:+} gcc.dg/pr114768.c scan-rtl-dump final "\\(mem/v:"
--- 0/pr114768.c.347r.final 2024-04-19 11:34:34.577037596 +0200
+++ ./pr114768.c.347r.final 2024-04-19 12:08:00.118312524 +0200
@@ -13,15 +13,27 @@
;; entry block defs1 [%stack] 2 [%frame] 3 [%args]
;; exit block uses 1 [%stack] 2 [%frame]
;; regs ever live
-;; ref usage r1={1d,2u} r2={1d,2u} r3={1d,1u}
-;;total ref usage 8{3d,5u,0e} in 1{1 regular + 0 call} insns.
+;; ref usage r1={1d,3u} r2={1d,3u} r3={1d,2u} r22={1d,1u}
r23={1d,2u}
+;;total ref usage 16{5d,11u,0e} in 4{4 regular + 0 call} insns.
(note 1 0 4 NOTE_INSN_DELETED)
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
-(note 2 4 3 2 NOTE_INSN_DELETED)
+(insn 2 4 3 2 (set (reg/v/f:DI 23 [ p ])
+(unspec:DI [
+(const_int 0 [0])
+] UNSPEC_ARG_REG))
"source-gcc/gcc/testsuite/gcc.dg/pr114768.c":8:1 14 {load_arg_regdi}
+ (nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
-(note 6 3 10 2 NOTE_INSN_DELETED)
-(note 10 6 11 2 NOTE_INSN_EPILOGUE_BEG)
-(jump_insn 11 10 12 2 (return)
"source-gcc/gcc/testsuite/gcc.dg/pr114768.c":10:1 289 {return}
+(insn 6 3 7 2 (set (reg:SI 22 [ _1 ])
+(mem/v:SI (reg/v/f:DI 23 [ p ]) [1 MEM[(volatile int
*)p_3(D)]+0 S4 A32])) "source-gcc/gcc/testsuite/gcc.dg/pr114768.c":9:8 6
{*movsi_insn}
+ (nil))
+(insn 7 6 10 2 (set (mem:SI (reg/v/f:DI 23 [ p ]) [1 *p_3(D)+0 S4
A32])
+(reg:SI 22 [ _1 ]))
"source-gcc/gcc/testsuite/gcc.dg/pr114768.c":9:6 6 {*movsi_insn}
+ (expr_list:REG_DEAD (reg/v/f:DI 23 [ p ])
+(expr_list:REG_DEAD (reg:SI 22 [ _1 ])
+(nil
+(note 10 7 13 2 NOTE_INSN_EPILOGUE_BEG)
+(note 13 10 11 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
+(jump_insn 11 13 12 3 (return)
"source-gcc/gcc/testsuite/gcc.dg/pr114768.c":10:1 289 {return}
(nil)
-> return)
(barrier 12 11 0)
--- 0/pr114768.s2024-04-19 11:34:34.577037596 +0200
+++ ./pr114768.s2024-04-19 12:08:00.118312524 +0200
@@ -13,5 +13,10 @@
{
.reg.u64 %ar0;
ld.param.u64 %ar0, [%in_ar0];
+ .reg.u32 %r22;
+ .reg.u64 %r23;
+ mov.u64 %r23, %ar0;
+ ld.u32 %r22, [%r23];
+ st.u32 [%r23], %r22;
ret;
}
PR testsuite/114768
gcc/testsuite/
* gcc.dg/pr114768.c: Enable for nvptx target.
[Bug d/111650] ICE in build_deref, at d/d-codegen.cc:1650
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111650 --- Comment #2 from GCC Commits --- The master branch has been updated by Iain Buclaw : https://gcc.gnu.org/g:4d4929fe0654d51b52a2bf6e6188d7aad0bf17ac commit r14-10036-g4d4929fe0654d51b52a2bf6e6188d7aad0bf17ac Author: Iain Buclaw Date: Fri Apr 19 10:51:12 2024 +0200 d: Fix ICE in build_deref, at d/d-codegen.cc:1650 [PR111650] PR d/111650 gcc/d/ChangeLog: * decl.cc (get_fndecl_arguments): Move generation of frame type to ... (DeclVisitor::visit (FuncDeclaration *)): ... here, after the call to build_closure. gcc/testsuite/ChangeLog: * gdc.dg/pr111650.d: New test.
[Bug rtl-optimization/114768] Volatile reads can be optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768 --- Comment #7 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9f295847a9c32081bdd0fe908ffba58e830a24fb commit r14-10035-g9f295847a9c32081bdd0fe908ffba58e830a24fb Author: Jakub Jelinek Date: Fri Apr 19 08:47:53 2024 +0200 rtlanal: Fix set_noop_p for volatile loads or stores [PR114768] On the following testcase, combine propagates the mem/v load into mem store with the same address and then removes it, because noop_move_p says it is a no-op move. If it was the other way around, i.e. mem/v store and mem load, or both would be mem/v, it would be kept. The problem is that rtx_equal_p never checks any kind of flags on the rtxes (and I think it would be quite dangerous to change it at this point), and set_noop_p checks side_effects_p on just one of the operands, not both. In the MEM <- MEM set, it only checks it on the destination, in store to ZERO_EXTRACT only checks it on the source. The following patch adds the missing side_effects_p checks. 2024-04-19 Jakub Jelinek PR rtl-optimization/114768 * rtlanal.cc (set_noop_p): Don't return true for MEM <- MEM sets if src has side-effects or for stores into ZERO_EXTRACT if ZERO_EXTRACT operand has side-effects. * gcc.dg/pr114768.c: New test.
[Bug libgcc/114762] wrong code with _BitInt() division by "BITINT_NN_MIN"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114762 --- Comment #3 from GCC Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:36f4c8a9ac8f71fc21fcb169c7913e8fef30d15c commit r14-10034-g36f4c8a9ac8f71fc21fcb169c7913e8fef30d15c Author: Jakub Jelinek Date: Fri Apr 19 08:44:54 2024 +0200 libgcc: Another __divmodbitint4 bug fix [PR114762] The following testcase is miscompiled because the code to decrement vn on negative value with all ones in most significant limb (even partial) and 0 in most significant bit of the second most significant limb doesn't take into account the case where all bits below the most significant limb are zero. This has been a problem both in the version before yesterday's commit where it has been done only if un was one shorter than vn before this decrement, and is now problem even more often when it is done earlier. When we decrement vn in such case and negate it, we end up with all 0s in the v2 value, so have both the problems with UB on __builtin_clz* and the expectations of the algorithm that the divisor has most significant bit set after shifting, plus when the decremented vn is 1 it can SIGFPE on division by zero even when it is not division by zero etc. Other values shouldn't get 0 in the new most significant limb after negation, because the bitint_reduce_prec canonicalization should reduce prec if the second most significant limb is all ones and if that limb is all zeros, if at least one limb below it is non-zero, carry in will make it non-zero. The following patch fixes it by checking if at least one bit below the most significant limb is non-zero, in that case it decrements, otherwise it will do nothing (but e.g. for the un < vn case that also means the divisor is large enough that the result should be q 0 r u). 2024-04-18 Jakub Jelinek PR libgcc/114762 * libgcc2.c (__divmodbitint4): Perform the decrement on negative v with most significant limb all ones and the second least significant limb with most significant bit clear always, regardless of un < vn. * gcc.dg/torture/bitint-70.c: New test.
