[Bug target/99781] [11 Regression] ICE in partial_subreg_p, at rtl.h:3144
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99781 --- Comment #2 from Arseny Solokha --- (In reply to Jakub Jelinek from comment #1) > ICEs since r8-6032-g43cacb12fc859b671464b63668794158974b2a34 when SVE > support has been added, so doesn't look like a regression to me, as before > that it would not accept that option: > invalid feature modifier in ‘-march=armv8-a+sve’ I can remove the regression marker, but I cannot change the PR priority.
[Bug target/99807] New: ICE in vect_slp_analyze_node_operations_1, at tree-vect-slp.c:3727
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99807 Bug ID: 99807 Summary: ICE in vect_slp_analyze_node_operations_1, at tree-vect-slp.c:3727 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: aarch64-linux-gnu gfortran-11.0.1-alpha20210328 snapshot (g:499fa254ae8c9752d8c2cf3130b13ffddfd83546) ICEs when compiling the following testcase w/ -march=armv8.3-a -O1 -ftree-slp-vectorize: subroutine cppco(ap, z) implicit none complex :: ap(*), z(*) z(1) = z(1) + z(2) * (ap(1)) return end subroutine cppco % aarch64-linux-gnu-gfortran-11.0.1 -march=armv8.3-a -O1 -ftree-slp-vectorize -c xrd4htvk.f90 during GIMPLE pass: slp xrd4htvk.f90:1:16: 1 | subroutine cppco(ap, z) |^ internal compiler error: in vect_slp_analyze_node_operations_1, at tree-vect-slp.c:3727 0x7c41bf vect_slp_analyze_node_operations_1 /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:3727 0x7c41bf vect_slp_analyze_node_operations /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:3933 0x123510b vect_slp_analyze_node_operations /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:3913 0x123510b vect_slp_analyze_node_operations /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:3913 0x1237972 vect_slp_analyze_operations(vec_info*) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:4120 0x123b01d vect_slp_analyze_bb_1 /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:4899 0x123b01d vect_slp_region /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:4945 0x123b01d vect_slp_bbs /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:5095 0x123ce3c vect_slp_function(function*) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vect-slp.c:5181 0x12437fa execute /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/tree-vectorizer.c:1450
[Bug c++/99806] New: ICE in tsubst_copy of gcc-trunk and tree_code_size of gcc-10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99806
Bug ID: 99806
Summary: ICE in tsubst_copy of gcc-trunk and tree_code_size of
gcc-10
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://godbolt.org/z/s687ePeGG
template concept C = requires (T a) { a.f(0); };
struct S { void f(auto) noexcept(); };
static_assert(C);
gcc-trunk:
:2:17: internal compiler error: in tsubst_copy, at cp/pt.c:17247
2 | struct S { void f(auto) noexcept(); };
| ^
gcc-10:
:2:17: internal compiler error: in tree_code_size, at tree.c:910
2 | struct S { void f(auto) noexcept(); };
|
[Bug libstdc++/96416] to_address() is broken by static_assert in pointer_traits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416 --- Comment #16 from Glen Joseph Fernandes --- > should a wording defect be raised against std::to_address(Ptr), to state that > pointer_traits being well-formed is actually a prerequisite? That's not an omission in the specification of to_address. The function is intended for pointers, and specified in terms of checking for a pointer_traits member, and this means pointer_traits must be well-formed. Adding an additional text to the specification saying this explicitly is unlikely to help anyone. The real change that users of iterators[1] would want is to make pointer_traits SFINAE friendly. [1] Users of pointers don't care much, since all the pointer types people are using with to_address(p) already have a well-formed pointer_traits.
[Bug c++/99805] New: filesystem::path::parent_path got a wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805
Bug ID: 99805
Summary: filesystem::path::parent_path got a wrong path
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: drfeng08 at gmail dot com
Target Milestone: ---
[work@centos7 ~]$ uname -a
Linux centos7 3.10.0-1160.11.1.el7.x86_64 #1 SMP Fri Dec 18 16:34:56 UTC 2020
x86_64 x86_64 x86_64 GNU/Linux
[work@centos7 ~]$ g++ --version
g++ (GCC) 10.2.1 20200804 (Red Hat 10.2.1-2)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[work@centos7 ~]$ which g++
/opt/rh/devtoolset-10/root/usr/bin/g++
[work@centos7 ~]$ cat ans8.cpp
#include
#include
#include
std::string get_path() {
static std::string path = "/ssd1/opt/stdpain/workspace";
return path;
}
int main() {
std::filesystem::path path(get_path());
std::filesystem::path path2 = path.parent_path();
std::cout << path << std::endl;
std::cout << path2 << std::endl;
}
output:
/ssd1/opt/stdpain/workspace
/ssd1/opt/stdpain/workspace
expect:
/ssd1/opt/stdpain/workspace
/ssd1/opt/stdpain/
[PATCH] libstdc++: Reimplement range adaptors [PR99433]
This rewrites our range adaptor implementation for more comprehensible error messages, improved SFINAE behavior and conformance to P2281. The diagnostic improvements mostly comes from using appropriately named functors instead of lambdas in the generic implementation of partial application and composition of range adaptors, and in the definition of each of the standard range adaptors. This makes their pretty printed types of much more comprehensible. The improved SFINAE behavior comes from constraining the range adaptors' member functions appropriately. This change fixes PR99433, and was also necessary in order to implement the wording changes of P2281. Finally, P2281 clarified that partial application and composition of range adaptors behaves like a perfect forwarding call wrapper. This patch implements this, except that we don't bother adding overloads for forwarding captured state entities as non-const lvalues, since it seems we only really need to handle the const lvalue and non-const rvalue cases. Such overloads can be easily added if they turn out to be needed. Tested on x86_64-pc-linux-gnu, does this look OK for trunk? libstdc++-v3/ChangeLog: PR libstdc++/99433 * include/std/ranges (views::__adaptor): Remove this namespace, moving everything within into the parent namespace. (__maybe_refwrap): Remove. (_detail::__adaptor_invocable): New concept. (_detail::__adaptor_partial_app_viable): New concept. (_RangeAdaptor): Rename template parameter _Callable to _Impl. Remove the now unnecessary deduction guide. (_RangeAdaptor::_M_callable): Remove data member. (_RangeAdaptor::_RangeAdaptor): Remove constructors. (_RangeAdaptor::operator()): Rewrite (_RangeAdaptor::_S_arity): Define. (_RangeAdaptor::_Partial): New class template. (__detail::__pipe_invocable): New concept. (_Pipe): New class template. (_RangeAdaptorClosure): Rename template parameter _Callable to _Callable to _Impl. Don't derive from _RangeAdaptor. New data member _M_impl. Add a defaulted default constructor. Add an explicit constructor taking an _Impl object. Remove the now unnecessary deduction guide. (_RangeAdaptorClosure::operator()): Reimplement. (_RangeAdaptorClosure::operator|): Reimplement. (__detail::__can_ref_view): New concept. (__detail::__can_subrange): New concept. (all): Replace the lambda here with ... (_All): ... this functor. Add appropriate constraints. Remove redundant viewable_range constraint. (__detail::__can_filter_view): New concept. (filter, _Filter): Like with all/_All. (__detail::__can_transform): New concept. (transform, _Transform): Like with all/_All. (__detail::__can_take_view): New concept. (take, _Take): Like with all/_All. (__detail::__can_take_while_view): New concept. (take_while, _TakeWhile): Like with all/_All. (__detail::__can_drop_view): New concept. (drop, _Drop): Like with all/_All. (__detail::__can_drop_while_view): New concept. (drop_while, _DropWhile): Like with all/_All. (__detail::__can_join_view): New concept. (join, _Join): Like with all/_All. (__detail::__can_split_view): New concept. (split, _Split): Like with all/_All. Rename template parameter _Fp to _Pattern). (__detail::__already_common): New concept. (__detail::__can_common_view): New concept. (common, _Common): Like with all/_All. (__detail::__can_reverse_view): New concept. (reverse, _Reverse): Like with all/_All. (__detail::__can_elements_view): New concept. (elements, _Elements): Like with all/_All. (keys, values): Adjust. * testsuite/std/ranges/adaptors/99433.cc: New test. * testsuite/std/ranges/adaptors/all.cc (test05): New test. * testsuite/std/ranges/adaptors/common.cc (test03): New test. * testsuite/std/ranges/adaptors/drop.cc (test09): New test. * testsuite/std/ranges/adaptors/drop_while.cc (test04): New test. * testsuite/std/ranges/adaptors/elements.cc (test04): New test. * testsuite/std/ranges/adaptors/filter.cc (test06): New test. * testsuite/std/ranges/adaptors/join.cc (test09): New test. * testsuite/std/ranges/adaptors/p2281.cc: New test. * testsuite/std/ranges/adaptors/reverse.cc (test07): New test. * testsuite/std/ranges/adaptors/split.cc (test01, test04): Adjust. (test09): New test. * testsuite/std/ranges/adaptors/split_neg.cc (test01): Adjust expected error message. (test02): Likewise. Extend test. * testsuite/std/ranges/adaptors/take.cc (test06): New test. * testsuite/std/ranges/adaptors/take_while.cc (test05): New test. *
Re: Remove RMS from the GCC Steering Committee
This is quite similar to James Madison and John Jay, two of the founding father of the United States Bill of Rights, which enshrined guarantees of personal freedoms and rights within the American Constitution. Many companies rely on their founder to be the chief salesperson. This is difficult as the company grows, but the founder is uniquely suited to convince others about free software in this case. Certainly not Nathan Sidwell, Deb Nicholson, or Neil McGovern. Or the others. If people think that the Jeffrey Epstein problems are going to be resolved by going after Stallman, they are highly misguided. Money and power often buy what they shouldn't. > Sent: Monday, March 29, 2021 at 11:21 AM > From: "Soul Studios" > To: "Mark Wielaard" , "GCC Development" > Cc: "Nathan Sidwell" > Subject: Re: Remove RMS from the GCC Steering Committee > > > We are not talking about some single recent incident, but about > > decades of problematic behavior. At the last face-to-face GNU Tools > > Cauldron, everybody I talked to about it had some story about being > > harassed by RMS, had witnessed such harassment or heard from or knew > > someone who had been. > > I think I will leave this discussion up to those who have more > familiarity with the guy than I do. Have worked with Stallman and never experienced any stories that are being perpetuated in discussions. > There's no doubt that some of the > stuff Stallman has written creeps me the hell out, and I think it was > more the tone of the OP I objected to. Yes, there are things that people can disagree with him about personal views. Which crimes has he committed exactly? And under which jurisdiction? I have to work with a lot of people that I could not particularly like on a personal level. I cannot see how people expect that others stay out of politics because they have some acrimony against them! > Giving twitter as reference points doesn't really help matters, but it > appears as though the problems are more offline than on. >
Re: Remove RMS from the GCC Steering Committee
We are not talking about some single recent incident, but about decades of problematic behavior. At the last face-to-face GNU Tools Cauldron, everybody I talked to about it had some story about being harassed by RMS, had witnessed such harassment or heard from or knew someone who had been. I think I will leave this discussion up to those who have more familiarity with the guy than I do. There's no doubt that some of the stuff Stallman has written creeps me the hell out, and I think it was more the tone of the OP I objected to. Giving twitter as reference points doesn't really help matters, but it appears as though the problems are more offline than on.
gcc-11-20210328 is now available
Snapshot gcc-11-20210328 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20210328/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch master revision 499fa254ae8c9752d8c2cf3130b13ffddfd83546 You'll find: gcc-11-20210328.tar.xz Complete GCC SHA256=ec27f7e5f259ad693996fe54742621b89e5abf82e4f97b5eb35c3bff2b163537 SHA1=518f798a97dbfc03d4a32146c85a0cf211f1c525 Diffs from 11-20210321 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[PATCH] AIX TLS DWARF symbols
GCC currently emits TLS relocation decorations on symbols in DWARF sections.
Recent changes to the AIX linker cause it to reject such symbols.
This patch removes the decorations (@ie, @le, @m) and emit only the
qualified symbol name.
Bootstrapped on powerpc-ibm-aix7.3.2.0.
* config/rs6000/rs6000.c (rs6000_output_dwarf_dtprel): Do not add
XCOFF TLS reloc decorations.
diff --git a/gcc/config/rs6000/rs6000.c b/gcc/config/rs6000/rs6000.c
index fd2b0b5280c..6a8943d0286 100644
--- a/gcc/config/rs6000/rs6000.c
+++ b/gcc/config/rs6000/rs6000.c
@@ -9027,26 +9027,6 @@ rs6000_output_dwarf_dtprel (FILE *file, int size, rtx x)
output_addr_const (file, x);
if (TARGET_ELF)
fputs ("@dtprel+0x8000", file);
- else if (TARGET_XCOFF && SYMBOL_REF_P (x))
-{
- switch (SYMBOL_REF_TLS_MODEL (x))
- {
- case 0:
- break;
- case TLS_MODEL_LOCAL_EXEC:
- fputs ("@le", file);
- break;
- case TLS_MODEL_INITIAL_EXEC:
- fputs ("@ie", file);
- break;
- case TLS_MODEL_GLOBAL_DYNAMIC:
- case TLS_MODEL_LOCAL_DYNAMIC:
- fputs ("@m", file);
- break;
- default:
- gcc_unreachable ();
- }
-}
}
/* Return true if X is a symbol that refers to real (rather than emulated)
[committed] doc: Update link to "Memory Model" paper
The original link redirected, alas the new location gives a 404 "Not
Found". Luckily I found what looks like a more stable location.
Pushed.
Gerald
commit d15db0c5f5d81e9057df07c9568ee81873860a44
Author: Gerald Pfeifer
Date: Sun Mar 28 23:34:35 2021 +0200
doc: Update link to "Memory Model" paper
gcc/ChangeLog:
* doc/analyzer.texi (Analyzer Internals): Update link to
"A Memory Model for Static Analysis of C Programs".
diff --git a/gcc/doc/analyzer.texi b/gcc/doc/analyzer.texi
index 3f7bcf3c115..26808ff5d22 100644
--- a/gcc/doc/analyzer.texi
+++ b/gcc/doc/analyzer.texi
@@ -245,7 +245,7 @@ Merging can be disabled via
@option{-fno-analyzer-state-merge}.
Part of the state stored at a @code{exploded_node} is a @code{region_model}.
This is an implementation of the region-based ternary model described in
-@url{http://lcs.ios.ac.cn/~xzx/memmodel.pdf,
+@url{https://www.researchgate.net/publication/221430855_A_Memory_Model_for_Static_Analysis_of_C_Programs,
"A Memory Model for Static Analysis of C Programs"}
(Zhongxing Xu, Ted Kremenek, and Jian Zhang).
[committed] wwwdocs: Update link to ECMA-335
Pushed. Gerald The link to ECMA-335 received a 301 (Moved Permanently) which we are thus following. On the way remove a duplicate link on this page. --- htdocs/projects/cli.html | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/htdocs/projects/cli.html b/htdocs/projects/cli.html index f6258fc1..3b3eb2ff 100644 --- a/htdocs/projects/cli.html +++ b/htdocs/projects/cli.html @@ -86,8 +86,7 @@ Andrea Ornstein and Erven Rohou. CLI is a framework that defines a platform independent format for executables and a run-time environment for the execution of applications. The framework has been been standardized by the European Computer -Manufacturers Association -(http://www.ecma-international.org/publications/standards/Ecma-335.htm;>ECMA-335) +Manufacturers Association [1] wwwdocs: and by the International Organization for Standardization (ISO/IEC 23271:2006). CLI executables are encoded in the Common Intermediate Language (CIL), a stack-based bytecode language. @@ -461,7 +460,7 @@ allowing the user to provide a native implementation if necessary. [1] wwwdocs: -ECMA, http://www.ecma-international.org/publications/standards/Ecma-335.htm;> +ECMA, https://www.ecma-international.org/publications-and-standards/standards/ecma-335/;> Common Language Infrastructure (CLI), 4th edition, June 2006. -- 2.30.2
[committed] wwwdocs: Update "creating commit with multiple authors" link
Pushed. Gerald --- htdocs/codingconventions.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html index 7577528d..21cc95de 100644 --- a/htdocs/codingconventions.html +++ b/htdocs/codingconventions.html @@ -146,7 +146,7 @@ a large batch of changes. changelog_file_comment - line that follows a changelog_file with description of changes in the file; must start with \t co_authored_by - https://docs.github.com/en/free-pro-team@latest/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors;>GitHub format + href="https://docs.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors;>GitHub format for a Co-Authored-By -- 2.30.2
[committed] wwwdocs: Update reference to rawhide-20090126 result
Pushed.
Gerald
https://www.redhat.com/archives/fedora-devel-list is now
https://listman.redhat.com/archives/fedora-devel-list .
---
htdocs/gcc-4.4/porting_to.html | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/htdocs/gcc-4.4/porting_to.html b/htdocs/gcc-4.4/porting_to.html
index b553e5cc..19c2cee1 100644
--- a/htdocs/gcc-4.4/porting_to.html
+++ b/htdocs/gcc-4.4/porting_to.html
@@ -239,7 +239,7 @@ C(): a(B()) { bar(a); }
Links
-Jakub Jelinek, https://www.redhat.com/archives/fedora-devel-list/2009-February/msg00180.html;>Results
of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9
+Jakub Jelinek, https://listman.redhat.com/archives/fedora-devel-list/2009-February/msg00180.html;>Results
of a test mass rebuild of rawhide-20090126 with gcc-4.4.0-0.9
--
2.30.2
[committed] wwwdocs: Fix the spelling of "run time" as a noun.
Pushed. Gerald --- htdocs/gcc-8/changes.html | 2 +- htdocs/gcc-9/changes.html | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/htdocs/gcc-8/changes.html b/htdocs/gcc-8/changes.html index 638782e8..d68e5146 100644 --- a/htdocs/gcc-8/changes.html +++ b/htdocs/gcc-8/changes.html @@ -1406,7 +1406,7 @@ are not listed here). deployment of the Large System Extensions (LSE) on GNU/Linux systems built with a baseline architecture targeting Armv8-A. When the option is specified code is emitted to detect the presence of LSE instructions at - runtime and use them for standard atomic operations. + run time and use them for standard atomic operations. For more information please refer to the documentation. diff --git a/htdocs/gcc-9/changes.html b/htdocs/gcc-9/changes.html index 8b827386..cbbf9299 100644 --- a/htdocs/gcc-9/changes.html +++ b/htdocs/gcc-9/changes.html @@ -1143,7 +1143,7 @@ are not listed here). deployment of the Large System Extensions (LSE) on GNU/Linux systems built with a baseline architecture targeting Armv8-A. When the option is specified code is emitted to detect the presence of LSE instructions at - runtime and use them for standard atomic operations. + run time and use them for standard atomic operations. For more information please refer to the documentation. GCC now supports the Fujitsu A64FX. The associated -mcpu -- 2.30.2
Re: [PATCH] Fix _GLIBCXX_DEBUG container allocator aware move constructors
On 27/03/21 10:07 pm, Jonathan Wakely wrote:
On 26/03/21 21:41 +0100, François Dumont via Libstdc++ wrote:
I review the allocator aware move constructors of _GLIBCXX_DEBUG
containers.
I think the recently added __gnu_debug basic_string one is also
missing the rvalue reference, no ?
You mean is_nothrow_constructible instead
of is_nothrow_constructible?
No, it's not missing. They mean the exact same thing: Base is an
rvalue, Base&& is an rvalue, and Base& is an lvalue. Writing Base&&
instead of Base is just extra noise that adds no value.
Ok, noted.
libstdc++: _GLIBCXX_DEBUG Fix allocator aware move constructor
The correct term is "allocator-extended move constructor". And is it
really a "fix"? The standard doesn't require a noexcept-specifier on
those constructors, so what we have now is not incorrect, just
suboptimal.
For the debug list it is a fix because we were missing the _Safe base
class call. For the vector it is also a fix even if a minor one.
Fix several allocator aware move construtor in _GLIBCXX_DEBUG
containers.
libstdc++-v3/ChangeLog:
* include/debug/forward_list
(forward_list(forward_list&&, const allocator_type&)):
Add noexcept qualification.
* include/debug/list (list(list&&, const
allocator_type&)): Likewise and add
call to safe container allocator aware move constructor.
* include/debug/string (basic_string(basic_string&&,
const _Allocator&)):
Check base type allocator aware more constructor.
* include/debug/vector (vector(vector&&, const
allocator_type&)):
Fix noexcept qualification.
*
testsuite/23_containers/forward_list/cons/noexcept_move_construct.cc:
Add allocator aware move constructor noexceot
qualification check.
*
testsuite/23_containers/list/cons/noexcept_move_construct.cc: Likewise.
Tested under linux x86_64.
Ok to commit ?
OK, thanks.
I eventually committed the attached patch.
If you are still interested by _GLIBCXX_DEBUG fixes there is still this one:
https://gcc.gnu.org/pipermail/libstdc++/2021-March/052176.html
Thanks,
François
diff --git a/libstdc++-v3/include/debug/forward_list b/libstdc++-v3/include/debug/forward_list
index db46705cc71..16f0531dce7 100644
--- a/libstdc++-v3/include/debug/forward_list
+++ b/libstdc++-v3/include/debug/forward_list
@@ -239,8 +239,11 @@ namespace __debug
{ }
forward_list(forward_list&& __list, const allocator_type& __al)
- : _Safe(std::move(__list._M_safe()), __al),
- _Base(std::move(__list._M_base()), __al)
+ noexcept(
+ std::is_nothrow_constructible<_Base,
+ _Base, const allocator_type&>::value )
+ : _Safe(std::move(__list._M_safe()), __al),
+ _Base(std::move(__list._M_base()), __al)
{ }
explicit
diff --git a/libstdc++-v3/include/debug/list b/libstdc++-v3/include/debug/list
index 06938899253..01fe43fc7df 100644
--- a/libstdc++-v3/include/debug/list
+++ b/libstdc++-v3/include/debug/list
@@ -119,7 +119,11 @@ namespace __debug
: _Base(__x, __a) { }
list(list&& __x, const allocator_type& __a)
- : _Base(std::move(__x), __a) { }
+ noexcept(
+ std::is_nothrow_constructible<_Base,
+ _Base, const allocator_type&>::value )
+ : _Safe(std::move(__x._M_safe()), __a),
+ _Base(std::move(__x._M_base()), __a) { }
#endif
explicit
diff --git a/libstdc++-v3/include/debug/vector b/libstdc++-v3/include/debug/vector
index df179cbbfea..987bba17c2b 100644
--- a/libstdc++-v3/include/debug/vector
+++ b/libstdc++-v3/include/debug/vector
@@ -217,8 +217,9 @@ namespace __debug
: _Base(__x, __a) { }
vector(vector&& __x, const allocator_type& __a)
- noexcept(noexcept(
- _Base(std::declval<_Base&&>()), std::declval()))
+ noexcept(
+ std::is_nothrow_constructible<_Base,
+ _Base, const allocator_type&>::value )
: _Safe(std::move(__x._M_safe()), __a),
_Base(std::move(__x._M_base()), __a),
_Safe_vector(std::move(__x)) { }
diff --git a/libstdc++-v3/testsuite/23_containers/forward_list/cons/noexcept_move_construct.cc b/libstdc++-v3/testsuite/23_containers/forward_list/cons/noexcept_move_construct.cc
index 96f3876e4f6..0eb5a5cdbba 100644
--- a/libstdc++-v3/testsuite/23_containers/forward_list/cons/noexcept_move_construct.cc
+++ b/libstdc++-v3/testsuite/23_containers/forward_list/cons/noexcept_move_construct.cc
@@ -23,4 +23,8 @@
typedef std::forward_list fltype;
-static_assert(std::is_nothrow_move_constructible::value, "Error");
+static_assert( std::is_nothrow_move_constructible::value,
+ "noexcept move constructor" );
+static_assert( std::is_nothrow_constructible::value,
+ "noexcept move constructor with allocator" );
diff --git a/libstdc++-v3/testsuite/23_containers/list/cons/noexcept_move_construct.cc b/libstdc++-v3/testsuite/23_containers/list/cons/noexcept_move_construct.cc
index 5a2de10cf09..858a0d76333 100644
---
Re: Remove RMS from the GCC Steering Committee
You showed your colours with your first few posts, don't try to pretend you are anything but a zealot and a nasty troll. Come back when you've contributed more to the GNU project than attacking those you see as its enemies. The people you are attacking have done more for Free Software than you ever will. On Sun, 28 Mar 2021, 19:43 Christopher Dimech via Gcc, wrote: > > > - > Christopher Dimech > General Administrator - Naiad Informatics - GNU Project (Geocomputation) > - Geophysical Simulation > - Geological Subsurface Mapping > - Disaster Preparedness and Mitigation > - Natural Resource Exploration and Production > - Free Software Advocacy > > > > Sent: Monday, March 29, 2021 at 6:13 AM > > From: "Mark Wielaard" > > To: "JeanHeyd Meneide" > > Cc: "GCC Development" , "Nathan Sidwell" < > nat...@acm.org> > > Subject: Re: Remove RMS from the GCC Steering Committee > > > > Hi, > > > > On Sun, Mar 28, 2021 at 10:33:15AM -0400, JeanHeyd Meneide wrote: > > > This is unacceptable. The only reason I was told - as early as > > > yesterday, by Free Software advocates, to my socially distanced face - > > > that Stallman was still here is because he was powerless and had no > > > effect on the project. That it was run by the caring, > > > community-oriented stewardship of the "real volunteers" doing the > > > "actual work". > > > > I do not think those people were lying or trying to deceive you. This > > is what we hope the actual situation is. But... > > > > > Further digging into Stallman's own words and behavior also > > > reveals that he continues to flex this influence throughout the > > > project (and in other places), showing up (generally unsolicited) into > > > places to do this kind of gross and extreme harassment and engaging in > > > canceling our own hardworking contributors that actually write code > > > and do work. This is not a person who is just here for "historical > > > reasons" and who has "no power"; this is an active, perpetual threat > > > to hardworking and contributing members of the Free Software movement. > > > > He does indeed show up randomly claiming authority even if the GNU > > community has told him no. And it is important to say upfront he has > > no authority and that his attempts to cancel the work of hardworking > > GNU contributors is unwelcome. IMHO for the GCC community this means > > to be explicit he doesn't have any authority and he shouldn't be on > > the GCC steering committee. > > > > > I will never, ever contribute another line of code, another > > > proposal implementation[6], another optimization, or another > > > new/better library implementation to GCC and all of its affiliated > > > projects, including the compilers, glibc, libstdc++, the potential > > > upcoming Rust implementation, and more until this problem is not > > > "address", but *fixed*. If you never fix it, I will never return. > > > > > > Wish you and your community all the best in sorting this out, > > > > Thanks. I do hope we can finally fix this and welcome you back. > > The attacks against Richard Stallman do not stem from any of his actual > statements. Instead, his statements have been given a subversive context > that fits into your narrative that wishes to smear him, followed a demand > that your interpretation of his words be considered canon — even though > evidence to the contrary summarily disproves your position. > > Stallman’s work and advocacy speaks for itself; and this holds true for > anyone > in the field of technology, where a person’s work is judged by a system of > meritocracy. > > Linus Torvalds was also famously criticized by those who took offense to > his > no-nonsense attitude and firm speech. Did the quality of the Linux kernel > suffer? Was being unoffensive a requirement as maintainer? The answer is > NO. > > Stallman has never been accused of doing physical harm to anyone, and > therefore > any assumptions about the harmful nature or context of his words should > not be > conflated with his professional capacity to hold a leadership role within > the FSF, > the very organization that he founded. > > > > > Cheers, > > > > Mark > > >
[Bug target/96770] -mpure-code produces suboptimal code for relocations with small offset for thumb-1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96770 --- Comment #4 from CVS Commits --- The master branch has been updated by Christophe Lyon : https://gcc.gnu.org/g:46720db72cadfb85501e102d94e06683300a2327 commit r11-7881-g46720db72cadfb85501e102d94e06683300a2327 Author: Christophe Lyon Date: Sun Mar 28 18:59:06 2021 + testsuite/arm: Improve scan-assembler in pr96770.c I'm seeing random scan-assembler-times failures in pr96770.c when LTO is used. I suspect this is because the \\+4 string matches the LTO sections, sometimes. This small patch avoids the issue, by matching arr\\+4 instead of \\+4. 2021-03-28 Christophe Lyon gcc/testsuite/ PR target/96770 * gcc.target/arm/pure-code/pr96770.c: Improve scan-assembler-times.
Re: Remove RMS from the GCC Steering Committee
On 3/28/21 8:20 PM, Alexandre Oliva wrote: Thanks for clarifying your understanding of Nathan's goal. I may indeed have misread and mistaken Nathan's goal and means. I thought the goal was to improve the GCC community by addressing the gender imbalance, and that the means (misguided, IMHO) was to distance ourselves from RMS. There's only one point of departure; you chose to interpret RMS' removal from the steering committee to be the solution while I (and others) have pointed out that it is a notable step in that direction. Your assertiveness came across to me as a correction of my mistake, but I didn't see any reason to prefer your understanding over mine, until Nathan posted today's followup. My reading of every gcc contributor that has participated in this discussion seems to reinforce my understanding over yours. Not one of them has conveyed IMO that RMS' removal from the board will magically solve gender or diversity issues with the community. Now it looks like you were right, but I still find that a little hard to believe. Are you really sure about your understanding? Do you know for a fact that Nathan agrees with your understanding? Do you know with certainty of anyone else who shares that understanding with you and him? In my opinion there is nothing to indicate from any of the contributors' statements that they see RMS' removal from the steering committee as a final solution to D issues in the GNU community. I'm happy to be corrected by others if they think I've misinterpreted their comments and if they indeed think that RMS' removal from the steering committee will solve all diversity issues. Siddhesh
Re: Remove RMS from the GCC Steering Committee
- Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > Sent: Monday, March 29, 2021 at 6:13 AM > From: "Mark Wielaard" > To: "JeanHeyd Meneide" > Cc: "GCC Development" , "Nathan Sidwell" > Subject: Re: Remove RMS from the GCC Steering Committee > > Hi, > > On Sun, Mar 28, 2021 at 10:33:15AM -0400, JeanHeyd Meneide wrote: > > This is unacceptable. The only reason I was told - as early as > > yesterday, by Free Software advocates, to my socially distanced face - > > that Stallman was still here is because he was powerless and had no > > effect on the project. That it was run by the caring, > > community-oriented stewardship of the "real volunteers" doing the > > "actual work". > > I do not think those people were lying or trying to deceive you. This > is what we hope the actual situation is. But... > > > Further digging into Stallman's own words and behavior also > > reveals that he continues to flex this influence throughout the > > project (and in other places), showing up (generally unsolicited) into > > places to do this kind of gross and extreme harassment and engaging in > > canceling our own hardworking contributors that actually write code > > and do work. This is not a person who is just here for "historical > > reasons" and who has "no power"; this is an active, perpetual threat > > to hardworking and contributing members of the Free Software movement. > > He does indeed show up randomly claiming authority even if the GNU > community has told him no. And it is important to say upfront he has > no authority and that his attempts to cancel the work of hardworking > GNU contributors is unwelcome. IMHO for the GCC community this means > to be explicit he doesn't have any authority and he shouldn't be on > the GCC steering committee. > > > I will never, ever contribute another line of code, another > > proposal implementation[6], another optimization, or another > > new/better library implementation to GCC and all of its affiliated > > projects, including the compilers, glibc, libstdc++, the potential > > upcoming Rust implementation, and more until this problem is not > > "address", but *fixed*. If you never fix it, I will never return. > > > > Wish you and your community all the best in sorting this out, > > Thanks. I do hope we can finally fix this and welcome you back. The attacks against Richard Stallman do not stem from any of his actual statements. Instead, his statements have been given a subversive context that fits into your narrative that wishes to smear him, followed a demand that your interpretation of his words be considered canon — even though evidence to the contrary summarily disproves your position. Stallman’s work and advocacy speaks for itself; and this holds true for anyone in the field of technology, where a person’s work is judged by a system of meritocracy. Linus Torvalds was also famously criticized by those who took offense to his no-nonsense attitude and firm speech. Did the quality of the Linux kernel suffer? Was being unoffensive a requirement as maintainer? The answer is NO. Stallman has never been accused of doing physical harm to anyone, and therefore any assumptions about the harmful nature or context of his words should not be conflated with his professional capacity to hold a leadership role within the FSF, the very organization that he founded. > Cheers, > > Mark >
[Bug fortran/99602] [11 regression] runtime error: pointer actual argument not associated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99602 --- Comment #35 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:297363774e6a5dca2f46a85ab086f1d9e59431ac commit r11-7880-g297363774e6a5dca2f46a85ab086f1d9e59431ac Author: Paul Thomas Date: Sun Mar 28 16:48:27 2021 +0100 Fortran: Fix problem with runtime pointer check [PR99602]. 2021-03-28 Paul Thomas gcc/fortran/ChangeLog PR fortran/99602 * trans-expr.c (gfc_conv_procedure_call): Use the _data attrs for class expressions and detect proc pointer evaluations by the non-null actual argument list. gcc/testsuite/ChangeLog PR fortran/99602 * gfortran.dg/pr99602.f90: New test. * gfortran.dg/pr99602a.f90: New test. * gfortran.dg/pr99602b.f90: New test. * gfortran.dg/pr99602c.f90: New test. * gfortran.dg/pr99602d.f90: New test.
[Bug c++/99804] New: cannot convert bit field enum to its own type in a template member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99804
Bug ID: 99804
Summary: cannot convert bit field enum to its own type in a
template member function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: phonyuc at outlook dot com
Target Milestone: ---
struct S {
enum E { A, B } e : 1; // line 2
void f1(decltype(e)) {} // line 3
template void f2() { f1(e); } // line 4
};
// -- end-of-code --
gcc (version 10.2 and earlier) won't compile this structure.
Compilation will success if any one of the following changes is made:
1. (in line 2) the member is not in enumeration type
2. (in line 2) the member is not in bit field
3. (in line 2) the width is the same as the underlying type
4. (in line 3) f1 is not a member function of S
5. (in line 4) f2 is not a member function of S
6. (in line 4) f2 is not a template function
7. (in line 4) call with a static enum value: f1(E::A)
8. (in line 4) cast the variable into its own type: f1((decltype(e))e)
The context looks similar to bug 92859 but the behaviour is different.
// -- compiler output --
$ g++ -c bit-enum-template.cc
a.cc: In member function 'void S::f2()':
a.cc:4:40: error: cannot convert 'unsigned char:1' to 'S::E'
4 | template void f2() { f1(e); } // line 4
|^
||
|unsigned char:1
a.cc:3:13: note: initializing argument 1 of 'void S::f1(S::E)'
3 | void f1(decltype(e)) {} // line 3
| ^~~~
Re: Remove RMS from the GCC Steering Committee
On Mar 28, 2021, Mark Wielaard wrote: > It shows we don't tolerate harassment in our project. It shows we will favor and engage in harassment against a certain demographic group, while pretending or believing it will somehow make for a welcoming atmosphere. > everybody I talked to about it had some story about being > harassed by RMS, had witnessed such harassment or heard from or knew > someone who had been. ... which, even if true, still requires quite a lot of twisting and forcing and breaking to make it fit the sexism narrative presented as the motivating factor. And this is the problem with most of the witchhunting in place. There are plenty of allegations circulating all over the Internet, and most of them fit either or both of two patterns: actual evidence twisted and forced to fit a false narrative, or repeated hearsay, most likely fabricated or exaggerated, without a traceable ultimate source. Which is not to say that there aren't exceptions, the first-hand narratives. Those invariably fit in either of two patterns: they look like smoking gun evidence of very wrongdoing, but they are disputed by other who were just as much there and are just as trustworthy, or they paint the known picture of person who has well-known flaws and is indeed frequently difficult to deal with, but those facts don't help construct the false boogeyman narrative. Of course conclusions may be different once one starts picking evidence that is favorable to make one's case, and disregarding that which opposes evidence. Most people would agree that this is not the way to go to find truth, be it for science or for justice. > he is against enforcing any anti-harassment policy some GNU > mailinglist is currently being used to organize a doxing campaign Doxing and harassment are not welcome, and that post has already been solved, with his support and before you brought it up, FWIW. Harassment has been tolerated before, which made this decision a little more difficult, because the target of an earlier and ongoing harassment campaign was someone in a position of power in the GNU project itself. My understanding is that there was a decision to not silence that discussion, although some moderators had engaged in suppression of dissenting positions to the (still) ongoing harassment. As anyone who studied history can predict, authoritarian positions tend to suppress or attempt to suppress dissent, while freedom-respecting ones endure it. If that was a trial run of the sort of leadership that was trying to replace Richard's, I'd much rather keep the devil we know. That alleged witch may have some warts indeed, but they're not quite as ugly as the prosecutors/judges/executioners's. > You link to a parody of a request of tens of Free Software foundation > projects and thousands of Free Software hackers If truth finding were a matter of headcount, we might still be forced to believe we're on a flat planet orbited by a star. But if we're to use that measuring stick, petitions calling for the FSF to keep Richard at the FSF board have been signed by more people, translated to more languages, despite there being more of them, and hosted on platforms that are less hostile to software freedom, and not being signed multiple times by the same few people on behalf of multiple organizations. > Sometimes satire is a way to deal with difficult problems, but I don't > think that is appropriate here How about this one instead? https://avilarenata.medium.com/stallman-d824724b0083 RMS’ principled stances cause an uncomfortable cognitive dissonance for them. They would rather kill a sacrificial Gnu than admit their own shortcomings. It is significant that the letter demanding his resignation must be signed using Microsoft’s Github platform, and that many organizations taking position are openly accepting money from Google and other predatory companies. Or this one? https://www.wetheweb.org/post/cancel-we-the-web The paradox of Stallman is that while his pointedness and stubbornness leads many to dismiss him as a jerk, his stubbornness and confrontations are actually rooted in his life-long obsession with morality. Though you may disagree, there is ample reason to believe he has come to hold his views from a concerted, rigorous, good-faith effort to be a voice for good in the world. “Stallman… is a hard man to like. He is driven, often impatient. His anger can flare at friend as easily as foe. He is uncompromising and persistent; patient in both.” Lawrence Lessig, Harvard Law Professor, democracy activist “Even if I strongly disagree with a position or an idea, an expression of an idea, advocacy of an idea, and even if the vast majority of the public disagrees with the idea and finds it offensive, that is not a justification for suppressing the idea. And it’s not a justification for taking away the equal rights of the person who espouses that idea including the right to continue
Re: Remove RMS from the GCC Steering Committee
Hi, On Sun, Mar 28, 2021 at 10:33:15AM -0400, JeanHeyd Meneide wrote: > This is unacceptable. The only reason I was told - as early as > yesterday, by Free Software advocates, to my socially distanced face - > that Stallman was still here is because he was powerless and had no > effect on the project. That it was run by the caring, > community-oriented stewardship of the "real volunteers" doing the > "actual work". I do not think those people were lying or trying to deceive you. This is what we hope the actual situation is. But... > Further digging into Stallman's own words and behavior also > reveals that he continues to flex this influence throughout the > project (and in other places), showing up (generally unsolicited) into > places to do this kind of gross and extreme harassment and engaging in > canceling our own hardworking contributors that actually write code > and do work. This is not a person who is just here for "historical > reasons" and who has "no power"; this is an active, perpetual threat > to hardworking and contributing members of the Free Software movement. He does indeed show up randomly claiming authority even if the GNU community has told him no. And it is important to say upfront he has no authority and that his attempts to cancel the work of hardworking GNU contributors is unwelcome. IMHO for the GCC community this means to be explicit he doesn't have any authority and he shouldn't be on the GCC steering committee. > I will never, ever contribute another line of code, another > proposal implementation[6], another optimization, or another > new/better library implementation to GCC and all of its affiliated > projects, including the compilers, glibc, libstdc++, the potential > upcoming Rust implementation, and more until this problem is not > "address", but *fixed*. If you never fix it, I will never return. > > Wish you and your community all the best in sorting this out, Thanks. I do hope we can finally fix this and welcome you back. Cheers, Mark
Re: Remove RMS from the GCC Steering Committee
The methods used to put a leash on Torvalds and Assange and the methods used to put one on Stallman are too similar to ignore. It hasn’t stopped there either, it is now being wielded as a way to yoke all developers of mainstream software (whether mainstream and non-free, or mainstream and under a free license) into indentured servants of projects that have been taken over by corporate donors who then force even original authors to do things the way the monopoly wanted, or get out. - Christopher Dimech General Administrator - Naiad Informatics - GNU Project (Geocomputation) - Geophysical Simulation - Geological Subsurface Mapping - Disaster Preparedness and Mitigation - Natural Resource Exploration and Production - Free Software Advocacy > Sent: Monday, March 29, 2021 at 12:47 AM > From: "Mark Wielaard" > To: "GCC Development" > Cc: "Nathan Sidwell" > Subject: Re: Remove RMS from the GCC Steering Committee > > Alexandre, > > Making our community more welcoming is indeed a process. And some > steps will just be symbolic. But I don't believe removing RMS from > (perceived) leadership positions in the GNU project and from the FSF > is just symbolic. And even for a symbolic step it is a powerful > one. It shows we don't tolerate harassment in our project. And I do > hope it doesn't end with that step. We also have to decide whether we > still want to be associated with the FSF. Hopefully the FSF takes > their responsibility and replaces the whole board to show we can start > with a clean slate. > > One issue is that as long as GCC is associated with RMS and the FSF > others who could help us won't because the FSF is that toxic now: > https://www.outreachy.org/blog/2021-03-23/fsf-participation-barred/ > And they are far from the only Free Software project who has said > something similar. > > We are not talking about some single recent incident, but about > decades of problematic behavior. At the last face-to-face GNU Tools > Cauldron, everybody I talked to about it had some story about being > harassed by RMS, had witnessed such harassment or heard from or knew > someone who had been. > > For years people have tried to help him see how his actions and words > might hurt others, even if they are completely logically correct to > himself. And obviously that is sometimes hard, nobody is perfect, but > hopefully we get a little better every time. But this never happened. > And it really needs to stop. > > RMS actively undermines those who try to make our community a little > bit more welcoming. Violating anti-harassment policies of > conferences. Even those from the FSF by claiming to be above those > policies because of his leadership position or using his position to > tell staff they cannot enforce such policies against others. Because > he is against enforcing any anti-harassment policy some GNU > mailinglist is currently being used to organize a doxing campaign > (publishing photos, address and calls to report to the local police > station to get her house raided and arrested) for simply saying the > same things we are discussing here now. > > I witnessed something similar recently when we had setup the > mailinglist to discuss improving governance of the GNU project. When a > female GNU (GCC) volunteer spoke up she got attacked and harassed. We > told the harassers that was totally unacceptable and blocked them from > sending more emails to the list. RMS arranged for those people to get > unblocked to continue their hate campaign on the public GNU list so > they could "defend him and the GNU project". That was followed by a > torrent of hate to the list making any discussion impossible and > making women feel like they were specifically targeted. He still > hasn't learned that his words and actions are dog whistles for > misogynists, transphobics and racists. This really has to stop. > > You link to a parody of a request of tens of Free Software foundation > projects and thousands of Free Software hackers who are calling for > the removal of the entire Board of the Free Software Foundation and > for Richard M. Stallman to be removed from all leadership positions, > including the GNU Project. For similar reasons that people here are > now calling for RMS to be removed from the GCC steering committee. > > The real letter is here: https://rms-open-letter.github.io/ > > Sometimes satire is a way to deal with difficult problems, but I don't > think that is appropriate here and I hope people take these issues > seriously, because I think they are. > > Mark >
Re: Remove RMS from the GCC Steering Committee
On 3/27/2021 2:49 PM, Martin Liška wrote: On 3/26/21 9:02 PM, Nathan Sidwell wrote: Dear members of the GCC Steering Committee (SC), I ask you to remove Richard Stallman (RMS) I do fully support Nathan's request. Speaking strictly for myself, not as a representative of the steering committee or Tachyum, I also fully support Nathan's request. jeff
Re: Remove RMS from the GCC Steering Committee
On Mar 28, 2021, Alexandre Oliva wrote: > Nathan posted today's followup. Erhm... Nathan, please accept my apologies. I misread someone else's message under the false impression it had come from you. -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Vim, Vi, Voltei pro Emacs -- GNUlius Caesar
[Bug c++/99803] New: internal compiler error: in make_typename_type, at cp/decl.c:4057
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99803
Bug ID: 99803
Summary: internal compiler error: in make_typename_type, at
cp/decl.c:4057
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://godbolt.org/z/4Yfnfzdhe
struct A { A(auto); };
A(unsigned) -> A:: template A;
[Bug ada/99802] New: [11 regression] Assignment of aggregate done component-by-component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99802 Bug ID: 99802 Summary: [11 regression] Assignment of aggregate done component-by-component Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: simon at pushface dot org Target Milestone: --- Created attachment 50481 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50481=edit Demonstrator, with output assembler In arm-eabi-gcc version 11.0.1 20210303 (experimental) (GCC), assigning an aggregate to a memory-mapped register is performed by assigning the components of the aggregate one-by-one to the register rather than as a whole word. The same bug is present in the x86_64-apple-darwin compiler. In compiler releases up to & including 10, this was done using a whole-word assignment. with ATSAM3X8E; use ATSAM3X8E; with ATSAM3X8E.PMC; use ATSAM3X8E.PMC; procedure Clock is begin PMC_Periph.CKGR_MOR := (KEY => 16#37#, MOSCXTEN => 1, -- main crystal oscillator enable MOSCRCEN => 1, -- main on-chip rc osc. enable MOSCXTST => 8, -- startup time others => <>); end Clock; The register is a component of a record: type PMC_Peripheral is record ... CKGR_MOR : aliased CKGR_MOR_Register; pragma Volatile_Full_Access (CKGR_MOR); ... end record with Volatile; with object as so: PMC_Periph : aliased PMC_Peripheral with Import, Address => PMC_Base; and the write respects the Volatile_Full_Access *as it writes each component separately to the register*! This fails, in this case, because the PMC hardware requires each write to this register to be accompanied by a valid value of the KEY field. The attached aggregate_assignment.zip contains Ada source, and the 10.1.0 and 11.0.1 versions of the arm-eabi cortex-m3 assembler output by -S. I've tried compiling the source in aggregate_assignment.zip with the x86_64-apple-darwin compiler, and the same bug seems to be present. NOTE, this bug is also present in GNAT CE 2020.
[Bug c++/99801] New: Address sanitizer false positive with pointer to member function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99801 Bug ID: 99801 Summary: Address sanitizer false positive with pointer to member function. Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: fsb4000 at yandex dot ru Target Milestone: --- Hi. Problematic piece of code: https://gcc.godbolt.org/z/s8x3KqaMb If we change `auto` to `void (Curses_table::*)()` then it works: https://gcc.godbolt.org/z/bezacsTPa clang works in both cases: https://gcc.godbolt.org/z/1e719Maa6 https://gcc.godbolt.org/z/8eqWzGzaW
[committed] d: Don't create gdc.test symlink in the gdc testsuite directory
Hi,
This patch removes the symlink added by the fix for PR88041, to support
filesystems where "file link" fails.
Instead, tests are copied from the source tree (i.e: $srcdir/compilable)
into the test base directory ($base_dir/compilable). A dejagnu test
file with all translated test directives is created in a path that
follows DejaGnu naming conventions ($base_dir/gdc.test/compilable),
which is then passed to `dg-test'.
Before invoking the compiler, the gdc.test prefixed is trimmed from the
test program in `gdc-dg-test' so that all copied test files are picked
up with the correct path names.
Regression tested on x86_64-linux-gnu, and committed to mainline.
Regards,
Iain.
---
gcc/testsuite/ChangeLog:
* lib/gdc-utils.exp (gdc-copy-extra): Rename to...
(gdc-copy-file): ... this. Use file copy instead of open/close.
(gdc-convert-test): Save translated dejagnu test to gdc.test
directory, only write dejagnu directives to the test file.
(gdc-do-test): Don't create gdc.test symlink.
---
gcc/testsuite/lib/gdc-utils.exp | 85 +
1 file changed, 32 insertions(+), 53 deletions(-)
diff --git a/gcc/testsuite/lib/gdc-utils.exp b/gcc/testsuite/lib/gdc-utils.exp
index 6d4a15e9a67..33c01450eb4 100644
--- a/gcc/testsuite/lib/gdc-utils.exp
+++ b/gcc/testsuite/lib/gdc-utils.exp
@@ -145,37 +145,33 @@ proc gdc-convert-args { args } {
return $out
}
-proc gdc-copy-extra { base extra } {
-# Split base, folder/file.
-set type [file dirname $extra]
+proc gdc-copy-file { srcdir filename } {
+# Split folder/file from the filename.
+set targetdir [file dirname $filename]
-# print "Filename: $base - $extra"
+# print "Filename: $srcdir - $filename"
-set fdin [open $base/$extra r]
-fconfigure $fdin -encoding binary
-
-file mkdir $type
-set fdout [open $extra w]
-fconfigure $fdout -encoding binary
-
-while { [gets $fdin copy_line] >= 0 } {
- set out_line $copy_line
- puts $fdout $out_line
-}
-
-close $fdin
-close $fdout
+file mkdir $targetdir
+file copy -force $srcdir/$filename $filename
# Remove file once test is finished.
upvar 2 cleanup_extra_files cleanups
-lappend cleanups $extra
-
-return $extra
+lappend cleanups $filename
}
#
# Translate DMD test directives to dejagnu equivalent.
#
+# This procedure copies the test and all its dependencies from its source
+# location in `$srcdir/$type' to `$base_dir/$type'. A stub dejagnu test file
+# is then created in `$base_dir/gdc.test/$type' containing all translated test
+# directives. This stub is then the test that is handed over to `dg-test'.
+# Before invoking the compiler, the `gdc.test' prefix is trimmed from the test
+# `$prog' name in `gdc-dg-test' so that all copied tests then get picked up
+# with the correct path names.
+#
+# The following directives are recognized:
+#
# COMPILE_SEPARATELY: Not handled.
# EXECUTE_ARGS: Parameters to add to the execution of the test.
# COMPILED_IMPORTS: List of modules files that are imported by the main
@@ -215,29 +211,31 @@ proc gdc-convert-test { base test } {
upvar 1 compilable_do_what compilable_do_what
set compilable_output_file_ext ""
-# Split base, folder/file.
+# Split folder/file from the test.
set type [file dirname $test]
set name [file tail $test]
# print "Filename: $base - $test"
+gdc-copy-file $base $test
+# Read in all test directives, and save the dejagnu equivalents to a new
+# file that will be returned as the test to run.
set fdin [open $base/$test r]
#fconfigure $fdin -encoding binary
-file mkdir $type
-set fdout [open $test w]
+# Include gdc.test prefix so test names follow DejaGnu conventions.
+set testdir [file tail $base]
+file mkdir $testdir/$type
+set fdout [open $testdir/$test w]
#fconfigure $fdout -encoding binary
while { [gets $fdin copy_line] >= 0 } {
- set out_line $copy_line
if [regexp -- {COMPILE_SEPARATELY} $copy_line] {
# COMPILE_SEPARATELY is not handled.
- regsub -- {COMPILE_SEPARATELY.*$} $copy_line "" out_line
} elseif [regexp -- {DISABLED} $copy_line] {
# DISABLED is not handled.
- regsub -- {DISABLED.*$} $copy_line "" out_line
} elseif [regexp -- {LINK:} $copy_line] {
# LINK sets dg-do-what-default "link"
@@ -245,7 +243,6 @@ proc gdc-convert-test { base test } {
} elseif [regexp -- {POST_SCRIPT} $copy_line] {
# POST_SCRIPT is not handled
- regsub -- {POST_SCRIPT.*$} $copy_line "" out_line
} elseif [regexp -- {DFLAGS\s*:\s*(.*)} $copy_line match args] {
# DFLAGS overrides the default value of PERMUTE_ARGS.
@@ -253,32 +250,27 @@ proc gdc-convert-test { base test } {
error "gdc-convert-test: DFLAGS is not empty as expected"
}
[committed] d: Predefine the D_PIE version condition when flag_pie is set.
Hi,
This patch adds D_PIE to the list of predefined version conditions when
flag_pie is default, or set by the command-line. Same as the D_PIC
version condition.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.
Regards,
Iain.
---
gcc/d/ChangeLog:
* d-builtins.cc (d_init_versions): Predefine D_PIE if flag_pie is set.
---
gcc/d/d-builtins.cc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/gcc/d/d-builtins.cc b/gcc/d/d-builtins.cc
index c45edc2fa3f..ce098617c62 100644
--- a/gcc/d/d-builtins.cc
+++ b/gcc/d/d-builtins.cc
@@ -480,6 +480,8 @@ d_init_versions (void)
VersionCondition::addPredefinedGlobalIdent ("D_Coverage");
if (flag_pic)
VersionCondition::addPredefinedGlobalIdent ("D_PIC");
+ if (flag_pie)
+VersionCondition::addPredefinedGlobalIdent ("D_PIE");
if (global.params.doDocComments)
VersionCondition::addPredefinedGlobalIdent ("D_Ddoc");
--
2.27.0
[committed] d: Define language hook for LANG_HOOKS_ENUM_UNDERLYING_BASE_TYPE
Hi,
This patch defines LANG_HOOKS_ENUM_UNDERLYING_BASE_TYPE for the D
front-end, the underlying base type for enumerals are always present in
TREE_TYPE.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.
Regards,
Iain
---
gcc/d/ChangeLog:
* d-lang.cc (d_enum_underlying_base_type): New function.
(LANG_HOOKS_ENUM_UNDERLYING_BASE_TYPE): Set as
d_enum_underlying_base_type.
---
gcc/d/d-lang.cc | 12
1 file changed, 12 insertions(+)
diff --git a/gcc/d/d-lang.cc b/gcc/d/d-lang.cc
index 0720cba1340..5028698a5bc 100644
--- a/gcc/d/d-lang.cc
+++ b/gcc/d/d-lang.cc
@@ -1719,6 +1719,16 @@ d_build_eh_runtime_type (tree type)
return convert (ptr_type_node, build_address (decl));
}
+/* Implements the lang_hooks.enum_underlying_base_type routine for language D.
+ Returns the underlying type of the given enumeration TYPE. */
+
+static tree
+d_enum_underlying_base_type (const_tree type)
+{
+ gcc_assert (TREE_CODE (type) == ENUMERAL_TYPE);
+ return TREE_TYPE (type);
+}
+
/* Definitions for our language-specific hooks. */
#undef LANG_HOOKS_NAME
@@ -1744,6 +1754,7 @@ d_build_eh_runtime_type (tree type)
#undef LANG_HOOKS_DUP_LANG_SPECIFIC_DECL
#undef LANG_HOOKS_EH_PERSONALITY
#undef LANG_HOOKS_EH_RUNTIME_TYPE
+#undef LANG_HOOKS_ENUM_UNDERLYING_BASE_TYPE
#undef LANG_HOOKS_PUSHDECL
#undef LANG_HOOKS_GETDECLS
#undef LANG_HOOKS_GLOBAL_BINDINGS_P
@@ -1774,6 +1785,7 @@ d_build_eh_runtime_type (tree type)
#define LANG_HOOKS_DUP_LANG_SPECIFIC_DECL d_dup_lang_specific_decl
#define LANG_HOOKS_EH_PERSONALITY d_eh_personality
#define LANG_HOOKS_EH_RUNTIME_TYPE d_build_eh_runtime_type
+#define LANG_HOOKS_ENUM_UNDERLYING_BASE_TYPE d_enum_underlying_base_type
#define LANG_HOOKS_PUSHDECLd_pushdecl
#define LANG_HOOKS_GETDECLSd_getdecls
#define LANG_HOOKS_GLOBAL_BINDINGS_P d_global_bindings_p
--
2.27.0
[committed] d: Use COMPILER_FOR_BUILD to build all D front-end generator programs
Hi, It was noticed that the wrong headers were being included for the generator programs built for the D front-end. Now COMPILER_FOR_BUILD and BUILD_COMPILERFLAGS are used to compile them, so that GENERATOR_FILE will be correctly defined. Bootstrapped on x86_64-linux-gnu, and committed to mainline. Regards, Iain. --- gcc/d/ChangeLog: * Make-lang.in (DMDGEN_COMPILE): Remove. (d/%.dmdgen.o): Use COMPILER_FOR_BUILD and BUILD_COMPILERFLAGS to build all D generator programs. (D_SYSTEM_H): New macro. (d/idgen.dmdgen.o): Add dependencies to build. (d/impcnvgen.dmdgen.o): Likewise. * d-system.h: Include bconfig.h if GENERATOR_FILE is defined. --- gcc/d/Make-lang.in | 14 +++--- gcc/d/d-system.h | 4 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/gcc/d/Make-lang.in b/gcc/d/Make-lang.in index b0fce06e507..75857d81ec7 100644 --- a/gcc/d/Make-lang.in +++ b/gcc/d/Make-lang.in @@ -52,7 +52,6 @@ d-warn = $(filter-out -pedantic -Woverloaded-virtual, $(STRICT_WARN)) # Also filter out warnings for missing format attributes in the D Frontend. DMD_WARN_CXXFLAGS = $(filter-out -Wmissing-format-attribute, $(WARN_CXXFLAGS)) DMD_COMPILE = $(subst $(WARN_CXXFLAGS), $(DMD_WARN_CXXFLAGS), $(COMPILE)) -DMDGEN_COMPILE = $(subst $(COMPILER), $(COMPILER_FOR_BUILD), $(DMD_COMPILE)) # D Frontend object files. D_FRONTEND_OBJS = \ @@ -360,6 +359,15 @@ d/id.h: d/id.c d/impcnvtab.c: d/impcnvgen$(build_exeext) cd d && ./impcnvgen$(build_exeext) +# Compile the generator programs. d/%.dmdgen.o: $(srcdir)/d/dmd/%.c - $(DMDGEN_COMPILE) $(D_INCLUDES) $< - $(POSTCOMPILE) + $(COMPILER_FOR_BUILD) -c $(BUILD_COMPILERFLAGS) $(D_INCLUDES) \ + $(BUILD_CPPFLAGS) -o $@ $< + +# Header dependencies for the generator programs. +D_SYSTEM_H = d/dmd/root/dsystem.h d/d-system.h + +d/idgen.dmdgen.o: d/dmd/idgen.c $(D_SYSTEM_H) $(BCONFIG_H) $(SYSTEM_H) + +d/impcnvgen.dmdgen.o: d/dmd/impcnvgen.c d/dmd/mtype.h $(D_SYSTEM_H) \ + $(BCONFIG_H) $(SYSTEM_H) diff --git a/gcc/d/d-system.h b/gcc/d/d-system.h index 685be25b729..a6a9fccc6b8 100644 --- a/gcc/d/d-system.h +++ b/gcc/d/d-system.h @@ -19,7 +19,11 @@ #ifndef GCC_D_SYSTEM_H #define GCC_D_SYSTEM_H +#ifdef GENERATOR_FILE +#include "bconfig.h" +#else #include "config.h" +#endif #include "system.h" /* Used by the dmd front-end to determine if we have POSIX-style IO. */ -- 2.27.0
[committed] d: Don't generate per-module wrapper for calling DSO constructor/destructor.
Hi,
This patch removes the per-module wrapper function for calling the DSO
constructor and destructor. The static constructor/destructor list only
ever has one function to call in it, so mark the gdc.dso_ctor and
gdc.dso_dtor functions as static ctor/dtor directly instead.
Bootstrapped and regression tested on x86_64-linux-gnu/-m32/-mx32, and
committed to mainline.
Regards,
Iain.
---
gcc/d/ChangeLog:
* config-lang.in (gtfiles): Remove modules.cc.
* modules.cc (struct module_info): Remove GTY marker.
(static_ctor_list): Remove variable.
(static_dtor_list): Remove variable.
(register_moduleinfo): Directly set DECL_STATIC_CONSTRUCTOR on
dso_ctor, and DECL_STATIC_DESTRUCTOR on dso_dtor.
(d_finish_compilation): Remove static ctor/dtor handling.
gcc/testsuite/ChangeLog:
* gdc.dg/gdc270a.d: Removed.
* gdc.dg/gdc270b.d: Removed.
---
gcc/d/config-lang.in | 2 +-
gcc/d/modules.cc | 36 +-
gcc/testsuite/gdc.dg/gdc270a.d | 11 ---
gcc/testsuite/gdc.dg/gdc270b.d | 7 ---
4 files changed, 6 insertions(+), 50 deletions(-)
delete mode 100644 gcc/testsuite/gdc.dg/gdc270a.d
delete mode 100644 gcc/testsuite/gdc.dg/gdc270b.d
diff --git a/gcc/d/config-lang.in b/gcc/d/config-lang.in
index 66714acf8d1..0568b8da1de 100644
--- a/gcc/d/config-lang.in
+++ b/gcc/d/config-lang.in
@@ -45,7 +45,7 @@ case "${noconfigdirs}" in
;;
esac
-gtfiles="\$(srcdir)/d/d-tree.h \$(srcdir)/d/d-builtins.cc
\$(srcdir)/d/d-lang.cc \$(srcdir)/d/modules.cc \$(srcdir)/d/typeinfo.cc"
+gtfiles="\$(srcdir)/d/d-tree.h \$(srcdir)/d/d-builtins.cc
\$(srcdir)/d/d-lang.cc \$(srcdir)/d/typeinfo.cc"
# Do not build by default.
build_by_default="no"
diff --git a/gcc/d/modules.cc b/gcc/d/modules.cc
index f51277e61ed..af69815deb9 100644
--- a/gcc/d/modules.cc
+++ b/gcc/d/modules.cc
@@ -75,7 +75,7 @@ static tree stop_minfo_node;
/* Record information about module initialization, termination,
unit testing, and thread local storage in the compilation. */
-struct GTY(()) module_info
+struct module_info
{
vec *ctors;
vec *dtors;
@@ -121,11 +121,6 @@ static module_info *current_testing_module;
static Module *current_module_decl;
-/* Static constructors and destructors (not D `static this'). */
-
-static GTY(()) vec *static_ctor_list;
-static GTY(()) vec *static_dtor_list;
-
/* Returns an internal function identified by IDENT. This is used
by both module initialization and dso handlers. */
@@ -460,10 +455,12 @@ register_moduleinfo (Module *decl, tree minfo)
/* Declare dso_ctor() and dso_dtor(). */
tree dso_ctor = build_dso_cdtor_fn (true);
- vec_safe_push (static_ctor_list, dso_ctor);
+ DECL_STATIC_CONSTRUCTOR (dso_ctor) = 1;
+ decl_init_priority_insert (dso_ctor, DEFAULT_INIT_PRIORITY);
tree dso_dtor = build_dso_cdtor_fn (false);
- vec_safe_push (static_dtor_list, dso_dtor);
+ DECL_STATIC_DESTRUCTOR (dso_dtor) = 1;
+ decl_fini_priority_insert (dso_dtor, DEFAULT_INIT_PRIORITY);
first_module = false;
}
@@ -908,27 +905,4 @@ d_finish_compilation (tree *vec, int len)
tree decl = vec[i];
wrapup_global_declarations (, 1);
}
-
- /* If the target does not directly support static constructors,
- static_ctor_list contains a list of all static constructors defined
- so far. This routine will create a function to call all of those
- and is picked up by collect2. */
- if (static_ctor_list)
-{
- tree decl = build_funcs_gates_fn (get_file_function_name ("I"),
- static_ctor_list, NULL);
- DECL_STATIC_CONSTRUCTOR (decl) = 1;
- decl_init_priority_insert (decl, DEFAULT_INIT_PRIORITY);
-}
-
- if (static_dtor_list)
-{
- tree decl = build_funcs_gates_fn (get_file_function_name ("D"),
- static_dtor_list, NULL);
- DECL_STATIC_DESTRUCTOR (decl) = 1;
- decl_fini_priority_insert (decl, DEFAULT_INIT_PRIORITY);
-}
}
-
-
-#include "gt-d-modules.h"
diff --git a/gcc/testsuite/gdc.dg/gdc270a.d b/gcc/testsuite/gdc.dg/gdc270a.d
deleted file mode 100644
index 4df6f02f753..000
--- a/gcc/testsuite/gdc.dg/gdc270a.d
+++ /dev/null
@@ -1,11 +0,0 @@
-// https://bugzilla.gdcproject.org/show_bug.cgi?id=270
-// { dg-do compile }
-
-module gdc270;
-
-void foo()
-{
-}
-
-/* { dg-final { scan-assembler "_GLOBAL__D_6gdc270" } } */
-/* { dg-final { scan-assembler "_GLOBAL__I_6gdc270" } } */
diff --git a/gcc/testsuite/gdc.dg/gdc270b.d b/gcc/testsuite/gdc.dg/gdc270b.d
deleted file mode 100644
index 5a544c58693..000
--- a/gcc/testsuite/gdc.dg/gdc270b.d
+++ /dev/null
@@ -1,7 +0,0 @@
-// https://bugzilla.gdcproject.org/show_bug.cgi?id=270
-// { dg-do compile }
-
-module gdc270;
-
-/* { dg-final { scan-assembler "_GLOBAL__D_6gdc270" } } */
-/* { dg-final { scan-assembler "_GLOBAL__I_6gdc270" } } */
--
2.27.0
Re: Remove RMS from the GCC Steering Committee
Setting aside whether or not RMS should be associated with the GCC project for a bit, I'm particularly concerned about the tone of some of the messages on this thread. People can and will have differences, and that is fine. But the discussion needs to stay civil. To those who have crossed the line (no, I'm not going to call them out by name) -- please tone things done. We have a long history here of not banning individuals from posting and I don't want to see this discussion escalate to the point where we're forced to take what I would consider drastic measures. To those on the receiving end, I'm terribly sorry that some people can't disagree in a civil manner and I hope their behavior does not discourage you from continuing to contribute to GCC. Jeff
Re: Remove RMS from the GCC Steering Committee
Hello, Siddhesh, Thanks for clarifying your understanding of Nathan's goal. I may indeed have misread and mistaken Nathan's goal and means. I thought the goal was to improve the GCC community by addressing the gender imbalance, and that the means (misguided, IMHO) was to distance ourselves from RMS. Your assertiveness came across to me as a correction of my mistake, but I didn't see any reason to prefer your understanding over mine, until Nathan posted today's followup. Now it looks like you were right, but I still find that a little hard to believe. Are you really sure about your understanding? Do you know for a fact that Nathan agrees with your understanding? Do you know with certainty of anyone else who shares that understanding with you and him? -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Vim, Vi, Voltei pro Emacs -- GNUlius Caesar
Re: Remove RMS from the GCC Steering Committee
Dear GCC Community,
Hi. My name is JeanHeyd Meneide, my online moniker is "ThePhD"
(not an actual Doctor. Yet!). I spend a lot of my time hacking on C
and C++. Some of the things I've done include:
- Contributing (mostly) a Implementation [1]
- Doing a GSoC for GCC and writing up about fixes for vector and
other data structures that can be helpful [2] (a lot of these
optimizations were rolled into libstdc++'s normal vector by
François Dumont, thank you!!)
- Implementing part of my own proposal's [[nodiscard("should have a
reason")]] [3]
- Macros for identifying literal and wide literal encoding, to aid in
code portability and pre-emptively solving a user concern while
preparing for a new C++ proposal that allows identifying the execution
and wide execution character sets deployed by the compiler [4]
I'm also helping to solve the intmax_t problems in C and C++ so
we can have wider integer types beyond "long long" blessed by
numeric_limits.[5]
I am also, recently, the ISO/IEC JTC1 SC22 WG14 - Programming
Languages, C: Project Editor. I do not speak for ISO/IEC, the C
Committee, or my National Body here; this e-mail is sent in a person
capacity, but my affiliations should be known (not that they are
hidden with a cursory search, either).
Asides from many other things, last and most importantly I am a
GCC advocate, a libstdc++ contributor, and an individual who spent an
exorbitant and extraordinary amount of my free time contributing to
these projects and the wider ecosystems in the hope that C, C++, Rust,
and related Systems Programming languages would continue to flourish
under the leadership done by the people here. By the time I was going
to finish my education, the goal was to ramp up these contributions
10-fold. There is much room for improvements in fundamental C and C++
architecture and library, leading me on a long, long journey, to where
I am today.
I am exactly one of the "future contributors" referenced in the
e-mails by Wakely, Rodgers, Wielaard, Poyarekar, and others here, even
if they were not explicitly thinking of me. Or, I would be:
On Sun, Mar 28, 2021 Mark Wielaard wrote:
>
> ...
>
> I witnessed something similar recently when we had setup the
> mailinglist to discuss improving governance of the GNU project. When a
> female GNU (GCC) volunteer spoke up she got attacked and harassed. We
> told the harassers that was totally unacceptable and blocked them from
> sending more emails to the list. RMS arranged for those people to get
> unblocked to continue their hate campaign on the public GNU list so
> they could "defend him and the GNU project". That was followed by a
> torrent of hate to the list making any discussion impossible and
> making women feel like they were specifically targeted. He still
> hasn't learned that his words and actions are dog whistles for
> misogynists, transphobics and racists. This really has to stop.
>
> ...
This is unacceptable. The only reason I was told - as early as
yesterday, by Free Software advocates, to my socially distanced face -
that Stallman was still here is because he was powerless and had no
effect on the project. That it was run by the caring,
community-oriented stewardship of the "real volunteers" doing the
"actual work".
That is not what this e-mail reveals.
Further digging into Stallman's own words and behavior also
reveals that he continues to flex this influence throughout the
project (and in other places), showing up (generally unsolicited) into
places to do this kind of gross and extreme harassment and engaging in
canceling our own hardworking contributors that actually write code
and do work. This is not a person who is just here for "historical
reasons" and who has "no power"; this is an active, perpetual threat
to hardworking and contributing members of the Free Software movement.
I refuse to spend my free time supporting a single bigot and an
entire globe's worth of toxic enthusiasts who actively support his
behavior while letting people like him create horrible ecosystems for
other developers. At the start of this conversation, I was much like
Nathan; I wanted an explanation. Having reviewed the facts of the
situation, I can now unequivocally say that an explanation is not even
close to enough.
I will never, ever contribute another line of code, another
proposal implementation[6], another optimization, or another
new/better library implementation to GCC and all of its affiliated
projects, including the compilers, glibc, libstdc++, the potential
upcoming Rust implementation, and more until this problem is not
"address", but *fixed*. If you never fix it, I will never return.
Wish you and your community all the best in sorting this out,
JeanHeyd Meneide
[#]: References -
https://gist.github.com/ThePhD/bcfad83f01e6a641c3fda5cfc013a72d
Re: [GSoC-2021] Interested in project `Extend the static analysis pass`
On Sun, 2021-03-28 at 18:06 +0530, Saloni Garg wrote:
> Hi, I have tried the following examples with the fanalyzer option in
> g++.
>
> 1 (a)
> void myFunction()
> {
> char *p =new char;
> }
> int main()
> {
> func();
> return 0;
> }
BTW, are you familiar with Compiler Explorer (godbolt.org)? It's very
handy for testing small snippets of code on different compilers and
different compiler versions. Though I don't know how long the URLs are
good for (in terms of how long code is cached for)
Fixing up the name of the called function to "func":
https://godbolt.org/z/TnM6n4xGc
I get the leak report, as per RFE 94355. This warning looks correct,
in that p does indeed leak.
I should mention that the analyzer has some special-casing for "main",
in that the user might not care about one-time leaks that occur within
"main", or something only called directly by it; this doesn't seem to
be the case here. If I remove the implementation to main, the analyzer
still correctly complains about the leak:
https://godbolt.org/z/zhK4vW6G8
: In function 'void func()':
:4:1: warning: leak of 'p' [CWE-401] [-Wanalyzer-malloc-leak]
4 | }
| ^
'void func()': events 1-2
|
|3 | char *p =new char;
| | ^~~~
| | |
| | (1) allocated here
|4 | }
| | ~
| | |
| | (2) 'p' leaks here; was allocated at (1)
|
> 1(b)
> void myFunction()
> {
> try {
> char *p = new char;
> throw p;
> }
> catch(...) {
> }
> }
> int main()
> {
> myFunction();
> return 0;
> }
> In 1(a), there is no exception handling. When I ran `cc1plus`, a
> memory
> leak was reported as shown in bug #94355.
> In 1(b), there is a use of exception handling. When I ran cc1plus`,
> no
> memory leaks were detected. I believe there should be one. Can you
> please
> confirm from your side as well?
I too am seeing no diagnostics on 1(b).
> As you said all the calls to try, catch and
> throw got converted to _cxa prefixed functions.
-fdump-ipa-analyzer=stderr shows the _cxa-prefixed functions:
https://godbolt.org/z/YMa9dE6aM
> I am trying to find the
> places where the corresponding checks can be placed for the analysis
> of
> exception handling in gimple IR.
Have a look at exploded_node::on_stmt in engine.cc; in particular, see
the GIMPLE_CALL case in the switch statement. Most of the the
analyzer's "knowledge" of the behaviors of specific functions is here,
or called from here.
The simpler cases are handled in the call to
m_region_model->on_call_pre
for functions which merely update state, which are implemented in
region-model-impl-calls.cc
Cases involving state machines (e.g. allocation) are handled in the:
sm.on_stmt
call torwards the bottom of the function.
But exception-handling is a special case, in that it affects control
flow. The closest thing to compare it to currently within the analyzer
is setjmp/longjmp, so it's worth stepping through how that is handled.
In particular, the real implementation of longjmp involves directly
updating the program counter, registers and stack, potentially popping
multiple stack frames. This is similar to what throwing an exception
does.
So I'd recommend looking at the analyzer's implementation of
setjmp/longjmp, the custom classes that I added to handle them, and
stepping through how exploded_node::on_stmt handles setjmp and longjmp
calls, and what the resulting exploded_graph looks like (-fdump-
analyzer-exploded-graph and -fdump-analyzer-supergraph), in that
special-cased edges have to be created that weren't in the original
CFGs or callgraph (for the interprocedural case).
I think an implementation of exception-handling would look somewhat
similar.
> Please, let me know your thoughts on this.
Looks like you're making a great start.
Hope this is helpful
Dave
> On Fri, Mar 26, 2021 at 12:48 AM David Malcolm
> wrote:
>
> > On Thu, 2021-03-25 at 14:52 +0530, Saloni Garg via Gcc wrote:
> > > Hi all,
> > > I am an undergraduate student in AMU, Aligarh. I am interested in
> > > the
> > > project* `Extend the static analysis pass`. *I have followed
> > > this(
> > > https://gcc.gnu.org/pipermail/gcc/2021-March/234941.html) and
> > > been
> > > able to
> > > successfully build and successfully ran and pass the test suite
> > > for C
> > > and
> > > C++.
> > >
> > > I found this sub-project `C++ support (new/delete checking,
> > > exceptions,
> > > etc)` interesting and may be the conservative code for this can
> > > be
> > > made
> > > along the lines of malloc/free implementation in C. I found here(
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355) that some
> > > part of
> > > it
> > > has already been implemented . I would like to expand it further
> > > and
> > > learn
> > > about it, maybe start with writing some test cases, please let me
> > > know.
> > >
> > > Further, I am inclined on
New Swedish PO file for 'gcc' (version 11.1-b20210321)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: https://translationproject.org/latest/gcc/sv.po (This file, 'gcc-11.1-b20210321.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: Remove RMS from the GCC Steering Committee
On Sun, 28 Mar 2021, 13:50 Mark Wielaard, wrote: > RMS actively undermines those who try to make our community a little > bit more welcoming. Violating anti-harassment policies of > conferences. Even those from the FSF by claiming to be above those > policies because of his leadership position or using his position to > tell staff they cannot enforce such policies against others. Because > he is against enforcing any anti-harassment policy some GNU > mailinglist is currently being used to organize a doxing campaign > (publishing photos, address and calls to report to the local police > station to get her house raided and arrested) for simply saying the > same things we are discussing here now. > > I witnessed something similar recently when we had setup the > mailinglist to discuss improving governance of the GNU project. When a > female GNU (GCC) volunteer spoke up she got attacked and harassed. We > told the harassers that was totally unacceptable and blocked them from > sending more emails to the list. RMS arranged for those people to get > unblocked to continue their hate campaign on the public GNU list so > they could "defend him and the GNU project". That was followed by a > torrent of hate to the list making any discussion impossible and > making women feel like they were specifically targeted. He still > hasn't learned that his words and actions are dog whistles for > misogynists, transphobics and racists. This really has to stop. > We even have a GNU maintainer* with no link to GCC sending abusive emails in this thread, because he feels such harassment is acceptable. * He is listed as maintainer on gnu.org despite the project having no public release and an empty repo. It looks like vapourware that only exists in his head, but he's still a proud "GNU maintainer". If that's who GNU welcomes, count me out.
[Bug fortran/98201] CSQRT function gives bad resuts at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201 Dominique d'Humieres changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #20 from Dominique d'Humieres --- > I think it can be closed. Thus closing.
[Bug fortran/98201] CSQRT function gives bad resuts at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201 --- Comment #19 from dpozar at ecs dot umass.edu --- I think it can be closed. never found out why this occurred, but I reloaded gfortran from another source and it worked after that. thanks, dave From: dominiq at lps dot ens.fr Sent: Sunday, March 28, 2021 8:38 AM To: David Pozar Subject: [Bug fortran/98201] CSQRT function gives bad resuts at runtime https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201 --- Comment #18 from Dominique d'Humieres --- Could this PR be closed or moved to target component? -- You are receiving this mail because: You reported the bug.
Re: Remove RMS from the GCC Steering Committee
Alexandre, Making our community more welcoming is indeed a process. And some steps will just be symbolic. But I don't believe removing RMS from (perceived) leadership positions in the GNU project and from the FSF is just symbolic. And even for a symbolic step it is a powerful one. It shows we don't tolerate harassment in our project. And I do hope it doesn't end with that step. We also have to decide whether we still want to be associated with the FSF. Hopefully the FSF takes their responsibility and replaces the whole board to show we can start with a clean slate. One issue is that as long as GCC is associated with RMS and the FSF others who could help us won't because the FSF is that toxic now: https://www.outreachy.org/blog/2021-03-23/fsf-participation-barred/ And they are far from the only Free Software project who has said something similar. We are not talking about some single recent incident, but about decades of problematic behavior. At the last face-to-face GNU Tools Cauldron, everybody I talked to about it had some story about being harassed by RMS, had witnessed such harassment or heard from or knew someone who had been. For years people have tried to help him see how his actions and words might hurt others, even if they are completely logically correct to himself. And obviously that is sometimes hard, nobody is perfect, but hopefully we get a little better every time. But this never happened. And it really needs to stop. RMS actively undermines those who try to make our community a little bit more welcoming. Violating anti-harassment policies of conferences. Even those from the FSF by claiming to be above those policies because of his leadership position or using his position to tell staff they cannot enforce such policies against others. Because he is against enforcing any anti-harassment policy some GNU mailinglist is currently being used to organize a doxing campaign (publishing photos, address and calls to report to the local police station to get her house raided and arrested) for simply saying the same things we are discussing here now. I witnessed something similar recently when we had setup the mailinglist to discuss improving governance of the GNU project. When a female GNU (GCC) volunteer spoke up she got attacked and harassed. We told the harassers that was totally unacceptable and blocked them from sending more emails to the list. RMS arranged for those people to get unblocked to continue their hate campaign on the public GNU list so they could "defend him and the GNU project". That was followed by a torrent of hate to the list making any discussion impossible and making women feel like they were specifically targeted. He still hasn't learned that his words and actions are dog whistles for misogynists, transphobics and racists. This really has to stop. You link to a parody of a request of tens of Free Software foundation projects and thousands of Free Software hackers who are calling for the removal of the entire Board of the Free Software Foundation and for Richard M. Stallman to be removed from all leadership positions, including the GNU Project. For similar reasons that people here are now calling for RMS to be removed from the GCC steering committee. The real letter is here: https://rms-open-letter.github.io/ Sometimes satire is a way to deal with difficult problems, but I don't think that is appropriate here and I hope people take these issues seriously, because I think they are. Mark
[Bug fortran/98201] CSQRT function gives bad resuts at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201 --- Comment #18 from Dominique d'Humieres --- Could this PR be closed or moved to target component?
Re: [GSoC-2021] Interested in project `Extend the static analysis pass`
Hi, I have tried the following examples with the fanalyzer option in g++.
1 (a)
void myFunction()
{
char *p =new char;
}
int main()
{
func();
return 0;
}
1(b)
void myFunction()
{
try {
char *p = new char;
throw p;
}
catch(...) {
}
}
int main()
{
myFunction();
return 0;
}
In 1(a), there is no exception handling. When I ran `cc1plus`, a memory
leak was reported as shown in bug #94355.
In 1(b), there is a use of exception handling. When I ran cc1plus`, no
memory leaks were detected. I believe there should be one. Can you please
confirm from your side as well? As you said all the calls to try, catch and
throw got converted to _cxa prefixed functions. I am trying to find the
places where the corresponding checks can be placed for the analysis of
exception handling in gimple IR.
Please, let me know your thoughts on this.
On Fri, Mar 26, 2021 at 12:48 AM David Malcolm wrote:
> On Thu, 2021-03-25 at 14:52 +0530, Saloni Garg via Gcc wrote:
> > Hi all,
> > I am an undergraduate student in AMU, Aligarh. I am interested in the
> > project* `Extend the static analysis pass`. *I have followed this(
> > https://gcc.gnu.org/pipermail/gcc/2021-March/234941.html) and been
> > able to
> > successfully build and successfully ran and pass the test suite for C
> > and
> > C++.
> >
> > I found this sub-project `C++ support (new/delete checking,
> > exceptions,
> > etc)` interesting and may be the conservative code for this can be
> > made
> > along the lines of malloc/free implementation in C. I found here(
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94355) that some part of
> > it
> > has already been implemented . I would like to expand it further and
> > learn
> > about it, maybe start with writing some test cases, please let me
> > know.
> >
> > Further, I am inclined on this(
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97111). Let me know if
> > it is
> > still available.
> >
> > Looking forward to hearing from you guys.
> > Thanks,
> > Saloni Garg
>
> Hi!
>
> I'm the author/maintainer of the static analysis pass, and would be the
> mentor for any GSoC project(s) involving it.
>
> I've already implemented most of the new/delete checking in GCC 11; the
> big missing component there is exception-handling.
>
> Implementing exception-handling in the analyzer could make a good GSoC
> project: it's non-trivial, but hopefully doable in one summer. I see
> you've already seen bug 97111, and there are some links in that bug to
> resources. Given that the analyzer runs on the gimple-ssa
> representation, by the time it sees the code, much of the exception-
> handling has already been translated into calls to various __cxa_-
> prefixed functions in the C++ runtime, so part of the work would
> involve "teaching" the analyzer about those functions. One way to make
> a start on this would be to create a collection of trivial C++ examples
> that use exceptions, and then look at analyzer dumps to see what IR is
> being "seen" by the analyzer for the various constructs. (I actually
> started this a long time ago and have a very crude barely-working
> prototype, but it was just the start, and I've forgotten almost all of
> it...)
>
> Hope this is helpful
> Dave
>
>
>
[Bug fortran/95998] gfc_typename use of static memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95998 Dominique d'Humieres changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #4 from Dominique d'Humieres --- The off by one problem has been fixed by r11-7873, closing.
Re: My 2nd attempt to devel for gcc
Hello, Ok fair enough. I thought cleaner separation of FE and generics interface would be useful feature. It would make adding new FE easier too hopefully. We could provide either multiple FEs per binary or not. Additionally, In single FE per binary option of my fegens cleanup scenario we could avoid calling langhooks via pointer and funcs could be statically called. As on data member read from langhooks needing mem access now, we could avoid this too and const data members would be inlined similarly to macro consts generally. But if there is no demand for fe<->generics cleanup its ok. As on your question on avoiding storing bytecode into lto and rereading it, it indeed looks like bit over the top task for me at the moment. I woukd need to researching it more deeply. What i rather meant was compiling in multiple targets and choosing via cmdline opts which one to use. As on Your questions wrt multiple targets, indeed target specific constint macro unrolling would need generally a call and additionally probably indirect one unfirtunately. If the hit on perfirmance is too big here its probably a no go. Unless we just cleanup generics target interface, then target data member reads can be as cheap as constint macro unrolling. As on command line processing, we would probably unfortunately have to make it multipass and opts unresolved in first pass would get checked against registered target opts available in 2nd pass only after targetsel option is found. Id check for availability of all required fkags in last phase where here selected target is already known. Additionally this multitarget scenario might have intermediate "generics target interface cleanup phase" which would help cleaning up this lower interface at first, posibly simplifying target autogen and unifying between constdata reads and calls to a target etc. In this phase data member reads from target will be as cheap as const int macro unrolling too. Here we can also think whether to stop at this phase or to extend it into multitarget feature. Hope all this makes my rationale bit less chaotic. If theres demand on researching and hopefully implementing any of these, please let me know. Best regards, Pawel Kunio niedz., 28.03.2021, 11:34 użytkownik Jonathan Wakely napisał: > > > On Sun, 28 Mar 2021, 02:20 pawel k., wrote: > >> Hmm, >> Thanks. Not sure I can see answer from him. Ill recheck it. >> > > > https://gcc.gnu.org/pipermail/gcc/2021-March/235079.html > > > >
[Bug middle-end/57832] compiling sha-256 code (xz 5.0.5) generates false warnings when using -march=native on Atom CPU
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57832
--- Comment #7 from Manuel López-Ibáñez ---
(In reply to Martin Sebor from comment #6)
> In the reduced test cases (in comment #3 and comment #4) d is a global
> variable so it's value is zero. c is assigned in the first iteration of the
> loop (when e is zero) and used in subsequent iterations when it has a
> defined value, so the warning .seems like a clear false postive to me. (I
> didn't look at the big test case.)
Oh, yes! Sorry, my comment didn't make sense. Even simpler:
int a, d;
void f (void)
{
int c;
for (int e = 0; e < 64; e += 6)
{
if (e == 0)
c = d;
else
a += c;
}
}
Re: My 2nd attempt to devel for gcc
Hello, Yea ok got it. Ill reply. I dont get email notifications from him. Ill prepare reply asap as of what we can or cannot do and what will be costs and benefits. Then he/you can decide. Best regards, Pawel niedz., 28.03.2021, 11:34 użytkownik Jonathan Wakely napisał: > > > On Sun, 28 Mar 2021, 02:20 pawel k., wrote: > >> Hmm, >> Thanks. Not sure I can see answer from him. Ill recheck it. >> > > > https://gcc.gnu.org/pipermail/gcc/2021-March/235079.html > > > >
Re: My 2nd attempt to devel for gcc
On Sun, 28 Mar 2021, 02:20 pawel k., wrote: > Hmm, > Thanks. Not sure I can see answer from him. Ill recheck it. > https://gcc.gnu.org/pipermail/gcc/2021-March/235079.html
[Bug c/99797] accessing uninitialized automatic variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797 --- Comment #5 from Andrew Pinski --- (In reply to Andrew Pinski from comment #4) > (In reply to Martin Uecker from comment #3) > > The C standard says (6.3.2.1p2) > > J.2 Undefined behavior > > — The value of an object with automatic storage duration is used while it is > indeterminate (6.2.4, 6.7.9, 6.8). 6.9p10 If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. Is that enough?
[Bug c/99797] accessing uninitialized automatic variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797 --- Comment #4 from Andrew Pinski --- (In reply to Martin Uecker from comment #3) > The C standard says (6.3.2.1p2) J.2 Undefined behavior — The value of an object with automatic storage duration is used while it is indeterminate (6.2.4, 6.7.9, 6.8).
[Bug c/99797] accessing uninitialized automatic variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99797 --- Comment #3 from Martin Uecker --- The C standard says (6.3.2.1p2) "... If the lvalue designates an object of automatic storage duration that could have been declared with the register storage class (never had its address taken), and that object is uninitialized (not declared with an initializer and no assignment to it has been performed prior to use), the behavior is undefined."
