Install of gcc-plugin-devel
Hi, we have to analyse a C++ code that show significant run time overhead through the scorep instrumentation. Therefore we want to use the compile time filtering to get reasonable results. If I understand correctly, scorep need the GCC plugin interface to have the compile time filtering and I have to install the gcc-plugin-development. Could you give me, please, the link to the gcc-plugin-development sources and the documentation to configure and install this package. We have a NEC-Cluster with Scientific Linux. Thank you and best regards, Tünde -- Tuende Erdei University of Stuttgart High Performance Computing Center, Nobelstrasse 19, 70569 Stuttgart phone: ++49-711-685-87237 fax: ++49-711-89238279 email: er...@hlrs.de url: http://www.hlrs.de/people/erdei
Re: Disable -std=c++17 "ISO C++1z does not allow dynamic exception specifications"?
On Tue, Feb 21, 2017 at 03:44:17PM +0100, Stephan Bergmann wrote: > There is no flag to suppress that error or demote it to a warning, is there? > Could be useful when adapting large code bases to C++17 incrementally. It is a warning in C++11/C++14 now, so compile with -std=c++14 and incrementally fix all those warnings, then switch over to -std=c++17? -std=c++17 also turns on P0012R1 (noexcept part of the typesystem), so not sure what would the deprecated dynamic exception specification mean together with that (we shouldn't be adding new mangling for the dynamic exception specification etc.). Jakub
Disable -std=c++17 "ISO C++1z does not allow dynamic exception specifications"?
There is no flag to suppress that error or demote it to a warning, is there? Could be useful when adapting large code bases to C++17 incrementally.
Re: Disable -std=c++17 "ISO C++1z does not allow dynamic exception specifications"?
On 21 February 2017 at 14:55, Jonathan Wakely wrote: > On 21 February 2017 at 14:51, Jakub Jelinek wrote: >> On Tue, Feb 21, 2017 at 03:44:17PM +0100, Stephan Bergmann wrote: >>> There is no flag to suppress that error or demote it to a warning, is there? >>> Could be useful when adapting large code bases to C++17 incrementally. >> >> It is a warning in C++11/C++14 now, so compile with -std=c++14 and >> incrementally fix all those warnings, then switch over to -std=c++17? >> >> -std=c++17 also turns on P0012R1 (noexcept part of the typesystem), so not >> sure what would the deprecated dynamic exception specification mean >> together with that (we shouldn't be adding new mangling for the dynamic >> exception specification etc.). > > We absolutely shouldn't add new mangling, but it could simply mean > noexcept(false). > > An exception specification that says "this can throw X, Y and Z" means > it can throw. > > I'm not proposing we do that though, I want dynamic exception > specifications to go away ASAP :-) I'm surprised who are trying C++17 s/who are/people who are/ > didn't get the memo 10+ years ago that they were broken and useless.
Re: Disable -std=c++17 "ISO C++1z does not allow dynamic exception specifications"?
On 21 February 2017 at 14:51, Jakub Jelinek wrote: > On Tue, Feb 21, 2017 at 03:44:17PM +0100, Stephan Bergmann wrote: >> There is no flag to suppress that error or demote it to a warning, is there? >> Could be useful when adapting large code bases to C++17 incrementally. > > It is a warning in C++11/C++14 now, so compile with -std=c++14 and > incrementally fix all those warnings, then switch over to -std=c++17? > > -std=c++17 also turns on P0012R1 (noexcept part of the typesystem), so not > sure what would the deprecated dynamic exception specification mean > together with that (we shouldn't be adding new mangling for the dynamic > exception specification etc.). We absolutely shouldn't add new mangling, but it could simply mean noexcept(false). An exception specification that says "this can throw X, Y and Z" means it can throw. I'm not proposing we do that though, I want dynamic exception specifications to go away ASAP :-) I'm surprised who are trying C++17 didn't get the memo 10+ years ago that they were broken and useless.
Re: Disable -std=c++17 "ISO C++1z does not allow dynamic exception specifications"?
On 02/21/2017 03:56 PM, Jonathan Wakely wrote: On 21 February 2017 at 14:55, Jonathan Wakely wrote: On 21 February 2017 at 14:51, Jakub Jelinek wrote: On Tue, Feb 21, 2017 at 03:44:17PM +0100, Stephan Bergmann wrote: There is no flag to suppress that error or demote it to a warning, is there? Could be useful when adapting large code bases to C++17 incrementally. It is a warning in C++11/C++14 now, so compile with -std=c++14 and incrementally fix all those warnings, then switch over to -std=c++17? Sure, cleaning up is trivial enough, when you have control over the code. -std=c++17 also turns on P0012R1 (noexcept part of the typesystem), so not sure what would the deprecated dynamic exception specification mean together with that (we shouldn't be adding new mangling for the dynamic exception specification etc.). We absolutely shouldn't add new mangling, but it could simply mean noexcept(false). An exception specification that says "this can throw X, Y and Z" means it can throw. I'm not proposing we do that though, I want dynamic exception specifications to go away ASAP :-) I'm surprised who are trying C++17 s/who are/people who are/ didn't get the memo 10+ years ago that they were broken and useless. The typical scenario being code base A #include'ing header files from code base B.
Re: Obsolete powerpc*-*-*spe*
On Mon, Feb 20, 2017 at 11:02 AM, Olivier Hainque wrote: > Hi David, > >> On Feb 17, 2017, at 01:10 , David Edelsohn wrote: >> >> This is not a new issue. The maintainer did not suddenly resign last >> week. There have been numerous efforts to reach out to the SPE >> community for over a *decade*, cajoling them to step up with >> maintenance for the port. I am glad that this notice of obsolescence >> has focused more attention on the long-standing problem. > > Would there be a minimum level of commitment you'd like > to get to accept leaving the port in (if not this, at least > that ...) ? Hi, Olivier There are three main areas that require attention: 1) Regular builds of the SPE configuration and regular GCC testsuite runs that are reported to the gcc-testsuite mailing list. 2) Timely reports of any regressions. 3) An active GCC developer who is the point of contact for the SPE port and submits patches for the port. None of us within IBM are experts on the SPE port. Someone from the SPE community is needed to help triage issues, debug problems and test patches that may affect the SPE port. With evidence of pro-active involvement from an SPE developer, the port does not have to be deprecated. The effort needs to be more that activity at GCC release cycle boundaries or an accelerated deprecation process will be proposed. Thanks, David
gcc-5-20170221 is now available
Snapshot gcc-5-20170221 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170221/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 245643 You'll find: gcc-5-20170221.tar.bz2 Complete GCC MD5=22d621fd0643b5c4b904f59eb30ca072 SHA1=70d12d62dc0fb1611c78f621d8884eb2aac0b11c Diffs from 5-20170214 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 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.
Argument Against Removal of GCJ
I have found GCJ to be one of the best methods for bootstrapping OpenJDK. No other method of adding support for new architectures that does not involve working closely with OpenJDK upstream is known to me. It is, of course, possible to add any architecture without the use of GCJ, but if one wishes to rely on as few prebuilt binaries as possible and minimize the chain of trust it is very hard to avoid the use of the GCC's java front end. I would also point out that removing GCJ would invalidate existing work on the GNU Classpath project. While most development now takes place on OpenJDK, Classpath provides a clean and minimalist implementation of core Java functionality, notably cryptographic interfaces. Besides my personal interest in GCJ and GNU Classpath I would like to reference Linus' opinion on removing code from the kernel, as I feel it is very applicable going forward. As long as one user benefits from some functionality he will not remove it. I suggest major GCC features should be treated the same way. "So if we actually have a user, and it works, then no, we're not removing EISA support. It's not like it hurts us or is in some way fundamentally broken, ..." - Linus. http: //marc dot info/?l=linux-kernel&m=142173458609850 Many of the users of GCJ and GNU Classpath do not know they are users and, even if they do know, are not aware that it is being considered for removal from the GCC nor aware of this mailing list. The GNU Java frontend is often the only usable "JRE" for poorly supported, old, or very new systems. Users of these systems need Java environments first produced with GCJ or GCJ itself. That the Java capabilities are not receiving development does not mean they are not useful, nor is that a good reason to remove them. Please allow GCJ to continue to exist in the GCC and provide what little maintenance it may require. It is entirely possible the frontend may experience renewed interest in the future. Respectfully, R0b0t1
