gcc-7/changes.html adjustments

[Richard Biener]

Committed.

Richard.

2017-02-28  Richard Biener  

* gcc-7/changes.html: Fix double value, adjust -Wstringop-overflow
default.

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.67
diff -r1.67 changes.html
460c460
<   return value value which indicates whether or not its output has
---
>   return value which indicates whether or not its output has
484c484
<   -Wstringop-overflow=1 is enabled by default.
---
>   -Wstringop-overflow=2 is enabled by default.

[wwwdocs] Handle /onlinedocs/ld

[Gerald Pfeifer]

>From the GCC documentation under /onlinedocs there is a link to 
/onlinedocs/ld.  That does not exist on gcc.gnu.org, so provide
a redirect to where it actually is available.

Committed.

Gerald

Index: .htaccess
===
RCS file: /cvs/gcc/wwwdocs/htdocs/.htaccess,v
retrieving revision 1.43
diff -u -r1.43 .htaccess
--- .htaccess   25 Feb 2017 16:15:01 -  1.43
+++ .htaccess   28 Feb 2017 07:47:51 -
@@ -70,6 +70,7 @@
 Redirect permanent /timeline.html  
https://gcc.gnu.org/releases.html#timeline
 Redirect permanent /web.html   https://gcc.gnu.org/about.html
 
+Redirect   /onlinedocs/ld  
http://sourceware.org/binutils/docs-2.27/ld
 Redirect   /onlinedocs/libc
https://www.gnu.org/software/libc/manual/html_node/
 Redirect   /onlinedocs/standards   
https://www.gnu.org/prep/standards/html_node/
 

[wwwdocs] adding ira-select branch description

[Vladimir Makarov]

Gerald reminded me that it would be nice to add ira-select branch 
description to svn.html.


Here is the patch I've committed.

Index: svn.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v
retrieving revision 1.215
diff -u -r1.215 svn.html
--- svn.html26 Feb 2017 10:26:14 - 1.215
+++ svn.html28 Feb 2017 02:43:38 -
@@ -246,6 +246,14 @@
   tag [incremental] in the subject line.


+  ira-select
+  This branch is for work on a new algorithm of calculations of
+  pseudo register classes. The new algorithm is based on choosing an
+  insn alternative first and then calculation of pseudo reg class
+  costs knowing the alternative.  The branch is maintained by Vladimir
+  Makarov mailto:vmaka...@redhat.com;>vmaka...@redhat.com.
+  
+
   libstdcxx_so_7-2-branch
   This branch carries all the C++ Runtime Library (libstdc++-v3) 
patches
   that break its abi. It will be merged into the trunk as soon as the 
decision

Re: Documentation patch related to PR42376

[Sandra Loosemore]

On 02/27/2017 03:26 PM, Gerald Pfeifer wrote:

On Mon, 11 Jan 2010, Martin Reinecke wrote:

thanks for applying the patch!
Unfortunately I just noticed some mistakes in my wording :(
Currently the sentence says
"code [...] may run significantly slower [...] than they did [...]"
I'm not a native speaker, but I guess it would be more correct
to write
"code [...] may run significantly more slowly [...] than it did [...]"


I realized that we did not actually update this back then, and
will admit that "significantly more slowly" feels less natural
than "significantly slower" to me, but then I am not a native
speaker either. ;-)

Sandra, what is your take on the patch below?


E  I would have written "more slowly" (since this is an adverb 
modifying "run"), but apparently both usages are correct.


https://www.grammarly.com/answers/questions/79959-comparing-with-adverbs/

-Sandra

Re: [PATCH] rs6000: float128 on BE and 32-bit

[Michael Meissner]

On Mon, Feb 13, 2017 at 10:20:48PM +, Segher Boessenkool wrote:
> This fixes float128 on BE and on 32-bit.
> 
> The configure tests need to use -mabi=altivec for 32-bit, since it is
> not the default there.  That also enables the "vector" keyword, used by
> the tests.  To do this it temporarily adds a few flags to the CFLAGS
> variable.
> 
> It also fixes a syntax error in the libgcc_cv_powerpc_float128_hw test
> (the function name was missing in the function declaration).
> 
> Regenerating config.in (via autoreconf) removed the duplicate definition
> of HAVE_SOLARIS_CRTS.
> 
> Finally, this adds a "-mfloat128-hardware requires -m64" test to
> rs6000.c: all the current patterns need 64-bit registers.  Maybe we'll
> want to add float128 hardware support to 32-bit some day, but certainly
> not today.
> 
> Tested on powerpc64-linux {-m32,-m64} so far.  I see I also need to
> update some code comments, ugh.

This patch fixes problems with float128.  Thanks for doing it.  I verified that
float128-hw.o is now built, and when I compile code with -mcpu=power8 and run
it on the power9 simulator it correctly switches __{add,sub,mul,div}kf3 to use
the hardware instructions.

Yeah, if there is a demand for -mfloat128-hardware -m32, we could do it, but
for now I think it is best to require 64-bit.

-- 
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797

Re: [PATCH] Remove x86 pcommit instruction

[Gerald Pfeifer]

Hi Andrew,

On Mon, 27 Feb 2017, Andrew Senkevich wrote:
>> +Support for the > +
>> href="https://software.intel.com/en-us/blogs/2016/09/12/deprecate-pcommit-instruction;>deprecated
>> +pcommit instruction has been removed.
> Could you please add the same statement for gcc-7 changes?

this never was part of a GCC 7-based release, and on top of that
we explicitly noted it's removal for both GCC 5 and GCC 6, so I
don't think this is necessary.  In fact, it would be even confusing?

Gerald

Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.

[Gerald Pfeifer]

Hi Martin,

at first I was surprised to see two suggestions from -- until I
realized those came from the two (Martins) of you. ;-)

On Mon, 27 Feb 2017, Martin Jambor wrote:
> on top of your patch, I would like to propose the following.  What do 
> you think?
> 
> Index: changes.html
> ===
> +  -Os).  This optimization and its option supersede
> +  interprocedural alignment propagation of gcc 6, and therefore the
> +  option -fipa-cp-alignment is now deprecated and
> +  ignored.

Make it "GCC 6" (all uppercase) and consider just saying "This
supersedes" or "This optimization supersedes", and I'll think I
like it. :-)

Thanks,
Gerald

Re: [wwwdocs] Update changes.html for LTO and IPA

[Gerald Pfeifer]

On Wed, 20 Jan 2016, Jan Hubicka wrote:
> this is updated patch.  I tried to explain better the situation WRT
> incremental linking.

Thank you, Jan.  I had a couple of editorial changes on top of
this, which I finally managed to commit.  (See the patch below.)

And one question: "declaration linking" is used in the description
of Link-time optimization improvements, alas that string does not 
appear anywhere in either the source tree or documentation?

On Wed, 3 Feb 2016, Jonathan Wakely wrote:
> s/of C++ methods/in C++ member functions/

This one got changed only partially in the patch applied last year, 
and I have adjusted this now to read "in C++ member functions" as 
opposed to "of C++ member functions".

Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
retrieving revision 1.95
diff -u -r1.95 changes.html
--- changes.html25 Feb 2017 17:46:38 -  1.95
+++ changes.html27 Feb 2017 22:29:33 -
@@ -59,12 +59,12 @@
on higher-level C++ programs. Programs doing invalid type punning
of pointer types may now need -fno-strict-aliasing
to work correctly.
-Alias analysis now correctly supports weakref and
-   alias attributes. This makes it possible to access
+Alias analysis now correctly supports the weakref and
+   alias attributes. This allows accessing
both a variable and its alias in one translation unit which is common
with link-time optimization.
 Value range propagation now assumes that the this pointer
-   of C++ member functions is non-null.  This eliminates
+   in C++ member functions is non-null.  This eliminates
common null pointer checks
but also breaks some non-conforming code-bases (such as Qt-5, Chromium,
KDevelop). As a temporary work-around
@@ -74,7 +74,8 @@
 
   warning and error attributes are now
  correctly preserved by declaration linking and thus
- -D_FORTIFY_SOURCE=2 is now supported with 
-flto.
+ -D_FORTIFY_SOURCE=2 is now supported with
+ -flto.
   Type merging was fixed to handle C and Fortran interoperability
  rules as defined by the Fortran 2008 language standard.
  
@@ -83,10 +84,10 @@
  char is scalar.
  INTEGER(KIND=C_SIGNED_CHAR) should be used instead.
  In general, this inter-operability cannot be implemented, for
- example, on targets where function passing conventions of arrays
- differs from scalars.
-  More type information is now preserved at link time reducing
- the loss of accuracy of the type based alias analysis compared
+ example on targets where the argument passing convention for
+ arrays differs from scalars.
+  More type information is now preserved at link time, reducing
+ the loss of accuracy of the type-based alias analysis compared
  to builds without link-time optimization.
   Invalid type punning on global variables and declarations is now
  reported with -Wodr-type-mismatch.
@@ -96,30 +97,35 @@
  was significantly improved by decreasing the size of streamed
  data when partitioning programs.  The size of streamed
  IL while compiling Firefox 46.0 was reduced by 66%.
-  The linker plugin was extended to pass information about type of
- binary produced to GCC back end (that can be also manually controlled
- by -flinker-output).  This makes it possible to
+  The linker plugin was extended to pass information about the
+ type of binary produced to the GCC back end. (That can also be
+ controlled manually by -flinker-output.)
+ This makes it possible to
  properly configure the code generator and support incremental
- linking. Incremental linking of LTO objects by gcc -r is
- now supported on plugin-enabled setups.
+ linking. Incremental linking of LTO objects by gcc -r
+ is now supported for plugin-enabled setups.
  There are two ways to perform incremental linking:
  
 Linking by ld -r will result in an object file
 with all sections from individual object files mechanically merged.
-This delays the actual link time optimization to final linking step
-and thus permits whole program optimization.  Linking final binary
+This delays the actual link-time optimization to the final
+linking step and thus permits whole program optimization.
+Linking the final binary
 with such object files is however slower.
-Linking by gcc -r will lead to link time 
optimization
-and produce final binary into the object file.  Linking such object
-file is fast but avoids any benefits from whole program 
optimization.
+Linking by gcc -r 

Re: Documentation patch related to PR42376

[Gerald Pfeifer]

On Mon, 11 Jan 2010, Martin Reinecke wrote:
> thanks for applying the patch!
> Unfortunately I just noticed some mistakes in my wording :(
> Currently the sentence says
> "code [...] may run significantly slower [...] than they did [...]"
> I'm not a native speaker, but I guess it would be more correct
> to write
> "code [...] may run significantly more slowly [...] than it did [...]"

I realized that we did not actually update this back then, and
will admit that "significantly more slowly" feels less natural
than "significantly slower" to me, but then I am not a native
speaker either. ;-)

Sandra, what is your take on the patch below?

Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.5/changes.html,v
retrieving revision 1.115
diff -u -r1.115 changes.html
--- changes.html28 May 2016 20:40:35 -  1.115
+++ changes.html27 Feb 2017 22:23:27 -
@@ -68,7 +68,7 @@
 unwind info is emitted.
 
 On x86 targets, code containing floating-point calculations may
-run significantly slower when compiled with GCC 4.5 in strict C99
+run significantly more slowly when compiled with GCC 4.5 in strict C99
 conformance mode than they did with earlier GCC versions. This is due
 to stricter standard conformance of the compiler and can be avoided by
 using the option -fexcess-precision=fast; also see

Re: [PATCH] Some more translation related tweaks

[Joseph Myers]

On Mon, 27 Feb 2017, Jakub Jelinek wrote:

> > Yes, it's generally the case that G_() is used whenever there's a 
> > conditional expression for the msgid argument to a diagnostic function.
> 
> So, is this ok for trunk?  Shall I regenerate gcc.pot or will you?

OK.  I'll regenerate gcc.pot in a few weeks' time.

-- 
Joseph S. Myers
jos...@codesourcery.com

Disable some concept checks in C++11

[François Dumont]

Hi


I had some problems when testing pretty printers while having 
activated concept checks. I noticed that std::deque had already the 
_SGIAssignableConcept check disable when using C++11 so I propose to 
generalize to all usages of this concept check.


Additionally it avoids the definition of a typedef, usually 
_Alloc_value_type, only used when concept check is activated.


Note that I plan to also commit several cleanup of empty chars with 
this patch, transformation of 8 spaces into tabs or removal of spaces at 
end of line. I attached a 'git diff -w' patch file, let me know if you 
want to see the complete version.


Tested under Linux x86_64.

Ok to commit ? Now ?

* include/bits/stl_deque.h (deque): Access allocator value_type only if
concept checks are enabled.
* include/bits/stl_stack.h (stack): Likewise.
* include/bits/stl_vector.h (vector): Likewise.
* include/bits/stl_list.h (list): Likewise and check
_SGIAssignableConcept only in C++03.
* include/bits/stl_map.h (map): Likewise.
* include/bits/stl_set.h (set): Likewise.
* include/bits/stl_multimap.h (multimap): Likewise.
* include/bits/stl_multiset.h (multiset): Likewise.
* include/bits/stl_queue.h (queue, priority_queue): Likewise.
* include/ext/slist (slist): Likewise.

François

diff --git a/libstdc++-v3/include/bits/stl_deque.h b/libstdc++-v3/include/bits/stl_deque.h
index f097429..bf652d3 100644
--- a/libstdc++-v3/include/bits/stl_deque.h
+++ b/libstdc++-v3/include/bits/stl_deque.h
@@ -844,12 +844,14 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   template >
 class deque : protected _Deque_base<_Tp, _Alloc>
 {
+#ifdef _GLIBCXX_CONCEPT_CHECKS
   // concept requirements
   typedef typename _Alloc::value_type	_Alloc_value_type;
 # if __cplusplus < 201103L
   __glibcxx_class_requires(_Tp, _SGIAssignableConcept)
 # endif
   __glibcxx_class_requires2(_Tp, _Alloc_value_type, _SameTypeConcept)
+#endif
 
   typedef _Deque_base<_Tp, _Alloc>			_Base;
   typedef typename _Base::_Tp_alloc_type		_Tp_alloc_type;
diff --git a/libstdc++-v3/include/bits/stl_list.h b/libstdc++-v3/include/bits/stl_list.h
index 9424aec..0f26511 100644
--- a/libstdc++-v3/include/bits/stl_list.h
+++ b/libstdc++-v3/include/bits/stl_list.h
@@ -502,10 +502,14 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
   template >
 class list : protected _List_base<_Tp, _Alloc>
 {
+#ifdef _GLIBCXX_CONCEPT_CHECKS
   // concept requirements
   typedef typename _Alloc::value_type		_Alloc_value_type;
+# if __cplusplus < 201103L
   __glibcxx_class_requires(_Tp, _SGIAssignableConcept)
+# endif
   __glibcxx_class_requires2(_Tp, _Alloc_value_type, _SameTypeConcept)
+#endif
 
   typedef _List_base<_Tp, _Alloc>			_Base;
   typedef typename _Base::_Tp_alloc_type		_Tp_alloc_type;
diff --git a/libstdc++-v3/include/bits/stl_map.h b/libstdc++-v3/include/bits/stl_map.h
index 194ce42..3033953 100644
--- a/libstdc++-v3/include/bits/stl_map.h
+++ b/libstdc++-v3/include/bits/stl_map.h
@@ -106,12 +106,16 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   typedef _Alloc	allocator_type;
 
 private:
+#ifdef _GLIBCXX_CONCEPT_CHECKS
   // concept requirements
   typedef typename _Alloc::value_type		_Alloc_value_type;
+# if __cplusplus < 201103L
   __glibcxx_class_requires(_Tp, _SGIAssignableConcept)
+# endif
   __glibcxx_class_requires4(_Compare, bool, _Key, _Key,
 _BinaryFunctionConcept)
   __glibcxx_class_requires2(value_type, _Alloc_value_type, _SameTypeConcept)
+#endif
 
 public:
   class value_compare
diff --git a/libstdc++-v3/include/bits/stl_multimap.h b/libstdc++-v3/include/bits/stl_multimap.h
index 8b37de9..7dc22a9 100644
--- a/libstdc++-v3/include/bits/stl_multimap.h
+++ b/libstdc++-v3/include/bits/stl_multimap.h
@@ -105,12 +105,16 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
   typedef _Alloc	allocator_type;
 
 private:
+#ifdef _GLIBCXX_CONCEPT_CHECKS
   // concept requirements
   typedef typename _Alloc::value_type		_Alloc_value_type;
+# if __cplusplus < 201103L
   __glibcxx_class_requires(_Tp, _SGIAssignableConcept)
+# endif
   __glibcxx_class_requires4(_Compare, bool, _Key, _Key,
 _BinaryFunctionConcept)
   __glibcxx_class_requires2(value_type, _Alloc_value_type, _SameTypeConcept)
+#endif
 
 public:
   class value_compare
diff --git a/libstdc++-v3/include/bits/stl_multiset.h b/libstdc++-v3/include/bits/stl_multiset.h
index 871369c..60a3db8 100644
--- a/libstdc++-v3/include/bits/stl_multiset.h
+++ b/libstdc++-v3/include/bits/stl_multiset.h
@@ -94,12 +94,16 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
 	typename _Alloc = std::allocator<_Key> >
 class multiset
 {
+#ifdef _GLIBCXX_CONCEPT_CHECKS
   // concept requirements
   typedef typename _Alloc::value_type		_Alloc_value_type;
+# if __cplusplus < 201103L
   __glibcxx_class_requires(_Key, _SGIAssignableConcept)
+# endif
   __glibcxx_class_requires4(_Compare, 

[Patch, fortran] PR79676 - [submodules] Compilation/linking error when module procedures PRIVATE

[Paul Richard Thomas]

Dear All,

This bug resulted from a cock-up on my part. The mechanism for
suppressing .smod files depended on detecting the presence of a module
procedure by resetting a flag if the module_procedure attribute was
written. Of course, this didn't happen if the module procedure is
private, which rather defeats the requirement that private symbols be
present in an .smod file. The fix traverses the namespace and resets
the flag on finding a module procedure.

Bootstraps and regtests on FC25/x86_64 - OK for trunk and 6-branch?

Paul

2017-02-27  Paul Thomas  

PR fortran/79676
* module.c (mio_symbol_attribute): Remove reset of the flag
'no_module_procedures'.
(check_for_module_procedures): New function. Move declaration
of 'no_module_procedures' to above it.
(gfc_dump_module): Traverse namespace calling new function.

2017-02-27  Paul Thomas  

PR fortran/79676
* gfortran.dg/submodule_28.f08 : New test.
Index: gcc/fortran/module.c
===
*** gcc/fortran/module.c(revision 245602)
--- gcc/fortran/module.c(working copy)
*** static const char *module_name;
*** 193,202 
  /* The name of the .smod file that the submodule will write to.  */
  static const char *submodule_name;
  
- /* Suppress the output of a .smod file by module, if no module
-procedures have been seen.  */
- static bool no_module_procedures;
- 
  static gfc_use_list *module_list;
  
  /* If we're reading an intrinsic module, this is its ID.  */
--- 193,198 
*** mio_symbol_attribute (symbol_attribute *
*** 2243,2252 
if (attr->array_outer_dependency)
MIO_NAME (ab_attribute) (AB_ARRAY_OUTER_DEPENDENCY, attr_bits);
if (attr->module_procedure)
-   {
MIO_NAME (ab_attribute) (AB_MODULE_PROCEDURE, attr_bits);
- no_module_procedures = false;
-   }
if (attr->oacc_declare_create)
MIO_NAME (ab_attribute) (AB_OACC_DECLARE_CREATE, attr_bits);
if (attr->oacc_declare_copyin)
--- 2239,2245 
*** dump_module (const char *name, int dump_
*** 6139,6144 
--- 6132,6149 
  }
  
  
+ /* Suppress the output of a .smod file by module, if no module
+procedures have been seen.  */
+ static bool no_module_procedures;
+ 
+ static void
+ check_for_module_procedures (gfc_symbol *sym)
+ {
+   if (sym && sym->attr.module_procedure)
+ no_module_procedures = false;
+ }
+ 
+ 
  void
  gfc_dump_module (const char *name, int dump_flag)
  {
*** gfc_dump_module (const char *name, int d
*** 6148,6153 
--- 6153,6160 
  dump_smod =false;
  
no_module_procedures = true;
+   gfc_traverse_ns (gfc_current_ns, check_for_module_procedures);
+ 
dump_module (name, dump_flag);
  
if (no_module_procedures || dump_smod)
Index: gcc/testsuite/gfortran.dg/submodule_28.f08
===
*** gcc/testsuite/gfortran.dg/submodule_28.f08  (nonexistent)
--- gcc/testsuite/gfortran.dg/submodule_28.f08  (working copy)
***
*** 0 
--- 1,52 
+ ! { dg-do run }
+ !
+ ! Tests the fix for PR79676 in which submod_test was private even to the
+ ! submodule 'my_submod'.
+ !
+ ! Contributed by Adam Hirst  
+ !
+ module my_mod
+   private   ! This hid 'submod_test'.
+   interface
+ module subroutine submod_test(x)
+   integer :: x
+ end subroutine
+   end interface
+   integer answer
+   public routine1, print_two, answer
+ contains
+   subroutine routine1(x)
+ integer :: x
+ call submod_test(x)
+   end subroutine
+   subroutine print_two()
+ integer, parameter :: two = 2
+ answer = answer * two
+   end subroutine
+ end module
+ 
+ module my_mod_2
+   use my_mod
+ contains
+   subroutine circular_dependency()
+ call print_two()
+   end subroutine
+ end module
+ 
+ submodule (my_mod) my_submod
+   use my_mod_2
+ contains
+ module subroutine submod_test(x)
+   integer :: x
+   answer = x
+   call circular_dependency()
+ end subroutine
+ 
+ end submodule
+ 
+ program hello
+   use my_mod
+   implicit none
+   call routine1(2)
+   if (answer .ne. 4) call abort
+ end program

Re: [PATCH] Some more translation related tweaks

[Jakub Jelinek]

On Mon, Feb 27, 2017 at 12:47:09PM +, Joseph Myers wrote:
> On Mon, 27 Feb 2017, Jakub Jelinek wrote:
> 
> > On Mon, Feb 27, 2017 at 11:04:36AM +0100, Volker Reichelt wrote:
> > > > This is not -Wformat-security friendly, perhaps better
> > > >   pedwarn (EXPR_LOC_OR_LOC (outer_nelts, input_location), 
> > > > OPT_Wvla,
> > > >typedef_variant_p (orig_type)
> > > >? "non-constant array new length must be specified "
> > > >  "directly, not by typedef"
> > > >: "non-constant array new length must be specified "
> > > >  "without parentheses around the type-id");
> > > > ?
> > > 
> > > Not quite. Like this the second string doesn't end up in the gcc.pot
> > > file for translation. I had to wrap the second string in G_(...) to make
> > > it work. (I'll have a look for other instances of this pattern and
> > > prepare a separate patch.)
> > 
> > Looks like a xgettext bug or missing feature :(.  Joseph, shall we just
> > change all those to be G_() around the second string (well, some could be
> 
> Yes, it's generally the case that G_() is used whenever there's a 
> conditional expression for the msgid argument to a diagnostic function.

So, is this ok for trunk?  Shall I regenerate gcc.pot or will you?

2017-02-27  Jakub Jelinek  

* config/i386/i386.c (ix86_option_override_internal): Use
cond ? G_("...") : G_("...") instead of just cond ? "..." : "...".
* config/nvptx/nvptx.c (nvptx_goacc_validate_dims): Likewise.
* coverage.c (read_counts_file): Likewise.
* omp-offload.c (oacc_loop_fixed_partitions): Likewise.
* gcov.c (read_count_file): Use cond ? N_("...") : N_("...") instead
of just cond ? "..." : "...".
c/
* c-parser.c (c_parser_asm_statement): Use cond ? G_("...") : G_("...")
instead of just cond ? "..." : "...".
(c_parser_oacc_enter_exit_data): Use %s and ternary operator only
for "enter"/"exit" keyword.
(c_finish_oacc_routine): Don't use %s to supply portions of the
message.
cp/
* decl.c (find_decomp_class_base): Use cond ? G_("...") : G_("...")
instead of just cond ? "..." : "...".
(grokdeclarator): Likewise.
(build_enumerator): Likewise.
* init.c (build_new_1): Likewise.
* call.c (build_new_method_call_1): Likewise.
* parser.c (cp_parser_oacc_enter_exit_data): Use %s and ternary
operator only for "enter"/"exit" keyword.
(cp_finalize_oacc_routine): Don't use %s to supply portions of the
message.
fortran/
* parse.c (parse_critical_block): Use cond ? G_("...") : G_("...")
instead of just cond ? "..." : "...".
* scanner.c (gfc_next_char_literal): Likewise.
* match.c (match_exit_cycle): Likewise.

--- gcc/config/i386/i386.c.jj   2017-02-21 15:38:48.0 +0100
+++ gcc/config/i386/i386.c  2017-02-27 15:47:08.665621000 +0100
@@ -5265,11 +5265,11 @@ ix86_option_override_internal (bool main
   else if (!strcmp (opts->x_ix86_tune_string, "x86-64"))
 warning (OPT_Wdeprecated,
 main_args_p
-? "%<-mtune=x86-64%> is deprecated; use %<-mtune=k8%> "
-  "or %<-mtune=generic%> instead as appropriate"
-: "% is deprecated; use "
-  "% or % "
-  "instead as appropriate");
+? G_("%<-mtune=x86-64%> is deprecated; use %<-mtune=k8%> "
+ "or %<-mtune=generic%> instead as appropriate")
+: G_("% is deprecated; use "
+ "% or %"
+ " instead as appropriate"));
 }
   else
 {
@@ -5418,17 +5418,19 @@ ix86_option_override_internal (bool main
if (!strcmp (opts->x_ix86_arch_string, "generic"))
  {
error (main_args_p
- ? "% CPU can be used only for %<-mtune=%> switch"
- : "% CPU can be used only for "
-   "% attribute");
+  ? G_("% CPU can be used only for %<-mtune=%> "
+   "switch")
+  : G_("% CPU can be used only for "
+   "% attribute"));
return false;
  }
else if (!strcmp (opts->x_ix86_arch_string, "intel"))
  {
error (main_args_p
- ? "% CPU can be used only for %<-mtune=%> switch"
- : "% CPU can be used only for "
-   "% attribute");
+  ? G_("% CPU can be used only for %<-mtune=%> "
+   "switch")
+  : G_("% CPU 

Re: [PATCH] Remove x86 pcommit instruction

[Andrew Senkevich]

2017-02-25 18:10 GMT+01:00 Gerald Pfeifer :
> On Wed, 7 Dec 2016, Andrew Senkevich wrote:
 But how to update changes for upcoming GCC 6.3 (and future GCC 5.5)?
>>> There are corresponding documents at  [1] and [2], please add a "GCC
>>> 6.3" or "GCC 5.5" entry with "Target Specific Changes" at the end of
>>> the documents.
>>>
>>> [1] https://gcc.gnu.org/gcc-6/changes.html
>>> [2] https://gcc.gnu.org/gcc-5/changes.html
>> Attached patches, who will apply them?
>
> I noticed nobody so far, so I took this.  The patch for GCC 6
> required some tweaking (and you can't use the some id for two
> different headings).
>
> Below is what I just applied.
>
> Gerald
>
> Index: gcc-6/changes.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-6/changes.html,v
> retrieving revision 1.93
> diff -u -r1.93 changes.html
> --- gcc-6/changes.html  18 Feb 2017 22:15:41 -  1.93
> +++ gcc-6/changes.html  25 Feb 2017 17:06:27 -
> @@ -879,5 +879,15 @@
>  complete (that is, it is possible that some PRs that have been fixed
>  are not listed here).
>
> +Target Specific Changes
> +
> +IA-32/x86-64
> +  
> +Support for the  +
> href="https://software.intel.com/en-us/blogs/2016/09/12/deprecate-pcommit-instruction;>deprecated
> +pcommit instruction has been removed.
> +  
> +
> + 
>  
>  

Thanks Gerald!

Could you please add the same statement for gcc-7 changes?


--
WBR,
Andrew

Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.

[Martin Jambor]

Hello,

On Sun, Feb 26, 2017 at 03:21:20PM +0100, Gerald Pfeifer wrote:
> On Sun, 19 Feb 2017, Gerald Pfeifer wrote:
> > That was quite a bit; thanks for doing that, Jakub!
> > 
> > In the patch below I try to streamline language a bit, document options 
> > being implied by -Os (in addition to -O2 or higher), fix grammar in a few 
> > places, and change a textual link to being a real one.
> > 
> > I have _not_ applied this yet, and would appreciate your feedback.
> 
> I did another two passes through this, making a few more simplifications
> and changes, and committed it.
> 
> If you see anything beyond it, or changes you disagree with, let me know!
> 

on top of your patch, I would like to propose the following.  What do
you think?

Martin


Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.67
diff -u -r1.67 changes.html
--- changes.html26 Feb 2017 14:21:15 -  1.67
+++ changes.html27 Feb 2017 16:55:31 -
@@ -67,7 +67,10 @@
   the call graph.  It is enabled by the -fipa-bit-cp
   option if -fipa-cp is enabled as well, and is enabled
   at the -O2 optimization level and higher (and
-  -Os).
+  -Os).  This optimization and its option supersede
+  interprocedural alignment propagation of gcc 6, and therefore the
+  option -fipa-cp-alignment is now deprecated and
+  ignored.
 
   A new interprocedural value range propagation optimization has been
   added, which propagates integral ranges that variable values can be proven

[RFC PATCH 2/3] Use call_summary in ipa-prop and ipa-cp

[Martin Jambor]

Hello,

this is patch is afairly straightforward conversion from use of a
vector indexed by edge->uid to use of the new call_summary from the
previous patch.

The patch is generally a cleanup, hashing is a nicer method of keeping
call-site related information than a gigantic vector that we never
shrink during its lifetime.  Moreover, it should allow further
cleanups and of course is a nice way of testing that the previous
patch works.

Any comments and/or suggestions are welcome,

Martin

2017-02-27  Martin Jambor  

* ipa-prop.h (ipa_edge_args): Make a class.  Mark with for_user GTY
tag.  Added a default constructor and a destructor.
(ipa_edge_args_sum_t): New class;
(ipa_edge_args_sum): Declare.
(ipa_edge_args_vector): Remove declaration.
(IPA_EDGE_REF): Use ipa_edge_args_sum.
(ipa_free_edge_args_substructures): Remove declaration.
(ipa_check_create_edge_args): Use ipa_edge_args_sum.
(ipa_edge_args_info_available_for_edge_p): Likewise.
* ipa-prop.c (ipa_edge_args_vector): Removed.
(edge_removal_hook_holder): Likewise.
(edge_duplication_hook_holder): Likewise.
(ipa_edge_args_sum): New variable.
(ipa_propagate_indirect_call_infos): Test ipa_edge_args_sum instead of
ipa_edge_args_vector.
(ipa_free_edge_args_substructures): Likewise.
(ipa_free_all_edge_args): Free ipa_edge_args_sum instead of
ipa_edge_args_vector.
(ipa_edge_removal_hook): Turned into method
ipa_edge_args_sum_t::remove.
(ipa_edge_duplication_hook): Turned into method
ipa_edge_args_sum_t::duplicate.
(ipa_register_cgraph_hooks): Create ipa_edge_args_sum instead of
registering edge hooks.
(ipa_unregister_cgraph_hooks): Do not unregister edge hooks.
* ipa-inline-analysis.c (estimate_function_body_sizes): Test
ipa_edge_args_sum instead of ipa_edge_args_vector.
* ipa-profile.c (ipa_profile): Likewise.
---
 gcc/ipa-inline-analysis.c |  2 +-
 gcc/ipa-profile.c |  2 +-
 gcc/ipa-prop.c| 71 +++
 gcc/ipa-prop.h| 59 +--
 4 files changed, 63 insertions(+), 71 deletions(-)

diff --git a/gcc/ipa-inline-analysis.c b/gcc/ipa-inline-analysis.c
index 611faab570f..639fc05fccd 100644
--- a/gcc/ipa-inline-analysis.c
+++ b/gcc/ipa-inline-analysis.c
@@ -2937,7 +2937,7 @@ estimate_function_body_sizes (struct cgraph_node *node, 
bool early)
 {
   if (!early)
 loop_optimizer_finalize ();
-  else if (!ipa_edge_args_vector)
+  else if (!ipa_edge_args_sum)
ipa_free_all_node_params ();
   free_dominance_info (CDI_DOMINATORS);
 }
diff --git a/gcc/ipa-profile.c b/gcc/ipa-profile.c
index ae1ca2f3762..0bfbfa1e447 100644
--- a/gcc/ipa-profile.c
+++ b/gcc/ipa-profile.c
@@ -620,7 +620,7 @@ ipa_profile (void)
 "Not speculating: target is overwritable "
 "and can be discarded.\n");
}
- else if (ipa_node_params_sum && ipa_edge_args_vector
+ else if (ipa_node_params_sum && ipa_edge_args_sum
   && (!vec_safe_is_empty
   (IPA_NODE_REF (n2)->descriptors))
   && ipa_get_param_count (IPA_NODE_REF (n2))
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index e4e44ce20c6..6d598763d02 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -57,12 +57,10 @@ along with GCC; see the file COPYING3.  If not see
 ipa_node_params_t *ipa_node_params_sum = NULL;
 /* Vector of IPA-CP transformation data for each clone.  */
 vec *ipcp_transformations;
-/* Vector where the parameter infos are actually stored. */
-vec *ipa_edge_args_vector;
+/* Edge summary for IPA-CP edge information.  */
+ipa_edge_args_sum_t *ipa_edge_args_sum;
 
 /* Holders of ipa cgraph hooks: */
-static struct cgraph_edge_hook_list *edge_removal_hook_holder;
-static struct cgraph_2edge_hook_list *edge_duplication_hook_holder;
 static struct cgraph_node_hook_list *function_insertion_hook_holder;
 
 /* Description of a reference to an IPA constant.  */
@@ -3537,7 +3535,7 @@ ipa_propagate_indirect_call_infos (struct cgraph_edge *cs,
  (i.e. during early inlining).  */
   if (!ipa_node_params_sum)
 return false;
-  gcc_assert (ipa_edge_args_vector);
+  gcc_assert (ipa_edge_args_sum);
 
   propagate_controlled_uses (cs);
   changed = propagate_info_to_inlined_callees (cs, cs->callee, new_edges);
@@ -3545,31 +3543,16 @@ ipa_propagate_indirect_call_infos (struct cgraph_edge 
*cs,
   return changed;
 }
 
-/* Frees all dynamically allocated structures that the argument info points
-   to.  */
-
-void
-ipa_free_edge_args_substructures (struct ipa_edge_args *args)
-{
-  vec_free (args->jump_functions);
-  memset 

[RFC PATCH 1/3] call_summary to keep info about cgraph_edges

[Martin Jambor]

Hello,

this patch is an actual implementation of the call_summary class (I
hope the name is a good analogy to the function_summary we have, I am
opened to other suggestions).  I have kept the implementation close to
the existing one of function-summary, there are I think only two
notable differences:

  - there is no call_graph hook for new edge creation, which is in
fact quite natural, so there is no virtual function for that
event, and

  - edge UIDs start with zero, and the inliner does use it to index a
vector, so not only did I need to remove asserts that UIDs are
non-zero, I also had to actually increment them before using them
because apparently our hash-map does not like zero hashes.

Apart from that, I have introduced a predicate method exists to both
summaries, in order to figure out whether a summary for a given
node/edge already exists.  This is useful for example for dumping,
there is no need for dumping to allocate new stuff by querying.

Moreover, I have also spotted what I think is a bug in
function_summary::symtab_removal which does not call the destructor of
the item it holds when a function is removed and the item is
garbage-collecotr allocated.  Fixed in a simple hunk below.

I'll be grateful for any comments and/or suggestions,

Martin

2017-02-24  Martin Jambor  

* symbol-summary.h (function_summary): New method exists.
(function_summary::symtab_removal): Deallocate through release.
(call_summary): New class.
(gt_ggc_mx): New overload.
(gt_pch_nx): Likewise.
(gt_pch_nx): Likewise.
---
 gcc/symbol-summary.h | 214 ++-
 1 file changed, 210 insertions(+), 4 deletions(-)

diff --git a/gcc/symbol-summary.h b/gcc/symbol-summary.h
index 3bcd14522c8..313082d7d5d 100644
--- a/gcc/symbol-summary.h
+++ b/gcc/symbol-summary.h
@@ -126,6 +126,12 @@ public:
 return m_map.elements ();
   }
 
+  /* Return true if a summary for the given NODE already exists.  */
+  bool exists (cgraph_node *node)
+  {
+return m_map.get (node->summary_uid) != NULL;
+  }
+
   /* Enable insertion hook invocation.  */
   void enable_insertion_hook ()
   {
@@ -160,10 +166,7 @@ public:
 if (v)
   {
summary->remove (node, *v);
-
-   if (!summary->m_ggc)
- delete (*v);
-
+   summary->release (*v);
summary->m_map.remove (summary_uid);
   }
   }
@@ -251,4 +254,207 @@ gt_pch_nx(function_summary* const& summary, 
gt_pointer_operator op,
   gt_pch_nx (>m_map, op, cookie);
 }
 
+/* An impossible class templated by non-pointers so, which makes sure that only
+   summaries gathering pointers can be created.  */
+
+template 
+class call_summary
+{
+private:
+  call_summary();
+};
+
+/* Class to store auxiliary information about call graph edges.  */
+
+template 
+class GTY((user)) call_summary 
+{
+public:
+  /* Default construction takes SYMTAB as an argument.  */
+  call_summary (symbol_table *symtab, bool ggc = false): m_ggc (ggc),
+m_map (13, ggc), m_released (false), m_symtab (symtab)
+  {
+m_symtab_removal_hook =
+  symtab->add_edge_removal_hook
+  (call_summary::symtab_removal, this);
+m_symtab_duplication_hook =
+  symtab->add_edge_duplication_hook
+  (call_summary::symtab_duplication, this);
+  }
+
+  /* Destructor.  */
+  virtual ~call_summary ()
+  {
+release ();
+  }
+
+  /* Destruction method that can be called for GGT purpose.  */
+  void release ()
+  {
+if (m_released)
+  return;
+
+m_symtab->remove_edge_removal_hook (m_symtab_removal_hook);
+m_symtab->remove_edge_duplication_hook (m_symtab_duplication_hook);
+
+/* Release all summaries.  */
+typedef typename hash_map ::iterator map_iterator;
+for (map_iterator it = m_map.begin (); it != m_map.end (); ++it)
+  release ((*it).second);
+
+m_released = true;
+  }
+
+  /* Traverses all summarys with a function F called with
+ ARG as argument.  */
+  template
+  void traverse (Arg a) const
+  {
+m_map.traverse  (a);
+  }
+
+  /* Basic implementation of removal operation.  */
+  virtual void remove (cgraph_edge *, T *) {}
+
+  /* Basic implementation of duplication operation.  */
+  virtual void duplicate (cgraph_edge *, cgraph_edge *, T *, T *) {}
+
+  /* Allocates new data that are stored within map.  */
+  T* allocate_new ()
+  {
+/* Call gcc_internal_because we do not want to call finalizer for
+   a type T.  We call dtor explicitly.  */
+return m_ggc ? new (ggc_internal_alloc (sizeof (T))) T () : new T () ;
+  }
+
+  /* Release an item that is stored within map.  */
+  void release (T *item)
+  {
+if (m_ggc)
+  {
+   item->~T ();
+   ggc_free (item);
+  }
+else
+  delete item;
+  }
+
+  /* Getter for summary callgraph edge pointer.  */
+  T* get (cgraph_edge *edge)
+  {
+return get (hashable_uid (edge));
+  }
+
+  /* Return number of elements handled by 

[RFC PATCH 3/3] Remove ipa_update_after_lto_read

[Martin Jambor]

Hello,

when working on call summaries, I have found a weird function
ipa_update_after_lto_read which currently only makes sure that IPA-CP
function and edge summaries exist, at times when they already have to
exist.

So I did some digging in history and found out that originally the
function was meant for setting a called_with_var_arguments flags where
appropriate after LTO stream-in.  We have however removed that flag in
2011 and the function is basically useless since then (although only
with call summaries it is definitely a no-OP).  Thus, I'll propose to
remove it next stage1.

Thanks,

Martin

2017-02-27  Martin Jambor  

* ipa-prop.c (ipa_update_after_lto_read): Removed.
* ipa-prop.h (ipa_update_after_lto_read): Remove declaration.
* ipa-cp.c (ipcp_propagate_stage): Do not call
ipa_update_after_lto_read.
* ipa-inline.c (ipa_inline): Likewise.
---
 gcc/ipa-cp.c |  4 
 gcc/ipa-inline.c |  3 ---
 gcc/ipa-prop.c   | 11 ---
 gcc/ipa-prop.h   |  1 -
 4 files changed, 19 deletions(-)

diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index aa3c9973a66..6a6467ce8ba 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -3234,10 +3234,6 @@ ipcp_propagate_stage (struct ipa_topo_info *topo)
   if (dump_file)
 fprintf (dump_file, "\n Propagating constants:\n\n");
 
-  if (in_lto_p)
-ipa_update_after_lto_read ();
-
-
   FOR_EACH_DEFINED_FUNCTION (node)
   {
 struct ipa_node_params *info = IPA_NODE_REF (node);
diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index 4843f8a2f8e..b681c568c89 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -2379,9 +2379,6 @@ ipa_inline (void)
 
   order = XCNEWVEC (struct cgraph_node *, symtab->cgraph_count);
 
-  if (in_lto_p && optimize)
-ipa_update_after_lto_read ();
-
   if (dump_file)
 dump_inline_summaries (dump_file);
 
diff --git a/gcc/ipa-prop.c b/gcc/ipa-prop.c
index 6d598763d02..47936a92adb 100644
--- a/gcc/ipa-prop.c
+++ b/gcc/ipa-prop.c
@@ -5096,17 +5096,6 @@ ipa_prop_read_jump_functions (void)
 }
 }
 
-/* After merging units, we can get mismatch in argument counts.
-   Also decl merging might've rendered parameter lists obsolete.
-   Also compute called_with_variable_arg info.  */
-
-void
-ipa_update_after_lto_read (void)
-{
-  ipa_check_create_node_params ();
-  ipa_check_create_edge_args ();
-}
-
 void
 write_ipcp_transformation_info (output_block *ob, cgraph_node *node)
 {
diff --git a/gcc/ipa-prop.h b/gcc/ipa-prop.h
index 4d8ee0d351d..bf5d02f8e3a 100644
--- a/gcc/ipa-prop.h
+++ b/gcc/ipa-prop.h
@@ -867,7 +867,6 @@ void ipa_prop_write_jump_functions (void);
 void ipa_prop_read_jump_functions (void);
 void ipcp_write_transformation_summaries (void);
 void ipcp_read_transformation_summaries (void);
-void ipa_update_after_lto_read (void);
 int ipa_get_param_decl_index (struct ipa_node_params *, tree);
 tree ipa_value_from_jfunc (struct ipa_node_params *info,
   struct ipa_jump_func *jfunc);
-- 
2.11.1

[RFC PATCH 0/3] Call summary class

[Martin Jambor]

Hello,

the patch sequence in this thread adds a call_summary class, which is
analogous to function_summary we already have but which gathers
information about call graph edges, rather than nodes.

The first patch implements the class itself, the second modifies
ipa-prop.[ch] and ipa-cp.c to use it instead of a vector indexed by
edge->uid and the third patch is a semi-related cleanup I spotted
along the way.

I have LTO-bootstrapped and tested the patches on x86_64-linux and
successfully LTO-built Mozilla Firefox with it.  I'll be grateful for
any comments, otherwise I'll queue the series for the next stage1.

Thanks,

Martin



Martin Jambor (3):
  call_summary to keep info about cgraph_edges
  Use call_summary in ipa-prop and ipa-cp
  Remove ipa_update_after_lto_read

 gcc/ipa-cp.c  |   4 -
 gcc/ipa-inline-analysis.c |   2 +-
 gcc/ipa-inline.c  |   3 -
 gcc/ipa-profile.c |   2 +-
 gcc/ipa-prop.c|  82 --
 gcc/ipa-prop.h|  60 +
 gcc/symbol-summary.h  | 214 +-
 7 files changed, 273 insertions(+), 94 deletions(-)

-- 
2.11.1

Re: [wwwdocs] Document in changes.html -fcode-hoisting, -fipa-bit-cp, -fipa-vrp, -fsplit-loops, GCJ removal, x86 ISA additions, -fshrink-wrap-separate etc.

[Martin Sebor]

On 02/26/2017 07:21 AM, Gerald Pfeifer wrote:

On Sun, 19 Feb 2017, Gerald Pfeifer wrote:

That was quite a bit; thanks for doing that, Jakub!

In the patch below I try to streamline language a bit, document options
being implied by -Os (in addition to -O2 or higher), fix grammar in a few
places, and change a textual link to being a real one.

I have _not_ applied this yet, and would appreciate your feedback.


I did another two passes through this, making a few more simplifications
and changes, and committed it.

If you see anything beyond it, or changes you disagree with, let me know!

@@ -525,8 +524,8 @@
 New __builtin_add_overflow_p,
   __builtin_sub_overflow_p,
   __builtin_mul_overflow_p built-in functions have been added.
-  These work similarly to earlier added built-in functions without the
-  _p suffix, but don't actually store the result of the
+  These work similarly to their siblings without the
+  _p suffix, but do not actually store the result of the
   arithmetics anywhere, just return whether the operation would overflow.
   These builtins allow easy checking for overflows e.g. in C++
   constexpr contexts.


Sorry to be jumping in so late. I only noticed this bit now.

I would suggest to say that these new built-ins evaluate to integer
constant expressions when their arguments do.  Not all C programmers
are familiar with C++ constexpr so they may not understand the use
use case.  The request for these built-ins also came from a C user
and was specifically motivated by avoiding -Woverflow warnings so
adding an example demonstrating that might be helpful as well.
Something like this:

  ... Calls to these built-ins with integer constant arguments
  evaluate to integer constants expressions.
  For example, in the following, c is assigned
  the result of a * b only if the multiplication
  does not overflow, otherwise it is assigned the value zero.
  The multiplication is performed at compile-time and without
  triggering a -Woverflow warning.
  
enum {
  a = 12345678,
  b = 87654321,
  c = __builtin_mul_overflow_p (a, b, a) ? 0 : a * b
};
  

Martin

Re: [PATCH] avoid using upper bound of width and precision in -Wformat-overlow (PR 79692)

[Jeff Law]

On 02/25/2017 03:46 PM, Martin Sebor wrote:

In an arithmetic directive with the width or precision specified
by an argument to the asterisk (e.g., "%*x") and where the argument
range is unknown, for the purposes of the return value optimization
the pass must assume it's potentially as large as INT_MAX.  But for
the purposes of issuing a warning, that assumption leads to false
positives because the value of the argument can and in reality
usually is much smaller.

The attached patch adjusts the checker to use the lower bound in
this case to avoid these false positives.  It does that for both
integer and floating directives (for the latter it uses the lesser
of 3 and the lower bound in this case).

In addition, the patch corrects the handling of the pound flag ('#')
in "%#.*g" directives which makes it keep as many trailing zeros after
the radix character as specified by the precision.  (Without the '#',
"%.*g" trims trailing zeros.)

Martin



gcc-79692.diff


PR middle-end/79692 - [7 Regression] -Wformat-overflow false positive

gcc/ChangeLog:

PR c/79692
* gimple-ssa-sprintf.c
(directive::known_width_and_precision): New function.
(format_integer): Use it.
(get_mpfr_format_length): Consider the full range of precision
when computing %g output with the # flag.  Set the likely byte
count to 3 rather than 1 when precision is indeterminate.
(format_floating): Correct the lower bound of precision.

gcc/testsuite/ChangeLog:

PR c/79692
* gcc.dg/tree-ssa/builtin-sprintf-2.c: Add test cases.
* gcc.dg/tree-ssa/builtin-sprintf-warn-10.c: Correct %#g.
* gcc.dg/tree-ssa/builtin-sprintf-warn-15.c: New test.


So in some cases you use

+  /* For an indeterminate precision the lower bound must be assumed
+ to be zero.  */
+  if (prec[0] < 0 && prec[1] >= 0)

Note prec[1] >= 0

In other cases you have:

+   /* The minimum output with unknown precision is a single byte
+  (e.g., "0") but the more likely output is 3 bytes ("0.0").  */
+   if (dir.prec[0] < 0 && dir.prec[1] > 0)

Note  dir.prec[1] > 0

Shouldn't one of those be changed to be consistent with the other?

Similarly in known_width_and_precision.  Please review the patch to 
ensure that we're as consistent as possible for these tests.



OK after doing that review and making any necessary trivial adjustments.

Jeff

New template for 'gcc' made available

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.  (If you have
any questions, send them to .)

A new POT file for textual domain 'gcc' has been made available
to the language teams for translation.  It is archived as:

http://translationproject.org/POT-files/gcc-7.1-b20170226.pot

Whenever you have a new distribution with a new version number ready,
containing a newer POT file, please send the URL of that distribution
tarball to the address below.  The tarball may be just a pretest or a
snapshot, it does not even have to compile.  It is just used by the
translators when they need some extra translation context.

Below is the URL which has been provided to the translators of your
package.  Please inform the translation coordinator, at the address
at the bottom, if this information is not current:

ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170101/gcc-7-20170101.tar.bz2

Translated PO files will later be automatically e-mailed to you.

Thank you for all your work,

The Translation Project robot, in the
name of your translation coordinator.

[gomp4] add support for gang local storage allocation in shared memory

[Cesar Philippidis]

This patch, which is largely implemented by Chung-Lin, is a first step
towards teaching the c and c++ FEs how to allocate shared memory for
gang local variables. E.g.

  #pragma acc parallel
  {
int some_array[N], some_var;

Both some_array and some_var will be stored in shared memory with this
patch.

Shared memory is allocated for local variables in a similar fashion to
worker reductions. The nvptx BE maintains a global __gangprivate_shared
variable for all of the local variables that require shared memory.
During RTL expansion, decls are checked for an "oacc gangprivate"
attribute, then those decls are remapped to a pointer within
__gangprivate_shared via the new expand_accel_var target hook. That hook
is also responsible for reserving shared memory for each decl in the
offloaded program. The c and c++ FEs attach "oacc gangprivate"
attributes to decls immediately after they process OpenACC kernels and
parallel regions.

This implementation still has a number of limitations, which will be
addressed in follow up patches at some later date:

 * Currently variables in private clauses inside acc loops will not
   utilize shared memory.
 * OpenACC routines don't use shared memory, except for reductions and
   worker state propagation.
 * Variables local to worker loops don't use shared memory.
 * Variables local to automatically partitioned gang and worker loops
   don't use shared memory.
 * Shared memory is allocated globally, not locally on a per-function
   basis. We're not sure if that matters though.

This patch has been applied to gomp-4_0-branch.

Cesar
2017-02-27  Chung-Lin Tang  
	Cesar Philippidis  

	gcc/c/
	* c-parser.c (mark_vars_oacc_gangprivate): New function.
	(c_parser_oacc_kernels_parallel): Call it to mark gang local variables
	with attribute "oacc gangprivate".

	gcc/cp/
	* cp-tree.h (mark_vars_oacc_gangprivate): Declare.
	* parser.c (mark_vars_oacc_gangprivate): New function.
	(cp_parser_oacc_kernels_parallel): Call it to mark gang local variables
	with attribute "oacc gangprivate".
	* pt.c (tsubst_expr): Likewise.

	gcc/
	* config/nvptx/nvptx.c (gangprivate_shared_size): New global variable.
	(gangprivate_shared_align): Likewise.
	(gangprivate_shared_sym): Likewise.
	(gangprivate_shared_hmap): Likewise.
	(nvptx_option_override): Initialize gangprivate_shared_sym.
	(nvptx_file_end): Output gangprivate_shared_sym.
	(nvptx_goacc_expand_accel_var): New function.
	(nvptx_set_current_function): New function.
	(TARGET_SET_CURRENT_FUNCTION): Define hook.
	(TARGET_GOACC_EXPAND_ACCEL): Likewise.
	* doc/tm.texi (TARGET_GOACC_EXPAND_ACCEL_VAR): Document new hook.
	* doc/tm.texi.in (TARGET_GOACC_EXPAND_ACCEL_VAR): Likewise.
	* expr.c (expand_expr_real_1): Remap decls marked with the
	"oacc gangprivate" atttribute.
	* omp-low.c (scan_sharing_clauses): Strip out any "oacc gangprivate"
	attributes from acc loop private clauses.
	* target.def (expand_accel_var): New hook.

	libgomp/
	* testsuite/libgomp.oacc-c-c++-common/gang-private-1.c: New test.


diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
index 3f994e3..728c31b 100644
--- a/gcc/c/c-parser.c
+++ b/gcc/c/c-parser.c
@@ -14086,6 +14086,32 @@ c_parser_oacc_loop (location_t loc, c_parser *parser, char *p_name,
 	| (OMP_CLAUSE_MASK_1 << PRAGMA_OACC_CLAUSE_WAIT) )
 
 static tree
+mark_vars_oacc_gangprivate (tree *tp,
+			int *walk_subtrees ATTRIBUTE_UNUSED,
+			void *data ATTRIBUTE_UNUSED)
+{
+  /* We back away from nested OpenACC non-gang loop directives.  */
+  if (TREE_CODE (*tp) == OACC_LOOP
+  && find_omp_clause (OMP_FOR_CLAUSES (*tp), OMP_CLAUSE_GANG) == NULL_TREE)
+{
+  return *tp;
+}
+  if (TREE_CODE (*tp) == BIND_EXPR)
+{
+  tree block = BIND_EXPR_BLOCK (*tp);
+  for (tree var = BLOCK_VARS (block); var; var = DECL_CHAIN (var))
+	{
+	  gcc_assert (TREE_CODE (var) == VAR_DECL);
+	  DECL_ATTRIBUTES (var)
+	= tree_cons (get_identifier ("oacc gangprivate"),
+			 NULL, DECL_ATTRIBUTES (var));
+	  c_mark_addressable (var);
+	}
+}
+  return NULL;
+}
+
+static tree
 c_parser_oacc_kernels_parallel (location_t loc, c_parser *parser,
 enum pragma_kind p_kind, char *p_name,
 bool *if_p)
@@ -14119,7 +14145,9 @@ c_parser_oacc_kernels_parallel (location_t loc, c_parser *parser,
 	  tree block = c_begin_omp_parallel ();
 	  tree clauses;
 	  c_parser_oacc_loop (loc, parser, p_name, mask, , if_p);
-	  return c_finish_omp_construct (loc, code, block, clauses);
+	  block = c_finish_omp_construct (loc, code, block, clauses);
+	  walk_tree_1 (, mark_vars_oacc_gangprivate, NULL, NULL, NULL);
+	  return block;
 	}
 }
 
@@ -14128,7 +14156,9 @@ c_parser_oacc_kernels_parallel (location_t loc, c_parser *parser,
   tree block = c_begin_omp_parallel ();
   add_stmt (c_parser_omp_structured_block (parser, if_p));
 
-  return c_finish_omp_construct (loc, code, block, clauses);
+  block = c_finish_omp_construct (loc, code, block, clauses);
+  walk_tree_1 (, 

[PATCH] Fix PR79723

[Richard Biener]

I am testing the following patch for another vectorizer issue with
address-space preserving.

Bootstrap / regtest running on x86_64-unknown-linux-gnu.

Richard.

2017-02-27  Richard Biener  

PR tree-optimization/79723
* tree-vect-stmts.c (get_vectype_for_scalar_type_and_size): Preserve
address-space properly.

* gcc.target/i386/pr79723.c: New testcase.

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   (revision 245753)
+++ gcc/tree-vect-stmts.c   (working copy)
@@ -8957,6 +8957,7 @@ free_stmt_vec_info (gimple *stmt)
 static tree
 get_vectype_for_scalar_type_and_size (tree scalar_type, unsigned size)
 {
+  tree orig_scalar_type = scalar_type;
   machine_mode inner_mode = TYPE_MODE (scalar_type);
   machine_mode simd_mode;
   unsigned int nbytes = GET_MODE_SIZE (inner_mode);
@@ -9017,6 +9018,12 @@ get_vectype_for_scalar_type_and_size (tr
   && !INTEGRAL_MODE_P (TYPE_MODE (vectype)))
 return NULL_TREE;
 
+  /* Re-attach the address-space qualifier if we canonicalized the scalar
+ type.  */
+  if (TYPE_ADDR_SPACE (orig_scalar_type) != TYPE_ADDR_SPACE (vectype))
+return build_qualified_type
+(vectype, KEEP_QUAL_ADDR_SPACE (TYPE_QUALS (orig_scalar_type)));
+
   return vectype;
 }
 
Index: gcc/testsuite/gcc.target/i386/pr79723.c
===
--- gcc/testsuite/gcc.target/i386/pr79723.c (nonexistent)
+++ gcc/testsuite/gcc.target/i386/pr79723.c (working copy)
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -msse2 -mno-avx" } */
+
+void memset_pattern_seg_gs(unsigned char * __seg_gs *s, long n)
+{
+  for (long i = 0; i < n; ++i)
+s[i] = 0;
+}
+
+/* { dg-final { scan-assembler "mov\[au\]p.\[ \t\]\[^,\]+, %gs:" } } */

RE: [PATCH] [ARC] Clean up arc header file.

[Claudiu Zissulescu]

> Oh, and you'll need to update the copyright headers to 2017 when you
> do eventually apply this, but everything else looks fine.
> 

Forgot to commit this one, done in this commit r245759. Sorry for this,
Claudiu

C++ PATCH to fix a comment

[Marek Polacek]

You might think it doesn't matter, but it causes vim's "jump to matching
brace" feature to malfunction, leaving me a bit miffed.

Applying to trunk.

2017-02-27  Marek Polacek  

* decl.c (expand_static_init): Add missing } in a comment.

diff --git gcc/cp/decl.c gcc/cp/decl.c
index 3dd1f5c..828359f 100644
--- gcc/cp/decl.c
+++ gcc/cp/decl.c
@@ -8052,6 +8052,7 @@ expand_static_init (tree decl, tree init)
   } catch {
 if (!flag) __cxa_guard_abort ();
   }
+}
   }
 
 Note that the `flag' variable is only set to 1 *after* the

Marek

Re: [PATCH] Some more translation related tweaks

[Volker Reichelt]

On 27 Feb, Jakub Jelinek wrote:
> On Mon, Feb 27, 2017 at 11:04:36AM +0100, Volker Reichelt wrote:
>> So here's the second attempt:
>> 
>> 2017-02-27  Volker Reichelt  
>> 
>>  * init.c: Include intl.h.
>>  (build_new_1): Move message strings into pedwarn to make them
>>  -Wformat-security friendly. Mark string for translation.
>>  * pt.c (tsubst_copy_and_build): Mark string for translation.
>>  Make the pointer const.
>>  * semantics.c (finish_id_expression): Mark strings for translation.
> 
> Ok for trunk then, I'll deal with the rest I've mentioned in another mail
> myself.
> 
>   Jakub

Ok, committed as revision 245757.

Volker

Re: [PATCH] Some more translation related tweaks

[Jakub Jelinek]

On Mon, Feb 27, 2017 at 11:04:36AM +0100, Volker Reichelt wrote:
> So here's the second attempt:
> 
> 2017-02-27  Volker Reichelt  
> 
>   * init.c: Include intl.h.
>   (build_new_1): Move message strings into pedwarn to make them
>   -Wformat-security friendly. Mark string for translation.
>   * pt.c (tsubst_copy_and_build): Mark string for translation.
>   Make the pointer const.
>   * semantics.c (finish_id_expression): Mark strings for translation.

Ok for trunk then, I'll deal with the rest I've mentioned in another mail
myself.

Jakub

Re: [PATCH] Some more translation related tweaks

[Joseph Myers]

On Mon, 27 Feb 2017, Jakub Jelinek wrote:

> On Mon, Feb 27, 2017 at 11:04:36AM +0100, Volker Reichelt wrote:
> > > This is not -Wformat-security friendly, perhaps better
> > > pedwarn (EXPR_LOC_OR_LOC (outer_nelts, input_location), OPT_Wvla,
> > >  typedef_variant_p (orig_type)
> > >  ? "non-constant array new length must be specified "
> > >"directly, not by typedef"
> > >  : "non-constant array new length must be specified "
> > >"without parentheses around the type-id");
> > > ?
> > 
> > Not quite. Like this the second string doesn't end up in the gcc.pot
> > file for translation. I had to wrap the second string in G_(...) to make
> > it work. (I'll have a look for other instances of this pattern and
> > prepare a separate patch.)
> 
> Looks like a xgettext bug or missing feature :(.  Joseph, shall we just
> change all those to be G_() around the second string (well, some could be

Yes, it's generally the case that G_() is used whenever there's a 
conditional expression for the msgid argument to a diagnostic function.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH PR69564]Improve vectorizer's runtime alias check for wrapping type

[Bin.Cheng]

On Fri, Feb 24, 2017 at 12:34 PM, Richard Biener
 wrote:
> On Fri, Feb 24, 2017 at 11:53 AM, Bin Cheng  wrote:
>> Hi,
>> As analyzed in PR69564, inefficient code for runtime alias check is 
>> generated in benchmark
>> scimark2.  It is suspected vectorized loop doesn't run enough iterations to 
>> cover the loss
>> of the inefficient code.  This patch improves runtime alias check for 
>> (unsigned) wrapping
>> types.
>>
>> Originally, vectorizer checks if below two ranges overlap with each other
>> range a: [min_a, max_a]  ; abs(length_a) = max_a - min_a
>> range_b: [min_b, max_b]  ; abs(length_b) = max_b - min_b
>> with condition like:
>> max_a <= min_b || max_b <= min_a
>>
>> With knowledge of length of the two ranges, this patch checks overlap with 
>> condition like:
>> (min_b - min_a) >= abs(len_a) && (min_b - min_a) <= (- abs(len_b))
>> It's better because common sub expressions in b/a can be folded.
>>
>> Note there is an implicit condition for above statements that length of 
>> range needs to be
>> no larger than middle value of the unsigned type.  This is always true since 
>> object never
>> spans over half address space in GCC.
>>
>> As mentioned, this is only done for case with wrap type and also constant 
>> segment length
>> for both a and b, which is the most common case.  It is possible to improve 
>> signed cases
>> or compilation time unknown segment length cases too, but may not worth the 
>> effort.
>>
>> Unfortunately, test case is hard to create for such code optimization.
>> Bootstrap and test on x86)64 and AArch64.  Is it OK?
>
> The patch mixes the above together with better folding (cancelling
> equal offset, decomposing
> pointer-plus).  Please separate those.
>
> Note that seg_len is always positive and the abs(len_N) in the
> comments doesn't make
> much sense to me.
>
> Meanwhile the simplification (ignoring overflow issues) can go,
> assuming equal lenghts
>
> mina + len <= minb || minb + len <= mina
>
> -> mina - minb <= -len || minb - mina <= -len
> -> minb - mina >= len || mina - minb >= len
>
> and as we know len >= 0 this is the same as
>
>abs (minb - mina) >= len
>
> and thus even simpler than your variant.  But maybe I'm missing something?
>
> As for the overflow issues, you do all computation in sizetype and
> thus guarantee
> unsigned compares, but I think to do these kind of "simplifications" you have 
> to
> use signed quantities which opens up the possibility of objects crossing the
> signed-address-space wrapping point and the simplification to break apart.

Hi Richard,
I might understand your concern about overflow now.  The validity of
simplification is based on unsigned wrapping behavior, rather than
"mis-use" of infinite precision for unsigned type.  Take example of
two simple ranges:  range_a [6, 12] and range_b [2, 8] and below
simplified condition:
  (min_b - min_a) >= len_a && (min_b - min_a) <= (0 - len_b)
For signed type, we have 2 - 6 == -4 > 2 - 8 == -6;
For unsigned wrapping type, we also have 2 - 6 == 0x8000 + -4 > 2
- 8 == 0x8000 + -6;

So actually I think the simplification stands for both signed type and
unsigned wrapping type.

I rewrite below comment in other to better explain that simplified
condition equals to the original one:

  /* Intersection between ranges [min_a, max_a] and [min_b, max_b] can be
 checked by below condition:

   max_a <= min_b || max_b <= min_a   ;cond_A
 Or
   (min_a + len_a) <= min_b || (min_b + len_b) <= min_a

 For type which wraps on overflow, it equals to:

   (min_b - min_a) >= len_a && (min_b - min_a) <= (0 - len_b) ;cond_B

 Proof:
   1) In case min_b >= min_a, i.e, (min_b - min_a) doesn't underflow.
 1.1) When min_b >= max_a
  (min_b - min_a) >= len_a is true.
  (min_b - min_a) <= (0 - len_b) is true because (0 - len_b)
  wraps to a large number.  Note (min_b - min_a) can only take
  the maxmum vaue (0 - len_b) if (min_a == 0 && max_b == MAX).

  Thus both cond_A and cond_B evaluate to TRUE.

 1.2) when min_b >= min_a && min_b < max_a
  (min_b - min_a) >= len_a is false.

  Thus both cond_A and cond_B evaluate to FALSE.

   2) In case min_a > min_b, i.e, (min_b - min_a) underflow.
 2.1) when min_a > min_b && min_a < max_b
  (min_b - min_a) <= (0 - len_b) == (min_b - max_b) is false.

  Thus both cond_A and cond_B evaluate to FALSE.

 2.2) When min_a >= max_b
  (min_b - min_a) >= len_a is true because (min_b - min_a) can
  only take the maximum value when (min_b == 0 && max_a == MAX).
  (min_b - min_a) <= (0 - len_b) == (min_b - max_b) is true.

  Thus both cond_A and cond_B evaluate to TRUE.

   We iterate all possible cases for two ranges and for each case cond_A
   and cond_B take the same value.  So the two conditions equal to each
   

[Patch, libgfortran, committed] Don't use rand_s on CYGWIN

[Janne Blomqvist]

Don't try to use rand_s on CYGWIN

CYGWIN seems to include _mingw.h and thus __MINGW64_VERSION_MAJOR is
defined even though rand_s is not available. Thus add an extra check
for __CYGWIN__.

Thanks to Tim Prince and Nightstrike for bringing this issue to my attention.

Committed as r245755.

2017-02-27  Janne Blomqvist  

* intrinsics/random.c (getosrandom): Don't try to use rand_s on
CYGWIN.


-- 
Janne Blomqvist

Re: [PATCH] Some more translation related tweaks

[Jakub Jelinek]

On Mon, Feb 27, 2017 at 11:04:36AM +0100, Volker Reichelt wrote:
> > This is not -Wformat-security friendly, perhaps better
> >   pedwarn (EXPR_LOC_OR_LOC (outer_nelts, input_location), OPT_Wvla,
> >typedef_variant_p (orig_type)
> >? "non-constant array new length must be specified "
> >  "directly, not by typedef"
> >: "non-constant array new length must be specified "
> >  "without parentheses around the type-id");
> > ?
> 
> Not quite. Like this the second string doesn't end up in the gcc.pot
> file for translation. I had to wrap the second string in G_(...) to make
> it work. (I'll have a look for other instances of this pattern and
> prepare a separate patch.)

Looks like a xgettext bug or missing feature :(.  Joseph, shall we just
change all those to be G_() around the second string (well, some could be
simplified to be
error_at (loc, "expected % after %<#pragma acc %s%>", enter ? "enter : 
"exit");
because the translations should not translate the text in between %< and %>
anyway.

c/c-parser.c-  if (!c_parser_require (parser, CPP_COLON,
c/c-parser.c-is_goto
c/c-parser.c:? "expected %<:%>"
c/c-parser.c-: "expected %<:%> or %<)%>"))

c/c-parser.c:  error_at (loc, enter
c/c-parser.c-   ? "expected % after %<#pragma acc enter%>"
c/c-parser.c-   : "expected % after %<#pragma acc exit%>");

c/c-parser.c-  error_at (loc, enter
c/c-parser.c:   ? "%<#pragma acc enter data%> has no data movement 
clause"
c/c-parser.c-   : "%<#pragma acc exit data%> has no data movement 
clause");

cp/call.c-  warning (0, (DECL_CONSTRUCTOR_P (current_function_decl)
cp/call.c:   ? "pure virtual %q#D called from 
constructor"
cp/call.c-   : "pure virtual %q#D called from 
destructor"),
cp/call.c-   fn);

cp/decl.c-  inform (DECL_SOURCE_LOCATION (field),
cp/decl.c:  TREE_PRIVATE (field) ? "declared private here"
cp/decl.c-  : "declared protected here");

cp/decl.c-  error ((flags == DTOR_FLAG)
cp/decl.c: ? "destructors may not be ref-qualified"
cp/decl.c- : "constructors may not be ref-qualified");

cp/parser.c-  error_at (loc, enter
cp/parser.c:? "expected % after %<#pragma acc enter%>"
cp/parser.c-: "expected % after %<#pragma acc exit%>");

coverage.c:   error (is_error < 0 ? "%qs has overflowed" : "%qs is 
corrupted",
coverage.c-  da_file_name);

omp-offload.c-  error_at (loop->loc,
omp-offload.c-seq_par
omp-offload.c:? "% overrides other OpenACC loop 
specifiers"
omp-offload.c-: "% conflicts with other OpenACC loop "
omp-offload.c-"specifiers");

Then we have some really non-translatable ones:
c/c-parser.c-  error_at (data->loc,
c/c-parser.c-   "%<#pragma acc routine%> must be applied before %s",
c/c-parser.c:   TREE_USED (fndecl) ? "use" : "definition");
which should be transformed into ? on the whole format string.

Jakub

Re: [PATCH] Some more translation related tweaks

[Volker Reichelt]

On 26 Feb, Jakub Jelinek wrote:
> On Sun, Feb 26, 2017 at 01:18:57PM +0100, Volker Reichelt wrote:
>> 2017-02-26  Volker Reichelt  
>> 
>>  * init.c: Include intl.h
> 
> Missing .

Indeed, I noticed that one after I hit the send button.

>> @@ -29,6 +29,7 @@
>>  #include "varasm.h"
>>  #include "gimplify.h"
>>  #include "c-family/c-ubsan.h"
>> +#include "intl.h"
>>  
>>  static bool begin_init_stmts (tree *, tree *);
>>  static tree finish_init_stmts (bool, tree, tree);
>> @@ -2805,11 +2806,11 @@
>>  {
>>const char *msg;
>>if (typedef_variant_p (orig_type))
>> -msg = ("non-constant array new length must be specified "
>> -   "directly, not by typedef");
>> +msg = G_("non-constant array new length must be specified "
>> + "directly, not by typedef");
>>else
>> -msg = ("non-constant array new length must be specified "
>> -   "without parentheses around the type-id");
>> +msg = G_("non-constant array new length must be specified "
>> + "without parentheses around the type-id");
>>pedwarn (EXPR_LOC_OR_LOC (outer_nelts, input_location),
>> OPT_Wvla, msg);
> 
> This is not -Wformat-security friendly, perhaps better
> pedwarn (EXPR_LOC_OR_LOC (outer_nelts, input_location), OPT_Wvla,
>  typedef_variant_p (orig_type)
>  ? "non-constant array new length must be specified "
>"directly, not by typedef"
>  : "non-constant array new length must be specified "
>"without parentheses around the type-id");
> ?

Not quite. Like this the second string doesn't end up in the gcc.pot
file for translation. I had to wrap the second string in G_(...) to make
it work. (I'll have a look for other instances of this pattern and
prepare a separate patch.)

>>  }
>> Index: gcc/cp/pt.c
>> ===
>> --- gcc/cp/pt.c  (revision 245719)
>> +++ gcc/cp/pt.c  (working copy)
>> @@ -17190,10 +17190,11 @@
>> stricter.  */
>>  bool in_lambda = (current_class_type
>>&& LAMBDA_TYPE_P (current_class_type));
>> -char const *msg = "%qD was not declared in this scope, "
>> -  "and no declarations were found by "
>> -  "argument-dependent lookup at the point "
>> -  "of instantiation";
>> +char const *const msg =
> 
> = should go on the next line in this case, i.e.
> = G_("%qD was not declared in this scope, "

Indeed, thanks for noticing.

> 
>   Jakub

So here's the second attempt:

2017-02-27  Volker Reichelt  

* init.c: Include intl.h.
(build_new_1): Move message strings into pedwarn to make them
-Wformat-security friendly. Mark string for translation.
* pt.c (tsubst_copy_and_build): Mark string for translation.
Make the pointer const.
* semantics.c (finish_id_expression): Mark strings for translation.

Index: gcc/cp/init.c
===
--- gcc/cp/init.c   (revision 245719)
+++ gcc/cp/init.c   (working copy)
@@ -29,6 +29,7 @@
 #include "varasm.h"
 #include "gimplify.h"
 #include "c-family/c-ubsan.h"
+#include "intl.h"
 
 static bool begin_init_stmts (tree *, tree *);
 static tree finish_init_stmts (bool, tree, tree);
@@ -2803,15 +2804,12 @@
 {
   if (complain & tf_warning_or_error)
{
- const char *msg;
- if (typedef_variant_p (orig_type))
-   msg = ("non-constant array new length must be specified "
-  "directly, not by typedef");
- else
-   msg = ("non-constant array new length must be specified "
-  "without parentheses around the type-id");
- pedwarn (EXPR_LOC_OR_LOC (outer_nelts, input_location),
-  OPT_Wvla, msg);
+ pedwarn (EXPR_LOC_OR_LOC (outer_nelts, input_location), OPT_Wvla,
+  typedef_variant_p (orig_type)
+  ? "non-constant array new length must be specified "
+"directly, not by typedef"
+  : G_("non-constant array new length must be specified "
+   "without parentheses around the type-id"));
}
   else
return error_mark_node;
Index: gcc/cp/pt.c
===
--- gcc/cp/pt.c (revision 245719)
+++ gcc/cp/pt.c (working copy)
@@ -17190,10 +17190,11 @@
   stricter.  */
bool in_lambda = (current_class_type
  && LAMBDA_TYPE_P (current_class_type));
-   char const *msg = "%qD was not declared in this scope, "
- "and no 

Re: [gomp4] DEV-PHASE change

[Tom de Vries]

On 27/02/17 10:09, Thomas Schwinge wrote:

Hi Tom!

On Thu, 23 Feb 2017 17:19:37 +0100, Tom de Vries  wrote:

[ was: r241221 [1/2] - in /branches/gomp-4_0-branch:  ]

On 16/10/16 22:13, tschwi...@gcc.gnu.org wrote:

Author: tschwinge
Date: Sun Oct 16 20:13:18 2016
New Revision: 241221

URL: https://gcc.gnu.org/viewcvs?rev=241221=gcc=rev
Log:
svn merge -r 235033:240831 svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-6-branch



In this merge, the DEV-PHASE file was cleared:



Consequently, when bootstrapping the branch, -Werror is not enabled by
default (as we can see here in configure):
...
else
   if test -d ${srcdir}/gcc && test x"`cat $srcdir/gcc/DEV-PHASE`" =
xexperimental; then
   enable_werror=yes
else
   enable_werror=no
fi
...

Was this change unintentionally merged from the 6 branch?


Well, I generally merge all changes from the base branch.

So you're suggesting we should restore that file's content, to get back
"enable_werror=yes"?


At https://gcc.gnu.org/install/configure.html I read:
...
--enable-werror
--disable-werror
--enable-werror=yes
--enable-werror=no
When you specify this option, it controls whether certain files in 
the compiler are built with -Werror in bootstrap stage2 and later. If 
you don't specify it, -Werror is turned on for the main development 
trunk. However it defaults to off for release branches and final 
releases. The specific files which get -Werror are controlled by the 
Makefiles.

...

Since gomp4 is not a release branch or final release, I'd expect -Werror 
to be turned on.



(I have not yet looked up which other things, if
any, this DEV-PHASE file control.)



Some default stage1 checking:
...
  if test "x$enable_checking" = x && \
 test -d ${srcdir}/gcc && \
 test x"`cat ${srcdir}/gcc/DEV-PHASE`" = xexperimental; then
stage1_checking=--enable-checking=yes,types,extra
  fi
...

Thanks,
- Tom

Re: [PR 78140] Reuse same IPA bits and VR info

[Richard Biener]

On Wed, Feb 22, 2017 at 11:11 AM, Martin Jambor  wrote:
> Hello,
>
> this is a fix for PR 78140 which is about LTO WPA of Firefox taking
> 1GB memory more than gcc 6.
>
> It works by reusing the ipa_bits and value_range that we previously
> had directly in jump functions and which are just too big to be
> allocated for each actual argument in all of Firefox.  Reusing is
> achieved by two hash table traits derived from ggc_cache_remove which
> apparently has been created just for this purpose and once I
> understood them they made my life a lot easier.  In future, I will
> have a look at applying this method to other parts of jump functions
> as well.
>
> According to my measurements, the patch saves about 1.2 GB of memory.
> The problem is that some change last week (between revision 245382 and
> 245595) has more than invalidated this:
>
>   | compiler| WPA mem (GB) |
>   |-+--|
>   | gcc 6 branch| 3.86 |
>   | trunk rev. 245382   | 5.21 |
>   | patched rev. 245382 | 4.06 |
>   | trunk rev. 245595   | 6.59 |
>   | patched rev. 245595 | 5.25 |
>
> (I have verified this by Martin's way of measuring things.)  I will
> try to bisect what commit has caused the increase.  Still, the patch
> helps a lot.
>
> There is one thing in the patch that intrigues me, I do not understand
> why I had to mark value_range with GTY((for_user)) - as opposed to
> just GTY(()) that was there before - whereas ipa_bits does not need
> it.  If anyone could enlighten me, that would be great.  But I suppose
> this is not an indication of anything being wrong under the hood.
>
> I have bootstrapped and LTO-bootstrapped the patch on x86_64-linux and
> also bootstrapped (C, C++ and Fortran) on an aarch64 and i686 cfarm
> machine.  I have also LTO-built Firefox with the patch and used it to
> browse for a while and it seemed fine.
>
> OK for trunk?

The idea looks good to me.  I wonder what a statistic over ranges
would look like (do they mostly look useful?).

Thanks,
Richard.

> Thanks,
>
> Martin
>
>
> 2017-02-20  Martin Jambor  
>
> PR lto/78140
> * ipa-prop.h (ipa_bits): Removed field known.
> (ipa_jump_func): Removed field vr_known.  Changed fields bits and m_vr
> to pointers.  Adjusted their comments to warn about their sharing.
> (ipcp_transformation_summary): Change bits to a vector of pointers.
> (ipa_check_create_edge_args): Moved to ipa-prop.c, declare.
> (ipa_get_ipa_bits_for_value): Declare.
> * tree-vrp.h (value_range): Mark as GTY((for_user)).
> * ipa-prop.c (ipa_bit_ggc_hash_traits): New.
> (ipa_bits_hash_table): Likewise.
> (ipa_vr_ggc_hash_traits): Likewise.
> (ipa_vr_hash_table): Likewise.
> (ipa_print_node_jump_functions_for_edge): Adjust for bits and m_vr
> being pointers and vr_known being removed.
> (ipa_set_jf_unknown): Likewise.
> (ipa_get_ipa_bits_for_value): New function.
> (ipa_set_jfunc_bits): Likewise.
> (ipa_get_value_range): New overloaded functions.
> (ipa_set_jfunc_vr): Likewise.
> (ipa_compute_jump_functions_for_edge): Use the above functions to
> construct bits and vr parts of jump functions.
> (ipa_check_create_edge_args): Move here from ipa-prop.h, also allocate
> ipa_bits_hash_table and ipa_vr_hash_table if they do not already
> exist.
> (ipcp_grow_transformations_if_necessary): Also allocate
> ipa_bits_hash_table and ipa_vr_hash_table if they do not already
> exist.
> (ipa_node_params_t::duplicate): Do not copy bits, just pointers to
> them.  Fix too long lines.
> (ipa_write_jump_function): Adjust for bits and m_vr being pointers and
> vr_known being removed.
> (ipa_read_jump_function): Use new setter functions to construct bits
> and vr parts of jump functions or set them to NULL.
> (write_ipcp_transformation_info): Adjust for bits being pointers.
> (read_ipcp_transformation_info): Likewise.
> (ipcp_update_bits): Likewise.  Fix excessively long lines a trailing
> space.
> Include gt-ipa-prop.h.
> * ipa-cp.c (propagate_bits_across_jump_function): Adjust for bits
> being pointers.
> (ipcp_store_bits_results): Likewise.
> (propagate_vr_across_jump_function): Adjust for m_vr being a pointer.
> Do not write to existing jump functions but use a temporary instead.
> ---
>  gcc/ipa-cp.c   |  49 
>  gcc/ipa-prop.c | 381 
> ++---
>  gcc/ipa-prop.h |  32 ++---
>  gcc/tree-vrp.h |   2 +-
>  4 files changed, 319 insertions(+), 145 deletions(-)
>
> diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
> index aa3c9973a66..16e7e2216ab 100644
> --- a/gcc/ipa-cp.c
> +++ b/gcc/ipa-cp.c
> @@ -1819,8 +1819,8 

Re: [gomp4] DEV-PHASE change

[Thomas Schwinge]

Hi Tom!

On Thu, 23 Feb 2017 17:19:37 +0100, Tom de Vries  wrote:
> [ was: r241221 [1/2] - in /branches/gomp-4_0-branch:  ]
> 
> On 16/10/16 22:13, tschwi...@gcc.gnu.org wrote:
> > Author: tschwinge
> > Date: Sun Oct 16 20:13:18 2016
> > New Revision: 241221
> >
> > URL: https://gcc.gnu.org/viewcvs?rev=241221=gcc=rev
> > Log:
> > svn merge -r 235033:240831 
> > svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-6-branch

> In this merge, the DEV-PHASE file was cleared:

> Consequently, when bootstrapping the branch, -Werror is not enabled by 
> default (as we can see here in configure):
> ...
> else
>if test -d ${srcdir}/gcc && test x"`cat $srcdir/gcc/DEV-PHASE`" = 
> xexperimental; then
>enable_werror=yes
> else
>enable_werror=no
> fi
> ...
> 
> Was this change unintentionally merged from the 6 branch?

Well, I generally merge all changes from the base branch.

So you're suggesting we should restore that file's content, to get back
"enable_werror=yes"?  (I have not yet looked up which other things, if
any, this DEV-PHASE file control.)


Grüße
 Thomas

Re: [PATCH 4/5] Document warning option -Wstring-plus-int

[Xi Ruoyao]

On 2017-02-25 Sat 18:19 +0100, Gerald Pfeifer wrote:

> I.e., after reading the above, I was wondering who'd do "abc" + 1.
> 
> Of course, once I looked at your good additions to the testsuite,
> I realized that this is really more about "abc" + '1'.  Technically
> the description is correct, since character constants are integers.
> 
> Perhaps add something like
> 
>   "A typical example this warns about is @samp{"abc" + 'd'}."
> 
> ?

Thanks for the advise. I'll make it clear and resubmit the patches
in early stage of GCC 8.
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

Re: enable -Wformat-truncation with -Og (PR 79691)

[Richard Biener]

On Fri, Feb 24, 2017 at 6:51 PM, Martin Sebor  wrote:
> On 02/24/2017 03:10 AM, Richard Biener wrote:
>>
>> On Fri, Feb 24, 2017 at 1:35 AM, Martin Sebor  wrote:
>>>
>>> Bug 79691 - -Wformat-truncation suppressed by (and only by) -Og
>>> points out that the gimple-ssa-sprintf pass doesn't run when
>>> this optimization option is used.  That's because I forgot to
>>> add it to the set of optimization passes that run with that
>>> option.  The attached trivial patch tested on x86_64 corrects
>>> the oversight.
>>>
>>> Is this okay for 7.0?
>>
>>
>> Any reason for the placement before copy-prop?  I'd have done it
>> after pass_late_warn_uninitialized for example.
>
>
> I wanted to make sure that folded sprintf return values would be
> eligible for further copy propagation.  E.g., that a + b would
> be folded into a constant:
>
>   int foo (void)
>   {
> int a = snprintf (0, 0, "%i", 123);
> int b = snprintf (0, 0, "%i", 1234);
> return a + b;
>   }
>
> But I could have easily missed some important use case where this
> placement will compromise the warning.  I don't have any tests
> for this one way or the other so I'm happy to go with your
> recommendation.  Let me know which you think is more appropriate
> (if you have a suggestion for a test case I'd be grateful).

Hmm, I see.  Note that I'd have expected this kind of constant folding
to happen in gimple-fold.c, but well.

>>
>> Also doesn't pass_sprintf_length rely on get_range_info ()?  With -Og
>> nothing populates those so you'll always get effectively VARYING ranges.
>
>
> It does when it's available but as Jakub noted, it works without
> it as well (at -O0).

Good.

Your original patch is ok.

Thanks,
Richard.

> Thanks
> Martin

[wwwdocs] gcc-4.8/changes.html

[Gerald Pfeifer]

Somehow this one got lost on my end, until this morning.
Embarrassing. :-(

Still, since I had prepared it back then, and it was a real
change, committed now.

Gerald

Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrieving revision 1.138
diff -u -r1.138 changes.html
--- changes.html28 May 2016 23:56:31 -  1.138
+++ changes.html27 Feb 2017 08:14:00 -
@@ -861,6 +861,14 @@
 
 Operating Systems
 
+OpenBSD
+
+  
+Support for OpenBSD/amd64 (x86_64-*-openbsd*) has been added
+and support for OpenBSD/i386 (i386-*-openbsd*) has been rejuvenated.
+
+  
+
 Windows (Cygwin)
   
 Executables are now linked against shared libgcc by default.

Re: [BUILDROBOT] arm-netbsdelf: Error during -fself-test (was: [PATCH] TS_OPTIMIZATION/TS_TARGET_OPTION need no chain/type)

[Richard Biener]

On Mon, 27 Feb 2017, Jan-Benedict Glaw wrote:

> Hi Richard,
> 
> On Wed, 2017-01-11 16:28:33 +0100, Richard Biener  wrote:
> > On Wed, 11 Jan 2017, Richard Biener wrote:
> > > LTO bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> > > 
> > > (most "gross" are still TS_LIST having a type and TS_VEC having type
> > > and chain, but that's been hard to fix with the C++ FE in place)
> > 
> > Forgot the tree-core.h part.
> > 
> > Re-bootstrapping testing on x86_64-unknown-linux-gnu.
> > 
> > Richard.
> > 
> > 2017-01-11  Richard Biener  
> > 
> > * tree.c (initialize_tree_contains_struct): Make TS_OPTIMIZATION
> > and TS_TARGET_OPTION directly derive from TS_BASE.
> > * tree-core.h (tree_optimization_option): Derive from tree_base.
> > (tree_target_option): Likewise.
> 
> This caused (or uncovered) a self-test issue on arm-netbsdelf (as run
> by config-list.mk), like in this build:
> http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=696565
> 
> /home/jbglaw/build-configlist_mk/arm-netbsdelf/build-gcc/mk/arm-netbsdelf/./gcc/xgcc
>  
> -B/home/jbglaw/build-configlist_mk/arm-netbsdelf/build-gcc/mk/arm-netbsdelf/./gcc/
>  -nostdinc -x c /dev/null -S -o /dev/null 
> -fself-test=/home/jbglaw/repos-configlist_mk/gcc/gcc/testsuite/selftests
> cc1: internal compiler error: Segmentation fault
> 0xaf7fdf crash_signal
> /home/jbglaw/repos-configlist_mk/gcc/gcc/toplev.c:333
> 0x6739b3 lookup_page_table_entry
> /home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-page.c:635
> 0x6739b3 ggc_set_mark(void const*)
> /home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-page.c:1532
> 0x571bff gt_ggc_mx_lang_tree_node(void*)
> ./gt-c-c-decl.h:49
> 0x57242a gt_ggc_mx_lang_tree_node(void*)
> ./gt-c-c-decl.h:401
> 0x572fae gt_ggc_mx_lang_tree_node(void*)
> ./gt-c-c-decl.h:382
> 0x571e61 gt_ggc_mx_lang_tree_node(void*)
> ./gt-c-c-decl.h:391
> 0x83ed15 ggc_mark_root_tab
> /home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-common.c:77
> 0x83ef70 ggc_mark_roots()
> /home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-common.c:94
> 0x674417 ggc_collect()
> /home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-page.c:2202
> 0x842dff selftest::forcibly_ggc_collect()
> /home/jbglaw/repos-configlist_mk/gcc/gcc/ggc-tests.c:36
> 0x11d0491 selftest::run_tests()
> /home/jbglaw/repos-configlist_mk/gcc/gcc/selftest-run-tests.c:103
> 0xaf9742 toplev::run_self_tests()
> /home/jbglaw/repos-configlist_mk/gcc/gcc/toplev.c:2046
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> Makefile:1932: recipe for target 's-selftest' failed
> 
> 
> Reverting your patch from current HEAD lets the self-test pass. Do you
> spot something obvious?

No, can you see which collect call in the self-test is involved?
That is, a better backtrace, eventually when compiling the testcase
with -O0?

Richard.

> MfG, JBG
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: [PATCH] FMA_EXPR can cause -fnon-call-exceptions with floating point args (PR middle-end/79396)

[Richard Biener]

On Sat, 25 Feb 2017, Jakub Jelinek wrote:

> On Sat, Feb 25, 2017 at 08:42:33AM +0100, Richard Biener wrote:
> > On February 24, 2017 9:56:25 PM GMT+01:00, Jakub Jelinek  
> > wrote:
> > >Hi!
> > >
> > >On the following testcase we replace a PLUS_EXPR (which is considered
> > >throwing with -fnon-call-exceptions when it has floating point
> > >arguments
> > >and FP exceptions or sNaNs are enabled) with a FMA_EXPR; I believe it
> > >can throw the same, but stmt_could_throw_1_p doesn't think so (as it is
> > >not unary/binary/comparison).  While we could tweak the widen_mul patch
> > >to deal with dropping EH from gsi_replace and cleaning up cfg etc., I
> > >believe the right fix is to fix stmt_could_throw_1_p.
> > >
> > >Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> > 
> > OK.  Can you make sure this is then consistent with the other throw 
> > predicates?.
> 
> may_trap_p_1 handles FMA right, no idea what other predicates could cover
> that on RTL.  But you're right, operation_could_trap_p used by
> tree_could_trap_p needs the same treatment:

Yes, that was what I remembered (used for example by vn_nary_may_trap).

Ok.

Thanks,
Richard.

> 2017-02-25  Jakub Jelinek  
> 
>   PR middle-end/79396
>   * tree-eh.c (operation_could_trap_p, stmt_could_throw_1_p): Handle
>   FMA_EXPR like tcc_binary or tcc_unary.
> 
>   * g++.dg/opt/pr79396.C: New test.
> 
> --- gcc/tree-eh.c.jj  2017-02-24 21:39:01.240088691 +0100
> +++ gcc/tree-eh.c 2017-02-25 09:21:06.017859379 +0100
> @@ -2513,7 +2513,8 @@ operation_could_trap_p (enum tree_code o
>  
>if (TREE_CODE_CLASS (op) != tcc_comparison
>&& TREE_CODE_CLASS (op) != tcc_unary
> -  && TREE_CODE_CLASS (op) != tcc_binary)
> +  && TREE_CODE_CLASS (op) != tcc_binary
> +  && op != FMA_EXPR)
>  return false;
>  
>return operation_could_trap_helper_p (op, fp_operation, honor_trapv,
> @@ -2738,7 +2739,8 @@ stmt_could_throw_1_p (gimple *stmt)
>  
>if (TREE_CODE_CLASS (code) == tcc_comparison
>|| TREE_CODE_CLASS (code) == tcc_unary
> -  || TREE_CODE_CLASS (code) == tcc_binary)
> +  || TREE_CODE_CLASS (code) == tcc_binary
> +  || code == FMA_EXPR)
>  {
>if (is_gimple_assign (stmt)
> && TREE_CODE_CLASS (code) == tcc_comparison)
> --- gcc/testsuite/g++.dg/opt/pr79396.C.jj 2017-02-25 09:20:03.608706718 
> +0100
> +++ gcc/testsuite/g++.dg/opt/pr79396.C2017-02-25 09:20:03.607706732 
> +0100
> @@ -0,0 +1,13 @@
> +// PR middle-end/79396
> +// { dg-do compile }
> +// { dg-options "-fnon-call-exceptions -O2" }
> +// { dg-additional-options "-mfma" { target i?86-*-* x86_64-*-* } }
> +
> +struct A { A (); ~A (); };
> +
> +float
> +foo (float x)
> +{
> +  A a;
> +  return __builtin_pow (x, 2) + 2;
> +}
> 
> 
>   Jakub
> 
> 

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)