GCC 6.0 Status Report (2015-04-13)
Status == The trunk has branched for the GCC 5 release and is now open again for general development, stage 1. Please consider not disrupting it too much during the RC phase of GCC 5 so it is possible to test important fixes for 5.1 on it. Quality Data Priority # Change from last report --- --- P14- 3 P2 80+ 10 P39+- 0 P4 84+ 4 P5 35- 1 --- --- Total P1-P3 93+ 7 Total 212+ 10 Previous Report === https://gcc.gnu.org/ml/gcc/2015-03/msg00241.html The next report will be sent by Richard.
About adding OMPT into GNU's libgomp
Dear list, we're considering in adding OMPT [1] into the GNU OpenMP runtime. In brief, OMPT is a specification of an API for performance analysis tools such as TAU, Extrae and HPCToolkit. It mainly consists of calls that allow querying the state of the threads and callbacks to notify a tool of various OpenMP runtime events during an execution. Before we start, we'd like to know if there is someone else working on this direction. And if so, could we cooperate? If there's nobody working on that, how should we start? According to the GCC webpage, GCC 5 is open for regression and doc fixes only [2], so it could considered mature enough to be a starting point? Or should we start in GCC 4.9.x? That being said, I've seen that there's a copy of GCC in GitHub [3]; should we clone it, branch to GCC 5 (if that exists), and then work on a local branch until we can send you some patches? Or do you suggest a different work plan? Thank you very much [1] http://openmp.org/mp-documents/ompt-tr2.pdf [2] https://gcc.gnu.org/ml/gcc/2015-03/msg00241.html [3] https://github.com/gcc-mirror/gcc -- "People say nothing is impossible, but I do nothing everyday." - A. A. Milne
Re: About adding OMPT into GNU's libgomp
On 13 April 2015 at 10:14, Harald Servat wrote: > Before we start, we'd like to know if there is someone else working > on this direction. And if so, could we cooperate? I have no idea about this part of your mail. > If there's nobody working on that, how should we start? According to > the GCC webpage, GCC 5 is open for regression and doc fixes only [2], > so it could considered mature enough to be a starting point? Or should > we start in GCC 4.9.x? Generally all new development should be done on the trunk (which has now branched for GCC 6 because 5 is about to be released). New features should be added to the trunk, not a stable release branch, so doing work against a branch would just mean you have to port it to the trunk before it could be included upstream. So you should just work on the trunk in the first place. >That being said, I've seen that there's a copy > of GCC in GitHub [3]; The official Git mirror is documented at https://gcc.gnu.org/wiki/GitMirror
Re: About adding OMPT into GNU's libgomp
On Mon, Apr 13, 2015 at 11:14:56AM +0200, Harald Servat wrote: > we're considering in adding OMPT [1] into the GNU OpenMP runtime. In > brief, OMPT is a specification of an API for performance analysis > tools such as TAU, Extrae and HPCToolkit. It mainly consists of calls > that allow querying the state of the threads and callbacks to notify a > tool of various OpenMP runtime events during an execution. > > Before we start, we'd like to know if there is someone else working > on this direction. And if so, could we cooperate? Not to my knowledge. The only thing I'd like to say is that it would be nice if the changes didn't affect performance of non-analyzed/traced apps, so if changes to hot code paths are needed, they should be done with care, guarded with __builtin_expect and benchmarked that they don't slow normal OpenMP code paths significantly. > If there's nobody working on that, how should we start? According to > the GCC webpage, GCC 5 is open for regression and doc fixes only [2], > so it could considered mature enough to be a starting point? Or should > we start in GCC 4.9.x? That being said, I've seen that there's a copy > of GCC in GitHub [3]; should we clone it, branch to GCC 5 (if that > exists), and then work on a local branch until we can send you some > patches? Or do you suggest a different work plan? Please see what Jonathan wrote. You really should start working on a branch from the trunk, and work towards incorporating it into the trunk (stage1 of GCC 6, where the trunk is open for new features, closes usually in November). Jakub
Re: lto bootstrap fails.
On 04/11/2015 01:33 AM, Jan Hubicka wrote: On Fri, Apr 10, 2015 at 11:18:39AM -0400, Trevor Saunders wrote: On Fri, Apr 10, 2015 at 03:59:19PM +0200, Toon Moene wrote: Like this: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01086.html ODR rears its head again ... huh, why is c/c-lang.h getting included in files linked into cc1plus? that seems strange. readelf -wl cc1plus | grep c-lang.h doesn't show anything. I tried to reproduce it and my bootstrap passes with same options as Toon's The following patch ought to be able to tell the particular translation unit causing the conflict. [ Patch elided ] The patch applied cleanly - this is what I got as a result: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01450.html I hope this is useful. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: lto bootstrap fails.
On Mon, Apr 13, 2015 at 05:46:35PM +0200, Toon Moene wrote: > On 04/11/2015 01:33 AM, Jan Hubicka wrote: > > >>On Fri, Apr 10, 2015 at 11:18:39AM -0400, Trevor Saunders wrote: > >>>On Fri, Apr 10, 2015 at 03:59:19PM +0200, Toon Moene wrote: > Like this: > > https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01086.html > > ODR rears its head again ... > >>> > >>> huh, why is c/c-lang.h getting included in files linked into cc1plus? > >>> that seems strange. > >> > >>readelf -wl cc1plus | grep c-lang.h > >>doesn't show anything. > > > >I tried to reproduce it and my bootstrap passes with same options as Toon's > >The following patch ought to be able to tell the particular translation unit > >causing the conflict. > > [ Patch elided ] > > The patch applied cleanly - this is what I got as a result: > > https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01450.html > > I hope this is useful. ok, so the problem would seem to be graphite-scop-detection.c is including front end specific headers. Can you put a #error in cp-tree.h and recompile graphite-scop-detection.o to see what the path to including it is? Trev > > Kind regards, > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands > At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ > Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Re: lto bootstrap fails.
On Mon, Apr 13, 2015 at 05:46:35PM +0200, Toon Moene wrote: > [ Patch elided ] > > The patch applied cleanly - this is what I got as a result: > > https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01450.html > > I hope this is useful. Looks like the http://gcc.gnu.org/ml/gcc-patches/2014-08/msg01014.html patch is bad, including a header of one particular FE in the middle-end is just wrong. #define TYPE_PTR_P(NODE)\ (TREE_CODE (NODE) == POINTER_TYPE) #define TYPE_OBJ_P(NODE)\ (TREE_CODE (NODE) != REFERENCE_TYPE \ && !VOID_TYPE_P (NODE) \ && TREE_CODE (NODE) != FUNCTION_TYPE \ && TREE_CODE (NODE) != METHOD_TYPE) #define TYPE_PTROB_P(NODE) \ (TYPE_PTR_P (NODE) && TYPE_OBJ_P (TREE_TYPE (NODE))) is nothing that one couldn't just open-code in the middle-end, like if (TREE_CODE (scev) == SSA_NAME && TREE_CODE (TREE_TYPE (scev)) == POINTER_TYPE && TREE_CODE (TREE_TYPE (TREE_TYPE ((scev != REFERENCE_TYPE && !VOID_TYPE_P (TREE_TYPE (TREE_TYPE ((scev && TREE_CODE (TREE_TYPE (TREE_TYPE ((scev != FUNCTION_TYPE && TREE_CODE (TREE_TYPE (TREE_TYPE ((scev != METHOD_TYPE) but it is unclear why you want this check. For the middle-end, most pointer conversions are useless, so the distinction between pointers to objects and pointers to something different, might be long time lost. Don't you want just if (TREE_CODE (scev) == SSA_NAME && POINTER_TYPE_P (TREE_TYPE (scev))) instead (i.e. just give up on all pointers/references)? That is what the middle-end usually tests... Jakub
Re: xtensa PR65730
On Sat, Apr 11, 2015 at 12:43 AM, Max Filippov wrote: > On Sat, Apr 11, 2015 at 2:16 AM, augustine.sterl...@gmail.com > wrote: >> On Fri, Apr 10, 2015 at 1:18 PM, Max Filippov wrote: >>> How can we have a mulsi3 pattern that don't get expanded until it's >>> optimized, and only gets expanded to a call if it couldn't be optimized? >> >> I'm not completely sure, but I think you want to use OPTAB_LIB as you >> described above, and eliminate the TARGET_MUL32 condition in the >> pattern. > > In that case mull is emitted for normal uses of multiplication. You will have to play around with it then. One possibility is to catch the simple cases when the instruction is originally expanded. That is, generate shifts there. You won't get all of the performance you would from the optimizer, but simple cases like even powers of two one shouldn't be too bad.
Re: lto bootstrap fails.
On 04/13/2015 06:00 PM, Trevor Saunders wrote: On Mon, Apr 13, 2015 at 05:46:35PM +0200, Toon Moene wrote: On 04/11/2015 01:33 AM, Jan Hubicka wrote: On Fri, Apr 10, 2015 at 11:18:39AM -0400, Trevor Saunders wrote: On Fri, Apr 10, 2015 at 03:59:19PM +0200, Toon Moene wrote: Like this: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01086.html ODR rears its head again ... huh, why is c/c-lang.h getting included in files linked into cc1plus? that seems strange. readelf -wl cc1plus | grep c-lang.h doesn't show anything. I tried to reproduce it and my bootstrap passes with same options as Toon's The following patch ought to be able to tell the particular translation unit causing the conflict. [ Patch elided ] The patch applied cleanly - this is what I got as a result: https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01450.html I hope this is useful. ok, so the problem would seem to be graphite-scop-detection.c is including front end specific headers. Can you put a #error in cp-tree.h and recompile graphite-scop-detection.o to see what the path to including it is? Trev I get this: In file included from /home/toon/compilers/trunk/gcc/graphite-scop-detection.c:73:0: /home/toon/compilers/trunk/gcc/cp/cp-tree.h:52:2: error: #error #error ^ (See https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01493.html) -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news
Dejagnu-fu/pex-fu/diagnostics-fu needed to get LTO warnings right
> > The patch applied cleanly - this is what I got as a result: > > > > https://gcc.gnu.org/ml/gcc-testresults/2015-04/msg01450.html > > > > I hope this is useful. > > ok, so the problem would seem to be graphite-scop-detection.c is > including front end specific headers. Can you put a #error in cp-tree.h > and recompile graphite-scop-detection.o to see what the path to > including it is? I am happy the patch found its use. I guess I should revive it for this stage1 then, but IMO the extra note with no location info is ugly. I wondered if we don't want to update the debug machinery itself to output something like translation_unit:source_file:line:column tuples or transparently add notes as we do for inline chains? I.e. adding extra note after each warning with location saying "originating from this translation unit". I guess the translation_unit should be .o name instead of the soruce code, because one source code may be used to build multiple units (like in libgcc). Any idea how to get this done? I suppose we need to do this in a way IDEs are not overly confused. Another thing we probably want to solve this time is to teach PEX in libiberty to not redirect STDERR, so colors are preserved and warnings are not cached until very end of compilation. Does anyone have understanding why the caching is done? I looked at pex briefly but it is all greek to me. Final think we need to solve is dejagnu support for LTO warning checks. I would be also very happy to find volunteer for that Honza
is it time to mass change from .c to .cc in gcc/ ?
Hi! To be clear I only want to talk about gcc/**/*.c but *not* testsuite/ The Question of changing from .c to a more standard C++ file extension has come up a couple times. I believe its reasonable accurate to say the consensus is moderately in favor of doing this at some point. The biggest concern was of course being able to access pre rename history easily. I know git will either handle this by default or with an option depending on the command, and svn claims it can handle renames so we should be good on that front. The other question was if we should wait to do this at the same time as a reorganization of directory structure. That was back in august 2013, about a year and a half ago, and we haven't done it or really moved forward with a plan to do it. It seems to me that if we do this part now we can then deal with moving files into directories later piece by piece and not need to move everything at once. If we want to go ahead with renaming we should pick a time, I think some people have advanced the idea of doing it just after a branch, on the other hand last year we held off on the big gimple refactoring until after the branch had released a .1. thoughts? Trev
Re: [gcc libcc1] build_qualified_type for self-referencing/incomplete types
On Fri, 10 Apr 2015 14:31:45 +0200, Jan Kratochvil wrote:
> What is the recommended fix? I expect pointer to a declaration / opaque type
> which gets completed only when one references the 'p' field later?
It looks as it got fixed by:
-plugin_build_record_type (cc1_plugin::connection *self)
+plugin_build_record_type (cc1_plugin::connection *self, const char *name)
{
plugin_context *ctx = static_cast (self);
- return convert_out (ctx->preserve (make_node (RECORD_TYPE)));
+ tree node (make_node (RECORD_TYPE));
+ tree type_decl (build_decl (input_location, TYPE_DECL, get_identifier (name),
+ node));
+ TYPE_NAME (node) = type_decl;
+ TYPE_STUB_DECL (node) = type_decl;
+ C_TYPE_BEING_DEFINED (node) = 1;
+ return convert_out (ctx->preserve (node));
Jan
Re: GCC 6.0 Status Report (2015-04-13)
Hi Jakub, On Mon, 13 Apr 2015, Jakub Jelinek wrote: > Priority # Change from last report > --- --- > P14- 3 > P2 80+ 10 > P39+- 0 > P4 84+ 4 > P5 35- 1 > --- --- > Total P1-P3 93+ 7 > Total 212+ 10 These numbers are higher than the corresponding numbers for GCC 5.0.1 you shared at the same when intuitively I would have expected them to match. I _know_ it must be something obvious. What is that? Gerald
Connecting to gcc.gnu.org - keygen_fail
Hi, If I try to browse to pages like http://gcc.gnu.org/bugs/segfault.html I get the following Mozilla alert: > >An error occurred during a connection to gcc.gnu.org:443. Unable to generate >public/private key pair. (Error code: sec_error_keygen_fail) > I suspect this is because somebody changed from http to https or vice-versa without correcting everything. Advice, please? Jim Donovan 0428-609-208 -- Sent from Mutt on a 256MB Raspberry Pi
Re: GCC 6.0 Status Report (2015-04-13)
On Tue, Apr 14, 2015 at 08:25:58AM +0200, Gerald Pfeifer wrote: > Hi Jakub, > > On Mon, 13 Apr 2015, Jakub Jelinek wrote: > > Priority # Change from last report > > --- --- > > P14- 3 > > P2 80+ 10 > > P39+- 0 > > P4 84+ 4 > > P5 35- 1 > > --- --- > > Total P1-P3 93+ 7 > > Total 212+ 10 > > These numbers are higher than the corresponding numbers for GCC 5.0.1 > you shared at the same when intuitively I would have expected them to > match. > > I _know_ it must be something obvious. What is that? Some bugs during the GCC 5 bugfixing were just retargetted to 6.0 milestone only, e.g. if they have been somehow worked around for GCC 5 and need a better fix for GCC 6, or if we've realized we are not going to fix them in GCC 5 and defer the fix to GCC 6, etc. Jakub
