[Bug tree-optimization/23384] escaped set should be flow sensitive

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81776

--- Comment #10 from Martin Sebor  ---
As a data point, Clang manages to optimize at least the simple case in bug
81788 as expected.  No other compiler I've tested does (IBM XLC, Intel ICC,
Visual Studio, or Sun/Oracle Studio).

[Bug tree-optimization/81776] missing sprintf optimization due to pointer escape analysis

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=23384

--- Comment #1 from Martin Sebor  ---
See also bug 23384 for a related limitation.

[Bug tree-optimization/23384] escaped set should be flow sensitive

[msebor at gcc dot gnu.org]

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

--- Comment #9 from Martin Sebor  ---
As a data point, Clang manages to optimize at least the simple case in bug
81788 as expected.  No other compiler I've tested does (IBM XLC, Intel ICC,
Visual Studio, or Sun/Oracle Studio).

[Bug tree-optimization/81788] address of a local variable escapes too early

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Dupe of bug 23384 sounds right.  The aliasing pass is documented as flow
insensitive so I suspected this was a known limitation.  Thanks for confirming
that.

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

[Bug tree-optimization/23384] escaped set should be flow sensitive

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #8 from Martin Sebor  ---
*** Bug 81788 has been marked as a duplicate of this bug. ***

[Bug testsuite/81784] [8 regression] gcc.dg/compare2.c fails starting with r250984

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

--- Comment #1 from Andrew Pinski  ---
Confirmed on aarch64-linux-gnu.

[Bug c++/81789] New: CWG1687 performed too soon

[barry.revzin at gmail dot com]

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

Bug ID: 81789
   Summary: CWG1687 performed too soon
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Consider this reduced example taken from StackOverflow
(https://stackoverflow.com/questions/45602368/correct-behavior-of-built-in-operator-candidates-of-the-overload-resolution-in-t):

struct X { X(int*); };
struct Y { operator double(); };
int operator+(X, int);

int main() {
  int{(int*)0 + Y()};
}

gcc compiles it fine. But the built-in operator, operator+(int*, std::ptrdiff_t
) should be a better match and selected by overload resolution and THEN, as a
result of CWG 1687, the expression should be considered ill-formed. However, it
appears that gcc pre-rejects that overload first and instead picks the provided
operator+(). 

clang does the opposite, preferring the builtin operator and then not rejecting
it, so this program fails to compile, but for the wrong reason (due to not
being able to convert int* to int).

[Bug c/81687] Compiler drops label in OpenMP region

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Thu Aug 10 00:33:20 2017
New Revision: 251019

URL: https://gcc.gnu.org/viewcvs?rev=251019=gcc=rev
Log:
PR c/81687
* omp-low.c (omp_copy_decl): Don't remap FORCED_LABEL or DECL_NONLOCAL
LABEL_DECLs.
* tree-cfg.c (move_stmt_op): Don't adjust DECL_CONTEXT of FORCED_LABEL
or DECL_NONLOCAL labels.
(move_stmt_r) : Adjust DECL_CONTEXT of FORCED_LABEL
or DECL_NONLOCAL labels here.

* testsuite/libgomp.c/pr81687-1.c: New test.
* testsuite/libgomp.c/pr81687-2.c: New test.

Added:
trunk/libgomp/testsuite/libgomp.c/pr81687-1.c
trunk/libgomp/testsuite/libgomp.c/pr81687-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c
trunk/gcc/tree-cfg.c
trunk/libgomp/ChangeLog

[Bug tree-optimization/81788] address of a local variable escapes too early

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 23384 I think.

[Bug tree-optimization/81788] New: address of a local variable escapes too early

[msebor at gcc dot gnu.org]

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

Bug ID: 81788
   Summary: address of a local variable escapes too early
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This is similar to bug 81776.

It seems that the alias analysis considers the address of a local variable to
escape if a call to an unknown function is made after the latter variable has
been declared, that takes the address of another local variable even if the
variable isn't used until after the call.

Clang emits optimal code for both functions below (though other compilers
suffer  the same limitation).

$ cat x.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout x.c
void f (void*);

void g0 (void)
{
  int a = 123;

  f ();

  int b = 456;

  if (b != 456)   // can never be true
__builtin_abort ();   // eliminated

  f ();
}

void g1 (void)
{
  int a = 123;
  int b = 456;

  f ();

  if (b != 456)   // can never be true
__builtin_abort ();   // not eliminated

  f ();
}

;; Function g0 (g0, funcdef_no=0, decl_uid=1817, cgraph_uid=0, symbol_order=0)

g0 ()
{
  int b;
  int a;

   [100.00%] [count: INV]:
  a = 123;
  f ();
  b = 456;
  f ();
  a ={v} {CLOBBER};
  b ={v} {CLOBBER};
  return;

}



;; Function g1 (g1, funcdef_no=1, decl_uid=1822, cgraph_uid=1, symbol_order=1)

g1 ()
{
  int b;
  int a;
  int b.1_1;

   [100.00%] [count: INV]:
  a = 123;
  b = 456;
  f ();
  b.1_1 = b;
  if (b.1_1 != 456)
goto ; [0.04%] [count: 0]
  else
goto ; [99.96%] [count: INV]

   [0.04%] [count: 0]:
  __builtin_abort ();

   [99.96%] [count: INV]:
  f ();
  a ={v} {CLOBBER};
  b ={v} {CLOBBER};
  return;

}

[Bug libstdc++/81751] [5/6/7/8 Regression]__basic_file::sync() may flush _all_ files

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||3.4.2
Summary|__basic_file::sync() may|[5/6/7/8
   |flush _all_ files   |Regression]__basic_file::sy
   ||nc() may flush _all_ files
  Known to fail||3.4.4, 5.4.0, 6.3.0, 7.1.0

--- Comment #8 from Jonathan Wakely  ---
Fixed on trunk so far.

[Bug target/81643] FAIL: gcc.target/aarch64/long_branch_1.c scan-assembler Ltb

[sje at gcc dot gnu.org]

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

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #6 from Steve Ellcey  ---
This is caused by adding the predict statement in finish_goto_label
(c/c-typeck.c).  I tried to modify the test case to generate an Ltb label again
but could not do it.

I put an abort in aarch64_gen_far_branch for anytime an Ltb label was generated
but after doing a bootstrap and a full testsuite run never hit the abort.

I tried writing a new testsuite from scratch but again, could not generate an
Ltb label.

I am thinking that maybe we should just remove the Ltb check from the test
case.

[Bug rtl-optimization/81423] [6/7/8 Regression] Wrong code at -O2

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #11 from Segher Boessenkool  ---
Fixed on trunk.

[Bug target/80938] [7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
Fixed on trunk for rs6000; backports pending.

[Bug target/79391] sh ICE in in eligible_for_delay, at config/sh/sh.md:564

[joel at gcc dot gnu.org]

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

--- Comment #2 from Joel Sherrill  ---
It builds on the gcc head and the 7 branch now. 

Should we just go ahead and close this or does it matter when it was fixed?

[Bug rtl-optimization/81423] [6/7/8 Regression] Wrong code at -O2

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
Author: segher
Date: Wed Aug  9 21:52:30 2017
New Revision: 251011

URL: https://gcc.gnu.org/viewcvs?rev=251011=gcc=rev
Log:
This time with the file added.

Testcase for PR81423

gcc/testsuite/
PR rtl-optimization/81423
* gcc.c-torture/execute/pr81423.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.c-torture/execute/pr81423.c

[Bug c++/81787] New: `#pragma GCC diagnostic warning "-fpermissive"` no longer works since gcc 4.8

[b.r.longbons at gmail dot com]

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

Bug ID: 81787
   Summary: `#pragma GCC diagnostic warning "-fpermissive"` no
longer works since gcc 4.8
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com
  Target Milestone: ---

This worked with 4.7, but fails with 4.8 through 7.1.


Original reports on StackOverflow:

https://stackoverflow.com/questions/10932479/in-gcc-how-to-mute-the-fpermissive-warning

https://stackoverflow.com/questions/45600368/how-to-supress-a-fpermissive-error-using-modern-gcc

[Bug target/80938] [7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330

[segher at gcc dot gnu.org]

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

--- Comment #4 from Segher Boessenkool  ---
Author: segher
Date: Wed Aug  9 21:08:33 2017
New Revision: 251005

URL: https://gcc.gnu.org/viewcvs?rev=251005=gcc=rev
Log:
rs6000: Use SAVE_MULTIPLE only if we restore what it saves (PR80938)

We can have SAVE_MULTIPLE while we do not have REST_MULTIPLE.  If the
inline restore does not restore all registers, the CFI for the save
and restore can conflict if things are shrink-wrapped.

We could restore all registers that are saved (not ideal), or emit
the CFI notes to say we did (which will work fine, but is also not
so great); instead, let's not save the registers that are unused.


PR target/80938
* config/rs6000/rs6000.c (rs6000_savres_strategy): Don't use
SAVE_MULTIPLE if not all the registers that saves, should be saved.

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

[Bug rtl-optimization/81423] [6/7/8 Regression] Wrong code at -O2

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
Author: segher
Date: Wed Aug  9 21:05:45 2017
New Revision: 251004

URL: https://gcc.gnu.org/viewcvs?rev=251004=gcc=rev
Log:
Testcase for PR81423

gcc/testsuite/
PR rtl-optimization/81423
* gcc.c-torture/execute/pr81423.c: New testcase.

Modified:
trunk/gcc/testsuite/ChangeLog

[Bug ipa/81360] [8 Regression] ice in estimate_edge_growth, at ipa-inline.h:86

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
(In reply to Martin Liška from comment #2)
> Confirmed, started with r250048.

Still going wrong, nearly a month later.

Revision 250983 seems to demonstrate the problem.

[Bug c++/81525] [7/8 Regression] Invalid codegen with constexpr variable template

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
(In reply to Jason Merrill from comment #4)
> Modified:
> branches/gcc-7-branch/gcc/cp/ChangeLog
> branches/gcc-7-branch/gcc/cp/pt.c

Reverted for now, as 7.2 is frozen.

[Bug tree-optimization/81786] New: local restricted pointer can be relied on in alias analysis

[msebor at gcc dot gnu.org]

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

Bug ID: 81786
   Summary: local restricted pointer can be relied on in alias
analysis
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

I've been looking for opportunities to improve code generation by relying on
explicit guarantees about aliasing properties that commonly hold but that GCC
cannot otherwise rely on due to the lack of contextual information.  For
instance, it's common for a function that takes a non-const pointer argument
(say Q) to modify the object it points to (say X), then call some other
function (say FOO), and then read X's value again via *Q.  Unless GCC knows the
semantics of FOO it must assume that every call to it changes the value of X,
even though it's quite rare in practice for that to happen.  It would be nice
to be able to express this guarantee to GCC to let it generate more efficient
code.

As it turns out, according to the C aliasing rules, locally declaring a
restrict-qualified pointer P as a copy of an unknown pointer Q (such as a
function argument) can be used to express the guarantee that the object X the
pointers point to isn't modified during P's lifetime.  (This is 6.7.3.1, p4.) 
So with this simple notation, GCC could rely on this guarantee to optimize the
program below as indicated in the comments.  Note that neither functions need
to make use of the restrict qualifier in its interface.  This is helpful
because relatively few functions do.

$ cat x.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout x.c
void foo (void);

void bar (int *q)
{ 
  int* restrict p = q;
  *p = 123; 

  foo (); // must not modify *P

  if (*p != 123)  // cannot be true
__builtin_abort ();   // can be eliminated
}

int x;

void baz (void)
{
  x = 789;
  bar ();
}

;; Function bar (bar, funcdef_no=0, decl_uid=1817, cgraph_uid=0,
symbol_order=0)

bar (int * q)
{
  int _1;

   [100.00%] [count: INV]:
  *q_2(D) = 123;
  foo ();
  _1 = *q_2(D);
  if (_1 != 123)
goto ; [0.04%] [count: 0]
  else
goto ; [99.96%] [count: INV]

   [0.04%] [count: 0]:
  __builtin_abort ();

   [99.96%] [count: INV]:
  return;

}



;; Function baz (baz, funcdef_no=1, decl_uid=1822, cgraph_uid=1,
symbol_order=2)

baz ()
{
  int _2;

   [100.00%] [count: INV]:
  x = 123;
  foo ();
  _2 = x;
  if (_2 != 123)
goto ; [0.04%] [count: 0]
  else
goto ; [99.96%] [count: INV]

   [0.04%] [count: 0]:
  __builtin_abort ();

   [99.96%] [count: INV]:
  return;

}

[Bug c++/81525] [7/8 Regression] Invalid codegen with constexpr variable template

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed Aug  9 20:17:55 2017
New Revision: 251001

URL: https://gcc.gnu.org/viewcvs?rev=251001=gcc=rev
Log:
PR c++/81525 - wrong constant value with generic lambda

* pt.c (tsubst_decl) [VAR_DECL]: Avoid clobbering auto.
(tsubst_copy) [VAR_DECL]: Handle auto.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const4.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/pt.c

[Bug c++/67054] Constructor inheritance with non-default constructible members

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Wed Aug  9 20:17:47 2017
New Revision: 251000

URL: https://gcc.gnu.org/viewcvs?rev=251000=gcc=rev
Log:
PR c++/67054 - Inherited ctor with non-default-constructible members

* method.c (walk_field_subobs) Consider member initializers (NSDMIs)
when deducing an inheriting constructor.

Added:
branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/inh-ctor29.C
Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/method.c

[Bug c++/81398] Complaining about 'partial specialization of '...' after instantiation' in c++1z

[rs2740 at gmail dot com]

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

TC  changed:

   What|Removed |Added

 CC||rs2740 at gmail dot com

--- Comment #1 from TC  ---
This is the result of DR 150/P0522R0.

[Bug target/78603] internal compiler error: in dwarf2out_var_location, at dwarf2out.c:21846

[jcmvbkbc at gcc dot gnu.org]

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

--- Comment #7 from jcmvbkbc at gcc dot gnu.org ---
*** Bug 67586 has been marked as a duplicate of this bug. ***

[Bug target/67586] xtensa: ICE with -Os -g -fno-builtin-malloc in dwarf2out_var_location, at dwarf2out.c:22380

[jcmvbkbc at gcc dot gnu.org]

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

jcmvbkbc at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from jcmvbkbc at gcc dot gnu.org ---


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

[Bug target/78860] ICE in compilation for MIPS with -mpaired-single

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-09
 CC||clm at codesourcery dot com,
   ||echristo at gmail dot com,
   ||marxin at gcc dot gnu.org,
   ||matthew.fortune at imgtec dot 
com
 Ever confirmed|0   |1

--- Comment #4 from Martin Liška  ---
Adding port maintainers.

[Bug target/64546] m32c ICE at calls.c:3638 compiling newlib

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Confirmed, started in between 4.9 and 5.

[Bug c++/81525] [7/8 Regression] Invalid codegen with constexpr variable template

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed Aug  9 19:21:49 2017
New Revision: 250999

URL: https://gcc.gnu.org/viewcvs?rev=250999=gcc=rev
Log:
PR c++/81525 - wrong constant value with generic lambda

* pt.c (tsubst_decl) [VAR_DECL]: Avoid clobbering auto.
(tsubst_copy) [VAR_DECL]: Handle auto.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-const4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug target/67586] xtensa: ICE with -Os -g -fno-builtin-malloc in dwarf2out_var_location, at dwarf2out.c:22380

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-09
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can't reproduce with cross-compiler, is it reproducible on x86_64-linux-gnu?

[Bug target/67638] [SH] ICE with nosave_low_regs ISR and -mfmovd

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-09
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can't reproduce with cross compiler on trunk and gcc-5 branch. Is it
reproducible with cross compiler? Which options do you use?

[Bug target/67643] [SH] ICE with ISR and -mfmovd

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-09
 CC||aoliva at gcc dot gnu.org,
   ||kkojima at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org,
   ||olegendo at gcc dot gnu.org
  Known to work||4.9.0
 Ever confirmed|0   |1
  Known to fail||5.4.0

--- Comment #1 from Martin Liška  ---
Confirmed, 4.9 looks fine, while 5 is affected by the ICE. Adding port
maintainers.

[Bug target/68834] ICE: in decompose_normal_address, at rtlanal.c:6086 with -O2 -fPIC --param=sched-autopref-queue-depth=1

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-09
 CC||marxin at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
  Known to work||7.1.0, 8.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, it's connected to haifa scheduler. Fixed on trunk in r239105 as we
switched to LRA. It's probably broken since the problematic param was
introduced.

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[hjl.tools at gmail dot com]

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

--- Comment #13 from H.J. Lu  ---
(In reply to Mike Lothian from comment #12)
> Created attachment 41960 [details]
> si_shader objdumps

We need a small testcase in C.

[Bug libgomp/68033] OpenMP: ICE with teams distribute

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #2 from Martin Jambor  ---
Below is a slightly more reduced testcase, crashes with gcc -S -fopenmp.

From what I have gathered so far, we would like to issue an error from
the gimplifier about a non sharing of an artificial temporary variable
that has not DECL_NAME and thus segfault.


void lud_omp(float *a, int size)
{
 int i,j,k;
 float sum;
 for (i=0; i 

[Bug c/81785] New: Segmentation fault for signed overflow in index expression when -fwrapv is enabled

[willwalker26 at gmail dot com]

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

Bug ID: 81785
   Summary: Segmentation fault for signed overflow in index
expression when -fwrapv is enabled
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: willwalker26 at gmail dot com
  Target Milestone: ---

Created attachment 41961
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41961=edit
reproduction preprocessed file

gcc version 4.9.2 (Debian 4.9.2-10)
Target: x86_64-linux-gnu
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O0' '-fwrapv' '-mtune=generic'
'-march=x86-64'

Compiling the c file (see the attached preprocessed file):

% gcc -O0 -fwrapv repro.c

Execution results in:

% ./a.out
Segmentation fault

I also tried with varied levels of optimization to the same results. It looks
like 4.7.x and earlier versions of gcc work as expected.

The offending code segment is:

 unsigned int k;
 unsigned int i;
 i = 0U;
 k = 2147483648U;
 while (k < 2147483658U) {
  y[i] = x[(int)k - (int)2147483611];
  k++;
  i++;
 }

What I was hoping to happen, is to have (int)k wrap to some large negative
value and the following signed subtraction wrap to a small positive value in
the range [37,46]. Note the arrays for x and y are length 100.

I am aware that signed overflow is not defined in C, but was hoping that using
the -fwrapv compiler option would let this through.

Note, hoisting out the index expression results in the expected execution,
e.g.:

tmp = (int)k - (int)2147483611;
y[i] = x[tmp];

[Bug libstdc++/81359] [7 Regression] bogus error: constructor required before non-static data member for ‘Foo::Bar::test’ has been parsed

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
  Component|c++ |libstdc++
   Assignee|jason at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org
Summary|[7/8 Regression] bogus  |[7 Regression] bogus error:
   |error: constructor required |constructor required before
   |before non-static data  |non-static data member for
   |member for ‘Foo::Bar::test’ |‘Foo::Bar::test’ has been
   |has been parsed |parsed

--- Comment #4 from Jason Merrill  ---
I've adjusted the compiler to accept this on trunk, but the change is too
invasive for the GCC 7 branch.  I'm changing the component to libstdc++ so that
library folks can consider a library approach for the branch.

[Bug c++/81359] [7/8 Regression] bogus error: constructor required before non-static data member for ‘Foo::Bar::test’ has been parsed

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Wed Aug  9 18:32:02 2017
New Revision: 250994

URL: https://gcc.gnu.org/viewcvs?rev=250994=gcc=rev
Log:
PR c++/81359 - Unparsed NSDMI error from SFINAE context.

* init.c (get_nsdmi): Add complain parm.
* typeck2.c (digest_nsdmi_init): Add complain parm.
(process_init_constructor_record): Pass complain to get_nsdmi.
* pt.c (maybe_instantiate_noexcept): Add complain parm, return bool.
* method.c (get_defaulted_eh_spec): Add complain parm.  Pass it into
synthesized_method_walk.
(synthesized_method_walk): Adjust.
(walk_field_subobs): Pass complain to get_nsdmi.
(defaulted_late_check): Skip other checks if deleted.
* decl2.c (mark_used): Pass complain to maybe_instantiate_noexcept.
* call.c (build_aggr_conv): Pass complain to get_nsdmi.
* parser.c (defarg_location): New.
* error.c (location_of): Use it.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/sfinae59.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c
trunk/gcc/cp/class.c
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/decl2.c
trunk/gcc/cp/error.c
trunk/gcc/cp/init.c
trunk/gcc/cp/method.c
trunk/gcc/cp/parser.c
trunk/gcc/cp/pt.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-defer6.C
trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi-template14.C
trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi10.C

[Bug target/67694] ICE on returning undefined enum in must_pass_in_stack_var_size_or_pad

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed for GCC 6 and 7.

[Bug libstdc++/79820] std::ifstream sets errno to zero

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |8.0

--- Comment #9 from Jonathan Wakely  ---
Fixed for GCC 8.

[Bug debug/80938] [7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #3 from Segher Boessenkool  ---
I have a patch (for rs6000).

[Bug libstdc++/81751] __basic_file::sync() may flush _all_ files

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Wed Aug  9 17:52:10 2017
New Revision: 250993

URL: https://gcc.gnu.org/viewcvs?rev=250993=gcc=rev
Log:
PR libstdc++/81751 don't call fflush(NULL)

PR libstdc++/79820
PR libstdc++/81751
* config/io/basic_file_stdio.cc (sys_open(FILE*, ios_base::openmode)):
Call fflush on the stream instead of calling sync() while _M_cfile is
null. Restore original value of errno.
* testsuite/ext/stdio_filebuf/char/79820.cc: New.
* testsuite/ext/stdio_filebuf/char/81751.cc: New.

Added:
trunk/libstdc++-v3/testsuite/ext/stdio_filebuf/char/79820.cc
trunk/libstdc++-v3/testsuite/ext/stdio_filebuf/char/81751.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/io/basic_file_stdio.cc

[Bug libstdc++/79820] std::ifstream sets errno to zero

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Wed Aug  9 17:52:10 2017
New Revision: 250993

URL: https://gcc.gnu.org/viewcvs?rev=250993=gcc=rev
Log:
PR libstdc++/81751 don't call fflush(NULL)

PR libstdc++/79820
PR libstdc++/81751
* config/io/basic_file_stdio.cc (sys_open(FILE*, ios_base::openmode)):
Call fflush on the stream instead of calling sync() while _M_cfile is
null. Restore original value of errno.
* testsuite/ext/stdio_filebuf/char/79820.cc: New.
* testsuite/ext/stdio_filebuf/char/81751.cc: New.

Added:
trunk/libstdc++-v3/testsuite/ext/stdio_filebuf/char/79820.cc
trunk/libstdc++-v3/testsuite/ext/stdio_filebuf/char/81751.cc
Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/config/io/basic_file_stdio.cc

[Bug target/80618] [8 regression] test case gcc.dg/pr50310-2.c fails with ICE starting with 247544

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška  ---
*** Bug 80503 has been marked as a duplicate of this bug. ***

[Bug target/80503] ICE in extract_insn, at recog.c:2311 on ppc64le-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Martin Liška  ---
Confirmed, it's dup.

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

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[mike at fireburn dot co.uk]

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

--- Comment #12 from Mike Lothian  ---
Created attachment 41960
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41960=edit
si_shader objdumps

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[mike at fireburn dot co.uk]

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

--- Comment #11 from Mike Lothian  ---
So a lot of the segfaults I see are in si_shader so I thought I'd compile Mesa
with and without BMI and compare the onjdumps of the two .o files

CFLAGS="-O2 -march=native -pipe -mno-bmi -m32" CXXFLAGS="-O2 -march=native
-pipe -mno-bmi -m32" LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed
-fuse-ld=bfd -m32" ./autogen.sh --prefix=/usr --build=i686-pc-linux-gnu
--host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info
--datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib
--disable-dependency-tracking --disable-silent-rules
--docdir=/usr/share/doc/mesa- --htmldir=/usr/share/doc/mesa-/html
--libdir=/usr/lib32 --enable-dri --enable-glx --enable-shared-glapi
--enable-texture-float --enable-nine --disable-debug --enable-dri3 --enable-egl
--enable-gbm --enable-gles1 --enable-gles2 --enable-glx-tls --disable-libunwind
--enable-valgrind=no --enable-llvm-shared-libs --with-dri-drivers=,swrast,i965
--with-gallium-drivers=,swrast,radeonsi --with-vulkan-drivers=,intel,radeon
PYTHON2=/usr/bin/python2.7 --with-platforms=x11,surfaceless,wayland,drm
--enable-nine --enable-llvm --enable-omx --enable-va --enable-vdpau
--disable-xa --disable-xvmc --with-va-libdir=/usr/lib32/va/drivers
--disable-glx-read-only-text --disable-gallium-osmesa


CFLAGS="-O2 -march=native -pipe -m32" CXXFLAGS="-O2 -march=native -pipe -m32"
LDFLAGS="-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed -fuse-ld=bfd -m32"
./autogen.sh --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu
--mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share
--sysconfdir=/etc --localstatedir=/var/lib --disable-dependency-tracking
--disable-silent-rules --docdir=/usr/share/doc/mesa-
--htmldir=/usr/share/doc/mesa-/html --libdir=/usr/lib32 --enable-dri
--enable-glx --enable-shared-glapi --enable-texture-float --enable-nine
--disable-debug --enable-dri3 --enable-egl --enable-gbm --enable-gles1
--enable-gles2 --enable-glx-tls --disable-libunwind --enable-valgrind=no
--enable-llvm-shared-libs --with-dri-drivers=,swrast,i965
--with-gallium-drivers=,swrast,radeonsi --with-vulkan-drivers=,intel,radeon
PYTHON2=/usr/bin/python2.7 --with-platforms=x11,surfaceless,wayland,drm
--enable-nine --enable-llvm --enable-omx --enable-va --enable-vdpau
--disable-xa --disable-xvmc --with-va-libdir=/usr/lib32/va/drivers
--disable-glx-read-only-text --disable-gallium-osmesa

Were my configure options, and LLVM was compiled with -mno-bmi 

I'm attaching the dumps

[Bug testsuite/81784] [8 regression] gcc.dg/compare2.c fails starting with r250984

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-08-09
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/81753] Building of cross-compiler for powerpc-darwin7 is broken

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

--- Comment #6 from Segher Boessenkool  ---
(In reply to Martin Liška from comment #4)
> I can confirm it works ;) Should I send the patch and install it?

Please send the patch for review.

[Bug middle-end/80295] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

[sch...@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab  ---
No, it doesn't.  It only made it possible to call the builtin from the
frontend.

[Bug libstdc++/81751] __basic_file::sync() may flush _all_ files

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Or just call fflush(__file) directly:

https://gcc.gnu.org/ml/gcc-patches/2017-08/msg00673.html

[Bug libgomp/81778] libgomp.c/for-5.c failure on nvptx -- illegal memory access

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

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

--- Comment #4 from Alexander Monakov  ---
I agree that simd loop in the presented testcase is mishandled, but fwiw the
original for-5.c testcase should not exhibit this issue with loop counter
wraparound; the root cause must have been different in the original failure you
were seeing.

[Bug c++/81767] Unused variable warning with structured binding

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED
   Target Milestone|--- |8.0

[Bug target/79565] ICE in copy_to_mode_reg, at explow.c:612

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
Created attachment 41959
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41959=edit
A patch

I got

[hjl@gnu-6 pr79565]$ cat x.i
typedef float a __attribute__ ((__vector_size__ (16)));
a b, d;
int __attribute__ ((__vector_size__ (2 * sizeof (int c;
void e () { d = __builtin_ia32_cvtpi2ps (b, c); }
[hjl@gnu-6 pr79565]$ make x.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -mno-mmx -S -o x.s x.i
x.i: In function ‘e’:
x.i:4:17: error: ‘__builtin_ia32_cvtpi2ps’ needs isa option -m32 -msse -mmmx
 void e () { d = __builtin_ia32_cvtpi2ps (b, c); }
 ^~
make: *** [Makefile:21: x.s] Error 1
[hjl@gnu-6 pr79565]$ cat y.i
typedef short v4hi __attribute__ ((__vector_size__ (4 * sizeof (short;
v4hi a, b, c;
void
foo (void)
{
  a = __builtin_ia32_psubusw (b, c);
}
[hjl@gnu-6 pr79565]$ make y.s
/export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc
-B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -mno-mmx -S -o y.s y.i
y.i: In function ‘foo’:
y.i:6:7: error: ‘__builtin_ia32_psubusw’ needs isa option -m32 -mmmx
   a = __builtin_ia32_psubusw (b, c);
   ^
make: *** [Makefile:21: y.s] Error 1
[hjl@gnu-6 pr79565]$

[Bug c++/81767] Unused variable warning with structured binding

[antoshkka at gmail dot com]

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

Antony Polukhin  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Antony Polukhin  ---
Yep, feature was already implemented in r248483

[Bug testsuite/81784] New: [8 regression] gcc.dg/compare2.c fails starting with r250984

[seurer at gcc dot gnu.org]

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

Bug ID: 81784
   Summary: [8 regression] gcc.dg/compare2.c fails starting with
r250984
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

The recent change to the test case gcc.dg/compare2.c doesn't seem to work quite
right.  At least not on powerpc64 where it fails on both BE and LE (tested on
power8).

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -Wsign-compare -S -o
compare2.s
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c: In function 'f':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:21:5: warning:
comparison of integer expressions of different signedness: 'unsigned int' and
'int' [-Wsign-compare]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:25:5: warning:
comparison of integer expressions of different signedness: 'unsigned int' and
'int' [-Wsign-compare]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:37:5: warning:
comparison of integer expressions of different signedness: 'unsigned int' and
'int' [-Wsign-compare]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:41:5: warning:
comparison of integer expressions of different signedness: 'unsigned int' and
'int' [-Wsign-compare]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:49:12: warning:
operand of ?: changes signedness from 'int' to 'unsigned int' due to
unsignedness of other operand [-Wsign-compare]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:57:12: warning:
operand of ?: changes signedness from 'int' to 'unsigned int' due to
unsignedness of other operand [-Wsign-compare]
output is:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c: In function 'f':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:21:5: warning:
comparison of integer expressions of different signedness: 'unsigned int' and
'int' [-Wsign-compare]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:25:5: warning:
comparison of integer expressions of different signedness: 'unsigned int' and
'int' [-Wsign-compare]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:37:5: warning:
comparison of integer expressions of different signedness: 'unsigned int' and
'int' [-Wsign-compare]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:41:5: warning:
comparison of integer expressions of different signedness: 'unsigned int' and
'int' [-Wsign-compare]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:49:12: warning:
operand of ?: changes signedness from 'int' to 'unsigned int' due to
unsignedness of other operand [-Wsign-compare]
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:57:12: warning:
operand of ?: changes signedness from 'int' to 'unsigned int' due to
unsignedness of other operand [-Wsign-compare]

PASS: gcc.dg/compare2.c case 1 (test for bogus messages, line 12)
PASS: gcc.dg/compare2.c case 2 (test for bogus messages, line 13)
PASS: gcc.dg/compare2.c case 3 (test for bogus messages, line 16)
PASS: gcc.dg/compare2.c case 4 (test for bogus messages, line 17)
PASS: gcc.dg/compare2.c case 5 (test for bogus messages, line 20)
PASS: gcc.dg/compare2.c case 6 (test for warnings, line 21)
PASS: gcc.dg/compare2.c case 7 (test for bogus messages, line 24)
PASS: gcc.dg/compare2.c case 8 (test for warnings, line 25)
PASS: gcc.dg/compare2.c case 9 (test for bogus messages, line 28)
PASS: gcc.dg/compare2.c case 10 (test for bogus messages, line 29)
PASS: gcc.dg/compare2.c case 11 (test for bogus messages, line 32)
PASS: gcc.dg/compare2.c case 12 (test for bogus messages, line 33)
PASS: gcc.dg/compare2.c case 13 (test for bogus messages, line 36)
PASS: gcc.dg/compare2.c case 14 (test for warnings, line 37)
PASS: gcc.dg/compare2.c case 15 (test for bogus messages, line 40)
PASS: gcc.dg/compare2.c case 16 (test for warnings, line 41)
PASS: gcc.dg/compare2.c case 17 (test for bogus messages, line 44)
PASS: gcc.dg/compare2.c case 18 (test for bogus messages, line 45)
PASS: gcc.dg/compare2.c case 19 (test for bogus messages, line 48)
FAIL: gcc.dg/compare2.c case 20 (test for warnings, line 49)
PASS: gcc.dg/compare2.c case 21 (test for bogus messages, line 52)
PASS: gcc.dg/compare2.c case 22 (test for bogus messages, line 53)
PASS: gcc.dg/compare2.c case 23 (test for bogus messages, line 56)
FAIL: gcc.dg/compare2.c case 24 (test for warnings, line 57)
FAIL: gcc.dg/compare2.c (test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/compare2.c:49:12: warning:
operand of ?: changes signedness from 'int' to 'unsigned int' due to
unsignedness of other 

[Bug target/80503] ICE in extract_insn, at recog.c:2311 on ppc64le-linux-gnu

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
Is this a dup of PR80618?  That is fixed on all branches already.

[Bug c++/81586] valgrind error in output_buffer_append_r with -Wall

[dcb314 at hotmail dot com]

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

--- Comment #6 from David Binderman  ---
(In reply to Martin Sebor from comment #5)
> Patch: https://gcc.gnu.org/ml/gcc-patches/2017-07/msg01866.html

Did this patch ever get into trunk gcc ?

I have some evidence that gcc trunk revision 250947
doesn't have it.

[Bug libfortran/80850] Sourced allocate() fails to allocate a pointer

[liakhdi at ornl dot gov]

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

--- Comment #12 from DIL  ---
Could you please tell me if there is a way I can check whether the dissociated
unlimited polymorphic pointer (class(*), pointer), which is set to NULL, is
indeed set to a clean state internally? That is, could you please tell me the
size and structure of the internal representation of a class(*) pointer and
what the proper values of those components would be when the pointer is set to
NULL()? I am still trying to understand why the sourced allocate() statement
sees that pointer as ALLOCATED. Basically, I want to inspect the internal state
of the class(*) NULL pointer to make sure that the problem indeed occurs inside
the sourced allocate() statement. Thanks!

[Bug target/79565] ICE in copy_to_mode_reg, at explow.c:612

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #1 from H.J. Lu  ---
(In reply to Martin Liška from comment #0)
> All releases I have suffer from:
> 
> Clang is also broken, ICC work for that test-case.

What does ICC generate with -mno-mmx -O0?

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[mike at fireburn dot co.uk]

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

--- Comment #10 from Mike Lothian  ---
Unfortunately it also depends on LLVM not just Mesa which makes it a much
bigger target for figuring this out

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[amonakov at gcc dot gnu.org]

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

--- Comment #9 from Alexander Monakov  ---
A (potentially simpler) alternative is to use sequential builds (make without
-j) and bisect by index of compiled source file, i.e. have a wrapper script
around gcc that uses some global counter to pass -mno-bmi to first N compiler
invocations.

[Bug libstdc++/81751] __basic_file::sync() may flush _all_ files

[bugzilla.volker at kabelmail dot de]

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

--- Comment #5 from Volker Wehrs  ---
I'm sorry but I ignored the first if-clause in sys_open(). That if-clause makes
sure there is no open file referenced by the __basic_file, otherwise sys_open()
fails.

Then the sync() is called before the new __file is set, so in the current
implementation sync() can only see a _M_cfile set to NULL. Thus sync() is wrong
here.

Note that currently the new file (in __file) is implicitly flushed by the call
to fflush("NULL"), i.e. "flush all". So the new file should be sync'd
explicitly.

So sys_open() might look like this:

  __basic_file*
  __basic_file::sys_open(__c_file* __file, ios_base::openmode)
  {
__basic_file* __ret = NULL;
if (!this->is_open() && __file)
  {
_M_cfile = __file;
_M_cfile_created = false;
__ret = this;
this->sync();
  }
return __ret;
  }

[...]

  int
  __basic_file::sync()
  {
int __err;
do
  __err = fflush(_M_cfile);
while ( __err && errno == EINTR );
return __err;
  }

[Bug target/81763] Issues with BMI on 32bit x86 apps on GCC 7.1+

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #8 from Alexander Monakov  ---
Mike, you can start by preparing two build trees, one with faulty mesa compiled
with -march=native, the other with working-fine mesa compiled with
-march=native -mno-bmi. You should be able to collect:

- .o files from each tree, and
- link commands from build logs

and be able to re-link mesa libraries by hand and verify they still exhibit the
same behavior (one fails, the other doesn't).

>From there you can proceed by building "hybrid" libraries by taking a set of
good .o files and a complementary set of bad .o files. This will allow you to
find a single .o file that makes the library behave wrongly. More explanation
and a helper script for bisecting is available at
https://gcc.gnu.org/wiki/Analysing_Large_Testcases

At that point please share your status (once you're down to one file there's no
generic recipe, you'd have to get creative).

[Bug debug/80938] [7/8 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Target|powerpcspe-*-linux-gnu* |powerpcspe-*-linux-gnu*,
   ||powerpc*-*-*

--- Comment #2 from Segher Boessenkool  ---
Also fails on powerpc*-linux (it needs -Os -fPIC -m32 -g).  It gets
a conflict in the CFI for the hard frame pointer.

[Bug c++/2082] g++ defines _GNU_SOURCE by default

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
 Resolution|FIXED   |WONTFIX

--- Comment #11 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #10)
> Should this be WONTFIX rather than FIXED? I think FIXED is the default for
> "closed" from the old gnatweb system, but this was not fixed.
> 
> Or now that I'm (slowly) working on fixing it, maybe even REOPENED, or make
> it a dup of Bug 11196.

From reading the previous comments it looks like WONTFIX is indeed more
accurate than FIXED, so I'm changing the status to that for now. Bug 11196
looks like a more specific instance of this one so I'd say if one's going to be
marked a duplicate of the other, it should probably be the other way around.

[Bug target/77953] [MIPS] ice: insn does not satisfy its constraints - __bswapsi2

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-08-09
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Can't reproduce on x86_64-linux-gnu cross compiler. Is it reproducible?

[Bug preprocessor/53404] warning column reported on comment in warning during bootstrap

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Eric Gallager from comment #3)
> (In reply to Manuel López-Ibáñez from comment #2)
> > I don't see this any longer.
> 
> I think I might've seen this before, but I'll have to double-check the next
> time I bootstrap to make sure

The warnings I get from gengtype-lex.c when bootstrapping are now:

../../gcc/gengtype-lex.l: In function ‘int yylex(const char**)’:
gengtype-lex.c:287:13: warning: this statement may fall through
[-Wimplicit-fallthrough=]
  *yy_cp = '\0'; \
  ~~~^~~
../../gcc/gengtype-lex.l:116:1: note: in expansion of macro
‘YY_DO_BEFORE_ACTION’
 *yylval = XDUPVAR (const char, yytext, yyleng, yyleng + 1);
 ^   ~~~
../../gcc/gengtype-lex.l:113:1: note: here
 "~" |
 ^~~~
gengtype-lex.c:287:13: warning: this statement may fall through
[-Wimplicit-fallthrough=]
  *yy_cp = '\0'; \
  ~~~^~~
../../gcc/gengtype-lex.l:133:1: note: in expansion of macro
‘YY_DO_BEFORE_ACTION’

 ^  
../../gcc/gengtype-lex.l:131:1: note: here
 "ENUM_BITFIELD"{WS}?"("{WS}?{ID}{WS}?")" {
 ^~~~

...which is no longer in a comment, but it still seems like there's some wrong
location information involved. Separate issue or the same thing?

[Bug target/78643] [5/6/7/8 Regression] ICE in convert_move, at expr.c:230

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-09
 CC||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|ICE in convert_move, at |[5/6/7/8 Regression] ICE in
   |expr.c:230  |convert_move, at expr.c:230
 Ever confirmed|0   |1
  Known to fail||8.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with
r220609.https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78643#

[Bug target/68485] ICE while building gpsd package on microblaze

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||eager at gcc dot gnu.org

--- Comment #4 from Martin Liška  ---
Started with r248540:

commit 707a69dfb56a2976e2b5c010f0e5cb2ac9905a07 (refs/bisect/bad)
Author: eager 
Date:   Sat May 27 18:29:40 2017 +

Revert:
2016-01-21  Ajit Agarwal  

See https://gcc.gnu.org/ml/gcc/2017-05/msg00221.html.

* config/microblaze/microblaze.h
(FIXED_REGISTERS): Update in macro.
(CALL_USED_REGISTERS): Update in macro.



git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@248540
138bc75d-0d04-0410-961f-82ee72b054a4

Can you please Agit take a look?

[Bug target/79810] ICE in ix86_vector_duplicate_value, at config/i386/i386.c:45701

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from H.J. Lu  ---
(In reply to Martin Liška from comment #1)
> Fixed on trunk in r246161. Do you plan Uros to backport it?

Should have been fixed on all branches.

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

[Bug target/80019] ICE in ix86_vector_duplicate_value, at config/i386/i386.c:42584

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu  ---
*** Bug 79810 has been marked as a duplicate of this bug. ***

[Bug target/48227] "rep ret" generated for -march=core2

[matt at godbolt dot org]

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

--- Comment #5 from Matt Godbolt  ---
Seems to have been fixed in 4.9

[Bug tree-optimization/79987] [CHKP] ICE in gimplify_expr, at gimplify.c:12151

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Taking, I've got a patch.

[Bug middle-end/81782] [7/8 Regression] Yet another -Wmaybe-uninitialized false positive with empty array

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-09
 CC||egallager at gcc dot gnu.org
 Blocks||24639
 Ever confirmed|0   |1

--- Comment #2 from Eric Gallager  ---
Confirmed that GCC warns here


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug target/68485] ICE while building gpsd package on microblaze

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |NEW

[Bug target/68485] ICE while building gpsd package on microblaze

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
Created attachment 41958
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41958=edit
Minimal test-case

[Bug target/79890] ICE in s390_initial_elimination_offset, at config/s390/s390.c:10430

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška  ---
*** Bug 80214 has been marked as a duplicate of this bug. ***

[Bug target/80214] ICE in s390_initial_elimination_offset, at config/s390/s390.c:10249

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Dup.

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

[Bug c/81783] New: -Wtautological-compare could do better

[sirl at gcc dot gnu.org]

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

Bug ID: 81783
   Summary: -Wtautological-compare could do better
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sirl at gcc dot gnu.org
  Target Milestone: ---

This example code doesn't warn with -Wtautological-compare:

int f(int a)
{
if ((a & 0x10) == 10)
return 1;
return 0;
}

clang warns like this:
Wtautological-compare-1.c:5:17: warning: bitwise comparison always evaluates to
false [-Wtautological-compare]
if ((a & 0x10) == 10)
~~~^

[Bug c++/2082] g++ defines _GNU_SOURCE by default

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=11196

--- Comment #10 from Jonathan Wakely  ---
Should this be WONTFIX rather than FIXED? I think FIXED is the default for
"closed" from the old gnatweb system, but this was not fixed.

Or now that I'm (slowly) working on fixing it, maybe even REOPENED, or make it
a dup of Bug 11196.

[Bug libstdc++/11196] _GNU_SOURCE vs. M_PI

[redi at gcc dot gnu.org]

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

--- Comment #16 from Jonathan Wakely  ---
See https://sourceware.org/bugzilla/show_bug.cgi?id=21326 and
https://sourceware.org/bugzilla/show_bug.cgi?id=21327 for the changes to glibc
that are needed before we can change anything in GCC.

[Bug middle-end/81695] [5/6/7 Regression] internal compiler error: in size_binop_loc, at fold-const.c:1768

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #10 from Marek Polacek  ---
I think I won't backport this, so closing.

[Bug target/68485] ICE while building gpsd package on microblaze

[sergio.pr...@e-labworks.com]

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

--- Comment #2 from Sergio Prado  ---
Created attachment 41957
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41957=edit
Pre-processed file from rtcm2_json.c compiled with -E option

Here is the pre-processed file.

[Bug middle-end/81782] [7/8 Regression] Yet another -Wmaybe-uninitialized false positive with empty array

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |7.2
Summary|Yet another |[7/8 Regression] Yet
   |-Wmaybe-uninitialized false |another
   |positive with empty array   |-Wmaybe-uninitialized false
   ||positive with empty array

--- Comment #1 from Marek Polacek  ---
Started with
commit 4d2b9d1e3c794a05c00708035519290e920768e8
Author: rguenth 
Date:   Thu Mar 2 13:42:05 2017 +

2017-03-02  Richard Biener  

PR tree-optimization/79345
PR c++/42000
* tree-ssa-alias.c (walk_aliased_vdefs_1): Take a limit
param and abort the walk, returning -1 if it is hit.
(walk_aliased_vdefs): Take a limit param and pass it on.
* tree-ssa-alias.h (walk_aliased_vdefs): Add a limit param,
defaulting to 0 and return a signed int.
* tree-ssa-uninit.c (struct check_defs_data): New struct.
(check_defs): New helper.
(warn_uninitialized_vars): Use walk_aliased_vdefs to warn
about uninitialized memory.

* fixed-value.c (fixed_from_string): Use ulow/uhigh to avoid
bogus uninitialized warning.
(fixed_convert_from_real): Likewise.

* g++.dg/warn/Wuninitialized-7.C: New testcase.
* c-c++-common/ubsan/bounds-2.c: Add -Wno-uninitialized.
* gcc.dg/uninit-pr19430-2.c: Add expected warning.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@245840
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug middle-end/81782] New: Yet another -Wmaybe-uninitialized false positive with empty array

[mpolacek at gcc dot gnu.org]

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

Bug ID: 81782
   Summary: Yet another -Wmaybe-uninitialized false positive with
empty array
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

I hope this isn't a duplicate of one of the many similar PRs.  This one happens
with -O0.  Also, if you remove the (int) cast, the warning disappears, because
then we get rid of the if conditional.

$ ./cc1 -quiet w.c -Wall
w.c: In function ‘foo’:
w.c:8:22: warning: ‘empty_array[i]’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
 ret = empty_array[i];
   ~~~^~~

int
foo (void)
{
  char empty_array[] = { };
  int i, ret = 0;

  for (i = 0; i < (int) (sizeof (empty_array) / sizeof (empty_array[0])); i++)
ret = empty_array[i];

  return ret;
}

[Bug middle-end/80295] [7/8 Regression] ICE in __builtin_update_setjmp_buf expander

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-09
 CC||marxin at gcc dot gnu.org
  Known to work||6.4.0
Summary|ICE in  |[7/8 Regression] ICE in
   |__builtin_update_setjmp_buf |__builtin_update_setjmp_buf
   |expander|expander
 Ever confirmed|0   |1
  Known to fail||7.1.0, 8.0

--- Comment #1 from Martin Liška  ---
Confirmed. Started with your commit r246720.

[Bug target/79810] ICE in ix86_vector_duplicate_value, at config/i386/i386.c:45701

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-09
  Known to work||7.1.0
 Ever confirmed|0   |1
  Known to fail||5.4.0, 6.3.0

--- Comment #1 from Martin Liška  ---
Fixed on trunk in r246161. Do you plan Uros to backport it?

[Bug libstdc++/81751] __basic_file::sync() may flush _all_ files

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
But there is an open FILE and it might have pending writes or ungetc'd data
that should be flushed. I think that's why it's there. Consider:

  FILE* f = std::fopen("81751.txt", "w+");
  std::fwrite("Some words.", 1, 10, f);
  __gnu_cxx::stdio_filebuf buf(f, std::ios::in|std::ios::out, BUFSIZ);
  int c = buf.sgetc();

If the constructor doesn't flush then the read performed by sgetc will follow
the write without an intervening seek or flush, which is undefined behaviour.

The constructor taking a file descriptor creates a new FILE using fdopen, so
there are no buffered writes on the stream, and a flush isn't needed.

[Bug debug/79953] ICE in expand_debug_locations when attribute target is used

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-09
 CC||aoliva at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, all releases I have ICE.

(gdb) p debug_rtx(val)
(mem/c:V32QI (plus:DI (reg/f:DI 82 virtual-stack-vars)
(const_int -32 [0xffe0])) [0 x+0 S32 A256])
$4 = void
(gdb) p mode
$5 = BLKmode

Problem is probably that nehalem does not have -mavx2 enabled and it's enabled
in the source code via target attribute.

[Bug c++/81781] consexpr pointer comparsion error

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-09
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Confirmed. Reduced:

template struct I { static constexpr int value = N; };

template constexpr int I::value;

static constexpr bool x = <5>::value == <10>::value;


ce.cc:5:40: error: ‘((& I<5>::value) == (& I<10>::value))’ is not a constant
expression
 static constexpr bool x = <5>::value == <10>::value;
   ~^

[Bug c/81233] --Wdiscarded-qualifiers and Wincompatible-pointer-types missing important detail

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed.  Further improvements are possible.

[Bug c/81233] --Wdiscarded-qualifiers and Wincompatible-pointer-types missing important detail

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Author: mpolacek
Date: Wed Aug  9 11:28:22 2017
New Revision: 250985

URL: https://gcc.gnu.org/viewcvs?rev=250985=gcc=rev
Log:
PR c/81233
* c-typeck.c (pedwarn_init): Make the function take a variable list.
Call emit_diagnostic_valist instead of pedwarn.
(convert_for_assignment): Unroll the PEDWARN_FOR_ASSIGNMENT macro.
Print the relevant types in diagnostics.

* diagnostic-core.h (emit_diagnostic_valist): Add declaration.
* diagnostic.c (emit_diagnostic): Add a comment.
(emit_diagnostic_valist): New function.

* gcc.dg/diagnostic-types-1.c: New test.
* gcc.dg/assign-warn-1.c: Update warning messages.
* gcc.dg/assign-warn-2.c: Likewise.
* gcc.dg/c90-const-expr-5.c: Likewise.
* gcc.dg/c99-const-expr-5.c: Likewise.
* gcc.dg/conv-2.c: Likewise.
* gcc.dg/init-bad-7.c: Likewise.
* gcc.dg/overflow-warn-1.c: Likewise.
* gcc.dg/overflow-warn-2.c: Likewise.
* gcc.dg/overflow-warn-3.c: Likewise.
* gcc.dg/overflow-warn-4.c: Likewise.
* gcc.dg/pointer-array-atomic.c: Likewise.
* gcc.dg/pr26865.c: Likewise.
* gcc.dg/pr61162-2.c: Likewise.
* gcc.dg/pr61162.c: Likewise.
* gcc.dg/pr67730-2.c: Likewise.
* gcc.dg/pr69156.c: Likewise.
* gcc.dg/pr70174.c: Likewise.
* objc.dg/proto-lossage-4.m: Likewise.

Added:
trunk/gcc/testsuite/gcc.dg/diagnostic-types-1.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-typeck.c
trunk/gcc/diagnostic-core.h
trunk/gcc/diagnostic.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/assign-warn-1.c
trunk/gcc/testsuite/gcc.dg/assign-warn-2.c
trunk/gcc/testsuite/gcc.dg/c90-const-expr-5.c
trunk/gcc/testsuite/gcc.dg/c99-const-expr-5.c
trunk/gcc/testsuite/gcc.dg/conv-2.c
trunk/gcc/testsuite/gcc.dg/init-bad-7.c
trunk/gcc/testsuite/gcc.dg/overflow-warn-1.c
trunk/gcc/testsuite/gcc.dg/overflow-warn-2.c
trunk/gcc/testsuite/gcc.dg/overflow-warn-3.c
trunk/gcc/testsuite/gcc.dg/overflow-warn-4.c
trunk/gcc/testsuite/gcc.dg/pointer-array-atomic.c
trunk/gcc/testsuite/gcc.dg/pr26865.c
trunk/gcc/testsuite/gcc.dg/pr61162-2.c
trunk/gcc/testsuite/gcc.dg/pr61162.c
trunk/gcc/testsuite/gcc.dg/pr67730-2.c
trunk/gcc/testsuite/gcc.dg/pr69156.c
trunk/gcc/testsuite/gcc.dg/pr70174.c
trunk/gcc/testsuite/objc.dg/proto-lossage-4.m

[Bug c++/81750] Calling generic lambda with no parameter fails to compile

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Indeed, thanks, Tim.

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

[Bug c++/64095] [C++14] Ellipsis at end of generic lambda parameter-declaration-clause should be parsed as a parameter pack

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||d25fe0be at outlook dot com

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

[Bug target/81780] -finstrument-control-flow -mcet is incompatible with __attribute__ ((regparm (3)))

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
(In reply to Florian Weimer from comment #1)
> Could we turn calls to regparam (3) functions into noplt calls?  Some
> additional mechanics are probably needed if the address of such a function
> is taken.

Yes, we can make regparam (3) to imply __attribute__ ((noplt)) with
-finstrument-control-flow -mcet.  It should work.

[Bug target/80503] ICE in extract_insn, at recog.c:2311 on ppc64le-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-09
 CC||amodra at gcc dot gnu.org,
   ||segher at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/80700] [7/8 Regression] ICE: Bus error (on SPE target)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-09
 CC||bergner at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
Summary|[8 Regression] ICE: Bus |[7/8 Regression] ICE: Bus
   |error (on SPE target)   |error (on SPE target)
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Confirmed, started with r244609.

[Bug target/81780] -finstrument-control-flow -mcet is incompatible with __attribute__ ((regparm (3)))

[fw at gcc dot gnu.org]

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

--- Comment #1 from Florian Weimer  ---
Could we turn calls to regparam (3) functions into noplt calls?  Some
additional mechanics are probably needed if the address of such a function is
taken.