New Vietnamese PO file for 'gcc' (version 6.1-b20160131)

[Translation Project Robot]

Hello, gentle maintainer.

This is a message from the Translation Project robot.

A revised PO file for textual domain 'gcc' has been submitted
by the Vietnamese team of translators.  The file is available at:

http://translationproject.org/latest/gcc/vi.po

(This file, 'gcc-6.1-b20160131.vi.po', has just now been sent to you in
a separate email.)

All other PO files for your package are available in:

http://translationproject.org/latest/gcc/

Please consider including all of these in your next release, whether
official or a pretest.

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.

The following HTML page has been updated:

http://translationproject.org/domain/gcc.html

If any question arises, please contact the translation coordinator.

Thank you for all your work,

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

[Bug rtl-optimization/69806] [6 Regression][SH] Combine doesn't see constant

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69806

--- Comment #9 from Jakub Jelinek  ---
Please see PR69671 then, that CSE change is right, so you really need to find
some solution at the backend side.  Look what fwprop* dumps show etc.

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881

--- Comment #2 from Bernd Edlinger  ---
Something like that might be needed?

Index: c_global/cstddef
===
--- c_global/cstddef(Revision 233574)
+++ c_global/cstddef(Arbeitskopie)
@@ -41,6 +41,13 @@

 #pragma GCC system_header

+#if defined(__need_wchar_t) || defined(__need_size_t) \
+|| defined(__need_ptrdiff_t) || defined(__need_NULL) \
+|| defined(__need_wint_t)
+
+#include 
+
+#else
 #include 
 #include 

@@ -51,5 +58,6 @@
   using ::max_align_t;
 }
 #endif
+#endif

 #endif // _GLIBCXX_CSTDDEF
Index: c_std/cstddef
===
--- c_std/cstddef   (Revision 233574)
+++ c_std/cstddef   (Arbeitskopie)
@@ -41,6 +41,13 @@

 #pragma GCC system_header

+#if defined(__need_wchar_t) || defined(__need_size_t) \
+|| defined(__need_ptrdiff_t) || defined(__need_NULL) \
+|| defined(__need_wint_t)
+
+#include 
+
+#else
 #include 
 #include 

@@ -51,5 +58,6 @@
   using ::max_align_t;
 }
 #endif
+#endif

 #endif // _GLIBCXX_CSTDDEF


Question:

why are the both files different?
diff c_global/cstddef c_std/cstddef
26c26
<  *  This is a Standard C++ Library file.  You should @c \#include this file
---
>  *  This is a Standard C++ Library file.  You should @c #include this file

Re: [C++ PATCH] Fix option handling when -std=gnu++14 is not used (PR 69865)

[Bernd Edlinger]

Hi,

as almost expected r233572 needs to be back-ported to gcc-5 and gcc-4.9
branches in order to be built by gcc-6.  It applies cleanly to both
branches.  But unfortunately PR 69881 prevents boot-strapping gcc-4.9
in the moment.

Boot-strap and regression-test of gcc-5 on x86_64-pc-linux-gnu.
OK for gcc-5 and gcc-4.9 when PR 69881 is resolved?


Thanks
Bernd.
2016-02-20  Bernd Edlinger  

	Backported from mainline
	2016-02-19  Jakub Jelinek  
		Bernd Edlinger  

	* Make-lang.in: Invoke gperf with -L C++.
 	* cfns.gperf: Remove prototypes for hash and libc_name_p
 	inlines.
 	* cfns.h: Regenerated.
	* except.c (nothrow_libfn_p): Adjust.

Index: gcc/cp/Make-lang.in
===
--- gcc/cp/Make-lang.in	(revision 233574)
+++ gcc/cp/Make-lang.in	(working copy)
@@ -111,7 +111,7 @@ else
 # deleting the $(srcdir)/cp/cfns.h file.
 $(srcdir)/cp/cfns.h:
 endif
-	gperf -o -C -E -k '1-6,$$' -j1 -D -N 'libc_name_p' -L ANSI-C \
+	gperf -o -C -E -k '1-6,$$' -j1 -D -N 'libc_name_p' -L C++ \
 		$(srcdir)/cp/cfns.gperf --output-file $(srcdir)/cp/cfns.h
 
 #
Index: gcc/cp/cfns.gperf
===
--- gcc/cp/cfns.gperf	(revision 233574)
+++ gcc/cp/cfns.gperf	(working copy)
@@ -1,3 +1,5 @@
+%language=C++
+%define class-name libc_name
 %{
 /* Copyright (C) 2000-2015 Free Software Foundation, Inc.
 
@@ -16,14 +18,6 @@ for more details.
 You should have received a copy of the GNU General Public License
 along with GCC; see the file COPYING3.  If not see
 .  */
-#ifdef __GNUC__
-__inline
-#endif
-static unsigned int hash (const char *, unsigned int);
-#ifdef __GNUC__
-__inline
-#endif
-const char * libc_name_p (const char *, unsigned int);
 %}
 %%
 # The standard C library functions, for feeding to gperf; the result is used
Index: gcc/cp/cfns.h
===
--- gcc/cp/cfns.h	(revision 233574)
+++ gcc/cp/cfns.h	(working copy)
@@ -1,5 +1,5 @@
-/* ANSI-C code produced by gperf version 3.0.3 */
-/* Command-line: gperf -o -C -E -k '1-6,$' -j1 -D -N libc_name_p -L ANSI-C cfns.gperf  */
+/* C++ code produced by gperf version 3.0.4 */
+/* Command-line: gperf -o -C -E -k '1-6,$' -j1 -D -N libc_name_p -L C++ --output-file cfns.h cfns.gperf  */
 
 #if !((' ' == 32) && ('!' == 33) && ('"' == 34) && ('#' == 35) \
   && ('%' == 37) && ('&' == 38) && ('\'' == 39) && ('(' == 40) \
@@ -28,7 +28,7 @@
 #error "gperf generated tables don't work with this execution character set. Please report a bug to ."
 #endif
 
-#line 1 "cfns.gperf"
+#line 3 "cfns.gperf"
 
 /* Copyright (C) 2000-2015 Free Software Foundation, Inc.
 
@@ -47,26 +47,19 @@ for more details.
 You should have received a copy of the GNU General Public License
 along with GCC; see the file COPYING3.  If not see
 .  */
-#ifdef __GNUC__
-__inline
-#endif
-static unsigned int hash (const char *, unsigned int);
-#ifdef __GNUC__
-__inline
-#endif
-const char * libc_name_p (const char *, unsigned int);
 /* maximum key range = 391, duplicates = 0 */
 
-#ifdef __GNUC__
-__inline
-#else
-#ifdef __cplusplus
-inline
-#endif
-#endif
-static unsigned int
-hash (register const char *str, register unsigned int len)
+class libc_name
 {
+private:
+  static inline unsigned int hash (const char *str, unsigned int len);
+public:
+  static const char *libc_name_p (const char *str, unsigned int len);
+};
+
+inline unsigned int
+libc_name::hash (register const char *str, register unsigned int len)
+{
   static const unsigned short asso_values[] =
 {
   400, 400, 400, 400, 400, 400, 400, 400, 400, 400,
@@ -122,14 +115,8 @@ along with GCC; see the file COPYING3.  If not see
   return hval + asso_values[(unsigned char)str[len - 1]];
 }
 
-#ifdef __GNUC__
-__inline
-#ifdef __GNUC_STDC_INLINE__
-__attribute__ ((__gnu_inline__))
-#endif
-#endif
 const char *
-libc_name_p (register const char *str, register unsigned int len)
+libc_name::libc_name_p (register const char *str, register unsigned int len)
 {
   enum
 {
Index: gcc/cp/except.c
===
--- gcc/cp/except.c	(revision 233574)
+++ gcc/cp/except.c	(working copy)
@@ -1040,7 +1040,8 @@ nothrow_libfn_p (const_tree fn)
  unless the system headers are playing rename tricks, and if
  they are, we don't want to be confused by them.  */
   id = DECL_NAME (fn);
-  return !!libc_name_p (IDENTIFIER_POINTER (id), IDENTIFIER_LENGTH (id));
+  return !!libc_name::libc_name_p (IDENTIFIER_POINTER (id),
+   IDENTIFIER_LENGTH (id));
 }
 
 /* Returns nonzero if an exception of type FROM will be caught by a

[Bug libstdc++/69881] with gcc-6 of today building gcc-4.9 fails

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881

--- Comment #1 from Bernd Edlinger  ---
note: back-porting r233572 will still be necessary to build 4.9 with gcc-6
but the build fails earlier than that.

[Bug libstdc++/69881] New: with gcc-6 of today building gcc-4.9 fails

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69881

Bug ID: 69881
   Summary: with gcc-6 of today building gcc-4.9 fails
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

Created attachment 37742
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37742=edit
preprocessed source code

g++ -c   -g -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables
-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -fno-common  -DHAVE_CONFIG_H -I. -I.
-I../../gcc-4.9-branch/gcc -I../../gcc-4.9-branch/gcc/.
-I../../gcc-4.9-branch/gcc/../include
-I../../gcc-4.9-branch/gcc/../libcpp/include -I/home/ed/gnu/gcc-build2/./gmp
-I/home/ed/gnu/gcc-4.9-branch/gmp -I/home/ed/gnu/gcc-build2/./mpfr
-I/home/ed/gnu/gcc-4.9-branch/mpfr -I/home/ed/gnu/gcc-4.9-branch/mpc/src 
-I../../gcc-4.9-branch/gcc/../libdecnumber
-I../../gcc-4.9-branch/gcc/../libdecnumber/bid -I../libdecnumber
-I../../gcc-4.9-branch/gcc/../libbacktrace -DCLOOG_INT_GMP
-I/home/ed/gnu/gcc-build2/./cloog/include
-I/home/ed/gnu/gcc-4.9-branch/cloog/include -I../gcc-4.9-branch/cloog/include 
-I/home/ed/gnu/gcc-build2/./isl/include
-I/home/ed/gnu/gcc-4.9-branch/isl/include  -o graphite.o -MT graphite.o -MMD
-MP -MF ./.deps/graphite.TPo ../../gcc-4.9-branch/gcc/graphite.c
...
In file included from /home/ed/gnu/gcc-build2/./gmp/gmp.h:51:0,
 from /home/ed/gnu/gcc-4.9-branch/isl/include/isl/int.h:15,
 from /home/ed/gnu/gcc-4.9-branch/isl/include/isl/ctx.h:16,
 from /home/ed/gnu/gcc-4.9-branch/isl/include/isl/list.h:13,
 from /home/ed/gnu/gcc-4.9-branch/isl/include/isl/aff_type.h:4,
 from
/home/ed/gnu/gcc-4.9-branch/isl/include/isl/local_space.h:4,
 from
/home/ed/gnu/gcc-4.9-branch/isl/include/isl/constraint.h:13,
 from ../../gcc-4.9-branch/gcc/graphite.c:38:
/home/ed/gnu/install/include/c++/6.0.0/cstddef:51:11: error: '::max_align_t'
has not been declared
   using ::max_align_t;
   ^~~

[Bug testsuite/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test

[edlinger at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580

--- Comment #13 from Bernd Edlinger  ---
Author: edlinger
Date: Sat Feb 20 05:58:00 2016
New Revision: 233581

URL: https://gcc.gnu.org/viewcvs?rev=233581=gcc=rev
Log:
2016-02-20  Bernd Edlinger  

Backport from mainline
2016-02-18  Bernd Edlinger  

PR testsuite/68580
* c-c++-common/tsan/pr65400-1.c (v, q, o): Make 8-byte aligned.

Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/c-c++-common/tsan/pr65400-1.c

[Bug rtl-optimization/69806] [6 Regression][SH] Combine doesn't see constant

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69806

Oleg Endo  changed:

   What|Removed |Added

 CC||kyrylo.tkachov at arm dot com

--- Comment #8 from Oleg Endo  ---
CC'ing Kyrylo since he's the author of r233133.

[Bug c++/69743] [5/6 Regression] function overload with variadic arguments - template instantiation depth exceeds maximum (gcc4, clang - no problem)

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69743

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c++/69743] [5/6 Regression] function overload with variadic arguments - template instantiation depth exceeds maximum (gcc4, clang - no problem)

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69743

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Sat Feb 20 04:31:16 2016
New Revision: 233579

URL: https://gcc.gnu.org/viewcvs?rev=233579=gcc=rev
Log:
PR c++/69743
* call.c (remaining_arguments): No longer static.
* cp-tree.h: Declare it.
* pt.c (more_specialized_fn): Use it.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic167.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Sat Feb 20 04:31:29 2016
New Revision: 233580

URL: https://gcc.gnu.org/viewcvs?rev=233580=gcc=rev
Log:
PR c++/69743
* call.c (remaining_arguments): No longer static.
* cp-tree.h: Declare it.
* pt.c (more_specialized_fn): Use it.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/variadic167.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/call.c
branches/gcc-5-branch/gcc/cp/cp-tree.h
branches/gcc-5-branch/gcc/cp/pt.c

[Bug rtl-optimization/69806] [6 Regression][SH] Combine doesn't see constant

[olegendo at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69806

--- Comment #7 from Oleg Endo  ---
(In reply to Segher Boessenkool from comment #6)
> r233159 was reverted in r233356.  Does this problem still happen?

Yes, problem is still there, because ...

(In reply to Jakub Jelinek from comment #5)
> I think you should bisect it to the exact commit.
> The only combine.c change in that range is r233159, but there is e.g.
> r233133 cse.c change too etc.

I can confirm that r233133 is the actual cause.

[Bug c++/69743] [5/6 Regression] function overload with variadic arguments - template instantiation depth exceeds maximum (gcc4, clang - no problem)

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69743

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Sat Feb 20 04:31:16 2016
New Revision: 233579

URL: https://gcc.gnu.org/viewcvs?rev=233579=gcc=rev
Log:
PR c++/69743
* call.c (remaining_arguments): No longer static.
* cp-tree.h: Declare it.
* pt.c (more_specialized_fn): Use it.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/variadic167.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Sat Feb 20 04:31:29 2016
New Revision: 233580

URL: https://gcc.gnu.org/viewcvs?rev=233580=gcc=rev
Log:
PR c++/69743
* call.c (remaining_arguments): No longer static.
* cp-tree.h: Declare it.
* pt.c (more_specialized_fn): Use it.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/variadic167.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/call.c
branches/gcc-5-branch/gcc/cp/cp-tree.h
branches/gcc-5-branch/gcc/cp/pt.c

C++ PATCH for c++/69743 (wrong overload resolution with variadic templates)

[Jason Merrill]

My change to tsubst_pack_expansion to handle the special case of T... 
revealed a latent bug whereby we were considering the trailing "void" 
when comparing two variadic templates.  When we then try to deduce one 
from the other we get a parameter of type "void", which results in 
substitution failure.


Tested x86_64-pc-linux-gnu, applying to trunk and 5.
commit dfdc04172ec79a1a65f9e0d874556ace45915b99
Author: Jason Merrill 
Date:   Fri Feb 19 18:22:24 2016 -0500

	PR c++/69743
	* call.c (remaining_arguments): No longer static.
	* cp-tree.h: Declare it.
	* pt.c (more_specialized_fn): Use it.

diff --git a/gcc/cp/call.c b/gcc/cp/call.c
index cb71176..4226094 100644
--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -1905,7 +1905,7 @@ add_candidate (struct z_candidate **candidates,
 /* Return the number of remaining arguments in the parameter list
beginning with ARG.  */
 
-static int
+int
 remaining_arguments (tree arg)
 {
   int n;
diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
index 7800ae8..3c23a83a 100644
--- a/gcc/cp/cp-tree.h
+++ b/gcc/cp/cp-tree.h
@@ -5612,6 +5612,7 @@ extern tree make_temporary_var_for_ref_to_temp	(tree, tree);
 extern bool type_has_extended_temps		(tree);
 extern tree strip_top_quals			(tree);
 extern bool reference_related_p			(tree, tree);
+extern int remaining_arguments			(tree);
 extern tree perform_implicit_conversion		(tree, tree, tsubst_flags_t);
 extern tree perform_implicit_conversion_flags	(tree, tree, tsubst_flags_t, int);
 extern tree build_integral_nontype_arg_conv	(tree, tree, tsubst_flags_t);
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 7308389..65edfa7 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -20288,7 +20288,7 @@ more_specialized_fn (tree pat1, tree pat2, int len)
 
   if (TREE_CODE (arg1) == TYPE_PACK_EXPANSION)
 {
-  int i, len2 = list_length (args2);
+  int i, len2 = remaining_arguments (args2);
   tree parmvec = make_tree_vec (1);
   tree argvec = make_tree_vec (len2);
   tree ta = args2;
@@ -20312,7 +20312,7 @@ more_specialized_fn (tree pat1, tree pat2, int len)
 }
   else if (TREE_CODE (arg2) == TYPE_PACK_EXPANSION)
 {
-  int i, len1 = list_length (args1);
+  int i, len1 = remaining_arguments (args1);
   tree parmvec = make_tree_vec (1);
   tree argvec = make_tree_vec (len1);
   tree ta = args1;
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic167.C b/gcc/testsuite/g++.dg/cpp0x/variadic167.C
new file mode 100644
index 000..cada972
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic167.C
@@ -0,0 +1,18 @@
+// PR c++/69743
+// { dg-do compile { target c++11 } }
+
+template 
+void f(int, T... d)
+{
+}
+
+template 
+void f(T... d)
+{
+  f(1, d...);
+}
+
+void g(void)
+{
+  f(1.0);
+}

[Bug lto/69866] lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:158

[acrsofter at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69866

--- Comment #3 from acrsofter at gmail dot com ---

reproduce steps:

[foo.c]

int _umh(int i)
{
  return i+1;
}

int weaks(int i) __attribute__((weak, alias("_umh")));

int main()
{
 return weaks(10);
}


[bar.c]

int weaks(int i)
{
  return i+1;
}


now compile:

gcc -c bar.c

gcc -flto -c foo.c

gcc -flto -o elf bar.o foo.o


note:

bar compiled without flt
but rest with flt


now at linking stage booms
at line

 gcc_assert (c != SYMBOL_EXTERNAL
  && (c == SYMBOL_DUPLICATE || !symbol_partitioned_p (node)));

in lto/lto-partition.c

===

same code compiled without lto ok

gcc 4.9.3 not affected
but 5.3.0 affected and latest (gcc-6-20160214) affected

[Bug c/69880] New: Linking Windows resources + implicit 'default-manifest.o' creates bad .exe

[vsz.bugzilla at emailuser dot net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69880

Bug ID: 69880
   Summary: Linking Windows resources + implicit
'default-manifest.o' creates bad .exe
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsz.bugzilla at emailuser dot net
  Target Milestone: ---

Hi,

Sorry for the ambiguous title, I'm not completely sure where/what is the
culprit yet. Please bear with me.

While migrating to MSYS2 and its own mingw-w64 (5.3.0) toolchain (from a
non-MSYS2 build of the same toolchain), I stumbled into a problem. When linking
an application that has its own Windows resource, including a Windows Manifest,
I noticed that the final .exe is not compressible with UPX (3.91) anymore, with
the error:
   upx: my.exe: CantPackException: superfluous data between sections

Further investigation revealed that MSYS2 comes with a _default Windows
manifest_, as part of the toolchain. They are packaged as
`*windows-default-manifest`.

The GCC patch below made this feature possible, by automatically linking a
default resource object, whenever it's found on disk:
   https://gcc.gnu.org/ml/gcc-patches/2014-04/msg01378.html

The problem happens when the application is also supplying its own resource
object (like in my case), and above default resource object is found as well.
In this case _both_ objects get linked to the executable. It means that the
.exe now has _two_ manifests. This by itself is already an ambiguity and some
unnecessary bloat. But, the way these two objects are linked also causes the
second instance to be apparently "orphaned" between two valid sections (.rsrc
and .reloc in my particular case) of the executable.

This orphaned data seems to be confusing UPX, hence its fatal error.

The orphaned data can be discarded by using `strip -g test.exe` (or `strip
--strip-unneeded test.exe`). In my case it deleted the extra data, and UPX
worked again. I'm not sure this works in all possible cases though, and
unfortunately it strips other information too, f.e. digital signatures. Plus
this extra step requires a revamp of existing build scripts and tooling.

To my best knowledge mingw never handled linking multiple Windows resources
well, but so far this could be easily mitigated by either merging .rc files in
advance and/or avoiding to pass multiple resource objects explicitly. With the
newly added implicit object feature, such care can no longer be taken.

IMO it'd be nice to have option to disable picking up the implicit
`default-manifest.o` object (deleting it cannot always be done and/or cannot be
done cleanly), or even better automatically drop it if there is any user
supplied resource object. Cleverly merging them and dropping any duplicate
entries, while giving the user-supplied object a priority would also be
helpful, if feasible. Anyhow, the goal is to allow to have a _single_ manifest
in the final executable, controlled by the user.

Here's my original bug report with some more aspects/information, plus steps to
recreate a minimal example:
   https://github.com/Alexpux/MSYS2-packages/issues/454

-Viktor

better debug info for C++ cdtors, aliases, thunks and other trampolines

[Alexandre Oliva]

Keith Seitz reported we were missing debug information for cdtors.
E.g., we emit a specification for the unified ctor and dtor, but then,
if we emit one of the in-charge and not-in-charge versions as an alias
to the other, from the debug info PoV it's as if one of them didn't
exist.  If we emit declone them, emitting the unified cdtor and the
others are trampolines to it, it's as if we had an extra cdtor, because
there's no info that the others are just trampolines.

This patch implements some improvements in this regard:

- when we emit a symbol as an alias (or weakref) to another, we now emit
  a DW_TAG_imported_decl definition for it, naming the alias target's
  DIE in a DW_AT_import attribute.

- when we emit decloned cdtor trampolines, or other kinds of thunks, we
  now annotate their DIEs with DW_AT_trampoline, referencing the
  target's DIE.

I realize this is a bit late for GCC 6, but I figured I'd post it right
now, so that I can work on any required changes while it's still fresh
in my mind.  Now, if someone agrees it is safe enough even for 6, I
surely wouldn't mind that either ;-)

This was regstrapped on x86_64-linux-gnu and i686-linux-gnu, and I
checked for any regressions in the GDB test results too, for good
measure (there were none)

Ok to install, now or later?


support aliases and trampolines in dwarf2

for  gcc/ChangeLog

* debug.h (struct gcc_debug_hooks): Add aliased_decl and
trampoline_decl.
* dwarf2out.c (dwarf2out_aliased_decl): New.
(dwarf2out_trampoline_decl): New.
(dwarf2_debug_hooks): Add them.
(dwarf2_name): Skip leading '*' returned by langhook.
(dwarf2_lineno_debug_hooks): Add dummies.
* debug.c (do_nothing_debug_hooks): Likewise.
* dbxout.c (dbx_debug_hooks, xcoff_debug_hooks): Likewise.
* sdbout.c (sdb_debug_hooks): Likewise.
* vmsdbgout.c (vmsdbg_debug_hooks): Likewise.
* cgraph.h (cgraph_node::is_lang_trampoline): Declare.
* cgraphunit.c: Include demangle.h.
(cgraph_node::expand_thunk): Call function_decl debug_hook
after assembly expansion.  Do not mark thunk as ignored in
gimple expansion.
(cxx_cdtor_trampoline_p): New.
(cgraph_node::is_lang_trampoline): New.
(cgraph_node::assemble_thunks_and_aliases): Call the new
debug_hooks.
(symbol_table::output_weakrefs): Likewise.
* varpool.c (varpool_node::assemble_aliases): Likewise.

for  gcc/cp/ChangeLog

* method.c (make_alias_for): Copy DECL_IGNORED_P.

for  gcc/testsuite/ChangeLog

* g++.dg/debug/dwarf2/cdtor-1.C: Adjust linkage_name count.
* g++.dg/debug/dwarf2/cdtor-2.C: New.
* g++.dg/debug/dwarf2/cdtor-3.C: New.
* g++.dg/debug/dwarf2/covariant-1.C: New.
* gcc.dg/debug/dwarf2/attr-alias-1.c: New.
* gcc.dg/debug/dwarf2/attr-alias-2.c: New.
* gcc.dg/debug/dwarf2/attr-weakref-1.c: New.
* gcc.dg/debug/dwarf2/attr-weakref-2.c: New.
---
 gcc/cgraph.h   |4 +
 gcc/cgraphunit.c   |  134 +++-
 gcc/cp/method.c|1 
 gcc/dbxout.c   |4 +
 gcc/debug.c|2 
 gcc/debug.h|8 +
 gcc/dwarf2out.c|  100 +++
 gcc/sdbout.c   |2 
 gcc/testsuite/g++.dg/debug/dwarf2/cdtor-1.C|2 
 gcc/testsuite/g++.dg/debug/dwarf2/cdtor-2.C|   13 ++
 gcc/testsuite/g++.dg/debug/dwarf2/cdtor-3.C|   17 +++
 gcc/testsuite/g++.dg/debug/dwarf2/covariant-1.C|   24 
 gcc/testsuite/gcc.dg/debug/dwarf2/attr-alias-1.c   |   10 +
 gcc/testsuite/gcc.dg/debug/dwarf2/attr-alias-2.c   |   10 +
 gcc/testsuite/gcc.dg/debug/dwarf2/attr-weakref-1.c |   10 +
 gcc/testsuite/gcc.dg/debug/dwarf2/attr-weakref-2.c |   10 +
 gcc/varpool.c  |8 +
 gcc/vmsdbgout.c|2 
 18 files changed, 349 insertions(+), 12 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/cdtor-2.C
 create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/cdtor-3.C
 create mode 100644 gcc/testsuite/g++.dg/debug/dwarf2/covariant-1.C
 create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/attr-alias-1.c
 create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/attr-alias-2.c
 create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/attr-weakref-1.c
 create mode 100644 gcc/testsuite/gcc.dg/debug/dwarf2/attr-weakref-2.c

diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index fc7bb22..4d8bf05 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -1117,6 +1117,10 @@ public:
  external means.  */
   inline void mark_force_output (void);
 
+  /* Return true when function is a language-defined trampoline, e.g.,
+ C++ ctor and dtor "thunks" that 

Re: [isocpp-parallel] Proposal for new memory_order_consume definition

[Tony V E]

There's at least one easy answer in there:

> ‎If implementations must support annotation, what form should that
annotation take?  P0190R0 recommends the [[carries_dependency]]
attribute, but I am not picky as long as it can be (1) applied
to all relevant pointer-like objects and (2) used in C as well
as C++.  ;-)

If an implementation must support it, then it is not an annotation but a 
keyword. So no [[]] 



Sent from my BlackBerry portable Babbage Device
  Original Message  
From: Paul E. McKenney
Sent: Thursday, February 18, 2016 4:58 AM
To: paral...@lists.isocpp.org; linux-ker...@vger.kernel.org; 
linux-a...@vger.kernel.org; gcc@gcc.gnu.org; llvm-...@lists.llvm.org
Reply To: paral...@lists.isocpp.org
Cc: pet...@infradead.org; j.algl...@ucl.ac.uk; will.dea...@arm.com; 
dhowe...@redhat.com; ramana.radhakrish...@arm.com; luc.maran...@inria.fr; 
a...@linux-foundation.org; peter.sew...@cl.cam.ac.uk; 
torva...@linux-foundation.org; mi...@kernel.org
Subject: [isocpp-parallel] Proposal for new memory_order_consume definition

Hello!

A proposal (quaintly identified as P0190R0) for a new memory_order_consume
definition may be found here:

http://www2.rdrop.com/users/paulmck/submission/consume.2016.02.10b.pdf

As requested at the October C++ Standards Committee meeting, this
is a follow-on to P0098R1 that picks one alternative and describes
it in detail. This approach focuses on existing practice, with the
goal of supporting existing code with existing compilers. In the last
clang/LLVM patch I saw for basic support of this change, you could count
the changed lines and still have lots of fingers and toes left over.
Those who have been following this story will recognize that this is
a very happy contrast to work that would be required to implement the
definition in the current standard.

I expect that P0190R0 will be discussed at the upcoming C++ Standards
Committee meeting taking place the week of February 29th. Points of
discussion are likely to include:

o   May memory_order_consume dependency ordering be used in
unannotated code? I believe that this must be the case,
especially given that this is our experience base. P0190R0
therefore recommends this approach.

o   If memory_order_consume dependency ordering can be used in
unannotated code, must implementations support annotation?
I believe that annotation support should be required, at the very
least for formal verification, which can be quite difficult to
carry out on unannotated code. In addition, it seems likely
that annotations can enable much better diagnostics. P0190R0
therefore recommends this approach.

o   If implementations must support annotation, what form should that
annotation take? P0190R0 recommends the [[carries_dependency]]
attribute, but I am not picky as long as it can be (1) applied
to all relevant pointer-like objects and (2) used in C as well
as C++. ;-)

o   If memory_order_consume dependency ordering can be used in
unannotated code, how best to define the situations where
the compiler can determine the exact value of the pointer in
question? (In current defacto implementations, this can
defeat dependency ordering. Interestingly enough, this case
is not present in the Linux kernel, but still needs to be
defined.)

Options include:

o   Provide new intrinsics that carry out the
comparisons, but guarantee to preserve dependencies,
as recommended by P0190R0 (std::pointer_cmp_eq_dep(),
std::pointer_cmp_ne_dep(), std::pointer_cmp_gt_dep(),
std::pointer_cmp_ge_dep(), std::pointer_cmp_lt_dep(),
and std::pointer_cmp_le_dep()).

o   State that -any- comparison involving an unannotated
pointer loses the dependency.

o   How is the common idiom of marking pointers by setting low-order
bits to be supported when those pointers carry dependencies?
At the moment, I believe that setting bits in pointers results in
undefined behavior even without dependency ordering, so P0190R0
kicks this particular can down the road. One option that
has been suggested is to provide intrinsics for this purpose.
(Sorry, but I forget who suggested this.)

Thoughts?

Thanx, Paul

___
Parallel mailing list
paral...@lists.isocpp.org
Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/parallel
Link to this post: http://lists.isocpp.org/parallel/2016/02/0040.php

Re: AW: Wonly-top-basic-asm

[David Wohlferd]

On 2/13/2016 8:00 PM, David Wohlferd wrote:

Fair enough.  Committing what we can right now sounds like a good plan.


Attached is the doc patch, minus the proposed warning.

ChangeLog:

2016-02-19  David Wohlferd  
Bernd Schmidt  

* doc/extend.texi: Doc basic asm behavior re clobbers.

dw

Index: extend.texi
===
--- extend.texi	(revision 233367)
+++ extend.texi	(working copy)
@@ -7458,7 +7458,8 @@
 @end table
 
 @subsubheading Remarks
-Using extended @code{asm} typically produces smaller, safer, and more
+Using extended @code{asm} (@pxref{Extended Asm}) typically produces smaller,
+safer, and more
 efficient code, and in most cases it is a better solution than basic
 @code{asm}.  However, there are two situations where only basic @code{asm}
 can be used:
@@ -7498,10 +7499,25 @@
 symbol errors during compilation if your assembly code defines symbols or 
 labels.
 
-Since GCC does not parse the @var{AssemblerInstructions}, it has no 
-visibility of any symbols it references. This may result in GCC discarding 
-those symbols as unreferenced.
+@strong{Warning:} The C standards do not specify semantics for @code{asm},
+making it a potential source of incompatibilities between compilers.  These
+incompatibilities may not produce compiler warnings/errors.
 
+GCC does not parse basic @code{asm}'s @var{AssemblerInstructions}, which
+means there is no way to communicate to the compiler what is happening
+inside them.  GCC has no visibility of symbols in the @code{asm} and may
+discard them as unreferenced.  It also does not know about side effects of
+the assembler code, such as modifications to memory or registers.  Unlike
+some compilers, GCC assumes that no changes to either memory or registers
+occur.  This assumption may change in a future release.
+
+To avoid complications from future changes to the semantics and the
+compatibility issues between compilers, consider replacing basic @code{asm}
+with extended @code{asm}.  See
+@uref{https://gcc.gnu.org/wiki/ConvertBasicAsmToExtended, How to convert
+from basic asm to extended asm} for information about how to perform this
+conversion.
+
 The compiler copies the assembler instructions in a basic @code{asm} 
 verbatim to the assembly language output file, without 
 processing dialects or any of the @samp{%} operators that are available with
@@ -7516,11 +7532,25 @@
 Basic @code{asm} provides no
 mechanism to provide different assembler strings for different dialects.
 
-Here is an example of basic @code{asm} for i386:
+Here is an example of top-level basic @code{asm} for i386 that defines an
+asm macro.  That macro is then invoked from within a function using
+extended @code{asm}:
 
 @example
-/* Note that this code will not compile with -masm=intel */
-#define DebugBreak() asm("int $3")
+/* Define macro at file scope with basic asm.  */
+/* Add macro parameter p to eax.  */
+asm (".macro testme p\n\t"
+"addl $\\p, %eax\n\t"
+".endm");
+
+/* Use macro in function using extended asm.  It needs
+   the "cc" clobber since the flags are changed and uses
+   the "a" constraint since it modifies eax.  */
+int DoAdd (int value)
+@{
+   asm ("testme 5" : "+a" (value) : : "cc");
+   return value;
+@}
 @end example
 
 @node Extended Asm

[Bug libstdc++/57272] node-based containers don't use allocator's pointer type internally

[philippeb8 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57272

--- Comment #6 from Phil Bouchard  ---
Also please make sure the pointer arguments are passed by reference and not by
value.  This would ensure we could use our own smart pointers.

[Bug c++/69743] [5/6 Regression] function overload with variadic arguments - template instantiation depth exceeds maximum (gcc4, clang - no problem)

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69743

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-02-19
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/69865] -trigraphs option broken

[bernd.edlinger at hotmail dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69865

Bernd Edlinger  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Bernd Edlinger  ---
fixed on trunk.
gcc-5 does not have this issue.

Re: [PATCH] 69759 - document __builtin_alloca and __builtin_alloca_with_align

[Joseph Myers]

On Fri, 19 Feb 2016, Martin Sebor wrote:

> > ... Here I'd like to get my updated patch reviewed so that I
> > can move on to my other GCC 6 tasks.
> 
> I integrated the documentation update into the coding patch for bug
> 69780 - [4.9/5/6 Regression] ICE on __builtin_alloca_with_align, to
> keep the two in sync.
> 
> Jakub has reviewed and approved the code changes but defers
> the documentation review to you.  The most recent combined patch
> is at the link below:
> 
>   https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01227.html

"doesn't cause it doesn't exceed" doesn't make sense.

I think when you talk about VLAs you should link to the relevant section 
of the manual.

I don't think "allocates an object @var{align} bytes large" is correct 
(it's size bytes large, not align bytes large, surely?).

"@code{g()}" is contrary to the GNU Coding Standards: "Please do not write 
@samp{()} after a function name just to indicate it is a function.  
@code{foo ()} is not a function, it is a function call with no 
arguments.".

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

[Bug target/69868] vec_perm built-in is not handled by swap optimization on powerpc64le

[wschmidt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69868

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-02-19
 Ever confirmed|0   |1

--- Comment #1 from Bill Schmidt  ---
Confirmed.

Re: Manipulating bit fields is behaving inconsistently

[Joseph Myers]

On Fri, 19 Feb 2016, Wink Saville wrote:

> The two links in msg00156.html point to single emails and the
> formatting is odd, such as in 13560.txt:
> 
>   i =3D =5FGeneric(st.bf,
> 
> Is there a way to look at the actual email thread using a browser or
> some other means?

I'm not aware of any WG14 reflector archive other than that one providing 
the raw MIME form of the emails at URLs based on the individual message 
numbers as they were distributed by the reflector.  You'll need to keep 
adding 1 to the number to get successive messages to the reflector.

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

Re: How to use _Generic with bit-fields

[Joseph Myers]

On Fri, 19 Feb 2016, Wink Saville wrote:

> And I've tried to use _Generic to print the type of a bit field but
> the compiler fails with:

Indeed, bit-field types cannot match any type name, only default.  The 
only conversions applied to the controlling expression are those involved 
in lvalue to rvalue conversion (at least, that's what's currently 
implemented, and is the current direction on DR#481).  In particular, the 
integer promotions (which would convert this bit-field to int) are not 
applied.

You can of course use unary + (or various other constructs depending on 
the set of possible types) to cause some promotions.

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

Re: [PATCH PR69052]Check if loop inv can be propagated into mem ref with additional addr expr canonicalization

[Jeff Law]

On 02/16/2016 11:43 AM, Bin Cheng wrote:


From: Jeff Law 
Sent: 11 February 2016 23:26
To: Bin.Cheng
Cc: Bin Cheng; gcc-patches@gcc.gnu.org; nd
Subject: Re: [PATCH PR69052]Check if loop inv can be propagated into mem ref 
with additional addr expr canonicalization


On 02/11/2016 10:59 AM, Bin.Cheng wrote:



Hi Jeff,
Thanks for detailed review.  I also think a generic canonical
interface for RTL is much better.  I will give it a try.  But with
high chance it's a next stage1 stuff.

That is, of course, fine.  However, if you do get something ready, I'd
support using it within LICM for gcc-6, then using it in other places
for gcc-7.

Hi,
This is the updated version patch.  It fixes the problem by introducing a 
generic address canonicalization interface.  This new interface canonicalizes 
address expression in following steps:
  1) Rewrite ASHIFT into MULT recursively.
  2) Divide address into sub expressions with PLUS as the separator.
  3) Sort sub expressions according to precedence defined for communative 
operations.
  4) Simplify CONST_INT_P sub expressions.
  5) Create new canonicalized address and return.

According to review comments, this interface is now restricted in LCIM, and 
will probably be expanded to other passes like fwprop and combine after 
entering GCC7.
Bootstrap and test on x86_64 and AArch64.  Is it OK?

Thanks,
bin

2016-02-15  Bin Cheng  

PR tree-optimization/69052
* loop-invariant.c (canonicalize_address_mult): New function.
(MAX_CANON_ADDR_PARTS): New macro.
(collect_address_parts): New function.
(compare_address_parts, canonicalize_address): New functions.
(inv_can_prop_to_addr_use): Check validity of address expression
which is canonicalized by above canonicalize_address.

gcc/testsuite/ChangeLog
2016-02-15  Bin Cheng  

PR tree-optimization/69052
* gcc.target/i386/pr69052.c: New test.

This is exactly what I was looking for from a design standpoint.

My only question is why didn't you use FOR_EACH_SUBRTX_VRA from 
rtl-iter.h to walk the RTX expressions in collect_address_parts and 
canonicalize_address_mult?


Jeff






Jeff

[Bug driver/69805] [6 Regression] ICE in greater_than_spec_func, at gcc.c:9722

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69805

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug c++/69865] -trigraphs option broken

[edlinger at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69865

--- Comment #9 from Bernd Edlinger  ---
Author: edlinger
Date: Fri Feb 19 22:22:04 2016
New Revision: 233574

URL: https://gcc.gnu.org/viewcvs?rev=233574=gcc=rev
Log:
gcc/c-family/ChangeLog:
2016-02-19  Bernd Edlinger  

PR c++/69865
* c-opts.c (c_common_post_options): Move call to set_std_cxx14 from
here...
(c_common_init_options): ...to here.
(set_std_cxx98): Initialize flag_isoc94 and flag_isoc99.

gcc/testsuite/ChangeLog:
2016-02-19  Bernd Edlinger  

PR c++/69865
* c-c++-common/Wshift-negative-value-6.c: Add -std=c++11 before
-std=c++03.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-opts.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/c-c++-common/Wshift-negative-value-6.c

[Bug c/69878] GCC produces pessimal assembly for C11 atomic increments

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69878

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #1 from Jakub Jelinek  ---
Dup of PR68908.

*** This bug has been marked as a duplicate of bug 68908 ***

[Bug c/68908] inefficient code for _Atomic operations

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68908

Jakub Jelinek  changed:

   What|Removed |Added

 CC||matt at bitbashing dot io

--- Comment #18 from Jakub Jelinek  ---
*** Bug 69878 has been marked as a duplicate of this bug. ***

[Bug driver/69805] [6 Regression] ICE in greater_than_spec_func, at gcc.c:9722

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69805

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb 19 22:18:38 2016
New Revision: 233573

URL: https://gcc.gnu.org/viewcvs?rev=233573=gcc=rev
Log:
PR driver/69805
* gcc.c (LINK_COMMAND_SPEC, GOMP_SELF_SPECS): Use
:%* in %:gt() argument.
(greater_than_spec_func): Adjust for expecting only numbers,
if there are more than two numbers, compare the last two.

* testsuite/libgomp.c/pr69805.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.c/pr69805.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gcc.c
trunk/libgomp/ChangeLog

Re: [PATCH] Fix driver handling of multiple -ftree-parallelize-loops= options (PR driver/69805)

[Jeff Law]

On 02/16/2016 08:24 AM, Jakub Jelinek wrote:

Hi!

As mentioned in the PR, %{ftree-parallelize-loops=*} expands to
all -ftree-parallelize-loops= options, not just the last one.
So greater_than_spec_func is actually called say for
-ftree-parallelize-loops=0 -ftree-parallelize-loops=2 with
- ftree-parallelize-loops=0 - ftree-parallelize-loops=2 1
(each whitespace separated sequence separate arg), but it asserts
it sees just 3 arguments.
Passing the - and ftree-parallelize-loops= stuff looks weird,
and we have %* that substitutes just the variable part of the option,
so in addition to fixing the case of multiple options I've also changed
%:gt() behaviour, so that it now gets just the numbers and compares the
last two of them.  So for the above options it would be called with
0 2 1
and would compare
2 > 1
and return "", or for
-ftree-parallelize-loops=2 -ftree-parallelize-loops=0 -ftree-parallelize-loops=1
would be
2 0 1 1
and compare
1 > 1
and return NULL. %:gt() is not used anywhere else, and has been introduced
only in GCC 6.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2016-02-16  Jakub Jelinek  

PR driver/69805
* gcc.c (LINK_COMMAND_SPEC, GOMP_SELF_SPECS): Use
:%* in %:gt() argument.
(greater_than_spec_func): Adjust for expecting only numbers,
if there are more than two numbers, compare the last two.

* testsuite/libgomp.c/pr69805.c: New test.
I'll note that Tom ack'd in c#3, and he certainly know this 
functionality better than I.  So OK for trunk.


Jeff

[Bug c++/69826] problem with cilkplus pragma and preprocessor variable

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69826

--- Comment #9 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug c++/69826] problem with cilkplus pragma and preprocessor variable

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69826

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb 19 22:12:54 2016
New Revision: 233571

URL: https://gcc.gnu.org/viewcvs?rev=233571=gcc=rev
Log:
PR c++/69826
* c-pragma.c (c_pp_lookup_pragma): Handle PRAGMA_CILK_GRAINSIZE.
(init_pragma): Register PRAGMA_CILK_GRAINSIZE even for
flag_preprocess_only.

* c-c++-common/cilk-plus/CK/pr69826-1.c: New test.
* c-c++-common/cilk-plus/CK/pr69826-2.c: New test.

Added:
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/pr69826-1.c
trunk/gcc/testsuite/c-c++-common/cilk-plus/CK/pr69826-2.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-pragma.c
trunk/gcc/testsuite/ChangeLog

Re: RFA: Prevent an ICE when redeclaring a static function as weak

[Jeff Law]

On 02/17/2016 07:24 AM, Nick Clifton wrote:

Hi Guys,

   Redefining a previously defined static function as both public and
   weak triggers an ICE in ipa-visibility.c:

internal compiler error: in function_and_variable_visibility, at 
ipa-visibility.c:518

   This bug has been discussed and patch proposed here:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49899

   This submission is an updated version of that patch, made against
   the latest gcc sources.  It still chooses to generate an error message
   and disallow the conversion, which I hope is the correct action.

   OK to apply ?

Cheers
   Nick

gcc/ChangeLog
2016-02-17  Nick Clifton  

PR middle-end/49889
* varasm.c (merge_weak): Generate an error if an attempt is made
to convert a non-weak static function into a weak, public function.

gcc/testsuite/ChangeLog
2016-02-17  Nick Clifton  

PR middle-end/49889
* gcc.dg/pr49889.c: New test.
Does this fix a regression?  Essentially I'm trying to figure out if we 
want this for gcc-6 or gcc-7.


jeff

Fix PR44281 (bad RA with global regs)

[Bernd Schmidt]

In this PR, we generate unnecessarily bad code for code that declares a 
global register var. Since global regs get added to fixed_regs, IRA 
never considers them as candidates. However, we do seem to have proper 
data flow information for them. In the testcase, the global reg dies, 
some operations are done on temporary results, and the final result 
stored back in the global reg. We can achieve the desired code 
generation by reusing the global reg for those temporaries.


Bootstrapped and tested on x86_64-linux. Ok? An argument could be made 
not to use this for gcc-6 since global register vars are both not very 
important and not very well represented in the testsuite.



Bernd
	PR rtl-optimization/44281
	* hard-reg-set.h (struct target_hard_regs): New field
	x_fixed_nonglobal_reg_set.
	(fixed_nonglobal_reg_set): New macro.
	* reginfo.c (init_reg_sets_1): Initialize it.
	* ira.c (setup_alloc_regs): Use fixed_nonglobal_reg_set instead
	of fixed_reg_set.

	PR rtl-optimization/44281
	* gcc.target/i386/pr44281.c: New test.

Index: gcc/hard-reg-set.h
===
--- gcc/hard-reg-set.h	(revision 233451)
+++ gcc/hard-reg-set.h	(working copy)
@@ -660,6 +660,12 @@ struct target_hard_regs {
  across calls even if we are willing to save and restore them.  */
   HARD_REG_SET x_call_fixed_reg_set;
 
+  /* Contains registers that are fixed use -- i.e. in fixed_reg_set -- but
+ only if they are not merely part of that set because they are global
+ regs.  Global regs that are not otherwise fixed can still take part
+ in register allocation.  */
+  HARD_REG_SET x_fixed_nonglobal_reg_set;
+
   /* Contains 1 for registers that are set or clobbered by calls.  */
   /* ??? Ideally, this would be just call_used_regs plus global_regs, but
  for someone's bright idea to have call_used_regs strictly include
@@ -722,6 +728,8 @@ extern struct target_hard_regs *this_tar
   (this_target_hard_regs->x_fixed_regs)
 #define fixed_reg_set \
   (this_target_hard_regs->x_fixed_reg_set)
+#define fixed_nonglobal_reg_set \
+  (this_target_hard_regs->x_fixed_nonglobal_reg_set)
 #define call_used_regs \
   (this_target_hard_regs->x_call_used_regs)
 #define call_really_used_regs \
Index: gcc/ira.c
===
--- gcc/ira.c	(revision 233451)
+++ gcc/ira.c	(working copy)
@@ -512,7 +512,7 @@ setup_alloc_regs (bool use_hard_frame_p)
 #ifdef ADJUST_REG_ALLOC_ORDER
   ADJUST_REG_ALLOC_ORDER;
 #endif
-  COPY_HARD_REG_SET (no_unit_alloc_regs, fixed_reg_set);
+  COPY_HARD_REG_SET (no_unit_alloc_regs, fixed_nonglobal_reg_set);
   if (! use_hard_frame_p)
 SET_HARD_REG_BIT (no_unit_alloc_regs, HARD_FRAME_POINTER_REGNUM);
   setup_class_hard_regs ();
Index: gcc/reginfo.c
===
--- gcc/reginfo.c	(revision 233451)
+++ gcc/reginfo.c	(working copy)
@@ -449,6 +449,7 @@ init_reg_sets_1 (void)
 }
 
   COPY_HARD_REG_SET (call_fixed_reg_set, fixed_reg_set);
+  COPY_HARD_REG_SET (fixed_nonglobal_reg_set, fixed_reg_set);
 
   /* Preserve global registers if called more than once.  */
   for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
Index: gcc/testsuite/gcc.target/i386/pr44281.c
===
--- gcc/testsuite/gcc.target/i386/pr44281.c	(revision 0)
+++ gcc/testsuite/gcc.target/i386/pr44281.c	(working copy)
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target lp64 } */
+/* { dg-options "-std=gnu99 -O2" } */
+/* { dg-final { scan-assembler "salq\[ \\t\]+\\\$8, %rbx" } } */
+
+#include 
+
+register uint64_t global_flag_stack __asm__("rbx");
+
+void push_flag_into_global_reg_var(uint64_t a, uint64_t b) {
+  uint64_t flag = (a==b);
+  global_flag_stack <<= 8;
+  global_flag_stack  |= flag;
+}

Re: gnu-gabi group

[Ian Lance Taylor]

On Fri, Feb 19, 2016 at 1:16 PM, Mark Wielaard  wrote:
> On Fri, Feb 19, 2016 at 12:57:34PM -0800, H.J. Lu wrote:
>> How do I subscribe gnu-abi mailing list?  The project page just
>> points to the mailing list archive.  There is no option to subscribe
>> it.
>
> To subscribe sent email to gnu-abi-subscr...@sourceware.org

It's actually gnu-gabi.  Send mail to gnu-gabi-subscr...@sourceware.org.

Ian

Re: [PATCH][AArch64][v2] Skip gcc.target/aarch64/assembler_arch_1.c if assembler does not support it

[Jeff Law]

On 02/17/2016 09:06 AM, Kyrill Tkachov wrote:

Hi all,

I've thought about this check a bit more and I think we can compactly
auto-generate checks
for any aarch64 architecture extension support in the assembler.
This is done in a similar way we autogenerate the arm_arch_*_ok checks
for arm.

So in this revision we autogenerate aarch64_asm__ok checks for
every architecture extension
using some of the expect machinery. This should make this approach a bit
more general to handle
checks for any .arch_extension argument without much extra cost.

This still assumes that the assembler supports the .arch_extension
pseudo-op, the effective
target check will fail if it doesn't. This is what we want for this
testcase.

Is this patch ok instead of
https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01052.html ?

Thanks,
Kyrill

2016-02-17  Kyrylo Tkachov  

 * lib/target-supports.exp: Define aarch64_asm_FUNC_ok checks
 for fp, simd, crypto, crc, lse.
 * doc/sourcebuild.texi (AArch64-specific attributes): Document the
 above.
 * gcc.target/aarch64/assembler_arch_1.c: Add aarch64_asm_lse_ok
 effective target check.

Yes, this is fine.
jeff

Re: [PATCH] Add configure flag for operator new (std::nothrow)

[Daniel Gutson]

On Mon, Nov 16, 2015 at 3:56 PM, Pedro Alves  wrote:
> On 11/10/2015 01:10 PM, Jonathan Wakely wrote:
>> On 06/11/15 09:59 +, Pedro Alves wrote:
>>> On 11/06/2015 01:56 AM, Jonathan Wakely wrote:
 On 5 November 2015 at 23:31, Daniel Gutson
>>>
> The issue is, as I understand it, to do the actual work of operator
> new, i.e. allocate memory. It should force
> us to copy most of the code of the original code of operator new,
> which may change on new versions of the
> STL, forcing us to keep updated.

 It can just call malloc, and the replacement operator delete can call free.

 That is very unlikely to need to change (which is corroborated by the
 fact that the default definitions in libsupc++ change very rarely).
>>>
>>> Or perhaps libsupc++ could provide the default operator new under
>>> a __default_operator_new alias or some such, so that the user-defined
>>> replacement can fallback to calling it.  Likewise for op delete.
>>
>> That could be useful, please file an enhancement request in bugzilla
>> if you'd like that done.
>>
>
> I'll leave that to Daniel/Aurelio.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69879

Please assign it to Aurelio.

Thanks and thanks Pedro for the idea.

   Daniel.

>
> Thanks,
> Pedro Alves
>



-- 

Daniel F. Gutson
Chief Engineering Officer, SPD

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

Phone:   +54 351 4217888 / +54 351 4218211
Skype:dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson

[Bug libstdc++/69879] New: Create a pointer to the default operator new and delete

[daniel.gutson at tallertechnologies dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69879

Bug ID: 69879
   Summary: Create a pointer to the default operator new and
delete
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.gutson at tallertechnologies dot com
  Target Milestone: ---

This issue comes from the following discussion:

https://gcc.gnu.org/ml/libstdc++/2015-11/msg9.html

In short: Pedro Alves suggested as a solution the addition of a pointer to the
original (default) operator new and another for the operator delete, e.g.
__default_operator_new and __default_operator_delete.
This will allow users to override the global operators new and delete, and yet
call the original implementations, for example to alter the behavior when there
is no memory and the nothrow new should not iterate calling the new_handler.

// Example 1:

void* operator new  ( std::size_t count, const std::nothrow_t& tag)
noexcept(true)
{
const auto old_handler = std::set_new_handler(nullptr);
const auto ret = __default_operator_new(count, tag);
std::set_new_handler(old_handler);
return ret;
}


// Slightly different example:

void* operator new  ( std::size_t count, const std::nothrow_t& tag)
noexcept(true)
{
const auto old_handler = std::set_new_handler(nullptr);
const auto ret = __default_operator_new(count, tag);
std::set_new_handler(old_handler);

if (ret == nullptr && old_handler != nullptr)
old_handler();

return ret;
}

Please assign this to aurelio.remo...@tallertechnologies.com

i386: add a variant peephole for decl (mem)

[Bernd Schmidt]

PR 49095 requested the following optimization:

-   movl-120(%rax), %ecx
-   leal-1(%rcx), %edx
-   movl%edx, -120(%rax)
-   testl   %edx, %edx
+   subl$1, -120(%rax)
jne .L92

The PR was fixed by adding a peephole, but it doesn't actually trigger 
for the code sequence quoted above. This is because the pattern expects 
to see a parallel including a clobber of CC, which is what you'd get for 
a normal add or logical operation. For lea, this does not match: the 
clobber is missing, and also the input and output operands can be different.


This shows up with some IRA cost changes I'm testing for a different PR. 
The following patch adds a variant peephole. It would be a prerequisite 
for those IRA changes so as to not regress an existing testcase. The new 
peephole triggers a few times in my collection of .i files.


Bootstrapped and tested on x86_64-linux.  Ok?



Bernd
	* config/i386/i386.md (operation on memory peephole): Duplicate an
	existing peephole and adapt it to match lea rather than an operation
	that clobbers CC.

Index: gcc/config/i386/i386.md
===
--- gcc/config/i386/i386.md	(revision 233451)
+++ gcc/config/i386/i386.md	(working copy)
@@ -17952,6 +17952,38 @@ (define_peephole2
  operands[5], const0_rtx);
 })
 
+;; Likewise for instances where we have a lea pattern.
+(define_peephole2
+  [(set (match_operand:SWI 0 "register_operand")
+	(match_operand:SWI 1 "memory_operand"))
+   (set (match_operand:SWI 3 "register_operand")
+	(plus (match_dup 0)
+	  (match_operand:SWI 2 "")))
+   (set (match_dup 1) (match_dup 3))
+   (set (reg FLAGS_REG) (compare (match_dup 3) (const_int 0)))]
+  "(TARGET_READ_MODIFY_WRITE || optimize_insn_for_size_p ())
+   && peep2_reg_dead_p (4, operands[3])
+   && (rtx_equal_p (operands[0], operands[3])
+   || peep2_reg_dead_p (2, operands[0]))
+   && !reg_overlap_mentioned_p (operands[0], operands[1])
+   && !reg_overlap_mentioned_p (operands[3], operands[1])
+   && !reg_overlap_mentioned_p (operands[0], operands[2])
+   && (mode != QImode
+   || immediate_operand (operands[2], QImode)
+   || any_QIreg_operand (operands[2], QImode))
+   && ix86_match_ccmode (peep2_next_insn (3), CCGOCmode)"
+  [(parallel [(set (match_dup 4) (match_dup 5))
+	  (set (match_dup 1) (plus:SWI (match_dup 1)
+	   (match_dup 2)))])]
+{
+  operands[4] = SET_DEST (PATTERN (peep2_next_insn (3)));
+  operands[5] = gen_rtx_PLUS (mode,
+			  copy_rtx (operands[1]),
+			  copy_rtx (operands[2]));
+  operands[5] = gen_rtx_COMPARE (GET_MODE (operands[4]),
+ operands[5], const0_rtx);
+})
+
 (define_peephole2
   [(parallel [(set (match_operand:SWI 0 "register_operand")
 		   (match_operator:SWI 2 "plusminuslogic_operator"

Re: gnu-gabi group

[H.J. Lu]

On Fri, Feb 19, 2016 at 1:16 PM, Mark Wielaard  wrote:
> On Fri, Feb 19, 2016 at 12:57:34PM -0800, H.J. Lu wrote:
>> How do I subscribe gnu-abi mailing list?  The project page just
>> points to the mailing list archive.  There is no option to subscribe
>> it.
>
> To subscribe sent email to gnu-abi-subscr...@sourceware.org
> Or use the subscribe form at https://sourceware.org/lists.html#ml-requestor

Have you tried?  It doesn't works for me.

Hi. This is the qmail-send program at sourceware.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is a copy of the message.

Return-Path: 
Received: (qmail 45923 invoked by uid 89); 19 Feb 2016 21:51:27 -
Authentication-Results: sourceware.org; auth=none
X-Virus-Checked: by ClamAV 0.99 on sourceware.org
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.4 required=5.0
tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS
autolearn=ham version=3.3.2 spammy=
X-Spam-Status: No, score=-2.4 required=5.0
tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS
autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org
X-Spam-Level:
X-HELO: mail-qg0-f51.google.com
Received: from mail-qg0-f51.google.com (HELO mail-qg0-f51.google.com)
(209.85.192.51)
 by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with
(AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 19 Feb 2016 21:51:26 +
Received: by mail-qg0-f51.google.com with SMTP id y89so72346223qge.2
for ; Fri, 19 Feb 2016
13:51:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:date:message-id:subject:from:to:content-type;
bh=eZC3LtZL7BXxfyIFtklb/yLCrPguGar0iu8XP/9UuyU=;
b=se5z8Q6PBBZxlt9AGx5aQY6dZhG0ksLTMm3tPhsKq9RFsP6r9bpoR9sLJbv+BnMoAu
 M8hD6qclE47HF1x54w23yGrx7CpbZMUdXiwa+9n/Q6ZQIQRgsbGrWrd4QohsGGyZaCrz
 t53H9J4NykEZyNwNCGgn5+jhW80KC2QKFYcDmCUdsA+59OjF+u2VavrVC+QUmSeoD9S1
 0ZNiR9grsoX7cuHi2H2LLefY1mgki7dI/aQMC/mReqEIfJVU24CXXLXvUSLkF/jqLlQS
 vmK+uFMr1S4L4L8aFoTZmxQUhEv4U7dGVyc9HduLZsTygt8/EyS4Sgzp8O5w4RuihkXK
 FxIg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:date:message-id:subject:from:to
 :content-type;
bh=eZC3LtZL7BXxfyIFtklb/yLCrPguGar0iu8XP/9UuyU=;
b=HwhJg/b727DM0KPtKbwcgRM8tlamj8wWLwxxc6fV9Z4bUdSKn/RCaciMaCar4f6FFl
 wr+vNsi8FP+2MbubOnpjrVvLIlwlbPPoTi23BP/vKzqJgkJ/WivaY4Pwc7wOhpOp7WmG
 W2UmxFNCX7YGEzPx3XVxXDygarKYGtxCM7VO2l0VOka1ryex0K/w1ElOeqO7QBVD3ljH
 07qSDt5Aaije9ZuuxOmkPOAOUdGNmmNB66AQ6MTCl6pI0WpHM2EWp+NJ/4xBTJ2APOZ5
 3GXZrHo89Hcl0OtS2iKkFDl0uN4+om+YSkbE/UOMfHp1sX2vU8K6FyWUQJd1avB3BRo4
 9wFA==
X-Gm-Message-State:
AG10YOSm8MzPqGT7Hia24HueQfxd0gM5xkxsrG+f6o1b7AVRiZxgGE155J9XNhmo8PT9XiJyJv3Ur0GuNQ8wkQ==
MIME-Version: 1.0
X-Received: by 10.140.19.52 with SMTP id 49mr19058993qgg.103.1455918684746;
 Fri, 19 Feb 2016 13:51:24 -0800 (PST)
Received: by 10.55.15.216 with HTTP; Fri, 19 Feb 2016 13:51:24 -0800 (PST)
Date: Fri, 19 Feb 2016 13:51:24 -0800
Message-ID: 
Subject: Subscribe
From: "H.J. Lu" 
To: gnu-abi-subscr...@sourceware.org
Content-Type: text/plain; charset=UTF-8

-- 
H.J.

Re: gnu-gabi group

[H.J. Lu]

On Fri, Feb 19, 2016 at 1:00 PM, Markus Trippelsdorf
 wrote:
> On 2016.02.19 at 12:57 -0800, H.J. Lu wrote:
>> On Mon, Feb 15, 2016 at 10:20 AM, Jose E. Marchesi
>>  wrote:
>> >
>> > > Great. I'll ask overseers to create a mailinglist. [...]
>> >
>> > Done [1] [2].  If y'all need a wiki too, just ask.
>> >
>> > [1] gnu-g...@sourceware.org
>> > [2] https://sourceware.org/ml/gnu-gabi/
>> >
>> > The link to the "GNU GABI project web page" in
>> > https://sourceware.org/ml/gnu-gabi is broken.
>>
>> How do I subscribe gnu-abi mailing list?  The project page just
>> points to the mailing list archive.  There is no option to subscribe
>> it.
>
> https://sourceware.org/lists.html#ml-requestor

Doesn't work:

Hi. This is the qmail-send program at sourceware.org.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

:
Sorry, no mailbox here by that name. (#5.1.1)

--- Below this line is a copy of the message.


-- 
H.J.

Re: [PATCH] Fix Cilk+ #pragma cilk grainsize preprocessing (PR c++/69826)

[Jeff Law]

On 02/17/2016 10:18 AM, Jakub Jelinek wrote:

Hi!

The following testcase works unless -save-temps or ccache is used
(or manually performing -E and compilation separately).  The problem
is that #pragma cilk grainsize is supposed to have macro expansion
(except for the grainsize keyword), but we weren't enabling that for -E.

Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk?

2016-02-17  Jakub Jelinek  

PR c++/69826
* c-pragma.c (c_pp_lookup_pragma): Handle PRAGMA_CILK_GRAINSIZE.
(init_pragma): Register PRAGMA_CILK_GRAINSIZE even for
flag_preprocess_only.

* c-c++-common/cilk-plus/CK/pr69826-1.c: New test.
* c-c++-common/cilk-plus/CK/pr69826-2.c: New test.

OK.
jeff

Re: [PATCH] 19705 - -fno-branch-count-reg doesn't prevent decrement and branch instructions on a count register

[Jeff Law]

On 02/18/2016 08:39 PM, Martin Sebor wrote:

Ping:

https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00809.html

On 02/11/2016 02:58 PM, Martin Sebor wrote:

The more than decennnial rtl-optimization/19705 - -fno-branch-count-reg
doesn't prevent decrement and branch instructions on a count register
points out that the documentation of the option leads one to expect
that it prevents the decrement and branch instruction from appearing
in the instruction stream.  This isn't the case  The option prevents
a dedicated pass from running that introduces such instructions, but
it doesn't prevent other passes from introducing it.  The attached
updates the documentation to clarify this
I'm not even sure why we have this option to begin with.  One could 
easily argue that it's mis-named or should just go away.


In the mean time, your patch at least clarifies what it really does, so 
it's fine for the trunk.


jeff

Re: [PATCH] Add configure flag for operator new (std::nothrow)

[Daniel Gutson]

On Tue, Nov 10, 2015 at 10:10 AM, Jonathan Wakely  wrote:
> On 06/11/15 09:59 +, Pedro Alves wrote:
>>
>> On 11/06/2015 01:56 AM, Jonathan Wakely wrote:
>>>
>>> On 5 November 2015 at 23:31, Daniel Gutson
>>
>>
 The issue is, as I understand it, to do the actual work of operator
 new, i.e. allocate memory. It should force
 us to copy most of the code of the original code of operator new,
 which may change on new versions of the
 STL, forcing us to keep updated.
>>>
>>>
>>> It can just call malloc, and the replacement operator delete can call
>>> free.
>>>
>>> That is very unlikely to need to change (which is corroborated by the
>>> fact that the default definitions in libsupc++ change very rarely).
>>
>>
>> Or perhaps libsupc++ could provide the default operator new under
>> a __default_operator_new alias or some such, so that the user-defined
>> replacement can fallback to calling it.  Likewise for op delete.

that would allow us to overload operator new as something like this:

void* operator new  ( std::size_t count, const std::nothrow_t& tag)
noexcept(true)
{
const auto old_handler = std::set_new_handler(nullptr);
const auto ret = __default_operator_new(count, tag);
std::set_new_handler(old_handler);
return ret;
}

This is a non-iterating operator new.

This additional user defined operator new would be possible:

void* operator new  ( std::size_t count, const std::nothrow_t& tag)
noexcept(true)
{
const auto old_handler = std::set_new_handler(nullptr);
const auto ret = __default_operator_new(count, tag);
std::set_new_handler(old_handler);

if (ret == nullptr && old_handler != nullptr)
old_handler();

return ret;
}

So I like the idea.


>
>
> That could be useful, please file an enhancement request in bugzilla
> if you'd like that done.



-- 

Daniel F. Gutson
Chief Engineering Officer, SPD

San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina

Phone:   +54 351 4217888 / +54 351 4218211
Skype:dgutson
LinkedIn: http://ar.linkedin.com/in/danielgutson

Re: i386: relax scan-assembler test in lzcnt-1 testcase

[Jeff Law]

On 02/19/2016 02:36 PM, Bernd Schmidt wrote:

I'm working on some IRA cost fixes, and I've had the lzcnt-1.c test fail
because the register allocator started making different decisions. In
both cases we end up generating two instructions, but with slightly
different register assignments. Hence, this patch, which relaxes the
test slightly.

Bootstrapped and tested on x86_64-linux (with my IRA changes, so I
probably ought to try without those as well). Ok?

OK.
jeff

i386: relax scan-assembler test in lzcnt-1 testcase

[Bernd Schmidt]

I'm working on some IRA cost fixes, and I've had the lzcnt-1.c test fail 
because the register allocator started making different decisions. In 
both cases we end up generating two instructions, but with slightly 
different register assignments. Hence, this patch, which relaxes the 
test slightly.


Bootstrapped and tested on x86_64-linux (with my IRA changes, so I 
probably ought to try without those as well). Ok?



Bernd
	* gcc.target/i386/lzcnt-1.c: Allow a different lzcntw output register.

Index: gcc/testsuite/gcc.target/i386/lzcnt-1.c
===
--- gcc/testsuite/gcc.target/i386/lzcnt-1.c	(revision 233451)
+++ gcc/testsuite/gcc.target/i386/lzcnt-1.c	(working copy)
@@ -1,6 +1,6 @@
 /* { dg-do compile } */
 /* { dg-options "-O2 -mlzcnt " } */
-/* { dg-final { scan-assembler "lzcntw\[^\\n]*(%|)ax" } } */
+/* { dg-final { scan-assembler "lzcntw\[^\\n]*(%|)\[ad\]\[xi\]" } } */
 
 #include 
 

Re: How to use _Generic with bit-fields

[Martin Sebor]

On 02/19/2016 11:25 AM, Wink Saville wrote:

I'm using gcc 5.3.0:

$ gcc --version
gcc (GCC) 5.3.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


And I've tried to use _Generic to print the type of a bit field but
the compiler fails with:

$ make
gcc -Wall -std=c11 -o test.o -c test.c
test.c: In function ‘main’:
test.c:8:35: error: ‘_Generic’ selector of type ‘unsigned char:2’ is
not compatible with any association
  #define type_to_str(__x) _Generic((__x), \
^
test.c:17:18: note: in expansion of macro ‘type_to_str’
printf("%s\n", type_to_str(b.f1));
   ^
Makefile:7: recipe for target 'test.o' failed
make: *** [test.o] Error 1
bash: ./test: No such file or directory


The test program is:

$ cat test.c
#include 

struct bits {
   unsigned char f0;
   unsigned char f1:2;
};

#define type_to_str(__x) _Generic((__x), \
   unsigned char : "unsigned char")

int main(void) {
   struct bits b = { .f0 = 255, .f1 = 3 };

   printf("%d\n", b.f0);
   printf("%s\n", type_to_str(b.f0));
   printf("%d\n", b.f1);
   printf("%s\n", type_to_str(b.f1));

   return 0;
}


...

How do I create a type association for a bit field?


I suspect this falls under the set of issues that fall under bug
65471 - type interpretation in _Generic.  The C language rules
for _Generic aren't completely clear about what conversions are
to take place.  It would be helpful if you could your test case
to the bug to make sure the bitfield case is considered when
the issue is discussed by the C committee.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65471

The only idea for a workaround that comes to mind is to trick GCC
into forgetting that it's a bit-field.  This hack seems to work:

  #define type_to_str(__x) _Generic((0)?(__x):(__x), \

Martin

Re: Fix/work around PR57676, LRA terminates prematurely

[Jeff Law]

On 02/19/2016 02:32 PM, Bernd Schmidt wrote:

The testcase in this PR causes gcc to abort with

internal compiler error: Maximum number of LRA constraint passes is
achieved (30)

[in theory - I've not managed to reproduce this on my system with any
compiler]

The abort is premature, allowing LRA to continue would allow the
testcase to compile. Vlad would like to leave the check in, however, as
it is a good way to catch problems with machine descriptions as they are
converted to use LRA.

The following is a compromise I came up with after some internal
discussion. The idea is to leave the assert in under -fchecking, so that
release compilers do not prematurely abort for valid testcases, while
development builds get an additional sanity check.

Bootstrapped and tested on x86_64-linux. Ok?


Bernd

 PR rtl-optimization/57676
 * lra-assigns.c (lra_assign): Guard test for maximum iterations
 with flag_checking.

 PR rtl-optimization/57676
 * gcc.dg/torture/pr57676.c: New test.

OK.  Your call on backporting the release branches.

jeff

Fix/work around PR57676, LRA terminates prematurely

[Bernd Schmidt]

The testcase in this PR causes gcc to abort with

internal compiler error: Maximum number of LRA constraint passes is 
achieved (30)


[in theory - I've not managed to reproduce this on my system with any 
compiler]


The abort is premature, allowing LRA to continue would allow the 
testcase to compile. Vlad would like to leave the check in, however, as 
it is a good way to catch problems with machine descriptions as they are 
converted to use LRA.


The following is a compromise I came up with after some internal 
discussion. The idea is to leave the assert in under -fchecking, so that 
release compilers do not prematurely abort for valid testcases, while 
development builds get an additional sanity check.


Bootstrapped and tested on x86_64-linux. Ok?


Bernd

PR rtl-optimization/57676
* lra-assigns.c (lra_assign): Guard test for maximum iterations
with flag_checking.

PR rtl-optimization/57676
* gcc.dg/torture/pr57676.c: New test.

Index: gcc/lra-assigns.c
===
--- gcc/lra-assigns.c	(revision 233451)
+++ gcc/lra-assigns.c	(working copy)
@@ -1620,7 +1620,12 @@ lra_assign (void)
   timevar_pop (TV_LRA_ASSIGN);
   if (former_reload_pseudo_spill_p)
 lra_assignment_iter_after_spill++;
-  if (lra_assignment_iter_after_spill > LRA_MAX_ASSIGNMENT_ITERATION_NUMBER)
+  /* This is conditional on flag_checking because valid code can take
+ more than this maximum number of iteration, but at the same time
+ the test can uncover errors in machine descriptions.  */
+  if (flag_checking
+  && (lra_assignment_iter_after_spill
+	  > LRA_MAX_ASSIGNMENT_ITERATION_NUMBER))
 internal_error
   ("Maximum number of LRA assignment passes is achieved (%d)\n",
LRA_MAX_ASSIGNMENT_ITERATION_NUMBER);
Index: gcc/testsuite/gcc.dg/torture/pr57676.c
===
--- gcc/testsuite/gcc.dg/torture/pr57676.c	(revision 0)
+++ gcc/testsuite/gcc.dg/torture/pr57676.c	(working copy)
@@ -0,0 +1,28 @@
+/* Verify that LRA does not abort prematurely in a release build of the
+   compiler.  */
+/* { dg-do compile } */
+/* { dg-options "-fno-checking -w -funroll-loops" } */
+
+int a, b, c;
+
+void f(p1)
+{
+for(;;)
+{
+if(p1 ? : (c /= 0))
+{
+int d;
+
+for(; d; d++)
+{
+for(b = 0; b < 4; b++)
+p1 /= p1;
+lbl:
+while(a);
+}
+}
+
+if((c &= 1))
+goto lbl;
+}
+}

[Bug c/69878] New: GCC produces pessimal assembly for C11 atomic increments

[matt at bitbashing dot io]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69878

Bug ID: 69878
   Summary: GCC produces pessimal assembly for C11 atomic
increments
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matt at bitbashing dot io
  Target Milestone: ---

Consider the following test case:

#include 

atomic_int foo;

void plusPlus(void)
{
foo++;
}

void fetchAdd(void)
{
atomic_fetch_add(, 1);
}

The assembly for plusPlus and fetchAdd should be the same,
since the two perform the same operation.
However, GCC 5.3 with -O2 -c yields:

 :
   0:   8b 05 00 00 00 00   mov0x0(%rip),%eax# 6 
   6:   66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
   d:   00 00 00
  10:   89 44 24 fc mov%eax,-0x4(%rsp)
  14:   8d 50 01lea0x1(%rax),%edx
  17:   8b 44 24 fc mov-0x4(%rsp),%eax
  1b:   f0 0f b1 15 00 00 00lock cmpxchg %edx,0x0(%rip)# 23

  22:   00
  23:   75 eb   jne10 
  25:   f3 c3   repz retq
  27:   66 0f 1f 84 00 00 00nopw   0x0(%rax,%rax,1)
  2e:   00 00

0030 :
  30:   f0 83 05 00 00 00 00lock addl $0x1,0x0(%rip)# 38

  37:   01
  38:   c3  retq

It seems like instead of a "simple" atomic increment, foo++ does the following:

1. Atomically load the value (with full sequential consistency).
2. Increment
3. Compare and swap the original value (with full sequential consistency).
4. If the CAS didn't take, go to step 1.

While this produces the desired effect (atomically adding one),
there's obviously much more going on than there should be,
and the extra memory barriers around each step are probably quite unfriendly
to performance (especially if there are several threads accessing the value).

The problem exists on ARM as well (where I originally discovered this issue),
so it doesn't seem to be target dependent:

 :
   0:   b510push{r4, lr}
   2:   4a0fldr r2, [pc, #60]   ; (40 )
   4:   f3bf 8f5f   dmb sy
   8:   b082sub sp, #8
   a:   ac02add r4, sp, #8
   c:   6813ldr r3, [r2, #0]
   e:   f3bf 8f5f   dmb sy
  12:   f844 3d04   str.w   r3, [r4, #-4]!
  16:   1c58addsr0, r3, #1
  18:   6821ldr r1, [r4, #0]
  1a:   f3bf 8f5f   dmb sy
  1e:   e852 3f00   ldrex   r3, [r2]
  22:   428bcmp r3, r1
  24:   d104bne.n   30 
  26:   e842 0e00   strex   lr, r0, [r2]
  2a:   f1be 0f00   cmp.w   lr, #0
  2e:   d1f6bne.n   1e 
  30:   f3bf 8f5f   dmb sy
  34:   d101bne.n   3a 
  36:   b002add sp, #8
  38:   bd10pop {r4, pc}
  3a:   6023str r3, [r4, #0]
  3c:   e7ebb.n 16 
  3e:   bf00nop
  40:   .word   0x

0044 :
  44:   4b06ldr r3, [pc, #24]   ; (60 )
  46:   f3bf 8f5f   dmb sy
  4a:   e853 2f00   ldrex   r2, [r3]
  4e:   3201addsr2, #1
  50:   e843 2100   strex   r1, r2, [r3]
  54:   2900cmp r1, #0
  56:   d1f8bne.n   4a 
  58:   f3bf 8f5f   dmb sy
  5c:   4770bx  lr
  5e:   bf00nop
  60:   .word   0x

(compiled using arm-none-eabi-gcc version 5.3 with -O2 -mthumb -mcpu=cortex-m4)

What's curious is that the C++ frontend doesn't seem to have this problem.
With g++ -std=c++11 -O2 -c and the equivalent C++:

#include 

std::atomic_int foo;

void plusPlus()
{
foo++;
}

void fetchAdd()
{
foo.fetch_add(1);
}

the compiler recognizes it's the same and implements one as a jump to the
other:

 :
   0:   f0 83 05 00 00 00 00lock addl $0x1,0x0(%rip)# 8

   7:   01
   8:   c3  retq
   9:   0f 1f 80 00 00 00 00nopl   0x0(%rax)

0010 :
  10:   e9 00 00 00 00  jmpq   15 

Clang also generates the same code for both (using clang and clang++):

 :
   0:   f0 ff 05 00 00 00 00lock incl 0x0(%rip)# 7 
   7:   c3  retq
   8:   0f 1f 84 00 00 00 00nopl   0x0(%rax,%rax,1)
   f:   00

0010 :
  10:   f0 ff 05 00 00 00 00lock incl 0x0(%rip)# 17 
  17:   c3  retq


Obligatory information:

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/5.3.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc-multilib/src/gcc-5-20160209/configure --prefix=/usr
--libdir=/usr/lib 

Re: gnu-gabi group

[Mark Wielaard]

On Fri, Feb 19, 2016 at 12:57:34PM -0800, H.J. Lu wrote:
> How do I subscribe gnu-abi mailing list?  The project page just
> points to the mailing list archive.  There is no option to subscribe
> it.

To subscribe sent email to gnu-abi-subscr...@sourceware.org
Or use the subscribe form at https://sourceware.org/lists.html#ml-requestor

Note I set the Reply-To: gnu-g...@sourceware.org so we don't keep
spamming all the GNU toolchain project lists. We should get at least
one representative from each GNU toolchain project on the gnu-gabi
list to make sure we have a process that makes sure we only document
abi that is actually supportable.

Thanks,

Mark

Re: [PATCH] Fix PR c++/68948 (wrong code generation due to invalid constructor call)

[Patrick Palka]

On Fri, Feb 19, 2016 at 2:06 PM, Jason Merrill  wrote:
> On 02/19/2016 11:56 AM, Patrick Palka wrote:
>>
>> On Fri, Feb 19, 2016 at 10:41 AM, Jason Merrill  wrote:
>>>
>>> On 02/18/2016 01:25 PM, Patrick Palka wrote:


 On Wed, Feb 17, 2016 at 10:51 PM, Jason Merrill 
 wrote:
>
>
> OK.


 Is this an approval of the 2nd patch for next stage 1?
>>>
>>>
>>> Actually, I've been looking at this area a lot recently in the context of
>>> the 10200 fix, and now I think we can go ahead with the 2nd patch now,
>>> but
>>> without the assert; I think it would fire if we wrote A::A().
>>
>>
>> I w ill commit the version without the assert shortly, but...
>>
>> I haven't been able to get the assert to fire even when the A in
>> A::A() is dependent because in that case FN should be dependent, so we
>> would already have exited out of finish_call_expr due to the
>> type_dependent_expression_p (fn) check near the top of
>> finish_call_expr.  (In particular for dependent A::A(), FN is a
>> SCOPE_REF whose 1st operand is the dependent type A and 2nd operand is
>> the identifier node A.)
>>
>> So it seems to me that the assert at that location is safe, since the
>> dummy object should be dependent only if the constructor call FN is
>> dependent in which case we would never reach the assert.
>
>
> It might be safe given our current dependency analysis, but I'm planning to
> tighten that up in GCC 7, along the lines of my 69753 patch that I ended up
> backing out.  Why do you want the assert?

No good reason.

>
> Jason
>

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[Richard Smith]

On Fri, Feb 19, 2016 at 5:35 AM, Michael Matz  wrote:
> Hi,
>
> On Thu, 18 Feb 2016, Richard Smith wrote:
>
>> >> An empty type is a type where it and all of its subobjects
>> >> (recursively) are of class, structure, union, or array type.  No
>> >> memory slot nor register should be used to pass or return an object
>> >> of empty type.
>> >
>> > The trivially copyable is gone again.  Why is it not necessary?
>>
>> The C++ ABI doesn't defer to the C psABI for types that aren't
>> trivially-copyable. See
>> http://mentorembedded.github.io/cxx-abi/abi.html#normal-call
>
> Hmm, yes, but we don't want to define something for only C and C++, but
> language independend (so far as possible).  And given only the above
> language I think this type:
>
> struct S {
>   S() {something();}
> };
>
> would be an empty type, and that's not what we want.

Yes it is. Did you mean to give S a copy constructor, copy assignment
operator, or destructor instead?

> "Trivially copyable"
> is a reasonably common abstraction (if in doubt we could even define it in
> the ABI), and captures the idea that we need well (namely that a bit-copy
> is enough).
>
>
> Ciao,
> Michael.

Re: [RFC] [P2] [PR tree-optimization/33562] Lowering more complex assignments.

[Jeff Law]

On 02/18/2016 02:56 AM, Richard Biener wrote:

Just a short quick comment - the above means you only handle partial
stores
with no interveaning uses.  You don't handle, say

struct S { struct R { int x; int y; } r; int z; } s;

   s = { {1, 2}, 3 };
   s.r.x = 1;
   s.r.y = 2;
   struct R r = s.r;
   s.z = 3;

where s = { {1, 2}, 3} is still dead.


Right.  But handling that has never been part of DSE's design goals. Once
there's a use, DSE has always given up.


Yeah, which is why I in the end said we need a "better" DSE ...
So I cobbled up a quick test for this.  I only handle assignments which 
may reference the same memory as the currently tracked store.  Obviously 
that could be extended to handle certain builtins and the like.


It triggers a bit here and there.  While looking at those cases it 
occurred to me that, we could also look at this as a failure earlier in 
the optimization pipeline.  In fact DOM already has code to handle a 
closely related situation.


When DOM sees a store to memory, it creates a new fake statement with 
the RHS and LHS reversed.  So in the case above DOM creates statements 
that look like:


1 = s.r.x
2 = s.r.y

DOM then puts the RHS into the available expression table as equivalent 
to the LHS.  So if it finds a later load of s.r.x, it will replace that 
load with "1".  I haven't looked at it in a while, but it certainly was 
functional prior to the tuple merge.


Presumably DOM is not looking at r = s.r and realizing it could look s.r 
piece-wise in the available expression table.  If it did, it would 
effectively turn that fragment into:


s = { {1, 2}, 3 };
s.r.x = 1;
s.r.y = 2;
struct R r = {1, 2}
s.z = 3;

At which point we no longer have the may-read of s.r.{x,y} and DSE would 
see the initial assignment as dead.


I'm not sure if it's advisable to teach DOM how to lookup structure 
references piecewise or not.  The code to handle this case in DSE is 
relatively simple, so perhaps we just go with the DSE variant.


I also looked a bit at cases where we find that while an entire store 
(such as an aggregate initialization or mem*) may not be dead, pieces of 
the store may be dead.   That's trivial to detect.   It triggers 
relatively often.  The trick is once detected, we have to go back and 
rewrite the original statement to only store the live parts.  I've only 
written the detection code, the rewriting might be somewhat painful.


I'm starting to wonder if what we have is a 3-part series.

[1/3] The basic tracking to handle 33562, possibly included in gcc-6
[2/3] Ignore reads that reference stuff not in live_bytes for gcc-7
[3/3] Detect partially dead aggregate stores, rewriting the partially
  dead store to only store the live bytes.  Also for gcc-7.


Obviously [1/3] would need compile-time benchmarking, but I really don't 
expect any issues there.


Jeff

Re: gnu-gabi group

[Markus Trippelsdorf]

On 2016.02.19 at 12:57 -0800, H.J. Lu wrote:
> On Mon, Feb 15, 2016 at 10:20 AM, Jose E. Marchesi
>  wrote:
> >
> > > Great. I'll ask overseers to create a mailinglist. [...]
> >
> > Done [1] [2].  If y'all need a wiki too, just ask.
> >
> > [1] gnu-g...@sourceware.org
> > [2] https://sourceware.org/ml/gnu-gabi/
> >
> > The link to the "GNU GABI project web page" in
> > https://sourceware.org/ml/gnu-gabi is broken.
> 
> How do I subscribe gnu-abi mailing list?  The project page just
> points to the mailing list archive.  There is no option to subscribe
> it.

https://sourceware.org/lists.html#ml-requestor

-- 
Markus

Re: gnu-gabi group

[H.J. Lu]

On Mon, Feb 15, 2016 at 10:20 AM, Jose E. Marchesi
 wrote:
>
> > Great. I'll ask overseers to create a mailinglist. [...]
>
> Done [1] [2].  If y'all need a wiki too, just ask.
>
> [1] gnu-g...@sourceware.org
> [2] https://sourceware.org/ml/gnu-gabi/
>
> The link to the "GNU GABI project web page" in
> https://sourceware.org/ml/gnu-gabi is broken.

How do I subscribe gnu-abi mailing list?  The project page just
points to the mailing list archive.  There is no option to subscribe
it.

-- 
H.J.

Re: [PATCH] Fix expansion of TREE_ADDRESSABLE bitwise copies (PR c++/69851)

[Jakub Jelinek]

On Fri, Feb 19, 2016 at 08:45:09PM +, Bernd Edlinger wrote:
> I have still another question.
> 
> Why are you adding braces here?
> 
> +   || (bitsize % BITS_PER_UNIT != 0)
> +   || (bitpos % BITS_PER_UNIT != 0)

These two are not really needed, but I've already committed the patch.

> +   || (compare_tree_int (DECL_SIZE (TREE_OPERAND (exp, 1)), bitsize)
> +   != 0)))
> 
> I think everywhere in that function we omit braces around == terms
> inside || terms even long ones.

emacs users keep saying that emacs needs this to indent it properly.

> || a == b
> || c == d
> || e == f)

These are on a single line, so it is not a problem.

Jakub

Re: PPC libgcc IEEE128 soft-fp exception/rounding fixes

[Paul E. Murphy]

On 02/17/2016 08:37 PM, Alan Modra wrote:
>> +/* A set bit indicates an exception is trapping.  */
>> +# define FP_TRAPPING_EXCEPTIONS ((_fpscr.i << 22) & FP_EX_ALL)
> 
> why then a shift here, since FP_EX_* are defined as the actual
> register bits?  Oh, I see.  FP_EX_* are the status bits, and you want
> the enable bits.  ie. bit 56 rather than bit 34, bit 57 rather than
> bit 35 and so on (bits numbered from 0 as msb).  A comment to that
> effect might reduce head scratching.

Thanks for taking a look Alan, and Joseph.  I've expanded the comment
to clarify the otherwise mysterious shift with the updated patch.

libgcc
* config/rs6000/sfp-machine.h:
(_FP_DECL_EX): Declare _fpsr as a union of u64 and double.
(FP_TRAPPING_EXCEPTIONS): Return a bitmask of trapping
exceptions.
(FP_INIT_ROUNDMODE): Read the fpscr instead of writing
a mystery value.
(FP_ROUNDMODE): Update the usage of _fpscr.

diff --git a/libgcc/config/rs6000/sfp-machine.h b/libgcc/config/rs6000/sfp-machine.h
index 75d5e1a..8dd8ea3 100644
--- a/libgcc/config/rs6000/sfp-machine.h
+++ b/libgcc/config/rs6000/sfp-machine.h
@@ -130,9 +130,13 @@ void __sfp_handle_exceptions (int);
 if (__builtin_expect (_fex, 0))		\
   __sfp_handle_exceptions (_fex);		\
   } while (0);
-/* A set bit indicates an exception is masked and a clear bit indicates it is
-   trapping.  */
-# define FP_TRAPPING_EXCEPTIONS (~_fpscr & (FP_EX_ALL >> 22))
+
+/* The FP_EX_* bits track whether the exception has occurred.  This macro
+   must set the FP_EX_* bits of those exceptions which are configured to
+   trap.  The FPSCR bit which indicates this is 22 ISA bits above the
+   respective FP_EX_* bit.  Note, the ISA labels bits from msb to lsb,
+   so 22 ISA bits above is 22 bits below when counted from the lsb.  */
+# define FP_TRAPPING_EXCEPTIONS ((_fpscr.i << 22) & FP_EX_ALL)
 
 # define FP_RND_NEAREST	0x0
 # define FP_RND_ZERO	0x1
@@ -141,16 +145,16 @@ void __sfp_handle_exceptions (int);
 # define FP_RND_MASK	0x3
 
 # define _FP_DECL_EX \
-  unsigned long long _fpscr __attribute__ ((unused)) = FP_RND_NEAREST
+  union { unsigned long long i; double d; } _fpscr __attribute__ ((unused)) = \
+	 { .i = FP_RND_NEAREST }
 
 #define FP_INIT_ROUNDMODE			\
   do {		\
-__asm__ __volatile__ ("mtfsf 255, %0"	\
-			  :			\
-			  : "f" (_fpscr));	\
+__asm__ __volatile__ ("mffs %0"		\
+			  : "=f" (_fpscr.d));	\
   } while (0)
 
-# define FP_ROUNDMODE	(_fpscr & FP_RND_MASK)
+# define FP_ROUNDMODE	(_fpscr.i & FP_RND_MASK)
 #endif	/* !__FLOAT128__ */
 
 /* Define ALIASNAME as a strong alias for NAME.  */

Re: [PATCH] Fix expansion of TREE_ADDRESSABLE bitwise copies (PR c++/69851)

[Bernd Edlinger]

Excuse me,

I have still another question.

Why are you adding braces here?

+ || (bitsize % BITS_PER_UNIT != 0)
+ || (bitpos % BITS_PER_UNIT != 0)
+ || (compare_tree_int (DECL_SIZE (TREE_OPERAND (exp, 1)), bitsize)
+ != 0)))

I think everywhere in that function we omit braces around == terms
inside || terms even long ones.

|| a == b
|| c == d
|| e == f)


I know many like to add braces here, but GCC does not do that
unnecessarily, right?


Thanks
Bernd.

Re: [PATCH] Fix expansion of TREE_ADDRESSABLE bitwise copies (PR c++/69851)

[Bernd Edlinger]

Excuse me,

I have still another question.

Why are you adding braces here?

+ || (bitsize % BITS_PER_UNIT != 0)
+ || (bitpos % BITS_PER_UNIT != 0)
+ || (compare_tree_int (DECL_SIZE (TREE_OPERAND (exp, 1)), bitsize)
+ != 0)))

I think everywhere in that function we omit braces around == terms
inside || terms even long ones.

|| a == b
|| c == d
|| e == f)


I know many like to add braces here, but GCC does not do that
unnecessarily, right?


Thanks
Bernd.

Re: [patch] Clarify interaction of -Wnarrowing with -std

[Jonathan Wakely]

On 19/02/16 13:17 -0700, Sandra Loosemore wrote:

On 02/19/2016 12:01 PM, Jason Merrill wrote:

On 02/19/2016 07:42 AM, Jonathan Wakely wrote:

In PR69864 Manu suggests improving the docs to explain that
-Wnarrowing sometimes produces errors not warnings.

I think the right way to do that is clarify how it interacts with
-std. Specifically that the effect of -Wnarrowing listed first in the
manual *only* applies to C++98 modes, For all later modes (not just
with -std=c++11 as it says now), narrowing conversions produce errors
or warnings by default.

OK for trunk?


OK, thanks.


I suppose the patch is OK as it stands, but I was going to suggest 
restructuring it so that it talks about the default behavior first and 
what it does with non-default -std= options after that, instead of 
vice-versa.  Unfortunately I am backlogged on other things right now 
and it might take me a day or two before I have time to come up with 
some alternate wording.  If we are in a rush, go ahead and commit the 
existing patch meanwhile, I guess.


I did wonder about that but couldn't come up with wording I liked.

I went ahead and committed it after Jason's OK, but I can take another
look at it next week.

Re: [PATCH] Fix expansion of TREE_ADDRESSABLE bitwise copies (PR c++/69851)

[Bernd Edlinger]

On 19.02.2016 21:08, Jakub Jelinek wrote:
> On Fri, Feb 19, 2016 at 08:04:39PM +, Bernd Edlinger wrote:
>> but you are just adding another term to this expression:
>>!(TREE_CODE (exp) == CONSTRUCTOR
>>  && bitsize % BITS_PER_UNIT == 0)
>
> No.  Please read the code again.  I'm adding another case
> after this one.
>

Ok, now I see.
Sorry for the noise.


Bernd.

Re: [patch] Clarify interaction of -Wnarrowing with -std

[Sandra Loosemore]

On 02/19/2016 12:01 PM, Jason Merrill wrote:

On 02/19/2016 07:42 AM, Jonathan Wakely wrote:

In PR69864 Manu suggests improving the docs to explain that
-Wnarrowing sometimes produces errors not warnings.

I think the right way to do that is clarify how it interacts with
-std. Specifically that the effect of -Wnarrowing listed first in the
manual *only* applies to C++98 modes, For all later modes (not just
with -std=c++11 as it says now), narrowing conversions produce errors
or warnings by default.

OK for trunk?


OK, thanks.


I suppose the patch is OK as it stands, but I was going to suggest 
restructuring it so that it talks about the default behavior first and 
what it does with non-default -std= options after that, instead of 
vice-versa.  Unfortunately I am backlogged on other things right now and 
it might take me a day or two before I have time to come up with some 
alternate wording.  If we are in a rush, go ahead and commit the 
existing patch meanwhile, I guess.


-Sandra

Re: [PATCH] Fix expansion of TREE_ADDRESSABLE bitwise copies (PR c++/69851)

[Jakub Jelinek]

On Fri, Feb 19, 2016 at 08:04:39PM +, Bernd Edlinger wrote:
> but you are just adding another term to this expression:
>   !(TREE_CODE (exp) == CONSTRUCTOR
> && bitsize % BITS_PER_UNIT == 0)

No.  Please read the code again.  I'm adding another case
after this one.

> so the result should look like
>   !(TREE_CODE (exp) == CONSTRUCTOR
>&& bitsize % BITS_PER_UNIT == 0
>&& (!TREE_ADDRESSABLE ...
>|| TREE_CODE () ...
>...
>|| (compare_tree_int ...
>!= 0)))

Jakub

[Bug rtl-optimization/69806] [6 Regression][SH] Combine doesn't see constant

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69806

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #6 from Segher Boessenkool  ---
r233159 was reverted in r233356.  Does this problem still happen?

Re: [PATCH] Fix expansion of TREE_ADDRESSABLE bitwise copies (PR c++/69851)

[Bernd Edlinger]

On 19.02.2016 20:04, Jakub Jelinek wrote:
> On Fri, Feb 19, 2016 at 06:42:32PM +, Bernd Edlinger wrote:
>> Hi,
>>
>>
>>> --- gcc/expr.c.jj   2016-02-12 00:50:55.0 +0100
>>> +++ gcc/expr.c  2016-02-19 10:43:59.639162531 +0100
>>> @@ -6643,14 +6643,24 @@ store_field (rtx target, HOST_WIDE_INT b
>>>   /* Except for initialization of full bytes from a CONSTRUCTOR, which
>>>  we will handle specially below.  */
>>>   && !(TREE_CODE (exp) == CONSTRUCTOR
>>> -  && bitsize % BITS_PER_UNIT == 0))
>>> +  && bitsize % BITS_PER_UNIT == 0)
>>> + /* And except for bitwise copying of TREE_ADDRESSABLE types,
>>> +where the FIELD_DECL has the right bitsize, but TREE_TYPE (exp)
>>> +includes some extra padding.  */
>>> + && (!TREE_ADDRESSABLE (TREE_TYPE (exp))
>>> + || TREE_CODE (exp) != COMPONENT_REF
>>> + || TREE_CODE (DECL_SIZE (TREE_OPERAND (exp, 1))) != INTEGER_CST
>>> + || (bitsize % BITS_PER_UNIT != 0)
>>> + || (bitpos % BITS_PER_UNIT != 0)
>>> + || (compare_tree_int (DECL_SIZE (TREE_OPERAND (exp, 1)), bitsize)
>>> + != 0)))
>>> /* If we are expanding a MEM_REF of a non-BLKmode non-addressable
>>>decl we must use bitfield operations.  */
>>
>> isn't the indentation of the new block wrong?
>
> No, I think it is correct.
>
>   Jakub
>


but you are just adding another term to this expression:
  !(TREE_CODE (exp) == CONSTRUCTOR
&& bitsize % BITS_PER_UNIT == 0)

so the result should look like
  !(TREE_CODE (exp) == CONSTRUCTOR
   && bitsize % BITS_PER_UNIT == 0
   && (!TREE_ADDRESSABLE ...
   || TREE_CODE () ...
   ...
   || (compare_tree_int ...
   != 0)))



Bernd.

Re: [PATCH] combine: Delete EQ* notes when pseudo mode changes (PR60818)

[Segher Boessenkool]

On Fri, Feb 19, 2016 at 08:34:03PM +0100, Eric Botcazou wrote:
> > It is not a regression (it is in all open release branches already).
> > I can postpone it if you think that is wiser?
> 
> I do think that the combiner is one of those pieces of code that you ought 
> not 
> to touch unless you really need to.

Oh I agree, which is why I throw all patches through testing on a zillion
different archs, and bootstraps on a few.

I'll postpone this patch to GCC 7, stage 4 is too late for it.


Segher

Re: Need suggestion about bug 68425

[Manuel López-Ibáñez]

On 19 February 2016 at 19:13, David Malcolm  wrote:
>> 68425.c:3:34: warning: excess elements in array initializer (6
>> elements,
>> expected 2)
>>const int array[2] = { 1, 2, 3 ,6 ,89 ,193};
>> ^
>
> Yes, that would be ideal.  Unfortunately, not every tree expression
> node has a location stored for it, so implementing the underlined range
> might be tricky to do.  (in particular, INTEGER_CST doesn't.  I hope to
> look into that for gcc 7, perhaps with a wrapper node to provide
> locations for expr nodes that don't have them).

Do you think that would be better than storing the locations in the
parent expression? That is, instead of adding extra wrapper nodes,
with all those tree nodes wasting space just to provide a location,
add extra location slots to every tree that may have an operand. Or
perhaps you are thinking about adding some lighter wrapper which is
just a loc+tree* or something like that.

In the case above (for C), struct constructor_stack could keep track
of token locations passed by the parser (all tokens have locations,
but those locations are not saved in all trees). In fact, I see that
there is already a lot of location passing in the corresponding code,
but probably all of them refer to input_location or some such.

Cheers,

Manuel.

Re: [PATCH 4/n] OpenMP 4.0 offloading infrastructure: lto-wrapper

[Ilya Verbin]

On Fri, Feb 19, 2016 at 20:41:58 +0100, Thomas Schwinge wrote:
> Hi!
> 
> On Thu, 2 Oct 2014 19:14:57 +0400, Ilya Verbin  wrote:
> > With this patch lto-wrapper performs invocation of mkoffload tool for each
> > offload target.  This tool [...]
> > will compile IR from .gnu.offload_lto_* sections into offload
> > target code and embed the resultant code (offload image) into the new host's
> > object file.
> 
> Consider the following scenario:
> 
> $ cat < CSTS-214-acc.c
> int acc (void)
> {
>   int a;
> 
> #pragma acc parallel num_gangs (1) copyout (a)
>   a = 100;
> 
>   return a;
> }
> $ cat < CSTS-214-test.c
> extern int acc (void);
> 
> int main (void)
> {
>   if (acc () != 100)
> __builtin_abort ();
>   
>   return 0;
> }
> 
> Compile these two files as follows:
> 
> $ [GCC] -fopenacc -c CSTS-214-acc.c
> $ x86_64-linux-gnu-ar -cr CSTS-214-acc.a CSTS-214-acc.o
> $ [GCC] -fopenacc CSTS-214-test.c CSTS-214-acc.a
> 
> The last step will fail -- with incomprehensible diagnostics, ;-) as so
> often when offloading fails...  Here's what's going on: the
> LTO/offloading machinery correctly identifies that it needs to process
> the CSTS-214-acc.c:acc function, present in the CSTS-214-acc.a archive
> file at a certain offset, and it "encodes" that as follows:
> CSTS-214-acc.a@0x9e (see lto-plugin/lto-plugin.c:claim_file_handler, the
> "file->offset != 0" code right at the beginning).  This makes its way
> down through here:
> 
> > --- a/gcc/lto-wrapper.c
> > +++ b/gcc/lto-wrapper.c
> 
> > +/* Copy a file from SRC to DEST.  */
> > +
> > +static void
> > +copy_file (const char *dest, const char *src)
> > +{
> > +  [...]
> > +}
> 
> > @@ -624,6 +852,54 @@ run_gcc (unsigned argc, char *argv[])
> 
> > +  /* If object files contain offload sections, but do not contain LTO 
> > sections,
> > + then there is no need to perform a link-time recompilation, i.e.
> > + lto-wrapper is used only for a compilation of offload images.  */
> > +  if (have_offload && !have_lto)
> > +{
> > +  for (i = 1; i < argc; ++i)
> > +   if ([...])
> > + {
> > +   char *out_file;
> > +   /* Can be ".o" or ".so".  */
> > +   char *ext = strrchr (argv[i], '.');
> > +   if (ext == NULL)
> > + out_file = make_temp_file ("");
> > +   else
> > + out_file = make_temp_file (ext);
> > +   /* The linker will delete the files we give it, so make copies.  */
> > +   copy_file (out_file, argv[i]);
> > +   printf ("%s\n", out_file);
> > + }
> > +[...]
> > +  goto finish;
> > +}
> > +
> >if (lto_mode == LTO_MODE_LTO)
> >  {
> >flto_out = make_temp_file (".lto.o");
> > @@ -850,6 +1126,10 @@ cont:
> >obstack_free (_obstack, NULL);
> >  }
> >  
> > + finish:
> > +  if (offloadend)
> > +printf ("%s\n", offloadend);
> > +
> >obstack_free (_obstack, NULL);
> >  }
> 
> When we hit this, for argv "CSTS-214-acc.a@0x9e", the copy_file call will
> fail -- there is no "CSTS-214-acc.a@0x9e" file to copy.  If we strip off
> the "@0x[...]" suffix (but still printf the filename including the
> suffix), then things work.  I copied that bit of code from earlier in
> this function, where the same archive offset handling needs to be done.
> Probably that code should be refactored a bit.
> 
> Also, I wonder if the "ext == NULL" case can really happen, and needs to
> be handled as done in the code cited above, or if that can be simplified?
> (Not yet tested that.)
> 
> Will something like the following be OK to fix this issue, or is that
> something "that should not happen", should be fixed differently?
> 
> --- gcc/lto-wrapper.c
> +++ gcc/lto-wrapper.c
> @@ -1161,15 +1161,31 @@ run_gcc (unsigned argc, char *argv[])
>   && strncmp (argv[i], "-flinker-output=",
>   sizeof ("-flinker-output=") - 1) != 0)
> {
> + char *p;
> + off_t file_offset = 0;
> + long loffset;
> + int consumed;
> + char *filename = argv[i];
> +
> + if ((p = strrchr (argv[i], '@'))
> + && p != argv[i] 
> + && sscanf (p, "@%li%n", , ) >= 1
> + && strlen (p) == (unsigned int) consumed)
> +   {
> + filename = XNEWVEC (char, p - argv[i] + 1);
> + memcpy (filename, argv[i], p - argv[i]);
> + filename[p - argv[i]] = '\0';
> + file_offset = (off_t) loffset;
> +   }
> +
>   char *out_file;
> - /* Can be ".o" or ".so".  */
> - char *ext = strrchr (argv[i], '.');
> + char *ext = strrchr (filename, '.');
>   if (ext == NULL)
> out_file = make_temp_file ("");
>   else
> out_file = make_temp_file (ext);
>   /* The linker will delete the files we give it, so make copies.  */
> - copy_file (out_file, argv[i]);
> + 

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[H.J. Lu]

On Fri, Feb 19, 2016 at 11:03 AM, Matthijs van Duin
 wrote:
> On 19 February 2016 at 14:35, Michael Matz  wrote:
>> struct S {
>>   S() {something();}
>> };
>>
>> would be an empty type, and that's not what we want.
>
> Why not? The default constructor is never invoked as part of passing
> such an object around. Its copy constructor is a nop and requires no
> reference to the original object.
>

Do you have a precise wording to describe it?

-- 
H.J.

Re: [C++ PATCH] Fix option handling when -std=gnu++14 is not used (PR 69865)

[Jason Merrill]

On 02/19/2016 02:37 PM, Bernd Edlinger wrote:

On 19.02.2016 17:03, Jason Merrill wrote:

On 02/19/2016 10:51 AM, Bernd Edlinger wrote:

+  flag_isoc94 = 0;
+  flag_isoc99 = 0;


Why?  These flags are global variables, so they're already
zero-initialized.

Otherwise the changes look good to me.

Jason



Hi Jason,

This hunk is really needed.

I can prove it:

Index: gcc/testsuite/c-c++-common/Wshift-negative-value-6.c
===
--- gcc/testsuite/c-c++-common/Wshift-negative-value-6.c(revision 
233557)
+++ gcc/testsuite/c-c++-common/Wshift-negative-value-6.c(working copy)
@@ -1,7 +1,7 @@
   /* PR c/65179 */
   /* { dg-do compile } */
   /* { dg-options "-O -Wextra" } */
-/* { dg-additional-options "-std=c++03" { target c++ } } */
+/* { dg-additional-options "-std=c++11 -std=c++03" { target c++ } } */
   /* { dg-additional-options "-std=c90" { target c } } */

   enum E {


unpatched gcc gives:

  === g++ tests ===


Running target unix
FAIL: c-c++-common/Wshift-negative-value-6.c(test for bogus
messages, line 10)
FAIL: c-c++-common/Wshift-negative-value-6.c(test for bogus
messages, line 26)
FAIL: c-c++-common/Wshift-negative-value-6.c(test for bogus
messages, line 29)


Would you like me to commit the above test case change together with
both parts of the patch?

Do you think the patch is OK now?


OK.

Jason

Re: [PATCH 4/n] OpenMP 4.0 offloading infrastructure: lto-wrapper

[Thomas Schwinge]

Hi!

On Thu, 2 Oct 2014 19:14:57 +0400, Ilya Verbin  wrote:
> With this patch lto-wrapper performs invocation of mkoffload tool for each
> offload target.  This tool [...]
> will compile IR from .gnu.offload_lto_* sections into offload
> target code and embed the resultant code (offload image) into the new host's
> object file.

Consider the following scenario:

$ cat < CSTS-214-acc.c
int acc (void)
{
  int a;

#pragma acc parallel num_gangs (1) copyout (a)
  a = 100;

  return a;
}
$ cat < CSTS-214-test.c
extern int acc (void);

int main (void)
{
  if (acc () != 100)
__builtin_abort ();
  
  return 0;
}

Compile these two files as follows:

$ [GCC] -fopenacc -c CSTS-214-acc.c
$ x86_64-linux-gnu-ar -cr CSTS-214-acc.a CSTS-214-acc.o
$ [GCC] -fopenacc CSTS-214-test.c CSTS-214-acc.a

The last step will fail -- with incomprehensible diagnostics, ;-) as so
often when offloading fails...  Here's what's going on: the
LTO/offloading machinery correctly identifies that it needs to process
the CSTS-214-acc.c:acc function, present in the CSTS-214-acc.a archive
file at a certain offset, and it "encodes" that as follows:
CSTS-214-acc.a@0x9e (see lto-plugin/lto-plugin.c:claim_file_handler, the
"file->offset != 0" code right at the beginning).  This makes its way
down through here:

> --- a/gcc/lto-wrapper.c
> +++ b/gcc/lto-wrapper.c

> +/* Copy a file from SRC to DEST.  */
> +
> +static void
> +copy_file (const char *dest, const char *src)
> +{
> +  [...]
> +}

> @@ -624,6 +852,54 @@ run_gcc (unsigned argc, char *argv[])

> +  /* If object files contain offload sections, but do not contain LTO 
> sections,
> + then there is no need to perform a link-time recompilation, i.e.
> + lto-wrapper is used only for a compilation of offload images.  */
> +  if (have_offload && !have_lto)
> +{
> +  for (i = 1; i < argc; ++i)
> + if ([...])
> +   {
> + char *out_file;
> + /* Can be ".o" or ".so".  */
> + char *ext = strrchr (argv[i], '.');
> + if (ext == NULL)
> +   out_file = make_temp_file ("");
> + else
> +   out_file = make_temp_file (ext);
> + /* The linker will delete the files we give it, so make copies.  */
> + copy_file (out_file, argv[i]);
> + printf ("%s\n", out_file);
> +   }
> +[...]
> +  goto finish;
> +}
> +
>if (lto_mode == LTO_MODE_LTO)
>  {
>flto_out = make_temp_file (".lto.o");
> @@ -850,6 +1126,10 @@ cont:
>obstack_free (_obstack, NULL);
>  }
>  
> + finish:
> +  if (offloadend)
> +printf ("%s\n", offloadend);
> +
>obstack_free (_obstack, NULL);
>  }

When we hit this, for argv "CSTS-214-acc.a@0x9e", the copy_file call will
fail -- there is no "CSTS-214-acc.a@0x9e" file to copy.  If we strip off
the "@0x[...]" suffix (but still printf the filename including the
suffix), then things work.  I copied that bit of code from earlier in
this function, where the same archive offset handling needs to be done.
Probably that code should be refactored a bit.

Also, I wonder if the "ext == NULL" case can really happen, and needs to
be handled as done in the code cited above, or if that can be simplified?
(Not yet tested that.)

Will something like the following be OK to fix this issue, or is that
something "that should not happen", should be fixed differently?

--- gcc/lto-wrapper.c
+++ gcc/lto-wrapper.c
@@ -1161,15 +1161,31 @@ run_gcc (unsigned argc, char *argv[])
&& strncmp (argv[i], "-flinker-output=",
sizeof ("-flinker-output=") - 1) != 0)
  {
+   char *p;
+   off_t file_offset = 0;
+   long loffset;
+   int consumed;
+   char *filename = argv[i];
+
+   if ((p = strrchr (argv[i], '@'))
+   && p != argv[i] 
+   && sscanf (p, "@%li%n", , ) >= 1
+   && strlen (p) == (unsigned int) consumed)
+ {
+   filename = XNEWVEC (char, p - argv[i] + 1);
+   memcpy (filename, argv[i], p - argv[i]);
+   filename[p - argv[i]] = '\0';
+   file_offset = (off_t) loffset;
+ }
+
char *out_file;
-   /* Can be ".o" or ".so".  */
-   char *ext = strrchr (argv[i], '.');
+   char *ext = strrchr (filename, '.');
if (ext == NULL)
  out_file = make_temp_file ("");
else
  out_file = make_temp_file (ext);
/* The linker will delete the files we give it, so make copies.  */
-   copy_file (out_file, argv[i]);
+   copy_file (out_file, filename);
printf ("%s\n", out_file);
  }
   goto finish;


Grüße
 Thomas


signature.asc
Description: PGP signature

[Bug libstdc++/69877] Problem with std::basic_ios::setstate()

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69877

--- Comment #3 from Jonathan Wakely  ---
(In reply to Leo Carreon from comment #1)
> In addition, if I comment out the line:
> 
> vStream.exceptions(std::ios_base::badbit);
> 
> The executable does not core dump.

Yes, obviously.

If you don't ask the stream to throw an exception when the badbit is set in the
stream's state, then it won't throw an exception when you set the badbit.

[Bug libstdc++/69877] Problem with std::basic_ios::setstate()

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69877

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Jonathan Wakely  ---
(In reply to Leo Carreon from comment #0)
> Please notice that the executable core dumped.  Even if I try to catch the
> exception, it still core dumps.  If I remember correctly, this did not
> happen on Fedora 22 which included g++ 5.1.1.

No, an unhandled exception results in abort() which always dumped core. That
hasn't changed.

The reason you can't catch it is that the library throws std::ios::failure but
you try to catch std::__cxx11::ios::failure, due to the default ABI changing in
F23. If you compile with -D_GLIBCXX_USE_CXX11_ABI=0 then you'll be able to
refer to the old exception type, but that changes the ABI.

The fact the old ABI exception is thrown is PR66145.

*** This bug has been marked as a duplicate of bug 66145 ***

[Bug libstdc++/66145] [5/6 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145

Jonathan Wakely  changed:

   What|Removed |Added

 CC||lcarreon at bigpond dot net.au

--- Comment #9 from Jonathan Wakely  ---
*** Bug 69877 has been marked as a duplicate of this bug. ***

Re: [C++ PATCH] Fix option handling when -std=gnu++14 is not used (PR 69865)

[Bernd Edlinger]

On 19.02.2016 17:03, Jason Merrill wrote:
> On 02/19/2016 10:51 AM, Bernd Edlinger wrote:
>> +  flag_isoc94 = 0;
>> +  flag_isoc99 = 0;
>
> Why?  These flags are global variables, so they're already
> zero-initialized.
>
> Otherwise the changes look good to me.
>
> Jason
>

Hi Jason,

This hunk is really needed.

I can prove it:

Index: gcc/testsuite/c-c++-common/Wshift-negative-value-6.c
===
--- gcc/testsuite/c-c++-common/Wshift-negative-value-6.c(revision 
233557)
+++ gcc/testsuite/c-c++-common/Wshift-negative-value-6.c(working copy)
@@ -1,7 +1,7 @@
  /* PR c/65179 */
  /* { dg-do compile } */
  /* { dg-options "-O -Wextra" } */
-/* { dg-additional-options "-std=c++03" { target c++ } } */
+/* { dg-additional-options "-std=c++11 -std=c++03" { target c++ } } */
  /* { dg-additional-options "-std=c90" { target c } } */

  enum E {


unpatched gcc gives:

 === g++ tests ===


Running target unix
FAIL: c-c++-common/Wshift-negative-value-6.c(test for bogus 
messages, line 10)
FAIL: c-c++-common/Wshift-negative-value-6.c(test for bogus 
messages, line 26)
FAIL: c-c++-common/Wshift-negative-value-6.c(test for bogus 
messages, line 29)


Would you like me to commit the above test case change together with
both parts of the patch?

Do you think the patch is OK now?


Thanks
Bernd.

[Bug libstdc++/69877] Problem with std::basic_ios::setstate()

[lcarreon at bigpond dot net.au]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69877

--- Comment #1 from Leo Carreon  ---
In addition, if I comment out the line:

vStream.exceptions(std::ios_base::badbit);

The executable does not core dump.

Re: [PATCH] combine: Delete EQ* notes when pseudo mode changes (PR60818)

[Eric Botcazou]

> It is not a regression (it is in all open release branches already).
> I can postpone it if you think that is wiser?

I do think that the combiner is one of those pieces of code that you ought not 
to touch unless you really need to.

> I misread it as moving the notes from i3 to i2, ugh.  It looks like we
> do have a problem if i2 is a parallel with only one SET; but we already
> had a problem anyway?  The REG_EQ* is put on the wrong insn?

Possibly indeed, we might need to filter them out during the move.

-- 
Eric Botcazou

[Bug c++/69864] Fix various Wnarrowing minor issues

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69864

--- Comment #12 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #11)
> Patch: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01326.html

Committed to trunk.

[Bug libstdc++/69877] New: Problem with std::basic_ios::setstate()

[lcarreon at bigpond dot net.au]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69877

Bug ID: 69877
   Summary: Problem with std::basic_ios::setstate()
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lcarreon at bigpond dot net.au
  Target Milestone: ---

I created the following simple test program:

#include 
#include 

int main()
{
std::ostringstream vStream;
vStream.exceptions(std::ios_base::badbit);

vStream.setstate(std::ios_base::badbit);

return 0;
}

I then compiled and linked it on 64-bit Fedora 23 using the following commands:

g++ -ansi -c -g -m64 -o sample.o -Wall -Werror -std=c++14 sample.cpp
g++ -g -m64 -o sample sample.o

When I execute the resulting executable, it generates the following output:

terminate called after throwing an instance of 'std::ios_base::failure'
  what():  basic_ios::clear
./sample.sh: line 3:  3397 Aborted (core dumped) ./sample

Please notice that the executable core dumped.  Even if I try to catch the
exception, it still core dumps.  If I remember correctly, this did not happen
on Fedora 22 which included g++ 5.1.1.

Do you have an idea why this is happening?  The above problem is causing my
user defined type's stream insertion/extraction operators to fail.

[Bug c++/68585] [5/6 Regression] c++14 code accepted by 4.9 not accepted by 5 and 6

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68585

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Jason Merrill  ---
Fixed.

[Bug c++/68679] [5/6 Regression] gcc-5.2.1 ICE in C++11 anon union of structs with template fns, OK in gcc <= 4.9.3

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68679

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #19 from Jakub Jelinek  ---
Fixed.  If you encounter some other -Wnonnull-compare false positive, please
file a new PR.

[Bug c++/69851] [6 Regression] ICE: in assign_temp, at function.c:961

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69851

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Jakub Jelinek  ---
Fixed.

[Bug c++/69850] [6 Regression] unnecessary -Wnonnull-compare warning

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69850

--- Comment #18 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb 19 19:16:31 2016
New Revision: 233568

URL: https://gcc.gnu.org/viewcvs?rev=233568=gcc=rev
Log:
PR c++/69850
* rtti.c (ifnonnull): Set TREE_NO_WARNING on the condition, use
NE_EXPR instead of EQ_EXPR and swap last two arguments on COND_EXPR.

* g++.dg/warn/Wnonnull-compare-4.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/warn/Wnonnull-compare-4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/rtti.c
trunk/gcc/testsuite/ChangeLog

Re: [PATCH] combine: Delete EQ* notes when pseudo mode changes (PR60818)

[Segher Boessenkool]

On Fri, Feb 19, 2016 at 07:39:03PM +0100, Eric Botcazou wrote:
> > Not for stage 4 certainly.
> 
> If we go this way, is the bug a regression?  If no, why rushing the fix?

It is not a regression (it is in all open release branches already).
I can postpone it if you think that is wiser?

> > That moves those notes to i2notes, and then distribute_notes drops them?
> 
> That's not why I understand though.  The code appends i2notes to i3notes and 
> distribute_notes will preserve them on i3:

I misread it as moving the notes from i3 to i2, ugh.  It looks like we
do have a problem if i2 is a parallel with only one SET; but we already
had a problem anyway?  The REG_EQ* is put on the wrong insn?


Segher

Re: [Patch, fortran] PR69423 - [6 Regression] Invalid optimization with deferred-length character

[Dominique d'Humières]

With the patch I get an ICE when compiling gfortran.dg/allocate_error_5.f90

(lldb) target create 
"/opt/gcc/gcc6p-233563p2/libexec/gcc/x86_64-apple-darwin15.3.0/6.0.0/f951"
Current executable set to 
'/opt/gcc/gcc6p-233563p2/libexec/gcc/x86_64-apple-darwin15.3.0/6.0.0/f951' 
(x86_64).
(lldb) run /opt/gcc/_clean/gcc/testsuite/gfortran.dg/allocate_error_5.f90
Process 18138 launched: 
'/opt/gcc/gcc6p-233563p2/libexec/gcc/x86_64-apple-darwin15.3.0/6.0.0/f951' 
(x86_64)
 gProcess 18138 stopped
* thread #1: tid = 0x2ebfe4a, 0x0001000d5679 
f951`(chain=0x7fff5fbfef20, expr=0x0001427c56b8, 
front=)(tree *, tree, bool) + 41 at trans.c:1549, queue = 
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, 
address=0x50004)
frame #0: 0x0001000d5679 f951`(chain=0x7fff5fbfef20, 
expr=0x0001427c56b8, front=)(tree *, tree, bool) + 41 at 
trans.c:1549
   1546 
   1547   if (*chain)
   1548 {
-> 1549   if (TREE_CODE (*chain) != STATEMENT_LIST)
   1550 {
   1551   tree tmp;
   1552 
(lldb) bt
* thread #1: tid = 0x2ebfe4a, 0x0001000d5679 
f951`(chain=0x7fff5fbfef20, expr=0x0001427c56b8, 
front=)(tree *, tree, bool) + 41 at trans.c:1549, queue = 
'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, 
address=0x50004)
  * frame #0: 0x0001000d5679 f951`(chain=0x7fff5fbfef20, 
expr=0x0001427c56b8, front=)(tree *, tree, bool) + 41 at 
trans.c:1549
frame #1: 0x0001000f045e 
f951`::gfc_null_and_pass_deferred_len(sym=0x000143d06d50, 
init=0x7fff5fbfef20, loc=0x7fff5fbfef10) + 174 at trans-decl.c:3965
frame #2: 0x0001000f9dba 
f951`gfc_trans_deferred_vars(proc_sym=0x000143d06a50, 
block=0x7fff5fbff0b0) + 2042 at trans-decl.c:4275
frame #3: 0x0001000fc5e4 
f951`gfc_generate_function_code(ns=) + 1332 at trans-decl.c:6269
frame #4: 0x00010008cb9c f951`gfc_parse_file() + 1644 at parse.c:5613
frame #5: 0x0001000d2d39 f951`::gfc_be_parse_file() + 57 at 
f95-lang.c:201
frame #6: 0x0001009ac32c f951`::compile_file() + 60 at toplev.c:465
frame #7: 0x000100d9caaf f951`toplev::main(int, char**) + 1154 at 
toplev.c:1988
frame #8: 0x000100d9c62d f951`toplev::main(this=, 
argc=, argv=) + 733
frame #9: 0x000100d9e479 f951`main(argc=2, argv=0x7fff5fbff318) + 
41 at main.c:39
frame #10: 0x7fff97c615ad libdyld.dylib`start + 1
frame #11: 0x7fff97c615ad libdyld.dylib`start + 1

Thanks for working on this PR,

Dominique

> Le 19 févr. 2016 à 09:47, Paul Richard Thomas  
> a écrit :
> 
> Dear All,
> 
> This has proven to be a rather vexatious bug to fix. On the face of
> it, using the indirect reference to the passed string length for
> deferred character length functions should have worked at all levels
> of optimization. However, setting the string length within a do loop
> resulted in the change not being visible within the rest of the
> function scope, even though the correct result was returned. This was,
> on the face of it, the same mechanism used for both dummies and
> declared results, which works fine at all levels of optimization.
> 
> In order to be as conservative as possible at this stage in the
> release cycle, I have resorted to the belt and braces approach of
> using a local variable '..result', which is nulled and returned, as
> appropriate, in a new helper function. So that the compiled code is
> consistent, I have done the same for functions with and without
> explicitly declared result variables.
> 
> There is some dead code in 'gfc_get_symbol_decl', which could, with
> advantage, be replaced by a gcc_assert. In addition,
> gfc_trans_deferred_vars could do with some further tidying up to
> ensure that the logic is clear. These steps can easily be done now if
> other maintainers think that it is timely.
> 
> Bootstraps and regtests on FC21/x86_64 - OK for trunk?
> 
> Paul
> 
> 2016-02-19  Paul Thomas  
> 
>PR fortran/69423
>* trans-decl.c (create_function_arglist): Deferred character
>length functions, with and without declared results, address
>the passed reference type as '.result' and the local string
>length as '..result'.
>(gfc_null_and_pass_deferred_len): Helper function to null and
>return deferred string lengths, as needed.
>(gfc_trans_deferred_vars): Call it, thereby reducing repeated
>code, add call for deferred arrays and reroute pointer function
>results. Avoid using 'tmp' for anything other that a temporary
>tree by introducing 'type_of_array' for the arrayspec type.
> 
> 2016-02-19  Paul Thomas  
> 
>PR fortran/69423
>* gfortran.dg/deferred_character_15.f90 : New test.
> 

Re: Need suggestion about bug 68425

[David Malcolm]

On Thu, 2016-02-18 at 14:28 +, Manuel López-Ibáñez wrote:
> On 18/02/16 11:40, Prasad Ghangal wrote:
> > Wouldn't it be nice instead of multiple warnings if gcc gives
> > single
> > warning like :
> > 
> > 68425.c:3:34: warning: excess elements in array initializer (6
> > elements, expected 2)
> >  const int array[2] = { 1, 2, 3 ,6 ,89 ,193};
> >^
> 
> Yes! Perhaps even (now that we have ranges!):
> 
> 68425.c:3:34: warning: excess elements in array initializer (6
> elements, 
> expected 2)
>const int array[2] = { 1, 2, 3 ,6 ,89 ,193};
> ^

Yes, that would be ideal.  Unfortunately, not every tree expression
node has a location stored for it, so implementing the underlined range
might be tricky to do.  (in particular, INTEGER_CST doesn't.  I hope to
look into that for gcc 7, perhaps with a wrapper node to provide
locations for expr nodes that don't have them).

> But even without ranges, your suggestion would be a great
> improvement.

Agreed.

[Bug c++/69851] [6 Regression] ICE: in assign_temp, at function.c:961

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69851

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Fri Feb 19 19:11:58 2016
New Revision: 233566

URL: https://gcc.gnu.org/viewcvs?rev=233566=gcc=rev
Log:
PR c++/69851
* expr.c (store_field): Don't use bit-field path if exp is
COMPONENT_REF with TREE_ADDRESSABLE type, where TYPE_SIZE is
different from bitsize, but DECL_SIZE of FIELD_DECL is bitsize
and the assignment can be performed by bitwise copy.  Formatting
fix.

* g++.dg/torture/pr69851.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/torture/pr69851.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/expr.c
trunk/gcc/testsuite/ChangeLog

Re: [PATCH] Fix expansion of TREE_ADDRESSABLE bitwise copies (PR c++/69851)

[Jason Merrill]

On 02/19/2016 02:07 PM, Jakub Jelinek wrote:

On Fri, Feb 19, 2016 at 02:00:07PM -0500, Jason Merrill wrote:

On 02/19/2016 01:41 PM, Jakub Jelinek wrote:

On Fri, Feb 19, 2016 at 01:30:52PM -0500, Jason Merrill wrote:

On 02/19/2016 09:03 AM, Jakub Jelinek wrote:

As described in the PR, in C++ we can have assignments
where both the lhs and rhs are COMPONENT_REFs with TREE_ADDRESSABLE types,
including padding, but the FIELD_DECLs are artificial fields that have
narrower bit sizes.
store_field in this case takes the path of bit-field handling (even when
it has bitpos and bitsize multiples of BITS_PER_UNIT (I think that is
necessarily true for the TREE_ADDRESSABLE types), which is incorrect,
because the rhs is expanded in that case through expand_normal, which
for a result type wider than the FIELD_DECL with forces it into a temporary.
In older GCCs that just generated inefficient code (copy the rhs into a
stack temporary, then copy that to lhs), but GCC trunk ICEs on that.
Fixed by not taking the bit-field path in that case after verifying
we'll be able to expand it properly using the normal store_expr.


Won't store_expr clobber tail padding because it doesn't know about bitsize?


It doesn't clobber it, because it uses get_inner_reference, expands the
inner reference (which is necessarily for something TREE_ADDRESSABLE either
a MEM_REF or some decl that lives in memory), and get_inner_reference in
that case gives it the bitsize/bitpos from the FIELD_DECL.
Which is why in the patch I've posted there is the comparison of DECL_SIZE
of the FIELD_DECL against the bitsize that is passed to store_field.


Ah, that makes sense.  Please mention that in your added comment.

For GCC 7, can we drop the TREE_ADDRESSABLE check?


I think we can't drop it, but we could replace it with a check that
get_inner_reference is something that must live in memory
(MEM_REF/TARGET_MEM_REF of SSA_NAME, or of decl that lives in memory,
or decl itself that lives in memory).


Please mention that in the comment, as well.  OK with those comment changes.

Jason

Re: [C++ PATCH] Fix -Wnonnull-compare warning from dynamic_cast <...> (this) (PR c++/69850)

[Jason Merrill]

OK.

Jason

Re: [PATCH] Fix expansion of TREE_ADDRESSABLE bitwise copies (PR c++/69851)

[Jakub Jelinek]

On Fri, Feb 19, 2016 at 02:00:07PM -0500, Jason Merrill wrote:
> On 02/19/2016 01:41 PM, Jakub Jelinek wrote:
> >On Fri, Feb 19, 2016 at 01:30:52PM -0500, Jason Merrill wrote:
> >>On 02/19/2016 09:03 AM, Jakub Jelinek wrote:
> >>>As described in the PR, in C++ we can have assignments
> >>>where both the lhs and rhs are COMPONENT_REFs with TREE_ADDRESSABLE types,
> >>>including padding, but the FIELD_DECLs are artificial fields that have
> >>>narrower bit sizes.
> >>>store_field in this case takes the path of bit-field handling (even when
> >>>it has bitpos and bitsize multiples of BITS_PER_UNIT (I think that is
> >>>necessarily true for the TREE_ADDRESSABLE types), which is incorrect,
> >>>because the rhs is expanded in that case through expand_normal, which
> >>>for a result type wider than the FIELD_DECL with forces it into a 
> >>>temporary.
> >>>In older GCCs that just generated inefficient code (copy the rhs into a
> >>>stack temporary, then copy that to lhs), but GCC trunk ICEs on that.
> >>>Fixed by not taking the bit-field path in that case after verifying
> >>>we'll be able to expand it properly using the normal store_expr.
> >>
> >>Won't store_expr clobber tail padding because it doesn't know about bitsize?
> >
> >It doesn't clobber it, because it uses get_inner_reference, expands the
> >inner reference (which is necessarily for something TREE_ADDRESSABLE either
> >a MEM_REF or some decl that lives in memory), and get_inner_reference in
> >that case gives it the bitsize/bitpos from the FIELD_DECL.
> >Which is why in the patch I've posted there is the comparison of DECL_SIZE
> >of the FIELD_DECL against the bitsize that is passed to store_field.
> 
> Ah, that makes sense.  Please mention that in your added comment.
> 
> For GCC 7, can we drop the TREE_ADDRESSABLE check?

I think we can't drop it, but we could replace it with a check that
get_inner_reference is something that must live in memory
(MEM_REF/TARGET_MEM_REF of SSA_NAME, or of decl that lives in memory,
or decl itself that lives in memory).

Jakub

Re: [PATCH] Fix PR c++/68948 (wrong code generation due to invalid constructor call)

[Jason Merrill]

On 02/19/2016 11:56 AM, Patrick Palka wrote:

On Fri, Feb 19, 2016 at 10:41 AM, Jason Merrill  wrote:

On 02/18/2016 01:25 PM, Patrick Palka wrote:


On Wed, Feb 17, 2016 at 10:51 PM, Jason Merrill  wrote:


OK.


Is this an approval of the 2nd patch for next stage 1?


Actually, I've been looking at this area a lot recently in the context of
the 10200 fix, and now I think we can go ahead with the 2nd patch now, but
without the assert; I think it would fire if we wrote A::A().


I w ill commit the version without the assert shortly, but...

I haven't been able to get the assert to fire even when the A in
A::A() is dependent because in that case FN should be dependent, so we
would already have exited out of finish_call_expr due to the
type_dependent_expression_p (fn) check near the top of
finish_call_expr.  (In particular for dependent A::A(), FN is a
SCOPE_REF whose 1st operand is the dependent type A and 2nd operand is
the identifier node A.)

So it seems to me that the assert at that location is safe, since the
dummy object should be dependent only if the constructor call FN is
dependent in which case we would never reach the assert.


It might be safe given our current dependency analysis, but I'm planning 
to tighten that up in GCC 7, along the lines of my 69753 patch that I 
ended up backing out.  Why do you want the assert?


Jason

Re: [PATCH] Fix expansion of TREE_ADDRESSABLE bitwise copies (PR c++/69851)

[Jakub Jelinek]

On Fri, Feb 19, 2016 at 06:42:32PM +, Bernd Edlinger wrote:
> Hi,
> 
> 
> > --- gcc/expr.c.jj   2016-02-12 00:50:55.0 +0100
> > +++ gcc/expr.c  2016-02-19 10:43:59.639162531 +0100
> > @@ -6643,14 +6643,24 @@ store_field (rtx target, HOST_WIDE_INT b
> >   /* Except for initialization of full bytes from a CONSTRUCTOR, which
> >  we will handle specially below.  */
> >   && !(TREE_CODE (exp) == CONSTRUCTOR
> > -  && bitsize % BITS_PER_UNIT == 0))
> > +  && bitsize % BITS_PER_UNIT == 0)
> > + /* And except for bitwise copying of TREE_ADDRESSABLE types,
> > +where the FIELD_DECL has the right bitsize, but TREE_TYPE (exp)
> > +includes some extra padding.  */
> > + && (!TREE_ADDRESSABLE (TREE_TYPE (exp))
> > + || TREE_CODE (exp) != COMPONENT_REF
> > + || TREE_CODE (DECL_SIZE (TREE_OPERAND (exp, 1))) != INTEGER_CST
> > + || (bitsize % BITS_PER_UNIT != 0)
> > + || (bitpos % BITS_PER_UNIT != 0)
> > + || (compare_tree_int (DECL_SIZE (TREE_OPERAND (exp, 1)), bitsize)
> > + != 0)))
> >/* If we are expanding a MEM_REF of a non-BLKmode non-addressable
> >   decl we must use bitfield operations.  */
> 
> isn't the indentation of the new block wrong?

No, I think it is correct.

Jakub

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[Matthijs van Duin]

On 19 February 2016 at 14:35, Michael Matz  wrote:
> struct S {
>   S() {something();}
> };
>
> would be an empty type, and that's not what we want.

Why not? The default constructor is never invoked as part of passing
such an object around. Its copy constructor is a nop and requires no
reference to the original object.

Matthijs van Duin

Re: [patch] Clarify interaction of -Wnarrowing with -std

[Jason Merrill]

On 02/19/2016 07:42 AM, Jonathan Wakely wrote:

In PR69864 Manu suggests improving the docs to explain that
-Wnarrowing sometimes produces errors not warnings.

I think the right way to do that is clarify how it interacts with
-std. Specifically that the effect of -Wnarrowing listed first in the
manual *only* applies to C++98 modes, For all later modes (not just
with -std=c++11 as it says now), narrowing conversions produce errors
or warnings by default.

OK for trunk?


OK, thanks.

Jason

Re: [PATCH] Fix expansion of TREE_ADDRESSABLE bitwise copies (PR c++/69851)

[Jason Merrill]

On 02/19/2016 01:41 PM, Jakub Jelinek wrote:

On Fri, Feb 19, 2016 at 01:30:52PM -0500, Jason Merrill wrote:

On 02/19/2016 09:03 AM, Jakub Jelinek wrote:

As described in the PR, in C++ we can have assignments
where both the lhs and rhs are COMPONENT_REFs with TREE_ADDRESSABLE types,
including padding, but the FIELD_DECLs are artificial fields that have
narrower bit sizes.
store_field in this case takes the path of bit-field handling (even when
it has bitpos and bitsize multiples of BITS_PER_UNIT (I think that is
necessarily true for the TREE_ADDRESSABLE types), which is incorrect,
because the rhs is expanded in that case through expand_normal, which
for a result type wider than the FIELD_DECL with forces it into a temporary.
In older GCCs that just generated inefficient code (copy the rhs into a
stack temporary, then copy that to lhs), but GCC trunk ICEs on that.
Fixed by not taking the bit-field path in that case after verifying
we'll be able to expand it properly using the normal store_expr.


Won't store_expr clobber tail padding because it doesn't know about bitsize?


It doesn't clobber it, because it uses get_inner_reference, expands the
inner reference (which is necessarily for something TREE_ADDRESSABLE either
a MEM_REF or some decl that lives in memory), and get_inner_reference in
that case gives it the bitsize/bitpos from the FIELD_DECL.
Which is why in the patch I've posted there is the comparison of DECL_SIZE
of the FIELD_DECL against the bitsize that is passed to store_field.


Ah, that makes sense.  Please mention that in your added comment.

For GCC 7, can we drop the TREE_ADDRESSABLE check?

Jason

Re: RFC: Update Intel386, x86-64 and IA MCU psABIs for passing/returning empty struct

[Matthijs van Duin]

On 19 February 2016 at 16:27, H.J. Lu  wrote:
> We want to include static member functions and exclude non-static member
> functions.

There's no reason to disallow non-static member functions in general; they
have no impact on being trivially copyable or not, only the presence of a
non-trivial copy constructor or destructor does.