Re: is it time to mass change from .c to .cc in gcc/ ?

[Trevor Saunders]

On Tue, Apr 14, 2015 at 10:46:19AM +0200, Richard Biener wrote:
> On Tue, Apr 14, 2015 at 7:20 AM, Trevor Saunders  
> wrote:
> > 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?
> 
> I see no value in doing this but making branch maintainance awkward.

I think its mostly valuable to cause less confusion of new people, and
though it is a simpler thing every little thing can be the thing that
breaks the cammel's back.  Yes its not all that hard to configure
editors and what not to handle it properly, but every new person needs
to do it, and looking up configuration options takes time that can more
profitably be spent.

That said keeping backports as easy as possible is also certainly
important.  I'm curious why renames hurt doing backports, I'm pretty
confident git cherry-pick will handle it for you, and if you like patch
files for some reason I'd think its easy to fix up with sed though
running that for each backport by hand would get a little old.

Trev

> 
> Richard.
> 
> > Trev

gcc-5-20150414 is now available

[gccadmin]

Snapshot gcc-5-20150414 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/5-20150414/
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 222104

You'll find:

 gcc-5-20150414.tar.bz2   Complete GCC

  MD5=507c64c7f1ad23c5770df9fe497c327c
  SHA1=74328852ce7f1d6ed531278d70af5f53e78c3211

Diffs from 5-20150405 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.

Re: Fail to compile trunk

[Jonathan Wakely]

On 14 April 2015 at 17:19, Harald Servat wrote:
> Should we file a PR to request to integrate this patch? Or should I
> better follow Peter's suggestion to build gcc from a separate build
> directory?

You should always build in a separate directory, that's what all the
installation docs and the FAQ page on the wiki say.

Re: Fail to compile trunk

[Andreas Schwab]

This is already filed as PR65763.

Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Fail to compile trunk

[Harald Servat]

That patch solved the problem Andreas, thank you very much!

Should we file a PR to request to integrate this patch? Or should I
better follow Peter's suggestion to build gcc from a separate build
directory?

Best regards.

2015-04-14 18:14 GMT+02:00 Andreas Schwab :
> Please try this patch:
>
> diff --git a/libcc1/Makefile.am b/libcc1/Makefile.am
> index ecab22c..7a274b3 100644
> --- a/libcc1/Makefile.am
> +++ b/libcc1/Makefile.am
> @@ -17,7 +17,7 @@
>  ## .
>
>  ACLOCAL_AMFLAGS = -I .. -I ../config
> -gcc_build_dir = ../$(host_subdir)/gcc
> +gcc_build_dir = ../gcc
>  AM_CPPFLAGS = -I $(srcdir)/../include -I $(srcdir)/../libgcc \
> -I $(gcc_build_dir) -I$(srcdir)/../gcc \
> -I $(srcdir)/../gcc/c -I $(srcdir)/../gcc/c-family \
> diff --git a/libcc1/Makefile.in b/libcc1/Makefile.in
> index ce752c0..1916134 100644
> --- a/libcc1/Makefile.in
> +++ b/libcc1/Makefile.in
> @@ -245,7 +245,7 @@ top_builddir = @top_builddir@
>  top_srcdir = @top_srcdir@
>  visibility = @visibility@
>  ACLOCAL_AMFLAGS = -I .. -I ../config
> -gcc_build_dir = ../$(host_subdir)/gcc
> +gcc_build_dir = ../gcc
>  AM_CPPFLAGS = -I $(srcdir)/../include -I $(srcdir)/../libgcc \
> -I $(gcc_build_dir) -I$(srcdir)/../gcc \
> -I $(srcdir)/../gcc/c -I $(srcdir)/../gcc/c-family \
> --
> 2.3.5
>
>
> Andreas.
>
> --
> Andreas Schwab, SUSE Labs, sch...@suse.de
> GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
> "And now for something completely different."



-- 
"People say nothing is impossible, but I do nothing everyday."
- A. A. Milne

Re: Fail to compile trunk

[Harald Servat]

Ah, sorry for the misundersanding, I'll send the questions to gcc-help
from now on!

Still, thank you very much for the answer!

2015-04-14 18:14 GMT+02:00 Peter Bergner :
> On Tue, 2015-04-14 at 17:37 +0200, Harald Servat wrote:
>>   I'm trying to compile the GCC's trunk but I find out the following
>> error while compiling it. I've configured it such as
>
> This question is not appropriate for this mailing list, as this
> list is only for questions about gcc development.  You should continue
> this on the gcc-help mailing list.
>
>
>>   ./configure --prefix=/home/harald/pkg/gcc/git
>> --enable-languages=c,c++ --disable-multilib
>
> Building gcc within the GCC source tree is not supported.
> try creating an empty build directory and using:
>
>   /path/to/gcc/source/directory/configure 
>
> Peter
>
>



-- 
"People say nothing is impossible, but I do nothing everyday."
- A. A. Milne

Re: Fail to compile trunk

[Andreas Schwab]

Please try this patch:

diff --git a/libcc1/Makefile.am b/libcc1/Makefile.am
index ecab22c..7a274b3 100644
--- a/libcc1/Makefile.am
+++ b/libcc1/Makefile.am
@@ -17,7 +17,7 @@
 ## .
 
 ACLOCAL_AMFLAGS = -I .. -I ../config
-gcc_build_dir = ../$(host_subdir)/gcc
+gcc_build_dir = ../gcc
 AM_CPPFLAGS = -I $(srcdir)/../include -I $(srcdir)/../libgcc \
-I $(gcc_build_dir) -I$(srcdir)/../gcc \
-I $(srcdir)/../gcc/c -I $(srcdir)/../gcc/c-family \
diff --git a/libcc1/Makefile.in b/libcc1/Makefile.in
index ce752c0..1916134 100644
--- a/libcc1/Makefile.in
+++ b/libcc1/Makefile.in
@@ -245,7 +245,7 @@ top_builddir = @top_builddir@
 top_srcdir = @top_srcdir@
 visibility = @visibility@
 ACLOCAL_AMFLAGS = -I .. -I ../config
-gcc_build_dir = ../$(host_subdir)/gcc
+gcc_build_dir = ../gcc
 AM_CPPFLAGS = -I $(srcdir)/../include -I $(srcdir)/../libgcc \
-I $(gcc_build_dir) -I$(srcdir)/../gcc \
-I $(srcdir)/../gcc/c -I $(srcdir)/../gcc/c-family \
-- 
2.3.5


Andreas.

-- 
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Fail to compile trunk

[Peter Bergner]

On Tue, 2015-04-14 at 17:37 +0200, Harald Servat wrote:
>   I'm trying to compile the GCC's trunk but I find out the following
> error while compiling it. I've configured it such as

This question is not appropriate for this mailing list, as this
list is only for questions about gcc development.  You should continue
this on the gcc-help mailing list.


>   ./configure --prefix=/home/harald/pkg/gcc/git
> --enable-languages=c,c++ --disable-multilib

Building gcc within the GCC source tree is not supported.
try creating an empty build directory and using:

  /path/to/gcc/source/directory/configure 

Peter

Fail to compile trunk

[Harald Servat]

Hello,

  I'm trying to compile the GCC's trunk but I find out the following
error while compiling it. I've configured it such as

  ./configure --prefix=/home/harald/pkg/gcc/git
--enable-languages=c,c++ --disable-multilib

  and then run the make using the parallel build using 4 simultaneous
jobs (-j 4).

  There's a moment that the compilation fails due to

../.././libcc1/findcomp.cc:20:20: fatal error: config.h: No such file
or directory

  If I remove the #include, then there's another file that compilains...

../.././libcc1/../gcc/gcc-plugin.h:27:20: fatal error: config.h: No
such file or directory

  Interestingly, there are several config.h files. Has anyone found
this error before? What should I do to proceed with the compilation?

Thank you very much in advance.
-- 
"People say nothing is impossible, but I do nothing everyday."
- A. A. Milne

Re: is it time to mass change from .c to .cc in gcc/ ?

[Richard Biener]

On Tue, Apr 14, 2015 at 7:20 AM, Trevor Saunders  wrote:
> 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?

I see no value in doing this but making branch maintainance awkward.

Richard.

> Trev

Re: About adding OMPT into GNU's libgomp

[Harald Servat]

2015-04-13 12:53 GMT+02:00 Jakub Jelinek :
>
> 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.

  The OMPT's phisolosophy is to limit as much as possible its
overhead. Still, we'll follow your indications in order to keep the
overhead as low as possible.

>>   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).

  Thank you very much.

> Jakub



-- 
"People say nothing is impossible, but I do nothing everyday."
- A. A. Milne

Re: lto bootstrap fails.

[Richard Biener]

On Mon, 13 Apr 2015, Jakub Jelinek wrote:

> 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...

I am testing the following.

Richard.

2015-04-14  Richard Biener  

* graphite-scop-detection.c: Do not include cp/cp-tree.h.
(graphite_can_represent_scev): Use POINTER_TYPE_P.

Index: gcc/graphite-scop-detection.c
===
--- gcc/graphite-scop-detection.c   (revision 222076)
+++ gcc/graphite-scop-detection.c   (working copy)
@@ -70,7 +70,6 @@ along with GCC; see the file COPYING3.
 #include "tree-pass.h"
 #include "sese.h"
 #include "tree-ssa-propagate.h"
-#include "cp/cp-tree.h"
 
 #ifdef HAVE_isl
 #include "graphite-poly.h"
@@ -239,7 +238,7 @@ graphite_can_represent_scev (tree scev)
  the only nodes, which are disabled in case they are pointers to object
  types, but this can be changed.  */
 
-  if (TYPE_PTROB_P (TREE_TYPE (scev)) && TREE_CODE (scev) == SSA_NAME)
+  if (POINTER_TYPE_P (TREE_TYPE (scev)) && TREE_CODE (scev) == SSA_NAME)
 return false;
 
   switch (TREE_CODE (scev))

Re: Connecting to gcc.gnu.org - keygen_fail

[Mikhail Maltsev]

14.04.2015 9:28, j...@aptnsw.org.au writes:
> 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)
>>
> 
> Advice, please?
> 

The server replies with status code "307 Temporary Redirect" and
redirects to HTTPS version ("Location:
https://gcc.gnu.org/bugs/segfault.html";). Recent versions of Chrome and
Firefox (well, Iceweasel actually) handle it correctly. SSL certificate
is OK.

Though it's strange. Why not "301 Moved Permanently"?...

-- 
Regards,
Mikhail Maltsev