[Bug libstdc++/58909] C++11's condition variables fail with static linking

[abbytsing at hotmail dot com]

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

abbycin  changed:

   What|Removed |Added

 CC||abbytsing at hotmail dot com

--- Comment #10 from abbycin  ---
Created attachment 40881
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40881=edit
condition_variable::wait and pthread_cond_wait

test platform
OS openSUSE Tumbleweed 64bit
kernel version 4.10.1-1-default 
gcc version 6.3.1 20170202 [gcc-6-branch revision 245119] (SUSE Linux)

[Bug c/79813] Hitting seg fault in cc1

[piers at piersandkatie dot com]

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

--- Comment #2 from Piers Finlayson  ---
I have reproduced on 5.2.0, but I strongly suspect some sort of build
error/inconsistently, possibly to do with musl libc.  I'm going to report to
the toolchain maintainers - happy for you to close this.

[Bug middle-end/79768] `-Wmaybe-uninitialized' false positive with optimisation

[caspervector at gmail dot com]

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

--- Comment #4 from Casper Ti. Vector  ---
(In reply to Manuel López-Ibáñez from comment #3)
> This is just too weird code for GCC to analyze correctly at -O2. It doesn't
> warn at -O3 (with 5.4.0 20160609)

The coding pattern is quite common though.  Nevertheless, if that only makes
trouble for `-Wmaybe-uninitialized' (and not the generated code), it is somehow
understandable.  Thanks anyway :)

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sat Mar  4 03:13:34 2017
New Revision: 245891

URL: https://gcc.gnu.org/viewcvs?rev=245891=gcc=rev
Log:
2017-03-03  Jerry DeLisle  

PR fortran/79841
* openmp.c (check_symbol_not_pointer): Adjust diagnostic.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/openmp.c

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle  ---
I will commit this:

diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 3ca23493..753dc5ad 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -3732,7 +3732,7 @@ check_symbol_not_pointer (gfc_symbol *sym, locus loc,
const char *name)
 gfc_error ("POINTER object %qs of derived type in %s clause at %L",
   sym->name, name, );
   if (sym->ts.type == BT_DERIVED && sym->attr.cray_pointer)
-gfc_error ("Cray pointer object of derived type %qs in %s clause at %L",
+gfc_error ("Cray pointer object %qs of derived type in %s clause at %L",
   sym->name, name, );
   if (sym->ts.type == BT_DERIVED && sym->attr.cray_pointee)
 gfc_error ("Cray pointee object of derived type %qs in %s clause at %L",
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 36786c03..fc22d802 100644

[Bug c/16351] NULL dereference warnings

[msebor at gcc dot gnu.org]

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

--- Comment #54 from Martin Sebor  ---
(In reply to janus from comment #53)

Unfortunately, it isn't.  The warning depends on actually dereferencing the
null pointer (i.e., trying to access the object it points to) and passing the
argument in the call to f(*((int*) NULL)) doesn't do that.  The pointer is
derefernced later, in f, but the -Wnull-dereference checker doesn't see it
because the call to f() isn't inlined by the time it runs (or ever).  To issue
the warning in this case the check also needs to happen when binding to
references.

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #3 from Jerry DeLisle  ---
I will adjust it and check testsuite.

[Bug tree-optimization/77627] Unexpected void * dereference in uninit warning (and missed out-of-bounds warning)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #2 from Manuel López-Ibáñez  ---
It seems the same as PR72826.

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

[Bug middle-end/72826] bad pretty-printing of decl *((void*)& x +offset) for uninitialized structure field (ESRA)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  ---
*** Bug 77627 has been marked as a duplicate of this bug. ***

[Bug middle-end/72826] bad pretty-printing of decl *((void*)& x +offset) for uninitialized structure field (ESRA)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

Summary|Poor diagnostic for |bad pretty-printing of decl
   |uninitialized structure |*((void*)& x +offset) for
   |field   |uninitialized structure
   ||field (ESRA)

--- Comment #4 from Manuel López-Ibáñez  ---
Clearer summary to spot duplicates

[Bug tree-optimization/18501] [5/6/7 Regression] Missing 'used uninitialized' warning (CCP)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||fwd at quantentunnel dot de

--- Comment #77 from Manuel López-Ibáñez  ---
*** Bug 78203 has been marked as a duplicate of this bug. ***

[Bug middle-end/78203] missing warning on return of unitialized variable

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #5 from Manuel López-Ibáñez  ---
Dup

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

[Bug middle-end/78993] False positive from -Wmaybe-uninitialized

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Andrew Pinski from comment #4)
>   # i_5 = PHI 
>   # j_27 = PHI 
>   # prephitmp_7 = PHI <0(3), prephitmp_17(4)>
>   _14 = i_5 > 9;
>   _18 = prephitmp_7 | _14;
>   if (_18 != 0)
> goto ; [44.99%]
>   else
> goto ; [55.01%]
> 
> 
> Most likely conditional warning does not understand the above case :).

If the reason is the prephitmp_7 | _14, then this is PR42145

[Bug middle-end/79768] `-Wmaybe-uninitialized' false positive with optimisation

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  ---
This is just too weird code for GCC to analyze correctly at -O2. It doesn't
warn at -O3 (with 5.4.0 20160609)

[Bug middle-end/78370] Missing uninitialzed warning

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #3 from Manuel López-Ibáñez  ---
probably PR19430

[Bug middle-end/71699] bogus -Wmaybe-uninitialized warning: gcc misses that non-NULL pointer + offset can never be NULL

[manish at mozilla dot com]

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

--- Comment #11 from Manish Goregaokar  ---
(In reply to Manuel López-Ibáñez from comment #10)
> (In reply to Manish Goregaokar from comment #9)
> > Already sent it :)
> > 
> > https://gcc.gnu.org/ml/gcc-patches/2016-06/msg02057.HTML is the current
> > patch; need to look at the test failures before moving forward.
> 
> Was this ever committed? Last comment by Richard was here:
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-06/msg02061.html

No, there were test failures I think. Or maybe not, I don't remember.

[Bug target/79846] s390: untranslatable diagnostic in s390.c

[joseph at codesourcery dot com]

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

--- Comment #1 from joseph at codesourcery dot com  ---
The correct way to print HOST_WIDE_INT is with %wu etc. formats.

[Bug middle-end/71699] bogus -Wmaybe-uninitialized warning: gcc misses that non-NULL pointer + offset can never be NULL

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to Manish Goregaokar from comment #9)
> Already sent it :)
> 
> https://gcc.gnu.org/ml/gcc-patches/2016-06/msg02057.HTML is the current
> patch; need to look at the test failures before moving forward.

Was this ever committed? Last comment by Richard was here:

https://gcc.gnu.org/ml/gcc-patches/2016-06/msg02061.html

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 70991, which changed state.

Bug 70991 Summary: Uninitialized class allowed if it came from self-assignment, 
or a member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70991

   What|Removed |Added

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

[Bug c++/52167] self-assignment should at least produce use-of-uninitialized warning

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||appfault at hotmail dot com

--- Comment #5 from Manuel López-Ibáñez  ---
*** Bug 70991 has been marked as a duplicate of this bug. ***

[Bug c++/70991] Uninitialized class allowed if it came from self-assignment, or a member function

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #3 from Manuel López-Ibáñez  ---
-Winit-self should warn for this but it doesn't work for classes.

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

[Bug target/79752] incorrect code generation for __divkf3 with -O2 -mcpu=power9

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from acsawdey at gcc dot gnu.org ---
Fixed in 245817.

[Bug middle-end/19430] taking address of a var causes missing uninitialized warning

[manu at gcc dot gnu.org]

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

--- Comment #32 from Manuel López-Ibáñez  ---
(In reply to Vincent Lefèvre from comment #31)
> In any case, no warnings are generated. So, the problem here is not related
> to whether the address of j is taken, but to something else.

With a constant, you hit PR18501. If you use "j = i", it warns as it should.

[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)

[bernds at gcc dot gnu.org]

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

--- Comment #9 from Bernd Schmidt  ---
Maybe we just need to declare this address to be invalid for TImode. The
following seems to cure the testcase; untested otherwise.

Index: i386.c
===
--- i386.c  (revision 245685)
+++ i386.c  (working copy)
@@ -15877,7 +15877,7 @@ ix86_validate_address_register (rtx op)
be recognized.  */

 static bool
-ix86_legitimate_address_p (machine_mode, rtx addr, bool strict)
+ix86_legitimate_address_p (machine_mode mem_mode, rtx addr, bool strict)
 {
   struct ix86_address parts;
   rtx base, index, disp;
@@ -15899,7 +15899,8 @@ ix86_legitimate_address_p (machine_mode,
 {
   rtx reg = ix86_validate_address_register (base);

-  if (reg == NULL_RTX)
+  if (reg == NULL_RTX
+ || (GET_MODE (reg) != Pmode && mem_mode == TImode))
return false;

   if ((strict && ! REG_OK_FOR_BASE_STRICT_P (reg))

[Bug bootstrap/79814] pass-instances.def:36:14: error: ‘*.gcc::pass_manager::pass_warn_unused_result_1’ is used uninitialized in this function

[dmalcolm at gcc dot gnu.org]

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

--- Comment #2 from David Malcolm  ---
The code in question is:
  do { ((void)(!(
 __null 
 == pass_warn_unused_result_1) ? fancy_abort ("./pass-instances.def", 36,
__FUNCTION__), 0 : 0)); if ((1) == 1) pass_warn_unused_result_1 =
make_pass_warn_unused_result (m_ctxt); else {
((void)(!(pass_warn_unused_result_1) ? fancy_abort ("./pass-instances.def", 36,
__FUNCTION__), 0 : 0)); pass_warn_unused_result_1 =
pass_warn_unused_result_1->clone (); } p = next_pass_1 (p,
pass_warn_unused_result_1, pass_warn_unused_result_1); } while (0);

i.e. it's complaining about this assertion:

  gcc_assert (NULL == PASS ## _ ## NUM); \

within the definition of NEXT_PASS(PASS, NUM) supplied within the pass_manager
ctor: it's asserting that a pointer field within the object is NULL.

pass_manager::operator new ensures that the underlying memory of the pass
manager is zero-initialized, but clearly the warning has no knowledge of this.

Eliminating the assertion fixes the warning, FWIW.

[Bug c/79847] New: diagnostics: missing space in "implicit declaration of function"

[roland.illig at gmx dot de]

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

Bug ID: 79847
   Summary: diagnostics: missing space in "implicit declaration of
function"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from c-decl.c:

G_("implicit declaration of function %qE;did you mean %qs?"),

There should be a space after the semicolon.

[Bug target/79846] New: s390: untranslatable diagnostic in s390.c

[roland.illig at gmx dot de]

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

Bug ID: 79846
   Summary: s390: untranslatable diagnostic in s390.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from s390.c:

error("constant argument %d for builtin %qF is out of range (0.."
  HOST_WIDE_INT_PRINT_UNSIGNED ")",

This function call results in a translation request for the string "constant
argument %d for builtin %qF is out of range (0..".

No matter how I translate this string, it will never be used because the
HOST_WIDE_INT_PRINT_UNSIGNED constant will be resolved by the C compiler but
not by xgettext.

The first argument to the "error" function must always be a concatenation of
string literals, as seen by a very naive parser.

[Bug target/79845] New: rs6000: make code in rd6000.c more i18n-friendly

[roland.illig at gmx dot de]

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

Bug ID: 79845
   Summary: rs6000: make code in rd6000.c more i18n-friendly
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from rs6000.c:

error ("Builtin function %s requires the -mhard-dfp option", name);

There are several variants of the above line. Currently one human translator
for each of the human languages has to translate all these variants one by one.
It would be much easier if the C code looked like this:

error ("Builtin function %s requires the %s option", name, "-mhard-dfp");

Not only does this reduce the work for translators, it also leads to fewer
possibilities for typos in the translations.

[Bug fortran/79844] New: diagnostics: extra space at end of line

[roland.illig at gmx dot de]

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

Bug ID: 79844
   Summary: diagnostics: extra space at end of line
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from fortran/trans-intrinsic.c:

gfc_error ("The event variable at %L shall not be coindexed ",
   _expr->where);

The space after "coindexed" looks like a typo.

[Bug fortran/79843] New: diagnostics: missing word in fortran/symbol.c, conflict_std

[roland.illig at gmx dot de]

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

Bug ID: 79843
   Summary: diagnostics: missing word in fortran/symbol.c,
conflict_std
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from fortran/symbol.c:

conflict_std:
  if (name == NULL)
{
  return gfc_notify_std (standard, "%s attribute "
 "with %s attribute at %L", a1, a2,
 where);
}
  else
{
  return gfc_notify_std (standard, "%s attribute "
 "with %s attribute in %qs at %L",
 a1, a2, name, where);
}

These diagnostic seem to be missing the word "conflicts" before the "with".

[Bug libfortran/78379] Processor-specific versions for matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #29 from Thomas Koenig  ---
(In reply to David Edelsohn from comment #28)
> Because PPC64LE Linux reset the base ISA level, VSX now is enabled by
> default, so a function clone for VSX probably isn't necessary.  While
> special versions might help AIX and PPC64BE, with lower ISA defaults, those
> are not the focus.

What about ARM NEON?  Is this time of the normal ISA level?

[Bug c/79758] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in store_parm_decls_oldstyle, at c/c-decl.c:8973

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed for GCC 7.

[Bug c/79758] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in store_parm_decls_oldstyle, at c/c-decl.c:8973

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Fri Mar  3 22:19:24 2017
New Revision: 245886

URL: https://gcc.gnu.org/viewcvs?rev=245886=gcc=rev
Log:
PR c/79758
* c-decl.c (store_parm_decls_oldstyle): Check if the element of
current_function_prototype_arg_types is error_mark_node.  Fix
formatting.  Use TREE_VALUE instead of TREE_TYPE.

* gcc.dg/noncompile/pr79758.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/noncompile/pr79758.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/79842] New: i18n: subword translation in "Can't use the same %smodule"

[roland.illig at gmx dot de]

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

Bug ID: 79842
   Summary: i18n: subword translation in "Can't use the same
%smodule"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

gfc_fatal_error ("Can't USE the same %smodule we're building!",
 p->state == COMP_SUBMODULE ? "sub" : "");

The message is either of these:
* "Can't USE the same module we're building!"
* "Can't USE the same submodule we're building!"

As a translator, I have no chance of providing a proper translation for this,
since the word part "sub" is always introduced.

Translations should always be complete sentences. In this case, the easiest
solution is this:

  for (p = gfc_state_stack; p; p = p->previous)
if ((p->state == COMP_MODULE || p->state == COMP_SUBMODULE)
 && strcmp (p->sym->name, module_name) == 0)
  if (p->state == COMP_SUBMODULE)
gfc_fatal_error ("Can't USE a submodule that is currently built");
  else
gfc_fatal_error ("Can't USE a module that is currently built");

This also fixes #79840 by removing the exclamation mark and rewording the
diagnostic.

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[yselkowi at redhat dot com]

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

--- Comment #4 from Yaakov Selkowitz  ---
This is an upstream issue in the recent zlib releases, here's a patch:

https://github.com/cygwinports/zlib/blob/master/1.2.11-gzopen_w.patch

Configuring with --with-system-zlib avoids this, as long as gcc doesn`t try
using the Win32-only gzopen_w on Cygwin (which it hasn't in the past).

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[daniel.santos at pobox dot com]

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

--- Comment #3 from Daniel Santos  ---
I'm guessing that either they didn't test on Cygwin or they tested on a
pre-release version or I have some local/environmental issue, although my
environment was just recently generated.

Upstream is at 1.2.11 and the latest zlib available in Cygwin is 1.2.8-3, which
does not have this patch, but I am not an expert in Cygwin.  _wopen is an
ms-proprietary function and I presumed that it not being exported in Cygwin was
intentional, although I could be wrong.  It's probably a good idea to send it
upstream.

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

[roland.illig at gmx dot de]

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

--- Comment #2 from Roland Illig  ---
German readers generally expect the %qs directly after the word "object".

This choice should eliminate all ambiguities, since in "object of type %qs",
the user no longer has to think about whether the %qs belongs to the object or
the type.

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #1 from Jerry DeLisle  ---
Of the two, which makes the most sense to you in german? In english it really
can go both ways I think.

It should not be difficult to make them the same.

[Bug fortran/79596] translation: argument to gfc_internal_error should not be translated

[joseph at codesourcery dot com]

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

--- Comment #3 from joseph at codesourcery dot com  ---
On Fri, 3 Mar 2017, roland.illig at gmx dot de wrote:

> I assume that somewhere there is some list of functions that take translatable
> strings, since xgettext has to decide which of these functions take
> printf-style arguments and which take gcc-internal-style arguments.

It's based on argument names ending with "msgid".  See ABOUT-GCC-NLS.

[Bug fortran/79841] New: Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

[roland.illig at gmx dot de]

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

Bug ID: 79841
   Summary: Inconsistent diagnostics in fortran/openmp.c, function
check_symbol_not_pointer
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

gfc_error ("POINTER object %qs of derived type in %s clause at %L",
   sym->name, name, );
gfc_error ("Cray pointer object of derived type %qs in %s clause at %L",
   sym->name, name, );

In the first call, the %qs appears after the word "object", in the second call
the %qs appear after the word "type".

As the German translator, I am confused now since the same expression is used
to refer to the object in one case and to the type of the object in the other
case.

All diagnostics in the check_symbol_not_pointer function should follow the same
pattern.

[Bug fortran/79840] Inconsistent exclamation mark in diagnostic

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This is an internal compiler error diagnostic really. Though maybe it should be
consistent it is not a huge issue.

[Bug fortran/79840] New: Inconsistent exclamation mark in diagnostic

[roland.illig at gmx dot de]

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

Bug ID: 79840
   Summary: Inconsistent exclamation mark in diagnostic
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

from fortran/module.c:

gfc_fatal_error ("Can't USE the same %smodule we're building!", ...);

This diagnostic uses an exclamation mark, as opposed to all the others that
don't use any punctuation at all. It also talks about "we", which is different
from all other diagnostics.

The diagnostic should follow the same pattern as all the other ones.

[Bug libstdc++/79839] New: malloc(0) returns 0 on AIX even with _LINUX_SOURCE_COMPAT

[jaideepbajwa at hotmail dot com]

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

Bug ID: 79839
   Summary: malloc(0) returns 0 on AIX even with
_LINUX_SOURCE_COMPAT
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jaideepbajwa at hotmail dot com
  Target Milestone: ---
Target: aix

malloc(0) returning 0 is expected behaviour on AIX but compiling with
-D_LINUX_SOURCE_COMPAT, malloc(0) should return a valid pointer. As per:
https://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.basetrf1/malloc.html
 
It doesn't work for c++ program which includes . In the header it
states:
// Get rid of those macros defined in  in lieu of real functions.
...
#undef malloc

The above seems to be causing the issue and resetting the behaviour of
-D_LINUX_SOURCE_COMPAT.

Code to reproduce:
>cat malloc.cpp
#include 
//#include   //<-- Works this stdlib
#include 
int main() {
  printf("%p \n", malloc(0));
  return 0;
}

>g++ malloc.cpp -D_LINUX_SOURCE_COMPAT
>./a.out
0

[Bug middle-end/79805] [7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c/79837] incomplete diagnostic in c-parser: expected +, *, -, &, ^, |, &&, ||, min or identifier

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
No, min and max are identifiers, so no need to mention them.

[Bug c/79837] incomplete diagnostic in c-parser: expected +, *, -, &, ^, |, &&, ||, min or identifier

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  3 20:16:58 2017
New Revision: 245885

URL: https://gcc.gnu.org/viewcvs?rev=245885=gcc=rev
Log:
PR c/79837
* c-parser.c (c_parser_omp_clause_reduction): Don't mention
% or % in the diagnostics, instead mention identifier.
(c_parser_omp_declare_reduction): Don't mention % in the
diagnostics.

Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c

[Bug fortran/79838] New: inconsistent trailing dot in diagnostic "The name %qs has already been used"

[roland.illig at gmx dot de]

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

Bug ID: 79838
   Summary: inconsistent trailing dot in diagnostic "The name %qs
has already been used"
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

gfc_error ("The name %qs at %C has already been used as "
   "an external module name.", use_list->module_name);

This error message, in contrast to almost every other error message, has a
trailing period. This period should be removed.

[Bug c/79836] typo in c/c-parser.c: pragma omp ordered

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Fixed together with 2 other similar issues.
Thanks for reporting these.

[Bug c/79836] typo in c/c-parser.c: pragma omp ordered

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  3 19:56:54 2017
New Revision: 245883

URL: https://gcc.gnu.org/viewcvs?rev=245883=gcc=rev
Log:
PR c/79836
* c-parser.c (c_parser_generic_selection): Use %<_Generic%>
instead of %<_Generic>.
(c_parser_omp_ordered): Use % instead of %.
(c_parser_omp_target_exit_data): Use % instead of
%.

Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-parser.c

[Bug c/79837] New: incomplete diagnostic in c-parser: expected +, *, -, &, ^, |, &&, ||, min or identifier

[roland.illig at gmx dot de]

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

Bug ID: 79837
   Summary: incomplete diagnostic in c-parser: expected +, *, -,
&, ^, |, &&, ||, min or identifier
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

c_parser_error (parser,
"expected %<+%>, %<*%>, %<-%>, %<&%>, "
"%<^%>, %<|%>, %<&&%>, %<||%>, % or identifier");

There is a ", max" missing after "min".

[Bug libfortran/78379] Processor-specific versions for matmul

[dje at gcc dot gnu.org]

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

--- Comment #28 from David Edelsohn  ---
Because PPC64LE Linux reset the base ISA level, VSX now is enabled by default,
so a function clone for VSX probably isn't necessary.  While special versions
might help AIX and PPC64BE, with lower ISA defaults, those are not the focus.

[Bug c/79836] New: typo in c/c-parser.c: pragma omp ordered

[roland.illig at gmx dot de]

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

Bug ID: 79836
   Summary: typo in c/c-parser.c: pragma omp ordered
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

error_at (loc,
"%<#pragma omp ordered%> with % clause may "
"only be used in compound statements");

It must be % (the percent is missing for the closing quote).

[Bug libfortran/78379] Processor-specific versions for matmul

[tkoenig at gcc dot gnu.org]

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

--- Comment #27 from Thomas Koenig  ---
(In reply to # David Edelsohn from comment #26)
> What is AVX-specific, as opposed to SIMD vector size-specific, about this
> feature? It seems that this should be enabled for all SIMD architectures of
> the appropriate width.

You're right, this might as well apply to other architectures where
SIMD instructions are available only on some architectures, but
cannot be turned on by default because they are not universally
implemented.

I would need three pieces of information:

- What to put into the libgfortran config file to check if
  the installed binutils support the SIMD extension in question

- How to check at runtime for the specific processor version

- Which options to pass to __attribute__((__target__ ..

Then it is relatively straightforward to put this in.

[Bug middle-end/79835] load to a variable outside the scope of a function is optimized out

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |middle-end

--- Comment #1 from Andrew Pinski  ---
You need to mark the variable as volatile as gcc thinks malloc does not change
any global visiable state.  There is a duplicate of this issue already but I
can't find it right now.

[Bug middle-end/79805] [7 Regression] ICE (verify_flow_info failed) with -fnon-call-exceptions -O

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  3 19:32:01 2017
New Revision: 245882

URL: https://gcc.gnu.org/viewcvs?rev=245882=gcc=rev
Log:
PR middle-end/79805
* internal-fn.def (ATOMIC_BIT_TEST_AND_SET, ATOMIC_BIT_TEST_AND_RESET,
ATOMIC_BIT_TEST_AND_COMPLEMENT, ATOMIC_COMPARE_EXCHANGE): Remove
ECF_NOTHROW.
* gimple-fold.c (fold_builtin_atomic_compare_exchange): Set
gimple_call_nothrow_p flag based on whether original builtin can throw.
If it can, emit following stmts on the fallthrough edge.
* tree-ssa-ccp.c (optimize_atomic_bit_test_and): Similarly, except
don't create new bb if inserting just debug stmts on the edge, try to
insert them on the fallthru bb or just reset debug stmts.

* g++.dg/opt/pr79805.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/opt/pr79805.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/internal-fn.def
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-ccp.c

[Bug c/79835] New: load to a variable outside the scope of a function is optimized out

[bugreporting at gmx dot com]

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

Bug ID: 79835
   Summary: load to a variable outside the scope of a function is
optimized out
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bugreporting at gmx dot com
  Target Milestone: ---

We use tcmalloc. Tcmalloc allows hooks that can be called during malloc. I was
using a static __thread thread-local variable to prevent re-entrance. I.e., 

in_malloc_hook = 1;
...do work that might call malloc...
in_malloc_hook = 0;

Sometimes the line setting in_malloc_hook = 1 would be optimized away.

I worked up an example that shows this problem without using tcmalloc.

First, create mymalloc.o that supplies a malloc() function from this mymalloc.c
file:

/*
 * gcc -g -O2 -Wall mymalloc.c -c -o mymalloc.o
 */

#include 
#include 

static void (*mymalloc_hook)(const void *ptr, size_t size);

void mymalloc_addhook(void (*f)(const void *ptr, size_t size)) {
mymalloc_hook = f;
}

void *malloc(size_t count) { // Will work the same way regardless of
fno-tree-dse if this is changed to mymalloc.
void *ptr = sbrk(count);
mymalloc_hook(ptr, count);
return ptr;
}

Next, link this .o into the following program, example.c:

/*
  $ gcc -g -O2 -Wall example.c mymalloc.o -o example
  $ ./example
  0x55d73b3a4000 64 0x55d73b3a4040
  0x55d73b3a4000

  $ gcc -g -O2 -fno-tree-dse -Wall example.c mymalloc.o -o example
  $ ./example
  0x55d31f3ea000 64 (nil)
  0x55d31f3ea000
*/

#include 
#include 

void mymalloc_addhook(void (*f)(const void *ptr, size_t size));
// Will work the same way regardless of fno-tree-dse if void *malloc(size_t) is
declared here.

static int in_hook = 0;

static int allocating = 0;
static void *buffer = NULL;

void *foo(void);

void hook(const void *ptr, size_t size) {
void *current;

if (in_hook) {
return;
}
in_hook = 1;
current = foo();
printf("%p %ld %p\n", ptr, size, current);
in_hook = 0;
}


void *foo(void) {
if (!buffer) {
if (allocating) {
return NULL;
}
allocating = 1; // Without -fno-tree-dse, this is optimized
out.
buffer = malloc(64);
allocating = 0;
}
return buffer;
}

int main() {
mymalloc_addhook();
printf("%p\n", foo());
return 0;
}

Then run the program. Note that the expectation is that, when we print out
current, it will always be (nil) because we guard against calling malloc more
than once.

However, this only happens with older versions of gcc (4.4.7) but not with
newer versions (4.9.2 and up). Using fno-tree-dse will get the correct
behavior.

The problem seems to be that gcc thinks that malloc is a builtin, even when it
is being provided by an external library (e.g., mymalloc.o or tcmalloc). It
therefore thinks that malloc cannot change a file-local variable, so it can
optimize out the load.

However, in this case, we have replaced malloc, and it can call back into
functions that change or test this file-local (or global? didn't test that)
variable.

If the name of the function "malloc" is changed, then (nil) is always returned
for the value of current, as expected.

The gcc command is in the comments. This works with many different versions of
gcc, from 4.9.2 and up.

$ gcc --version
gcc (Debian 6.3.0-5) 6.3.0 20170124
$ uname -a
Linux  4.9.0-1-amd64 #1 SMP Debian 4.9.2-2 (2017-01-12) x86_64 GNU/Linux

[Bug c/79834] New: c/c-parser.c: make code more i18n-friendly

[roland.illig at gmx dot de]

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

Bug ID: 79834
   Summary: c/c-parser.c: make code more i18n-friendly
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

The following code pattern occurs several times:

c_parser_error (parser, "%<#pragma acc update%> may only be "
"used in compound statements");

Each of these occurrences has to be translated individually by a translator for
each of the supported human languages. This creates unnecessary work. It would
be less work (and fewer chances of introducing typos) to have only one
template:

c_parser_error (parser, "%<#pragma %s%> may only be "
"used in compound statements",
"acc update");

The code in c/c-parser.c and cp/parser.c should therefore use the second
pattern consistently.

[Bug c++/58987] [5/6/7 Regression] ICE with template alias

[reichelt at gcc dot gnu.org]

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

Volker Reichelt  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
  Known to work||4.7.0, 4.7.2
Summary|[c++11] ICE with template   |[5/6/7 Regression] ICE with
   |alias   |template alias

--- Comment #1 from Volker Reichelt  ---
Although the default template parameter is not used here, the code is probably
ill-formed, so that we actually have a regression here.

This bug is related to PR77339.

[Bug libstdc++/77854] std::deque doesn't use allocator's size_type and difference_type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-03
 Ever confirmed|0   |1

[Bug tree-optimization/71437] [7 regression] Performance regression after r235817

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |law at redhat dot com

--- Comment #15 from Jeffrey A. Law  ---
So what looks real promising here.

1. Pull the "handle_dominating_asserts" bits out of tree-ssa-threadedge and
into tree-vrp.c.  They really should have been there all along.

2. Improve DOM's handling of BIT_AND_EXPR/BIT_IOR_EXPR to avoid a couple minor
regressions due to #1.

3. Push some common code from tree-vrp.c/tree-ssa-dom.c into
tree-ssa-threadedge.c.

4. Change the random walk order for threading in tree-vrp.c to a domwalk

5. Record data from ASSERT_EXPRs during threading domwalk

6. Query the expression hash table in simplify_stmt_for_jump_threading


It all sounds more complex than it is.  In addition to fixing bz71437, it
starts some refactoring towards addressing bz78496 and cutting down on the
amount of work we're doing for jump threading.

[Bug tree-optimization/78687] inefficient code generated for eggs.variant

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org

--- Comment #5 from Martin Jambor  ---
Mine.

[Bug fortran/79596] translation: argument to gfc_internal_error should not be translated

[roland.illig at gmx dot de]

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

--- Comment #2 from Roland Illig  ---
(In reply to Dominique d'Humieres from comment #1)
> > Internal errors should not be translated. Their only purpose is to give
> > information back to the developers, and this information should not be
> > modified by any translator.
> 
> I agree, but how do achieve that?

gcc/Makefile.in contains the po/gcc.pot target, which uses po/exgettext.

I assume that somewhere there is some list of functions that take translatable
strings, since xgettext has to decide which of these functions take
printf-style arguments and which take gcc-internal-style arguments.

The gfc_internal_error function should be removed from that list. I could not
find this list anywhere, though.

[Bug target/77687] frame access after release without redzone on powerpc

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||meissner at gcc dot gnu.org

--- Comment #5 from Segher Boessenkool  ---
*** Bug 50467 has been marked as a duplicate of this bug. ***

[Bug target/50467] Compiler can move stack cleanup before last memory reference involving the stack

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Segher Boessenkool  ---
This is a duplicate of 77687, which is fixed on trunk.

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

[Bug target/77687] frame access after release without redzone on powerpc

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-03
 Ever confirmed|0   |1

[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 CC||bernds at gcc dot gnu.org

--- Comment #8 from Bernd Schmidt  ---
I was also playing with this before I noticed Jakub was investigating. As an
experiment, I came up with the following, trying to recognize situations where
picking one alternative would cause an infinite cycle:

Index: lra-constraints.c
===
--- lra-constraints.c   (revision 245685)
+++ lra-constraints.c   (working copy)
@@ -1899,6 +1899,7 @@ process_alt_operands (int only_alternati
   int reload_nregs, reload_sum;
   bool costly_p;
   enum reg_class cl;
+  bool must_not_reload_op1 = false;

   /* Calculate some data common for all alternatives to speed up the
  function. */
@@ -1932,6 +1933,15 @@ process_alt_operands (int only_alternati
  = regno_reg_rtx[hard_regno[nop]];
 }

+  /* See if we have an insn of the form
+   (set (pseudo) (something)
+ If yes, then we should not try to reload operand 1 into a pseudo,
+ because this would cause an infinite cycle.  */
+  if (curr_insn_set != NULL_RTX
+  && operand_reg[0] != NULL_RTX
+  && hard_regno[0] < 0)
+must_not_reload_op1 = true;
+
   /* The constraints are made of several alternatives. Each operand's
  constraint looks like foo,bar,... with commas separating the
  alternatives.  The first alternatives for all operands go
@@ -2193,7 +2203,10 @@ process_alt_operands (int only_alternati
  switch (get_constraint_type (cn))
{
case CT_REGISTER:
- cl = reg_class_for_constraint (cn);
+ if (nop == 1 && must_not_reload_op1)
+   cl = NO_REGS;
+ else
+   cl = reg_class_for_constraint (cn);
  if (cl != NO_REGS)
goto reg;
  break;

Sadly, it seems to be ineffective (or at least incomplete), it goes into a
different infinite cycle.

[Bug inline-asm/79804] ICE in print_reg, at config/i386/i386.c:17637

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-03
  Component|target  |inline-asm
 Ever confirmed|0   |1

--- Comment #2 from Uroš Bizjak  ---
Minimized testcase:

--cut here--
void foo (int x)
{
  register int r20 asm ("20") = x;

  asm volatile ("# %0" : : "r" (r20));
}
--cut here--

(gdb) f 2
#2  0x00e8fcdc in print_reg (x=0x70265f18, code=0, file=0x1fd3620)
at /home/uros/gcc-svn/trunk/gcc/config/i386/i386.c:17634
17634 gcc_assert (regno != ARG_POINTER_REGNUM
(gdb) list
17629 else
17630   msize = GET_MODE_SIZE (GET_MODE (x));
17631
17632 regno = REGNO (x);
17633
17634 gcc_assert (regno != ARG_POINTER_REGNUM
17635 && regno != FRAME_POINTER_REGNUM
17636 && regno != FPSR_REG
17637 && regno != FPCR_REG);
17638
(gdb) p debug_rtx (x)
(reg/v:SI 20 frame [ r20 ])
$3 = void

While we can change the assert to an error, I really wonder how the numeric
name gets pass "invalid register name" check. Naming a register e.g "x20" gets
us:

pr79804.c: In function ‘foo’:
pr79804.c:3:16: error: invalid register name for ‘r20’
   register int r20 asm ("x20") = x;

I'll recategorize this PR to a generic inline-asm component.

[Bug target/43763] segfault when using by -mwarn-cell-microcode

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org

[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)

[vmakarov at gcc dot gnu.org]

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

--- Comment #7 from Vladimir Makarov  ---
I am working on the PR.  I hope the fix will be ready at the beginning of the
next week.

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
We are not handling the internal unit check correctly in unit.c (get_unit) and
we return a NULL to the caller which is then interpreted as an error. I am
working on the fix now. (just a little head scratching)

[Bug c++/79833] New: std::put_time has the wrong values for 2 digit years

[jllansf at lirr dot org]

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

Bug ID: 79833
   Summary: std::put_time has the wrong values for 2 digit years
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jllansf at lirr dot org
  Target Milestone: ---

When using the %y specifier on the std::put_time function the documentation
both for std::put_time and the posix strptime() read:

y:  The last two digits of the year. When format contains neither a C
conversion specifier nor a Y conversion specifier, values in the range [69,99]
shall refer to years 1969 to 1999 inclusive and values in the range [00,68]
shall refer to years 2000 to 2068 inclusive;

Running the following sample code:

int main(int argc, char * argv[]) {
std::tm t = {0};
std::istringstream ss("03/03/17 11:03:16");
ss.imbue(std::locale("en_US.UTF8"));
ss >> std::get_time(, "%m/%d/%y %H:%M:%S");

if (ss.fail()) {
std::cout << "Parse failed\n";
} else {
std::cout << std::put_time(, "%c") << '\n';
}
}

Yields:  "Sun Mar  3 11:03:16 1917"

When based on the documentation since 17, is in the [00,68] range it should
instead Result in the value "Sun Mar  3 11:03:16 2017"

[Bug target/43763] segfault when using by -mwarn-cell-microcode

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Author: segher
Date: Fri Mar  3 17:00:50 2017
New Revision: 245880

URL: https://gcc.gnu.org/viewcvs?rev=245880=gcc=rev
Log:
rs6000: Fix for -mwarn-cell-microcode (PR43763)

If using -mwarn-cell-microcode, rs6000_final_prescan_insn calls
get_insn_template to get the name of the machine instruction.  But,
get_insn_template calls the output template if that is code, and that
then can modify recog_data (it is normal to change the operands, for
example).

This patch saves and restores recog_data around the call to
get_insn_template to fix the problems this causes.


PR target/43763
* config/rs6000/rs6000.c (rs6000_final_prescan_insn): Save and
restore recog_data (including the operand rtxes inside it) around
the call to get_insn_template.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c

[Bug tree-optimization/79699] small memory leak in MPFR

[msebor at gcc dot gnu.org]

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

--- Comment #7 from Martin Sebor  ---
Author: msebor
Date: Fri Mar  3 16:35:00 2017
New Revision: 245878

URL: https://gcc.gnu.org/viewcvs?rev=245878=gcc=rev
Log:
PR tree-optimization/79699 - small memory leak in MPFR

gcc/ChangeLog:
* context.c (context::~context): Free MPFR caches to avoid
a memory leak on program exit.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/context.c

[Bug tree-optimization/79699] small memory leak in MPFR

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Fixed in r245878.

[Bug tree-optimization/79828] missing div-by-zero warning

[arnd at linaro dot org]

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

--- Comment #8 from Arnd Bergmann  ---
(In reply to Jakub Jelinek from comment #6)
> If the warning has false positives, then I'm sure the kernel will turn it
> off anyway like it does with tons of other warnings.

That is well possible. I try to catch new warnings early by building lots of
kernels with random configurations and sending kernel fixes, but if there are
more than a few dozen instances and none of them are interesting kernel bugs,
I'd also turn off that warning.

I have started going through all available warnings to see how much output they
generate (97GB on an allmodconfig kernel build when turning them all on with
gcc, more with clang), with the intention of re-enabling the more useful ones,
but will take a while to get there as I can only enable them after having fixed
all the warnings we get.

[Bug tree-optimization/79828] missing div-by-zero warning

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  ---
The thing is, if we could prove the trap is always executed, then we'd just zap
everything prior to the trap without visible side effects and everything after
the trap.  It's actually not an interesting case.

It's critical to remember that a trap introduced by the compiler is on a *path*
through the CFG and a series of conditionals has to be met for the trap to be
executed.  The compiler has already tried  to prove the path is infeasible and
failed.

In fact, that pass was originally introduced specifically because there are
cases where the compiler will never be able to prove a particular problem path
can't execute and as a result it must keep the path in the CFG, which in turn
leads to false positives from -Wuninitialized later.  By isolating the path and
introducing a trap on that path, the CFG simplifies in useful ways *and* if the
program were to erroneously get on the path, it gets halted prior to execution
of undefined behavior which is desirable from a security standpoint.

There is some code in tree-ssa-uninit.c which does predicate analysis to
further reduce the set of false positives for -Wuninitialized.  However, that
code won't solve the problems that folks are looking at here (if it did, we
wouldn't have erroneous path isolation to begin with).

[Bug target/79812] [7 Regression] ICE in simplify_binary_operation_1, at simplify-rtx.c:3586

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||uros at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Guess it would be nice to check somewhere in genrecog.c or similar that if we
have a vec_select with parallel (rather than say match_parallel) inside of it,
then it has the right number of elements.

[Bug target/79812] [7 Regression] ICE in simplify_binary_operation_1, at simplify-rtx.c:3586

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 40880
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40880=edit
gcc7-pr79812.patch

Untested fix.

[Bug target/79793] Incorrect stack alignment for interrupt handler in 64-bit

[julia.koval at intel dot com]

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

--- Comment #2 from Yulia Koval  ---
Patch posted at
https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00178.html

[Bug middle-end/68270] [MPX] Common pattern for variable sized data clashes with MPX bound checks

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-03
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
The issue is not solved, let's consider:

$ cat /tmp/chkp.ii
typedef struct a *b;
struct a {
  struct {
int e[1];
  } f;
};
int g(b ptr)
{
  return ptr->f.e[1];
}

$ ./xgcc -B. /tmp/chkp.ii -Werror -c -mmpx -fcheck-pointer-bounds -O1 -Wall
-fchkp-flexible-struct-trailing-arrays 
/tmp/chkp.ii: In function ‘int g.chkp(b,
\xe2\x80\x98pointer_bounds_typ\xe2\x80\x99 not supported by dump_type#, void, ...)’:
/tmp/chkp.ii:9:20: error: memory access check always fail [-Werror=chkp]
   return ptr->f.e[1];
^
cc1plus: all warnings being treated as errors

It's wrong and reason is explained in Richi's email:
https://gcc.gnu.org/ml/gcc-patches/2017-01/msg00172.html

I'm testing the patch.

[Bug c++/79832] [C++14/17] result of subscripting non lvalue array should be xvalue

[felix.morgner at gmail dot com]

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

--- Comment #1 from Felix Morgner  ---
adjusted the title to be more clear. sorry!

[Bug c++/79832] New: [C++14/17] result of array subscript operator should be xvlaue

[felix.morgner at gmail dot com]

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

Bug ID: 79832
   Summary: [C++14/17] result of array subscript operator should
be xvlaue
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix.morgner at gmail dot com
  Target Milestone: ---

According to ISO14882:2014 [expr.sub] (as well as the current draft) the
following should yield an xvalue on line 3 (arr{}[0]):

  int main() {
using arr = int[3];
arr{}[0];
  }

since 'arr{}' is an array prvalue. It seems that it does not in GCC since the
following code compiles just fine:

  int main() {
using arr = int[3];
{}[0];
  }

even though taking the address of an xvalue (the result of subscripting the
array prvalue) is invalid. There exists a relevant DR1213 (pre C++14) here:
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1213 which
introduced the notion that subscripting a non lvalue array yields an xvalue.

Compiled using -Wall -Wextra -pedantic with GCC 6.3.1

[Bug c++/79796] [5/6/7 Regression] ICE with NSDMI and this pointer

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Surprisingly my naïve attempt to fix this works:

--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -8047,6 +8047,8 @@ build_over_call (struct z_candidate *cand, int flags,
tsubst_flags_t complain)
{
  arg = cp_build_indirect_ref (arg, RO_NULL, complain);
  val = build2 (MODIFY_EXPR, TREE_TYPE (to), to, arg);
+ if (cxx_dialect >= cxx14)
+   replace_placeholders (arg, to);
}
   else
{


and the C++ testsuite passes.

[Bug rtl-optimization/79812] [7 Regression] ICE in simplify_binary_operation_1, at simplify-rtx.c:3586

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-03
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Looking into this.

[Bug middle-end/79831] New: [DOC][CHKP] Missing -Wchkp

[marxin at gcc dot gnu.org]

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

Bug ID: 79831
   Summary: [DOC][CHKP] Missing -Wchkp
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: ienkovich at gcc dot gnu.org
  Target Milestone: ---

We miss documentation for the option.

[Bug tree-optimization/79830] GCC generates counterproductive code surrounding very simple loops (improvement request)

[kobalicek.petr at gmail dot com]

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

--- Comment #3 from Petr  ---
Sorry for misunderstanding, I really read initially that you replaced the exit
condition in the sample code :)

[Bug tree-optimization/79830] GCC generates counterproductive code surrounding very simple loops (improvement request)

[kobalicek.petr at gmail dot com]

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

--- Comment #2 from Petr  ---
I'm not sure I follow with the exit test. I mean the code should be correct as
each point has x|y coord, which is two doubles, so length 8 means 16 doubles (I
converted from my production code into a simpler form that uses only native
types).

However, I think that the problem is also that if this code was handwritten it
would only use 3 registers (dst, src, and i), but GCC uses:

  rax|rcd|rdx|rsi|rdi|r8|r9

which is a lot and the same code in 32-bit mode contains one short spill of GP
register. Basically if I needed more GP registers inside the function the
problem would be much bigger (but no clue if GCC would use different approach
in that case).

[Bug tree-optimization/79830] GCC generates counterproductive code surrounding very simple loops (improvement request)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-03
 CC||amker at gcc dot gnu.org
  Component|c++ |tree-optimization
Version|unknown |7.0.1
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
It is induction variable optimization (-fivopts) that re-writes the main
induction variable.  We have

Original cost 17 (complexity 2)

Final cost 17 (complexity 2)

Selected IV set for loop 2 at t.C:44, 4 avg niters, 0 expressions, 1 IVs:
Candidate 5:
  Var befor: ivtmp.25_108
  Var after: ivtmp.25_107
  Incr POS: before exit test
  IV struct:
Type:   sizetype
Base:   0
Step:   32
Biv:N
Overflowness wrto loop niter:   No-overflow

Replacing exit test: if (i_32 >= 0)

but it doesn't seem to account the extra cost for the exit test replacement
when facing equal original/final cost.

[Bug c++/79830] New: GCC generates counterproductive code surrounding very simple loops (improvement request)

[kobalicek.petr at gmail dot com]

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

Bug ID: 79830
   Summary: GCC generates counterproductive code surrounding very
simple loops (improvement request)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kobalicek.petr at gmail dot com
  Target Milestone: ---

It seems that GCC tries very hard to optimize loops, but in my case it's
counterproductive. I have illustrated the problem in the following C++ code and
disassembly.

Loops that are constructed this way need only one variable (`i`) as a loop
counter and use sign flag to check whether the loop is done or not. Typically
such loop requires simple check at the beginning (`sub` and `js`) and at the
end. The purpose of such loop is to save registers and to only require minimal
code surrounding the loop.

However, it seems that GCC tries to convert such loop into something else and
requires a lot of operations to do that, resulting in bigger and slower code.
When using `-Os` GCC produces code that I would expect, however, I don't want
to optimize for size globally.

It's not a compiler bug, but I think that in this case this optimization
doesn't make any sense and only adds to the executable/library size. I doubt
this leads to any improvement and it would be nice if GCC can somehow discover
to not do this for these kind of loops.

Also, here is a compiler explorer URL, for people wanting to compare:

  https://godbolt.org/g/oeDGmy



Consider the following C++ code
---


#include 

#if defined(_MSC_VER)
# include 
#else
# include 
#endif

void transform(double* dst, const double* src, const double* matrix, size_t
length) {
  __m256d m_00_11 = _mm256_castpd128_pd256(_mm_set_pd(matrix[3], matrix[0]));
  __m256d m_10_01 = _mm256_castpd128_pd256(_mm_set_pd(matrix[1], matrix[2]));
  __m256d m_20_21 = _mm256_broadcast_pd(reinterpret_cast(matrix
+ 4));

  m_00_11 = _mm256_permute2f128_pd(m_00_11, m_00_11, 0);
  m_10_01 = _mm256_permute2f128_pd(m_10_01, m_10_01, 0);

  intptr_t i = static_cast(length);
  while ((i -= 8) >= 0) {
__m256d s0 = _mm256_loadu_pd(src +  0);
__m256d s1 = _mm256_loadu_pd(src +  4);
__m256d s2 = _mm256_loadu_pd(src +  8);
__m256d s3 = _mm256_loadu_pd(src + 12);

__m256d a0 = _mm256_add_pd(_mm256_mul_pd(s0, m_00_11), m_20_21);
__m256d a1 = _mm256_add_pd(_mm256_mul_pd(s1, m_00_11), m_20_21);
__m256d a2 = _mm256_add_pd(_mm256_mul_pd(s2, m_00_11), m_20_21);
__m256d a3 = _mm256_add_pd(_mm256_mul_pd(s3, m_00_11), m_20_21);

__m256d b0 = _mm256_mul_pd(_mm256_shuffle_pd(s0, s0, 0x1), m_10_01);
__m256d b1 = _mm256_mul_pd(_mm256_shuffle_pd(s1, s1, 0x1), m_10_01);
__m256d b2 = _mm256_mul_pd(_mm256_shuffle_pd(s2, s2, 0x1), m_10_01);
__m256d b3 = _mm256_mul_pd(_mm256_shuffle_pd(s3, s3, 0x1), m_10_01);

_mm256_storeu_pd(dst +  0, _mm256_add_pd(a0, b0));
_mm256_storeu_pd(dst +  4, _mm256_add_pd(a1, b1));
_mm256_storeu_pd(dst +  8, _mm256_add_pd(a2, b2));
_mm256_storeu_pd(dst + 12, _mm256_add_pd(a3, b3));

dst += 16;
src += 16;
  }
  i += 8;

  while ((i -= 2) >= 0) {
__m256d s0 = _mm256_loadu_pd(src);

__m256d a0 = _mm256_add_pd(_mm256_mul_pd(s0, m_00_11), m_20_21);
__m256d b0 = _mm256_mul_pd(_mm256_shuffle_pd(s0, s0, 0x1), m_10_01);

_mm256_storeu_pd(dst, _mm256_add_pd(a0, b0));

dst += 4;
src += 4;
  }

  if (i & 1) {
__m128d s0 = _mm_loadu_pd(src +  0);

__m128d a0 = _mm_add_pd(_mm_mul_pd(s0, _mm256_castpd256_pd128(m_00_11)),
_mm256_castpd256_pd128(m_20_21));
__m128d b0 = _mm_mul_pd(_mm_shuffle_pd(s0, s0, 0x1),
_mm256_castpd256_pd128(m_10_01));

_mm_storeu_pd(dst +  0, _mm_add_pd(a0, b0));
  }
}



Which is compiled to the following
--

(-O2 -mavx -fno-exceptions -fno-tree-vectorize)

See comments describing what I din't like..

transform(double*, double const*, double const*, unsigned long):
vmovsd  xmm4, QWORD PTR [rdx]
mov r9, rcx
vmovsd  xmm5, QWORD PTR [rdx+16]
sub r9, 8
vmovhpd xmm4, xmm4, QWORD PTR [rdx+24]
vbroadcastf128  ymm6, XMMWORD PTR [rdx+32]
mov r8, rcx
vmovhpd xmm5, xmm5, QWORD PTR [rdx+8]
vperm2f128  ymm4, ymm4, ymm4, 0
vperm2f128  ymm5, ymm5, ymm5, 0
js  .L6

;; <--- Weird
mov rax, r9
sub rcx, 16
mov r8, r9
and rax, -8
mov rdx, rsi
sub rcx, rax
mov rax, rdi
;; <--- Weird
.L5:
vmovupd xmm3, XMMWORD PTR [rdx]
sub r8, 8
sub rax, -128
sub rdx, -128
vinsertf128 ymm3, ymm3, XMMWORD PTR [rdx-112], 0x1
vmovupd xmm2, XMMWORD PTR [rdx-96]
 

[Bug bootstrap/79829] New: Assumes host CC and CXX behave the same

[rguenth at gcc dot gnu.org]

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

Bug ID: 79829
   Summary: Assumes host CC and CXX behave the same
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

When (due to a glitch) having host gcc 4.8 but host g++ 4.3 I run into

[  121s] g++ -std=gnu++98  -I../../../libcpp -I. -I../../../libcpp/../include
-I
../../../libcpp/include  -fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2
-funwind-tab
les -fasynchronous-unwind-tables -g -U_FORTIFY_SOURCE -W -Wall -Wno-narrowing
-W
write-strings -Wmissing-format-attribute -pedantic -Wno-long-long 
-fno-exceptio
ns -fno-rtti -I../../../libcpp -I. -I../../../libcpp/../include
-I../../../libcp
p/include   -DPACKAGE_SUFFIX=\"-7\" -c -o charset.o -MT charset.o -MMD -MP -MF
.
deps/charset.Tpo ../../../libcpp/charset.c
[  121s] cc1plus: error: unrecognized command line option "-Wno-narrowing"

because libcpp uses the host _C_ compiler for its ACX_PROG_CC_WARNING_OPTS
checks while later using the host _C++_ compiler for doing the actual
compilation.

It looks like it is ACX_PROG_CC_WARNING_OPTS itself which forces the use of C
here.

Not sure if worth fixing.

[Bug c++/79827] genautomata segmentation fault on NI-RT Linux

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
You can look at imposed limits with

> ulimit -a

and for example raise stack limit with

> ulimit -s unlimited

[Bug c++/79827] genautomata segmentation fault on NI-RT Linux

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||build
 Target||x86_64-linux
   Host||x86_64-linux
  Build||x86_64-linux

--- Comment #6 from Richard Biener  ---
So I assume this is x86_64-linux.

Can you try without --with-boot-ldflags=" -static -static-libgcc " as that is
pretty non-standard?  Did you make sure to set LD_LIBRARY_PATH in a way that
picks up the runtime libraries for the compiler you built on Ubuntu (and are
using to build gcc on NI RT Linux)?

Doing

> ldd gcc/build/genautomata

should tell you if there are any odd pickups.

You can debug genautomata with

> cd gcc
> gdb --args build/genautomata /Flash/gcc/build/gcc-6.3.0/gcc/common.md 
> /Flash/gcc/build/gcc-6.3.0/gcc/config/i386/i386.md insn-conditions.md
(gdb) run

(gdb) bt

which should give you a backtrace.  Of course you need gdb (can use the NI
one).

[Bug target/79807] [5/6 Regression] ICE in extract_insn, at recog.c:2311 (error: unrecognizable insn)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
Summary|[5/6/7 Regression] ICE in   |[5/6 Regression] ICE in
   |extract_insn, at|extract_insn, at
   |recog.c:2311 (error:|recog.c:2311 (error:
   |unrecognizable insn)|unrecognizable insn)

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

[Bug target/79807] [5/6/7 Regression] ICE in extract_insn, at recog.c:2311 (error: unrecognizable insn)

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Fri Mar  3 12:24:53 2017
New Revision: 245871

URL: https://gcc.gnu.org/viewcvs?rev=245871=gcc=rev
Log:
PR target/79807
* config/i386/i386.c (ix86_expand_multi_arg_builtin): If target
is a memory operand, increase num_memory.
(ix86_expand_args_builtin): Likewise.

* gcc.target/i386/pr79807.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr79807.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
There is
https://github.com/madler/zlib/commit/b4ce6caf0992296230e4e25b22a63e418bdf4dcf
but not enough further info why it has changed.  So, report upstream?

[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
If this comes from upstream, then most likely upstream zlib doesn't build on
cygwin64 either.  So either you have too old cygwin and newer one supports it,
or it would be nice to figure out why this changed upstream.

[Bug c++/79782] [7 Regression] ICE: tree check: expected tree_list, have void_type in emit_mem_initializers, at cp/init.c:1225

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/46854] PowerPC optimization regression

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||segher at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #5 from Segher Boessenkool  ---
Current trunk does (with -O2)

test:
mr. 10,3
lis 3,.LANCHOR0@ha
la 3,.LANCHOR0@l(3)
beqlr 0
.p2align 5,,31
.L3:
lbzu 9,1(3)
cmpwi 7,9,0
bne 7,.L3
addic. 10,10,-1
bne 0,.L3
blr

and with -Os

test:
lis 9,.LANCHOR0@ha
la 9,.LANCHOR0@l(9)
.L2:
cmpwi 7,3,0
bne 7,.L3
mr 3,9
blr
.L3:
lbzu 10,1(9)
cmpwi 7,10,0
bne 7,.L3
addi 3,3,-1
b .L2

Both are reasonable, with no obvious inefficiency; I'm closing this
bug as fixed.

(Note that since a few years we generate bdnz only in inner loops).

[Bug rtl-optimization/79780] [7 Regression] ICE in rtl_verify_bb_insns, at cfgrtl.c:2661 (error: flow control insn inside a basic block)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug lto/79760] ICE in type_in_anonymous_namespace_p in ipa-utils.h:219

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-03
  Known to work||7.0
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.3.0

--- Comment #5 from Martin Liška  ---
Fixed on trunk so far.