[Bug libstdc++/100606] Please complete LWG3490: ranges::drop_while_view::begin() is missing a precondition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100606 --- Comment #1 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:11784fe27d879a10dc8a79212c37f50d4f7146f3 commit r12-959-g11784fe27d879a10dc8a79212c37f50d4f7146f3 Author: Patrick Palka Date: Fri May 21 00:05:18 2021 -0400 libstdc++: Implement LWG 3490 change to drop_while_view::begin() libstdc++-v3/ChangeLog: PR libstdc++/100606 * include/std/ranges (drop_while_view::begin): Assert the precondition added by LWG 3490.
[Bug libstdc++/100690] ranges::iota_view::_Sentinel cannot access _M_current of _Iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100690 --- Comment #1 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:317a38cd468d565dc8ce45c6da0dbccf38808f70 commit r12-958-g317a38cd468d565dc8ce45c6da0dbccf38808f70 Author: Patrick Palka Date: Thu May 20 23:39:05 2021 -0400 libstdc++: Fix access issue in iota_view::_Sentinel [PR100690] libstdc++-v3/ChangeLog: PR libstdc++/100690 * include/std/ranges (iota_view::_Sentinel::_M_distance_from): Split out this member function from ... (iota_view::_Sentinel::operator-): ... here, for sake of access control. * testsuite/std/ranges/iota/iota_view.cc (test05): New test.
[Bug target/100712] New: The vec_splatid instruction allows the creation of XXSPLTIDP instructions which produces undefined results.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100712 Bug ID: 100712 Summary: The vec_splatid instruction allows the creation of XXSPLTIDP instructions which produces undefined results. Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org Target Milestone: --- The vec_splatid builtin from altivec.h (i.e. __builtin_vec_xxspltid) allows the user to create an XXSPLTIDP instruction where the value is a single precision denormal value. Right now the compiler warns about this usage, but it should really not allow it. In addition, the warning is buried in rs6000_emit_xxspltidp_v2df (in rs6000.c). A better place might be in rs6000_expand_binop_builtin (in rs6000-calls.) where other usage warnings are given.
[Bug target/100711] New: Miss optimization for pandn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100711
Bug ID: 100711
Summary: Miss optimization for pandn
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com
Target Milestone: ---
Target: x86_64-*-* i?86-*-*
cat test.c
typedef int v4si __attribute__((vector_size (16)));
v4si
foo (int a, v4si b)
{
return (__extension__ (v4si) {~a, ~a, ~a, ~a}) & b;
}
generate
notl%edi
vmovdqa %xmm0, %xmm1
vpbroadcastd%edi, %xmm0
vpand %xmm1, %xmm0, %xmm0
ret
it should be better as
vmovdqa %xmm0, %xmm1
vpbroadcastd%edi, %xmm0
vpandn %xmm1, %xmm0, %xmm0
[Bug other/100463] many errors using GTY and hash_map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100463 Martin Sebor changed: What|Removed |Added Last reconfirmed||2021-05-21 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org
[Bug jit/96089] Support initializers for global variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96089 --- Comment #2 from Antoni --- Created attachment 50851 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50851=edit Add patch to set an arbitrary value to a global variable I made this patch to set an arbitrary value to a global variable. This patch suffers from the same issue as inline assembly (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380), i.e. it segfaults if the `rvalue` is created after the global variable. It seems to be a design issue so I'm not sure what would be the fix for it and having it fixed would allow me to test this new function much more and see if things are missing (i.e. it might require a way to create a constant struct). See the link above for an explanation of this issue.
[Bug go/100537] Bootstrap-O3 and bootstrap-debug fail on 32-bit ARM after gcc-12-657-ga076632e274a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100537 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Target|arm-linux-gnueabihf |arm-linux-gnueabihf ||powerpc64le-linux CC||bergner at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-05-20
[Bug c++/100489] [10/11/12 Regression] ICE in cp/constexpr.c:3556
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100489 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Jason Merrill --- Fixed for 10.4/11.2/12.
[Bug c++/100489] [10/11/12 Regression] ICE in cp/constexpr.c:3556
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100489 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a335afe208cd27cf8ee4cb028fb7769700ab6245 commit r10-9857-ga335afe208cd27cf8ee4cb028fb7769700ab6245 Author: Jason Merrill Date: Wed May 19 21:12:45 2021 -0400 c++: designated init with anonymous union [PR100489] My patch for PR98463 added an assert that tripped on this testcase, because we ended up with a U CONSTRUCTOR with an initializer for a, which is not a member of U. We need to wrap the a initializer in another CONSTRUCTOR for the anonymous union. For the GCC 10 branch, just remove the assert. PR c++/100489 gcc/cp/ChangeLog: * constexpr.c (get_or_insert_ctor_field): Remove assert. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/desig18.C: New test.
[Bug c++/80456] [9/10 Regression] calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80456 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:75c5c4ab2662a92f0e3811cb17e27cc61814b400 commit r10-9856-g75c5c4ab2662a92f0e3811cb17e27cc61814b400 Author: Jason Merrill Date: Thu Apr 15 15:13:18 2021 -0400 c++: constexpr and volatile member function [PR80456] When calling a static member function we still need to evaluate an explicit object argument. But we don't want to force a load of the entire object if the argument is volatile, so we take its address. If as a result it no longer has any side-effects, we don't need to evaluate it after all. gcc/cp/ChangeLog: PR c++/80456 * call.c (build_new_method_call_1): Check again for side-effects with a volatile object. gcc/testsuite/ChangeLog: PR c++/80456 * g++.dg/cpp0x/constexpr-volatile3.C: New test.
[Bug c++/100054] [11 Regression] internal compiler error: in get_nsdmi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100054 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:fe0f9ef823dda3205638a2f23d08eb7d0bc497b9 commit r10-9855-gfe0f9ef823dda3205638a2f23d08eb7d0bc497b9 Author: Jason Merrill Date: Tue Apr 13 12:33:39 2021 -0400 c++: generic lambda in template fn with DMI [PR100054] get_nsdmi instantiates default member initializers on demand. It tries to push into the context of the class before doing so, so access checking works properly, but since my patch for 90479 not for local classes. We should only be doing this when any template parameters have arguments. But in this case, we get here while regenerating a generic lambda, so processing_template_decl is true, even though the class and its DMI are non-dependent at this point. And so we crashed. So let's do more of the pushing into the context of the class even for local classes. gcc/cp/ChangeLog: PR c++/100054 PR c++/90479 * init.c (get_nsdmi): Do more context adjustment for local classes. gcc/testsuite/ChangeLog: PR c++/100054 * g++.dg/cpp1y/lambda-generic-local-class1.C: New test.
[Bug target/90479] gcc-arm-none-eabi-8-2018-q4-major [c99 plus -pg not working]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90479 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:fe0f9ef823dda3205638a2f23d08eb7d0bc497b9 commit r10-9855-gfe0f9ef823dda3205638a2f23d08eb7d0bc497b9 Author: Jason Merrill Date: Tue Apr 13 12:33:39 2021 -0400 c++: generic lambda in template fn with DMI [PR100054] get_nsdmi instantiates default member initializers on demand. It tries to push into the context of the class before doing so, so access checking works properly, but since my patch for 90479 not for local classes. We should only be doing this when any template parameters have arguments. But in this case, we get here while regenerating a generic lambda, so processing_template_decl is true, even though the class and its DMI are non-dependent at this point. And so we crashed. So let's do more of the pushing into the context of the class even for local classes. gcc/cp/ChangeLog: PR c++/100054 PR c++/90479 * init.c (get_nsdmi): Do more context adjustment for local classes. gcc/testsuite/ChangeLog: PR c++/100054 * g++.dg/cpp1y/lambda-generic-local-class1.C: New test.
[Bug c++/100032] [9/10 Regression] renaming alias template that also adds cv-qualifiers is deemed equivalent to underlying template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100032 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:d83c30ec6c4865ca23a135c067eb9b56ac74a1f2 commit r10-9854-gd83c30ec6c4865ca23a135c067eb9b56ac74a1f2 Author: Jason Merrill Date: Tue Apr 13 14:49:29 2021 -0400 c++: alias template equivalence and cv-quals [PR100032] We also need to check that the cv-qualifiers are the same. gcc/cp/ChangeLog: PR c++/100032 * pt.c (get_underlying_template): Compare TYPE_QUALS. gcc/testsuite/ChangeLog: PR c++/100032 * g++.dg/cpp0x/alias-decl-equiv1.C: New test.
[Bug c++/91933] [9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in build_simple_base_path, at cp/class.c:541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91933 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:59d821d3cce3496b3f4ede6293ffe192d0e56014 commit r10-9853-g59d821d3cce3496b3f4ede6293ffe192d0e56014 Author: Jason Merrill Date: Mon Apr 12 17:43:51 2021 -0400 c++: constexpr, inheritance, and local class [PR91933] Here we complained about referring to nm3 from the local class member function because referring to the base class subobject involved taking the variable's address. Let's shortcut this case to avoid that. gcc/cp/ChangeLog: PR c++/91933 * class.c (build_base_path): Shortcut simple non-pointer case. gcc/testsuite/ChangeLog: PR c++/91933 * g++.dg/cpp0x/constexpr-base7.C: New test.
[Bug c++/95486] ICE for alias CTAD with non-dependent argument and constrained constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95486 --- Comment #14 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:92e9b2a995f718f1c2ab1cd0840b439c24d3535f commit r10-9852-g92e9b2a995f718f1c2ab1cd0840b439c24d3535f Author: Jason Merrill Date: Fri Apr 9 18:02:38 2021 -0400 c++: deduction guide using alias [PR99180] alias_ctad_tweaks was expecting that all deduction guides for the class would be suitable for deduction from the alias definition; in this case, the deduction guide uses 'true' and the alias B uses 'false', so deduction fails. But that's OK, we just don't use that deduction guide. I also noticed that we were giving up on deduction entirely if substitution failed for some guide; we should only give up on that particular deduction guide. We ought to give a better diagnostic about this case when deduction fails, but that can wait. gcc/cp/ChangeLog: PR c++/99180 PR c++/93295 PR c++/93867 PR c++/99118 PR c++/96873 * pt.c (alias_ctad_tweaks): Handle failure better. gcc/testsuite/ChangeLog: PR c++/99180 PR c++/93295 PR c++/93867 PR c++/95486 * g++.dg/cpp2a/class-deduction-alias5.C: New test. * g++.dg/cpp2a/class-deduction-alias6.C: New test. * g++.dg/cpp2a/class-deduction-alias7.C: New test. * g++.dg/cpp2a/class-deduction-alias8.C: New test.
[Bug c++/96873] Internal compiler error in alias_ctad_tweaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96873 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:92e9b2a995f718f1c2ab1cd0840b439c24d3535f commit r10-9852-g92e9b2a995f718f1c2ab1cd0840b439c24d3535f Author: Jason Merrill Date: Fri Apr 9 18:02:38 2021 -0400 c++: deduction guide using alias [PR99180] alias_ctad_tweaks was expecting that all deduction guides for the class would be suitable for deduction from the alias definition; in this case, the deduction guide uses 'true' and the alias B uses 'false', so deduction fails. But that's OK, we just don't use that deduction guide. I also noticed that we were giving up on deduction entirely if substitution failed for some guide; we should only give up on that particular deduction guide. We ought to give a better diagnostic about this case when deduction fails, but that can wait. gcc/cp/ChangeLog: PR c++/99180 PR c++/93295 PR c++/93867 PR c++/99118 PR c++/96873 * pt.c (alias_ctad_tweaks): Handle failure better. gcc/testsuite/ChangeLog: PR c++/99180 PR c++/93295 PR c++/93867 PR c++/95486 * g++.dg/cpp2a/class-deduction-alias5.C: New test. * g++.dg/cpp2a/class-deduction-alias6.C: New test. * g++.dg/cpp2a/class-deduction-alias7.C: New test. * g++.dg/cpp2a/class-deduction-alias8.C: New test.
[Bug c++/93867] ICE using class type NTTPs and class template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93867 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:92e9b2a995f718f1c2ab1cd0840b439c24d3535f commit r10-9852-g92e9b2a995f718f1c2ab1cd0840b439c24d3535f Author: Jason Merrill Date: Fri Apr 9 18:02:38 2021 -0400 c++: deduction guide using alias [PR99180] alias_ctad_tweaks was expecting that all deduction guides for the class would be suitable for deduction from the alias definition; in this case, the deduction guide uses 'true' and the alias B uses 'false', so deduction fails. But that's OK, we just don't use that deduction guide. I also noticed that we were giving up on deduction entirely if substitution failed for some guide; we should only give up on that particular deduction guide. We ought to give a better diagnostic about this case when deduction fails, but that can wait. gcc/cp/ChangeLog: PR c++/99180 PR c++/93295 PR c++/93867 PR c++/99118 PR c++/96873 * pt.c (alias_ctad_tweaks): Handle failure better. gcc/testsuite/ChangeLog: PR c++/99180 PR c++/93295 PR c++/93867 PR c++/95486 * g++.dg/cpp2a/class-deduction-alias5.C: New test. * g++.dg/cpp2a/class-deduction-alias6.C: New test. * g++.dg/cpp2a/class-deduction-alias7.C: New test. * g++.dg/cpp2a/class-deduction-alias8.C: New test.
[Bug c++/99118] ICE in alias_ctad_tweaks, at cp/pt.c:28569
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99118 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:92e9b2a995f718f1c2ab1cd0840b439c24d3535f commit r10-9852-g92e9b2a995f718f1c2ab1cd0840b439c24d3535f Author: Jason Merrill Date: Fri Apr 9 18:02:38 2021 -0400 c++: deduction guide using alias [PR99180] alias_ctad_tweaks was expecting that all deduction guides for the class would be suitable for deduction from the alias definition; in this case, the deduction guide uses 'true' and the alias B uses 'false', so deduction fails. But that's OK, we just don't use that deduction guide. I also noticed that we were giving up on deduction entirely if substitution failed for some guide; we should only give up on that particular deduction guide. We ought to give a better diagnostic about this case when deduction fails, but that can wait. gcc/cp/ChangeLog: PR c++/99180 PR c++/93295 PR c++/93867 PR c++/99118 PR c++/96873 * pt.c (alias_ctad_tweaks): Handle failure better. gcc/testsuite/ChangeLog: PR c++/99180 PR c++/93295 PR c++/93867 PR c++/95486 * g++.dg/cpp2a/class-deduction-alias5.C: New test. * g++.dg/cpp2a/class-deduction-alias6.C: New test. * g++.dg/cpp2a/class-deduction-alias7.C: New test. * g++.dg/cpp2a/class-deduction-alias8.C: New test.
[Bug c++/99180] [10 Regression] ICE with alias template and empty parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99180 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:92e9b2a995f718f1c2ab1cd0840b439c24d3535f commit r10-9852-g92e9b2a995f718f1c2ab1cd0840b439c24d3535f Author: Jason Merrill Date: Fri Apr 9 18:02:38 2021 -0400 c++: deduction guide using alias [PR99180] alias_ctad_tweaks was expecting that all deduction guides for the class would be suitable for deduction from the alias definition; in this case, the deduction guide uses 'true' and the alias B uses 'false', so deduction fails. But that's OK, we just don't use that deduction guide. I also noticed that we were giving up on deduction entirely if substitution failed for some guide; we should only give up on that particular deduction guide. We ought to give a better diagnostic about this case when deduction fails, but that can wait. gcc/cp/ChangeLog: PR c++/99180 PR c++/93295 PR c++/93867 PR c++/99118 PR c++/96873 * pt.c (alias_ctad_tweaks): Handle failure better. gcc/testsuite/ChangeLog: PR c++/99180 PR c++/93295 PR c++/93867 PR c++/95486 * g++.dg/cpp2a/class-deduction-alias5.C: New test. * g++.dg/cpp2a/class-deduction-alias6.C: New test. * g++.dg/cpp2a/class-deduction-alias7.C: New test. * g++.dg/cpp2a/class-deduction-alias8.C: New test.
[Bug c++/93295] ICE in alias_ctad_tweaks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93295 --- Comment #13 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:92e9b2a995f718f1c2ab1cd0840b439c24d3535f commit r10-9852-g92e9b2a995f718f1c2ab1cd0840b439c24d3535f Author: Jason Merrill Date: Fri Apr 9 18:02:38 2021 -0400 c++: deduction guide using alias [PR99180] alias_ctad_tweaks was expecting that all deduction guides for the class would be suitable for deduction from the alias definition; in this case, the deduction guide uses 'true' and the alias B uses 'false', so deduction fails. But that's OK, we just don't use that deduction guide. I also noticed that we were giving up on deduction entirely if substitution failed for some guide; we should only give up on that particular deduction guide. We ought to give a better diagnostic about this case when deduction fails, but that can wait. gcc/cp/ChangeLog: PR c++/99180 PR c++/93295 PR c++/93867 PR c++/99118 PR c++/96873 * pt.c (alias_ctad_tweaks): Handle failure better. gcc/testsuite/ChangeLog: PR c++/99180 PR c++/93295 PR c++/93867 PR c++/95486 * g++.dg/cpp2a/class-deduction-alias5.C: New test. * g++.dg/cpp2a/class-deduction-alias6.C: New test. * g++.dg/cpp2a/class-deduction-alias7.C: New test. * g++.dg/cpp2a/class-deduction-alias8.C: New test.
[Bug c++/41723] [9/10 Regression] Error when using a qualified name to declare a nested template instantiation as a friend of the containing template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41723 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:e41d610696b81e72d1d06db176b281424e32fc23 commit r10-9851-ge41d610696b81e72d1d06db176b281424e32fc23 Author: Jason Merrill Date: Wed Apr 7 16:42:44 2021 -0400 c++: friend with redundant qualification [PR41723] Different code paths were correctly choosing to look up D directly, since C is the current instantiation, but here we decided to try to make it a typename type, leading to confusion. Fixed by using dependent_scope_p as we do elsewhere. gcc/cp/ChangeLog: PR c++/41723 * parser.c (cp_parser_class_name): Check dependent_scope_p. gcc/testsuite/ChangeLog: PR c++/41723 * g++.dg/template/friend71.C: New test.
[Bug c++/52625] [9/10 Regression] Incorrect specialization semantics of friend class template declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52625 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:de47fb31b13e6bd20d693cb1eef47cbfb5de20ce commit r10-9850-gde47fb31b13e6bd20d693cb1eef47cbfb5de20ce Author: Jason Merrill Date: Wed Apr 7 15:38:07 2021 -0400 c++: base template friend [PR52625] Here we were mistakenly treating the injected-class-name as a partial specialization. gcc/cp/ChangeLog: PR c++/52625 * pt.c (maybe_process_partial_specialization): Check DECL_SELF_REFERENCE_P. gcc/testsuite/ChangeLog: PR c++/52625 * g++.dg/template/friend70.C: New test.
[Bug c++/92918] [9/10 Regression] Does not do name lookup when using from base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92918 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:decd38f99dd05eb54ddcaee7c52f21a56a844613 commit r10-9849-gdecd38f99dd05eb54ddcaee7c52f21a56a844613 Author: Jason Merrill Date: Wed Apr 7 14:55:48 2021 -0400 c++: using overloaded with local decl [PR92918] The problem here was that the lookup for 'impl' when parsing the template only found the using-declaration, not the member function declaration. This happened because when trying to add the member function declaration, push_class_level_binding_1 saw that the current binding was a USING_DECL and the new value is an overload, and decided to just return success. That 'return true' dates back to r69921. In https://gcc.gnu.org/pipermail/gcc-patches/2003-July/110632.html Nathan mentions that we only push dependent USING_DECLs, which is no longer the case; now that we retain more USING_DECLs, handling this case like the other overloaded function cases seems like the obvious solution. gcc/cp/ChangeLog: PR c++/92918 * name-lookup.c (push_class_level_binding_1): Do overload a new function with a previous using-declaration. gcc/testsuite/ChangeLog: PR c++/92918 * g++.dg/lookup/using66.C: New test.
[Bug c++/96673] [9/10 Regression] Friend class with templates and default constructor not recognized in C++14 or later
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96673
--- Comment #6 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:e206f71eaf98149224269b00407bc5def6ae2dca
commit r10-9848-ge206f71eaf98149224269b00407bc5def6ae2dca
Author: Jason Merrill
Date: Tue Apr 6 15:13:02 2021 -0400
c++: access checking in aggregate initialization [PR96673]
We were deferring access checks while parsing B{}, didn't adjust that
when we went to instantiate the default member initializer for B::c,
deferred access checking for C::C, and then checked it after parsing
B{}, back in the main() context which has no access. We need to do
the
access checks in the class context of the DMI.
I tried fixing this in push_to/pop_from_top_level, but that caused several
regressions.
gcc/cp/ChangeLog:
PR c++/96673
* init.c (get_nsdmi): Don't defer access checking.
gcc/testsuite/ChangeLog:
PR c++/96673
* g++.dg/cpp1y/nsdmi-aggr13.C: New test.
[Bug c++/99901] [9/10 Regression] static const class var implemented with constexpr doesn't emit symbols in C++17 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99901 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5b68416a940b32b739cdc033e018bab5161a721d commit r10-9847-g5b68416a940b32b739cdc033e018bab5161a721d Author: Jason Merrill Date: Tue Apr 6 01:21:05 2021 -0400 c++: C++17 constexpr static data member linkage [PR99901] C++17 makes constexpr static data members implicitly inline variables. In C++14, a subsequent out-of-class declaration is the definition. We want to continue emitting a symbol for such a declaration in C++17 mode, for ABI compatibility with C++14 code that wants to refer to it. Normally I'd distinguish in- and out-of-class declarations by looking at DECL_IN_AGGR_P, but we never set DECL_IN_AGGR_P on inline variables. I think that's wrong, but don't want to mess with it so close to release. Conveniently, we already have a test for in-class declaration earlier in the function. gcc/cp/ChangeLog: PR c++/99901 * decl.c (cp_finish_decl): mark_needed an implicitly inline static data member with an out-of-class redeclaration. gcc/testsuite/ChangeLog: PR c++/99901 * g++.dg/cpp1z/inline-var9.C: New test.
[Bug c++/96311] [9/10 Regression] false positive for -Wunused-but-set-variable (const/constexpr identifier used in generic lambda)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96311 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:8909ed58700694f5ba66499739edfea90a0fc813 commit r10-9846-g8909ed58700694f5ba66499739edfea90a0fc813 Author: Jason Merrill Date: Mon Apr 5 16:22:51 2021 -0400 c++: -Wunused, constant, and generic lambda [PR96311] We never called mark_use for a return value in a function with dependent return type. In that situation we don't know if the use is as an rvalue or lvalue, but we can use mark_exp_read instead. gcc/cp/ChangeLog: PR c++/96311 * typeck.c (check_return_expr): Call mark_exp_read in dependent case. gcc/testsuite/ChangeLog: PR c++/96311 * g++.dg/cpp1y/lambda-generic-Wunused.C: New test.
[Bug c++/95870] [9/10 Regression] ICE (segmentation fault) in most_general_template(), in gcc/cp/pt.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95870 --- Comment #12 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ff24ef677edee888012aaddeb0ec9bbe366b4f57 commit r10-9845-gff24ef677edee888012aaddeb0ec9bbe366b4f57 Author: Jason Merrill Date: Mon Apr 5 11:34:48 2021 -0400 c++: lambda in DMI in class template [PR95870] Here enclosing_instantiation_of was failing to find a match because otctx is struct S and current_function_decl is S::S(), so the latter has more function contexts, and we end up trying to compare S() to NULL_TREE. After spending a bit of time working on establishing the correspondence in this case (class <=> constructor), it occurred to me that we could just use DECL_SOURCE_LOCATION, which is unique for lambdas, since they cannot be redeclared. Since we're so close to release, for now I'm only doing this for the case that was failing before. gcc/cp/ChangeLog: PR c++/95870 * pt.c (enclosing_instantiation_of): Compare DECL_SOURCE_LOCATION if there is no enclosing non-lambda function. gcc/testsuite/ChangeLog: PR c++/95870 * g++.dg/cpp0x/lambda/lambda-nsdmi10.C: New test.
[Bug c++/99201] [9/10 Regression] ICE in tsubst_copy, at cp/pt.c:16581 since r8-7613-g1456e764105702a0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99201 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:7c365bb1462a7a9dadf9b8f8668a0c832b18056c commit r10-9844-g7c365bb1462a7a9dadf9b8f8668a0c832b18056c Author: Jason Merrill Date: Sun Apr 4 01:01:56 2021 -0400 c++: constexpr if and nested generic lambda [PR99201] When building up *_EXTRA_ARGS for a constexpr if or pack expansion, we need to walk into the body of a lambda to find all the local_specializations that we need to remember, like we do in find_parameter_packs_r. gcc/cp/ChangeLog: PR c++/99201 * pt.c (class el_data): Add visited field. (extract_local_specs): Pass it to cp_walk_tree. (extract_locals_r): Walk into the body of a lambda. gcc/testsuite/ChangeLog: PR c++/99201 * g++.dg/cpp1z/constexpr-if-lambda4.C: New test.
[Bug c++/99643] [9/10 Regression] internal compiler error in build_over_call, involving array new and copy elision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99643 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:dce71e0a274f58fe7cbabba8760f78469ba13548 commit r10-9843-gdce71e0a274f58fe7cbabba8760f78469ba13548 Author: Jason Merrill Date: Sat Apr 3 16:17:29 2021 -0400 c++: array new initialized from a call [PR99643] Here the get_foo() call results in a TARGET_EXPR, which we strip in massage_init_elt, but then when build_vec_init tries to use it to initialize the array element we crash because build_aggr_init expects a class rvalue to have a TARGET_EXPR. So don't strip it. The stripping was added in r206639 for PR59659, so I checked that removing it didn't significantly increase compile time or memory usage for that testcase; compile time was unaffected, memory usage increased by 0.4%. gcc/cp/ChangeLog: PR c++/99643 * typeck2.c (massage_init_elt): Don't strip TARGET_EXPR. gcc/testsuite/ChangeLog: PR c++/99643 * g++.dg/cpp0x/initlist-new5.C: New test.
[Bug c++/90664] [9/10 regression] noexcept confuses template argument deduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90664 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b13ac26df5e401ce5914b8ec0c862d56edd57913 commit r10-9842-gb13ac26df5e401ce5914b8ec0c862d56edd57913 Author: Jason Merrill Date: Fri Apr 2 17:07:12 2021 -0400 c++: PMF template parm and noexcept [PR90664] The constexpr code only wants to preserve PTRMEM_CST in conversions if the conversions are only qualification conversions; dropping noexcept counts as a qualification adjustment in overload resolution, so let's include it here. gcc/cp/ChangeLog: PR c++/90664 * cvt.c (can_convert_qual): Check fnptr_conv_p. gcc/testsuite/ChangeLog: PR c++/90664 * g++.dg/cpp1z/noexcept-type24.C: New test.
[Bug c++/91217] [9/10 Regression] Returning std::array from lambda results in an extra copy step on return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91217 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a12ae580e13f5856983142a0234651d8e8aad599 commit r10-9841-ga12ae580e13f5856983142a0234651d8e8aad599 Author: Jason Merrill Date: Sat Apr 3 01:07:36 2021 -0400 c++: NRV in lambda in template [PR91217] tsubst_lambda_expr was producing a function with two blocks that claimed to be the outermost block in the function body, one from the call to start_lambda_function in tsubst_lambda_expr, and one from tsubsting the block added by start_lambda_function when we first parsed the lambda. This messed with the named return value optimization, which only works for variables in the outermost block. gcc/cp/ChangeLog: PR c++/91217 * pt.c (tsubst_lambda_expr): Skip the body block from DECL_SAVED_TREE. gcc/testsuite/ChangeLog: PR c++/91217 * g++.dg/opt/nrv20.C: New test.
[Bug c++/97938] [9/10 Regression] g++ crash when inferring type of auto parameter pack in lambda capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97938 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5e7801808d2e9e99dc2931462c69a80c6f0e89cc commit r10-9840-g5e7801808d2e9e99dc2931462c69a80c6f0e89cc Author: Jason Merrill Date: Fri Apr 2 11:05:46 2021 -0400 c++: lambda pack init-capture within generic lambda We represent the type of a pack init-capture as auto... with packs from the initializer stuck into PACK_EXPANSION_PARAMETER_PACKS so that expanding it produces the right number of elements. But when partially instantiating the auto..., we were changing PACK_EXPANSION_PARAMETER_PACKS to refer to only the auto itself. Fixed thus. gcc/cp/ChangeLog: PR c++/97938 * cp-tree.h (PACK_EXPANSION_AUTO_P): New. * lambda.c (add_capture): Set it. * pt.c (tsubst_pack_expansion): Handle it. gcc/testsuite/ChangeLog: PR c++/97938 * g++.dg/cpp2a/lambda-pack-init6.C: New test.
[Bug fortran/100551] [11/12 Regression] Passing return value of intrinsic to class(*) dummy argument can cause segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100551 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-May/056071.html
[Bug c++/100700] -Wreturn-type has many false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700 gnzlbg changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #4 from gnzlbg --- > That's true if you use -fstrict-enums, Wasn't aware of this. Thanks, closing as invalid.
[Bug analyzer/100705] RFE: warn about dead store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100705 David Malcolm changed: What|Removed |Added Summary|warn about dead store |RFE: warn about dead store --- Comment #1 from David Malcolm --- Thanks for filing this RFE. Some notes: "CWE-563: Assignment to Variable without Use": https://cwe.mitre.org/data/definitions/563.html PVS-Studio implements this as V-519: https://pvs-studio.com/en/docs/warnings/v519/ https://pvs-studio.com/en/blog/examples/v519/ (lots of examples at that link) I'm not sure how well this ties into what the analyzer is already doing, though.
[Bug c++/100489] [10/11/12 Regression] ICE in cp/constexpr.c:3556
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100489 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:0a1010428b3861464eb319c629c68cb13b9ca01e commit r11-8449-g0a1010428b3861464eb319c629c68cb13b9ca01e Author: Jason Merrill Date: Wed May 19 21:12:45 2021 -0400 c++: designated init with anonymous union [PR100489] My patch for PR98463 added an assert that tripped on this testcase, because we ended up with a U CONSTRUCTOR with an initializer for a, which is not a member of U. We need to wrap the a initializer in another CONSTRUCTOR for the anonymous union. There was already support for this in process_init_constructor_record, but not in process_init_constructor_union. But since this is about brace elision, it really belongs under reshape_init rather than digest_init, so this patch moves the handling to reshape_init_class, which also handles unions. PR c++/100489 gcc/cp/ChangeLog: * decl.c (reshape_init_class): Handle designator for member of anonymous aggregate here. * typeck2.c (process_init_constructor_record): Not here. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/desig18.C: New test.
[Bug c++/100489] [10/11/12 Regression] ICE in cp/constexpr.c:3556
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100489 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:84fd1b5dff70cd74aee7e8b18f66959d8b8e1ce7 commit r12-954-g84fd1b5dff70cd74aee7e8b18f66959d8b8e1ce7 Author: Jason Merrill Date: Wed May 19 21:12:45 2021 -0400 c++: designated init with anonymous union [PR100489] My patch for PR98463 added an assert that tripped on this testcase, because we ended up with a U CONSTRUCTOR with an initializer for a, which is not a member of U. We need to wrap the a initializer in another CONSTRUCTOR for the anonymous union. There was already support for this in process_init_constructor_record, but not in process_init_constructor_union. But since this is about brace elision, it really belongs under reshape_init rather than digest_init, so this patch moves the handling to reshape_init_class, which also handles unions. PR c++/100489 gcc/cp/ChangeLog: * decl.c (reshape_init_class): Handle designator for member of anonymous aggregate here. * typeck2.c (process_init_constructor_record): Not here. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/desig18.C: New test.
[Bug target/100693] PPC: missing 64-bit addg6s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100693 Segher Boessenkool changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-20 Status|UNCONFIRMED |NEW
[Bug target/100693] PPC: missing 64-bit addg6s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100693 --- Comment #1 from Segher Boessenkool --- Confirmed. The define_insn for it is for SImode only as well.
[Bug libstdc++/100676] Redeclaring __failed_assertion() at every point of use of __glibcxx_assert breaks Clang CUDA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100676 --- Comment #3 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6b42b5a8a207de5e021a2916281f46bcd60b20d2 commit r12-952-g6b42b5a8a207de5e021a2916281f46bcd60b20d2 Author: Jonathan Wakely Date: Thu May 20 16:39:06 2021 +0100 libstdc++: Use __builtin_unreachable for constexpr assertions [PR 100676] The current implementation of compile-time precondition checks causes compilation to fail by calling a non-constexpr function declared at block scope. This breaks the CUDA compiler, which wraps some libstdc++ headers in a pragma that declares everything as a __host__ __device__ function, but others are not wrapped and so everything is a __host__ function. The local declaration thus gets redeclared as two different types of function, which doesn't work. Just use __builtin_unreachable to make constant evaluation fail, instead of the local function declaration. Also simplify the assertion macros, which has the side effect of giving simpler compilation errors when using Clang. libstdc++-v3/ChangeLog: PR libstdc++/100676 * include/bits/c++config (__glibcxx_assert_1): Rename to ... (__glibcxx_constexpr_assert): ... this. (__glibcxx_assert_impl): Use __glibcxx_constexpr_assert. (__glibcxx_assert): Define as either __glibcxx_constexpr_assert or __glibcxx_assert_impl. (__glibcxx_assert_2): Remove * include/debug/macros.h (_GLIBCXX_DEBUG_VERIFY_AT_F): Use __glibcxx_constexpr_assert instead of __glibcxx_assert_1. * testsuite/21_strings/basic_string_view/element_access/char/back_constexpr_neg.cc: Adjust expected error. * testsuite/21_strings/basic_string_view/element_access/char/constexpr_neg.cc: Likewise. * testsuite/21_strings/basic_string_view/element_access/char/front_constexpr_neg.cc: Likewise. Likewise. * testsuite/21_strings/basic_string_view/element_access/wchar_t/back_constexpr_neg.cc: Likewise. * testsuite/21_strings/basic_string_view/element_access/wchar_t/constexpr_neg.cc: Likewise. * testsuite/21_strings/basic_string_view/element_access/wchar_t/front_constexpr_neg.cc: Likewise. * testsuite/23_containers/span/back_neg.cc: Likewise. * testsuite/23_containers/span/front_neg.cc: Likewise. * testsuite/23_containers/span/index_op_neg.cc: Likewise.
[Bug c++/100710] New: static_cast to derived* of base* pointing to non-static data member of base type not rejected in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100710
Bug ID: 100710
Summary: static_cast to derived* of base* pointing to
non-static data member of base type not rejected in
constant expression
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.e.cobb at gmail dot com
Target Milestone: ---
In the following code:
[code]
class B {};
class D : public B {
public:
B member;
};
constexpr bool test(bool do_ub = true) {
if (do_ub) {
D d;
return static_cast() != nullptr;
}
return false;
}
static_assert(test());
[/code]
On Compiler Explorer: https://godbolt.org/z/eKEcT7bhb
GCC 11.1 accepts when it should reject due to the static_cast being UB during
the evaluation of a constant expression, as the pointer to B does not actually
point to a base class subobject of an object of type D.
>From [expr.static.cast]/11:
> If the prvalue of type “pointer to cv1 B” points to a B that is actually a
> subobject of an object of type D, the resulting pointer points to the
> enclosing object of type D. Otherwise, the behavior is undefined.
This wording is slightly broken because it says "actually a subobject" instead
of "actually a base class subobject", but there is an editorial PR to fix this:
https://github.com/cplusplus/draft/pull/4605
[Bug fortran/100656] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100656 --- Comment #2 from anlauf at gcc dot gnu.org --- Using a temporary may help: subroutine s(x) character(:), allocatable, optional :: x(:) character(:), allocatable :: y(:) if ( present(x) ) then if ( allocated(x) ) then y = 'a' // x // 'e' x = y end if end if end This does not ICE.
[Bug target/100694] PPC: initialization of __int128 is very inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100694 Segher Boessenkool changed: What|Removed |Added Last reconfirmed||2021-05-20 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Segher Boessenkool --- The important difference between powerpc64 and aarch64 is that the store is in TImode for powerpc64, but as two DImode stores for aarch64, right after expand already (and before expand the code was identical). Confirmed.
[Bug c++/100708] dynamic_cast can convert xvalue to lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100708 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-20 Ever confirmed|0 |1
[Bug c++/100709] New: Use of a function parameter pack in an expression expected to be constexpr in a deduction guide produces an unclear diagnostic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100709 Bug ID: 100709 Summary: Use of a function parameter pack in an expression expected to be constexpr in a deduction guide produces an unclear diagnostic. Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: brycelelbach at gmail dot com Target Milestone: --- Use of a function parameter pack in an expression expected to be `constexpr` in a deduction guide leads to an unclear diagnostic. Such code should be ill-formed, because a function parameter pack is not `constexpr` itself, so it can't be used in a `constexpr` context. Use a function parameter pack in an expression expected to be `constexpr` in other contexts, like in a function body, does produce a good diagnostic, which points to the problematic line of code and names the problematic function parameter pack (`i`) - or at least, names the expansion of it to its elements. I found this diagnostic sufficient to understand the issue. You can see both cases here: https://godbolt.org/z/4joWjejMn
[Bug c++/100700] -Wreturn-type has many false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700 --- Comment #3 from Jonathan Wakely --- (In reply to gnzlbg from comment #2) > Until C++17, creating an enum value that's out-of-range of the enum was > unspecified behavior. In C++ standard >= 17 (e.g. -std=c++17), this became > undefined behavior. With GCC it depends on the -fstrict-enums option. > The only way in which "h(E e)" can fall of its end in C++>=17 is if the > program already had undefined behavior. That's true if you use -fstrict-enums, and if you do that, there's no warning. Without that option GCC does not treat (E)2 as undefined, and so it considers it possible for the function to be called with that value.
[Bug c++/100708] New: dynamic_cast can convert xvalue to lvalue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100708
Bug ID: 100708
Summary: dynamic_cast can convert xvalue to lvalue
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
GCC accepts
struct A { virtual ~A() {}; };
struct B : A {} b;
void g ()
{
dynamic_cast(static_cast(b));
}
[expr.dynamic.cast]/2 says that for dynamic_cast(v):
If T is an lvalue reference type, v shall be an lvalue of a complete class
type, and the result is an lvalue of the type referred to by T.
[Bug c++/51577] dependent name lookup finds operator in global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 Patrick Palka changed: What|Removed |Added CC||asif_bahrainwala at hotmail dot co ||m --- Comment #21 from Patrick Palka --- *** Bug 99611 has been marked as a duplicate of this bug. ***
[Bug c++/99611] Code compilation issue using templates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99611 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Patrick Palka --- Thanks for the bug report. This looks like a dup of PR51577, which has recently been partially fixed on trunk. *** This bug has been marked as a duplicate of bug 51577 ***
[Bug middle-end/100684] [11 Regression] spurious -Wnonnull with -O1 on a C++ lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100684 Martin Sebor changed: What|Removed |Added Summary|spurious -Wnonnull with -O1 |[11 Regression] spurious |on a C++ lambda |-Wnonnull with -O1 on a C++ ||lambda Known to fail|12.0| --- Comment #4 from Martin Sebor --- Fixed on trunk. Will backport to 11.2.
[Bug middle-end/100684] spurious -Wnonnull with -O1 on a C++ lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100684 --- Comment #3 from CVS Commits --- The master branch has been updated by Martin Sebor : https://gcc.gnu.org/g:9480491a6447576e8e695b8ea3c4989cf72c9670 commit r12-948-g9480491a6447576e8e695b8ea3c4989cf72c9670 Author: Martin Sebor Date: Thu May 20 13:15:58 2021 -0600 PR middle-end/100684 - spurious -Wnonnull with -O1 on a C++ lambda gcc/ChangeLog: PR middle-end/100684 * tree-ssa-ccp.c (pass_post_ipa_warn::execute): Handle C++ lambda. gcc/testsuite/ChangeLog: PR middle-end/100684 * g++.dg/warn/Wnonnull13.C: New test. * g++.dg/warn/Wnonnull14.C: New test. * g++.dg/warn/Wnonnull15.C: New test.
[Bug c++/100700] -Wreturn-type has many false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700 --- Comment #2 from gnzlbg --- > in a call to f(-1) the function falls off the end, Indeed, thanks. Using <= in the condition removes the warning. > and ditto in a call to h ((enum E)2) Until C++17, creating an enum value that's out-of-range of the enum was unspecified behavior. In C++ standard >= 17 (e.g. -std=c++17), this became undefined behavior. So the warning should point at the place where this happens: (enum E)2. The only way in which "h(E e)" can fall of its end in C++>=17 is if the program already had undefined behavior.
[Bug fortran/92065] [9/10/11/12 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #27 from anlauf at gcc dot gnu.org --- The code seems to compile with today's trunk, but still fails with 11-branch. Could one of Paul's recent commits have fixed this? If so, a backport might be nice.
[Bug testsuite/100655] 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #6 from Bernd Edlinger --- Jonathan, what was the problem why you wanted to add the dg-shouldfail ?
[Bug tree-optimization/88240] [9 Regression] Potential optimization bug: invalid pre-load of floating-point value could cause SIGFPE-underflow if value is integer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88240 --- Comment #23 from Thomas De Schampheleire --- Thanks a lot!
[Bug tree-optimization/100696] mult_higpart is not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100696 Uroš Bizjak changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #2 from Uroš Bizjak --- Related: PR89386. CC added.
[Bug libstdc++/100639] reverse_iterator::reference erroneously uses iterator_traits::reference instead of iter_reference_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100639 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:d5cbe0f0d4b7bc11f80b2236521f90ec94e95767 commit r12-946-gd5cbe0f0d4b7bc11f80b2236521f90ec94e95767 Author: Patrick Palka Date: Thu May 20 14:08:17 2021 -0400 libstdc++: Implement missing P0896R4 changes to reverse_iterator [PR100639] This implements the P0896R4 changes to reverse_iterator's member types value_type, difference_type and reference in C++20 mode, which fixes taking the reverse_iterator of an iterator with a non-integral difference_type (such as iota_view). libstdc++-v3/ChangeLog: PR libstdc++/100639 * include/bits/stl_iterator.h (reverse_iterator::difference_type): In C++20 mode, define in terms of iter_difference_t as per P0896R4. (reverse_iterator::reference): Likewise, but with iter_reference_t. (reverse_iterator::value_type): Likewise, but with iter_value_t. * testsuite/std/ranges/adaptors/reverse.cc (test08): New test. * testsuite/24_iterators/reverse_iterator/100639.cc: New test.
[Bug target/100706] Invalid instructions in plt calls on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100706 --- Comment #1 from Andrew Pinski --- GCC does not generate the PLTs directly normally. It is the linker. Does using BFD ld instead of gold fix the issue?
[Bug c++/100700] -Wreturn-type has many false positives
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100700
Martin Sebor changed:
What|Removed |Added
CC||msebor at gcc dot gnu.org
Severity|normal |enhancement
--- Comment #1 from Martin Sebor ---
[Please include the full command line and the full compiler output in bug
reports (as requested in https://gcc.gnu.org/bugs/#need). Links to third party
sites are not a substitute (they can go away and the compiler versions they use
can change).]
$ cat pr100700.c && gcc -S -xc++ pr100700.c
int f(unsigned i) {
if (i < unsigned(-1)) return i;
}
enum E { A, B };
int h (enum E e) {
switch (e) {
case A: return 0;
case B: return 0;
}
}
pr100700.c: In function ‘int f(unsigned int)’:
pr100700.c:4:1: warning: control reaches end of non-void function
[-Wreturn-type]
4 | }
| ^
pr100700.c: In function ‘int h(E)’:
pr100700.c:13:1: warning: control reaches end of non-void function
[-Wreturn-type]
13 | }
| ^
In both examples the warning is strictly correct: in a call to f(-1) the
function falls off the end, and ditto in a call to h ((enum E)2). I could see
value in relaxing the warning for the enum case and issuing it only under some
stricter setting (say with -Wextra or under a new level), similarly to
-Wswitch-default. I think there already is a request along these lines.
[Bug c/100702] Strict overflow warning regression in gcc 8 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100702 Martin Sebor changed: What|Removed |Added CC||msebor at gcc dot gnu.org Severity|normal |enhancement Last reconfirmed||2021-05-20 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #3 from Martin Sebor --- It should be possible to detect the wide-spread 'i < i + 1' anipattern in the front ends without too many false positives (with __builtin_warning it should even be able to avoid them in dead code). Let me confirm this request on that basis.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #225 from John Buddery --- Yes, I looked briefly at that - I added a new class, but then started hitting bundling errors because it wasn't being positioned correctly in the 3 instruction bundle. It will need more changes to itanium2.md, which looks at the actual itanium_class rather than just the derived type as I was expecting, and fixes the bundling for long_i only (rather than type L). For now I've reverted to scall to test the other changes - this seems to work, probably because the assembler is fixing up any bundling issues This isn't really right though, as you say it needs combined long_i and scall behaviour for a new type.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #224 from dave.anglin at bell dot net --- On 2021-05-20 10:59 a.m., jvb at cyberscience dot com wrote: > but I need to work out how to vary the attribute, as you were right: scall > maps > to a "B" type attribute, but brl is an L+X instruction not a pure B unit > instruction, so I think it should be type "L". I think brl needs its own class. Currently, long_i (for movl) and nop_x (for nop.x) map to type "L". The brl class should also map to type "L" but its bypass behavior should be similar to scall.
[Bug target/100701] [12 Regression] wrong code with -O -fschedule-insns2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100701 Uroš Bizjak changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Uroš Bizjak --- Fixed.
[Bug target/100701] [12 Regression] wrong code with -O -fschedule-insns2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100701 --- Comment #3 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:a71f55c482ada2c6c31d450ac22494b547512127 commit r12-945-ga71f55c482ada2c6c31d450ac22494b547512127 Author: Uros Bizjak Date: Thu May 20 18:48:16 2021 +0200 i386: Avoid integer logic insns for 32bit and 64bit vector modes [PR100701] Integer logic instructions clobber flags, do not use them for 32bit and 64bit vector modes. 2021-05-20 Uroš Bizjak gcc/ PR target/100701 * config/i386/i386.md (isa): Remove x64_bmi. (enabled): Remove x64_bmi. * config/i386/mmx.md (mmx_andnot3): Remove general register alternative. (*andnot3): Ditto. (*mmx_3): Ditto. (*3): Ditto. gcc/testsuite/ PR target/100701 * gcc.target/i386/pr100701.c: New test.
[Bug c/100661] [11/12 Regression] ICE in omp-low.c / refs_may_alias_p_2, at tree-ssa-alias.c:2460
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100661
Jakub Jelinek changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org,
||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Slightly better testcase:
void
foo (char **x)
{
#pragma omp parallel for
for (int i = 0; i < 16; i++)
{
char c[50];
__builtin_strcpy (c, x[i]);
void bar (void)
{
__builtin_strcat (c, "foo");
}
}
}
This ICEs all the way back to GCC 4.2/4.3. And I'm not sure what can be done
about it. Nested functions are implemented by adding all the variables that
can be accessed from nested functions into a single large frame structure whose
address is passed in the chain argument to the nested function.
But, in the above case, the c array is such a variable, but each thread is
supposed to have a private copy of that variable.
For C, this is a GNU extension and we can do whatever we want, including sorry.
For Fortran, nested functions can be only defined outside of BLOCK and when one
explicitly privatizes some variable, access to them from the nested functions
could be considered UB (like would be e.g. if in C/C++ one privatizes a
variable, but passes (shared or firstprivate or in some global variable)
address of the variable before being privatized and accesses that var through
the pointer).
[Bug c++/100707] [modules] ICE on nested namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100707
--- Comment #1 from wang ivor ---
A quick workaround: https://wandbox.org/permlink/n8E5xJuJhq1CUA0e
Create a module that only contains the namespace declaration, and 'export
import' it whenever you declare a new namespace.
// namespace_decl.cc
export module namespace_decl;
export namespace A::B{
}
// m2.cc
export module m2;
export import namespace_decl;
import m3;
export namespace A::B{
}
[Bug c++/100707] New: [modules] ICE on nested namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100707
Bug ID: 100707
Summary: [modules] ICE on nested namespace
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: amorvincitomnia.iw at gmail dot com
Target Milestone: ---
See it live: https://wandbox.org/permlink/HOMZ2A8ClOzIKXO1
Minimum code to reproduce ICE:
// m3.cc
export module m3;
export namespace A{
}
// m2.cc
export module m2;
import m3;
export namespace A::B{
}
// m1.cc
export module m1;
import m2;
export namespace A::B{
}
Compile it with:
$ g++ "-std=gnu++20" "-fmodules-ts" "m3.cc" "m2.cc" "m1.cc"
Produces the following ICE:
m1.cc:3:21: internal compiler error: in resume_scope, at cp/name-lookup.c:4417
3 | export namespace A::B{
| ^
0x5f4ed6 resume_scope
../../source/gcc/cp/name-lookup.c:4417
0x7328fb push_namespace(tree_node*, bool)
../../source/gcc/cp/name-lookup.c:8882
0x779b37 cp_parser_namespace_definition
../../source/gcc/cp/parser.c:20475
0x77a458 cp_parser_declaration
../../source/gcc/cp/parser.c:14141
0x77a153 cp_parser_module_export
../../source/gcc/cp/parser.c:13951
0x77a153 cp_parser_declaration
../../source/gcc/cp/parser.c:14104
0x77ac4e cp_parser_toplevel_declaration
../../source/gcc/cp/parser.c:14190
0x77ac4e cp_parser_translation_unit
../../source/gcc/cp/parser.c:4942
0x77ac4e c_parse_file()
../../source/gcc/cp/parser.c:45393
0x84b7dd c_common_parse_file()
../../source/gcc/c-family/c-opts.c:1218
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/100646] [11 Regression] gcc -E -fdirectives-only causes "error: unterminated comment" when no new line at the end of file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100646 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[11/12 Regression] gcc -E |[11 Regression] gcc -E |-fdirectives-only causes|-fdirectives-only causes |"error: unterminated|"error: unterminated |comment" when no new line |comment" when no new line |at the end of file |at the end of file --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug target/100706] New: Invalid instructions in plt calls on PPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100706
Bug ID: 100706
Summary: Invalid instructions in plt calls on PPC
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: alexander.gr...@tu-dresden.de
Target Milestone: ---
This turns up when compiling TensorFlow 2.5.0 on ppc9le. I wasn't yet able to
reduce the code to reproduce it with a small example, so only got the
following:
The relevant code is this:
mutex.h:
struct MuData {
void* space[2];
};
struct mutex{
mutex();
MuData m_;
};
--
mutex.cc:
#include "mutex.h"
#include "nsync_mu.h"
static inline nsync::nsync_mu *mu_cast(MuData *mu) {
return reinterpret_cast(mu);
}
mutex::mutex() { nsync::nsync_mu_init(mu_cast(_)); }
--
This is compiled into a shared library with the following compile command: `gcc
-U_FORTIFY_SOURCE -fstack-protector -fno-omit-frame-pointer -g0
'-D_FORTIFY_SOURCE=1' -DNDEBUG -ffunction-sections -fdata-sections -O3
'-mcpu=native' -fno-math-errno -fPIC '-std=c++14'
-fno-canonical-system-headers`
Linker flags used later are `-Wl,-no-as-needed -Wl,-z,relro,-z,now
-Wl,--gc-sections`
The nsync library is from https://github.com/google/nsync (version 1.24)
An instance of the mutex class is than later created by an application linked
against this shared library during init (i.e. in a static global context) and
that raises an SIGILL.
Doing that manually I see a plt_call being made which looks like this:
Dump of assembler code for function
.plt_call._ZN5nsync13nsync_mu_initEPNS_11nsync_mu_s_E:
0x20074900 <+0>: std r2,24(r1)
0x20074904 <+4>: ld r12,-32584(r2)
0x20074908 <+8>: mtctr r12
0x2007490c <+12>:bctr
0x20074910 <+16>:.long 0x0
0x20074914 <+20>:.long 0x0
0x20074918 <+24>:.long 0x0
0x2007491c <+28>:.long 0x0
This looks good and works (as mentioned my reduced example didn't run into the
problem)
The TF compiled version of this plt call looks like this:
Dump of assembler code for function
0003.plt_call._ZN5nsync13nsync_mu_initEPNS_11nsync_mu_s_E:
0x200b19851660 <+0>: std r2,24(r1)
0x200b19851664 <+4>: nop
=> 0x200b19851668 <+8>: .long 0x41004ce
0x200b1985166c <+12>:lfdpf12,264(0)
0x200b19851670 <+16>:mtctr r12
0x200b19851674 <+20>:bctr
0x200b19851678 <+24>:.long 0x0
0x200b1985167c <+28>:.long 0x0
As you can see something inserted a strange value into the asm code. I'm not
sure if gcc or the linker (gold linker used here) creates those plt calls, but
something is obviously wrong here.
I also checked another call into the nsync library: nsync::nsync_mu_lock
The plt call looks very similar:
Dump of assembler code for function
0003.plt_call._ZN5nsync13nsync_mu_lockEPNS_11nsync_mu_s_E:
0x200b19851680 <+0>: std r2,24(r1)
0x200b19851684 <+4>: nop
0x200b19851688 <+8>: .long 0x41004ce
0x200b1985168c <+12>:lfdpf12,240(0)
0x200b19851690 <+16>:mtctr r12
0x200b19851694 <+20>:bctr
0x200b19851698 <+24>:.long 0x0
0x200b1985169c <+28>:.long 0x0
As you can see the constant inserted and everything else but the lfdp offset is
the same.
I hope that is enough to find the problem. I'm happy to provide more insight or
do some further tests if required. However I'm not a PPC expert so I have no
idea where to go further with that.
[Bug target/100704] Vector register isn't used to push BLKmode argument onto stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100704 --- Comment #2 from H.J. Lu --- (In reply to Richard Biener from comment #1) > Hmm, I didn't realize we can't push %xmm regs... With loads+stores the > pushes do not look less efficient for this particular example? I suppose a > nice > architectural enhancement would be a push-multiple - rep pushq anyone? ;) YMM and ZMM load/store is much more efficient.
[Bug testsuite/96488] failures of gnat.dg/unchecked_convert[56].adb on PowerPC64 LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96488 Eric Botcazou changed: What|Removed |Added Target Milestone|--- |9.4 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Eric Botcazou --- .
[Bug testsuite/96488] failures of gnat.dg/unchecked_convert[56].adb on PowerPC64 LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96488 --- Comment #5 from CVS Commits --- The releases/gcc-9 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:5bd98868260de9cfc44224cf3833eb86e95d7c47 commit r9-9544-g5bd98868260de9cfc44224cf3833eb86e95d7c47 Author: Eric Botcazou Date: Thu May 20 17:12:11 2021 +0200 Fix gnat.dg spurious failures on PowerPC64 LE gcc/testsuite PR testsuite/96488 * gnat.dg/unchecked_convert5.adb: Do not run on PowerPC64 LE. * gnat.dg/unchecked_convert6.adb: Likewise.
[Bug c++/100281] ICE with SImode pointer assignment in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100281 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Andreas Krebbel : https://gcc.gnu.org/g:e43f47686980e9d0081aa765b619bdc89189b51a commit r11-8448-ge43f47686980e9d0081aa765b619bdc89189b51a Author: Andreas Krebbel Date: Tue Apr 27 10:09:06 2021 +0200 PR100281 C++: Fix SImode pointer handling The problem appears to be triggered by two locations in the front-end where non-POINTER_SIZE pointers aren't handled right now. 1. An assertion in strip_typedefs is triggered because the alignment of the types don't match. This in turn is caused by creating the new type with build_pointer_type instead of taking the type of the original pointer into account. 2. An assertion in cp_convert_to_pointer is triggered which expects the target type to always have POINTER_SIZE. gcc/cp/ChangeLog: PR c++/100281 * cvt.c (cp_convert_to_pointer): Use the size of the target pointer type. * tree.c (cp_build_reference_type): Call cp_build_reference_type_for_mode with VOIDmode. (cp_build_reference_type_for_mode): Rename from cp_build_reference_type. Add MODE argument and invoke build_reference_type_for_mode. (strip_typedefs): Use build_pointer_type_for_mode and cp_build_reference_type_for_mode for pointers and references. gcc/ChangeLog: PR c++/100281 * tree.c (build_reference_type_for_mode) (build_pointer_type_for_mode): Pick pointer mode if MODE argument is VOIDmode. (build_reference_type, build_pointer_type): Invoke build_*_type_for_mode with VOIDmode. gcc/testsuite/ChangeLog: PR c++/100281 * g++.target/s390/pr100281-1.C: New test. * g++.target/s390/pr100281-2.C: New test. (cherry picked from commit 720dff974ea0487c35c0a4bfa527f30df5066ce1)
[Bug testsuite/96488] failures of gnat.dg/unchecked_convert[56].adb on PowerPC64 LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96488 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:a4b3683e3cb00459eb74d1a37be8936abd529865 commit r10-9839-ga4b3683e3cb00459eb74d1a37be8936abd529865 Author: Eric Botcazou Date: Thu May 20 17:12:11 2021 +0200 Fix gnat.dg spurious failures on PowerPC64 LE gcc/testsuite PR testsuite/96488 * gnat.dg/unchecked_convert5.adb: Do not run on PowerPC64 LE. * gnat.dg/unchecked_convert6.adb: Likewise.
[Bug testsuite/96488] failures of gnat.dg/unchecked_convert[56].adb on PowerPC64 LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96488 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:a470d058707bf3e555f30adc68237f422d0a7d47 commit r11-8447-ga470d058707bf3e555f30adc68237f422d0a7d47 Author: Eric Botcazou Date: Thu May 20 17:12:11 2021 +0200 Fix gnat.dg spurious failures on PowerPC64 LE gcc/testsuite PR testsuite/96488 * gnat.dg/unchecked_convert5.adb: Do not run on PowerPC64 LE. * gnat.dg/unchecked_convert6.adb: Likewise.
[Bug testsuite/96488] failures of gnat.dg/unchecked_convert[56].adb on PowerPC64 LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96488 --- Comment #2 from CVS Commits --- The master branch has been updated by Eric Botcazou : https://gcc.gnu.org/g:325bb080259d3a00c5f5a7378872f78a2b889dfb commit r12-943-g325bb080259d3a00c5f5a7378872f78a2b889dfb Author: Eric Botcazou Date: Thu May 20 17:12:11 2021 +0200 Fix gnat.dg spurious failures on PowerPC64 LE gcc/testsuite PR testsuite/96488 * gnat.dg/unchecked_convert5.adb: Do not run on PowerPC64 LE. * gnat.dg/unchecked_convert6.adb: Likewise.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #223 from dave.anglin at bell dot net ---
On 2021-05-20 10:59 a.m., jvb at cyberscience dot com wrote:
> The simplest variant I have is:
>
> (define_insn "call_nogp"
> [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s"))
> (const_int 0))
>(clobber (match_operand:DI 1 "register_operand" "=b,b"))]
> ""
> {
> if (TARGET_HPUX && which_alternative == 1 )
> return "brl.call%+.many %1 = %0";
> else
> return "br.call%+.many %1 = %0";
> }
This looks good.
I agree it should be possible to get the attribute right for brl.
[Bug testsuite/96488] failures of gnat.dg/unchecked_convert[56].adb on PowerPC64 LE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96488 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED Summary|failures of |failures of |gnat.dg/unchecked_convert5. |gnat.dg/unchecked_convert[5 |adb and |6].adb on PowerPC64 LE |gnat.dg/unchecked_convert6. | |adb | Component|ada |testsuite
[Bug ada/60977] Float_IO.Put fails on large floats when 'digits exceeds 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60977 Eric Botcazou changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |11.0 --- Comment #2 from Eric Botcazou --- Fixed in GCC 11 and later.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #222 from dave.anglin at bell dot net --- On 2021-05-20 10:02 a.m., dave.anglin at bell dot net wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #220 from dave.anglin at bell dot net --- > On 2021-05-20 9:37 a.m., jvb at cyberscience dot com wrote: >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 >> >> --- Comment #219 from John Buddery --- >> Great, thanks - I'll look at ia64.c and build and test with that change. > Instead of creating a separate HPUX pattern, another way might be to setup > an instruction alternative table. See define_insn for prefetch. There is a which_alternative variable that could be used to check for "s" constraint (e.g., "which_alternative == 1").
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
--- Comment #221 from John Buddery ---
Thanks - that is neater, as it avoids the need to change the calls in ia64.c,
which gets messy.
The simplest variant I have is:
(define_insn "call_nogp"
[(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s"))
(const_int 0))
(clobber (match_operand:DI 1 "register_operand" "=b,b"))]
""
{
if (TARGET_HPUX && which_alternative == 1 )
return "brl.call%+.many %1 = %0";
else
return "br.call%+.many %1 = %0";
}
[(set_attr "itanium_class" "br,scall")])
but I need to work out how to vary the attribute, as you were right: scall maps
to a "B" type attribute, but brl is an L+X instruction not a pure B unit
instruction, so I think it should be type "L".
Looks like cond and match-test are valid for attributes, so it should be
possible to get this right.
[Bug libstdc++/100690] ranges::iota_view::_Sentinel cannot access _M_current of _Iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100690 Patrick Palka changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-05-20 CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED
[Bug c++/97051] Evaluating is_constant_evaluated in requires clause fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97051 Patrick Palka changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #7 from Patrick Palka --- *** Bug 100675 has been marked as a duplicate of this bug. ***
[Bug c++/100675] std::string_view::find in constexpr function is not constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100675 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #3 from Patrick Palka --- Already fixed on trunk by r11-3295 (and also fixed for 10.4). This seems like ultimately a variant of PR97051, with the is_constant_evaluated() call instead deeply nested. *** This bug has been marked as a duplicate of bug 97051 ***
[Bug target/100704] Vector register isn't used to push BLKmode argument onto stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100704 --- Comment #1 from Richard Biener --- Hmm, I didn't realize we can't push %xmm regs... With loads+stores the pushes do not look less efficient for this particular example? I suppose a nice architectural enhancement would be a push-multiple - rep pushq anyone? ;)
[Bug analyzer/100705] New: warn about dead store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100705
Bug ID: 100705
Summary: warn about dead store
Product: gcc
Version: 11.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: mail at milianw dot de
Target Milestone: ---
Hey there,
in a large code base I'm working on I stumbled over code in one area that
basically did the below, but in a more elaborate manner. It would have been
quite helpful to get a warning when `-fanalyzer` is passed, because in my
opinion, this code is bogus:
```
struct Properties
{
int foo = 0;
int bar = 0;
};
Properties asdf()
{
Properties ret;
ret.foo = 42; // warning: this has no effect
ret.bar = 1;
ret.foo = 12; // b/c it's unconditionally overwritten here
return ret;
}
```
Thanks
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #220 from dave.anglin at bell dot net --- On 2021-05-20 9:37 a.m., jvb at cyberscience dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #219 from John Buddery --- > Great, thanks - I'll look at ia64.c and build and test with that change. Instead of creating a separate HPUX pattern, another way might be to setup an instruction alternative table. See define_insn for prefetch.
[Bug target/100704] New: Vector register isn't used to push BLKmode argument onto stack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100704
Bug ID: 100704
Summary: Vector register isn't used to push BLKmode argument
onto stack
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
CC: crazylht at gmail dot com, ubizjak at gmail dot com
Target Milestone: ---
Target: i386,x86-64
[hjl@gnu-cfl-2 gcc]$ cat /tmp/x.c
struct S
{
long long s1 __attribute__ ((aligned (8)));
unsigned s2, s3, s4, s5, s6, s7, s8, s9, s10, s11, s12, s13, s14;
};
extern struct S array[];
void bar (struct S x);
void
foo (void)
{
bar (array[0]);
}
[hjl@gnu-cfl-2 gcc]$ gcc -S -O2 /tmp/x.c
[hjl@gnu-cfl-2 gcc]$ cat x.s
.file "x.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
pushq array+56(%rip)
.cfi_def_cfa_offset 24
pushq array+48(%rip)
.cfi_def_cfa_offset 32
pushq array+40(%rip)
.cfi_def_cfa_offset 40
pushq array+32(%rip)
.cfi_def_cfa_offset 48
pushq array+24(%rip)
.cfi_def_cfa_offset 56
pushq array+16(%rip)
.cfi_def_cfa_offset 64
pushq array+8(%rip)
.cfi_def_cfa_offset 72
pushq array(%rip)
.cfi_def_cfa_offset 80
callbar
addq$72, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 11.1.1 20210428 (Red Hat 11.1.1-1)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 gcc]$
[hjl@gnu-cfl-2 gcc]$ ./xgcc -B./ -S -O2 /tmp/x.c -mno-push-args
[hjl@gnu-cfl-2 gcc]$ cat x.s
.file "x.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
subq$72, %rsp
.cfi_def_cfa_offset 80
movdqu array(%rip), %xmm0
movdqu array+16(%rip), %xmm1
movdqu array+32(%rip), %xmm2
movdqu array+48(%rip), %xmm3
movups %xmm0, (%rsp)
movups %xmm1, 16(%rsp)
movups %xmm2, 32(%rsp)
movups %xmm3, 48(%rsp)
callbar
addq$72, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 12.0.0 20210519 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 gcc]$
There is
#define PUSH_ARGS (TARGET_PUSH_ARGS && !ACCUMULATE_OUTGOING_ARGS)
Can we update PUSH_ARGS to also check function arguments?
[Bug gcov-profile/100145] missed optimization for dead code elimination at -O3 (vs. -O2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100145 --- Comment #3 from Richard Biener --- Note after inlining we still have a backedge into BB 3: [local count: 1073741824]: c = 0; b.1_7 = b; if (b.1_7 != 0) goto ; [34.00%] else goto ; [66.00%] [local count: 3318838410]: _9 = 1; _10 = 0; _11 = _9 & _10; if (_11 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 1659419208]: _12 = 0; _13 = _10 & _12; if (_13 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 829709603]: iftmp.0_14 = 1; [local count: 3318838410]: # iftmp.0_15 = PHI <0(3), 0(4), iftmp.0_14(5)> _19 = iftmp.0_15; _8 = _19; c = _8; if (_8 != 0) goto ; [11.00%] else goto ; [89.00%] [local count: 1073741824]: but that's quickly elided by CCP after inlining producing [local count: 1073741824]: c = 0; b.1_7 = b; if (b.1_7 != 0) goto ; [34.00%] else goto ; [66.00%] [local count: 3318838410]: if (0 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 1659419208]: if (0 != 0) goto ; [50.00%] else goto ; [50.00%] [local count: 829709603]: [local count: 3318838410]: c = 1; if (1 != 0) goto ; [11.00%] else goto ; [89.00%] [local count: 1073741824]: and the CFG cleanup ends up with the following: [local count: 1073741824]: c = 0; b.1_7 = b; if (b.1_7 != 0) goto ; [34.00%] else goto ; [66.00%] [local count: 3318838410]: c = 1; [local count: 1073741824]: d = 1; _1 = c; if (_1 > 100) goto ; [33.00%] else goto ; [67.00%] [local count: 354334800]: foo (); [local count: 1073741824]: return 0;
[Bug jit/100688] Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688
--- Comment #7 from David Malcolm ---
One other thing: the docs should make it clear about the leading ".".
If I want to create the equivalent of:
__attribute__((section(".section")))
do I call it with:
gcc_jit_lvalue_set_link_section(foo, "section");
or with:
gcc_jit_lvalue_set_link_section(foo, ".section");
It's a bit unclear to me from just reading the patch. The example suggests
it's the former. In either case, the documentation should be clearer about
this.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #219 from John Buddery --- Great, thanks - I'll look at ia64.c and build and test with that change. Yes, "b" on ia64 seems to be a branch register, and the brl op only accepts immediate values not registers. Initially I hoped the assembler would patch this up and accept both, but it doesn't so the two variants are needed. I'll look into the scall attribute as well.
[Bug jit/100688] Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688
--- Comment #6 from David Malcolm ---
Thanks for the patch; I like the idea; various nits below:
> diff --git a/gcc/jit/docs/topics/expressions.rst
> b/gcc/jit/docs/topics/expressions.rst
> index 396259ef07e..b39f6c02527 100644
> --- a/gcc/jit/docs/topics/expressions.rst
> +++ b/gcc/jit/docs/topics/expressions.rst
> @@ -539,6 +539,18 @@ where the rvalue is computed by reading from the storage
> area.
>
> in C.
>
> +.. function:: void
> + gcc_jit_lvalue_set_link_section (gcc_jit_lvalue *lvalue,
> + const char *name)
> +
> + Set the link section of a variable; analogous to:
> +
> + .. code-block:: c
> +
> + int variable __attribute__((section(".section")));
> +
> + in C.
Please rename param "name" to "section_name". Your implementation requires
that it be non-NULL (rather than having NULL unset the section), so please
specify that it must be non-NULL in the docs.
Please add the usual "This entrypoint was added in" text to state which API
version it was added in.
> +
> Global variables
>
>
> diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
> index 825a3e172e9..8b0f65e87e8 100644
> --- a/gcc/jit/jit-playback.h
> +++ b/gcc/jit/jit-playback.h
> @@ -650,6 +650,8 @@ public:
>
> private:
>context *m_ctxt;
> +
> +protected:
>tree m_inner;
> };
I think you only use this...
>
> @@ -670,6 +672,12 @@ public:
>rvalue *
>get_address (location *loc);
>
> + void
> + set_link_section (const char* name)
> + {
> +set_decl_section_name (m_inner, name);
> + }
...here, and you can get at rvalue::m_inner using as_tree (), so I don't think
we need to make m_inner protected.
> diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c
> index 117ff70114c..d54f878cc6b 100644
> --- a/gcc/jit/jit-recording.c
> +++ b/gcc/jit/jit-recording.c
> @@ -3713,6 +3713,11 @@ recording::lvalue::get_address (recording::location
> *loc)
>return result;
> }
>
> +void recording::lvalue::set_link_section (const char *name)
> +{
> + m_link_section = new_string (name);
> +}
> +
> /* The implementation of class gcc::jit::recording::param. */
>
> /* Implementation of pure virtual hook recording::memento::replay_into
> @@ -4547,8 +4552,7 @@ recording::block::dump_edges_to_dot (pretty_printer *pp)
> void
> recording::global::replay_into (replayer *r)
> {
> - set_playback_obj (
> -m_initializer
> + playback::lvalue *global = m_initializer
> ? r->new_global_initialized (playback_location (r, m_loc),
>m_kind,
>m_type->playback_type (),
> @@ -4560,7 +4564,12 @@ recording::global::replay_into (replayer *r)
> : r->new_global (playback_location (r, m_loc),
>m_kind,
>m_type->playback_type (),
> - playback_string (m_name)));
> + playback_string (m_name));
> + if (m_link_section != NULL)
> + {
> +global->set_link_section(m_link_section->c_str());
> + }
Coding convention nits: don't use {} when it's just one statement (which I
think is a bad convention, but it is the project's convention).
Missing spaces between function name and open-paren in both calls here.
> + set_playback_obj (global);
> }
>
[...snip]
> diff --git a/gcc/jit/jit-recording.h b/gcc/jit/jit-recording.h
> index 03fa1160cf0..0691fac579d 100644
> --- a/gcc/jit/jit-recording.h
> +++ b/gcc/jit/jit-recording.h
> @@ -1105,7 +1105,8 @@ public:
>lvalue (context *ctxt,
> location *loc,
> type *type_)
> -: rvalue (ctxt, loc, type_)
> +: rvalue (ctxt, loc, type_),
> + m_link_section(NULL)
> {}
>
>playback::lvalue *
> @@ -1127,6 +1128,10 @@ public:
>const char *access_as_rvalue (reproducer ) OVERRIDE;
>virtual const char *access_as_lvalue (reproducer );
>virtual bool is_global () const { return false; }
> + void set_link_section (const char *name);
> +
> +protected:
> + string *m_link_section;
> };
Can it be private, rather than protected?
> diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
> index 7fa948007ad..8cfa48aae24 100644
> --- a/gcc/jit/libgccjit.c
> +++ b/gcc/jit/libgccjit.c
> @@ -1953,6 +1953,18 @@ gcc_jit_lvalue_get_address (gcc_jit_lvalue *lvalue,
>return (gcc_jit_rvalue *)lvalue->get_address (loc);
> }
>
> +/* Public entrypoint. See description in libgccjit.h.
> +
> + After error-checking, the real work is done by the
> + gcc::jit::recording::lvalue::set_section method in jit-recording.c. */
^^^
set_link_section
Also, a newline here please for consistency with the other entrypoints.
> +void
> +gcc_jit_lvalue_set_link_section (gcc_jit_lvalue *lvalue,
> + const char *name)
> +{
> + RETURN_IF_FAIL (name, NULL, NULL, "NULL
[Bug target/100701] [12 Regression] wrong code with -O -fschedule-insns2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100701 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com CC|uros at gcc dot gnu.org| --- Comment #2 from Uroš Bizjak --- (In reply to Richard Biener from comment #1) > orq %rdi, %rsi > pshuflw $0, %xmm3, %xmm0 > movq%xmm0, %rbp > and %rbx, %rbp > je .L4 > > Confirmed. Somehow the mmx_andv8qi3 doesn't clobber CC: Eh, stupid me. Let's remove integer regs from the insn patterns for now.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #218 from dave.anglin at bell dot net --- On 2021-05-20 5:19 a.m., jvb at cyberscience dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 > > --- Comment #217 from John Buddery --- > Thanks very much for adding the binutils patch. > > Sorry, I'm new to .md definitions, so I've probably got this wrong. Did you > mean something like: > > (define_insn "call_nogp_longcall" > [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s")) > (const_int 0)) >(clobber (match_operand:DI 1 "register_operand" "=b,b"))] > "TARGET_HPUX && ia64_tune == PROCESSOR_ITANIUM2" > "@ >br.call%+.many %1 = %0 >brl.call%+.many %1 = %0" > [(set_attr "itanium_class" "br,scall")]) > > (define_insn "call_nogp" > [(call (mem:DI (match_operand:DI 0 "call_operand" "?b,s")) > (const_int 0)) >(clobber (match_operand:DI 1 "register_operand" "=b,b"))] > "" > "br.call%+.many %1 = %0" > [(set_attr "itanium_class" "br,scall")]) > > I assume you need a second instruction to catch the case where the condition > doesn't match ? Yes. Note that the call_nogp pattern is output directly in a couple of places in ia64.c. These will need adjustment for hpux. I'm not a ia64 maintainer. I can only apply changes specific to hpux. I have limited knowledge of the ia64 instruction set. In the above, the "brl.call" alternative apples to the "s" constraint for operand 0. Is that what you want? The "br.call" form is used for the disparaged "b" constraint for operand 0. I'm not sure that the scall call attribute is correct for brl. > > Itanium 1 support seems to have been dropped at some point, so -mtune only > accepts options mapping to Itanium2. So, I couldn't test the br case on HP. Then, we don't need to check the ia64_tune in the above.
[Bug target/100703] __vector_pair and __vector_quad cannot be passed by reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100703
--- Comment #1 from Alexander Grund ---
It goes further: Even the usual conversion rules for pointer types don't apply:
void foo(__vector_pair*){}
void bar(const __vector_pair*){}
int main(){
__vector_pair p;
foo(p); // works
bar(p); // fails
}
[Bug testsuite/100655] 'g++.dg/tsan/pthread_cond_clockwait.C' FAILs due to 'pthread_cond_clockwait' missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100655 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|redi at gcc dot gnu.org|unassigned at gcc dot gnu.org
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 --- Comment #12 from CVS Commits --- The releases/gcc-11 branch has been updated by Joern Rennecke : https://gcc.gnu.org/g:5f772bd9847cdbf6a7a6d856de87cb65472d56f4 commit r11-8446-g5f772bd9847cdbf6a7a6d856de87cb65472d56f4 Author: Joern Rennecke Date: Thu May 20 13:21:41 2021 +0100 libstdc++: Disable floating_to_chars.cc on 16 bit targets This patch conditionally disables the compilation of floating_to_chars.cc on 16 bit targets, thus fixing a build failure for these targets as the POW10_SPLIT_2 array exceeds the maximum object size. libstdc++-v3/ PR libstdc++/100361 * include/std/charconv (to_chars): Hide the overloads for floating-point types for 16 bit targets. * src/c++17/floating_to_chars.cc: Don't compile for 16 bit targets. * testsuite/20_util/to_chars/double.cc: Run this test only on size32plus targets. * testsuite/20_util/to_chars/float.cc: Likewise. * testsuite/20_util/to_chars/long_double.cc: Likewise.
[Bug target/99977] arm: ICE with __sync_bool_compare_and_swap and -mcpu=cortex-m23
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99977 --- Comment #9 from CVS Commits --- The releases/gcc-10 branch has been updated by Alex Coplan : https://gcc.gnu.org/g:0a193c95590779aad4036f18258b0eebb9f70a62 commit r10-9838-g0a193c95590779aad4036f18258b0eebb9f70a62 Author: Alex Coplan Date: Tue Apr 27 14:56:15 2021 +0100 arm: Fix ICEs with compare-and-swap and -march=armv8-m.base [PR99977] The PR shows two ICEs with __sync_bool_compare_and_swap and -mcpu=cortex-m23 (equivalently, -march=armv8-m.base): one in LRA and one later on, after the CAS insn is split. The LRA ICE occurs because the @atomic_compare_and_swap_1 pattern attempts to tie two output operands together (operands 0 and 1 in the third alternative). LRA can't handle this, since it doesn't make sense for an insn to assign to the same operand twice. The later (post-splitting) ICE occurs because the expansion of the cbranchsi4_scratch insn doesn't quite go according to plan. As it stands, arm_split_compare_and_swap calls gen_cbranchsi4_scratch, attempting to pass a register (neg_bval) to use as a scratch register. However, since the RTL template has a match_scratch here, gen_cbranchsi4_scratch ignores this argument and produces a scratch rtx. Since this is all happening after RA, this is doomed to fail (and we get an ICE about the insn not matching its constraints). It seems that the motivation for the choice of constraints in the atomic_compare_and_swap pattern comes from an attempt to satisfy the constraints of the cbranchsi4_scratch insn. This insn requires the scratch register to be the same as the input register in the case that we use a larger negative immediate (one that satisfies J, but not L). Of course, as noted above, LRA refuses to assign two output operands to the same register, so this was never going to work. The solution I'm proposing here is to collapse the alternatives to the CAS insn (allowing the two output register operands to be matched to different registers) and to ensure that the constraints for cbranchsi4_scratch are met in arm_split_compare_and_swap. We do this by inserting a move to ensure the source and destination registers match if necessary (i.e. in the case of large negative immediates). Another notable change here is that we only do: emit_move_insn (neg_bval, const1_rtx); for non-negative immediates. This is because the ADDS instruction used in the negative case suffices to leave a suitable value in neg_bval: if the operands compare equal, we don't take the branch (so neg_bval will be set by the load exclusive). Otherwise, the ADDS will leave a nonzero value in neg_bval, which will correctly signal that the CAS has failed when it is later negated. Co-Authored-By: Christophe Lyon gcc/ChangeLog: PR target/99977 * config/arm/arm.c (arm_split_compare_and_swap): Fix up codegen with negative immediates: ensure we expand cbranchsi4_scratch correctly and ensure we satisfy its constraints. * config/arm/sync.md (@atomic_compare_and_swap_1): Don't attempt to tie two output operands together with constraints; collapse two alternatives. (@atomic_compare_and_swap_1): Likewise. * config/arm/thumb1.md (cbranchsi4_neg_late): New. gcc/testsuite/ChangeLog: PR target/99977 * gcc.target/arm/pr99977.c: New test.
[Bug libstdc++/100361] gcc-11 for msp430-elf fails to build: src/c++17/floating_to_chars.cc:107: d2fixed_full_table.h:1283:23: error: size of array ‘POW10_SPLIT_2’ exceeds maximum object size ‘32767’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100361 --- Comment #11 from CVS Commits --- The master branch has been updated by Joern Rennecke : https://gcc.gnu.org/g:66c5f24788652a49b528f14e23e8121ad0935ace commit r12-942-g66c5f24788652a49b528f14e23e8121ad0935ace Author: Joern Rennecke Date: Thu May 20 13:21:41 2021 +0100 libstdc++: Disable floating_to_chars.cc on 16 bit targets This patch conditionally disables the compilation of floating_to_chars.cc on 16 bit targets, thus fixing a build failure for these targets as the POW10_SPLIT_2 array exceeds the maximum object size. libstdc++-v3/ PR libstdc++/100361 * include/std/charconv (to_chars): Hide the overloads for floating-point types for 16 bit targets. * src/c++17/floating_to_chars.cc: Don't compile for 16 bit targets. * testsuite/20_util/to_chars/double.cc: Run this test only on size32plus targets. * testsuite/20_util/to_chars/float.cc: Likewise. * testsuite/20_util/to_chars/long_double.cc: Likewise.
[Bug c/100702] Strict overflow warning regression in gcc 8 onwards
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100702 --- Comment #2 from David Brown --- Runtime diagnostics can be very useful - but they are a different kind of warning. In particular, they only show what errors have occurred during your testing - they don't show what errors /might/ occur. There is a general rule that the earlier you find your problems, the cheaper, faster and easier they are to handle. Compile-time checks are better than run-time checks when all else is equal. Clearly compile-time checks have more risk of false-positives - that's why it's important that most are optional or can be disabled by pragmas or particular code constructs. But when they /can/ be used, they are preferable. In this particular example, there is no doubt of the undefined behaviour and the infinite loop. The compiler knows about them. It would not be a false positive to issue a warning in such cases. Another limitation of runtime diagnostics is their use in embedded systems. gcc is heavily used in microcontrollers, where you often do not have much in the way of a console output, no file system, etc. Runtime diagnostic opportunities are far more limited in such cases. I fully appreciate that compile-time warnings are difficult, especially avoiding false positives, and if you say that a warning here would be too niche or too difficult to justify the effort, I am happy to accept that. But run-time diagnostics are not a replacement - they are an additional and complementary tool. Please do not consider sanitizers as a substitute for static analysis and compile-time error checking and warnings.
