GCC Status Report (2015-11-15), Stage 3 in effect now

2015-11-15 Thread Jakub Jelinek
Status
==

The trunk is in Stage 3 now, which means it is open for general
bugfixing.

Patches posted early enough during Stage 1 and not yet fully reviewed
may still get in early in Stage 3.  Please make sure to ping them
soon enough.


Quality Data


Priority  #   Change from last report
---   ---
P13-   1
P2   84
P3  146+  16
P4   83
P5   32
---   ---
Total P1-P3 233+  15
Total   348+  15


Previous Report
===

https://gcc.gnu.org/ml/gcc/2015-11/msg00045.html


Re: [PATCH] PR fortran/58027,60993 -- BOZ in array constructor initialization expression

2015-11-15 Thread Paul Richard Thomas
Dear Steve,

OK for trunk.

Some of the code around the patch brings back fond memories;
especially the "scalarization"!

Thanks for the patch.

Paul

On 16 November 2015 at 03:22, Steve Kargl
 wrote:
> First, thanks to Dominiq for prodding me into looking at PR 58027.
>
> This was a fun ICE to track down!
>
> Most users have no idea what the Fortran standard requires for
> the parsing of a BOZ.  Consider the line of code
>
>   integer, parameter :: i(1) = (/ z'ff80' /)
>
> The naive user wants to assign a BOZ interpreted as a 32-bit entity
> to i(1) in an array constructor.  Ignoring the fact that a BOZ
> can't be used here, the BOZ is converted to an integer with the
> widest decimal exponential range.  On all(?) targets this is at
> least a 64-bit integer (known as INTEGER(8)).  To do the assignment
> gfortan inserts a __convert_i8_i4(), but it does so after any
> checking for an initialization expression.  So, when gfortran
> finally gets around to calling gfc_conv_array_initializer() to
> translates into tree-ssa form, gfc_conv_array_initializer() is not
> expecting a function and dies with an ICE.
>
> The fix is affected by calling gfc_check_init_expr() under
> appropriate conditions.  Because the __convert_* functions
> are sort of psuedo-intrinsic procedures, a check for an intrinsic
> procedure needs to be circumvented.
>
> Anyway, the patch has been built and tested on i386-*-freebsd
> and x86_64-*-freebsd.  OK to commit?
>
> 2015-11-15  Steven G. Kargl  
>
> PR fortran/58027
> PR fortran/60993
> * expr.c (gfc_check_init_expr): Prevent a redundant check when a
> __convert_* function was inserted into an array constructor.
> (gfc_check_assign_symbol): Check for an initialization expression
> when a __convert_* was inserted.
>
> 2015-11-15  Steven G. Kargl  
>
> PR fortran/58027
> PR fortran/60993
> * gfortran.dg/pr58027.f90: New test.
>
> --
> Steve



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx


Re: [PATCH][DJGPP][libgfortran] Do not use S_ISVTX for DJGPP in libfortran/intrinsic/chmod.c

2015-11-15 Thread Andris Pavenis

On 11/15/2015 09:19 PM, Andreas Schwab wrote:

Andris Pavenis  writes:


diff --git a/libgfortran/intrinsics/chmod.c b/libgfortran/intrinsics/chmod.c
index 1fffa3d..482a8a6 100644
--- a/libgfortran/intrinsics/chmod.c
+++ b/libgfortran/intrinsics/chmod.c
@@ -451,7 +451,7 @@ clause_done:
if ((ugo[2] || honor_umask) && !rwxXstugo[8])
  file_mode = (file_mode & ~(S_IROTH | S_IWOTH | S_IXOTH))
  | (new_mode & (S_IROTH | S_IWOTH | S_IXOTH));
-#ifndef __VXWORKS__
+#if !defined(__VXWORKS__) && !defined(__DJGPP__)

How about making that #ifdef S_ISVTX?

Andreas.


New patch attached. It is OK for DJGPP. Let us only hope that we have no some 
obscure target
for which S_ISVTX is present but is not a preprocessor macro. I have no way of 
checking for
all targets. From that point of view original patch was safer.

Andris

2015-11-16 Andris Pavenis 

* libgfortran/intrinsics/chmod.c: use S_ISVTX only when it is defined


>From 6fcff7721ce292df7889797f1380d5313e445c6f Mon Sep 17 00:00:00 2001
From: Andris Pavenis 
Date: Mon, 16 Nov 2015 06:33:14 +0200
Subject: [PATCH] libgfortran/intrinsics/chmod.c: use S_ISVTX only when it is
 defined

2015-11-16 Andris Pavenis 

* libgfortran/intrinsics/chmod.c: use S_ISVTX only when it is defined
---
 libgfortran/intrinsics/chmod.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libgfortran/intrinsics/chmod.c b/libgfortran/intrinsics/chmod.c
index 1fffa3d..f8eed17 100644
--- a/libgfortran/intrinsics/chmod.c
+++ b/libgfortran/intrinsics/chmod.c
@@ -451,7 +451,7 @@ clause_done:
 	if ((ugo[2] || honor_umask) && !rwxXstugo[8])
 	  file_mode = (file_mode & ~(S_IROTH | S_IWOTH | S_IXOTH))
 		  | (new_mode & (S_IROTH | S_IWOTH | S_IXOTH));
-#ifndef __VXWORKS__
+#ifdef  S_ISVTX
 	if (is_dir && rwxXstugo[5])
 	  file_mode |= S_ISVTX;
 	else if (!is_dir)
@@ -463,7 +463,7 @@ clause_done:
   {
 	/* Clear '-'.  */
 	file_mode &= ~new_mode;
-#if !defined( __MINGW32__) && !defined (__VXWORKS__)
+#ifdef  S_ISVTX
 	if (rwxXstugo[5] || !is_dir)
 	  file_mode &= ~S_ISVTX;
 #endif
@@ -471,7 +471,7 @@ clause_done:
 else if (set_mode == 3)
   {
 	file_mode |= new_mode;
-#if !defined (__MINGW32__) && !defined (__VXWORKS__)
+#ifdef  S_ISVTX
 	if (rwxXstugo[5] && is_dir)
 	  file_mode |= S_ISVTX;
 	else if (!is_dir)
-- 
2.4.3



[PATCH] PR 68366 - include emit-rtl.h in sdbout.c

2015-11-15 Thread tbsaunde+gcc
From: Trevor Saunders 

Some of the pa target macros rely on macros in emit-rtl.h and sdbout.c
uses some of those macros, which means that sdbout.c needs to include
emit-rtl.h.

this seems obvious, bootstrapped on x86_64-linux-gnu, and checked that a cross
to hppa-linux now builds so committing to trunk.

I noticed that gcc-order-headers already wanted to reorder includes so I didn't
worry about the oorder here, we can clean that up later easily anyway.

Trev


gcc/ChangeLog:

2015-11-15  Trevor Saunders  

PR middle-end/68366
* sdbout.c: Include emit-rtl.h and function.h.
---
 gcc/sdbout.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/gcc/sdbout.c b/gcc/sdbout.c
index f22bc7c..09fa06e 100644
--- a/gcc/sdbout.c
+++ b/gcc/sdbout.c
@@ -68,6 +68,8 @@ static GTY(()) bool sdbout_initialized;
 
 #include "rtl.h"
 #include "regs.h"
+#include "function.h"
+#include "emit-rtl.h"
 #include "flags.h"
 #include "insn-config.h"
 #include "reload.h"
-- 
2.1.4



[PATCH] PR fortran/58027,60993 -- BOZ in array constructor initialization expression

2015-11-15 Thread Steve Kargl
First, thanks to Dominiq for prodding me into looking at PR 58027.

This was a fun ICE to track down!

Most users have no idea what the Fortran standard requires for
the parsing of a BOZ.  Consider the line of code

  integer, parameter :: i(1) = (/ z'ff80' /)

The naive user wants to assign a BOZ interpreted as a 32-bit entity
to i(1) in an array constructor.  Ignoring the fact that a BOZ 
can't be used here, the BOZ is converted to an integer with the
widest decimal exponential range.  On all(?) targets this is at
least a 64-bit integer (known as INTEGER(8)).  To do the assignment
gfortan inserts a __convert_i8_i4(), but it does so after any
checking for an initialization expression.  So, when gfortran
finally gets around to calling gfc_conv_array_initializer() to
translates into tree-ssa form, gfc_conv_array_initializer() is not
expecting a function and dies with an ICE. 

The fix is affected by calling gfc_check_init_expr() under
appropriate conditions.  Because the __convert_* functions
are sort of psuedo-intrinsic procedures, a check for an intrinsic
procedure needs to be circumvented.

Anyway, the patch has been built and tested on i386-*-freebsd
and x86_64-*-freebsd.  OK to commit?

2015-11-15  Steven G. Kargl  

PR fortran/58027
PR fortran/60993
* expr.c (gfc_check_init_expr): Prevent a redundant check when a
__convert_* function was inserted into an array constructor.
(gfc_check_assign_symbol): Check for an initialization expression
when a __convert_* was inserted.

2015-11-15  Steven G. Kargl  

PR fortran/58027
PR fortran/60993
* gfortran.dg/pr58027.f90: New test.

-- 
Steve
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c	(revision 230397)
+++ gcc/fortran/expr.c	(working copy)
@@ -2471,7 +2471,8 @@ gfc_check_init_expr (gfc_expr *e)
   t = false;
 
   {
-	gfc_intrinsic_sym* isym;
+	bool conversion;
+	gfc_intrinsic_sym* isym = NULL;
 	gfc_symbol* sym = e->symtree->n.sym;
 
 	/* Simplify here the intrinsics from the IEEE_ARITHMETIC and
@@ -2490,8 +2491,14 @@ gfc_check_init_expr (gfc_expr *e)
 	  }
 	  }
 
-	if (!gfc_is_intrinsic (sym, 0, e->where)
-	|| (m = gfc_intrinsic_func_interface (e, 0)) != MATCH_YES)
+	/* If a conversion function, e.g., __convert_i8_i4, was inserted
+	   into an array constructor, we need to skip the error check here.
+   Conversion errors are  caught below in scalarize_intrinsic_call.  */
+	conversion = e->value.function.isym
+		   && (e->value.function.isym->conversion == 1);
+
+	if (!conversion && (!gfc_is_intrinsic (sym, 0, e->where)
+	|| (m = gfc_intrinsic_func_interface (e, 0)) != MATCH_YES))
 	  {
 	gfc_error ("Function %qs in initialization expression at %L "
 		   "must be an intrinsic function",
@@ -2518,7 +2525,7 @@ gfc_check_init_expr (gfc_expr *e)
 	   array argument.  */
 	isym = gfc_find_function (e->symtree->n.sym->name);
 	if (isym && isym->elemental
-	&& (t = scalarize_intrinsic_call(e)))
+	&& (t = scalarize_intrinsic_call (e)))
 	  break;
   }
 
@@ -3844,7 +3851,17 @@ gfc_check_assign_symbol (gfc_symbol *sym
   if (pointer || proc_pointer)
 r = gfc_check_pointer_assign (&lvalue, rvalue);
   else
-r = gfc_check_assign (&lvalue, rvalue, 1);
+{
+  /* If a conversion function, e.g., __convert_i8_i4, was inserted
+	 into an array constructor, we should check if it can be reduced
+	 as an initialization expression.  */
+  if (rvalue->expr_type == EXPR_FUNCTION
+	  && rvalue->value.function.isym
+	  && (rvalue->value.function.isym->conversion == 1))
+	gfc_check_init_expr (rvalue);
+
+  r = gfc_check_assign (&lvalue, rvalue, 1);
+}
 
   free (lvalue.symtree);
   free (lvalue.ref);
Index: gcc/testsuite/gfortran.dg/pr58027.f90
===
--- gcc/testsuite/gfortran.dg/pr58027.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr58027.f90	(working copy)
@@ -0,0 +1,5 @@
+! { dg-do compile }
+! PR fortran/58027
+integer, parameter :: i(1)=(/z'ff80'/) ! { dg-error "overflow converting" }
+print *, isclass
+end


Re: [PATCH] PR 68192 Export AIX TLS symbols

2015-11-15 Thread David Edelsohn
On Thu, Nov 5, 2015 at 10:53 PM, Alexandre Oliva  wrote:
> On Nov  5, 2015, Paolo Bonzini  wrote:
>
>> On 05/11/2015 17:28, David Edelsohn wrote:
>>> [Explicitly copying build maintainers.]
>>>
>>> Paolo and Alexandre,
>>>
>>> Could you review and help with this patch?
>>>
>>> TLS symbols in AIX display a new, different symbol type in nm output.
>>> Libtool explicitly creates a list of exported symbols for shared
>>> libraries using nm and does not recognize the new TLS symbols, so
>>> those symbols are not exported.
>>>
>>> This is a regression for TLS support on AIX.
>>>
>>> This patch updates libtool.m4 in GCC and configure for libstdc++-v3,
>>> libgfortran, and libgomp.  I would like to apply the patch to GCC
>>> while I simultaneously work with the Libtool community to correct the
>>> bug upstream.  I also would like to backport this to GCC 5.2 and GCC
>>> 4.9.x.
>
>> I think it's okay to wait for the patch to be upstream.
>
> *nod*.  The reason we want it upstream first is that we don't want a
> regression when someone updates the libtool version in GCC, now or in
> the future.
>
> It's such a simple patch that it should be really easy to get it into
> libtool upstream.

Ten days and still waiting for a response on libtool-patches.

- David


Another boot strap fix

2015-11-15 Thread Andi Kleen

Without this patch bootstrap errors out with

In file included from ./plugin-version.h:1:0,
 from ../../gcc/gcc/plugin.c:34:
./configargs.h:3:19: error: 'thread_model' defined but not used 
[-Werror=unused-variable]
 static const char thread_model[] = "posix";
   ^~~~

gcc/:
2015-11-15  Andi Kleen  

* configure.ac: Make configargs.h variables global.
Add name to structure.
* configure: dito.

diff --git a/gcc/configure b/gcc/configure
index d5f6dd4..1f68744 100755
--- a/gcc/configure
+++ b/gcc/configure
@@ -11794,10 +11794,11 @@ rm -f conftest.out
 
 cat > configargs.h < configargs.h <

Re: [PATCH] Fix obvious typo that breaks boot strap in delayed folding

2015-11-15 Thread Andi Kleen
On Sun, Nov 15, 2015 at 11:09:18PM +0100, Andreas Schwab wrote:
> Andi Kleen  writes:
> 
> > Fix the obivous typos. To to commit?
> 
> They are not typos.

Ok. What do you suggest to fix the error then?

-Andi


Re: [PATCH, 6/6] Remove first_pass_instance

2015-11-15 Thread Tom de Vries

[ Adding CC Le-Chun Wu ]

On 15/11/15 17:22, Tom de Vries wrote:

On 15/11/15 16:24, David Malcolm wrote:

On Sun, 2015-11-15 at 12:08 +0100, Tom de Vries wrote:

On 15/11/15 11:55, Tom de Vries wrote:

[ was: Re: [PATCH] Remove first_pass_instance from pass_vrp ]

This patch series removes first_pass_instance.

   1Remove first_pass_instance from pass_vrp
   2Remove first_pass_instance from pass_reassoc
   3Remove first_pass_instance from pass_dominator
   4Remove first_pass_instance from pass_object_sizes
   5Remove first_pass_instance from pass_ccp
   6Remove first_pass_instance

Bootstrapped and reg-tested on x86_64.

I will post the individual patches in reply to this email.

[ I won't post the first patch though. It was already posted here:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01701.html . ]


this patch removes the variable first_pass_instance.


Can we also get rid of TODO_mark_first_instance, or would that be a
followup?


TODO_mark_first_instance is used in position_pass, which AFAIU is used
in the plugin infrastructure. I'm not familiar with the plugin
infrastructure and concepts, so I can't say anything sensible about
whether we can get rid of the flag.

Thanks,
- Tom




Re: Broken link

2015-11-15 Thread Gerald Pfeifer
Hi William,

On Fri, 2 May 2014, William Leighton Dawson wrote:
> http://gcc.gnu.org/ml/gcc-patches/2008-10/msg01096.html
> 
> Gerald indicated a stale link for 'Guide for the use of the Ada
> programming language in high integrity systems'. The document is, in
> fact, not removed, just moved. It's new location is:
> 
> http://www.dit.upm.es/~str/ork/documents/adahis.pdf

thanks for the pointer and update!  Somehow it seems the new
address does not work, either: I am not getting a successful
response from that new server.  Probably a better idea to let
this rest (unless there is a really stable and working URL)?

Gerald


[wwwdocs] Bring release branch and release tags up-to-date in svn.html

2015-11-15 Thread Gerald Pfeifer
Generalize description of GCC branch names and simplify description
of GCC release tags.  Use more recent examples for both.

Committed.

Gerald

Index: svn.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v
retrieving revision 1.204
retrieving revision 1.206
diff -u -r1.204 -r1.206
--- svn.html14 Nov 2015 23:40:21 -  1.204
+++ svn.html15 Nov 2015 22:35:55 -  1.206
@@ -106,8 +106,8 @@
 svn co svn://gcc.gnu.org/svn/gcc/branches/branchname gcc
 
 
-(The release branch of the latest version of GCC x.y
-is named gcc-x_y-branch.)
+(The release branch of the GCC SERIES release series
+is named gcc-SERIES-branch.)
 
 
 Similarly a tag called tagname can be checked out with the
@@ -117,25 +117,21 @@
 svn co svn://gcc.gnu.org/svn/gcc/tags/tagname gcc
 
 
-(For recent releases, the SVN tag for GCC X.Y.Z
-is of the form
+(The SVN tag for GCC X.Y.Z is of the form
 gcc_X_Y_Z_release.)
 
 
 The following list provides some representative examples:
 
 
-  gcc-4_3-branch
-  gcc_4_3_4_release
-  gcc_4_3_3_release
-  gcc_4_3_2_release
-  gcc_4_3_1_release
-  gcc_4_3_0_release
+  gcc-5-branch
+  gcc-4_9-branch
+  gcc_4_9_3_release
+  gcc_4_9_2_release
+  gcc_4_9_1_release
+  gcc_4_9_0_release
+  gcc-4_8-branch
   gcc-3_4-branch
-  gcc_3_4_3_release
-  gcc_3_4_2_release
-  gcc_3_4_1_release
-  gcc_3_4_0_release
 
 
 To get a list of available branches, use the command:


[PATCH] Allow embedded timestamps by C/C++ macros to be set externally (2)

2015-11-15 Thread Dhole
Hi!

A while back I submitted a patch to the gcc-patches mailing list
to allow the embedded timestamps by C/C++ macros to be set externally
[0]. The attached patch addresses a comment from Joseph Myers : move the getenv calls into the gcc/ directory;
and it also provides better organization and style following the advice
and comments of the current Debian gcc package maintainer Matthias Klose
 (I'm sending the patch with him as co-author).

As a reminder for the motivation behind this patch, we are working on
the reproducible builds project which aims to provide users with a way
to reproduce bit-for-bit identical binary packages from the source and
build environment. The project involves Debian as well as several other
free software projects. See  for more
information.

Quoting from the original email:

> In order to do this, we need to make the build processes deterministic.
> As you can imagine, gcc is quite involved in producing Debian packages.
> One issue we encounter in many packages that fail to build reproducibly
> is the use of the __DATE__, __TIME__ C macros [1], right now we have 456
> affected packages that would need patching (either removing the macros,
> or passing a known date externally).

> A solution for toolchain packages that embed timestamps during the build
> process has been proposed for anyone interested and it consists of the
> following:
> The build environment can export an environment variable called
> SOURCE_DATE_EPOCH with a known timestamp in Unix epoch format (In our
> case, we use the last date of the package's debian changelog). The
> toolchain package running during the build can check if the exported
> variable is set and if so, instead of embedding the local date/time,
> embed the date/time from SOURCE_DATE_EPOCH.

The proposal to use SOURCE_DATE_EPOCH has now been gathered in a more
formal specification [2], so that any project can adhere to it to
achieve reproducible builds when dealing with timestamps.

> It would be very beneficial to our project (and other free software
> projects working on reproducible builds) if gcc supported this feature.

I'm attaching a patch for gcc-5.2.0 that enables this feature: it
modifies the behavior of the macros __DATE__ and __TIME__ when
SOURCE_DATE_EPOCH is exported.

Any comments, suggestions or other ideas to improve this patch are
mostly welcomed.

I'm willing to extend the documentation if the patch feels appropriate.

Thanks for your attention!


PD: Implementation details:

The error output in gcc/c-family/c-common.c (get_source_date_epoch) is
handled by an fprintf() to stderr followed by an exit (EXIT_FAILURE). I
am not sure this is the right approach for error handling, as I have
found many usages of the error() function in the code. If implemented
with error(), the output looks like this:

"""
$ SOURCE_DATE_EPOCH=123a123 g++ test_cpp.cpp -o test_cpp
In file included from :0:0:
/usr/include/stdc-predef.h:1:0: error: Environment variable
$SOURCE_DATE_EPOCH: Trailing garbage: a123

 /* Copyright (C) 1991-2014 Free Software Foundation, Inc.
 ^
"""

For this reason I used fprintf(stderr, "error message") to report the
errors.


[0] https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02210.html
[1] https://wiki.debian.org/ReproducibleBuilds/TimestampsFromCPPMacros
[2] https://reproducible-builds.org/specs/source-date-epoch/

Best regards,
Dhole
gcc/c-family/ChangeLog:

2015-10-10  Eduard Sanou  
Matthias Klose  
* gcc/c-family/c-common.c (get_source_date_epoch): New function, gets 
the environment variable SOURCE_DATE_EPOCH and parses it as long long
with error handling.
* gcc/c-family/c-common.h (get_source_date_epoch): Prototype.
* gcc/c-family/c-lex.c (c_lex_with_flags): set 
parse_in->source_date_epoch.

libcpp/ChangeLog:

2015-10-10  Eduard Sanou  
Matthias Klose  
* libcpp/include/cpplib.h (cpp_init_source_date_epoch): Prototype.
* libcpp/init.c (cpp_init_source_date_epoch): New function.
* libcpp/internal.h: Added source_date_epoch variable to struct
cpp_reader to store a reproducible date.
* libcpp/macro.c (_cpp_builtin_macro_text): Set pfile->date timestamp
from pfile->source_date_epoch instead of localtime if source_date_epoch
is set, to be used for __DATE__ and __TIME__ macros to help
reproducible builds.
diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
index 7fe7fa6..f795871 100644
--- a/gcc/c-family/c-common.c
+++ b/gcc/c-family/c-common.c
@@ -12318,4 +12318,49 @@ pointer_to_zero_sized_aggr_p (tree t)
   return (TYPE_SIZE (t) && integer_zerop (TYPE_SIZE (t)));
 }
 
+/* Read SOURCE_DATE_EPOCH from environment to have a deterministic
+   timestamp to replace embedded current dates to get reproducible
+   results. Returns -1 if SOURCE_DATE_EPOCH is not defined.  */
+long long
+get_source_date_epoch()
+{
+  char *source_date_epoch;
+  unsigned 

Re: [PATCH] Fix obvious typo that breaks boot strap in delayed folding

2015-11-15 Thread Andreas Schwab
Andi Kleen  writes:

> Fix the obivous typos. To to commit?

They are not typos.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


Re: [PATCH] Enable libstdc++ numeric conversions on Cygwin

2015-11-15 Thread Jennifer Yao
> I just finished running the testsuite on x86_64-pc-cygwin for
> Jonathan's latest patch and compared the results against an older
> (about two months old) run, and so far I'm not seeing any regressions.
> Granted, this is strictly preliminary; I'm currently re-running the
> testsuite on the up-to-date, unpatched build tree to see if there are
> any differences. I'll update when I have more information.

Finally finished testing the patch that was committed to trunk on Nov.
13. No regressions to report for x86_64-pc-cygwin.


Re: [PATCH] Fix PR ipa/68311

2015-11-15 Thread Christophe Lyon
On 15 November 2015 at 10:01, Martin Liška  wrote:
> On 11/14/2015 09:33 AM, Christophe Lyon wrote:
>> On 13 November 2015 at 13:17, Richard Biener  
>> wrote:
>>> On Fri, Nov 13, 2015 at 1:04 PM, Martin Liška  wrote:
 Hello.

 Following patch fixes PR68311, can regbootstrap on x86_64-linux-gnu.

 Ready for trunk?
>>>
>>> Please use
>>>
>>>  auto_vec  newclasses;
>>>
>>> as it gets you a stack allocation.  Also use quick_push as you know the 
>>> vector
>>> is large enough.
>>>
>>> Ok with that changes.
>>>
>>> Richard.
>>>
>> Hi,
>>
>> This patch broke the GCC build for armeb in libgfortran:
>> /tmp/9046893_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgfortran/generated/matmul_i4.c:
>> In function 'matmul_i4':
>> /tmp/9046893_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgfortran/generated/matmul_i4.c:79:1:
>> internal compiler error: in vectorizable_load, at tree-vect-s
>> tmts.c:6711
>>  matmul_i4 (gfc_array_i4 * const restrict retarray,
>>  ^
>>
>> 0xcff5d2 vectorizable_load
>> 
>> /tmp/9046893_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-vect-stmts.c:6711
>> 0xd06955 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*,
>> _slp_tree*, _slp_instance*)
>> 
>> /tmp/9046893_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-vect-stmts.c:8002
>> 0xd0ec21 vect_transform_loop(_loop_vec_info*)
>> 
>> /tmp/9046893_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-vect-loop.c:6793
>> 0xd317c9 vectorize_loops()
>> 
>> /tmp/9046893_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-vectorizer.c:533
>> Please submit a full bug report,
>
> Hi Christophe.
>
> It looks really strange that the ICE is caused by the patch. May I ask you 
> for creating a PR
> and attaching pre-processed source file, so that I can reproduce it with 
> cross-compiler?
>

Well, the build succeded before this commit and started to fail at
r230311 (this commit).

I've created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68367

Thanks

> Thank you,
> Martin
>
>>
>>
>>
 Thanks,
 Martin
>


Re: vector lightweight debug mode

2015-11-15 Thread François Dumont
On 12/10/2015 21:42, François Dumont wrote:
> On 07/10/2015 22:09, Jonathan Wakely wrote:
>> On 07/10/15 21:38 +0200, François Dumont wrote:
>>> Hi
>>>
>>>I completed vector assertion mode. Here is the result of the new
>>> test you will find in the attached patch.
>>>
>>> With debug mode:
>>> /home/fdt/dev/gcc/build_git/x86_64-unknown-linux-gnu/libstdc++-v3/include/debug/safe_iterator.h:375:
>>>
>>> Error: attempt to advance a dereferenceable (start-of-sequence)
>>> iterator 2
>>> steps, which falls outside its valid range.
>>>
>>> Objects involved in the operation:
>>>iterator @ 0x0x7fff1c346760 {
>>>  type =
>>> __gnu_debug::_Safe_iterator<__gnu_cxx::__normal_iterator>> std::__cxx1998::vector > >,
>>> std::__debug::vector > > (mutable iterator);
>>>  state = dereferenceable (start-of-sequence);
>>>  references sequence with type 'std::__debug::vector>> std::allocator >' @ 0x0x7fff1c3469a0
>>>}
>>> XFAIL: 23_containers/vector/debug/insert8_neg.cc execution test
>>>
>>>
>>> With assertion mode:
>>> /home/fdt/dev/gcc/build_git/x86_64-unknown-linux-gnu/libstdc++-v3/include/bits/stl_vector.h:1124:
>>>
>>> Error: invalid insert position outside container [begin, end) range.
>>>
>>> Objects involved in the operation:
>>>sequence "this" @ 0x0x7fff60b1f870 {
>>>  type = std::vector >;
>>>}
>>>iterator "__position" @ 0x0x7fff60b1f860 {
>>>  type = __gnu_cxx::__normal_iterator>> std::allocator > >;
>>>}
>>> XFAIL: 23_containers/vector/debug/insert8_neg.cc execution test
>> I still don't like the formatted output for the lightweight mode, it
>> adds a dependency on I/O support in libc, which is a problem for
>> embedded systems.
> I thought you just meant I/O dependency in terms of included headers.
> The __glibcxx_assert also has some I/O as in case of failure it calls:
>
>   inline void
>   __replacement_assert(const char* __file, int __line,
>const char* __function, const char* __condition)
>   {
> __builtin_printf("%s:%d: %s: Assertion '%s' failed.\n", __file, __line,
>  __function, __condition);
> __builtin_abort();
>   }
>
> but it is much more limited than the _GLIBCXX_DEBUG_VERIFY counterpart
> which is calling fprintf to send to stderr.
>
> So ok let's limit this mode to glibcxx_assert.
>
>> The idea was to just add really cheap checks and abort  :-(
>>
>> Have you compared codegen with and without assertion mode? How much
>> more code is added to member functions like operator[] that must be
>> inlined for good performance?  Is it likely to affect inlining
>> decisions?
>>
>> I suspect it will have a much bigger impact than if we just use
>> __builtin_abort() as I made it do originally.
> I think that impact on compiled code depends more on the assert
> condition than on the code executed when this assertion happens to be
> false. But I haven't check it and will try.
>
> In the attached patch I eventually:
> - Move assertion macros in debug/assertions.h, it sounds like the right
> place for those.
> - Complete implementation of assertion checks by using __valid_range
> function. All checks I can think of are now in place. I still need to
> compare with google branch.
>
> Note that for the latter, condition is still evaluated in O(1).
> __valid_range detects iterator issues without looping through them.
> __valid_range, by considering iterator category, also make those macros
> usable in any container.
>
> François
>
Here is a last version I think.

I completed the debug light mode by adding some check on iterator
ranges.

Even if check are light I made some changes to make sure that
internally vector is not using methods instrumented with those checks.
This is to make sure checks are not done several times. Doing so also
simplify normal mode especially when using insert range, there is no
need to check if parameters are integers or not.

I also introduce some __builtin_expect to make sure compiler will
prefer the best path.

I didn't manage to check result on generated code. I am pretty sure
there will be an impact, you can't run more code without impact. But
that is a known drawback of debug mode, light or not, we just need to
minimize it. Mostly by making sure that checks are done only once.

It would be great to have it for gcc 6.0. I am working on the same
for other containers.

François

diff --git a/libstdc++-v3/include/bits/stl_vector.h b/libstdc++-v3/include/bits/stl_vector.h
index 305d446..66b813d 100644
--- a/libstdc++-v3/include/bits/stl_vector.h
+++ b/libstdc++-v3/include/bits/stl_vector.h
@@ -63,6 +63,8 @@
 #include 
 #endif
 
+#include 
+
 namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
@@ -320,7 +322,8 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   vector(const vector& __x)
   : _Base(__x.size(),
 	_Alloc_traits::_S_select_on_copy(__x._M_get_Tp_allocator()))
-  { this->_M_impl._M_finish =
+  {
+	this->_M_impl._M_finish =
 	  std::__uninitialized

Re: [PATCH v4] SH FDPIC backend support

2015-11-15 Thread Rich Felker
On Sun, Nov 15, 2015 at 02:08:34PM +0900, Oleg Endo wrote:
> On Wed, 2015-11-11 at 09:56 -0500, Rich Felker wrote:
> 
> > Sorry, I don't really understand RTL well enough to make a code
> > snippet. What I want to express is that an insn "uses" (in the (use
> > ...) sense) a register (r12) conditionally depending on a runtime
> > option (TARGET_FDPIC).
> 
> As far as I know this is not possible.  It would require two variants
> of the same pattern, one with the use and another without the use.  

OK. That's exactly what we've got now.

> > Is this possible in the sh backend or does it need changes to
> > higher-level gcc code? (i.e. is it presently possible to make an insn
> > that conditionally clobbers different things rather than having to
> > make tons of different insns for each possible set of clobbers?)
> 
> This is basically the same as above ... it's not possible to
> conditionally construct/modify pattern descriptions in the .md. 
>  However, it's possible to modify the CALL_INSN_FUNCTION_USAGE field of
> call insns -- for some examples see 'grep -r CALL_INSN_FUNCTION_USAGE
> gcc/config/*'.  Also, it seems the SH backend doesn't make use of some
> existing libcall related parameters and target hooks/macros.  Maybe
> those could be helpful.

I'll take a look at this. Let me know if you turn up anything
interesting.

> > Another issue I've started looking at is how r12 is put in 
> > fixed_regs, which is conceptually wrong. Preliminary tests show that 
> > removing it from fixed_regs doesn't break and produces much better 
> > code -- r12 gets used as a temp register in functions that don't need 
> > it, and in one function that made multiple calls, the saving of 
> > initial r12 to a call-saved register even happened in the delay slot 
> > of the call. I've been discussing it with Alexander Monakov on IRC 
> > (#musl) and based on my understanding so far of how gcc works (which 
> > admittedly may be wrong) the current FDPIC code looks like it's 
> > written not to depend on r12 being 'fixed'. Also I think I'm pretty 
> > close to understanding how we could make the same improvements for 
> > non-FDPIC PIC codegen: instead loading r12 in the prologue, load a 
> > pseudo, then use that pseudo for GOT access and force it into r12 the 
> > same way FDPIC call code does for PLT calls. Does this sound correct?
> 
> Maybe TARGET_USE_PSEUDO_PIC_REG could be useful?

Yes. Is there any documentation on using it? I came across that but
couldn't figure out how it compares to just doing the pseudo yourself
in the target files. Is non-target-specific code affected by this?

Rich


[PATCH] Fix obvious typo that breaks boot strap in delayed folding

2015-11-15 Thread Andi Kleen

The recent merge of the delayed folding branch breaks boot strap with

../../gcc/gcc/cp/tree.c: In function 'tree_node* build_cplus_array_type(tree, 
tree)':
../../gcc/gcc/cp/tree.c:894:44: error: suggest parentheses around assignment 
used as truth value [-Werror=parentheses]
= TYPE_NEEDS_CONSTRUCTING (elt_type));
^

../../gcc/gcc/cp/tree.c:896:51: error: suggest parentheses around assignment 
used as truth value [-Werror=parentheses]
= TYPE_HAS_NONTRIVIAL_DESTRUCTOR (elt_type));


Fix the obivous typos. To to commit?

-Andi


diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index d2db31a..83643df 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -891,9 +891,9 @@ build_cplus_array_type (tree elt_type, tree index_type)
   /* Push these needs up to the ARRAY_TYPE so that initialization takes
  place more easily.  */
   bool needs_ctor = (TYPE_NEEDS_CONSTRUCTING (t)
-= TYPE_NEEDS_CONSTRUCTING (elt_type));
+== TYPE_NEEDS_CONSTRUCTING (elt_type));
   bool needs_dtor = (TYPE_HAS_NONTRIVIAL_DESTRUCTOR (t)
-= TYPE_HAS_NONTRIVIAL_DESTRUCTOR (elt_type));
+== TYPE_HAS_NONTRIVIAL_DESTRUCTOR (elt_type));
 
   if (!dependent && t == TYPE_MAIN_VARIANT (t)
   && !COMPLETE_TYPE_P (t) && COMPLETE_TYPE_P (elt_type))





Re: [PATCH][DJGPP][libgfortran] Do not use S_ISVTX for DJGPP in libfortran/intrinsic/chmod.c

2015-11-15 Thread Andreas Schwab
Andris Pavenis  writes:

> diff --git a/libgfortran/intrinsics/chmod.c b/libgfortran/intrinsics/chmod.c
> index 1fffa3d..482a8a6 100644
> --- a/libgfortran/intrinsics/chmod.c
> +++ b/libgfortran/intrinsics/chmod.c
> @@ -451,7 +451,7 @@ clause_done:
>   if ((ugo[2] || honor_umask) && !rwxXstugo[8])
> file_mode = (file_mode & ~(S_IROTH | S_IWOTH | S_IXOTH))
> | (new_mode & (S_IROTH | S_IWOTH | S_IXOTH));
> -#ifndef __VXWORKS__
> +#if !defined(__VXWORKS__) && !defined(__DJGPP__)

How about making that #ifdef S_ISVTX?

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."


Re: [PATCH, libstdc++-v3, DJGPP] Update error constants for DJGPP

2015-11-15 Thread Andris Pavenis

On 11/15/2015 08:56 PM, Andris Pavenis wrote:

Included patch updates error constants for DJGPP.

Andris

2015-11-15 Andris Pavenis 

* libstdc++-v3/config/os/djgpp/error_constants.h (std::errc): Update error 
constants for DJGPP


Sorry email addrss andris.pave...@iki.fi


[PATCH, libstdc++-v3, DJGPP] Update error constants for DJGPP

2015-11-15 Thread Andris Pavenis

Included patch updates error constants for DJGPP.

Andris

2015-11-15 Andris Pavenis 

* libstdc++-v3/config/os/djgpp/error_constants.h (std::errc): Update error 
constants for DJGPP

>From fd43935415eee35aaa2ece3d07b0814de4da70f7 Mon Sep 17 00:00:00 2001
From: Andris Pavenis 
Date: Sun, 15 Nov 2015 20:22:33 +0200
Subject: [PATCH] [DJGPP} libstdc++-v3/config/os/djgpp/error_constants.h:
 Update according to errno codes available for DJGPP

---
 libstdc++-v3/config/os/djgpp/error_constants.h | 99 +++---
 1 file changed, 75 insertions(+), 24 deletions(-)

diff --git a/libstdc++-v3/config/os/djgpp/error_constants.h b/libstdc++-v3/config/os/djgpp/error_constants.h
index 8e25aa0..21e4906 100644
--- a/libstdc++-v3/config/os/djgpp/error_constants.h
+++ b/libstdc++-v3/config/os/djgpp/error_constants.h
@@ -37,8 +37,6 @@ namespace std _GLIBCXX_VISIBILITY(default)
 {
 _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
-// Most of the commented-out error codes are socket-related and could be
-// replaced by Winsock WSA-prefixed equivalents.
   enum class errc
 {
 //address_family_not_supported = 		EAFNOSUPPORT,
@@ -49,13 +47,17 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   argument_out_of_domain = 			EDOM,
   bad_address = EFAULT,
   bad_file_descriptor = 			EBADF,
-//bad_message = EBADMSG,
+
+#ifdef _GLIBCXX_HAVE_EBADMSG
+  bad_message = EBADMSG,
+#endif
+
   broken_pipe = EPIPE,
 //connection_aborted = 			ECONNABORTED,
 //connection_already_in_progress = 		EALREADY,
 //connection_refused = 			ECONNREFUSED,
 //connection_reset = 			ECONNRESET,
-//cross_device_link = 			EXDEV,
+  cross_device_link = 			EXDEV,
 //destination_address_required = 		EDESTADDRREQ,
   device_or_resource_busy = 		EBUSY,
   directory_not_empty = 			ENOTEMPTY,
@@ -65,7 +67,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   filename_too_long = 			ENAMETOOLONG,
   function_not_supported = 			ENOSYS,
 //host_unreachable = 			EHOSTUNREACH,
-//identifier_removed = 			EIDRM,
+
+#ifdef _GLIBCXX_HAVE_EIDRM
+  identifier_removed = 			EIDRM,
+#endif
+
   illegal_byte_sequence = 			EILSEQ,
   inappropriate_io_control_operation = 	ENOTTY,
   interrupted = EINTR,
@@ -78,48 +84,93 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 //network_reset = ENETRESET,
 //network_unreachable = 			ENETUNREACH,
 //no_buffer_space = 			ENOBUFS,
-//no_child_process = 			ECHILD,
-//no_link = ENOLINK,
+  no_child_process = 			ECHILD,
+
+#ifdef _GLIBCXX_HAVE_ENOLINK
+  no_link = ENOLINK,
+#endif
+
   no_lock_available = 			ENOLCK,
-//no_message_available = 			ENODATA, 
+
+#ifdef _GLIBCXX_HAVE_ENODATA
+  no_message_available = 			ENODATA, 
+#endif
+
 //no_message = ENOMSG, 
 //no_protocol_option = 			ENOPROTOOPT,
-//no_space_on_device = 			ENOSPC,
-//no_stream_resources = 			ENOSR,
+  no_space_on_device = 			ENOSPC,
+
+#ifdef _GLIBCXX_HAVE_ENOSR
+  no_stream_resources = 			ENOSR,
+#endif
+
   no_such_device_or_address = 		ENXIO,
   no_such_device = ENODEV,
   no_such_file_or_directory = 		ENOENT,
   no_such_process = 			ESRCH,
   not_a_directory = 			ENOTDIR,
 //not_a_socket = ENOTSOCK,
-//not_a_stream = ENOSTR,
+
+#ifdef _GLIBCXX_HAVE_ENOSTR
+  not_a_stream = ENOSTR,
+#endif
+
 //not_connected = ENOTCONN,
   not_enough_memory = 			ENOMEM,
-//not_supported = ENOTSUP,
-//operation_canceled = 			ECANCELED,
+
+#ifdef _GLIBCXX_HAVE_ENOTSUP
+  not_supported = ENOTSUP,
+#endif
+
+#ifdef _GLIBCXX_HAVE_ECANCELED
+  operation_canceled = 			ECANCELED,
+#endif
+
 //operation_in_progress = 			EINPROGRESS,
-//operation_not_permitted = 		EPERM,
+  operation_not_permitted = 		EPERM,
 //operation_not_supported = 		EOPNOTSUPP,
 //operation_would_block = 			EWOULDBLOCK,
-//owner_dead = EOWNERDEAD,
+
+#ifdef _GLIBCXX_HAVE_EOWNERDEAD
+  owner_dead = EOWNERDEAD,
+#endif
+
   permission_denied = 			EACCES,
-//protocol_error = EPROTO,
+
+#ifdef _GLIBCXX_HAVE_EPROTO
+  protocol_error = EPROTO,
+#endif
+
 //protocol_not_supported = 			EPROTONOSUPPORT,
   read_only_file_system = 			EROFS,
   resource_deadlock_would_occur = 		EDEADLK,
   resource_unavailable_try_again = 		EAGAIN,
   result_out_of_range = 			ERANGE,
-//state_not_recoverable = 			ENOTRECOVERABLE,
-//stream_timeout = ETIME,
-//text_file_busy = ETXTBSY,
+
+#ifdef _GLIBCXX_HAVE_ENOTRECOVERABLE
+  state_not_recoverable = 			ENOTRECOVERABLE,
+#endif
+
+#ifdef _GLIBCXX_HAVE_ETIME
+  stream_timeout = ETIME,
+#endif
+
+#ifdef _GLIBCXX_HAVE_ETXTBSY
+  text_file_busy = ETXTBSY,
+#endif
+
 //timed_out = ETIMEDOUT,
   too_many_files_open_in_system = 		ENFILE,
   too_many_files_open = 			EMFILE,
-  too_many_links = EMLINK
- //   too_many_symbolic_link_levels =

[PATCH][DJGPP][libgfortran] Do not use S_ISVTX for DJGPP in libfortran/intrinsic/chmod.c

2015-11-15 Thread Andris Pavenis

DJGPP do not have S_ISVTX defined. Therefore its use should be avoided.
Attached patch updates existing preprocessor conditional constructions
not to use S_ISVTX also for DJGPP

Andris

2015-11-15 Andris Pavenis 

* libgfortran/intrinsics/chmod.c (chmod_internal): do not use S_ISVTX for DJGPP 
target


>From 09606704601c67d87ab69c0ee1da140b8f2d984d Mon Sep 17 00:00:00 2001
From: Andris Pavenis 
Date: Sat, 14 Nov 2015 19:37:36 +0200
Subject: [PATCH] [DJGPP] libgfortran/intrinsic/chmod.c: avoid using S_ISVTX
 for DJGPP

---
 libgfortran/intrinsics/chmod.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libgfortran/intrinsics/chmod.c b/libgfortran/intrinsics/chmod.c
index 1fffa3d..482a8a6 100644
--- a/libgfortran/intrinsics/chmod.c
+++ b/libgfortran/intrinsics/chmod.c
@@ -451,7 +451,7 @@ clause_done:
 	if ((ugo[2] || honor_umask) && !rwxXstugo[8])
 	  file_mode = (file_mode & ~(S_IROTH | S_IWOTH | S_IXOTH))
 		  | (new_mode & (S_IROTH | S_IWOTH | S_IXOTH));
-#ifndef __VXWORKS__
+#if !defined(__VXWORKS__) && !defined(__DJGPP__)
 	if (is_dir && rwxXstugo[5])
 	  file_mode |= S_ISVTX;
 	else if (!is_dir)
@@ -463,7 +463,7 @@ clause_done:
   {
 	/* Clear '-'.  */
 	file_mode &= ~new_mode;
-#if !defined( __MINGW32__) && !defined (__VXWORKS__)
+#if !defined( __MINGW32__) && !defined (__VXWORKS__) && !defined(__DJGPP__)
 	if (rwxXstugo[5] || !is_dir)
 	  file_mode &= ~S_ISVTX;
 #endif
@@ -471,7 +471,7 @@ clause_done:
 else if (set_mode == 3)
   {
 	file_mode |= new_mode;
-#if !defined (__MINGW32__) && !defined (__VXWORKS__)
+#if !defined (__MINGW32__) && !defined (__VXWORKS__) && !defined(__DJGPP__)
 	if (rwxXstugo[5] && is_dir)
 	  file_mode |= S_ISVTX;
 	else if (!is_dir)
-- 
2.4.3



Re: [PATCH,x86,FreeBSD] Update FreeBSD/i386 to i586

2015-11-15 Thread Andreas Tobler

On 15.11.15 10:52, Gerald Pfeifer wrote:

This is something I had first done and tested a while ago, but
apparently failed to submit.

It did not show in my running of the testsuite (bootstrap and
testing without regressions on i386-unknown-freebsd10.1), but
in some cases the use of i586 instructions actually avoided
issues for users.  And who is running i486 these days?

(And FreeBSD 5 has been out of support for many years; I guess
modern versions of GCC won't work there for completely different
reasons.)

Okay?


Ok.


And okay for GCC 5 after two weeks or so on trunk?


Ok.

Thank you!

Andreas


2015-11-15  Gerald Pfeifer  

* config/i386/freebsd.h (SUBTARGET32_DEFAULT_CPU): Change to i586.
Remove support for FreeBSD 5 and earlier.

Index: gcc/config/i386/freebsd.h
===
--- gcc/config/i386/freebsd.h   (revision 230394)
+++ gcc/config/i386/freebsd.h   (working copy)
@@ -121,10 +121,7 @@
  /* Static stack checking is supported by means of probes.  */
  #define STACK_CHECK_STATIC_BUILTIN 1

-/* Support for i386 has been removed from FreeBSD 6.0 onward.  */
-#if FBSD_MAJOR >= 6
-#define SUBTARGET32_DEFAULT_CPU "i486"
-#endif
+#define SUBTARGET32_DEFAULT_CPU "i586"

  #define TARGET_ASM_FILE_END file_end_indicate_exec_stack






Re: [PATCH] Enable libstdc++ numeric conversions on Cygwin

2015-11-15 Thread Christophe Lyon
On 15 November 2015 at 12:14, Jonathan Wakely  wrote:
> On 15/11/15 09:58 +0100, Christophe Lyon wrote:
>>
>> Ha, and my newlib copy is not very recent, it's from Oct 30th 2013:
>> maybe it's too old?
>
>
> The autoconf checks should handle old versions as well as new.
>
> The problem is I didn't change a defined(_GLIBCXX_USE_C99_WCHAR) to
> just test its value, rather than whether it's defined.
>
> As I added to include/bits/c++config on Friday:
>
> // N.B. these _GLIBCXX_USE_C99_XXX macros are defined unconditionally
> // so they should be tested with #if not with #ifdef.
>
> Fixed with this patch, committed to trunk.
>

Thanks, this does fix the build of aarch64*-none-elf.

The arm*-none-eabi ones are still failing, but for another reason now.
Lots of things have been committed in the past few days :-)


Re: [PATCH, 6/6] Remove first_pass_instance

2015-11-15 Thread Tom de Vries

On 15/11/15 16:24, David Malcolm wrote:

On Sun, 2015-11-15 at 12:08 +0100, Tom de Vries wrote:

On 15/11/15 11:55, Tom de Vries wrote:

[ was: Re: [PATCH] Remove first_pass_instance from pass_vrp ]

This patch series removes first_pass_instance.

   1Remove first_pass_instance from pass_vrp
   2Remove first_pass_instance from pass_reassoc
   3Remove first_pass_instance from pass_dominator
   4Remove first_pass_instance from pass_object_sizes
   5Remove first_pass_instance from pass_ccp
   6Remove first_pass_instance

Bootstrapped and reg-tested on x86_64.

I will post the individual patches in reply to this email.

[ I won't post the first patch though. It was already posted here:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01701.html . ]


this patch removes the variable first_pass_instance.


Can we also get rid of TODO_mark_first_instance, or would that be a
followup?


TODO_mark_first_instance is used in position_pass, which AFAIU is used 
in the plugin infrastructure. I'm not familiar with the plugin 
infrastructure and concepts, so I can't say anything sensible about 
whether we can get rid of the flag.


Thanks,
- Tom


Re: [PATCH, 6/6] Remove first_pass_instance

2015-11-15 Thread David Malcolm
On Sun, 2015-11-15 at 12:08 +0100, Tom de Vries wrote:
> On 15/11/15 11:55, Tom de Vries wrote:
> > [ was: Re: [PATCH] Remove first_pass_instance from pass_vrp ]
> >
> > This patch series removes first_pass_instance.
> >
> >   1Remove first_pass_instance from pass_vrp
> >   2Remove first_pass_instance from pass_reassoc
> >   3Remove first_pass_instance from pass_dominator
> >   4Remove first_pass_instance from pass_object_sizes
> >   5Remove first_pass_instance from pass_ccp
> >   6Remove first_pass_instance
> >
> > Bootstrapped and reg-tested on x86_64.
> >
> > I will post the individual patches in reply to this email.
> >
> > [ I won't post the first patch though. It was already posted here:
> > https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01701.html . ]
> 
> this patch removes the variable first_pass_instance.

Can we also get rid of TODO_mark_first_instance, or would that be a
followup?


> 
> Thanks,
> - Tom
> 
> differences between files attachment
> (0006-Remove-first_pass_instance.patch)
> Remove first_pass_instance
> 
> 2015-11-15  Tom de Vries  
> 
>   * passes.c (first_pass_instance): Remove variable.
>   (execute_todo): Remove setting of first_pass_instance.
>   * tree-pass.h (first_pass_instance): Remove declaration.
> 
> ---
>  gcc/passes.c| 4 
>  gcc/tree-pass.h | 6 --
>  2 files changed, 10 deletions(-)
> 
> diff --git a/gcc/passes.c b/gcc/passes.c
> index e634c5c..0e23dcb 100644
> --- a/gcc/passes.c
> +++ b/gcc/passes.c
> @@ -151,7 +151,6 @@ debug_pass (void)
>  
>  /* Global variables used to communicate with passes.  */
>  bool in_gimple_form;
> -bool first_pass_instance;
>  
> 
>  /* This is called from various places for FUNCTION_DECL, VAR_DECL,
> @@ -2005,9 +2004,6 @@ execute_todo (unsigned int flags)
>  
>timevar_push (TV_TODO);
>  
> -  /* Inform the pass whether it is the first time it is run.  */
> -  first_pass_instance = (flags & TODO_mark_first_instance) != 0;
> -
>statistics_fini_pass ();
>  
>if (flags)
> diff --git a/gcc/tree-pass.h b/gcc/tree-pass.h
> index d647e73..dcd2d5e 100644
> --- a/gcc/tree-pass.h
> +++ b/gcc/tree-pass.h
> @@ -629,12 +629,6 @@ extern void ipa_read_optimization_summaries (void);
>  extern void register_one_dump_file (opt_pass *);
>  extern bool function_called_by_processed_nodes_p (void);
>  
> -/* Set to true if the pass is called the first time during compilation of the
> -   current function.  Note that using this information in the optimization
> -   passes is considered not to be clean, and it should be avoided if
> -   possible.  */
> -extern bool first_pass_instance;
> -
>  /* Declare for plugins.  */
>  extern void do_per_function_toporder (void (*) (function *, void *), void *);
>  




Re: Ping: [Patch, fortran] Bug 68241 - [meta-bug] Deferred-length character - PRs50221, 68216, 63932, 66408, 67674 and 49954

2015-11-15 Thread Paul Richard Thomas
Dear Steve,

Thanks for the review.

Committed as revision 230396.

My diagnosis of the last problem that Dominique found is correct.
However, I have not succeeded in fixing it and so the patch was
committed as review. I'll just have to return to the problem this
evening.

Cheers

Paul

On 14 November 2015 at 21:10, Steve Kargl
 wrote:
> On Sat, Nov 14, 2015 at 07:25:29PM +0100, Paul Richard Thomas wrote:
>>
>> Following an email from Dominique to me, I think not. In the course of
>> fixing PR49954, I put right the setting of the descriptor dtype. Since
>> this gets passed to the IO runtime, I think that this is the reason
>> for the difference in behaviour.
>>
>> I think that another week of effort should put right gfortran's woes
>> with deferred characters. As well as concatenation problems that I
>> think I have fixed, parentheses cause instant death :-(
>>
>
> Hi Paul,
>
> I built and tested on both x86_64-*-freebsd and i386-*-freebsd.
> All tests passed.
>
> I read through the patch did not raise any red (or what
> the heck is he doing here) flags.
>
> OK to commit as this is a step in the right direction in
> dealing with deferred character issues.
>
> --
> Steve



-- 
Outside of a dog, a book is a man's best friend. Inside of a dog it's
too dark to read.

Groucho Marx


RE: [RFC] [PATCH V2]: RE: [RFC] [Patch] Relax tree-if-conv.c trap assumptions.

2015-11-15 Thread Kumar, Venkataramanan
Hi Richard  and Bernhard.

> -Original Message-
> From: Richard Biener [mailto:richard.guent...@gmail.com]
> Sent: Tuesday, November 10, 2015 5:33 PM
> To: Kumar, Venkataramanan
> Cc: Andrew Pinski; gcc-patches@gcc.gnu.org
> Subject: Re: [RFC] [PATCH V2]: RE: [RFC] [Patch] Relax tree-if-conv.c trap
> assumptions.
> 
> On Sat, Nov 7, 2015 at 12:41 PM, Kumar, Venkataramanan
>  wrote:
> > Hi Richard,
> >
> > I have now implemented storing of DR and references using hash maps.
> > Please find attached patch.
> >
> > As discussed, I am now storing the ref, DR  and baseref, DR pairs along with
> unconditional read/write information  in  hash tables while iterating over DR
> during its initialization.
> > Then during checking for possible traps for if-converting,  just check if 
> > the
> memory reference for a gimple statement is read/written unconditionally by
> querying the hash table instead of quadratic walk.
> >
> > Boot strapped and regression tested on x86_64.
> 
> @@ -592,137 +598,153 @@ struct ifc_dr {
> 
>/* -1 when not initialized, 0 when false, 1 when true.  */
>int rw_unconditionally;
> +
> +  tree ored_result;
> +
> 
> excess vertical space at the end.  A better name would be simply "predicate".
> 
> +  if (!exsist1)
> +{
> +  if (is_true_predicate (ca))
> +   {
> + DR_RW_UNCONDITIONALLY (a) = 1;
> +   }
> 
> -while (TREE_CODE (ref_base_a) == COMPONENT_REF
> -   || TREE_CODE (ref_base_a) == IMAGPART_EXPR
> -   || TREE_CODE (ref_base_a) == REALPART_EXPR)
> -  ref_base_a = TREE_OPERAND (ref_base_a, 0);
> +  IFC_DR (a)->ored_result = ca;
> +  *master_dr = a;
> + }
> +  else
> +{
> +  IFC_DR (*master_dr)->ored_result
> += fold_or_predicates
> +   (EXPR_LOCATION (IFC_DR (*master_dr)->ored_result),
> +ca, IFC_DR (*master_dr)->ored_result);
> 
> -while (TREE_CODE (ref_base_b) == COMPONENT_REF
> -   || TREE_CODE (ref_base_b) == IMAGPART_EXPR
> -   || TREE_CODE (ref_base_b) == REALPART_EXPR)
> -  ref_base_b = TREE_OPERAND (ref_base_b, 0);
> +  if (is_true_predicate (ca)
> + || is_true_predicate (IFC_DR (*master_dr)->ored_result))
> +   {
> + DR_RW_UNCONDITIONALLY (*master_dr) = 1;
> +   }
> +  }
> 
> please common the predicate handling from both cases, that is, do
> 
>if (is_true_predicate (IFC_DR (*master_dr)->ored_result))
> DR_RW_...
> 
> after the if.  Note no {}s around single stmts.
> 
> Likewise for the base_master_dr code.
> 
> +  if (!found)
> +   {
> + DR_WRITTEN_AT_LEAST_ONCE (a) =0;
> + DR_RW_UNCONDITIONALLY (a) = 0;
> + return false;
> 
> no need to update the flags on non-"master" DRs.
> 
> Please remove the 'found' variable and simply return 'true'
> whenever found.
> 
>  static bool
>  ifcvt_memrefs_wont_trap (gimple *stmt, vec refs)  {
> -  return write_memrefs_written_at_least_once (stmt, refs)
> -&& memrefs_read_or_written_unconditionally (stmt, refs);
> +  return memrefs_read_or_written_unconditionally (stmt, refs);
> 
> please simply inline memrefs_read_or_written_unconditionally here.
> 
> +  if (ref_DR_map)
> +delete ref_DR_map;
> +  ref_DR_map = NULL;
> +
> +  if (baseref_DR_map)
> +delete baseref_DR_map;
> + baseref_DR_map = NULL;
> 
> at this point the pointers will never be NULL.
> 
> Ok with those changes.

The attached patch addresses all the review comments and is rebased to current 
trunk.
GCC regression test and bootstrap passed.  

Wanted to check with you once before committing it to trunk.
Ok for trunk?

gcc/ChangeLog

2015-11-15  Venkataramanan  
* tree-if-conv.c  (ref_DR_map): Define.
(baseref_DR_map): Like wise
(struct ifc_dr): Add new tree predicate field.
(hash_memrefs_baserefs_and_store_DRs_read_written_info): New function.
(memrefs_read_or_written_unconditionally):  Use hash maps to query 
unconditional read/written information.
(write_memrefs_written_at_least_once): Remove.
(ifcvt_memrefs_wont_trap): Remove call to 
write_memrefs_written_at_least_once.
(if_convertible_loop_p_1):  Initialize hash maps and predicates
before hashing data references.
* tree-data-ref.h  (decl_binds_to_current_def_p): Declare .

gcc/testsuite/ChangeLog
2015-11-15  Venkataramanan  
* gcc.dg/tree-ssa/ifc-8.c:  Add new.


Regards,
Venkat.
 
> 
> Note the tree-hash-traits.h part is already committed.
> 
> 
> > gcc/ChangeLog
> >  2015-11-07  Venkataramanan  
> >
> > *tree-hash-traits.h (struct tree_operand_hash). Use compare_type
> and value_type.
> >   (equal_keys): Rename to equal and use compare_type and
> value_type.
> > * tree-if-conv.c (ref_DR_map): Define.
> >(baseref_DR_map): Like wise
> >(struct ifc_dr):  New tree predicate field.
> >(

Re: [PATCH] Enable libstdc++ numeric conversions on Cygwin

2015-11-15 Thread Jonathan Wakely

On 15/11/15 09:58 +0100, Christophe Lyon wrote:

Ha, and my newlib copy is not very recent, it's from Oct 30th 2013:
maybe it's too old?


The autoconf checks should handle old versions as well as new.

The problem is I didn't change a defined(_GLIBCXX_USE_C99_WCHAR) to
just test its value, rather than whether it's defined.

As I added to include/bits/c++config on Friday:

// N.B. these _GLIBCXX_USE_C99_XXX macros are defined unconditionally
// so they should be tested with #if not with #ifdef.

Fixed with this patch, committed to trunk.

commit 8c33b5d8510378148bdac7247fd99b1f70eec04f
Author: Jonathan Wakely 
Date:   Sun Nov 15 11:03:54 2015 +

PR libstdc++/68353 fix _GLIBCXX_USE_C99_WCHAR test

	PR libstdc++/68353
	* include/bits/basic_string.h: Test value of _GLIBCXX_USE_C99_WCHAR
	not whether it is defined.
	* include/ext/vstring.h: Likewise.

diff --git a/libstdc++-v3/include/bits/basic_string.h b/libstdc++-v3/include/bits/basic_string.h
index b3853cd..e7f965e 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -5503,7 +5503,7 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   }
 #endif // _GLIBCXX_USE_C99_STDIO
 
-#if defined(_GLIBCXX_USE_WCHAR_T) && defined(_GLIBCXX_USE_C99_WCHAR)
+#if defined(_GLIBCXX_USE_WCHAR_T) && _GLIBCXX_USE_C99_WCHAR
   inline int 
   stoi(const wstring& __str, size_t* __idx = 0, int __base = 10)
   { return __gnu_cxx::__stoa(&std::wcstol, "stoi", __str.c_str(),
diff --git a/libstdc++-v3/include/ext/vstring.h b/libstdc++-v3/include/ext/vstring.h
index 8732bd3..529e4f3 100644
--- a/libstdc++-v3/include/ext/vstring.h
+++ b/libstdc++-v3/include/ext/vstring.h
@@ -2794,7 +2794,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   }
 #endif // _GLIBCXX_USE_C99_STDIO
 
-#if defined(_GLIBCXX_USE_WCHAR_T) && defined(_GLIBCXX_USE_C99_WCHAR)
+#if defined(_GLIBCXX_USE_WCHAR_T) && _GLIBCXX_USE_C99_WCHAR
   inline int 
   stoi(const __wvstring& __str, std::size_t* __idx = 0, int __base = 10)
   { return __gnu_cxx::__stoa(&std::wcstol, "stoi", __str.c_str(),


[PATCH, 6/6] Remove first_pass_instance

2015-11-15 Thread Tom de Vries

On 15/11/15 11:55, Tom de Vries wrote:

[ was: Re: [PATCH] Remove first_pass_instance from pass_vrp ]

This patch series removes first_pass_instance.

  1Remove first_pass_instance from pass_vrp
  2Remove first_pass_instance from pass_reassoc
  3Remove first_pass_instance from pass_dominator
  4Remove first_pass_instance from pass_object_sizes
  5Remove first_pass_instance from pass_ccp
  6Remove first_pass_instance

Bootstrapped and reg-tested on x86_64.

I will post the individual patches in reply to this email.

[ I won't post the first patch though. It was already posted here:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01701.html . ]


this patch removes the variable first_pass_instance.

Thanks,
- Tom

Remove first_pass_instance

2015-11-15  Tom de Vries  

	* passes.c (first_pass_instance): Remove variable.
	(execute_todo): Remove setting of first_pass_instance.
	* tree-pass.h (first_pass_instance): Remove declaration.

---
 gcc/passes.c| 4 
 gcc/tree-pass.h | 6 --
 2 files changed, 10 deletions(-)

diff --git a/gcc/passes.c b/gcc/passes.c
index e634c5c..0e23dcb 100644
--- a/gcc/passes.c
+++ b/gcc/passes.c
@@ -151,7 +151,6 @@ debug_pass (void)
 
 /* Global variables used to communicate with passes.  */
 bool in_gimple_form;
-bool first_pass_instance;
 
 
 /* This is called from various places for FUNCTION_DECL, VAR_DECL,
@@ -2005,9 +2004,6 @@ execute_todo (unsigned int flags)
 
   timevar_push (TV_TODO);
 
-  /* Inform the pass whether it is the first time it is run.  */
-  first_pass_instance = (flags & TODO_mark_first_instance) != 0;
-
   statistics_fini_pass ();
 
   if (flags)
diff --git a/gcc/tree-pass.h b/gcc/tree-pass.h
index d647e73..dcd2d5e 100644
--- a/gcc/tree-pass.h
+++ b/gcc/tree-pass.h
@@ -629,12 +629,6 @@ extern void ipa_read_optimization_summaries (void);
 extern void register_one_dump_file (opt_pass *);
 extern bool function_called_by_processed_nodes_p (void);
 
-/* Set to true if the pass is called the first time during compilation of the
-   current function.  Note that using this information in the optimization
-   passes is considered not to be clean, and it should be avoided if
-   possible.  */
-extern bool first_pass_instance;
-
 /* Declare for plugins.  */
 extern void do_per_function_toporder (void (*) (function *, void *), void *);
 


[PATCH, 5/6] Remove first_pass_instance from pass_ccp

2015-11-15 Thread Tom de Vries

On 15/11/15 11:55, Tom de Vries wrote:

[ was: Re: [PATCH] Remove first_pass_instance from pass_vrp ]

This patch series removes first_pass_instance.

  1Remove first_pass_instance from pass_vrp
  2Remove first_pass_instance from pass_reassoc
  3Remove first_pass_instance from pass_dominator
  4Remove first_pass_instance from pass_object_sizes
  5Remove first_pass_instance from pass_ccp
  6Remove first_pass_instance

Bootstrapped and reg-tested on x86_64.

I will post the individual patches in reply to this email.

[ I won't post the first patch though. It was already posted here:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01701.html . ]


this patch removes first_pass_instance from pass_ccp.

Thanks,
- Tom

Remove first_pass_instance from pass_ccp

2015-11-15  Tom de Vries  

	* passes.def: Add arg to pass_ccp pass instantiation.
	* tree-ssa-ccp.c (ccp_finalize): Add param nonzero_p.  Use nonzero_p
	instead of first_pass_instance.
	(do_ssa_ccp): Add and handle param nonzero_p.
	(pass_ccp::pass_ccp): Initialize nonzero_p.
	(pass_ccp::set_pass_param): New member function.  Set nonzero_p.
	(pass_ccp::execute): Call do_ssa_ccp with extra arg.
	(pass_ccp::nonzero_p): New private member.

---
 gcc/passes.def | 10 ++
 gcc/tree-ssa-ccp.c | 27 +--
 2 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/gcc/passes.def b/gcc/passes.def
index 64883a7..17027786 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -78,7 +78,9 @@ along with GCC; see the file COPYING3.  If not see
   PUSH_INSERT_PASSES_WITHIN (pass_all_early_optimizations)
 	  NEXT_PASS (pass_remove_cgraph_callee_edges);
 	  NEXT_PASS (pass_object_sizes, true /* insert_min_max_p */);
-	  NEXT_PASS (pass_ccp);
+	  /* Don't record nonzero bits before IPA to avoid
+	 using too much memory.  */
+	  NEXT_PASS (pass_ccp, false /* nonzero_p */);
 	  /* After CCP we rewrite no longer addressed locals into SSA
 	 form if possible.  */
 	  NEXT_PASS (pass_forwprop);
@@ -157,7 +159,7 @@ along with GCC; see the file COPYING3.  If not see
   /* Initial scalar cleanups before alias computation.
 	 They ensure memory accesses are not indirect wherever possible.  */
   NEXT_PASS (pass_strip_predict_hints);
-  NEXT_PASS (pass_ccp);
+  NEXT_PASS (pass_ccp, true /* nonzero_p */);
   /* After CCP we rewrite no longer addressed locals into SSA
 	 form if possible.  */
   NEXT_PASS (pass_complete_unrolli);
@@ -209,7 +211,7 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_dce);
   NEXT_PASS (pass_forwprop);
   NEXT_PASS (pass_phiopt);
-  NEXT_PASS (pass_ccp);
+  NEXT_PASS (pass_ccp, true /* nonzero_p */);
   /* After CCP we rewrite no longer addressed locals into SSA
 	 form if possible.  */
   NEXT_PASS (pass_cse_sincos);
@@ -319,7 +321,7 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_lower_complex);
   NEXT_PASS (pass_lower_vector_ssa);
   /* Perform simple scalar cleanup which is constant/copy propagation.  */
-  NEXT_PASS (pass_ccp);
+  NEXT_PASS (pass_ccp, true /* nonzero_p */);
   NEXT_PASS (pass_object_sizes);
   /* Fold remaining builtins.  */
   NEXT_PASS (pass_fold_builtins);
diff --git a/gcc/tree-ssa-ccp.c b/gcc/tree-ssa-ccp.c
index d09fab1..b845a7b 100644
--- a/gcc/tree-ssa-ccp.c
+++ b/gcc/tree-ssa-ccp.c
@@ -886,12 +886,12 @@ do_dbg_cnt (void)
 
 
 /* Do final substitution of propagated values, cleanup the flowgraph and
-   free allocated storage.
+   free allocated storage.  If NONZERO_P, record nonzero bits.
 
Return TRUE when something was optimized.  */
 
 static bool
-ccp_finalize (void)
+ccp_finalize (bool nonzero_p)
 {
   bool something_changed;
   unsigned i;
@@ -910,9 +910,7 @@ ccp_finalize (void)
   if (!name
 	  || (!POINTER_TYPE_P (TREE_TYPE (name))
 	  && (!INTEGRAL_TYPE_P (TREE_TYPE (name))
-		  /* Don't record nonzero bits before IPA to avoid
-		 using too much memory.  */
-		  || first_pass_instance)))
+		  || !nonzero_p)))
 	continue;
 
   val = get_value (name);
@@ -2394,16 +2392,17 @@ ccp_visit_stmt (gimple *stmt, edge *taken_edge_p, tree *output_p)
 }
 
 
-/* Main entry point for SSA Conditional Constant Propagation.  */
+/* Main entry point for SSA Conditional Constant Propagation.  If NONZERO_P,
+   record nonzero bits.  */
 
 static unsigned int
-do_ssa_ccp (void)
+do_ssa_ccp (bool nonzero_p)
 {
   unsigned int todo = 0;
   calculate_dominance_info (CDI_DOMINATORS);
   ccp_initialize ();
   ssa_propagate (ccp_visit_stmt, ccp_visit_phi_node);
-  if (ccp_finalize ())
+  if (ccp_finalize (nonzero_p))
 todo = (TODO_cleanup_cfg | TODO_update_ssa);
   free_dominance_info (CDI_DOMINATORS);
   return todo;
@@ -2429,14 +2428,22 @@ class pass_ccp : public gimple_opt_pass
 {
 public:
   pass_ccp (gcc::context *ctxt)
-: gimple_opt_pass (pass_data_ccp, ctxt)
+: gimple_opt_pass (pass_da

[PATCH, 4/6] Remove first_pass_instance from pass_object_sizes

2015-11-15 Thread Tom de Vries

On 15/11/15 11:55, Tom de Vries wrote:

[ was: Re: [PATCH] Remove first_pass_instance from pass_vrp ]

This patch series removes first_pass_instance.

  1Remove first_pass_instance from pass_vrp
  2Remove first_pass_instance from pass_reassoc
  3Remove first_pass_instance from pass_dominator
  4Remove first_pass_instance from pass_object_sizes
  5Remove first_pass_instance from pass_ccp
  6Remove first_pass_instance

Bootstrapped and reg-tested on x86_64.

I will post the individual patches in reply to this email.

[ I won't post the first patch though. It was already posted here:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01701.html . ]


this patches removes first_pass_instance from pass_object_sizes.

Thanks,
- Tom

Remove first_pass_instance from pass_object_sizes

2015-11-15  Tom de Vries  

	* passes.def: Add arg to pass_object_sizes pass instantiation.
	* tree-object-size.c (pass_object_sizes::pass_object_sizes): Initialize
	insert_min_max_p.
	(pass_object_sizes::set_pass_param): New member function.  Set
	insert_min_max_p.
	(pass_object_sizes::insert_min_max_p): New private member.
	(pass_object_sizes::execute): Use insert_min_max_p instead of
	first_pass_instance.

---
 gcc/passes.def |  4 ++--
 gcc/tree-object-size.c | 14 +++---
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/gcc/passes.def b/gcc/passes.def
index d274a95..64883a7 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -77,7 +77,7 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_all_early_optimizations);
   PUSH_INSERT_PASSES_WITHIN (pass_all_early_optimizations)
 	  NEXT_PASS (pass_remove_cgraph_callee_edges);
-	  NEXT_PASS (pass_object_sizes);
+	  NEXT_PASS (pass_object_sizes, true /* insert_min_max_p */);
 	  NEXT_PASS (pass_ccp);
 	  /* After CCP we rewrite no longer addressed locals into SSA
 	 form if possible.  */
@@ -164,7 +164,7 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_backprop);
   NEXT_PASS (pass_phiprop);
   NEXT_PASS (pass_forwprop);
-  NEXT_PASS (pass_object_sizes);
+  NEXT_PASS (pass_object_sizes, false /* insert_min_max_p */);
   /* pass_build_alias is a dummy pass that ensures that we
 	 execute TODO_rebuild_alias at this point.  */
   NEXT_PASS (pass_build_alias);
diff --git a/gcc/tree-object-size.c b/gcc/tree-object-size.c
index fa3625c..459e65d 100644
--- a/gcc/tree-object-size.c
+++ b/gcc/tree-object-size.c
@@ -1217,13 +1217,21 @@ class pass_object_sizes : public gimple_opt_pass
 {
 public:
   pass_object_sizes (gcc::context *ctxt)
-: gimple_opt_pass (pass_data_object_sizes, ctxt)
+: gimple_opt_pass (pass_data_object_sizes, ctxt), insert_min_max_p (false)
   {}
 
   /* opt_pass methods: */
   opt_pass * clone () { return new pass_object_sizes (m_ctxt); }
+  void set_pass_param (unsigned int n, bool param)
+{
+  gcc_assert (n == 0);
+  insert_min_max_p = param;
+}
   virtual unsigned int execute (function *);
 
+ private:
+  /* Determines whether the pass instance creates MIN/MAX_EXPRs.  */
+  bool insert_min_max_p;
 }; // class pass_object_sizes
 
 /* Dummy valueize function.  */
@@ -1250,12 +1258,12 @@ pass_object_sizes::execute (function *fun)
 
 	  init_object_sizes ();
 
-	  /* In the first pass instance, only attempt to fold
+	  /* If insert_min_max_p, only attempt to fold
 	 __builtin_object_size (x, 1) and __builtin_object_size (x, 3),
 	 and rather than folding the builtin to the constant if any,
 	 create a MIN_EXPR or MAX_EXPR of the __builtin_object_size
 	 call result and the computed constant.  */
-	  if (first_pass_instance)
+	  if (insert_min_max_p)
 	{
 	  tree ost = gimple_call_arg (call, 1);
 	  if (tree_fits_uhwi_p (ost))


[PATCH, 3/6] Remove first_pass_instance from pass_dominator

2015-11-15 Thread Tom de Vries

On 15/11/15 11:55, Tom de Vries wrote:

[ was: Re: [PATCH] Remove first_pass_instance from pass_vrp ]

This patch series removes first_pass_instance.

  1Remove first_pass_instance from pass_vrp
  2Remove first_pass_instance from pass_reassoc
  3Remove first_pass_instance from pass_dominator
  4Remove first_pass_instance from pass_object_sizes
  5Remove first_pass_instance from pass_ccp
  6Remove first_pass_instance

Bootstrapped and reg-tested on x86_64.

I will post the individual patches in reply to this email.

[ I won't post the first patch though. It was already posted here:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01701.html . ]


this patch removes first_pass_instance from pass_dominator.

Thanks,
- Tom

Remove first_pass_instance from pass_dominator

2015-11-15  Tom de Vries  

	* passes.def: Add arg to pass_dominator pass instantiation.
	* tree-pass.h (first_pass_instance): Remove pass_dominator-related bit
	of comment.
	* tree-ssa-dom.c (pass_dominator::pass_dominator): Initialize
	may_peel_loop_headers_p.
	(pass_dominator::set_pass_param): New member function.  Set
	may_peel_loop_headers_p.
	(pass_dominator::may_peel_loop_headers_p): New private member.
	(pass_dominator::execute): Use may_peel_loop_headers_p instead of
	first_pass_instance.

---
 gcc/passes.def |  4 ++--
 gcc/tree-pass.h|  7 ++-
 gcc/tree-ssa-dom.c | 16 ++--
 3 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/gcc/passes.def b/gcc/passes.def
index 78fdf0f..d274a95 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -190,7 +190,7 @@ along with GCC; see the file COPYING3.  If not see
 	 propagations have already run, but before some more dead code
 	 is removed, and this place fits nicely.  Remember this when
 	 trying to move or duplicate pass_dominator somewhere earlier.  */
-  NEXT_PASS (pass_dominator);
+  NEXT_PASS (pass_dominator, true /* may_peel_loop_headers_p */);
   /* At this point the majority of const/copy propagations
 	 are exposed.  Go ahead and identify paths that should never
 	 be executed in a conforming program and isolate those paths.
@@ -279,7 +279,7 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_reassoc, false /* insert_powi_p */);
   NEXT_PASS (pass_strength_reduction);
   NEXT_PASS (pass_tracer);
-  NEXT_PASS (pass_dominator);
+  NEXT_PASS (pass_dominator, false /* may_peel_loop_headers_p */);
   NEXT_PASS (pass_strlen);
   NEXT_PASS (pass_vrp, false /* warn_array_bounds_p */);
   /* The only const/copy propagation opportunities left after
diff --git a/gcc/tree-pass.h b/gcc/tree-pass.h
index a672d52..d647e73 100644
--- a/gcc/tree-pass.h
+++ b/gcc/tree-pass.h
@@ -631,11 +631,8 @@ extern bool function_called_by_processed_nodes_p (void);
 
 /* Set to true if the pass is called the first time during compilation of the
current function.  Note that using this information in the optimization
-   passes is considered not to be clean, and it should be avoided if possible.
-   This flag is currently used to prevent loops from being peeled repeatedly
-   in jump threading; it will be removed once we preserve loop structures
-   throughout the compilation -- we will be able to mark the affected loops
-   directly in jump threading, and avoid peeling them next time.  */
+   passes is considered not to be clean, and it should be avoided if
+   possible.  */
 extern bool first_pass_instance;
 
 /* Declare for plugins.  */
diff --git a/gcc/tree-ssa-dom.c b/gcc/tree-ssa-dom.c
index 5cb2644..aeb726c 100644
--- a/gcc/tree-ssa-dom.c
+++ b/gcc/tree-ssa-dom.c
@@ -536,14 +536,26 @@ class pass_dominator : public gimple_opt_pass
 {
 public:
   pass_dominator (gcc::context *ctxt)
-: gimple_opt_pass (pass_data_dominator, ctxt)
+: gimple_opt_pass (pass_data_dominator, ctxt),
+  may_peel_loop_headers_p (false)
   {}
 
   /* opt_pass methods: */
   opt_pass * clone () { return new pass_dominator (m_ctxt); }
+  void set_pass_param (unsigned int n, bool param)
+{
+  gcc_assert (n == 0);
+  may_peel_loop_headers_p = param;
+}
   virtual bool gate (function *) { return flag_tree_dom != 0; }
   virtual unsigned int execute (function *);
 
+ private:
+  /* This flag is used to prevent loops from being peeled repeatedly in jump
+ threading; it will be removed once we preserve loop structures throughout
+ the compilation -- we will be able to mark the affected loops directly in
+ jump threading, and avoid peeling them next time.  */
+  bool may_peel_loop_headers_p;
 }; // class pass_dominator
 
 unsigned int
@@ -619,7 +631,7 @@ pass_dominator::execute (function *fun)
   free_all_edge_infos ();
 
   /* Thread jumps, creating duplicate blocks as needed.  */
-  cfg_altered |= thread_through_all_blocks (first_pass_instance);
+  cfg_altered |= thread_through_all_blocks (may_peel_loop_headers_p);
 
   if (cfg_altered)
 free_dominance_info (CDI

[PATCH, 2/6] Remove first_pass_instance from pass_reassoc

2015-11-15 Thread Tom de Vries

On 15/11/15 11:55, Tom de Vries wrote:

[ was: Re: [PATCH] Remove first_pass_instance from pass_vrp ]

This patch series removes first_pass_instance.

  1Remove first_pass_instance from pass_vrp
  2Remove first_pass_instance from pass_reassoc
  3Remove first_pass_instance from pass_dominator
  4Remove first_pass_instance from pass_object_sizes
  5Remove first_pass_instance from pass_ccp
  6Remove first_pass_instance

Bootstrapped and reg-tested on x86_64.

I will post the individual patches in reply to this email.

[ I won't post the first patch though. It was already posted here:
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01701.html . ]


this patch removes first_pass_instance from pass_reassoc.

Thanks,
- Tom

Remove first_pass_instance from pass_reassoc

2015-11-15  Tom de Vries  

	* passes.def: Add arg to pass_reassoc pass instantiation.
	* tree-ssa-reassoc.c (reassoc_insert_powi_p): New static variable.
	(acceptable_pow_call, reassociate_bb): Use reassoc_insert_powi_p instead
	of first_pass_instance.
	(execute_reassoc): Add and handle insert_powi_p parameter.
	(pass_reassoc::insert_powi_p): New private member.
	(pass_reassoc::pass_reassoc): Initialize insert_powi_p.
	(pass_reassoc::set_pass_param): New member function.  Set insert_powi_p.
	(pass_reassoc::execute): Call execute_reassoc with extra arg.

---
 gcc/passes.def |  4 ++--
 gcc/tree-ssa-reassoc.c | 28 ++--
 2 files changed, 24 insertions(+), 8 deletions(-)

diff --git a/gcc/passes.def b/gcc/passes.def
index 64c1fa1..78fdf0f 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -205,7 +205,7 @@ along with GCC; see the file COPYING3.  If not see
 	 opportunities.  */
   NEXT_PASS (pass_phi_only_cprop);
   NEXT_PASS (pass_dse);
-  NEXT_PASS (pass_reassoc);
+  NEXT_PASS (pass_reassoc, true /* insert_powi_p */);
   NEXT_PASS (pass_dce);
   NEXT_PASS (pass_forwprop);
   NEXT_PASS (pass_phiopt);
@@ -276,7 +276,7 @@ along with GCC; see the file COPYING3.  If not see
   NEXT_PASS (pass_lower_vector_ssa);
   NEXT_PASS (pass_split_paths);
   NEXT_PASS (pass_cse_reciprocals);
-  NEXT_PASS (pass_reassoc);
+  NEXT_PASS (pass_reassoc, false /* insert_powi_p */);
   NEXT_PASS (pass_strength_reduction);
   NEXT_PASS (pass_tracer);
   NEXT_PASS (pass_dominator);
diff --git a/gcc/tree-ssa-reassoc.c b/gcc/tree-ssa-reassoc.c
index a75290c..6b08a59 100644
--- a/gcc/tree-ssa-reassoc.c
+++ b/gcc/tree-ssa-reassoc.c
@@ -172,6 +172,9 @@ along with GCC; see the file COPYING3.  If not see
 destructive update for the associating op, and keep the destructive
 update together for vector sum reduction recognition.  */
 
+/* Enable insertion of __builtin_powi calls during execute_reassoc.  See
+   point 3a in the pass header comment.  */
+static bool reassoc_insert_powi_p;
 
 /* Statistics */
 static struct
@@ -3940,7 +3943,7 @@ acceptable_pow_call (gimple *stmt, tree *base, HOST_WIDE_INT *exponent)
   tree fndecl, arg1;
   REAL_VALUE_TYPE c, cint;
 
-  if (!first_pass_instance
+  if (!reassoc_insert_powi_p
   || !flag_unsafe_math_optimizations
   || !is_gimple_call (stmt)
   || !has_single_use (gimple_call_lhs (stmt)))
@@ -4856,7 +4859,7 @@ reassociate_bb (basic_block bb)
 	  if (rhs_code == MULT_EXPR)
 		attempt_builtin_copysign (&ops);
 
-	  if (first_pass_instance
+	  if (reassoc_insert_powi_p
 		  && rhs_code == MULT_EXPR
 		  && flag_unsafe_math_optimizations)
 		powi_result = attempt_builtin_powi (stmt, &ops);
@@ -5111,11 +5114,14 @@ fini_reassoc (void)
   loop_optimizer_finalize ();
 }
 
-/* Gate and execute functions for Reassociation.  */
+/* Gate and execute functions for Reassociation.  If INSERT_POWI_P, enable
+   insertion of __builtin_powi calls.  */
 
 static unsigned int
-execute_reassoc (void)
+execute_reassoc (bool insert_powi_p)
 {
+  reassoc_insert_powi_p = insert_powi_p;
+
   init_reassoc ();
 
   do_reassoc ();
@@ -5145,14 +5151,24 @@ class pass_reassoc : public gimple_opt_pass
 {
 public:
   pass_reassoc (gcc::context *ctxt)
-: gimple_opt_pass (pass_data_reassoc, ctxt)
+: gimple_opt_pass (pass_data_reassoc, ctxt), insert_powi_p (false)
   {}
 
   /* opt_pass methods: */
   opt_pass * clone () { return new pass_reassoc (m_ctxt); }
+  void set_pass_param (unsigned int n, bool param)
+{
+  gcc_assert (n == 0);
+  insert_powi_p = param;
+}
   virtual bool gate (function *) { return flag_tree_reassoc != 0; }
-  virtual unsigned int execute (function *) { return execute_reassoc (); }
+  virtual unsigned int execute (function *)
+{ return execute_reassoc (insert_powi_p); }
 
+ private:
+  /* Enable insertion of __builtin_powi calls during execute_reassoc.  See
+ point 3a in the pass header comment.  */
+  bool insert_powi_p;
 }; // class pass_reassoc
 
 } // anon namespace


[PATCH, 0/6] Remove first_pass_instance

2015-11-15 Thread Tom de Vries

[ was: Re: [PATCH] Remove first_pass_instance from pass_vrp ]

This patch series removes first_pass_instance.

 1  Remove first_pass_instance from pass_vrp
 2  Remove first_pass_instance from pass_reassoc
 3  Remove first_pass_instance from pass_dominator
 4  Remove first_pass_instance from pass_object_sizes
 5  Remove first_pass_instance from pass_ccp
 6  Remove first_pass_instance

Bootstrapped and reg-tested on x86_64.

I will post the individual patches in reply to this email.

[ I won't post the first patch though. It was already posted here: 
https://gcc.gnu.org/ml/gcc-patches/2015-11/msg01701.html . ]


Thanks,
- Tom


[PATCH,x86,FreeBSD] Update FreeBSD/i386 to i586

2015-11-15 Thread Gerald Pfeifer
This is something I had first done and tested a while ago, but
apparently failed to submit.

It did not show in my running of the testsuite (bootstrap and
testing without regressions on i386-unknown-freebsd10.1), but
in some cases the use of i586 instructions actually avoided
issues for users.  And who is running i486 these days?

(And FreeBSD 5 has been out of support for many years; I guess
modern versions of GCC won't work there for completely different
reasons.)

Okay?

And okay for GCC 5 after two weeks or so on trunk?

Gerald

2015-11-15  Gerald Pfeifer  

* config/i386/freebsd.h (SUBTARGET32_DEFAULT_CPU): Change to i586.
Remove support for FreeBSD 5 and earlier.

Index: gcc/config/i386/freebsd.h
===
--- gcc/config/i386/freebsd.h   (revision 230394)
+++ gcc/config/i386/freebsd.h   (working copy)
@@ -121,10 +121,7 @@
 /* Static stack checking is supported by means of probes.  */
 #define STACK_CHECK_STATIC_BUILTIN 1
 
-/* Support for i386 has been removed from FreeBSD 6.0 onward.  */
-#if FBSD_MAJOR >= 6
-#define SUBTARGET32_DEFAULT_CPU "i486"
-#endif
+#define SUBTARGET32_DEFAULT_CPU "i586"
 
 #define TARGET_ASM_FILE_END file_end_indicate_exec_stack
 


Re: [PATCH] Fix PR ipa/68311

2015-11-15 Thread Martin Liška
On 11/14/2015 09:33 AM, Christophe Lyon wrote:
> On 13 November 2015 at 13:17, Richard Biener  
> wrote:
>> On Fri, Nov 13, 2015 at 1:04 PM, Martin Liška  wrote:
>>> Hello.
>>>
>>> Following patch fixes PR68311, can regbootstrap on x86_64-linux-gnu.
>>>
>>> Ready for trunk?
>>
>> Please use
>>
>>  auto_vec  newclasses;
>>
>> as it gets you a stack allocation.  Also use quick_push as you know the 
>> vector
>> is large enough.
>>
>> Ok with that changes.
>>
>> Richard.
>>
> Hi,
> 
> This patch broke the GCC build for armeb in libgfortran:
> /tmp/9046893_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgfortran/generated/matmul_i4.c:
> In function 'matmul_i4':
> /tmp/9046893_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libgfortran/generated/matmul_i4.c:79:1:
> internal compiler error: in vectorizable_load, at tree-vect-s
> tmts.c:6711
>  matmul_i4 (gfc_array_i4 * const restrict retarray,
>  ^
> 
> 0xcff5d2 vectorizable_load
> 
> /tmp/9046893_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-vect-stmts.c:6711
> 0xd06955 vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*,
> _slp_tree*, _slp_instance*)
> 
> /tmp/9046893_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-vect-stmts.c:8002
> 0xd0ec21 vect_transform_loop(_loop_vec_info*)
> 
> /tmp/9046893_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-vect-loop.c:6793
> 0xd317c9 vectorize_loops()
> 
> /tmp/9046893_7.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/tree-vectorizer.c:533
> Please submit a full bug report,

Hi Christophe.

It looks really strange that the ICE is caused by the patch. May I ask you for 
creating a PR
and attaching pre-processed source file, so that I can reproduce it with 
cross-compiler?

Thank you,
Martin

> 
> 
> 
>>> Thanks,
>>> Martin



Re: [PATCH] Enable libstdc++ numeric conversions on Cygwin

2015-11-15 Thread Christophe Lyon
On 14 November 2015 at 17:32, Jonathan Wakely  wrote:
> On 14/11/15 09:37 +0100, Christophe Lyon wrote:
>>
>> Hi, this commit makes the GCC build to fail for targets using newlib
>> (I tested arm-none-eabi and aarch64-none-elf)
>>
>> I'm seeing errors such as:
>> In file included from
>>
>> /tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/string:52:0,
>> from
>>
>> /tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/bits/locale_classes.h:40,
>> from
>>
>> /tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/bits/ios_base.h:41,
>> from
>>
>> /tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/ios:42,
>> from
>>
>> /tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/istream:38,
>> from
>>
>> /tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/sstream:38,
>> from
>>
>> /tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/complex:45,
>> from
>>
>> /tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/ccomplex:38,
>> from
>>
>> /tmp/9122162_8.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/libstdc++-v3/include/precompiled/stdc++.h:52:
>>
>> /tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/bits/basic_string.h:
>> In function 'long long int std::__cxx11::stoll(const wstring&,
>> std::size_t*, int)':
>>
>> /tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/bits/basic_string.h:5524:31:
>> error: 'wcstoll' is not a member of 'std'
>>   { return __gnu_cxx::__stoa(&std::wcstoll, "stoll", __str.c_str(),
>>   ^
>
>
> This shouldn't be possible unless you're using --enable-cheaders=c
> because we have an autoconf test for wcstoll, and if it's found then
> it should get added to namespace std by .

I configure newlib with:
--enable-newlib-io-pos-args \
--enable-newlib-io-c99-formats \
--enable-newlib-io-long-long \
--enable-newlib-io-long-double \
--with-sysroot="${sysroot}"

Ha, and my newlib copy is not very recent, it's from Oct 30th 2013:
maybe it's too old?

>
> Could you let me know the output of:
>
> grep C_INCLUDE_DIR
> /tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/Makefile
>
C_INCLUDE_DIR = ${glibcxx_srcdir}/include/c_global
c_base_srcdir = $(C_INCLUDE_DIR)

> Or alternatively:
>
> ls -l
> /tmp/9122162_8.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64_be-none-elf/gcc3/aarch64_be-none-elf/libstdc++-v3/include/cwchar
it's a symlink to libstdc++-v3/include/c_global/cwchar in the srcdir

>


Re: [PATCH] gcc.c: new macro POST_LINK_SPECS to be able to add additional steps after linking

2015-11-15 Thread Andris Pavenis

On 11/13/2015 08:40 AM, Jeff Law wrote:

On 11/10/2015 11:16 AM, Andris Pavenis wrote:

One may need to execute extra steps after linking program. This is required
for example for DJGPP to run stubify.exe on file generated by linker.

The only way how to achieve was to use LINK_COMMAND_SPEC. It would be
much easier
and less error prone to use new macro POST_LINK_SPEC introduced in this
patch.

Andris

ChangeLog entry

2015 Nov 10 Andris Pavenis 

 * gcc.c: new macro POST_LINK_SPEC
 * doc/tm.texi.in: document POST_LINK_SPEC
 * doc/tm.texi: regenerate
Instaled with a better ChangeLog.  Presumably there's going to be a followup to simplify a bunch 
of hte djgpp configuration?


jeff



There are large number of changes in djgpp related configuration files accumulated over many years. 
Some cleanup and
verification whether all is still needed and and of course testing of both cross- and native 
compiler is required.


It would be rather difficult to split it into parts. I'll going to submit configuration changes for 
DJGPP
(gcc/config.host + gcc/config/i386/*djgpp*) in one large patch after cleanup and testing unless 
there are objections.


Therefore small small separate changes can be expected first.

Andris



[PATCH] Fix inconsistent use of integer types in gcc/lto-streamer-out.c

2015-11-15 Thread Andris Pavenis

This fixes use of pointers different unsigned integer types as function 
parameter.
Function prototype is (see gcc/tree-streamer.h):

bool streamer_tree_cache_lookup (struct streamer_tree_cache_d *, tree,
 unsigned *);

gcc/lto-streamer-out.c passes uint32_t int * as parameter to this method in 2 
places.
Current type unisgned is used elsewhere in the same file.

uint32_t is not guaranteed to be the same as unsigned (for DJGPP uint32_t is 
actually
unsigned long). That causes compile failure for DJGPP native build.

Andris

2015-11-15 Andris Pavenis 

* gcc/lto-streamer-out.c (write_global_references): Adjust integer type
  (lto_output_decl_state_refs): Likewise

>From 8962f5b60f3ea241634a5e50cda04dc17ebb1322 Mon Sep 17 00:00:00 2001
From: Andris Pavenis 
Date: Sun, 15 Nov 2015 09:57:24 +0200
Subject: [PATCH] lto-streamer-out.c: Fix inconsistent use unsigned integer
 types

* lto-streamer-out (write_global_references, lto_output_decl_state_streams): use integer
 type passed to streamer_tree_cache_lookup.
---
 gcc/lto-streamer-out.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/lto-streamer-out.c b/gcc/lto-streamer-out.c
index 11daf7a..7d008b5 100644
--- a/gcc/lto-streamer-out.c
+++ b/gcc/lto-streamer-out.c
@@ -2402,7 +2402,7 @@ write_global_references (struct output_block *ob,
 
   for (index = 0; index < size; index++)
 {
-  uint32_t slot_num;
+  unsigned slot_num;
 
   t = lto_tree_ref_encoder_get_tree (encoder, index);
   streamer_tree_cache_lookup (ob->writer_cache, t, &slot_num);
@@ -2437,7 +2437,7 @@ lto_output_decl_state_refs (struct output_block *ob,
 			struct lto_out_decl_state *state)
 {
   unsigned i;
-  uint32_t ref;
+  unsigned ref;
   tree decl;
 
   /* Write reference to FUNCTION_DECL.  If there is not function,
-- 
2.4.3



[wwwdocs] Mention SH FDPIC support

2015-11-15 Thread Oleg Endo
Hi,

I've just committed the attached patch to the GCC 6 changes page.

Cheers,
Oleg? sh_fdpic_wwwdocs.patch
Index: htdocs/gcc-6/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1.41
diff -u -r1.41 changes.html
--- htdocs/gcc-6/changes.html	14 Nov 2015 20:40:43 -	1.41
+++ htdocs/gcc-6/changes.html	15 Nov 2015 07:58:27 -
@@ -271,6 +271,10 @@
   
 Support for SH5 / SH64 has been declared obsolete and will be removed
 in future releases.
+
+Support for the FDPIC ABI has been added.  It can be enabled using the
+new -mfdpic target option and --enable-fdpic
+configure option.