[Bug c++/67131] New: [6 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

Bug ID: 67131
   Summary: [6 Regression] ICE: Segmentation fault
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
CC: jason at gcc dot gnu.org
  Target Milestone: ---

trippels@gcc2-power8 test % cat metafunction.ii
template  typename T::_ type;
template  class> struct A;
template  class f> A metafunction;
namespace detail {
template  struct _decltype;
}
template  class F> struct A {
  template 
  auto operator()() -> decltype(type...>>);
};
template  auto valid_call(F f) -> decltype(f());
constexpr auto valid_call(...) { return 0; }
template  struct no_type;
static_assert(!valid_call(metafunction),"");

trippels@gcc2-power8 test % clang++ -Wall -Wextra -c -std=c++14 metafunction.ii
trippels@gcc2-power8 test % g++ -c metafunction.ii
metafunction.ii: In substitution of ‘template decltype
(type...> >) A<  >::operator()()
[with T = {}]’:
metafunction.ii:11:57:   required by substitution of ‘template
decltype (f()) valid_call(F) [with F = A]’
metafunction.ii:14:48:   required from here
metafunction.ii:9:8: internal compiler error: Segmentation fault
   auto operator()() -> decltype(type...>>);
^
0x10a19a33 crash_signal
../../gcc/gcc/toplev.c:352
0x1031435c invalid_nonstatic_memfn_p
../../gcc/gcc/cp/typeck.c:1815
0x10385f67 finish_decltype_type(tree_node*, bool, int)
../../gcc/gcc/cp/semantics.c:7172
0x1020c867 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12686
0x1021219f tsubst_function_type
../../gcc/gcc/cp/pt.c:11749
0x1020c033 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12493
0x1021911b tsubst_decl
../../gcc/gcc/cp/pt.c:10969
0x1020c3f3 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:11965
0x10209c4f instantiate_template_1
../../gcc/gcc/cp/pt.c:16156
0x10209c4f instantiate_template(tree_node*, tree_node*, int)
../../gcc/gcc/cp/pt.c:16207
0x10236c27 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../gcc/gcc/cp/pt.c:16556
0x10188d3b add_template_candidate_real
../../gcc/gcc/cp/call.c:3022
0x1018996f add_template_candidate
../../gcc/gcc/cp/call.c:3119
0x1018996f add_candidates
../../gcc/gcc/cp/call.c:5245
0x1019012b build_op_call_1
../../gcc/gcc/cp/call.c:4232
0x1019012b build_op_call(tree_node*, vec**, int)
../../gcc/gcc/cp/call.c:4319
0x1037e2e3 finish_call_expr(tree_node*, vec**,
bool, bool, int)
../../gcc/gcc/cp/semantics.c:2408
0x10222d6b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:15397
0x1020b8e3 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12666
0x10211ebb tsubst_function_type
../../gcc/gcc/cp/pt.c:11749
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

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

--- Comment #14 from Andreas Krebbel  ---
Fixed in Glibc per comment #12.

[Bug go/66303] runtime.Caller() returns infinitely deep stack frames on s390x

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #15 from Andreas Krebbel  ---
Closing. Fixed in Glibc.

[Bug preprocessor/58397] Please add host_hooks for NetBSD to make precompiled headers work

[martin at netbsd dot org]

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

Martin Husemann  changed:

   What|Removed |Added

  Attachment #30803|0   |1
is obsolete||

--- Comment #2 from Martin Husemann  ---
Created attachment 36137
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36137&action=edit
Updated version of host hooks for NetBSD

[Bug preprocessor/58397] Please add host_hooks for NetBSD to make precompiled headers work

[martin at netbsd dot org]

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

Martin Husemann  changed:

   What|Removed |Added

Version|4.8.1   |5.2.0

--- Comment #3 from Martin Husemann  ---
This still applies to current releases of gcc and makes plain FSF gcc
unbuildable on many NetBSD architectures.

[Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc

[martin at netbsd dot org]

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

Martin Husemann  changed:

   What|Removed |Added

Version|4.8.1   |5.2.0

--- Comment #3 from Martin Husemann  ---
This still applies to recent versions and is an obvious fix. Please apply!

[Bug target/67129] x86: erratic parsing of "#pragma GCC target ("...")"

[vogt at linux dot vnet.ibm.com]

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

--- Comment #4 from Dominik Vogt  ---
Also, it is a bad idea to pass global_options_set in this call

  ix86_valid_target_attribute_tree (args, &global_options,
&global_options_set);

because it may be modified (via ix86_handle_option()).  Unlike global_options,
the structure global_options_set is never saved or restored, so any target
pragma or attribute may change the structure for the rest of the compilation
unit.  This may or may not cause weird things to happen.

[Bug c/67132] New: gcc -D__WCHAR_TYPE__='unsigned int' should not complain about built-in types redefined

[giacomo at tesio dot it]

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

Bug ID: 67132
   Summary: gcc -D__WCHAR_TYPE__='unsigned int' should not
complain about built-in types redefined
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: giacomo at tesio dot it
  Target Milestone: ---

I have a 3rd party library that `typedef Rune uint32_t`, and gcc *properly*
complains about the signedness of the following assignment

Rune *s = L"Άρχιμήδης";

because wchar_t is int32_b by default.

I have found that calling gcc with 

-D__WCHAR_TYPE__='unsigned int'
-D__WCHAR_MAX__=4294967295U
-D__WCHAR_MIN__=0

fix the signedness problem completely, but gcc then warns about such built-in
types redeclared at command line.

It would be nice to be able to redefine such built-in types without rebuilding
gcc.

[Bug middle-end/67133] New: ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274

[su at cs dot ucdavis.edu]

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

Bug ID: 67133
   Summary: ICE at -Os and above on x86_64-linux-gnu in gimple_op,
at gimple.h:2274
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The following code causes an ICE when compiled with the current gcc trunk at
-Os and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.

It is a regression from 5.1.x. 


$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --prefix=/usr/local/gcc-trunk
--enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
gcc version 6.0.0 20150805 (experimental) [trunk revision 226646] (GCC)
$
$ gcc-trunk -O1 -c small.c
$ gcc-5.1 -Os -c small.c
$
$ gcc-trunk -Os -c small.c
small.c: In function ‘fn3’:
small.c:29:1: internal compiler error: in gimple_op, at gimple.h:2274
 fn3 ()
 ^
0x86e15d gimple_op
../../gcc-trunk/gcc/gimple.h:2274
0x86e15d gimple_call_arg
../../gcc-trunk/gcc/gimple.h:2861
0x86e15d infer_nonnull_range_by_attribute(gimple_statement_base*, tree_node*)
../../gcc-trunk/gcc/gimple.c:2681
0x10c96f6 find_explicit_erroneous_behaviour
../../gcc-trunk/gcc/gimple-ssa-isolate-paths.c:410
0x10c96f6 gimple_ssa_isolate_erroneous_paths
../../gcc-trunk/gcc/gimple-ssa-isolate-paths.c:526
0x10c96f6 execute
../../gcc-trunk/gcc/gimple-ssa-isolate-paths.c:577
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$


---


#include 

int printf (const char *, ...);

int a, *b, c;

static int
fn1 ()
{ 
  if (a)
return (a = 0);
  for (; a; )
a = 0;
  return 0;
}

static int
fn2 (int p)
{ 
  fn1 ();
  c = 0;
  if (p)
printf ("%d", 0);
  assert (b != &p);
  return 0;
}

void
fn3 ()
{ 
  fn2 (0);
}

[Bug ipa/66896] ipa-prop.c:2479 runtime error: member call on null pointer of type 'struct ipa_polymorphic_call_context'

[marxin at gcc dot gnu.org]

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

--- Comment #14 from Martin Liška  ---
(In reply to Vittorio Zecca from comment #13)
> I see only two NULL dereferencing in ipa-prop.c my lines 2479 and 2545
> same statement
> 
> dst_ctx->combine_with (ctx);
> 
> Did you take care of both of them?

Hi.

Both cases are fixed on both trunk and gcc-5 branch in function
update_jump_functions_after_inlining.

Thanks,
Martin

[Bug fortran/64022] [F2003][IEEE] ieee_support_flag does not handle kind=10 and kind=16 REAL variables

[fxcoudert at gcc dot gnu.org]

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

--- Comment #9 from Francois-Xavier Coudert  ---
Author: fxcoudert
Date: Thu Aug  6 08:38:59 2015
New Revision: 226665

URL: https://gcc.gnu.org/viewcvs?rev=226665&root=gcc&view=rev
Log:
PR fortran/64022
* gfortran.dg/ieee/large_1.f90: Adjust test.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/ieee/large_1.f90

[Bug c/67134] New: internal compiler error: Segmentation fault

[momchil.uzunov at gmail dot com]

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

Bug ID: 67134
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 4.7.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: momchil.uzunov at gmail dot com
  Target Milestone: ---

I use:
mips-sde-elf-gcc (Sourcery CodeBench Lite 2013.05-35) 4.7.3
compiler.

When I compile my project I receive the error:
printer.c:1490:1: internal compiler error: Segmentation fault

There is nothing special at printer.c:1490:1.

The problem i in another file fragment:

...
#define INFO_IFM_HW_VER 29
#define INFO_IFM_FW_VER 30
#define INFO_HW_CAPABILITIES31
#define INFO_DATA_FLASH_ADDRES  32

#define PARAM_SAVE_TO_FLASH 0
#define PARAM_APPLICATION_ID1
...

When I add an empty line or change the name: INFO_DATA_FLASH_ADDRES it WORK!
worked example:

...
#define INFO_IFM_HW_VER 29
#define INFO_IFM_FW_VER 30
#define INFO_HW_CAPABILITIES31

#define INFO_DATA_FLASH_ADDRES  32

#define PARAM_SAVE_TO_FLASH 0
#define PARAM_APPLICATION_ID1
...

I can give my source code but I thin this describe the type of the problem.

[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-06
 CC||trippels at gcc dot gnu.org
Summary|ICE at -Os and above on |[6 Regression] ICE at -Os
   |x86_64-linux-gnu in |and above on
   |gimple_op, at gimple.h:2274 |x86_64-linux-gnu in
   ||gimple_op, at gimple.h:2274
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Confirmed. Also happens when building LLVM.

[Bug c/67134] internal compiler error: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
4.7.3 is no longer supported, please report the issue to your vendor code
sourcery.

[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||lopezibanez at gmail dot com

--- Comment #2 from Richard Biener  ---
CCing author

[Bug c++/67131] [6 Regression] ICE: Segmentation fault

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

   Target Milestone|6.0 |---

--- Comment #3 from Markus Trippelsdorf  ---
Backtrace in the LLVM case is slightly different:

AnalysisConsumer.ii:131658:8: internal compiler error: Segmentation fault
0x10a19a33 crash_signal
../../gcc/gcc/toplev.c:352
0x1072af6c infer_nonnull_range_by_attribute(gimple_statement_base*, tree_node*)
../../gcc/gcc/gimple.c:2682
0x110abb8f find_explicit_erroneous_behaviour
../../gcc/gcc/gimple-ssa-isolate-paths.c:410
0x110abb8f gimple_ssa_isolate_erroneous_paths
../../gcc/gcc/gimple-ssa-isolate-paths.c:526
0x110abb8f execute
../../gcc/gcc/gimple-ssa-isolate-paths.c:577
Please submit a full bug report,

[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug target/67124] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #2)
> Hmm, looks like a target issue.  We expand from

Not this time. It looks to me that generic code is at fault, performing DImode
move from %rdx to %xmm0, instead of inserting %rdx into %xmm0.

This can be seen with -O2 -msse2 -mtune=corei7 (please note that arrow points
to an instruction *before* it is executed):

   0x00400440 <+0>: movzbl 0x200c4b(%rip),%eax
   0x00400447 <+7>: movdqa 0x200c41(%rip),%xmm0
   0x0040044f <+15>:movq   %xmm0,%rdx
=> 0x00400454 <+20>:mov%rax,%rcx
   0x00400457 <+23>:and$0xff00,%rdx
   0x0040045e <+30>:shl$0x10,%rax
   0x00400462 <+34>:or %rax,%rdx
   0x00400465 <+37>:xor%eax,%eax
   0x00400467 <+39>:movq   %rdx,%xmm0
   0x0040046c <+44>:pinsrw $0x2,%eax,%xmm0
   0x00400471 <+49>:mov0x200be8(%rip),%rax
   0x00400478 <+56>:movups %xmm0,(%rax)

(gdb) i r rax rdx xmm0
rax0x1
rdx0x1
xmm0   {uint128 = 0x00010001}

   0x00400465 <+37>:xor%eax,%eax
=> 0x00400467 <+39>:movq   %rdx,%xmm0
   0x0040046c <+44>:pinsrw $0x2,%eax,%xmm0

(gdb) i r rdx xmm0
rdx0x1
xmm0   {uint128 = 0x00010001}

   0x00400465 <+37>:xor%eax,%eax
   0x00400467 <+39>:movq   %rdx,%xmm0
=> 0x0040046c <+44>:pinsrw $0x2,%eax,%xmm0

(gdb) i r rdx xmm0
rdx0x1
xmm0   {uint128 = 0x0001}

The same code can be compiled with -msse4 instead of -msse2, so we will have
pinsrb insn available:

   0x00400440 <+0>: movzbl 0x200c4b(%rip),%eax
   0x00400447 <+7>: xor%edx,%edx
   0x00400449 <+9>: movdqa 0x200c3f(%rip),%xmm0
=> 0x00400451 <+17>:pinsrb $0x2,%eax,%xmm0
   0x00400457 <+23>:pinsrw $0x2,%edx,%xmm0
   0x0040045c <+28>:mov0x200bfd(%rip),%rdx# 0x601060

   0x00400463 <+35>:movups %xmm0,(%rdx)

(gdb) i r rax xmm0
rax0x1
xmm0   {uint128 = 0x00010001}

   0x00400449 <+9>: movdqa 0x200c3f(%rip),%xmm0
   0x00400451 <+17>:pinsrb $0x2,%eax,%xmm0
=> 0x00400457 <+23>:pinsrw $0x2,%edx,%xmm0

i r xmm0
xmm0   {uint128 = 0x00010001}

As shown in the first case, the value in %xmm0 is already wrong before pinsrw
is executed.

[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
(In reply to Manuel López-Ibáñez from comment #4)
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

Well, it is a >5MB testcase and reducing isn't instantaneous unfortunately.

[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274

[manu at gcc dot gnu.org]

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

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Markus Trippelsdorf from comment #5)
> Well, it is a >5MB testcase and reducing isn't instantaneous unfortunately.

No problem, I'm not in a hurry. I need to bootstrap gcc and that will take me a
whole day at least.

[Bug middle-end/67124] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC|uros at gcc dot gnu.org|rsandifo at gcc dot 
gnu.org,
   ||ubizjak at gmail dot com
  Component|target  |middle-end

--- Comment #5 from Uroš Bizjak  ---
Wrong expansion, adding CC.

[Bug fortran/64022] [F2003][IEEE] ieee_support_flag does not handle kind=10 and kind=16 REAL variables

[fxcoudert at gcc dot gnu.org]

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

--- Comment #10 from Francois-Xavier Coudert  ---
Author: fxcoudert
Date: Thu Aug  6 09:22:30 2015
New Revision: 226670

URL: https://gcc.gnu.org/viewcvs?rev=226670&root=gcc&view=rev
Log:
PR fortran/64022
* gfortran.dg/ieee/large_2.f90: New test.
* gfortran.dg/ieee/large_3.F90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/ieee/large_2.f90
trunk/gcc/testsuite/gfortran.dg/ieee/large_3.F90
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Martin Husemann from comment #3)
> This still applies to recent versions and is an obvious fix. Please apply!

I personally would prefer to factor out all that repeated code into a function
pch_read_fatal_error() or to an exit label and use goto pch_read_fatal_error;

In any case, patches need to be submitted to gcc-patc...@gcc.gnu.org. Reviewers
rarely look for patches in bugzilla. See point #8 in
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

You should perhaps include the name of the file being patched in the subject.
I'm not sure we have a maintainer for ggc anymore.

[Bug preprocessor/58381] crash in diagnostic_report_current_module when a fatal_error happens during PCH processing on NetBSD/spa64rc

[manu at gcc dot gnu.org]

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

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Martin Husemann from comment #3)
> This still applies to recent versions and is an obvious fix. Please apply!

Points #7 and #8 in https://gcc.gnu.org/wiki/Community can help you to get your
patch through.

[Bug target/56309] conditional moves instead of compare and branch result in almost 2x slower code

[ysrumyan at gmail dot com]

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

--- Comment #33 from Yuri Rumyantsev  ---
With current compiler there is not performance difference for by-ref and by-val
test-cases, but if we turn off if-convert transformation we will get ~2X
speed-up:
on Intel(R) Xeon(R) CPU   X5670  @ 2.93GHz

 ./t1.exe
Took 11.55 seconds total.
 ./t1.noifcvt.exe
Took 6.51 seconds total.

The test will be attached.
This is caused by skew conditional branch probabilities for the loop:

for (auto rhs_it = rbegin; rhs_it != rend; ++rhs_it) {
tmp = x*(*rhs_it) + data[i] + carry;
if (tmp >= imax) {
carry = tmp >> numbits;
tmp &= imax - 1;
} else {
carry = 0;
}
data[i++] = tmp;
}

Only 2.5% conditional branches are not taken since imax represents MAX_INT32
and profile estimation phase needs to be fixed to set-up unlikely probability
for integral comparison with huge constants.
To coupe with this issue we may implement Jakub approach to design Oracle for
if-conversion profitability which simply computes region (loop) costs for
if-converted and not-if-converted regions ( cost of all acyclic paths).
Using such approach we can see that for fixed profile hammock predication is
not profitable and if vectorization will not be successful loop must be
restored to orginal one.

[Bug target/56309] conditional moves instead of compare and branch result in almost 2x slower code

[ysrumyan at gmail dot com]

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

--- Comment #34 from Yuri Rumyantsev  ---
Created attachment 36138
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36138&action=edit
simple reproducer

Use -O3 -std=c++14 options to compile and -fno-tree-loop-if-convert to get
better performance

[Bug fortran/67123] ICE with source allocation

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from vehre at gcc dot gnu.org ---
I can confirm that this is a duplicate of 66927.

The code in the description nevertheless needs a tweak in the allocate to read:

allocate( as(0:0), ...

to allocate an array of size 1, but with bounds 0..0. Using as(0) allocates an
array of size 0 with bound 1..0, which then is the next bug that is not fixed
by pr66927. Therefore I did not mark this bug as duplicate, but as depends on,
because without the fix for 66927 the next "bug" does not show.

[Bug fortran/66927] [6 Regression] ICE in gfc_conf_procedure_call

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #7 from vehre at gcc dot gnu.org ---
Currently checking whether the bug can be fixed more elegantly.

[Bug target/67129] x86: erratic parsing of "#pragma GCC target ("...")"

[vogt at linux dot vnet.ibm.com]

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

--- Comment #5 from Dominik Vogt  ---
Created attachment 36139
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36139&action=edit
experimental fix

The attached patch fixes the problem for me (on x86), but it really needs
reviewing.

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

[kkojima at gcc dot gnu.org]

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

--- Comment #19 from Kazumoto Kojima  ---
(In reply to Kazumoto Kojima from comment #18)
In the problematic situation, get_max_insn_count returns the false
value after

  if (MAY_HAVE_DEBUG_INSNS)
expand_debug_locations ();

in pass_expand::execute (function *fun).  expand_debug_locations
calls sh_recog_treg_set_expr indirectly at this very early stage
to compute rtx costs.  sh_recog_treg_set_expr makes some set insns
and they cause the differences of cur_insn_uid with -g.  Oleg, how
about the patch below?  My first trial was --cur_insn_uid just
after make_insn_raw there but I'm afraid that it will make another
surprise.

diff --git a/config/sh/sh.c b/config/sh/sh.c
index f429193..450d634 100644
--- a/config/sh/sh.c
+++ b/config/sh/sh.c
@@ -14165,6 +14165,12 @@ sh_recog_treg_set_expr (rtx op, machine_mode mode)
   if (!can_create_pseudo_p ())
 return false;

+  /* expand_debug_locations may call this to compute rtx costs at
+ very early stage.  In that case, don't make new insns here to
+ avoid codegen differences with -g. */
+  if (currently_expanding_to_rtl)
+return false;
+
   /* We are going to invoke recog in a re-entrant way and thus
  have to capture its current state and restore it afterwards.  */
   recog_data_d prev_recog_data = recog_data;

[Bug c++/67135] New: [thread_local] heap-use-after-free (OS X 10.10.4)

[marian.tri...@haw-hamburg.de]

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

Bug ID: 67135
   Summary: [thread_local] heap-use-after-free (OS X 10.10.4)
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marian.tri...@haw-hamburg.de
  Target Milestone: ---

Created attachment 36140
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36140&action=edit
code example

#include 
#include 

thread_local std::unique_ptr uptr;

int main() {
  std::thread t1([]{
if (! uptr) uptr = std::unique_ptr(new int);
  });
  t1.join();
}

Compiled with:
g++-5 -std=c++11 main.cpp -fsanitize=address -fno-omit-frame-pointer

It will trigger a heap-use-after-free, detected from ASAN:
=
==25568==ERROR: AddressSanitizer: heap-use-after-free on address 0x6020dfd8
at pc 0x00010e6c5548 bp 0x000111b37e10 sp 0x000111b37e08
READ of size 8 at 0x6020dfd8 thread T1
#0 0x10e6c5547  (/Users/Hamdor/osx_thread_local/./a.out+0x12547)
#1 0x10f3f48e5  (/usr/local/lib/gcc/5/libstdc++.6.dylib+0x18e5)
#2 0x7fff86535450  (/usr/lib/system/libsystem_pthread.dylib+0x4450)
#3 0x7fff86534272  (/usr/lib/system/libsystem_pthread.dylib+0x3272)
#4 0x7fff865341e4  (/usr/lib/system/libsystem_pthread.dylib+0x31e4)
#5 0x7fff8653241c  (/usr/lib/system/libsystem_pthread.dylib+0x141c)

0x6020dfd8 is located 8 bytes inside of 16-byte region
[0x6020dfd0,0x6020dfe0)
freed by thread T1 here:
#0 0x10e708419  (/usr/local/lib/gcc/5/libasan.2.dylib+0x32419)
#1 0x10f68c682  (/usr/local/lib/gcc/5/libgcc_s.1.dylib+0x11682)

previously allocated by thread T1 here:
#0 0x10e70826a  (/usr/local/lib/gcc/5/libasan.2.dylib+0x3226a)
#1 0x10f68c7db  (/usr/local/lib/gcc/5/libgcc_s.1.dylib+0x117db)

Thread T1 created by T0 here:
#0 0x10e6e40f0  (/usr/local/lib/gcc/5/libasan.2.dylib+0xe0f0)
#1 0x10f425d6c  (/usr/local/lib/gcc/5/libstdc++.6.dylib+0x32d6c)

SUMMARY: AddressSanitizer: heap-use-after-free ??:0 ??
Shadow bytes around the buggy address:
  0x1c041ba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c041bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c041bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c041bd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c041be0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x1c041bf0: fa fa fa fa fa fa 04 fa fa fa fd[fd]fa fa fd fd
  0x1c041c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x1c041c10: fa fa fa fa fa fa 00 06 fa fa 00 00 fa fa 00 04
  0x1c041c20: fa fa 00 06 fa fa 00 06 fa fa 00 fa fa fa 00 00
  0x1c041c30: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
  0x1c041c40: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Heap right redzone:  fb
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack partial redzone:   f4
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
==25568==ABORTING

This bug was tested with:
g++-5 --version 
g++-5 (Homebrew gcc5 5.2.0) 5.2.0

Older GCC versions are also affected (tested on 4.9.2)

Builds on Linux seems to be not affected, ASAN does not detect a
heap-use-after-free for the same code. OS X is 10.10.4

[Bug sanitizer/67136] New: sanitizer reports "member access within null pointer" for correct C++ code

[konstantin.vladimirov at gmail dot com]

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

Bug ID: 67136
   Summary: sanitizer reports "member access within null pointer"
for correct C++ code
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: konstantin.vladimirov at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Minimal reproduction:



#include 

using namespace std;

class Base
{
public:
  Base ():m_nl (144) {}
  virtual ~Base() {}
protected:
  const int m_nl;
};

class Derived : public Base
{
  public:
  __attribute__ ((noinline)) Derived ():Base()
  {
fprintf (stderr, "error = %d\n", (m_nl/2-1)%m_nl);
  }
};

Base *base;

int
main ()
{
  base = new Derived;
  return 0;
}



Compile with G++ 5.2.0

g++-5.2.0 -fno-sanitize-recover -fsanitize=undefined -O1 -Wall test.cpp
-Wl,-rpath /tools/local/gcc-5.2.0/lib64 -lubsan

---

Yields warning:

test.cpp: In constructor ‘Derived::Derived()’:
test.cpp:20:39: warning: ‘’ may be used uninitialized in this
function [-Wmaybe-uninitialized]
 fprintf (stderr, "error = %d\n", (m_nl/2-1)%m_nl);

---

I suggest, that macro UBSAN_NULL expands incorrectly on sanopt pass, yields
unitialized Gimple anonymous variable and then incorrectly compares with 0.

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

[olegendo at gcc dot gnu.org]

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

--- Comment #20 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #19)
> (In reply to Kazumoto Kojima from comment #18)
> In the problematic situation, get_max_insn_count returns the false
> value after
> 
>   if (MAY_HAVE_DEBUG_INSNS)
> expand_debug_locations ();
> 
> in pass_expand::execute (function *fun).  expand_debug_locations
> calls sh_recog_treg_set_expr indirectly at this very early stage
> to compute rtx costs.  sh_recog_treg_set_expr makes some set insns
> and they cause the differences of cur_insn_uid with -g.

Thank you very much for tracking this down.

> Oleg, how about the patch below?

Yes, that looks OK.  treg_set_expr-something recog matching is actually only
required during combine.  The simpler forms like (reg:SI T_REG) could also be
required during expansion.

> My first trial was --cur_insn_uid just
> after make_insn_raw there but I'm afraid that it will make another
> surprise.

Hm ... actually it should work.  The temporary rtx insn is not used for
anything else, so that assigned insn uid will never appear anywhere.  However,
it's probably better to have one "static rtx_insn" to avoid constructing the
temporary rtx over and over again.  Unfortunately the gen_rtx* functions
allocate rtx objects always on the GC heap.

[Bug c++/67131] [6 Regression] ICE: Segmentation fault

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-08-06
 Ever confirmed|0   |1

--- Comment #1 from Jason Merrill  ---
What version of clang compiles that with no errors?  Mine says,

wa2.C:17:15: error: static_assert expression is not an integral constant
expression
static_assert(!valid_call(metafunction),"");
  ^~
wa2.C:17:27: note: read of non-constexpr variable 'metafunction' is
not allowed in a constant expression
static_assert(!valid_call(metafunction),"");
  ^
wa2.C:17:27: note: in call to 'A(metafunction)'
wa2.C:6:45: note: declared here
template  class f> A metafunction;
^

[Bug c++/67130] [6 Regression] ICE: tree check: expected identifier_node, have template_decl in write_unqualified_id, at cp/mangle.c:1218

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-08-06
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/67131] [6 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

--- Comment #2 from Markus Trippelsdorf  ---
(In reply to Jason Merrill from comment #1)
> What version of clang compiles that with no errors?

Latest trunk.

[Bug c++/66260] [C++14] Failure to compile variable template with recursively defined partial specialization

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Thu Aug  6 14:26:18 2015
New Revision: 226676

URL: https://gcc.gnu.org/viewcvs?rev=226676&root=gcc&view=rev
Log:
PR c++/67130
PR c++/67131
PR c++/66260
* mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable
templates.
* pt.c (tsubst_copy_and_build): Check for argument substitution
failure.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ42.C
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ43.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/mangle.c
trunk/gcc/cp/pt.c

[Bug c++/67130] [6 Regression] ICE: tree check: expected identifier_node, have template_decl in write_unqualified_id, at cp/mangle.c:1218

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Thu Aug  6 14:26:18 2015
New Revision: 226676

URL: https://gcc.gnu.org/viewcvs?rev=226676&root=gcc&view=rev
Log:
PR c++/67130
PR c++/67131
PR c++/66260
* mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable
templates.
* pt.c (tsubst_copy_and_build): Check for argument substitution
failure.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ42.C
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ43.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/mangle.c
trunk/gcc/cp/pt.c

[Bug c++/67131] [6 Regression] ICE: Segmentation fault

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Thu Aug  6 14:26:18 2015
New Revision: 226676

URL: https://gcc.gnu.org/viewcvs?rev=226676&root=gcc&view=rev
Log:
PR c++/67130
PR c++/67131
PR c++/66260
* mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable
templates.
* pt.c (tsubst_copy_and_build): Check for argument substitution
failure.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ42.C
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ43.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/mangle.c
trunk/gcc/cp/pt.c

[Bug c++/67130] [6 Regression] ICE: tree check: expected identifier_node, have template_decl in write_unqualified_id, at cp/mangle.c:1218

[jason at gcc dot gnu.org]

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

--- Comment #2 from Jason Merrill  ---
Author: jason
Date: Thu Aug  6 14:28:26 2015
New Revision: 226677

URL: https://gcc.gnu.org/viewcvs?rev=226677&root=gcc&view=rev
Log:
PR c++/67130
PR c++/67131
PR c++/66260
* mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable
templates.
* pt.c (tsubst_copy_and_build): Check for argument substitution
failure.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/var-templ42.C
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/var-templ43.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/mangle.c
branches/gcc-5-branch/gcc/cp/pt.c

[Bug c++/66260] [C++14] Failure to compile variable template with recursively defined partial specialization

[jason at gcc dot gnu.org]

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

--- Comment #7 from Jason Merrill  ---
Author: jason
Date: Thu Aug  6 14:28:26 2015
New Revision: 226677

URL: https://gcc.gnu.org/viewcvs?rev=226677&root=gcc&view=rev
Log:
PR c++/67130
PR c++/67131
PR c++/66260
* mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable
templates.
* pt.c (tsubst_copy_and_build): Check for argument substitution
failure.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/var-templ42.C
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/var-templ43.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/mangle.c
branches/gcc-5-branch/gcc/cp/pt.c

[Bug c++/67131] [6 Regression] ICE: Segmentation fault

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Aug  6 14:28:26 2015
New Revision: 226677

URL: https://gcc.gnu.org/viewcvs?rev=226677&root=gcc&view=rev
Log:
PR c++/67130
PR c++/67131
PR c++/66260
* mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable
templates.
* pt.c (tsubst_copy_and_build): Check for argument substitution
failure.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/var-templ42.C
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/var-templ43.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/mangle.c
branches/gcc-5-branch/gcc/cp/pt.c

[Bug c++/67130] [6 Regression] ICE: tree check: expected identifier_node, have template_decl in write_unqualified_id, at cp/mangle.c:1218

[trippels at gcc dot gnu.org]

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

--- Comment #3 from Markus Trippelsdorf  ---
Fixed. Thanks.

[Bug c++/67130] [6 Regression] ICE: tree check: expected identifier_node, have template_decl in write_unqualified_id, at cp/mangle.c:1218

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #4 from Markus Trippelsdorf  ---
really fixed

[Bug c++/67131] [6 Regression] ICE: Segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #5 from Markus Trippelsdorf  ---
With this fix there is only one ICE left when building boost_hana: PR66533.

Closing.

[Bug bootstrap/67137] New: --enable-languages=jit and --disable-shared

[dilyan.palauzov at aegee dot org]

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

Bug ID: 67137
   Summary: --enable-languages=jit and --disable-shared
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dilyan.palauzov at aegee dot org
  Target Milestone: ---

/git/gcc/configure --enable-host-shared --enable-threads=posix
--with-arch=haswell --enable-__cxa_atexit --enable-languages=c,c++,lto,jit
--disable-shared --enable-targets=all --enable-nls --with-linker-hash-style=gnu
--with-system-zlib --disable-multilib 

make 

at stage2 fails with the message below, trying to build libgccjit.so.0.0.1 . As
I pass --disable-shared to ./configure, either configure shall fail, when
--enable-languages=jit is also requested, or it shall build libgccjit static. 
In any case, make may not fail because of impossible combinations of flags to
./configure, it is ./configure which must fail then.


make[3]: Entering directory '/src/gcc/gcc2/gcc'
/src/gcc/gcc2/./prev-gcc/xg++ -B/src/gcc/gcc2/./prev-gcc/
-B/usr/local/gcc60/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
 -I/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/include 
-I/git/gcc/libstdc++-v3/libsupc++
-L/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -no-pie  
-g -O2 -gtoggle -DIN_GCC -fPIC-fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common
 -DHAVE_CONFIG_H -static-libstdc++ -static-libgcc  -o libgccjit.so.0.0.1
-shared \
 attribs.o jit/dummy-frontend.o jit/libgccjit.o jit/jit-logging.o
jit/jit-recording.o jit/jit-playback.o jit/jit-result.o jit/jit-tempdir.o
jit/jit-builtins.o jit/jit-spec.o gcc.o libbackend.a libcommon-target.a
libcommon.a \
 ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a libcommon.a
../libcpp/libcpp.a   ../libbacktrace/.libs/libbacktrace.a
../libiberty/pic/libiberty.a ../libdecnumber/libdecnumber.a  -lisl -lmpc -lmpfr
-lgmp -rdynamic -ldl  -lz \
 driver-i386.o  \
 -Wl,--version-script=/git/gcc/gcc/jit/libgccjit.map \
 -Wl,-soname,libgccjit.so.0
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/../../../../x86_64-unknown-linux-gnu/bin/ld:
/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a(pure.o):
relocation R_X86_64_32 against `.rodata.__cxa_pure_virtual.str1.1' can not be
used when making a shared object; recompile with -fPIC
/src/gcc/gcc2/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs/libstdc++.a:
error adding symbols: Bad value
collect2: error: ld returned 1 exit status
/git/gcc/gcc/jit/Make-lang.in:84: recipe for target 'libgccjit.so.0.0.1' failed
make[3]: *** [libgccjit.so.0.0.1] Error 1
make[3]: Leaving directory '/src/gcc/gcc2/gcc'
Makefile:4417: recipe for target 'all-stage2-gcc' failed
make[2]: *** [all-stage2-gcc] Error 2
make[2]: Leaving directory '/src/gcc/gcc2'
Makefile:19833: recipe for target 'stage2-bubble' failed
make[1]: *** [stage2-bubble] Error 2
make[1]: Leaving directory '/src/gcc/gcc2'
Makefile:908: recipe for target 'all' failed
make: *** [all] Error 2

[Bug c++/66533] [C++14] ICE: in dependent_type_p, at cp/pt.c:21073

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Thu Aug  6 16:33:14 2015
New Revision: 226684

URL: https://gcc.gnu.org/viewcvs?rev=226684&root=gcc&view=rev
Log:
PR c++/66533
* parser.c (cp_parser_primary_expression): Don't skip to the end
of the statement if we're parsing tentatively.

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

[Bug c++/66533] [C++14] ICE: in dependent_type_p, at cp/pt.c:21073

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Thu Aug  6 16:36:58 2015
New Revision: 226685

URL: https://gcc.gnu.org/viewcvs?rev=226685&root=gcc&view=rev
Log:
PR c++/66533
* parser.c (cp_parser_primary_expression): Don't skip to the end
of the statement if we're parsing tentatively.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp1y/lambda-generic-ice3.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/parser.c

[Bug c++/66533] [C++14] ICE: in dependent_type_p, at cp/pt.c:21073

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|--- |5.3

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

[Bug c++/66538] Parameter not in scope of generic lambda trailing decltype

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #2 from Markus Trippelsdorf  ---
Fixed by r226684.

[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-06
 CC||fxcoudert at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |fxcoudert at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #11 from Francois-Xavier Coudert  ---
What I do not understand is how this didn't show up before now, since the
relevant libgfortran code was committed in 2012, and the mingw-w64 project has
been providing gfortran builds throughout this time.


Other than that, I would simply suggest we don't use umask() on mingw targets
(no need to make useless system calls):

Index: io/unix.c
===
--- io/unix.c   (revision 226632)
+++ io/unix.c   (working copy)
@@ -1083,6 +1083,14 @@ set_close_on_exec (int fd __attribute__ 
 }


+/* On mingw, we don't use umask in the function below, because it
+   doesn't support the user/group/other-based permissions.  */
+
+#ifdef __MINGW32__
+#undef HAVE_UMASK
+#endif
+
+
 /* Helper function for tempfile(). Tries to open a temporary file in
the directory specified by tempdir. If successful, the file name is
stored in fname and the descriptor returned. Returns -1 on


Can someone (Keith?) actually confirm that this restores the build on mingw32?
(It should, but double-checking never hurts.)

[Bug c++/67138] New: [concepts] bogus "not more constrained" error for more constrained partial specialization

[eric.niebler at gmail dot com]

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

Bug ID: 67138
   Summary: [concepts] bogus "not more constrained" error for more
constrained partial specialization
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric.niebler at gmail dot com
  Target Milestone: ---

template 
concept bool _Auto = true;

template <_Auto T>
struct test {};

template <_Auto T>
  requires requires (T t) { t + t; }
struct test {};


yields:

test.cpp:10:8: error: partial specialization ‘struct test’ does not
specialize any template arguments and is not more constrained than
 struct test {};
^
test.cpp:6:8: note: primary template here
 struct test {};
^

[Bug c++/66937] Do not compare constraints for unconstrained template template parameters

[jason at gcc dot gnu.org]

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

--- Comment #1 from Jason Merrill  ---
Author: jason
Date: Thu Aug  6 17:42:25 2015
New Revision: 226687

URL: https://gcc.gnu.org/viewcvs?rev=226687&root=gcc&view=rev
Log:
PR c++/66937
* pt.c (is_compatible_template_arg): A template template parameter
with unconstrained parameters can match an argument with
constrained parameters.

Added:
   
branches/c++-concepts/gcc/testsuite/g++.dg/concepts/template-template-parm1.C
Modified:
branches/c++-concepts/ChangeLog.concepts
branches/c++-concepts/gcc/cp/pt.c

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[thiago at kde dot org]

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

--- Comment #33 from Thiago Macieira  ---
gcc 5.2.1 can no longer reproduce the testcase.

Has the situation changed?

[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #12 from Steve Kargl  ---
On Thu, Aug 06, 2015 at 04:57:15PM +, fxcoudert at gcc dot gnu.org wrote:
> 
> Index: io/unix.c
> ===
> --- io/unix.c   (revision 226632)
> +++ io/unix.c   (working copy)
> @@ -1083,6 +1083,14 @@ set_close_on_exec (int fd __attribute__ 
>  }
> 
> 
> +/* On mingw, we don't use umask in the function below, because it
> +   doesn't support the user/group/other-based permissions.  */
> +
> +#ifdef __MINGW32__
> +#undef HAVE_UMASK
> +#endif
> +

Aren't there enough occurences of __MINGW32__ in io/unix.c?
Why add yet another kludge?  Put the #undef at line 48.

[Bug c++/67139] New: [concepts] ICE on checking concepts with void

[eric.niebler at gmail dot com]

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

Bug ID: 67139
   Summary: [concepts] ICE on checking concepts with void
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric.niebler at gmail dot com
  Target Milestone: ---

Created attachment 36141
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36141&action=edit
preprocessed source archive

Compile the attached code with -std=gnu++1z. The result is:

../cmcstl2/test/concepts/object.cpp:254:50: internal compiler error:
Segmentation fault
 CONCEPT_ASSERT(!models::move_constructible());
  ^

../cmcstl2/test/concepts/object.cpp:254:50: internal compiler error: Aborted
g++: internal compiler error: Aborted (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Cursory attempts to reduce the test case caused the error to go away.

[Bug libfortran/66936] io/unix.c gratuitously uses S_IRWXG and S_IRWXO on the basis that umask() is available

[fxcoudert at gcc dot gnu.org]

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

--- Comment #13 from Francois-Xavier Coudert  ---
(In reply to Steve Kargl from comment #12)
> Aren't there enough occurences of __MINGW32__ in io/unix.c?
> Why add yet another kludge?  Put the #undef at line 48.

Indeed, that works equally:

Index: io/unix.c
===
--- io/unix.c   (revision 226632)
+++ io/unix.c   (working copy)
@@ -101,6 +101,12 @@ id_from_fd (const int fd)
 }

 #endif /* HAVE_WORKING_STAT */
+
+
+/* On mingw, we don't use umask in tempfile_open(), because it
+   doesn't support the user/group/other-based permissions.  */
+#undef HAVE_UMASK
+
 #endif /* __MINGW32__ */

[Bug libfortran/66458] Loading libgfortran.so changes the FPU exception flags

[fxcoudert at gcc dot gnu.org]

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

--- Comment #5 from Francois-Xavier Coudert  ---
The comment in the front-end confirms the original intent, which is that FPU
shouldn't be messed with if the user didn't explicitly request it:

  /* If -ffpe-trap option was provided, add a call to set_fpe so that
 the library will raise a FPE when needed.  */

The patch below makes libgfortran behave in the same way:

Index: runtime/main.c
===
--- runtime/main.c  (revision 226632)
+++ runtime/main.c  (working copy)
@@ -263,7 +263,11 @@ init (void)
   init_variables ();

   init_units ();
-  set_fpu ();
+
+  /* If (and only if) the user asked for it, set up the FPU state.  */
+  if (options.fpe != 0)
+set_fpu ();
+
   init_compile_options ();

 #ifdef DEBUG

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[hjl.tools at gmail dot com]

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

--- Comment #34 from H.J. Lu  ---
(In reply to Thiago Macieira from comment #33)
> gcc 5.2.1 can no longer reproduce the testcase.
> 
> Has the situation changed?

GCC 5 r226650 still fails for me.

[Bug target/65886] [5/6 Regression] Copy reloc in PIE incompatible with DSO created by -Wl,-Bsymbolic

[thiago at kde dot org]

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

--- Comment #35 from Thiago Macieira  ---
I've only tried with SUSE's distro build, as my own GCC build is now GCC 6.

However, I can reproduce it with my GCC 6 build. Let me investigate if OpenSUSE
applied a patch.

[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #7 from Manuel López-Ibáñez  ---
(In reply to Zhendong Su from comment #0)
> The following code causes an ICE when compiled with the current gcc trunk at
> -Os and above on x86_64-linux-gnu in both 32-bit and 64-bit modes.
> 
> It is a regression from 5.1.x. 

This was already latent in r226635, just compile with options:

-Os -fisolate-erroneous-paths-dereference -fisolate-erroneous-paths-attribute

The problem is that infer_nonnull_range gets:

(gdb) p debug_gimple_stmt(stmt)
__builtin_unreachable ();

which is decorated with attributes:

(gdb) p debug_tree(attrs)
 
value >
chain 
value 
chain 
chain >

That is, this __builtin_unreachable has __attribute__((nonnull(1))), which
doesn't make any sense and breaks infer_nonnull_range when it tries to access
its first argument.

I have no idea whatsoever how __builtin_unreachable gets to have attribute
nonnull, but that is a pre-existing bug. Surprising it doesn't break more
stuff.

[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274

[manu at gcc dot gnu.org]

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

--- Comment #8 from Manuel López-Ibáñez  ---
Or even with options: -O2 -fisolate-erroneous-paths-attribute

(why is the latter not enabled by default?)

[Bug c++/67139] [concepts] ICE on checking concepts with void

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-06
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 tmp % cat o.ii
template  typename T::typevalue_type _v;
template  concept bool Constructible() { return _v; }

template  concept bool MoveConstructible() {
  return Constructible();
}

template  constexpr bool move_constructible() { return false; }
MoveConstructible { T }
constexpr bool move_constructible() { return true; }

static_assert((!move_constructible()), "");


markus@x4 tmp % g++ -std=gnu++1z -c o.ii
o.ii:12:42: internal compiler error: Segmentation fault
 static_assert((!move_constructible()), "");
  ^
0xc7f85f crash_signal
../../gcc/gcc/toplev.c:352
0x7fab31e0770f ???
/var/tmp/glibc/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0xef7bd0 strip_array_types(tree_node*)
../../gcc/gcc/tree.c:8194
0x71a2e8 cp_type_quals(tree_node const*)
../../gcc/gcc/cp/typeck.c:9006
0x790024 cv_unqualified(tree_node*)
../../gcc/gcc/cp/tree.c:1161
0x7fc8c4 satisfy_predicate_constraint
../../gcc/gcc/cp/constraint.cc:1705
0x7fc8c4 satisfy_constraint_1
../../gcc/gcc/cp/constraint.cc:1901
0x7fd5f6 satisfy_constraint
../../gcc/gcc/cp/constraint.cc:1952
0x7fd74c constraints_satisfied_p(tree_node*)
../../gcc/gcc/cp/constraint.cc:2059
0x5d832c add_function_candidate
../../gcc/gcc/cp/call.c:1986
0x5d8e88 add_template_candidate_real
../../gcc/gcc/cp/call.c:3109
0x5d957c add_template_candidate
../../gcc/gcc/cp/call.c:3151
0x5d957c add_candidates
../../gcc/gcc/cp/call.c:5307
0x5dbc03 perform_overload_resolution
../../gcc/gcc/cp/call.c:4003
0x5de10e build_new_function_call(tree_node*, vec**, bool, int)
../../gcc/gcc/cp/call.c:4080
0x76b998 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2391
0x6e9737 cp_parser_postfix_expression
../../gcc/gcc/cp/parser.c:6421
0x6ee229 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7485
0x6ee188 cp_parser_unary_expression
../../gcc/gcc/cp/parser.c:7438
0x6eee57 cp_parser_binary_expression
../../gcc/gcc/cp/parser.c:8222
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/67130] [6 Regression] ICE: tree check: expected identifier_node, have template_decl in write_unqualified_id, at cp/mangle.c:1218

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Thu Aug  6 18:45:05 2015
New Revision: 226696

URL: https://gcc.gnu.org/viewcvs?rev=226696&root=gcc&view=rev
Log:
PR c++/67130
PR c++/67131
PR c++/66260
* mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable
templates.
* pt.c (tsubst_copy_and_build): Check for argument substitution
failure.

Added:
branches/c++-concepts/gcc/testsuite/g++.dg/cpp1y/var-templ42.C
branches/c++-concepts/gcc/testsuite/g++.dg/cpp1y/var-templ43.C
Modified:
branches/c++-concepts/gcc/cp/mangle.c
branches/c++-concepts/gcc/cp/pt.c

[Bug c++/66260] [C++14] Failure to compile variable template with recursively defined partial specialization

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Thu Aug  6 18:45:05 2015
New Revision: 226696

URL: https://gcc.gnu.org/viewcvs?rev=226696&root=gcc&view=rev
Log:
PR c++/67130
PR c++/67131
PR c++/66260
* mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable
templates.
* pt.c (tsubst_copy_and_build): Check for argument substitution
failure.

Added:
branches/c++-concepts/gcc/testsuite/g++.dg/cpp1y/var-templ42.C
branches/c++-concepts/gcc/testsuite/g++.dg/cpp1y/var-templ43.C
Modified:
branches/c++-concepts/gcc/cp/mangle.c
branches/c++-concepts/gcc/cp/pt.c

[Bug c++/67131] [6 Regression] ICE: Segmentation fault

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Author: jason
Date: Thu Aug  6 18:45:05 2015
New Revision: 226696

URL: https://gcc.gnu.org/viewcvs?rev=226696&root=gcc&view=rev
Log:
PR c++/67130
PR c++/67131
PR c++/66260
* mangle.c (write_expression) [TEMPLATE_ID_EXPR]: Handle variable
templates.
* pt.c (tsubst_copy_and_build): Check for argument substitution
failure.

Added:
branches/c++-concepts/gcc/testsuite/g++.dg/cpp1y/var-templ42.C
branches/c++-concepts/gcc/testsuite/g++.dg/cpp1y/var-templ43.C
Modified:
branches/c++-concepts/gcc/cp/mangle.c
branches/c++-concepts/gcc/cp/pt.c

[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274

[trippels at gcc dot gnu.org]

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

--- Comment #9 from Markus Trippelsdorf  ---
trippels@gcc2-power8 llvm_build % cat AnalysisConsumer.ii
class A;
struct B {
  typedef A type;
};
template  struct I : B {};
class C {
public:
  C(char *);
  int size();
};
template  struct D;
template > class F {
  class G {
template  static _Tp *__test();
typedef int _Del;

  public:
typedef decltype(__test<_Del>()) type;
  };

public:
  typename I<_Tp>::type operator*() {
typename G::type a = 0;
return *a;
  }
};
class H {
  F Out;
  H();
};
void fn1(void *, void *, int) __attribute__((__nonnull__));
class A {
  int OutBufEnd, OutBufCur;

public:
  void operator<<(C p1) {
int b, c = p1.size();
if (OutBufEnd)
  fn1(&OutBufCur, &b, c);
  }
};
char* a;
H::H() { *Out << a; }

trippels@gcc2-power8 llvm_build % g++ -O2 -c AnalysisConsumer.ii
AnalysisConsumer.ii: In constructor ‘H::H()’:
AnalysisConsumer.ii:43:1: internal compiler error: Segmentation fault
 H::H() { *Out << a; }
 ^
0x10a18c53 crash_signal
../../gcc/gcc/toplev.c:352
0x1072af0c infer_nonnull_range_by_attribute(gimple_statement_base*, tree_node*)
../../gcc/gcc/gimple.c:2682
0x110a881f find_explicit_erroneous_behaviour
../../gcc/gcc/gimple-ssa-isolate-paths.c:410
0x110a881f gimple_ssa_isolate_erroneous_paths
../../gcc/gcc/gimple-ssa-isolate-paths.c:526
0x110a881f execute
../../gcc/gcc/gimple-ssa-isolate-paths.c:577
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug middle-end/67124] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

[rsandifo at gcc dot gnu.org]

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

--- Comment #6 from rsandifo at gcc dot gnu.org  
---
(In reply to Uroš Bizjak from comment #5)
> Wrong expansion, adding CC.

The expand code looks OK to me.  Assigning to one DImode word
of a TImode isn't supposed to change the other half.

I think the problem is in LRA.  It tries to reload the low half
of the TImode as follows:

  Creating newreg=104, assigning class NO_REGS to secondary r104
   51: r104:DI=r103:DI
Inserting the sec. move after:
   52: r90:TI#0=r104:DI

then allocates it as an xmm<-mem move:

 Choosing alt 14 in insn 52:  (0) *v  (1) m {*movdi_internal}

That isn't right because the move won't preserve the high half
of the xmm register.  It would need to be a strict_lowpart to do that.

[Bug go/66870] split stack issues on ppc64le and ppc64

[boger at us dot ibm.com]

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

--- Comment #21 from boger at us dot ibm.com ---
Created attachment 36142
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36142&action=edit
Configure gold with split stack based on binutils version

This is an updated version of the previous patch, simplifying the test done in
gcc/configure.ac.  Instead of trying to link a program this just checks the
binutils version number on the ld.gold --version output.  The configure check
in libgo will fail if the gold linker doesn't have split stack support but only
on pp64le.  On ppc64 the version check should be sufficient to make sure the
right gold linker is there.

[Bug c++/67139] [concepts] ICE on checking concepts with void

[eric.niebler at gmail dot com]

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

--- Comment #2 from Eric Niebler  ---
Thanks, except that that is invalid code, and this bug is an ICE-on-valid.
Here's the equivalent valid repro case:

template 
constexpr typename T::type::value_type _v = T::type::value;

template  concept bool IsTrue_() { return _v; }

template  concept bool Unpossible() {
  return IsTrue_();
}

template  constexpr bool unpossible() { return false; }
Unpossible{ T }
constexpr bool unpossible() { return true; }

static_assert((!unpossible()), "");

[Bug c++/67139] [concepts] ICE on checking concepts with void with variable template

[eric.niebler at gmail dot com]

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

Eric Niebler  changed:

   What|Removed |Added

Summary|[concepts] ICE on checking  |[concepts] ICE on checking
   |concepts with void  |concepts with void with
   ||variable template

--- Comment #3 from Eric Niebler  ---
The problem goes away when _v is replaced with the equivalent T::type::value
in concept IsTrue_, so that seems to be the smoking gun.

[Bug middle-end/67133] [6 Regression] ICE at -Os and above on x86_64-linux-gnu in gimple_op, at gimple.h:2274

[manu at gcc dot gnu.org]

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

--- Comment #10 from Manuel López-Ibáñez  ---
(In reply to Markus Trippelsdorf from comment #9)
> trippels@gcc2-power8 llvm_build % cat AnalysisConsumer.ii

It is also latent in r226635, just compile with options:

-O2 -fisolate-erroneous-paths-attribute


In this case, I cannot even debug it (i is 2):

(gdb) p gimple_call_arg (stmt, i)

/home/manuel/test3/pr67133.cc: In constructor ‘H::H()’:
/home/manuel/test3/pr67133.cc:43:1: internal compiler error: gimple check:
expected gimple_call(error_mark), have gimple_call() in gimple_call_arg, at
gimple.h:2858
 H::H() { *Out << a; }
 ^
0xa3d9c5 gimple_check_failed(gimple_statement_base const*, char const*, int,
char const*, gimple_code, tree_code)
/home/manuel/test3/src/gcc/gimple.c:1154
0x5b3abd gimple_call_arg
/home/manuel/test3/src/gcc/gimple.h:2858

But that is not the segmentation fault that is triggered when running the code
normally. It seems something wrong with the checking code.

If I print the stmt in the classic way (is there no better way to debug
gimple?):

(gdb) p *stmt
$5 = {code = GIMPLE_CALL, no_warning = 0, visited = 0, nontemporal_move = 0,
plf = 0, modified = 0, has_volatile_ops = 0, pad = 0, subcode = 0, uid = 11,
location = 2147483674, num_ops = 6, bb = 0x765bf340, next = 0x0, prev =
0x765a3b48}

Thus, it seems it should work?

[Bug fortran/67140] New: undefined reference to _gfortran_mvbits_i16

[eskei.one at gmail dot com]

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

Bug ID: 67140
   Summary: undefined reference to _gfortran_mvbits_i16
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eskei.one at gmail dot com
  Target Milestone: ---

Created attachment 36143
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36143&action=edit
example that reproduces error in title

I've been using bit manipulation of long integers in ISO_C_BINDING (IBSET,
IBCLR, BTEST, IBITS) for a while now. Today I tried to do MVBITS between two
C_INT128_T and got the error in the title. I am attaching an example program.

[Bug fortran/64022] [F2003][IEEE] ieee_support_flag does not handle kind=10 and kind=16 REAL variables

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
Version|5.0 |6.0
 Resolution|--- |FIXED

--- Comment #11 from Francois-Xavier Coudert  ---
Fixed on trunk.

[Bug libgomp/67141] New: wrong libgomp mutex initialisation order

[mattiase at acm dot org]

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

Bug ID: 67141
   Summary: wrong libgomp mutex initialisation order
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mattiase at acm dot org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Libgomp may use a mutex, acc_device_lock, prior to initialising it depending on
the constructor calling order: it is initialised in initialize_env and used in
goacc_host_init, both declared __attribute__ ((constructor)) but in different
files.

This was discovered on Windows after a change to the pthread library in
mingw-w64, making all-zero an invalid mutex value. Apparently the constructors
were called in the "wrong" order, and pthread_mutex_lock called before
pthread_mutex_init.

[Bug rtl-optimization/67124] [6 Regression] wrong code at -O1, -O2 and -O3 on x86_64-linux-gnu

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Keywords||ra
 CC||vmakarov at gcc dot gnu.org
  Component|middle-end  |rtl-optimization

--- Comment #7 from Uroš Bizjak  ---
(In reply to rsand...@gcc.gnu.org from comment #6)

> The expand code looks OK to me.  Assigning to one DImode word
> of a TImode isn't supposed to change the other half.
> 
> I think the problem is in LRA.  It tries to reload the low half
> of the TImode as follows:

Thanks for your analysis!

Reconfirmed as RA problem, adding another CC.

[Bug fortran/67140] undefined reference to _gfortran_mvbits_i16

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-08-06
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||4.8.5, 4.9.4, 5.2.1, 6.0

--- Comment #1 from kargl at gcc dot gnu.org ---
I have a patch.  Don't know if it actaully works
as your test program has no output and no indication
of the expected result.

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

[kkojima at gcc dot gnu.org]

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

--- Comment #21 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #20)
> Yes, that looks OK.  treg_set_expr-something recog matching is actually only
> required during combine.  The simpler forms like (reg:SI T_REG) could also
> be required during expansion.

Thanks.  I'll commit it when the usual test is done.

> Hm ... actually it should work.  The temporary rtx insn is not used for
> anything else, so that assigned insn uid will never appear anywhere. 
> However, it's probably better to have one "static rtx_insn" to avoid
> constructing the temporary rtx over and over again.  Unfortunately the
> gen_rtx* functions allocate rtx objects always on the GC heap.

Yes, it works.  I'm uncomfortable with it because the current use of
crtl->emit.x_cur_insn_uid aka cur_insn_uid is limitted to emit-rtl.c.
I think that the use of that field outside of emit-rtl.c is unexpected.
Also it doesn't sound good to add a new interface to access that field
there.  After all, your "static rtx_insn" is the right thing to do.

[Bug target/67002] [5] [SH]: Bootstrap stage 2/3 comparison failure - gcc/real.o differs

[olegendo at gcc dot gnu.org]

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

--- Comment #22 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #21)
> 
> Yes, it works.  I'm uncomfortable with it because the current use of
> crtl->emit.x_cur_insn_uid aka cur_insn_uid is limitted to emit-rtl.c.
> I think that the use of that field outside of emit-rtl.c is unexpected.
> Also it doesn't sound good to add a new interface to access that field
> there.  After all, your "static rtx_insn" is the right thing to do.

OK.  I will try to implement that "static rtx_insn" thing, after I have
finished the patch attachment 36012, which makes some changes to treg_set_expr.

[Bug libfortran/67140] undefined reference to _gfortran_mvbits_i16

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Created attachment 36144
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36144&action=edit
patch

Patched built and tested with OP's code.
Regression test passed.

[Bug c++/66937] Do not compare constraints for unconstrained template template parameters

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #2 from Jason Merrill  ---
Applied the proposed solution for now.

[Bug c++/66937] Do not compare constraints for unconstrained template template parameters

[rbock at eudoxos dot de]

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

--- Comment #3 from Roland B  ---
(In reply to Jason Merrill from comment #1)
> Author: jason
> Date: Thu Aug  6 17:42:25 2015
> New Revision: 226687
> 
> URL: https://gcc.gnu.org/viewcvs?rev=226687&root=gcc&view=rev
> Log:
>   PR c++/66937
>   * pt.c (is_compatible_template_arg): A template template parameter
>   with unconstrained parameters can match an argument with
>   constrained parameters.
> 
> Added:
>
> branches/c++-concepts/gcc/testsuite/g++.dg/concepts/template-template-parm1.C

Thanks for the commit. Works fine for me!

In the test file (template-template-parm1.C) I guess you should edit the
comment in the last line a bit.

```
// This fails, but should not
```

Not true anymore, since it compiles just fine :-)

Thanks again,

Roland

[Bug c++/67138] [concepts] bogus "not more constrained" error for more constrained partial specialization

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #1 from Jason Merrill  ---
Fixed by r226711.

[Bug c++/67139] [concepts] ICE on checking concepts with void with variable template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #4 from Jason Merrill  ---
This seems to be fixed now.