[Bug bootstrap/80447] Profiled LTO bootstrap fails on powerpc64le

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
(In reply to Martin Sebor from comment #9)
>
> It's possible that the path is not reachable and GCC doesn't see it.

Well, 18 exabytes allocations or memsets would not go unnoticed for very
long...

[Bug rtl-optimization/80401] [7 regression] gcc.target/powerpc/dimode_off.c and gcc.target/powerpc/pr79038-1.c fail starting with r246764

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #6 from Jeffrey A. Law  ---
So if this is fixed by Vlad's lra-constraints patch, should we close this BZ?

[Bug target/74563] [6 regression] Classic MIPS16 (non-MIPS16e) function return broken

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[6/7 regression] Classic|[6 regression] Classic
   |MIPS16 (non-MIPS16e)|MIPS16 (non-MIPS16e)
   |function return broken  |function return broken

--- Comment #10 from Jeffrey A. Law  ---
Fixed on the trunk.  Port maintainers can decide to backport or not to the
release branches.

[Bug target/74563] [6/7 regression] Classic MIPS16 (non-MIPS16e) function return broken

[law at gcc dot gnu.org]

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

--- Comment #9 from Jeffrey A. Law  ---
Author: law
Date: Wed Apr 19 04:52:54 2017
New Revision: 246987

URL: https://gcc.gnu.org/viewcvs?rev=246987=gcc=rev
Log:
PR target/74563
* mips.md ({return,simple_return}_internal): Do not overwrite
operands[0].

PR target/74563
* gcc.target/mips/pr74563: New test.

Added:
trunk/gcc/testsuite/gcc.target/mips/pr74563.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/mips.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/80460] New: Non-sensical fallthrough warning after [[noreturn]] function leading to __builtin_unreachable()

[thiago at kde dot org]

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

Bug ID: 80460
   Summary: Non-sensical fallthrough warning after [[noreturn]]
function leading to __builtin_unreachable()
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org
  Target Milestone: ---

Testcase:

===
[[noreturn]] void qt_assert() noexcept;
inline void qt_noop() {}

void f(int i)
{
switch (i) {
case 0:
((!(!"message")) ? qt_assert() : qt_noop());
case 1:
qt_noop();
}
}
===

Prints (under -O2):

: In function 'void f(int)':
:8:49: warning: this statement may fall through
[-Wimplicit-fallthrough=]
 ((!(!"message")) ? qt_assert() : qt_noop());
  ~~~^~
:9:5: note: here
 case 1:
 ^~~~

The condition !!"message" is always true, so the [[noreturn]] function
qt_assert() will be called. There's no condition under which qt_noop() will be
called, so there's no fallthrough possible.

[Bug bootstrap/55496] False positive -Werror=uninitialized breaks profiledbootstrap and bootstrap-lto

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
There are a ton of warnings in profiledbootstrap, including -Wuninitialized
(see the full list below for an x86_64 GCC 7.0 configured with
--enable-languages=ada,all,c,c++,fortran,go,objc,obj-c++
-with-build-config=bootstrap-lto --disable-werror).  My understanding is that
it's not really expected to work without --disable-werror.

DiagnosticCount   UniqueFiles
-Wmaybe-uninitialized   315   97   46
-Wuninitialized  44   221
-Walloc-size-larger-than=3462
-Wlto-type-mismatch  25   206
-Wunused-parameter   2032
-Wstringop-overflow= 1011
-Wnonnull1042
-Wimplicit-fallthrough=   811
-Wsign-compare611
-Wcpp 411
-Wformat-truncation=  321

-Walloc-size-larger-than Instances: 
  /src/gcc/trunk/gcc/dominance.c:153
  /src/gcc/trunk/gcc/dominance.c:167
  /src/gcc/trunk/gcc/dominance.c:168
  /src/gcc/trunk/gcc/dominance.c:169
  /src/gcc/trunk/gcc/dominance.c:303
  /src/gcc/trunk/gcc/go/go-gcc.cc:1896

-Wcpp Instances: 
  /usr/include/features.h:148

-Wformat-truncation Instances: 
  /src/gcc/trunk/libgfortran/intrinsics/date_and_time.c:168
  /src/gcc/trunk/libgfortran/intrinsics/date_and_time.c:172

-Wimplicit-fallthrough Instances: 
  gengtype-lex.c:380

-Wlto-type-mismatch Instances: 
  /src/gcc/trunk/gcc/ada/fe.h:112
  /src/gcc/trunk/gcc/ada/fe.h:113
  /src/gcc/trunk/gcc/ada/fe.h:135
  /src/gcc/trunk/gcc/ada/fe.h:149
  /src/gcc/trunk/gcc/ada/fe.h:271
  /src/gcc/trunk/gcc/ada/fe.h:49
  /src/gcc/trunk/gcc/ada/fe.h:90
  /src/gcc/trunk/gcc/ada/fe.h:91
  /src/gcc/trunk/gcc/ada/fe.h:92
  /src/gcc/trunk/gcc/ada/gnatvsn.adb:57
  /src/gcc/trunk/gcc/ada/init.c:80
  /src/gcc/trunk/gcc/ada/init.c:82
  /src/gcc/trunk/gcc/ada/init.c:83
  /src/gcc/trunk/gcc/ada/init.c:94
  /src/gcc/trunk/gcc/ada/namet.h:122
  /src/gcc/trunk/gcc/ada/namet.h:49
  /src/gcc/trunk/gcc/ada/namet.h:67
  /src/gcc/trunk/gcc/ada/uintp.h:105
  /src/gcc/trunk/gcc/ada/uintp.h:84
  /src/gcc/trunk/gcc/ada/urealp.h:59

-Wmaybe-uninitialized Instances: 
  g-comlin.adb:583
  g-debpoo.adb:1418
  /src/gcc/trunk/gcc/ada/xref_lib.adb:1039
  /src/gcc/trunk/gcc/ada/xref_lib.adb:1143
  /src/gcc/trunk/gcc/ada/xref_lib.adb:770
  /src/gcc/trunk/gcc/ada/xr_tabls.adb:1015
  /src/gcc/trunk/gcc/ada/xr_tabls.adb:1065
  /src/gcc/trunk/gcc/ada/atree.adb:1776
  /src/gcc/trunk/gcc/ada/atree.adb:2448
  /src/gcc/trunk/gcc/ada/checks.adb:7915
  /src/gcc/trunk/gcc/ada/checks.adb:8129
  /src/gcc/trunk/gcc/ada/checks.adb:8287
  /src/gcc/trunk/gcc/ada/contracts.adb:938
  /src/gcc/trunk/gcc/ada/einfo.adb:10997
  /src/gcc/trunk/gcc/ada/elists.adb:261
  /src/gcc/trunk/gcc/ada/exp_attr.adb:1340
  /src/gcc/trunk/gcc/ada/exp_attr.adb:1430
  /src/gcc/trunk/gcc/ada/exp_ch4.adb:4029
  /src/gcc/trunk/gcc/ada/exp_ch7.adb:8332
  /src/gcc/trunk/gcc/ada/exp_ch7.adb:8729
  /src/gcc/trunk/gcc/ada/exp_ch7.adb:8909
  /src/gcc/trunk/gcc/ada/exp_ch9.adb:3292
  /src/gcc/trunk/gcc/ada/exp_ch9.adb:6177
  /src/gcc/trunk/gcc/ada/exp_ch9.adb:9984
  /src/gcc/trunk/gcc/ada/exp_disp.adb:1060
  /src/gcc/trunk/gcc/ada/exp_disp.adb:1561
  /src/gcc/trunk/gcc/ada/exp_disp.adb:1577
  /src/gcc/trunk/gcc/ada/exp_disp.adb:1672
  /src/gcc/trunk/gcc/ada/exp_disp.adb:1687
  /src/gcc/trunk/gcc/ada/exp_disp.adb:5186
  /src/gcc/trunk/gcc/ada/exp_dist.adb:10036
  /src/gcc/trunk/gcc/ada/exp_dist.adb:1533
  /src/gcc/trunk/gcc/ada/exp_dist.adb:1538
  /src/gcc/trunk/gcc/ada/exp_dist.adb:1555
  /src/gcc/trunk/gcc/ada/exp_dist.adb:1571
  /src/gcc/trunk/gcc/ada/exp_dist.adb:1574
  /src/gcc/trunk/gcc/ada/freeze.adb:1287
  /src/gcc/trunk/gcc/ada/inline.adb:3359
  /src/gcc/trunk/gcc/ada/inline.adb:3493
  /src/gcc/trunk/gcc/ada/nlists.adb:303
  /src/gcc/trunk/gcc/ada/par-ch3.adb:3859
  /src/gcc/trunk/gcc/ada/par-ch9.adb:125
  /src/gcc/trunk/gcc/ada/par-ch9.adb:472
  /src/gcc/trunk/gcc/ada/put_spark_xrefs.adb:167
  /src/gcc/trunk/gcc/ada/put_spark_xrefs.adb:174
  /src/gcc/trunk/gcc/ada/sem.adb:766
  /src/gcc/trunk/gcc/ada/sem_aggr.adb:2874
  /src/gcc/trunk/gcc/ada/sem_aggr.adb:4824
  /src/gcc/trunk/gcc/ada/sem_case.adb:488
  /src/gcc/trunk/gcc/ada/sem_ch12.adb:13651
  /src/gcc/trunk/gcc/ada/sem_ch12.adb:4678
  /src/gcc/trunk/gcc/ada/sem_ch12.adb:5692
  /src/gcc/trunk/gcc/ada/sem_ch13.adb:10056
  /src/gcc/trunk/gcc/ada/sem_ch13.adb:13475
  /src/gcc/trunk/gcc/ada/sem_ch13.adb:13490
  /src/gcc/trunk/gcc/ada/sem_ch13.adb:1854
  

[Bug bootstrap/80455] -Werror=coverage-mismatch in profiledboostrap despite --disable-werror

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Yes, it looks like it is.  Thanks for pointing out to me!  After blowing away
the in-tree gmp and other prerequisites the bootstrap succeeds.

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

[Bug bootstrap/69725] LTO/PGO bootstrap fails with in-tree gmp

[msebor at gcc dot gnu.org]

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

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

[Bug target/74563] [6/7 regression] Classic MIPS16 (non-MIPS16e) function return broken

[law at redhat dot com]

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

--- Comment #8 from Jeffrey A. Law  ---
So AFAICT this pattern:

(define_insn "*"
  [(any_return)]
  ""
  {
operands[0] = gen_rtx_REG (Pmode, RETURN_ADDR_REGNUM);
return mips_output_jump (operands, 0, -1, false);
  }
  [(set_attr "type" "jump")
   (set_attr "mode" "none")])


Is used for shrink-wrapping -- in particular it may be used while the return
pointer is still sitting in $31.


The _internal pattern:

(define_insn "_internal"
  [(any_return)
   (use (match_operand 0 "pmode_register_operand" ""))]
  ""
  {
operands[0] = gen_rtx_REG (Pmode, RETURN_ADDR_REGNUM);
return mips_output_jump (operands, 0, -1, false);
  }
  [(set_attr "type" "jump")
   (set_attr "mode" "none")])

Is used directly by mips.c which should be passing in the right
RETURN_ADDR_REGNUM.

So like you, I think the solution is to just remove the offending line.  I'm
going to spin one more test.  But I think we're converging on the solution.

[Bug c++/80459] [7 regression] c-c++-common/opaque-vector.c FAILs

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug c++/80459] New: [7 regression] c-c++-common/opaque-vector.c FAILs

[ro at gcc dot gnu.org]

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

Bug ID: 80459
   Summary: [7 regression] c-c++-common/opaque-vector.c FAILs
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: sparc-sun-solaris2.12, powerpc64-unknown-linux-gnu

Between 20170417 (r246952) and 20170418 (r246971), a c++ testsuite regression
occured:

+FAIL: c-c++-common/opaque-vector.c  -std=c++11 (test for excess errors)
+FAIL: c-c++-common/opaque-vector.c  -std=c++14 (test for excess errors)
+FAIL: c-c++-common/opaque-vector.c  -std=c++98 (test for excess errors)

I'm seeing it on 32-bit (only) Solaris/SPARC, but according to gcc-testresults
the same regression occurs on 32-bit powerpc64-unknown-linux-gnu:

Excess errors:
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/opaque-vector.c:3:84:
error: could not find an integer type of the same size as 'long double'
/vol/gcc/src/hg/trunk/local/gcc/testsuite/c-c++-common/opaque-vector.c:3:140:
error: inferred scalar type 'long double' is not an integer or floating point
type of the same size as 'int'

  Rainer

[Bug c++/80458] [-Wreturn-type] false negative on missing return statement in a member function

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
I think this is because an unused inline function doesn't generate any code, so
isn't seen by the compiler passes that produce the warning.

[Bug c++/80458] [-Wreturn-type] false negative on missing return statement in a member function

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
The two cases are not equivalent, because the member function is also inline.
If you add 'inline' to the second example you get no warning for that one too.

In both cases you get a warning for the inline function if it is used.

[Bug other/72815] libmpx on i386

[vicencb at gmail dot com]

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

--- Comment #2 from vicencb at gmail dot com ---
I think the bug was triggered with buildroot version
eb1a30a3d92c8ddbcc295cb48226604d6d881e25
following these steps:
cat << EOF > .config
BR2_x86_i686=y
BR2_DL_DIR="/media/sources"
BR2_HOST_DIR="/opt/i686-buildroot-linux-musl/usr"
BR2_TOOLCHAIN_BUILDROOT_MUSL=y
BR2_BINUTILS_VERSION_2_26_X=y
BR2_GCC_VERSION_6_X=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_GCC_ENABLE_LTO=y
BR2_GCC_ENABLE_GRAPHITE=y
EOF
make olddefconfig
make toolchain

So, it was triggered while building gcc itself, not after installation.

Regards.

[Bug c++/80458] New: [-Wreturn-type] false negative on missing return statement in a member function

[skvadrik at gmail dot com]

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

Bug ID: 80458
   Summary: [-Wreturn-type] false negative on missing return
statement in a member function
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: skvadrik at gmail dot com
  Target Milestone: ---

On the following example (missing return statement in a member function) GCC
emits no warning:

$ cat 1.cc
#include  // exit
extern void *f();
class Bag {
void *g() {
void *p = f();
if (!p) exit(1);
}
};
$ g++ -c -Wall -Wextra -O2 1.cc
$

If I comment out class definition, GCC emits warning:

$ cat 1.cc
#include  // exit
extern void *f();
//class Bag {
void *g() {
void *p = f();
if (!p) exit(1);
}
//};
$ g++ -c -Wall -Wextra -O2 1.cc
1.cc: In function ‘void* g()’:
1.cc:7:5: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
$

[Bug bootstrap/80455] -Werror=coverage-mismatch in profiledboostrap despite --disable-werror

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Isn't that a dup of PR69725, where Markus showed a diff for the file you
mentioned: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69725#c10 ?
I can take a look in the morning why the file changed in between stages.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[juergen.reuter at desy dot de]

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

--- Comment #51 from Jürgen Reuter  ---
(In reply to Thomas Koenig from comment #50)
> (In reply to Jürgen Reuter from comment #48)
> > (In reply to Thomas Koenig from comment #47)
> > > I'll try some bisection.
> > 
> > Did you get the full tarball running on an x86_64?
> 
> Yes, at least up to the point where I could "make check".
> 
> I would have gone faster if "make -j4" worked to compile
> the package in parallel :-)

Strange. We always do `make -j4`. What went wrong?

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[tkoenig at gcc dot gnu.org]

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

--- Comment #50 from Thomas Koenig  ---
(In reply to Jürgen Reuter from comment #48)
> (In reply to Thomas Koenig from comment #47)
> > I'll try some bisection.
> 
> Did you get the full tarball running on an x86_64?

Yes, at least up to the point where I could "make check".

I would have gone faster if "make -j4" worked to compile
the package in parallel :-)

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[tkoenig at gcc dot gnu.org]

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

--- Comment #49 from Thomas Koenig  ---
(In reply to Bijan Chokoufe from comment #39)

> Configure fails when I set FCFLAGS='-m32' with
> **
> configure: error: Fortran compiler does not support get_command_argument;
> configure aborted.
> configure: error:
> **

Can you compile a simple test program with -m32?

You may have to recompile gcc trunk for that; do not specify
--disable-multilib.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[juergen.reuter at desy dot de]

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

--- Comment #48 from Jürgen Reuter  ---
(In reply to Thomas Koenig from comment #47)
> I'll try some bisection.

Did you get the full tarball running on an x86_64?

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[tkoenig at gcc dot gnu.org]

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

--- Comment #47 from Thomas Koenig  ---
I'll try some bisection.

[Bug tree-optimization/80426] [7 Regression] wrong manipulation of range based on INT_MIN

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

  Attachment #41214|0   |1
is obsolete||

--- Comment #7 from Eric Botcazou  ---
Created attachment 41223
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41223=edit
Better fix

This directly computes the overflow, as done in the other cases.

[Bug other/78068] warning: implicit declaration of function ‘time’; did you mean ‘nice’? [-Wimplicit-function-declaration]

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-18
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Martin Sebor  ---
Confirmed with the simple test case below where GCC could conceivably avoid
issuing the hint also because the function cannot be used as a replacement for
the call to time().  As declared, nice takes an argument but the call to time()
doesn't pass one, and returns void but the call is used in a context where an
int is expected.

$ cat b.c && gcc -S -Wall b.c
void nice (int);

int foo (void)
{
  return time ();
}

b.c: In function ‘foo’:
b.c:5:10: warning: implicit declaration of function ‘time’; did you mean
‘nice’? [-Wimplicit-function-declaration]
   return time ();
  ^~~~
  nice

[Bug tree-optimization/80457] vectorizable_condition does not update the vectorizer cost model

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-18
 CC||rguenth at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org
   Target Milestone|--- |7.0
 Ever confirmed|0   |1

[Bug tree-optimization/80457] New: vectorizable_condition does not update the vectorizer cost model

[wschmidt at gcc dot gnu.org]

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

Bug ID: 80457
   Summary: vectorizable_condition does not update the vectorizer
cost model
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
  Target Milestone: ---

Discovered this oversight by accident while looking into a performance problem.
 vectorizable_condition needs to call vect_model_simple_cost when it determines
that vectorization is ok.  I'm testing a patch.

[Bug c++/80456] New: calling constexpr member function from volatile-qualified member function: error: ‘this’ is not a constant expression

[redi at gcc dot gnu.org]

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

Bug ID: 80456
   Summary: calling constexpr member function from
volatile-qualified member function: error: ‘this’ is
not a constant expression
   Product: gcc
   Version: 6.3.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This valid code is rejected:

struct A {
  static constexpr bool test() noexcept { return true; }

  void f() volatile {
constexpr bool b = test();
  }
};

void g() {
  A a;
  a.f();
}

vol.cc: In member function ‘void A::f() volatile’:
vol.cc:5:29: error: ‘this’ is not a constant expression
 constexpr bool b = test();
 ^

This complicates adding static assertions to std::atomic, as it has lots of
volatile-qualified member functions which need to enforce requirements.

[Bug lto/56891] Bad static analysis on fread() gives spurious warning on valid code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #1 from Martin Sebor  ---
I'm not able to reproduce any errors or warnings with any of GCC 5, 6, or 7. 
GCC 4.9 is no longer being maintained so I'm closing this report as
worksforsome.

[Bug fortran/80121] Memory leak with derived-type intent(out) argument

[janus at gcc dot gnu.org]

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

--- Comment #7 from janus at gcc dot gnu.org ---
(In reply to janus from comment #6)
> (In reply to janus from comment #5)
> > In trans-decl.c there is a function called 'init_intent_out_dt', which takes
> > care of deallocating the allocatable components of intent(out) derived-type
> > dummies. However, it has a comment saying:
> > 
> > /* Note: Allocatables are excluded as they are already handled
> >by the caller.  */
> 
> 
> Apparently 'gfc_conv_procedure_call' in trans-expr.c does that.

My feeling is that it would be a good idea to handle allocatable derived types
inside of the callee as well. I can see at least two advantages:
* It would avoid code duplication if the procedure is called several times.
* It would take some complexity out of gfc_conv_procedure_call, which is quite
a monster.

>From the technical side a treatment in the callee should be possible AFAICS. I
wonder why it is being done in the caller at all?

[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array

[tomaszkam at gmail dot com]

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

--- Comment #2 from Tomasz Kamiński  ---
Example of some real life safe-code (now raw allocations, STL container used),
that is leaking:
#include 
#include 
#include 

using namespace std;


struct Test {
string a;
string b;
};

Test make_test() {
vector strings {"123456789abcdef0"};
return Test {
strings.at(0),
strings.at(2) // throws; the destructor for a copy of strings.at(0) is
not called and memory leakds
};
}

int main() {
try {
Test test = make_test();
} catch (exception ) {
cerr << e.what() << endl;
}
}

Live code proving leaks: https://wandbox.org/permlink/GjjxFw9jAE9bfvyS

[Bug gcov-profile/67463] PGO (Profile Guided Optimizations) are not applied with gcc-5.2.1 (they are fine on gcc-4.9.x)

[shlomif at shlomifish dot org]

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

--- Comment #3 from Shlomi Fish  ---
Hi Martin, thanks for returning to me.

(In reply to Martin Liška from comment #2)
> Hi.
> 
> Sorry for waiting for some time. I tested your benchmark, where I had to
> disable tcmalloc as I can't link it with GCC 4.9, caused by C++ abi change.
> I also enhanced dump output to print total time spent (when function
> FCS_PRINT_FINISHED is called):
> 
> 4.9.4:
> Finished in 3.607
> Finished in 3.613
> Finished in 3.621
> Finished in 3.662
> 
> 5.4.0:
> Finished in 3.643
> Finished in 3.636
> Finished in 3.630
> Finished in 3.708
> 
> 6.3.0:
> Finished in 3.618
> Finished in 3.618
> Finished in 3.627
> Finished in 3.652
> 
> Tested on my desktop machine with Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz.
> That mentioned, I cannot see the regression, all numbers look within noise
> level.
> The regression you reported is very small (~3%) and it would be very hard to
> compare generated assembly to find different decisions made by GCC. Please
> try to
> test GCC 6 and possible GCC 7 (which will be released in couple of weeks)
> and if seen
> a significant regress, please reopen the issue.

Thanks! I'll try.

[Bug bootstrap/80447] Profiled LTO bootstrap fails on powerpc64le

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #9 from Martin Sebor  ---
I'm having trouble reproducing the warning due to the errors described in in
bug 80455.  But it's clear from the context of the warning that there is a path
to the memset call where the value of n is -1.  It's possible that the path is
not reachable and GCC doesn't see it.  The easiest thing to do then is to
assert that n cannot be negative.

In other similar reports, the warning would also disappear when the type of the
size argument changed to unsigned.  This is often because the signed size
argument starts out as unsigned (such as size_t) with some limited non-negative
range.  That range can be lost or turned into a positive-negative one in
unsigned to signed conversions.  When the positive-negative range becomes
subject to path splitting, it's not uncommon to see the negative (and
unreachable) path cause the warning.  Using an unsigned type for sizes helps
avoid this problem.

[Bug fortran/80361] [5/6/7 Regression] [OOP] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[janus at gcc dot gnu.org]

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

--- Comment #24 from janus at gcc dot gnu.org ---
(In reply to Jürgen Reuter from comment #23)
> Our code and testsuite now works without problems when using -fcheck=all. 
> Seems also no regressions on our side.

Thanks for the feedback!

[Bug tree-optimization/80443] [7 Regression] ICE on valid code at -O2 on x86_64-linux-gnu: in set_value_range, at tree-vrp.c:367

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/80443] [7 Regression] ICE on valid code at -O2 on x86_64-linux-gnu: in set_value_range, at tree-vrp.c:367

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 18 19:17:32 2017
New Revision: 246981

URL: https://gcc.gnu.org/viewcvs?rev=246981=gcc=rev
Log:
PR tree-optimization/80443
* tree-vrp.c (intersect_ranges): For signed 1-bit precision type,
instead of adding 1, subtract -1 and similarly instead of subtracting
1 add -1.

* gcc.c-torture/compile/pr80443.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr80443.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[tkoenig at gcc dot gnu.org]

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

--- Comment #46 from Thomas Koenig  ---
gcc version 7.0.1 20170227 (experimental) (GCC)

also fails.

[Bug middle-end/79665] gcc's signed (x*x)/200 is slower than clang's

[wilco at gcc dot gnu.org]

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

wilco at gcc dot gnu.org changed:

   What|Removed |Added

 CC||wilco at gcc dot gnu.org

--- Comment #14 from wilco at gcc dot gnu.org ---
(In reply to PeteVine from comment #13)
> Still, the 5% regression must have happened very recently. The fast gcc was
> built on 20170220 and the slow one yesterday, using the original patch. Once
> again, switching away from Cortex-A53 codegen restores the expected
> performance.

The issue is due to inefficient code generated for unsigned modulo:

umull   x0, w0, w4
umull   x1, w1, w4
lsr x0, x0, 32
lsr x1, x1, 32
lsr w0, w0, 6
lsr w1, w1, 6

It seems the Cortex-A53 scheduler isn't modelling this correctly. When I
manually remove the redundant shifts I get a 15% speedup. I'll have a look.

[Bug rtl-optimization/80357] [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #15 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug rtl-optimization/80357] [7 Regression] ICE in model_update_limit_points_in_group, at haifa-sched.c:1982 on powerpc64le-linux-gnu

[law at gcc dot gnu.org]

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

--- Comment #14 from Jeffrey A. Law  ---
Author: law
Date: Tue Apr 18 18:49:19 2017
New Revision: 246980

URL: https://gcc.gnu.org/viewcvs?rev=246980=gcc=rev
Log:
gcc/
PR rtl-optimization/80357
* haifa-sched.c (tmp_bitmap): New variable.
(model_recompute): Handle duplicate use records.
(alloc_global_sched_pressure_data): Initialize tmp_bitmap.
(free_global_sched_pressure_data): Free it.

gcc/testsuite/
PR rtl-optimization/80357
* gcc.c-torture/compile/pr80357.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr80357.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/haifa-sched.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/80455] -Werror=coverage-mismatch in profiledboostrap despite --disable-werror

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
The same error happens in both a powerpc64le build as well as on x86_64.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[juergen.reuter at desy dot de]

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

--- Comment #45 from Jürgen Reuter  ---
Looking into my backups, it seems that the revision 241975 from Nov 8, 2016 was
still working without the `volatile` hack. Then I upgraded in early February to
revision 245197 where the problem is already present. Unfortunately I cannot
narrow it down any further. Any smaller test case is incredibly difficult to
produce for us.

[Bug ipa/65972] ICE after applying a patch to enable verify_ssa with auto-pgo

[spop at gcc dot gnu.org]

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

--- Comment #9 from Sebastian Pop  ---
In the link in the previous comment, Richi has a similar patch as suggested by
Dehao pending review/test/commit: let's close this bug when Richi's patch lands
in trunk.

[Bug bootstrap/80455] New: -Werror=coverage-mismatch in profiledboostrap despite --disable-werror

[msebor at gcc dot gnu.org]

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

Bug ID: 80455
   Summary: -Werror=coverage-mismatch in profiledboostrap despite
--disable-werror
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Current top of trunk (GCC 7) configured with
--enable-languages=ada,all,c,c++,fortran,go,lto,objc,obj-c++
-with-build-config=bootstrap-lto --disable-werror fails in stagefeedback with
the following errors

get_d.c:412:1: error: the control flow of function ‘__gmpn_get_d’ does not
match its profile data (counter ‘arcs’) [-Werror=coverage-mismatch]
get_d.c:412:1: error: the control flow of function ‘__gmpn_get_d’ does not
match its profile data (counter ‘time_profiler’) [-Werror=coverage-mismatch]

A search through the build log for get_d.c and -Werror turns up nothing:

$ grep get_d\.c /build/gcc-trunk-profiledbootstrap/profiledbootstrap.log | grep
Werror
get_d.c:412:1: error: the control flow of function ‘__gmpn_get_d’ does not
match its profile data (counter ‘arcs’) [-Werror=coverage-mismatch]
get_d.c:412:1: error: the control flow of function ‘__gmpn_get_d’ does not
match its profile data (counter ‘time_profiler’) [-Werror=coverage-mismatch]

However, as pointed out in bug 32193, libgomp is still built with -Werror, so I
suspect the error is the result of that.

[Bug ipa/65972] ICE after applying a patch to enable verify_ssa with auto-pgo

[spop at gcc dot gnu.org]

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

--- Comment #8 from Sebastian Pop  ---
Yes please!
This patch also solves the problem I was chasing a week or so ago:

https://gcc.gnu.org/ml/gcc-patches/2017-04/msg00067.html

I also know that this is ICE-ing on a large proprietary project when I compile
it with autoFDO on gcc-5.x and 6.x releases.

[Bug middle-end/80422] [7 Regression] ICE on valid code at -O3 in 32-bit mode on x86_64-linux-gnu: in operator[], at vec.h:732

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
Fixed on the trunk.

[Bug middle-end/80422] [7 Regression] ICE on valid code at -O3 in 32-bit mode on x86_64-linux-gnu: in operator[], at vec.h:732

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Tue Apr 18 17:31:30 2017
New Revision: 246975

URL: https://gcc.gnu.org/viewcvs?rev=246975=gcc=rev
Log:
PR middle-end/80422
* cfgcleanup.c (try_crossjump_to_edge): Verify SRC1 and SRC2 have
predecessors after walking up the insn chain.

PR middle-end/80422
* gcc.c-torture/compile/pr80422.c: New test.

Added:
trunk/gcc/testsuite/gcc.c-torture/compile/pr80422.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgcleanup.c
trunk/gcc/testsuite/ChangeLog

[Bug target/68163] GCC on power8 does not issue the stxsspx instruction on power8

[meissner at gcc dot gnu.org]

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

--- Comment #2 from Michael Meissner  ---
Author: meissner
Date: Tue Apr 18 17:08:16 2017
New Revision: 246974

URL: https://gcc.gnu.org/viewcvs?rev=246974=gcc=rev
Log:
Add initial patch for pr 68163

Added:
branches/ibm/meissner-gcc8/gcc/testsuite/gcc.target/powerpc/pr68163.c
  - copied unchanged from r246956,
branches/ibm/meissner-work/gcc/testsuite/gcc.target/powerpc/pr68163.c
Modified:
branches/ibm/meissner-gcc8/gcc/ChangeLog.meissner
branches/ibm/meissner-gcc8/gcc/config/rs6000/rs6000.md
branches/ibm/meissner-gcc8/gcc/testsuite/ChangeLog.meissner

[Bug debug/80263] gcc's internal type "sizetype" leaks out as base type name in the DWARF info

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 18 16:58:48 2017
New Revision: 246973

URL: https://gcc.gnu.org/viewcvs?rev=246973=gcc=rev
Log:
PR debug/80263
* dwarf2out.c (modified_type_die): Try harder not to emit internal
sizetype type into debug info.

* gcc.dg/debug/dwarf2/pr80263.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/pr80263.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/dwarf2out.c
trunk/gcc/testsuite/ChangeLog

[Bug target/80099] ICE in rs6000_expand_vector_extract, at config/rs6000/rs6000.c:7450

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

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

--- Comment #4 from Michael Meissner  ---
Fixed in subversion id 246972.

[Bug target/80099] ICE in rs6000_expand_vector_extract, at config/rs6000/rs6000.c:7450

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
Author: meissner
Date: Tue Apr 18 16:41:06 2017
New Revision: 246972

URL: https://gcc.gnu.org/viewcvs?rev=246972=gcc=rev
Log:
[gcc]
2017-04-18  Michael Meissner  

PR target/80099
* config/rs6000/rs6000.c (rs6000_expand_vector_extract): Eliminate
unneeded test for TARGET_UPPER_REGS_SF.
* config/rs6000/vsx.md (vsx_extract_v4sf_var): Likewise.

[gcc/testsuite]
2017-04-18  Michael Meissner  

PR target/80099
* gcc.target/powerpc/pr80099-1.c: New test.
* gcc.target/powerpc/pr80099-2.c: Likewise.
* gcc.target/powerpc/pr80099-3.c: Likewise.
* gcc.target/powerpc/pr80099-4.c: Likewise.
* gcc.target/powerpc/pr80099-5.c: Likewise.


Added:
trunk/gcc/testsuite/gcc.target/powerpc/pr80099-1.c
trunk/gcc/testsuite/gcc.target/powerpc/pr80099-2.c
trunk/gcc/testsuite/gcc.target/powerpc/pr80099-3.c
trunk/gcc/testsuite/gcc.target/powerpc/pr80099-4.c
trunk/gcc/testsuite/gcc.target/powerpc/pr80099-5.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/rs6000/rs6000.c
trunk/gcc/config/rs6000/vsx.md
trunk/gcc/testsuite/ChangeLog

[Bug target/80433] [CRIS] ICE at -O2: unrecognized insn (post_inc on acr) building glibc sha512.c

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||law at redhat dot com
 Resolution|--- |FIXED

--- Comment #2 from Jeffrey A. Law  ---
I fixed this about a week ago.   I did a build of cris-linux and crisv32-linux
for binutils, gcc and glibc trunks (Apr 17).  I did cris-elf and crisv32-elf
binutils, gcc & newlib over the weekend as well.

[Bug c/53119] -Wmissing-braces wrongly warns about universal zero initializer {0}

[vincent-gcc at vinc17 dot net]

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

Vincent Lefèvre  changed:

   What|Removed |Added

 CC||vincent-gcc at vinc17 dot net

--- Comment #25 from Vincent Lefèvre  ---
On the same subject, I've reported a new bug: PR 80454.

[Bug other/71250] -Wmissing-field-initializers documentation is incomplete

[vincent-gcc at vinc17 dot net]

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

--- Comment #5 from Vincent Lefèvre  ---
(In reply to Alexander Monakov from comment #4)
> Note that that's a different warning: -Wmissing-braces, not
> -Wmissing-field-initializers.  I believe it would be nice to fix, but
> handling of universal zero initializers in -Wmissing-braces should be a
> separate issue.

I've just reported PR 80454 (it seems that not everything was fixed in PR
53119).

[Bug c/80454] New: -Wmissing-braces wrongly warns about universal zero initializer {0}

[vincent-gcc at vinc17 dot net]

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

Bug ID: 80454
   Summary: -Wmissing-braces wrongly warns about universal zero
initializer {0}
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

Consider:

typedef union { char c; int i; } union_t;

struct { struct { int a; long b; } x; int y; } t = { { 0 }, 1 };

struct { struct { union_t a; long b; } x; int y; } u = { { 0 }, 1 };

As expected, I do not get a warning for the first initialization. But with
Debian's GCC 6.3.0 20170415 (and previous versions GCC 4.9 and 5), I get a
warning for the second one:

tst.c:5:56: warning: missing braces around initializer [-Wmissing-braces]
 struct { struct { union_t a; long b; } x; int y; } u = { { 0 }, 1 };
^
tst.c:5:56: note: (near initialization for ‘u’)

(pthread_rwlock_t from  is such a union type on my machine, so that
there's the same problem with this.)

It seems that not everything was fixed in PR 53119.

[Bug libstdc++/80451] [6/7 Regression] return implicit type conversion to std::experimental::optional does not compile

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Денис Крыськов from comment #8)
> If I understand correctly,
> http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579 is not
> implemented in gcc 5.4 and 6.3. Which means some code runs slower than is
> should. To be sure that a fast constructor is called, I need to delete slow
> constructor. 
> 
> Which results in bloated code (each and every class should contain delete
> statement).

No, if you define a move constructor then the implicitly-declared copy
constructor is automatically deleted. So if you think explicitly deleting it is
"bloated code" then simply don't do that and let the compiler implicitly delete
it for you.

> If that's not serious, that's unpleasant.

So do "return std::move(b);" as was necessary before 2014 anyway.

This is a bug, and it will be fixed, but there's no need to exaggerate its
seriousness.

[Bug sanitizer/80444] -fcompare-debug failures with -fsanitize-coverage=trace-pc

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug other/71250] -Wmissing-field-initializers documentation is incomplete

[amonakov at gcc dot gnu.org]

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

--- Comment #4 from Alexander Monakov  ---
Note that that's a different warning: -Wmissing-braces, not
-Wmissing-field-initializers.  I believe it would be nice to fix, but handling
of universal zero initializers in -Wmissing-braces should be a separate issue.

[Bug debug/80453] [7 Regression] another compare-debug failure

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf  ---
git bisect points to r241329:

commit 34b94be25f231249fa213152feb6b7208b4c0d13
Author: rguenth 
Date:   Wed Oct 19 08:39:55 2016 +

2016-10-19  Richard Biener  

* domwalk.c (dom_walker::walk): Use RPO order.

[Bug other/71250] -Wmissing-field-initializers documentation is incomplete

[vincent-gcc at vinc17 dot net]

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

--- Comment #3 from Vincent Lefèvre  ---
However, it seems that GCC doesn't support the { 0 } idiom in all cases. For
instance:

#include 

struct { struct { int a; long b; } x; int y; } s = { { 1 }, 1 };

struct { struct { int a; long b; } x; int y; } t = { { 0 }, 1 };

struct { struct { pthread_rwlock_t a; long b; } x; int y; } u = { { 0 }, 1 };

The first structure initialization triggers the warning as expected:

tst.c:3:17: warning: missing initializer for field ‘b’ of ‘struct ’
-Wmissing-field-initializers]
 struct { struct { int a; long b; } x; int y; } s = { { 1 }, 1 };
 ^
tst.c:3:31: note: ‘b’ declared here
 struct { struct { int a; long b; } x; int y; } s = { { 1 }, 1 };
   ^

The second one doesn't trigger any warning due to the use of the idiom.

But the third one triggers the following warning, though the same idiom is
used:

tst.c:7:65: warning: missing braces around initializer [-Wmissing-braces]
 struct { struct { pthread_rwlock_t a; long b; } x; int y; } u = { { 0 }, 1 };
 ^
tst.c:7:65: note: (near initialization for ‘u’)

[Bug fortran/80361] [5/6/7 Regression] [OOP] bogus recursive call to nonrecursive procedure with -fcheck=recursion

[juergen.reuter at desy dot de]

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

--- Comment #23 from Jürgen Reuter  ---
Our code and testsuite now works without problems when using -fcheck=all. 
Seems also no regressions on our side. Thanks for the quick fix.

[Bug driver/56469] The .gcno file being generated is not cleaned up after gcc exits with an error.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-18
 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 #1 from Martin Liška  ---
Confirmed, I've got patch for that.

[Bug target/74563] [6/7 regression] Classic MIPS16 (non-MIPS16e) function return broken

[law at redhat dot com]

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

--- Comment #7 from Jeffrey A. Law  ---
I was essentially thinking the same WRT a proposed patch.


My concern is whether something might be passing in an unexpected rtx for
operands[0] and whether or not we can get into the other pattern for MIPS16.

So I've got a series of builds running with instrumentation to see if any of
the cases I'm worried about triggers during a build of the usual runtime
libraries.

[Bug debug/57737] -fopenmp + -femit-struct-debug-reduced/baseonly = internal compiler error: Segmentation fault

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
I can confirmed that it used to ICE for old releases. However, 4.9.0+ works
fine, as well as all active branches. Thus closing as resolved.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[bijan at chokoufe dot com]

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

--- Comment #44 from Bijan Chokoufe  ---
Created attachment 41222
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41222=edit
Diff of generalized assembly using extended precision with and without volatile

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[bijan at chokoufe dot com]

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

--- Comment #43 from Bijan Chokoufe  ---
I actually made the same mistake when generating the diffs. I attach the
correct diff when --with-precision=extended is given to configure. Similar
contents though, as far as I can judge. Strangely, the code without volatile is
overall larger:

-rw-r--r-- 1 root root 1456592 Apr 18 14:43 shower_core.s
-rw-r--r-- 1 root root 1450362 Apr 18 14:20 shower_core_volatile.s

[Bug other/53742] bad assembler output when compiling with LTO and PGO

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Liška  ---
Is the issue still valid?

[Bug sanitizer/80444] -fcompare-debug failures with -fsanitize-coverage=trace-pc

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 18 15:02:06 2017
New Revision: 246971

URL: https://gcc.gnu.org/viewcvs?rev=246971=gcc=rev
Log:
PR sanitizer/80444
* sancov.c (sancov_pass): Use gsi_start_nondebug_after_labels_bb
instead of gsi_after_labels.

* gcc.dg/sancov/pr80444.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/sancov/pr80444.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/sancov.c
trunk/gcc/testsuite/ChangeLog

[Bug ipa/65972] ICE after applying a patch to enable verify_ssa with auto-pgo

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Liška  ---
Looks the patch hasn't been applied to trunk. Should I test it and send to ML?

[Bug gcov-profile/80435] Expose __gcov_flush to allow developers to dump coverage numbers on demand

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Jan Hubicka  ---
The patch is preapproved (for release branch, too, assuming that RMs agree).
Thanks!

[Bug gcov-profile/55121] ICE in if-conversion with PGO (ARM)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #17 from Martin Liška  ---
No response, it's quite old issue. Thus closing as fixed.

[Bug c++/53727] ICE when compiling firefox with PGO and LTO (not OOM)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #12 from Martin Liška  ---
Closing as it's more than 5 years and no recent error has been seen.

[Bug c++/53743] ICE when compiling firefox with PGO and LTO

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Liška  ---
It's quite some time and recent regression with the same symptoms has been
reported. Thus closing as fixed.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[tkoenig at gcc dot gnu.org]

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

--- Comment #42 from Thomas Koenig  ---
Using ./configure --with-precision=extended

results in

checking whether gfortran supports c_float128 (a gfortran extension)... yes
checking the requested floating point precision... extended
configure: error:
***
configure: error: the requested default real kind 'extended' is not available
in this environment
configure: error:
***

[Bug middle-end/67463] PGO (Profile Guided Optimizations) are not applied with gcc-5.2.1 (they are fine on gcc-4.9.x)

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||marxin at gcc dot gnu.org
 Resolution|--- |WORKSFORME

--- Comment #2 from Martin Liška  ---
Hi.

Sorry for waiting for some time. I tested your benchmark, where I had to
disable tcmalloc as I can't link it with GCC 4.9, caused by C++ abi change. I
also enhanced dump output to print total time spent (when function
FCS_PRINT_FINISHED is called):

4.9.4:
Finished in 3.607
Finished in 3.613
Finished in 3.621
Finished in 3.662

5.4.0:
Finished in 3.643
Finished in 3.636
Finished in 3.630
Finished in 3.708

6.3.0:
Finished in 3.618
Finished in 3.618
Finished in 3.627
Finished in 3.652

Tested on my desktop machine with Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz.
That mentioned, I cannot see the regression, all numbers look within noise
level.
The regression you reported is very small (~3%) and it would be very hard to
compare generated assembly to find different decisions made by GCC. Please try
to
test GCC 6 and possible GCC 7 (which will be released in couple of weeks) and
if seen
a significant regress, please reopen the issue.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[tkoenig at gcc dot gnu.org]

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

--- Comment #41 from Thomas Koenig  ---
Created attachment 41221
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41221=edit
Config log for PowerPC

Here's the config.log for PowerPC.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[dominiq at lps dot ens.fr]

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

--- Comment #40 from Dominique d'Humieres  ---
> You have to
>
>  ./configure --with-precision=extended

I don't think this works on powerpc: no 80-bit fp.

[Bug middle-end/79788] ICE in expand_expr_real_2, at expr.c:9557

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug middle-end/80375] [5/6 Regression] ICE in expand_expr_real_2, at expr.c:9382 with -ftrapv

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
Summary|[5/6/7 Regression] ICE in   |[5/6 Regression] ICE in
   |expand_expr_real_2, at  |expand_expr_real_2, at
   |expr.c:9382 with -ftrapv|expr.c:9382 with -ftrapv

--- Comment #5 from Jakub Jelinek  ---
Fixed on the trunk.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[bijan at chokoufe dot com]

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

--- Comment #39 from Bijan Chokoufe  ---
(In reply to Thomas Koenig from comment #38)
> (In reply to Bijan Chokoufe from comment #37)
> > Concerning your PowerPC compilation: Have you set FCLAGS yourself
> 
> No, I didn't.; I just ran "./configure" and "make -j16".
> This is why I suspect a target issue.  Of course, it could also
> be that there are different inlining heuristics on PowerPC.
> 

You have to

  ./configure --with-precision=extended

to reproduce the FAIL. Also add the config.log so we can exclude that any
environment variables are influencing the configure. In principle, it would be
not too surprising if you can't reproduce it on PowerPC as it also does not
happen when -O0 is used and I would assume that optimizations for different
architectures are different.

Configure fails when I set FCFLAGS='-m32' with
**
configure: error: Fortran compiler does not support get_command_argument;
configure aborted.
configure: error:
**

[Bug other/71250] -Wmissing-field-initializers documentation is incomplete

[amonakov at gcc dot gnu.org]

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

--- Comment #2 from Alexander Monakov  ---
Thanks. Basically the documentation can be enhanced to mention that GCC
shouldn't (and wouldn't) warn for universal zero initializer, which is '{0}' in
C and just '{}' in C++. After a day or so I can submit a patch with an extra
sentence after the short example, like the following:

However, for empty initializers in C++ and '{0}' initializers in C,
no warning is issued, because those are the idiomatic ways to express
zero initialization of the complete object.

[Bug libstdc++/80451] [6/7 Regression] return implicit type conversion to std::experimental::optional does not compile

[krisk0.2017.02.27 at protonmail dot com]

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

--- Comment #8 from Денис Крыськов  ---
If I understand correctly,
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1579 is not
implemented in gcc 5.4 and 6.3. Which means some code runs slower than is
should. To be sure that a fast constructor is called, I need to delete slow
constructor. 

Which results in bloated code (each and every class should contain delete
statement).

If that's not serious, that's unpleasant.

[Bug debug/80453] New: [7 Regression] another compare-debug failure

[trippels at gcc dot gnu.org]

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

Bug ID: 80453
   Summary: [7 Regression] another compare-debug failure
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 41220
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41220=edit
unreduced testcase

markus@x4 /tmp % g++ --save-temps --param ggc-min-expand=20 --param
ggc-min-heapsize=0 -c -fcompare-debug -Woverloaded-virtual -O3 -fno-exceptions
-fno-rtti CheckerManager.ii
g++: error: CheckerManager.ii: -fcompare-debug failure (length)

markus@x4 /tmp % diff -u CheckerManager.gkd CheckerManager.gk.gkd   
--- CheckerManager.gkd  2017-04-18 15:54:16.758998434 +0200 
+++ CheckerManager.gk.gkd   2017-04-18 15:54:30.302038615 +0200 
@@ -56701,7 +56701,7 @@ 
 (reg:DI 41 r12))
"/home/trippels/llvm/tools/clang/lib/StaticAnalyzer/Core/CheckerManager.cpp":171#
{*pushdi2_rex64}
  (expr_list:REG_DEAD (reg:DI 41 r12)   
 (nil)))
-(insn # 0 0 2 (set (reg/v/f:DI 42 r13 [orig:180 Src ] [180]) 
+(insn # 0 0 2 (set (reg/v/f:DI 42 r13 [orig:184 Src ] [184])   
 (reg:DI 2 cx [ Src ]))
"/home/trippels/llvm/tools/clang/lib/StaticAnalyzer/Core/CheckerManager.cpp":171#
{*movdi_internal}
  (expr_list:REG_DEAD (reg:DI 2 cx [ Src ]) 
 (nil)))
@@ -56713,11 +56713,11 @@  
   
(reg:DI 3 bx))
"/home/trippels/llvm/tools/clang/lib/StaticAnalyzer/Core/CheckerManager.cpp":171#
{*pushdi2_rex64} 
  (expr_list:REG_DEAD (reg:DI 3 bx) 
 (nil)))   
   
   -(insn # 0 0 2 (set (reg:SI 6 bp [orig:178 isPreVisit ]
[178])   
+(insn # 0 0 2 (set (reg:SI 6 bp [orig:182 isPreVisit ] [182])  
 (reg:SI 4 si [ isPreVisit ]))
"/home/trippels/llvm/tools/clang/lib/StaticAnalyzer/Core/CheckerManager.cpp":171#
{*movsi_internal}
  (expr_list:REG_DEAD (reg:SI 4 si [ isPreVisit ])  
 (nil)))
-(insn:TI # 0 0 2 (set (reg/v/f:DI 4 si [orig:181 S ] [181])   
+(insn:TI # 0 0 2 (set (reg/v/f:DI 4 si [orig:185 S ] [185])
 (reg:DI 37 r8 [ S ]))
"/home/trippels/llvm/tools/clang/lib/StaticAnalyzer/Core/CheckerManager.cpp":171#
{*movdi_internal}
  (nil))
 (insn/f:TI # 0 0 2 (parallel [ 
@@ -56733,7 +56733,7 @@
   
(const_int -424 [0xfe58]))) 
 (nil   
 (note # 0 0 NOTE_INSN_PROLOGUE_END)   
   
   -(insn:TI # 0 0 2 (set (reg/v:QI 0 ax [orig:183 WasInlined ]
[183])  
+(insn:TI # 0 0 2 (set (reg/v:QI 0 ax [orig:187 WasInlined ] [187]) 
 (mem/c:QI (plus:DI (reg/f:DI 7 sp) 
 (const_int 480 [0x1e0])) [ WasInlined+0 S1 A64]))
"/home/trippels/llvm/tools/clang/lib/StaticAnalyzer/Core/CheckerManager.cpp":171#
{*movqi_internal} 
  (nil))
...

[Bug target/79242] ICE in simplify_subreg, at simplify-rtx.c:6029

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The problem is that for __builtin_*_overflow{,_p} and/or -fsanitize=undefined
and/or for the automatic discovery of constructs checking for overflow uses
complex integer types and apparently that is just completely broken on msp430
and perhaps on other targets that have other similar partial int modes, I think
that might be avr, bfin and m32c.

Try a simple testcase like:
typedef _Complex __int20 C;

C
foo (C x, C y)
{
  return x + y;
}

which ICEs the same.

[Bug tree-optimization/69991] missed tail merge optimization

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-18
 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 #1 from Martin Liška  ---
Confirmed. I'll take a look at the in GCC 8.

[Bug other/71250] -Wmissing-field-initializers documentation is incomplete

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-18
 CC||amonakov at gcc dot gnu.org,
   ||manu at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Adding to CC authors of the warning.

[Bug driver/79637] missing documentation for PARAM_MAX_FSM_THREAD_LENGTH

[spop at gcc dot gnu.org]

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

--- Comment #3 from Sebastian Pop  ---
As to why we call it a "finite state automaton" jump threading, that is because
this transform shows to be useful when the switch statement in the previous
example is contained in a loop, which is the way most people use to implement a
parser, or a finite state machine.  Some of these automata are implementing
state transitions by setting the next state in one of the cases.  To continue
the example from the previous comment, here is how a two state machine looks
like:

c = 1;
while (1)
{
  switch (c)
{
case 1:
  c = 5;
  break;
case 5:
  c = 1;
  break;
}
}

and after jump threading, it would look like this:

c = 1;
label1:
  c = 5;
  goto label2;

label2:
  c = 1;
  goto label1;

which is much faster than having to take the loop back-edge + jump from switch
to case.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[tkoenig at gcc dot gnu.org]

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

--- Comment #38 from Thomas Koenig  ---
(In reply to Bijan Chokoufe from comment #37)
> (In reply to Thomas Koenig from comment #35)
> 
> > [tkoenig@gcc1-power7 shower]$ pwd
> > /home/tkoenig/whizard-2.4.1/src/shower
> > [tkoenig@gcc1-power7 shower]$ grep -i volatile *.f90
> > [tkoenig@gcc1-power7 shower]$ 
> > 
> > Did you run a diff on the generated assembly with and without
> > the VOLATILE statement?  You can use the -save-temps option for that.
> 
> I generated the .s files with -save-temps with and without volatile
> attributes. The diff is attached. I can say the instructions are different
> but that's about it.

I looked at the diffs, but for me also, nothing stands out.

> Concerning your PowerPC compilation: Have you set FCLAGS yourself

No, I didn't.; I just ran "./configure" and "make -j16".
This is why I suspect a target issue.  Of course, it could also
be that there are different inlining heuristics on PowerPC.

You could add "-m32" to the compiler flags; this would
build a 32-bit binary.  Obviously, you would have to rebuild
the whole source tree.  What does that do?

Additionally, if it is not possible to generate a smaller failing test case,
the next step would be to see which revision failed first.

What is the latest version of the compiler that still works?
Specifically, did you ever try this with an earlier version of
gcc 7 trunk?

[Bug other/72815] libmpx on i386

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Hi. The file you are mentioning (libmpx/mpxrt/mpxrt.h) is not installed by GCC
and for internal purpose only. Can you please specify how you use the header
file?

[Bug target/79453] Translator unfriendly string in avr_pgm_check_var_decl

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Priority|P3  |P5
 Status|UNCONFIRMED |RESOLVED
   Keywords||diagnostic
  Component|translation |target
 CC||gjl at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |6.4
   Severity|normal  |minor

--- Comment #1 from Georg-Johann Lay  ---
Fixed in r246966 and r246967

[Bug middle-end/70140] Inefficient expansion of __builtin_mempcpy

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-18
 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 #1 from Martin Liška  ---
I'll do that for GCC8.

[Bug driver/79637] missing documentation for PARAM_MAX_FSM_THREAD_LENGTH

[spop at gcc dot gnu.org]

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

--- Comment #2 from Sebastian Pop  ---
Here is what I see in doc/invoke.texi:

@item max-fsm-thread-path-insns
Maximum number of instructions to copy when duplicating blocks on a
finite state automaton jump thread path.  The default is 100.

@item max-fsm-thread-length
Maximum number of basic blocks on a finite state automaton jump thread
path.  The default is 10.

@item max-fsm-thread-paths
Maximum number of new jump thread paths to create for a finite state
automaton.  The default is 50.

I think these parameters are quite technical.  The rule is that all the magic
constants should have a param instead of hard coding them in the code, so they
get exposed to the users of the compiler that way.

Roland, I would have liked to point you to a paper that describes the algorithm
for backwards jump-threading, although we have not wrote one yet.  Jeff, I
think it would be good if I take the time to write that paper, and I will ask
you, James, and Brian to co-sign the paper.

Here is a short description of how the backwards jump-threading works:

We start by looking for a switch or condition statement of the form
"switch(c)". Then, following the SSA definitions backwards from "c" to its
definition, until  a place in the program where the condition "c" is statically
known at compile time. To make the example simple, let's say we reach a
statement that sets "c = 5".  With that information in hand, we create a new
path that starts from the basic block that sets "c = 5" and ends in the target
block of the switch "case 5:".  This is done by duplicating all the basic
blocks on the path from "c = 5" to the target of the now known value of the
condition.
max-fsm-thread-length is the bound on the number of basic blocks on that path,
such that we do not increase too much the code size of the program.

[Bug middle-end/70897] Confused branch predictors

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-04-18
 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 #1 from Martin Liška  ---
Confirmed, I'll take a look at these predictors in GCC8.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[bijan at chokoufe dot com]

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

--- Comment #37 from Bijan Chokoufe  ---
(In reply to Thomas Koenig from comment #35)

> [tkoenig@gcc1-power7 shower]$ pwd
> /home/tkoenig/whizard-2.4.1/src/shower
> [tkoenig@gcc1-power7 shower]$ grep -i volatile *.f90
> [tkoenig@gcc1-power7 shower]$ 
> 
> Did you run a diff on the generated assembly with and without
> the VOLATILE statement?  You can use the -save-temps option for that.

I generated the .s files with -save-temps with and without volatile attributes.
The diff is attached. I can say the instructions are different but that's about
it.

Concerning your PowerPC compilation: Have you set FCLAGS yourself and if so
have you included -O2? That other tests are failing is not too suprising and
doesn't have to be a major problem as the test suite is not numerically
waterproof (and partly can't be). The issue with memcpy looks like a bug
though.

[Bug driver/69754] --print-{file,prog}-name don't work for liblto_plugin.so

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
Confirmed, can you please send the patch to mailing list
gcc-patc...@gcc.gnu.org? Looks it's overlooked here.

[Bug c++/79435] [7 Regression] ICE on invalid C++ code (with member access into an incomplete type) on x86_64-linux-gnu: Segmentation fault

[gjl at gcc dot gnu.org]

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

--- Comment #6 from Georg-Johann Lay  ---
Author: gjl
Date: Tue Apr 18 13:23:01 2017
New Revision: 246967

URL: https://gcc.gnu.org/viewcvs?rev=246967=gcc=rev
Log:
gcc/
Backport from 2017-04-18 trunk r246966.
PR target/79435
* config/avr/avr.c (intl.h): Include it.
(avr_pgm_check_var_decl) [reason]: Wrap diagnostic snippets into _().


Modified:
branches/gcc-6-branch/gcc/ChangeLog
branches/gcc-6-branch/gcc/config/avr/avr.c

[Bug libstdc++/80448] #include fails with Clang 5.0

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
Apparently related to CWG1351  and solved by
removing 'noexcept' from the ctor.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

[bijan at chokoufe dot com]

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

--- Comment #36 from Bijan Chokoufe  ---
Created attachment 41219
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41219=edit
Diff of generalized assembly with and without volatile

[Bug middle-end/79788] ICE in expand_expr_real_2, at expr.c:9557

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 18 13:15:46 2017
New Revision: 246965

URL: https://gcc.gnu.org/viewcvs?rev=246965=gcc=rev
Log:
PR middle-end/79788
PR middle-end/80375
* c-common.c (c_common_type_for_mode): Don't handle
widest_*_literal_type_node here.
c_common_signed_or_unsigned_type): Likewise.
(c_common_nodes_and_builtins): Set widest_*_literal_type_node
to *intTI_type_node or *intDI_type_node depending on whether
TImode is supported by the target or not.

* gcc.dg/pr79788-1.c: New test.
* gcc.dg/pr79788-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr79788-1.c
trunk/gcc/testsuite/gcc.dg/pr79788-2.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

[Bug middle-end/80375] [5/6/7 Regression] ICE in expand_expr_real_2, at expr.c:9382 with -ftrapv

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Tue Apr 18 13:15:46 2017
New Revision: 246965

URL: https://gcc.gnu.org/viewcvs?rev=246965=gcc=rev
Log:
PR middle-end/79788
PR middle-end/80375
* c-common.c (c_common_type_for_mode): Don't handle
widest_*_literal_type_node here.
c_common_signed_or_unsigned_type): Likewise.
(c_common_nodes_and_builtins): Set widest_*_literal_type_node
to *intTI_type_node or *intDI_type_node depending on whether
TImode is supported by the target or not.

* gcc.dg/pr79788-1.c: New test.
* gcc.dg/pr79788-2.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr79788-1.c
trunk/gcc/testsuite/gcc.dg/pr79788-2.c
Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-common.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/79435] [7 Regression] ICE on invalid C++ code (with member access into an incomplete type) on x86_64-linux-gnu: Segmentation fault

[gjl at gcc dot gnu.org]

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

--- Comment #5 from Georg-Johann Lay  ---
Author: gjl
Date: Tue Apr 18 13:15:47 2017
New Revision: 246966

URL: https://gcc.gnu.org/viewcvs?rev=246966=gcc=rev
Log:
gcc/
PR target/79435
* config/avr/avr.c (intl.h): Include it.
(avr_pgm_check_var_decl) [reason]: Wrap diagnostic snippets into _().


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

[Bug libstdc++/80451] [6/7 Regression] return implicit type conversion to std::experimental::optional does not compile

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Денис Крыськов from comment #6)
> Seems like a serious bug in compiler.

No, it's just an incomplete implementation of a new feature added in C++14.