[Bug c/70389] uint_16t left shift with -Wconversion produces incorrect warning

[bobgmeyers at muchomail dot com]

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

--- Comment #2 from Bob Meyers  ---
Does the most recent C spec actually say that short unsigned ints should be
promoted to signed ints prior to a left shift? (But somehow "x++" just
increments the short unsigned int x with no such implicit conversion, and so
does not trigger the same -Wconversion error.) That seems inconsistent, but if
it's true, then this is correct behavior. Thanks for the comment.

[Bug fortran/69524] [6 Regression] [F08] Compiler segfaults on "module subroutine"

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #10 from Jeffrey A. Law  ---
Fixed on the trunk a couple weeks ago.

[Bug fortran/70031] Error in recursive module subroutine declaration if declared as "module recursive"

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #3 from Jeffrey A. Law  ---
Fixed on the trunk a couple weeks ago.

[Bug target/69331] [6 regression] FAIL: 20_util/shared_ptr/thread/default_weaktoshared.cc execution test

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P4  |P3
 CC||law at redhat dot com

--- Comment #7 from Jeffrey A. Law  ---
Bumping up to P3 given it's showing up on multiple targets.

[Bug target/70319] [6 Regression] FAIL: gcc.dg/sso/q2.c -O1 -fno-inline execution test

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #14 from Jeffrey A. Law  ---
Fixed by John's commit on the trunk.

[Bug libstdc++/70411] Stack overflow with std::regex_match

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

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

--- Comment #2 from Tim Shen  ---
This is a known issue. I have a plan to fix it, but it's not going to be in GCC
6.

Thanks for reporting!

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

[Bug libstdc++/61582] C++11 regex memory corruption

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

 CC||bisqwit at iki dot fi

--- Comment #18 from Tim Shen  ---
*** Bug 70411 has been marked as a duplicate of this bug. ***

[Bug c++/64372] [DR1560] Gratuitous lvalue-to-rvalue conversion in conditional-expression with throw-expression operand

[hs at xmission dot com]

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

hs  changed:

   What|Removed |Added

 CC||hs at xmission dot com

--- Comment #8 from hs  ---
I wanted to bump this bug and supply a simpler test-case:

void blah(int&) {}

int main() {
int i{};
blah(true ? i : throw);
}


result with gcc 6.0:

prog.cc: In function 'int main()':
prog.cc:6:15: error: invalid initialization of non-const reference of type
'int&' from an rvalue of type 'int'
 blah(true ? i : throw 0);
  ~^
prog.cc:2:6: note:   initializing argument 1 of 'void blah(int&)'
 void blah(int&) {}
  ^~~~

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

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

--- Comment #20 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #19)
> Created attachment 38100 [details]
> Another patch with correct rounding
> 
> > While I think the handling of nafter < 0 is correct, it is probably
> > a too big hammer since the expected output should be all zeroes.
> 
> The attached patch does exactly that.

Nice work!

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #11 from Jeffrey A. Law  ---
Fixed by rth's patch which I committed to the trunk.

[Bug target/70120] [6 Regression][aarch64] -g causes Assembler messages: Error: unaligned opcodes detected in executable segment

[law at gcc dot gnu.org]

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

--- Comment #10 from Jeffrey A. Law  ---
Author: law
Date: Fri Mar 25 23:37:13 2016
New Revision: 234486

URL: https://gcc.gnu.org/viewcvs?rev=234486=gcc=rev
Log:
2016-03-25  Richard Henderson  

PR target/70120
* config/aarch64/aarch64.c (aarch64_asm_output_pool_epilogue): New.
* config/aarch64/aarch64-protos.h: Declare it.
* config/aarch64/aarch64.h (ASM_OUTPUT_POOL_EPILOGUE): New.

PR target/70120
* gcc.target/aarch64/pr70120-1.c: New.
* gcc.target/aarch64/pr70120-2.c: New.
* gcc.target/aarch64/pr70120-3.c: New.

Added:
trunk/gcc/testsuite/gcc.target/aarch64/pr70120-1.c
trunk/gcc/testsuite/gcc.target/aarch64/pr70120-2.c
trunk/gcc/testsuite/gcc.target/aarch64/pr70120-3.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/aarch64/aarch64-protos.h
trunk/gcc/config/aarch64/aarch64.c
trunk/gcc/config/aarch64/aarch64.h
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/68695] [6 Regression] Performance regression related to ssa patch / ifcvt

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P1  |P2
 CC||law at redhat dot com

--- Comment #24 from Jeffrey A. Law  ---
I think one could easily argue here that the only reason we got good code
before Alex's change is because the copyrename pass was buggy.

Given something like this:

  # i_1 = PHI 

Where x & a are parameters and i is a local, all of type int.  The copyrename
pass would ignore the fact that x & a were promoted to DImode while i was
SImode

Alex's work exposed this as problematical in general and the suggested fix was
to not coalesce with the promoted modes were different.

I don't think this deserves to be a release blocker, but I do think we can
continue to look at either improving things on the RTL side, or finding a safe
set of cases where we can coalesce even when the promotions are different.

[Bug lto/70415] New: -Wa options should be passed to LTO

[vincent.riviere at freesbee dot fr]

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

Bug ID: 70415
   Summary: -Wa options should be passed to LTO
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent.riviere at freesbee dot fr
  Target Milestone: ---
Target: m68k-elf

Basically, options specified with -Wa should be used in final LTO step.
Currently, they are not passed to LTO, this can break inline assembly.

Concretely, LTO fails if inline assembly requires gas
--register-prefix-optional option.

Testcase:

$ cat bug.c
void _start(void)
{
asm("clr.l d0"); /* Note the absence of % in front of d0 */
}

$ m68k-elf-gcc -nostartfiles -nodefaultlibs -Wa,--register-prefix-optional
bug.c -o bug
# This works

$ m68k-elf-gcc -nostartfiles -nodefaultlibs -Wa,--register-prefix-optional
bug.c -o bug -flto
/tmp/ccQVzOtj.ltrans0.ltrans.o: In function `_start':
:(.text+0x6): undefined reference to `d0'
collect2: error: ld returned 1 exit status

If we add -v on the command line, we can see that --register-prefix-optional is
not passed to "as" when for the LTO pass. While it should.

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[dominiq at lps dot ens.fr]

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

--- Comment #19 from Dominique d'Humieres  ---
Created attachment 38100
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38100=edit
Another patch with correct rounding

> While I think the handling of nafter < 0 is correct, it is probably
> a too big hammer since the expected output should be all zeroes.

The attached patch does exactly that.

[Bug c++/55004] [meta-bug] constexpr issues

[jason at gcc dot gnu.org]

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

Bug 70353 Summary: [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr 
function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70353

   What|Removed |Added

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

[Bug c++/64266] Can GCC produce local mergeable symbols for *.__FUNCTION__ and *.__PRETTY_FUNCTION__ functions?

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed for GCC 6.

[Bug c++/70353] [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||6.0
 Resolution|--- |FIXED
  Known to fail|6.0 |

--- Comment #13 from Jason Merrill  ---
Fixed for 6, but the patch isn't really suitable for backporting since it's a
change in behavior.  Since 4.9 didn't accept the code, I'm going to close this.

[Bug c++/70353] [5/6 regression] ICE on __PRETTY_FUNCTION__ in a constexpr function

[jason at gcc dot gnu.org]

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

--- Comment #12 from Jason Merrill  ---
Author: jason
Date: Fri Mar 25 21:29:26 2016
New Revision: 234484

URL: https://gcc.gnu.org/viewcvs?rev=234484=gcc=rev
Log:
PR c++/64266
PR c++/70353
Core issue 1962
* decl.c (cp_fname_init): Decay the initializer to pointer.
(cp_make_fname_decl): Set DECL_DECLARED_CONSTEXPR_P,
DECL_VALUE_EXPR, DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P.
Don't call cp_finish_decl.
* pt.c (tsubst_expr) [DECL_EXPR]: Set DECL_VALUE_EXPR,
DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P.  Don't call cp_finish_decl.
* constexpr.c (cxx_eval_constant_expression) [VAR_DECL]:
Handle DECL_VALUE_EXPR.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-__func__2.C
trunk/gcc/testsuite/g++.dg/ext/fnname5.C
Removed:
trunk/gcc/testsuite/g++.old-deja/g++.ext/pretty4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c

[Bug c++/64266] Can GCC produce local mergeable symbols for *.__FUNCTION__ and *.__PRETTY_FUNCTION__ functions?

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Mar 25 21:29:26 2016
New Revision: 234484

URL: https://gcc.gnu.org/viewcvs?rev=234484=gcc=rev
Log:
PR c++/64266
PR c++/70353
Core issue 1962
* decl.c (cp_fname_init): Decay the initializer to pointer.
(cp_make_fname_decl): Set DECL_DECLARED_CONSTEXPR_P,
DECL_VALUE_EXPR, DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P.
Don't call cp_finish_decl.
* pt.c (tsubst_expr) [DECL_EXPR]: Set DECL_VALUE_EXPR,
DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P.  Don't call cp_finish_decl.
* constexpr.c (cxx_eval_constant_expression) [VAR_DECL]:
Handle DECL_VALUE_EXPR.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-__func__2.C
trunk/gcc/testsuite/g++.dg/ext/fnname5.C
Removed:
trunk/gcc/testsuite/g++.old-deja/g++.ext/pretty4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/cp/decl.c
trunk/gcc/cp/pt.c

[Bug c++/70275] -w disables all -Werror flags

[kevin-tucker at cox dot net]

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

Kevin Tucker  changed:

   What|Removed |Added

 CC||kevin-tucker at cox dot net

--- Comment #1 from Kevin Tucker  ---
Tried example on 5.3.0 on Cygwin and got reported results.  
Found similar results for unused variable warnings with following source:
int main()
{
  int i;
  return 0;
}

Compiled with:
gcc -w -Werror=unused-variable -Wunused-variable unused.cpp

Gives no error

Also tried w/v6.0 (updated and built from r234482 of
svn://gcc.gnu.org/svn/gcc/trunk) and got same results.

However, I would think that if "-w" is given, then there are no warnings to
promote to errors, since warnings are disabled.

[Bug c++/70414] Function declaration in other scope: type safety violation

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #1 from Andrew Pinski  ---
The front-end should have rejected this code as it is invalid.

[Bug c++/70414] New: Function declaration in other scope: type safety violation

[stackoverflow...@gmx-topmail.de]

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

Bug ID: 70414
   Summary: Function declaration in other scope: type safety
violation
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stackoverflow...@gmx-topmail.de
  Target Milestone: ---

The following code compiles: 

-
#include

void t(){
std::cout << "func t()" << std::endl;
}

int main(int argc, char **argv) {
int t(); 
std::cout << t() << std::endl;
}
-

Output:
func t()\n6295712

This should not compile in my opinion because the two function declarations are
of different type.

I'm also referring to (I asked this question):
https://stackoverflow.com/questions/36224099/violation-of-type-safety-in-c-with-function-declaration-of-other-type

[Bug c++/70413] New: Class template names in anonymous namespaces are not globally unique

[ers.trion at gmail dot com]

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

Bug ID: 70413
   Summary: Class template names in anonymous namespaces are not
globally unique
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ers.trion at gmail dot com
  Target Milestone: ---

Created attachment 38099
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38099=edit
Example Source Code

If a class template is defined twice with the same name inside of anonymous
namespaces in different translation units and then used as a template template
parameter, the two templates are not treated as having globally unique names.

Example:

invoke.hh:
#include 
void invoke_foo(), invoke_bar();

template