Re: [PATCH] Deprecate -frepo option.
On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote: > > On 6/21/19 4:28 PM, Richard Biener wrote: > > On Fri, Jun 21, 2019 at 4:13 PM Jakub Jelinek wrote: > >> > >> On Fri, Jun 21, 2019 at 04:04:00PM +0200, Martin Liška wrote: > >>> On 6/21/19 1:58 PM, Jakub Jelinek wrote: > On Fri, Jun 21, 2019 at 01:52:09PM +0200, Martin Liška wrote: > > On 6/21/19 1:47 PM, Jonathan Wakely wrote: > >> On Fri, 21 Jun 2019 at 11:40, Martin Liška wrote: > >>> Yes, I would be fine to deprecate that for GCC 10.1 > >> > >> Would it be appropriate to issue a warning in GCC 10.x if the option > >> is used? > > > > Sure. With the patch attached one will see: > > > > $ gcc -frepo /tmp/main.cc -c > > gcc: warning: switch ‘-frepo’ is no longer supported > > > > I'm sending patch that also removes -frepo tests from test-suite. > > I've been testing the patch. > > IMHO for just deprecation of an option you don't want to remove it from > the > testsuite, just match the warning it will generate in those tests, and > I'm not convinced you want to remove it from the documentation (rather > than > just saying in the documentation that the option is deprecated and might > be > removed in a later GCC version). > >>> > >>> Agree with you. I'm sending updated version of the patch. > >>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > >> > >> I'm also not convinced about the Deprecated flag, seems like that is a flag > >> that we use for options that have been already removed. > >> So, instead there should be some proper warning in the C++ FE for it, > >> or just Warn. > > > > In principle -frepo is a nice idea - does it live up to its promises? That > > is, > > does it actually work, for example when throwing it on the libstdc++ > > testsuite or a larger C++ project? > > I've just tested tramp3d, and it does not survive linking: > > g++ tramp3d-v4.o > collect: recompiling tramp3d-v4.cpp > collect: relinking > collect: recompiling tramp3d-v4.cpp > collect: relinking > collect: recompiling tramp3d-v4.cpp > collect: relinking > collect: recompiling tramp3d-v4.cpp > collect: relinking > collect: recompiling tramp3d-v4.cpp > collect: relinking > collect: recompiling tramp3d-v4.cpp > collect: relinking > collect: recompiling tramp3d-v4.cpp > collect: relinking > collect: recompiling tramp3d-v4.cpp > collect: relinking > collect: recompiling tramp3d-v4.cpp > collect: relinking > collect: recompiling tramp3d-v4.cpp > collect: relinking > collect: recompiling tramp3d-v4.cpp > collect: relinking > collect: recompiling tramp3d-v4.cpp > collect: relinking > collect: recompiling tramp3d-v4.cpp > collect: relinking > collect: recompiling tramp3d-v4.cpp > collect: relinking > collect: recompiling tramp3d-v4.cpp > collect: relinking > collect: recompiling tramp3d-v4.cpp > collect: relinking > collect: recompiling tramp3d-v4.cpp > collect: relinking > /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: > /tmp/ccEeuyj7.ltrans0.ltrans.o: in function > `RefCountedBlockPtr, > ViewEngine<3, IndexFunction UniformRectilinearTag, CartesianTag, 3> >::PositionsFunctor> > >, false, > RefBlockController, > ViewEngine<3, IndexFunction UniformRectilinearTag, CartesianTag, 3> >::PositionsFunctor> > > > > >::RefCountedBlockPtr(RefCountedBlockPtr double, Full>, ViewEngine<3, IndexFunction UniformRectilinearTag, CartesianTag, 3> >::PositionsFunctor> > >, false, > RefBlockController, > ViewEngine<3, IndexFunction UniformRectilinearTag, CartesianTag, 3> >::PositionsFunctor> > > > > const&)': > :(.text+0x4181b): undefined reference to > `RefCountedPtr Full>, ViewEngine<3, IndexFunction UniformRectilinearTag, CartesianTag, 3> >::PositionsFunctor> > > > > >::RefCountedPtr(RefCountedPtr Vector<3, double, Full>, ViewEngine<3, IndexFunction double, UniformRectilinearTag, CartesianTag, 3> >::PositionsFunctor> > > > > > const&)' > /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: > /tmp/ccEeuyj7.ltrans0.ltrans.o: in function `std::_Vector_base, > Interval<3> >, std::allocator, Interval<3> > > > >::_Vector_impl::~_Vector_impl()': > :(.text+0xc1890): undefined reference to > `std::allocator, Interval<3> > >::~allocator()' > /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: > /tmp/ccEeuyj7.ltrans0.ltrans.o: in function `std::_Vector_base, > Interval<3> >, std::allocator, Interval<3> > > > >::_Vector_base()': > :(.text+0xc18aa): undefined reference to > `std::_Vector_base, Interval<3> >, > std::allocator, Interval<3> > > >::_Vector_impl::_Vector_impl()' > /usr/lib64/gcc/x86_64-suse-linux/9/../../../../x86_64-suse-linux/bin/ld: > /tmp/ccEeuyj7.ltrans0.ltrans.o: in function `std::vector, > std::allocator > >::_S_use_relocate()': > :(.text+0xc496f): undefined reference to `std::vector, > std::allocator > >::_S_nothrow_relocate(std::integral_constant true>)' > /usr/lib64/
Re: [PATCH] Deprecate -frepo option.
On 7/9/19 6:39 AM, Richard Biener wrote: On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote: Same happens also for GCC7. It does 17 iteration (#define MAX_ITERATIONS 17) and apparently 17 is not enough to resolve all symbols. And it's really slow. Ouch. hm, 17 is a magic number. in C++98 it was the maximum depth of template instantiations that implementations needed to support. Portable code could not expect more. So the worst case -frepo behaviour would be 17 iterations. That's not true any more, it's been 1024 since C++11. Has a bug been filed about this frepo problem? If not, it suggest those using frepo are not compiling modern C++. That said, I would recommend to remove it :) In the end it's up to the C++ FE maintainers but the above clearly doesn't look promising (not sure if it keeps re-compiling _all_ repo-triggered templates or just incrementally adds them to new object files). I'm not opposed to removing -frepo from GCC 10 but then I would start noting it is obsolete on the GCC 9 branch at least. I concur. frepo's serial reinvocation of the compiler is not compatible with modern C++ code bases. nathan -- Nathan Sidwell
Re: [GSoC'19, libgomp work-stealing] Task parallelism runtime
Hi, This is an update about my status. I've been working on unifying the three queues into a single queue. I'm almost finished and passed all the tests except for the dependency handling part. Ray Kim
Re: [PATCH] Deprecate -frepo option.
On 7/9/19 1:41 PM, Nathan Sidwell wrote: > On 7/9/19 6:39 AM, Richard Biener wrote: >> On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote: >>> > >>> >>> Same happens also for GCC7. It does 17 iteration (#define MAX_ITERATIONS >>> 17) and >>> apparently 17 is not enough to resolve all symbols. And it's really slow. >> >> Ouch. > > hm, 17 is a magic number. in C++98 it was the maximum depth of template > instantiations that implementations needed to support. Portable code could > not expect more. So the worst case -frepo behaviour would be 17 iterations. > > That's not true any more, it's been 1024 since C++11. > > Has a bug been filed about this frepo problem? I create a new one: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91125 > If not, it suggest those using frepo are not compiling modern C++. > >>> That said, I would recommend to remove it :) >> >> In the end it's up to the C++ FE maintainers but the above clearly >> doesn't look promising >> (not sure if it keeps re-compiling _all_ repo-triggered templates or >> just incrementally adds >> them to new object files). > >> I'm not opposed to removing -frepo from GCC 10 but then I would start >> noting it is obsolete >> on the GCC 9 branch at least. > > I concur. frepo's serial reinvocation of the compiler is not compatible with > modern C++ code bases. Great. Then I'm sending patch that does the functionality removal. Ready to be installed after proper testing & bootstrap? Martin > > nathan > >From 06a298c3381c204b6ed6cf97b05940ebb8abcbde Mon Sep 17 00:00:00 2001 From: Martin Liska Date: Tue, 9 Jul 2019 14:45:05 +0200 Subject: [PATCH] Remove support for repo files (PR c++/91125). gcc/ChangeLog: 2019-07-09 Martin Liska PR c++/91125 * Makefile.in: Remove tlink.o. * collect2.c (do_link): New function isolated from do_tlink. (main): Use. * collect2.h (do_tlink): Remove declaration of do_tlink. * doc/extend.texi: Remove documentation of -frepo. * doc/invoke.texi: Likewise. * doc/sourcebuild.texi: Remove cleanup-repo-files. * tlink.c: Remove. gcc/c-family/ChangeLog: 2019-07-09 Martin Liska PR c++/91125 * c-common.c: Remove definition of flag_use_repository. * c-common.h: Likewise. * c-opts.c (c_common_handle_option): Do not handle OPT_frepo option. * c.opt: Mark the option with Deprecated. gcc/cp/ChangeLog: 2019-07-09 Martin Liska PR c++/91125 * Make-lang.in: Remove repo.o. * config-lang.in: Likewise. * cp-tree.h (init_repo): Remove declarations of repo-related functions. (repo_emit_p): Likewise. (repo_export_class_p): Likewise. (finish_repo): Likewise. * decl2.c (import_export_class): Always set -1 value/ (mark_needed): Remove -frepo from comment. (import_export_decl): Similarly here. (c_parse_final_cleanups): Remove call of finish_repo. * lex.c (cxx_init): Remove call to init_repo. * optimize.c (can_alias_cdtor): Remove dead condition. * pt.c (push_template_decl_real): Update comment. (instantiate_decl): Remove dead code used for -frepo. * repo.c: Remove. gcc/testsuite/ChangeLog: 2019-07-09 Martin Liska PR c++/91125 * g++.dg/parse/repo1.C: Remove. * g++.dg/rtti/repo1.C: Remove. * g++.dg/template/repo1.C: Remove. * g++.dg/template/repo10.C: Remove. * g++.dg/template/repo11.C: Remove. * g++.dg/template/repo2.C: Remove. * g++.dg/template/repo3.C: Remove. * g++.dg/template/repo4.C: Remove. * g++.dg/template/repo5.C: Remove. * g++.dg/template/repo6.C: Remove. * g++.dg/template/repo7.C: Remove. * g++.dg/template/repo8.C: Remove. * g++.dg/template/repo9.C: Remove. * g++.old-deja/g++.pt/instantiate4.C: Remove. * g++.old-deja/g++.pt/instantiate6.C: Remove. * g++.old-deja/g++.pt/repo1.C: Remove. * g++.old-deja/g++.pt/repo2.C: Remove. * g++.old-deja/g++.pt/repo3.C: Remove. * g++.old-deja/g++.pt/repo4.C: Remove. * lib/g++.exp: Remove removal of repo files. * lib/gcc-dg.exp: Likewise. * lib/obj-c++.exp: Likewise. --- gcc/Makefile.in | 2 +- gcc/c-family/c-common.c | 5 - gcc/c-family/c-common.h | 5 - gcc/c-family/c-opts.c | 6 - gcc/c-family/c.opt| 4 +- gcc/collect2.c| 36 +- gcc/collect2.h| 4 +- gcc/cp/Make-lang.in | 2 +- gcc/cp/config-lang.in | 2 +- gcc/cp/cp-tree.h | 6 - gcc/cp/decl2.c| 37 +- gcc/cp/lex.c | 2 - gcc/cp/optimize.c | 3 - gcc/cp/pt.c | 18 +- gcc/cp/repo.c | 374 gcc/doc/extend.texi | 25 - gcc/doc/invoke.texi | 8 +- gcc/doc/sourcebuild.texi | 3 - gcc/testsuite/g++.dg/parse/repo1.C| 10 - gcc/tes
Re: [PATCH] Deprecate -frepo option.
On 7/9/19 9:00 AM, Martin Liška wrote: On 7/9/19 1:41 PM, Nathan Sidwell wrote: On 7/9/19 6:39 AM, Richard Biener wrote: On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote: Same happens also for GCC7. It does 17 iteration (#define MAX_ITERATIONS 17) and apparently 17 is not enough to resolve all symbols. And it's really slow. Ouch. hm, 17 is a magic number. in C++98 it was the maximum depth of template instantiations that implementations needed to support. Portable code could not expect more. So the worst case -frepo behaviour would be 17 iterations. That's not true any more, it's been 1024 since C++11. Has a bug been filed about this frepo problem? I create a new one: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91125 If not, it suggest those using frepo are not compiling modern C++. That said, I would recommend to remove it :) In the end it's up to the C++ FE maintainers but the above clearly doesn't look promising (not sure if it keeps re-compiling _all_ repo-triggered templates or just incrementally adds them to new object files). I'm not opposed to removing -frepo from GCC 10 but then I would start noting it is obsolete on the GCC 9 branch at least. I concur. frepo's serial reinvocation of the compiler is not compatible with modern C++ code bases. Great. Then I'm sending patch that does the functionality removal. Ready to be installed after proper testing & bootstrap? I'd like Jason to render an opinion, and we should mark it obsolete in the gcc 9 branch (how much runway would that give people?) nathan -- Nathan Sidwell
Re: ARM peephole2 from 2003 never merged, still valid
On 7/8/19 12:41 AM, Fredrik Hederstierna wrote: >> From: Segher Boessenkool Sent: >> Thursday, June 6, 2019 6:49 PM To: Richard Earnshaw (lists) Cc: >> Fredrik Hederstierna; Jeff Law; gcc@gcc.gnu.org Subject: Re: ARM >> peephole2 from 2003 never merged, still valid >> >> >> On Thu, Jun 06, 2019 at 05:06:35PM +0100, Richard Earnshaw (lists) >> wrote: >>> The reason combine doesn't catch this is because at the time it >>> runs the MOV is in a different basic block. Later on it is sunk >>> into the same basic block, but it's then too late to do the >>> merge. >> >> Or you could say the MOV didn't even exist yet: the insn that is >> merged by the peephole is created by the prologue code, >> eventually. >> >> This isn't really a target problem, it is very much generic, but I >> don't see a better solution than a peephole either. >> >> Segher > > So what is the conclusion, should be re-open PR-9663 and try to fix > the missing peephole? I think there will always be cases where the > code generated target specific register optimizations are possible, > that not necessarily have any direct connection of the actual basic > blocks but more by chance which instructions are finally generated > after each other, where maybe eg peephole-alike optimizers are the > only solution to do the job? /Fredrik > I think it's largely up to the ARM maintainers. Based on my understanding of the thread, I'd go with the peephole2. jeff
Re: [PATCH] Deprecate -frepo option.
On 7/9/19 1:48 PM, Nathan Sidwell wrote: On 7/9/19 9:00 AM, Martin Liška wrote: On 7/9/19 1:41 PM, Nathan Sidwell wrote: On 7/9/19 6:39 AM, Richard Biener wrote: On Mon, Jul 8, 2019 at 2:04 PM Martin Liška wrote: Same happens also for GCC7. It does 17 iteration (#define MAX_ITERATIONS 17) and apparently 17 is not enough to resolve all symbols. And it's really slow. Ouch. hm, 17 is a magic number. in C++98 it was the maximum depth of template instantiations that implementations needed to support. Portable code could not expect more. So the worst case -frepo behaviour would be 17 iterations. That's not true any more, it's been 1024 since C++11. Has a bug been filed about this frepo problem? I create a new one: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91125 If not, it suggest those using frepo are not compiling modern C++. That said, I would recommend to remove it :) In the end it's up to the C++ FE maintainers but the above clearly doesn't look promising (not sure if it keeps re-compiling _all_ repo-triggered templates or just incrementally adds them to new object files). I'm not opposed to removing -frepo from GCC 10 but then I would start noting it is obsolete on the GCC 9 branch at least. I concur. frepo's serial reinvocation of the compiler is not compatible with modern C++ code bases. Great. Then I'm sending patch that does the functionality removal. Ready to be installed after proper testing & bootstrap? I'd like Jason to render an opinion, and we should mark it obsolete in the gcc 9 branch (how much runway would that give people?) I haven't noticed any responses to my earlier question: Are there any targets without COMDAT support that we still care about? But given the observation above about the 17 limit, even if there are such targets it wouldn't be very useful for modern code. And if people want to compile old code for old platforms, they might as well continue to use an old compiler. So I'm OK with deprecating with a warning for the next GCC 9 release, to see if anyone complains, and removing in 10. Jason
RFC: Deprecate libstdc++ Policy-Based Data Structures
Hi there! I hope, this message will go to where it's expected to go, since I'm not really familiar with e-mail threads. I was the one who brought https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81806 issue about sub-optimal implementation of split function in pbds. The reason why I did so is clearly described on this comment: https://codeforces.com/blog/entry/10355?#comment-157883 So, a bit of story and context. Five years ago at codeforces.com (competitive programming website) someone eventually pointed out that there is order-statistics tree in SGI library. It turned out to be very useful in competitions since it is quite common type of queries to count number of elements less than k in set and unfortunately regular std::set doesn't provide such possibility although it would be extremely useful in competitions. I made two posts about pbds on codeforces to introduce them to community: https://codeforces.com/blog/entry/11080 and https://codeforces.com/blog/entry/13279. First one introduces structures in general and second one describes how to modify them so they support custom queries. Second one was not quite as popular, perhaps because it's not much easier to comprehend and remember concept than simply write something like cartesian tree on live contest. But the first one is pretty much alive, most recent comment was only 8 days ago. There was also another post (https://codeforces.com/blog/entry/60737) considering hash_map from pb_ds as a replacement for unordered_map since hash_map clearly outperform unordered_map. This one is also quite popular and well-known in competitive programming community. So speaking about "Do you actually use these containers?" I would say that I often use tree_order_statistics_node_update in competitions, and in general specifically tree_order_statistics_node_update and hash_map are pretty popular in competitive programming community. Deprecating policy based data structures will deal much pain to some competitors because problems in which it's possible to use pbds instead of custom balanced binary trees occur quite often and so now we'll have to implement bbst instead of using something out of the box. Not sure if you would consider this usage case as something "serious", but well, I was asked, so I answered. Regards, Oleksandr Kulkov
Re: RFC: Deprecate libstdc++ Policy-Based Data Structures
I hoped it would attach to https://gcc.gnu.org/ml/libstdc++/2019-05/msg00107.html but it didn't happen :( ср, 10 июл. 2019 г. в 01:39, Alexander Kulkov : > Hi there! I hope, this message will go to where it's expected to go, since > I'm not really familiar with e-mail threads. > > I was the one who brought > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81806 issue about > sub-optimal implementation of split function in pbds. The reason why I did > so is clearly described on this comment: > https://codeforces.com/blog/entry/10355?#comment-157883 > > So, a bit of story and context. Five years ago at codeforces.com > (competitive programming website) someone eventually pointed out that there > is order-statistics tree in SGI library. It turned out to be very useful in > competitions since it is quite common type of queries to count number of > elements less than k in set and unfortunately regular std::set doesn't > provide such possibility although it would be extremely useful in > competitions. > > I made two posts about pbds on codeforces to introduce them to community: > https://codeforces.com/blog/entry/11080 and > https://codeforces.com/blog/entry/13279. First one introduces structures > in general and second one describes how to modify them so they support > custom queries. Second one was not quite as popular, perhaps because it's > not much easier to comprehend and remember concept than simply write > something like cartesian tree on live contest. But the first one is pretty > much alive, most recent comment was only 8 days ago. > > There was also another post (https://codeforces.com/blog/entry/60737) > considering hash_map from pb_ds as a replacement for unordered_map since > hash_map clearly outperform unordered_map. This one is also quite popular > and well-known in competitive programming community. > > So speaking about "Do you actually use these containers?" I would say that > I often use tree_order_statistics_node_update in competitions, and in > general specifically tree_order_statistics_node_update and hash_map are > pretty popular in competitive programming community. > > Deprecating policy based data structures will deal much pain to some > competitors because problems in which it's possible to use pbds instead of > custom balanced binary trees occur quite often and so now we'll have to > implement bbst instead of using something out of the box. > > Not sure if you would consider this usage case as something "serious", but > well, I was asked, so I answered. > > Regards, > Oleksandr Kulkov >
g...@gcc.gnu.orgfXsXa
提供各种发票幵:1 3 6;922 275 95张【 有 】↓【3%-13%】【 増 】各【 发 】 【 稙 】种【 票 】【 税 】真【 幵 】 如果你不想 再收到该产品的推荐邮件, 请点击这里退订
Re: RFC: Deprecate libstdc++ Policy-Based Data Structures
On Tue, 9 Jul 2019 at 23:44, Alexander Kulkov wrote: > > I hoped it would attach to > https://gcc.gnu.org/ml/libstdc++/2019-05/msg00107.html but it didn't happen > :( The links to other messages in a thread only work within the same month, so you'll never get links between archived posts sent in different months.
