[Bug rtl-optimization/70478] [LRA] S/390: Performance regression - superfluous stack frame

[krebbel at gcc dot gnu.org]

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

--- Comment #3 from Andreas Krebbel  ---
(In reply to Vladimir Makarov from comment #2)
Thanks for having a look.  I'll experiment a bit with adding a '?' constraint
modifier to see what impact it has on benchmarks. In fact it would match the
reality a bit better anyway since the mem-mem instructions have some
restrictions others don't have.

[Bug bootstrap/60244] GCC-trunk rev.207809, Segmentation fault when executing ".../xgcc -dumpspecs"

[vcunat at gmail dot com]

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

--- Comment #9 from Vladimír Čunát  ---
More information about my case: it's x86_64, Linux, gcc-5.3.0 from tarball
being built by gcc-4.8.3. I re-tried with --enable-debug and ran the
segfaulting command in gdb (I filtered seemingly uninteresting lines):

$ gdb -- /tmp/nix-build-gcc-5.3.0.drv-1/build/./gcc/xgcc
(gdb) run -B/tmp/nix-build-gcc-5.3.0.drv-1/build/./gcc/ -dumpspecs
Program received signal SIGSEGV, Segmentation fault.
(gdb) bt full
#0  0x0047ea8c in atexit ()
No symbol table info available.
#1  0x0040fd9a in driver::global_initializations (this=0x7fffd9f0)
at ../../gcc-5.3.0/gcc/gcc.c:6985
No locals.
#2  0x0040fb81 in driver::main (this=0x7fffd9f0, argc=3,
argv=0x7fffdaf8) at ../../gcc-5.3.0/gcc/gcc.c:6900
early_exit = false
#3  0x00416958 in main (argc=3, argv=0x7fffdaf8) at
../../gcc-5.3.0/gcc/gcc-main.c:45
d = {explicit_link_files = 0x47ea00 <__libc_csu_init>
"AWA\211\377AVI\211\366AUI\211\325ATL\215%0\033&", decoded_options = 0x6e6d70, 
  decoded_options_count = 3}

It really puzzles me that the segfault occurs *during* a call to atexit. It
uses glibc-2.23. Any idea about what could be wrong? Thanks.

[Bug target/70490] __atomic_load_n(const __int128 *, ...) generates CMPXCHG16B with no warning

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
The question is if e.g. XMM aligned loads are atomic or not.  If they are, we'd
have to use some pattern that would ensure RA etc. doesn't optimize that into a
GPR loads.

[Bug rtl-optimization/59393] [4.9/5/6 regression] mips16 code size

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Thu, 31 Mar 2016, law at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59393
> 
> Jeffrey A. Law  changed:
> 
>What|Removed |Added
> 
>  CC||law at redhat dot com
> 
> --- Comment #7 from Jeffrey A. Law  ---
> I was looking at this and noticed we have several sequences like
> 
>  _18 = l_11 >> 16;
>   _19 = _18 & 255;
>   _20 = _19 + 256;
>   _21 = _20 * 8;
>
> There's variations in the constants, but the pattern repeats regularly.  My
> first thought was to rewrite that as
> 
>  _18 = l_11 >> 13;
>  _19 = _18 & 0x7f8;
>  _20 = _19 + 0x800;
> 
> That seemed to be slightly worse on x86_64.  I'd already noticed that the
> addition was setting bits we knew to be zero, so it could be rewritten using 
> an
> IOR like this:
> 
> 
>  _18 = l_11 >> 13;
>  _19 = _18 & 0x7f8;
>  _20 = _19 | 0x800;
> 
> In isolation, that looked good on x86_64.  So my thought was that we may have
> an gcc-7 improvement that could be made for this code.  But then I coded up a
> quick pattern in match.pd and tested it and the resulting assembly code was
> considerably worse on x86_64 for the benchmark code.
> 
> There's a couple things in play here on x86_64.  In the benchmark code these
> are address computations.  The *8 and +256 in the original sequence can be a
> part of the effective address in the memory reference.  Furthermore, the
> masking is a 2 byte movzbl in the original sequence, but a 3 byte and # in the
> later sequences.  This negates all the gain by using IOR instead of PLUS, 
> which
> was shorter for x86_64.

Yeah, I think we have several fold-const.c pieces that try to make sure
to preserve / create shifts / ands that match mode widths.

> mips16 does slightly better with the second sequence, saving ~76 bytes on the
> included testcase.
> 
> However, given how highly dependent this is on the target's addressing modes,
> match.pd is probably not the place to attack this problem.  Combine is likely 
> a
> better place, using either a generic splitting sequence that self-tunes via
> rtx_cost.  Or via a target specific splitter.

True, though the idea to have target specific match.pd bits is still
on the plate - we'd have sth like config/$arch/$arch.pd which we can
include from match.pd and we could guard those patterns by
sth like compile-phase == pre-RTL-expand so they get enabled only
in late GIMPLE (after loop opts).  We'd add those mainly to remove
expand complexity and its reliance on TER to see complex expressions
for better initial instruction selection.

> The closest we get right now is this combine attempt:
> 
> (set (reg:SI 1077)
> (plus:SI (ashift:SI (and:SI (lshiftrt:SI (reg:SI 1073)
> (const_int 8 [0x8]))
> (reg:SI 1074))
> (const_int 2 [0x2]))
> (const_int 1024 [0x400])))
> 
> 
> reg:SI 1074 is (const_int 255), but we can't blindly substitute in because reg
> 1074 has other uses as seen by this attempt:
> 
> (parallel [
> (set (reg:SI 1077)
> (plus:SI (and:SI (ashift:SI (reg:SI 1072)
> (const_int 2 [0x2]))
> (const_int 1020 [0x3fc]))
> (const_int 1024 [0x400])))
> (set (reg:SI 1074)
> (const_int 255 [0xff]))
> ])

Yeah, the multi-use restriction in combine is a serious limitation.
OTOH we face a similar issue in GIMPLE forwprop and all those
"aritificial" single_use tests in match.pd - to do better the
pattern detection / replacement would need to be done with a
cost model that includes all pattern applications (all with
have uses in common at least).

[Bug target/70490] __atomic_load_n(const __int128 *, ...) generates CMPXCHG16B with no warning

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
(In reply to Jakub Jelinek from comment #3)
> The question is if e.g. XMM aligned loads are atomic or not.  If they are,
> we'd have to use some pattern that would ensure RA etc. doesn't optimize
> that into a GPR loads.

They are not, as stated in Vol 3B, 8.1.1:

An x87 instruction or an SSE instructions that accesses data larger than a
quadword [64 bits] may be implemented using multiple memory accesses.

[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower

[rguenth at gcc dot gnu.org]

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

--- Comment #27 from Richard Biener  ---
So, dealII slowdown is confirmed.

447.dealII  11440252   45.4 S   11440255   44.8 S
447.dealII  11440254   45.1 S   11440256   44.6 S
447.dealII  11440253   45.2 *   11440256   44.7 *

it's probably similarly artificial than the slowdown in this PR and thus it
might be acceptable given artificially swapping all exit comparisons isn't
something that should be done.

When profiling the difference it looks like the culprit is (are)

  6.55%  dealII_base.amd  libstdc++.so.6.0.22 [.]
std::_Rb_tree_increment(std::_Rb_tree_node_base const*)
  6.53%  dealII_peak.amd  dealII_peak.amd64-m64-gcc42-nn  [.]
MappingQ1<3>::compute_fill(TriaIterator<3, DoFCellAccessor<3> > const&,
unsigned int, QProjector<3>::D
  6.34%  dealII_peak.amd  libstdc++.so.6.0.22 [.]
std::_Rb_tree_increment(std::_Rb_tree_node_base const*)
  5.95%  dealII_base.amd  dealII_base.amd64-m64-gcc42-nn  [.]
MappingQ1<3>::compute_fill(TriaIterator<3, DoFCellAccessor<3> > const&,
unsigned int, QProjector<3>::D
...
  1.61%  dealII_peak.amd  dealII_peak.amd64-m64-gcc42-nn  [.]
SparsityPattern::operator()(unsigned int, unsigned int) const
  1.60%  dealII_peak.amd  dealII_peak.amd64-m64-gcc42-nn  [.]
MappingQ<3>::transform_covariant(Tensor<1, 3>*, Tensor<1, 3>*, Tensor<1, 3>
const*, Mapping<3>::Intern
  1.60%  dealII_base.amd  dealII_base.amd64-m64-gcc42-nn  [.]
SparsityPattern::operator()(unsigned int, unsigned int) const
  1.56%  dealII_base.amd  dealII_base.amd64-m64-gcc42-nn  [.]
MappingQ<3>::transform_covariant(Tensor<1, 3>*, Tensor<1, 3>*, Tensor<1, 3>
const*, Mapping<3>::Intern

but there isn't any assembly difference for MappingQ1<3>::compute_fill ...

[Bug c++/70488] [6 Regression] ICE in tree.c:7345 triggered by warning of placement new too small on VLA

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
  Known to work||5.3.0
   Keywords||diagnostic,
   ||ice-on-valid-code
   Last reconfirmed||2016-04-01
 Ever confirmed|0   |1
Summary|ICE in tree.c:7345  |[6 Regression] ICE in
   |triggered by warning of |tree.c:7345 triggered by
   |placement new too small |warning of placement new
   ||too small on VLA
   Target Milestone|--- |6.0

--- Comment #1 from Richard Biener  ---
Confirmed, full testcase

#include 
struct failure_case {unsigned long s;};

void break_func(unsigned int s) {
char temp_buffer[sizeof(failure_case) + s];
failure_case *f = new (temp_buffer) failure_case;
};

[Bug c/70485] Duplicate typedef results in missing debug info

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||6.0
 Resolution|--- |FIXED
  Known to fail||4.7.4, 5.3.0

--- Comment #1 from Richard Biener  ---
This is fixed in GCC 6 but still broken in GCC 5.  GCC 4.5 complained:

t.c:2: error: redefinition of typedef ‘yyx_handle’
t.c:1: error: previous declaration of ‘yyx_handle’ was here

since GCC 4.6 we accept the code and do not emit the typedef in debug info.

Thus not a regression, fixed.

[Bug target/70453] gcc generates invalid instruction vextractu64x4 (should be: vextracti64x4)

[kyukhin at gcc dot gnu.org]

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

Kirill Yukhin  changed:

   What|Removed |Added

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

--- Comment #8 from Kirill Yukhin  ---
Done.

[Bug c++/70403] A null pointer check removed with -O2 even with -fno-delete-null-pointer-checks

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #10 from Richard Biener  ---
The reduced testcase doesn't have the pattern you describe in the description.

With the preprocessed source I can confirm your observation (the NULL pointer
check is gone) with GCC 4.9.2.  With GCC 5 the whole function
NewLogicalSwitch::CpSelect is optimized to

  :
  _profile63.mpRecord = 0B;
  _profile63.mThisBufferId = 0;
  msEnabled.9_15 = msEnabled;
  if (msEnabled.9_15 != 0)
goto ;
  else
goto ;

  :
  ProfilePoint::Enter (&_profile63, &__PRETTY_FUNCTION__, 0);

  :
  tbrGet ();

  :
  *rFailureReason_5(D) = 0;
  __builtin_unreachable ();

:
  msEnabled.10_16 = msEnabled;
  if (msEnabled.10_16 != 0)
goto ;
  else
goto ;

  :
  ProfilePoint::Exit (&_profile63);

  :
  _14 = __builtin_eh_pointer (2);
  __builtin_unwind_resume (_14);

which means there is something wrong with your code.  Very likely it is

McCpId* pCpId = static_cast(&newCpId);

and it's further use.  You can't use an object of McId via a pointer to
McCpId but you call

pCpId->toString (cpIdBuf, sizeof (cpIdBuf));

on it.

[Bug rtl-optimization/70484] Wrong optimization with aliasing and access via char

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||alias, wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-01
  Component|tree-optimization   |rtl-optimization
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Still ok on the GIMPLE level:

f (int * pi, long int * pl)
{
  char _6;
  int _7;

  :
  *pi_2(D) = 1;
  *pl_4(D) = 0;
  _6 = MEM[(char *)pi_2(D)];
  _7 = (int) _6;
  return _7;

confirmed assembler:

f:
.LFB0:
.cfi_startproc
movl$1, (%rdi)
movl$1, %eax
movq$0, (%rsi)
ret

[Bug rtl-optimization/70484] Wrong optimization with aliasing and access via char

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
It's DSE1 that does this.

trying to replace QImode load in insn 9 from SImode store in insn 7
deferring rescan insn with uid = 9.
deferring rescan insn with uid = 17.
 -- replaced the loaded MEM with (reg 92)


  else if (s_info->rhs)
/* Need to see if it is possible for this store to overwrite
   the value of store_info.  If it is, set the rhs to NULL to
   keep it from being used to remove a load.  */
{
  if (canon_true_dependence (s_info->mem,
 GET_MODE (s_info->mem),
 s_info->mem_addr,
 mem, mem_addr))
{
  s_info->rhs = NULL;
  s_info->const_rhs = NULL;
}

it shouldn't use true_dependence but output_dependence (canon_output_dependence
is missing but trivial to add).

So the following patch fixes it.

Index: gcc/dse.c
===
--- gcc/dse.c   (revision 234663)
+++ gcc/dse.c   (working copy)
@@ -1609,10 +1609,7 @@ record_store (rtx body, bb_info_t bb_inf
   the value of store_info.  If it is, set the rhs to NULL to
   keep it from being used to remove a load.  */
{
- if (canon_true_dependence (s_info->mem,
-GET_MODE (s_info->mem),
-s_info->mem_addr,
-mem, mem_addr))
+ if (output_dependence (s_info->mem, mem))
{
  s_info->rhs = NULL;
  s_info->const_rhs = NULL;

[Bug libstdc++/70493] New: std::setlocale("") throws exception

[michi at triodia dot com]

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

Bug ID: 70493
   Summary: std::setlocale("") throws exception
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michi at triodia dot com
  Target Milestone: ---

#include 

int main(int, char**)
{
std::locale("");
}

Compile with --std=c++11 and run with

$ LC_ALL= LC_MONETARY=bad ./a.out

This aborts with a std::runtime_error: locale::facet::_S_create_c_locale name
not valid

From the C++ 11 spec, 22.3.1.2/8:

"Remarks: The set of valid string argument values is "C", "", and any
implementation-defined values."

By definition, "C" and "" are valid arguments, so I don't think this is allowed
to throw?

[Bug target/70482] Opimization opportunity to vectorize basic block for -mavx target.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-01
  Component|tree-optimization   |target
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Hmm, vectorization _does_ happen - it just happens in an awkward way
(we just vectorize the store).  We vectorize all of it with -mprefer-avx128.

Note that the vectorizer thinks vectorizing it in the awkward way is
profitable:

1: note: Cost model analysis:
  Vector inside of basic block cost: 1
  Vector prologue cost: 5
  Vector epilogue cost: 0
  Scalar cost of basic block: 8

if it weren't it would try vectorizing with smaller vector size.  I think
it under-estimates vector construction cost here (prologue cost).  From i386.c:

  case vec_construct:
elements = TYPE_VECTOR_SUBPARTS (vectype);
return ix86_cost->vec_stmt_cost * (elements / 2 + 1);

But in the assembler I see 8 vector instructions plus the store.  vec_construct
is supposed to handle the case of building up a vector from element registers.
Note the same is used for simple splats...  detailed analysis is possible
in the ix86_add_stmt_cost hook - but it might be "somewhat" awkward to
extract enough info from the stmt_info the vectorizer passes down... (which
stmt_info is passed down might also be somewhat random, not sure).

Note the cost model is disabled in the vect.exp testsuite.

[Bug c++/70494] New: Capturing an array of vectors in a lambda

[email.anukul at gmail dot com]

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

Bug ID: 70494
   Summary: Capturing an array of vectors in a lambda
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: email.anukul at gmail dot com
  Target Milestone: ---

#include 

int main()
{
std::vector v[] = {std::vector(10), std::vector(10)};
auto lambda = [v]{};
}

file.cpp: In function ‘int main()’:
file.cpp:7:20: internal compiler error: in build_special_member_call, at
cp/call.c:7789
  auto lambda = [v]{};
^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/70403] A null pointer check removed with -O2 even with -fno-delete-null-pointer-checks

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #10)
> McCpId* pCpId = static_cast(&newCpId);
> 
> and it's further use.  You can't use an object of McId via a pointer to
> McCpId but you call
> 
> pCpId->toString (cpIdBuf, sizeof (cpIdBuf));
> 
> on it.

You don't even need to use it through the derived pointer, simply performing
the static_cast is undefined behaviour:

  struct base { };
  struct derived : base { };
  base b;
  static_cast(&b);  // undefined

Compiling with -fsanitize=undefined would have found that bug.

[Bug c++/70494] Capturing an array of vectors in a lambda

[paolo.monteverde at gmail dot com]

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

Paolo Monteverde  changed:

   What|Removed |Added

 CC||paolo.monteverde at gmail dot 
com

--- Comment #1 from Paolo Monteverde  ---
The issue was raised by me here:
http://stackoverflow.com/questions/36351963/capturing-an-array-of-vectors-in-a-lambda-possible-gcc-bug

Thanks to anukul for having reported here :)

[Bug rtl-optimization/70484] [4.9/5/6 Regression] Wrong optimization with aliasing and access via char

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||4.3.4
Summary|Wrong optimization with |[4.9/5/6 Regression] Wrong
   |aliasing and access via |optimization with aliasing
   |char|and access via char
  Known to fail||4.4.7, 4.8.5, 5.3.0

--- Comment #3 from Richard Biener  ---
4.3.4 works thus this is a regression (possibly DSE got enhanced, I do see
the same bogus canon_true_dependence check there).

extern void abort (void);

int __attribute__((noinline,noclone))
f(int *pi, long *pl)
{
  *pi = 1;
  *pl = 0;
  return *(char *)pi;
}

int main()
{
  char a[sizeof (long)];
  if (f ((int *)a, (long *)a) != 0)
abort ();
  return 0;
}

[Bug rtl-optimization/70484] [4.9/5/6 Regression] Wrong optimization with aliasing and access via char

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug rtl-optimization/70484] [4.9/5/6 Regression] Wrong optimization with aliasing and access via char

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |4.9.4

[Bug libstdc++/66145] [5/6 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[malcolm.parsons at gmail dot com]

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

Malcolm Parsons  changed:

   What|Removed |Added

 CC||malcolm.parsons at gmail dot 
com

--- Comment #10 from Malcolm Parsons  ---
https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html says

"Although the standard exception types defined in  use strings, they
are not defined twice, so that a std::out_of_range exception thrown in one file
can always be caught by a suitable handler in another file, even if the two
files are compiled with different ABIs."

Why doesn't this apply to the std::ios_base exceptions?

[Bug libstdc++/66145] [5/6 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI

[redi at gcc dot gnu.org]

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to Malcolm Parsons from comment #10)
> Why doesn't this apply to the std::ios_base exceptions?

Because the C++11 standard mandated an ABI change for std::ios_base::failure,
by giving it a std::system_error base class that wasn't present in C++03.

[Bug c++/70494] Capturing an array of vectors in a lambda

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

 Target||*-*-*
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-01
 CC||jgreenhalgh at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from James Greenhalgh  ---
Fails for me on trunk and 5.3. Trunk backtrace for an aarch64-none-elf compiler
(but the target doesn't matter, same fail on arm-none-eabi and a
not-quite-trunk x86_64-none-linux-gnu):

foo.cpp: In function ‘int main()’:
foo.cpp:7:23: internal compiler error: tree check: expected record_type or
union_type or qual_union_type, have array_type in build_special_member_call, at
cp/call.c:7936
 auto lambda = [v]{};

0xf52300 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
.../tree.c:9643
0x5b24b2 tree_check3(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code)
.../tree.h:3046
0x5b24b2 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
.../cp/call.c:7951
0x661169 split_nonconstant_init_1
.../cp/typeck2.c:695
0x66248d split_nonconstant_init(tree_node*, tree_node*)
.../cp/typeck2.c:745
0x666ca1 store_init_value(tree_node*, tree_node*, vec**, int)
.../cp/typeck2.c:850
0x5df656 check_initializer
.../cp/decl.c:6150
0x5e4d52 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
.../cp/decl.c:6798
0x6e7109 cp_parser_init_declarator
.../cp/parser.c:18658
0x6e73bb cp_parser_simple_declaration
.../cp/parser.c:12379
0x6e7f7c cp_parser_block_declaration
.../cp/parser.c:12248
0x6e80c6 cp_parser_declaration_statement
.../cp/parser.c:11860
0x6c7b07 cp_parser_statement
.../cp/parser.c:10528
0x6c7bea cp_parser_statement_seq_opt
.../cp/parser.c:10806
0x6c7ce6 cp_parser_compound_statement
.../cp/parser.c:10760
0x6e647d cp_parser_function_body
.../cp/parser.c:20653
0x6e647d cp_parser_ctor_initializer_opt_and_function_body
.../cp/parser.c:20689
0x6e677d cp_parser_function_definition_after_declarator
.../cp/parser.c:25351
0x6e6b52 cp_parser_function_definition_from_specifiers_and_declarator
.../cp/parser.c:25263
0x6e6b52 cp_parser_init_declarator
.../cp/parser.c:18429

[Bug c++/70495] New: false warning: comparison between signed and unsigned integer expressions

[andras.szilard at gmail dot com]

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

Bug ID: 70495
   Summary: false warning: comparison between signed and unsigned
integer expressions
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andras.szilard at gmail dot com
  Target Milestone: ---

Hi,
I have the strange warning "comparison between signed and unsigned integer
expressions" when only unsigned types are used (more than 2 members).

Simplest example (I could find):
uint32_t a = 0;
uint8_t b = 0;
a < b + b + b;

Some more details: http://coliru.stacked-crooked.com/a/816fde87f946dcad

Side notes:
- Originally I used size_t instead of uint32_t (as in my real-life code).
- Using uint16_t instead of uint32_t / size_t does not give this warning.
- clang++ does not give this warning.

Tested the sample code with these g++ compiler versions: 4.8.4, 5.3.0 and
5.3.1.

Please, clarify what is going on! :)
Thanks in advance!

[Bug target/67896] Inconsistent behaviour between C and C++ for types poly8x8_t and poly16x8_t

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #6 from James Greenhalgh  ---
Author: jgreenhalgh
Date: Fri Apr  1 09:45:44 2016
New Revision: 234665

URL: https://gcc.gnu.org/viewcvs?rev=234665&root=gcc&view=rev
Log:
Backport: [PATCH] Do not set structural equality on polynomial types

gcc/ChangeLog:

PR target/67896
* config/aarch64/aarch64-builtins.c
(aarch64_init_simd_builtin_types): Do not set structural
equality to __Poly{8,16,64,128}_t types.

gcc/testsuite/ChangeLog:

PR target/67896
* gcc.target/aarch64/simd/pr67896.C: New.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/simd/pr67896.C
  - copied unchanged from r232818,
trunk/gcc/testsuite/gcc.target/aarch64/simd/pr67896.C
Modified:
branches/gcc-5-branch/   (props changed)
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/aarch64/aarch64-builtins.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

Propchange: branches/gcc-5-branch/
('svn:mergeinfo' modified)

[Bug libstdc++/70493] std::setlocale("") throws exception

[michi at triodia dot com]

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

--- Comment #1 from Michi Henning  ---
Ah, on reading http://pubs.opengroup.org/onlinepubs/9699919799/ section 8.2, it
appears that it's OK to throw in this case.

It would be nice to have a better diagnostic in the exception though. It could
show the facet that was found to be bad and the value that was objectionable
maybe?

[Bug rtl-optimization/68749] FAIL: gcc.dg/ifcvt-4.c scan-rtl-dump ce1 "2 true changes made"

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/ml/gcc-
   ||patches/2016-03/msg01631.ht
   ||ml

--- Comment #7 from Rainer Orth  ---
Patch posted.

[Bug target/67896] Inconsistent behaviour between C and C++ for types poly8x8_t and poly16x8_t

[jgreenhalgh at gcc dot gnu.org]

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

James Greenhalgh  changed:

   What|Removed |Added

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

--- Comment #7 from James Greenhalgh  ---
Fixed on trunk and 5.

[Bug middle-end/26461] liveness of thread local references across function calls

[andy at miniciv dot com]

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

Andy Robbins  changed:

   What|Removed |Added

 CC||andy at miniciv dot com

--- Comment #12 from Andy Robbins  ---
Cross posting to help others who need this feature. From a similar ticket on
LLVM, about adding the /GT flag (which fixes the OP's problem, while being
optional, and MSVC supports this):


[...] The option is /GT as specified in the title, and it is not enabled by
default.

There's one particular use case where this kind of option is really important:
a fiber-based job system, something that has been used in video game
development for multi-core machines.

In a system like this, it's common for one job (occupying a fiber) to be paused
(ie: swapped for another fiber in the thread it is running) while it waits for
some other work to finish, and then be resumed (ie: swapped to) from the next
available worker thread, which will be essentially a random worker thread. The
whole point here is to distribute jobs to all available CPU cores evenly and
automatically, so this TLS situation is inevitable and by design.

Yes, TLS is slower in this use case, but it is the correct behaviour. Not
having the /GT flag means having to manually inspect all code and roll a custom
replacement TLS, which is a considerable effort.

Please reconsider having this option.


Reference: https://llvm.org/bugs/show_bug.cgi?id=19177

[Bug bootstrap/60244] GCC-trunk rev.207809, Segmentation fault when executing ".../xgcc -dumpspecs"

[vcunat at gmail dot com]

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

--- Comment #10 from Vladimír Čunát  ---
Now I see the segfault does not happen if I use binutils-2.23 instead of 2.26.
Perhaps the cause is in there then.

[Bug target/70496] New: [6 regression] inadvertent change to ASM_APP_OFF for .arm / .thumb directives.

[ramana at gcc dot gnu.org]

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

Bug ID: 70496
   Summary: [6 regression] inadvertent change to ASM_APP_OFF for
.arm / .thumb directives.
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ramana at gcc dot gnu.org
  Target Milestone: ---

int i;
void main (void)
{
  __asm__ volatile (".arm");
  i = 0;
  __asm__ volatile ("\n cbz r0, 2f\n2:");
}


GCC 5 compiles this .

Trunk gives an error
/tmp/cc9ECIlN.s:40: Error: selected processor does not support `cbz r0,2f' in
ARM mode

with $gcc -c -march=armv7-a -mthumb /tmp/tst.c

[Bug target/70496] [6 regression] inadvertent change to ASM_APP_OFF for .arm / .thumb directives.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-01
   Assignee|unassigned at gcc dot gnu.org  |ramana at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Ramana Radhakrishnan  ---
mine.

[Bug tree-optimization/70497] New: Missed CSE of subregs on GIMPLE

[rguenth at gcc dot gnu.org]

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

Bug ID: 70497
   Summary: Missed CSE of subregs on GIMPLE
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

RTL DSE handles removing the redundand load (and thus 'u' itself) in

union U { int i[16]; char c; };

char foo(int i)
{
  union U u;
  u.i[0] = i;
  return u.c;
}

but nothing on GIMPLE does that.  FRE could do this, replacing
u.c with proper sub-setting of i (via a cast or a BIT_FIELD_REF).

[Bug tree-optimization/70497] Missed CSE of subregs on GIMPLE

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-01
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.

[Bug c++/70498] New: Libiberty Demangler segfaults (3)

[boehme.marcel at gmail dot com]

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

Bug ID: 70498
   Summary: Libiberty Demangler segfaults (3)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: boehme.marcel at gmail dot com
  Target Milestone: ---

Due to the inconsistent use of long and int for string/array length in
cp-demangle.c there is an integer overflow that leads to a write access
violation. The target crashes on an access violation at an address matching the
destination operand of the instruction.

This error was found during fuzzing with a more efficient version of AFL.

How to reproduce:
$ valgrind c++filt _Z808
==87985== Invalid read of size 1
==87985==at 0x7C3DFC: d_unqualified_name (cp-demangle.c:1555)
==87985==by 0x7CA9DF: d_name (cp-demangle.c:1399)
==87985==by 0x7CC1A3: d_encoding (cp-demangle.c:1257)
==87985==by 0x7D153C: cplus_demangle_mangled_name (cp-demangle.c:1172)
==87985==by 0x7D153C: d_demangle_callback (cp-demangle.c:5894)
==87985==by 0x7D153C: d_demangle (cp-demangle.c:5945)
==87985==by 0x7D153C: cplus_demangle_v3 (cp-demangle.c:6102)
==87985==by 0x75AB53: cplus_demangle (cplus-dem.c:865)
..
Segmentation fault

Root cause:
In cp-demangle.c sometimes length-variables are of type long, e.g., when the
length of an identifier is parsed in d_number. Other times they are of type
int, e.g., when actually parsing an identifier in d_identifier. Note that
cp-demangle.h exports structs and methods with length-variables of type int.

Preparing a patch.

[Bug libstdc++/70483] string_view::compare and coparision operators are not constexpr

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-01
 Ever confirmed|0   |1

[Bug target/69890] FAIL: gcc.target/i386/chkp-* on x86_64-apple-darwin15

[ienkovich at gcc dot gnu.org]

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

--- Comment #9 from Ilya Enkovich  ---
Author: ienkovich
Date: Fri Apr  1 10:40:51 2016
New Revision: 234666

URL: https://gcc.gnu.org/viewcvs?rev=234666&root=gcc&view=rev
Log:
gcc/testsuite/

PR target/69890
* gcc.dg/strlenopt.h (memmove): New.
* gcc.target/i386/chkp-strlen-1.c: Include "../../gcc.dg/strlenopt.h"
instead of "string.h".
* gcc.target/i386/chkp-strlen-2.c: Likewise.
* gcc.target/i386/chkp-strlen-3.c: Likewise.
* gcc.target/i386/chkp-strlen-4.c: Likewise.
* gcc.target/i386/chkp-strlen-5.c: Likewise.
* gcc.target/i386/chkp-stropt-1.c: Likewise.
* gcc.target/i386/chkp-stropt-10.c: Likewise.
* gcc.target/i386/chkp-stropt-11.c: Likewise.
* gcc.target/i386/chkp-stropt-12.c: Likewise.
* gcc.target/i386/chkp-stropt-13.c: Likewise.
* gcc.target/i386/chkp-stropt-14.c: Likewise.
* gcc.target/i386/chkp-stropt-15.c: Likewise.
* gcc.target/i386/chkp-stropt-16.c: Likewise.
* gcc.target/i386/chkp-stropt-2.c: Likewise.
* gcc.target/i386/chkp-stropt-3.c: Likewise.
* gcc.target/i386/chkp-stropt-4.c: Likewise.
* gcc.target/i386/chkp-stropt-5.c: Likewise.
* gcc.target/i386/chkp-stropt-6.c: Likewise.
* gcc.target/i386/chkp-stropt-7.c: Likewise.
* gcc.target/i386/chkp-stropt-8.c: Likewise.
* gcc.target/i386/chkp-stropt-9.c: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/strlenopt.h
trunk/gcc/testsuite/gcc.target/i386/chkp-strlen-1.c
trunk/gcc/testsuite/gcc.target/i386/chkp-strlen-2.c
trunk/gcc/testsuite/gcc.target/i386/chkp-strlen-3.c
trunk/gcc/testsuite/gcc.target/i386/chkp-strlen-4.c
trunk/gcc/testsuite/gcc.target/i386/chkp-strlen-5.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-1.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-10.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-11.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-12.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-13.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-14.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-15.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-16.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-2.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-3.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-4.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-5.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-6.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-7.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-8.c
trunk/gcc/testsuite/gcc.target/i386/chkp-stropt-9.c

[Bug c++/70495] false warning: comparison between signed and unsigned integer expressions

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
b+b has type int

[Bug c++/70488] [6 Regression] ICE in tree.c:7345 triggered by warning of placement new too small on VLA

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Started with r229827.

[Bug target/70496] [6 regression] inadvertent change to ASM_APP_OFF for .arm / .thumb directives.

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |6.0

[Bug c++/70495] false warning: comparison between signed and unsigned integer expressions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-01
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
(In reply to Jonathan Wakely from comment #1)
> b+b has type int

But even b+b+b can never be negative (which is the case where the warning is
interesting).

[Bug target/70496] [6 regression] inadvertent change to ASM_APP_OFF for .arm / .thumb directives.

[ramana at gcc dot gnu.org]

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

--- Comment #2 from Ramana Radhakrishnan  ---
Created attachment 38152
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38152&action=edit
Patch.

Patch I'm testing.

[Bug c++/70495] false warning: comparison between signed and unsigned integer expressions

[andras.szilard at gmail dot com]

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

--- Comment #3 from András  ---
> b+b has type int
Note: this does not give the warning. You can see the linked example for more
details.

[Bug c++/68475] [4.9/5/6 Regression] ICE: in merge_exception_specifiers, at cp/typeck2.c:2115 with -fno-exceptions on invalid code

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Author: nathan
Date: Fri Apr  1 12:10:17 2016
New Revision: 234667

URL: https://gcc.gnu.org/viewcvs?rev=234667&root=gcc&view=rev
Log:
PR c++/68475
* decl.c (check_redeclaration_exception_specification): Check
regardless of -fno-exceptions.
* typeck2.c (merge_exception_specifiers): Relax assert by checking
flag_exceptions too.

* g++.dg/g++.dg/cpp0x/noexcept29.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/noexcept29.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/cp/typeck2.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/68475] [4.9/5/6 Regression] ICE: in merge_exception_specifiers, at cp/typeck2.c:2115 with -fno-exceptions on invalid code

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #4 from Nathan Sidwell  ---
Fixed r234667.

As this is a checking ICE, I don't intend backporting.

[Bug tree-optimization/70497] Missed CSE of subregs on GIMPLE

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
union U { int i[16]; char c[4]; };

char foo(int i)
{
  union U u;
  u.i[0] = i;
  return u.c[1];
}

I have a prototype that for the above generates

movl%edi, %eax
movsbl  %ah, %eax

instead of (through RTL DSE):

movl%edi, %eax
shrw$8, %ax

The prototype ends up simply using BIT_FIELD_REFs.

  :
  _3 = BIT_FIELD_REF ;
  return _3;

[Bug c++/70488] [6 Regression] ICE in tree.c:7345 triggered by warning of placement new too small on VLA

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
I believe we should add these two checks:
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -2430,7 +2430,8 @@ warn_placement_new_too_small (tree type, tree nelts, tree
size, tree oper)
 though the size of a member of a union may be viewed as extending
 to the end of the union itself (it is by __builtin_object_size).  */
   if ((TREE_CODE (oper) == VAR_DECL || use_obj_size)
- && DECL_SIZE_UNIT (oper))
+ && DECL_SIZE_UNIT (oper)
+ && valid_constant_size_p (DECL_SIZE_UNIT (oper)))
{
  /* Use the size of the entire array object when the expression
 refers to a variable or its size depends on an expression
@@ -2438,7 +2439,8 @@ warn_placement_new_too_small (tree type, tree nelts, tree
size, tree oper)
  bytes_avail = tree_to_uhwi (DECL_SIZE_UNIT (oper));
  exact_size = !use_obj_size;
}
-  else if (TYPE_SIZE_UNIT (TREE_TYPE (oper)))
+  else if (TYPE_SIZE_UNIT (TREE_TYPE (oper))
+  && valid_constant_size_p (TYPE_SIZE_UNIT (TREE_TYPE (oper
{
  /* Use the size of the type of the destination buffer object
 as the optimistic estimate of the available space in it.  */

before calling tree_to_uhwi on those *_SIZE_UNITs.

[Bug c++/70495] false warning: comparison between signed and unsigned integer expressions

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to András from comment #3)
> > b+b has type int
> Note: this does not give the warning. You can see the linked example for
> more details.

I know, but b+b+b adds b to an int and still produces an int, which is
obviously enough to confuse the compiler. I'm not saying it's not a bug, just
explaining where the signed value comes from.

[Bug testsuite/70004] [6 Regression] FAIL: gcc.target/aarch64/scalar_shift_1.c scan-assembler-times neg\\td[0-9]+, d[0-9]+ 4

[clyon at gcc dot gnu.org]

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

--- Comment #6 from Christophe Lyon  ---
Author: clyon
Date: Fri Apr  1 12:22:05 2016
New Revision: 234669

URL: https://gcc.gnu.org/viewcvs?rev=234669&root=gcc&view=rev
Log:
Backport from mainline r233964.

2016-03-04  Kyrylo Tkachov  

PR target/70004
* gcc.target/aarch64/scalar_shift_1.c: (test_corners_sisd_di):
Delete.
(test_corners_sisd_si): Likewise.
(main): Remove checks of the above.
* gcc.target/aarch64/shift_wide_invalid_1.c: New test.


Added:
   
branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/shift_wide_invalid_1.c
Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gcc.target/aarch64/scalar_shift_1.c

[Bug c++/70495] false warning: comparison between signed and unsigned integer expressions

[andras.szilard at gmail dot com]

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

--- Comment #5 from András  ---
@Jonathan: could you, please, give me a link, which explains why this
"conversion to int" takes place (where it comes from)?
Thanks!

[Bug c++/70488] [6 Regression] ICE in tree.c:7345 triggered by warning of placement new too small on VLA

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Created attachment 38153
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38153&action=edit
gcc6-pr70488.patch

I think tree_fits_uhwi_p is the right test.  The code uses unsigned
HOST_WIDE_INT, so doesn't need objects that fit into half of address space.

[Bug c++/70495] false warning: comparison between signed and unsigned integer expressions

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
http://en.cppreference.com/w/cpp/language/implicit_cast#Integral_promotion

[Bug c++/70488] [6 Regression] ICE in tree.c:7345 triggered by warning of placement new too small on VLA

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Better testcase:

// PR c++/70488
// { dg-do compile }

typedef __typeof__ (sizeof 0) size_t;
void* operator new (size_t, void *p) { return p; }
void* operator new[] (size_t, void *p) { return p; }

struct S { size_t s; };

void
fn (unsigned int s)
{
  char a[sizeof (S) + s];
  S *f = new (a) S;
  S *f2 = new (a) S [1];
}

[Bug c++/70488] [6 Regression] ICE in tree.c:7345 triggered by warning of placement new too small on VLA

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
That said, the function also contains bogus loop like:
  /* Descend into a struct or union to find the member whose address
 is being used as the agument.  */
  while (TREE_CODE (oper) == COMPONENT_REF)
{
  tree op0 = oper;
  while (TREE_CODE (op0 = TREE_OPERAND (op0, 0)) == COMPONENT_REF);
  if (TREE_CODE (op0) == VAR_DECL)
var_decl = op0;
  oper = TREE_OPERAND (oper, 1);
}

TREE_OPERAND (, 1) of a COMPONENT_REF is a FIELD_DECL, so the loop doesn't make
sense, it will never loop more than once (so it is the same as if).
Martin, what exactly you've meant here?

[Bug c++/70499] New: internal compiler error: in make_ssa_name_fn, at tree-ssanames.c:266

[matthias.hochsteger at tuwien dot ac.at]

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

Bug ID: 70499
   Summary: internal compiler error: in make_ssa_name_fn, at
tree-ssanames.c:266
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthias.hochsteger at tuwien dot ac.at
  Target Milestone: ---

The compiler crashes with the given code. Multiple (in fact probably all)
versions are affected. Tested versions are 4.7, 4.8, 4.9, 5.1, 5.3 and 6.0 (4.6
and earlier don't accept -mavx2). Exact versions and abort messages are given
below.

Thanks!

The code:
//
#include 

struct SIMD {
  __m256d data;
  SIMD() {};
  SIMD (double val) { }
  SIMD(__m256d _data) { data = _data; }
  SIMD operator* (SIMD a) { return a; }
};

struct Foo {
  SIMD val;
  SIMD dval[2];
  __attribute__((__always_inline__)) SIMD & Value() throw() { return val; }
  __attribute__((__always_inline__)) Foo operator* ( const Foo & y) throw() 
{
  Foo res;
  SIMD hx;
  SIMD hy;
  res.Value() = hx*hy;
  res.dval[0] = hx*hy;
  return res;
}
};

template  
__attribute__((__always_inline__)) void inlineFunc(Tx hx[]) {
Tx x = hx[0], y = hx[1];
Tx lam[1] = (x*y);
}

void FooBarFunc () {
  Foo adp[2];
  inlineFunc (adp);
}
//

Abort messages:
=
g++-4.7 -v
Using built-in specs.
COLLECT_GCC=g++-4.7
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.7.3-12ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs
--enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.7 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-gnu-unique-object --disable-libmudflap --enable-plugin
--with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl
--disable-cloog-version-check --disable-ppl-version-check --enable-multiarch
--disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-12ubuntu1) 

g++-4.7 -mavx2 -O2 -c simd.cpp
simd.cpp:27:41: warning: always_inline function might not be inlinable
[-Wattributes]
simd.cpp: In function ‘void inlineFunc(Tx*) [with Tx = Foo]’:
simd.cpp:35:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/cc7UN6UV.out file, please attach this to
your bugreport.
ERROR: Cannot create report: [Errno 17] File exists:
'/var/crash/_usr_lib_gcc_x86_64-linux-gnu_4.7_cc1plus.1028.crash'
=
g++-4.8 -v
Using built-in specs.
COLLECT_GCC=g++-4.8
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.8.2-19ubuntu1'
--with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.8 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1) 

g++-4.8 -mavx2 -O2 -c simd.cpp
simd.cpp:27:41: warning: always_inline function might not be inlinable
[-Wattributes]
 __attribute__((__always_inline__)) void inlineFunc(Tx hx[]) {
 ^
simd.cpp: In function ‘void FooBarFunc()’:
simd.c

[Bug target/67896] Inconsistent behaviour between C and C++ for types poly8x8_t and poly16x8_t

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug target/48863] A Bug When Assembler Instructions with C Expression Operands in arm-elf-gcc 4.5

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-01
 CC||ramana at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #5 from Ramana Radhakrishnan  ---
Well confirmed.

[Bug c++/70449] [6 Regression] ICE with -Wall on valid code on x86_64-linux-gnu in pp_string, at pretty-print.c:928

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
The reason for the UNKNOWN_LOCATION is that in the testcase we try to
instantiate_decl the function being currently parsed, and do there
22017 input_location
22018   = DECL_STRUCT_FUNCTION (code_pattern)->function_end_locus;
but because we are in the middle of parsing that template, we haven't parsed
the closing } of the function template yet, so function_end_locus is unset.
That is also the reason for the bogus warning, the so far parsed statements of
the function template don't contain any return statements.

What does C++11/14 say about this?

clang++ 3.8 on this testcase warns:
warning: inline function 'f<0>' is not defined [-Wundefined-inline]
and if I add additional
constexpr int c = f<0> ();
after the template, it errors on it:
error: expression is not an integral constant expression
Both the clang diagnostics look really weird, I hope this really is invalid in
C++, can't see what the compiler could do there, because it needs the function
to be already parsed to use proper enumerators.
If I try
constexpr int f ()
{
  enum E { a = f () };
  return 0; 
}
instead, then clang++ diagnostics is similarly weird, but g++ reports a nice
pr70449-3.C: In function ‘constexpr int f()’:
pr70449-3.C:3:18: error: ‘constexpr int f()’ called in a constant expression
before its definition is complete
   enum E { a = f () };
~~^~
pr70449-3.C:3:19: error: enumerator value for ‘a’ is not an integer constant
   enum E { a = f () };
   ^
error.  So I think it would be best if we could emit the same diagnostics even
with templates.

[Bug c++/70500] New: Template deduction should fail on narrowing conversion

[akrzemi1 at gmail dot com]

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

Bug ID: 70500
   Summary: Template deduction should fail on narrowing conversion
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akrzemi1 at gmail dot com
  Target Milestone: ---

An example in the Standard shows that template deduction should fail upon
narrowing conversion from template argument. [temp.deduct] para 9:

```
template  int f(int);
template  int f(int);
int i1 = f<1000>(0); // OK
int i2 = f<1>(0); // ambiguous; not narrowing
```

However, GCC sees both calls as ambiguous. This happens on all GCC versions.

For similar reason, the following program is ill-formed (and is reported as
such by Clang), but in GCC it compiles fine:

```
template  int f(int) { return 0; }
int i = f<1>(0);

int main() {}
```

[Bug lto/68881] [6 Regression] UNRESOLVED/FAIL: gcc.dg/lto/attr-weakref-1 -O2 -flto

[hubicka at ucw dot cz]

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

--- Comment #16 from Jan Hubicka  ---
Hi,
I am testing the attached patch and would apprechiate testing on any additional
targets.
It implements the optimization of weakref to non-weakref in the case the target
is defined in same TU.
Unfortunately this is not cmopletely trivial as I had to bring in the symbol
privatization bits. 
Next stage1 I will cleanup the privatization little bit.

Also this patch does not solve all cases - if you define weakref target in
!binds_to_current_def
then the transparent alias must be created and this can't be done for symbols
marked as used.
We need to eventually fix gas to handle the case.

Honza

[Bug c++/70501] New: internal compiler error: in verify_ctor_sanity, at cp/constexpr.c:2249

[mpolacek at gcc dot gnu.org]

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

Bug ID: 70501
   Summary: internal compiler error: in verify_ctor_sanity, at
cp/constexpr.c:2249
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

$ ./cc1plus -quiet q.C 
q.C: In function ‘v4si fn1(int)’:
q.C:7:25: internal compiler error: in verify_ctor_sanity, at
cp/constexpr.c:2249
   r = i <= (v4si){(0, 0)};
 ^
0xa2827f verify_ctor_sanity
/home/marek/src/gcc/gcc/cp/constexpr.c:2248
0xa28507 cxx_eval_bare_aggregate
/home/marek/src/gcc/gcc/cp/constexpr.c:2283
0xa2e088 cxx_eval_constant_expression
/home/marek/src/gcc/gcc/cp/constexpr.c:3762
0xa25f42 cxx_eval_binary_expression
/home/marek/src/gcc/gcc/cp/constexpr.c:1639
0xa2ddd7 cxx_eval_constant_expression
/home/marek/src/gcc/gcc/cp/constexpr.c:3695
0xa2f0c5 cxx_eval_outermost_constant_expr
/home/marek/src/gcc/gcc/cp/constexpr.c:4011
0xa325db potential_constant_expression_1
/home/marek/src/gcc/gcc/cp/constexpr.c:4983
0xa328af potential_rvalue_constant_expression(tree_node*)
/home/marek/src/gcc/gcc/cp/constexpr.c:5044
0x8c25c4 cp_parser_constant_expression
/home/marek/src/gcc/gcc/cp/parser.c:9334
0x8d71d8 cp_parser_initializer_clause
/home/marek/src/gcc/gcc/cp/parser.c:20791
0x8c1ee4 cp_parser_assignment_expression
/home/marek/src/gcc/gcc/cp/parser.c:9074
0x8c21be cp_parser_expression
/home/marek/src/gcc/gcc/cp/parser.c:9222
0x8c5092 cp_parser_expression_statement
/home/marek/src/gcc/gcc/cp/parser.c:10683
0x8c4c97 cp_parser_statement
/home/marek/src/gcc/gcc/cp/parser.c:10534
0x8c5561 cp_parser_statement_seq_opt
/home/marek/src/gcc/gcc/cp/parser.c:10806
0x8c545e cp_parser_compound_statement
/home/marek/src/gcc/gcc/cp/parser.c:10760
0x8d6dd1 cp_parser_function_body
/home/marek/src/gcc/gcc/cp/parser.c:20653
0x8d6f9b cp_parser_ctor_initializer_opt_and_function_body
/home/marek/src/gcc/gcc/cp/parser.c:20689
0x8dfd99 cp_parser_function_definition_after_declarator
/home/marek/src/gcc/gcc/cp/parser.c:25351
0x8dfb9d cp_parser_function_definition_from_specifiers_and_declarator
/home/marek/src/gcc/gcc/cp/parser.c:25263
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ cat q.C
typedef int v4si __attribute__ ((vector_size (16)));

v4si
fn1 (int i)
{
  v4si r;
  r = i <= (v4si){(0, 0)};
  return r;
}

v4si
fn2 (int i)
{
  struct S { v4si v; };
  struct S s = { .v = i <= (v4si){(0, 0)} };
  return s.v;
}

[Bug c/70502] New: inconsistent behavior of -Werror=

[manu at gcc dot gnu.org]

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

Bug ID: 70502
   Summary: inconsistent behavior of -Werror=
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manu at gcc dot gnu.org
  Target Milestone: ---

According to the manual, -Werror=foo implies -Wfoo, however, these two
command-lines:

$ gcc -std=c89 -c -Werror=return-type -Wreturn-type  -Wno-all test.c

$ gcc -std=c89 -c -Werror=return-type -Wno-all test.c

produce different results for:

int foo() { return; }

I think the first behavior is the correct one (give an error). The problem is
caused by -Werror= not updating opts_set, which is what is tested by the
options machinery for options that imply other options.

[Bug c++/70501] internal compiler error: in verify_ctor_sanity, at cp/constexpr.c:2249

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-01
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Started with r229128.

(I found this while working on PR70307 -- they are somewhat related.)

[Bug c++/70501] [6 Regression] internal compiler error: in verify_ctor_sanity, at cp/constexpr.c:2249

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|internal compiler error: in |[6 Regression] internal
   |verify_ctor_sanity, at  |compiler error: in
   |cp/constexpr.c:2249 |verify_ctor_sanity, at
   ||cp/constexpr.c:2249

[Bug middle-end/70457] ICE (segfault) in gimple_expand_builtin_pow on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #3 from Bill Schmidt  ---
So we have an unreachable call to pow with the wrong number of arguments.  I
suppose the expansion logic for builtin_pow should tolerate this situation and
just do nothing with it.

[Bug c++/70452] [5/6 Regression] Regression in C++ parsing performance between 4.9.3 and 5.3.1

[ppalka at gcc dot gnu.org]

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

--- Comment #7 from Patrick Palka  ---
Created attachment 38155
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38155&action=edit
patch that reuses the function copies

I attached a small patch (not commented yet) that reduces the runtime (of a
checking compiler) from 3.5s to 2s and reduces GGC memory usage from 550MB to
200MB when compiling the test case in comment #1.

What it does is it maintains a per-FUNCTION_DECL freelist of body/parm/res
copies that were created by copy_fn().  When a constexpr call is finished it
pushes the copied body/parm/res trees to the freelist and before a call is
evaluated it tries to reuse the trees from the freelist, falling back to
copy_fn() if the freelist is empty.

AFAICT the reason we use copy_fn() in the first place is to make recursive
constexpr calls work.  If we didn't copy the function trees then recursive
calls would refer the same VAR/PARM_DECL trees.  In that respect I think this
patch is safe because recursive calls to the same function will still use
distinct trees since all the entries on the freelist are distinct copies.

Does this seem approach sensible?

[Bug middle-end/70457] ICE (segfault) in gimple_expand_builtin_pow on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #4 from Bill Schmidt  ---
(I should say, presumably unreachable.  This source code looks pretty dicey in
the first place, but nonetheless we should probably tolerate it at this stage
of optimization.)

[Bug c++/70452] [5/6 Regression] Regression in C++ parsing performance between 4.9.3 and 5.3.1

[ppalka at gcc dot gnu.org]

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

--- Comment #8 from Patrick Palka  ---
So with the patch instead of making ~200k total copies of the same fn (one for
each recursive call) we only make ~15 total copies (the maximum recursion depth
of the function).

[Bug c++/70476] C++11: Function name declared in unnamed namespace extern "C" gets exernal linkage

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
And this means the functions I thought were local to src/c++11/thread.cc are
not ... drat.

[Bug target/65248] Copy relocation against protected symbol doesn't work

[jb999 at gmx dot de]

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

jb999 at gmx dot de changed:

   What|Removed |Added

 CC||jb999 at gmx dot de

--- Comment #8 from jb999 at gmx dot de ---
(In reply to Khem Raj from comment #7)
> (In reply to H.J. Lu from comment #6)
> > Fixed for GCC 5. No plan for backport.
> 
> reading the commit message here
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=17709#c5
> 
> Does this mean now binutils >= 2.26 will be broken for older gcc ?
> 
> If thats the case, I would like to request a backport of this to atleast for
> gcc 4.9 and 4.8 which are not EOLed yet.

I second this.

[Bug target/70496] [6 regression] inadvertent change to ASM_APP_OFF for .arm / .thumb directives.

[ramana at gcc dot gnu.org]

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

--- Comment #3 from Ramana Radhakrishnan  ---
Author: ramana
Date: Fri Apr  1 14:58:53 2016
New Revision: 234675

URL: https://gcc.gnu.org/viewcvs?rev=234675&root=gcc&view=rev
Log:
Fix PR target/70496

While doing the unified asm rewrite - I inadvertently changed the
meaning of ASM_APP_OFF which causes failures when folks who know what
they are doing switch between arm and thumb states within a
function. The intent of the unified asm rewrite was not to affect any
inline assembler code in that it would remain in divided syntax by
default and switching back to unified asm in normal compiled code
after the inline assembler block. Thanks to Jim Wilson for pointing it
out on the linaro list.

Fixed thusly and a test is added. Tested arm-none-eabi cross and
applied.

Ramana

2016-04-01  Ramana Radhakrishnan  

PR target/70496
* config/arm/arm.h (ASM_APP_OFF): Handle TARGET_ARM
and TARGET_THUMB.

2016-04-01  Ramana Radhakrishnan  

PR target/70496
* gcc.target/arm/pr70496.c: New test.





Added:
trunk/gcc/testsuite/gcc.target/arm/pr70496.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm.h
trunk/gcc/testsuite/ChangeLog

[Bug target/70496] [6 regression] inadvertent change to ASM_APP_OFF for .arm / .thumb directives.

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan  changed:

   What|Removed |Added

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

--- Comment #4 from Ramana Radhakrishnan  ---
Fixed.

[Bug libstdc++/70503] New: extern "C" functions in src/c++11/thread.cc are global in libstdc++.a

[redi at gcc dot gnu.org]

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

Bug ID: 70503
   Summary: extern "C" functions in src/c++11/thread.cc are global
in libstdc++.a
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

In src/c++11/thread.cc we have:

namespace std
{
  namespace
  {
extern "C" void*
execute_native_thread_routine(void*)
{
  // ...
}

#if _GLIBCXX_THREAD_ABI_COMPAT
extern "C" void*
execute_native_thread_routine_compat(void* __p)
{
  // ...
}
#endif
  }
  // ...

I was under the mistaken impression that the unnamed namespace meant those
functions got internal linkage, but as PR 70476 points out, that's not true.

This means the functions are global symbols in the static library (they're not
exported from the shared library because the linker script makes everything
internal by default and only selected symbols are exported).

The following program should fail to link, but with -static it finds the
function in libstdc++.a and so crashes:

#include 

extern "C"
long execute_native_thread_routine(long i, long j);

int main()
{
  std::cout << execute_native_thread_routine(0, 0);
}

Variations can be produced with different link order that will produce a
multiple definition error, which happens with the RHEL devtoolset.

This bug has been present for some time, but is made worse in GCC 6 because I
renamed execute_native_thread_routine to execute_native_thread_routine_compat
and added a different function called execute_native_thread_routine. This means
we now have an additional global function in libstdc++.a, and the behaviour of
the original one changed.

[Bug c++/70489] ICE in cxx_eval_increment_expression initializing a VLA in a constexpr function

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-01
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

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

[msebor at gcc dot gnu.org]

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

Bug 64977 Summary: constexpr variable initialization by reference in lambda 
rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64977

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

[Bug c++/64977] constexpr variable initialization by reference in lambda rejected

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Martin Sebor  ---
Thanks.  Since we agree the test case is invalid I'll go ahead and close the
report.

[Bug middle-end/70457] ICE (segfault) in gimple_expand_builtin_pow on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #5 from Bill Schmidt  ---
Created attachment 38156
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38156&action=edit
Patch that permits this to compile

The attached patch allows the compilation to succeed in spite of the incorrect
number of arguments provided to pow ().

I suppose this is a reasonable approach, but it makes me a bit queasy to let
obviously incorrect code go by undiagnosed.  Still, it's no different than
providing the wrong number of arguments to some other function; we only notice
here because we convert the function call to a built-in.

CCing Richard for his opinion.

[Bug c++/70449] [6 Regression] ICE with -Wall on valid code on x86_64-linux-gnu in pp_string, at pretty-print.c:928

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 38157
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38157&action=edit
gcc6-pr70449.patch

Untested fix that attempts not to handle the case of fun being instantiation of
the current_function_decl like fun == current_function_decl case.

[Bug middle-end/70457] ICE (segfault) in gimple_expand_builtin_pow on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |wschmidt at gcc dot 
gnu.org
   Target Milestone|--- |6.0

[Bug rtl-optimization/70504] New: FLD, FLD, FXCH emitted instead of FLD, FLD in the needed order

[b7.10110111 at gmail dot com]

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

Bug ID: 70504
   Summary: FLD, FLD, FXCH emitted instead of FLD, FLD in the
needed order
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b7.10110111 at gmail dot com
  Target Milestone: ---

The following code demonstrates the bug:


long double inl_scalbn(long double mant, long double exp)
{
long double result;
asm("fscale"
: "=&t"(result)
: "%0"(mant),
  "u"(exp)
   );
return result;
}


With `-O3` option GCC generates the following assembly:


inl_scalbn:
fld TBYTE PTR [esp+4]
fld TBYTE PTR [esp+16]
fxchst(1)
fscale
fstpst(1)
ret


What's even stranger, I thought it was somehow related to order of function
arguments, but if I switch `mant` and `exp`, the code just switches `fld`
instructions instead of removing `fxch`.

It's clear that in both cases the code could have just loaded the parameters in
the correct order in the first place.

[Bug target/70504] FLD, FLD, FXCH emitted instead of FLD, FLD in the needed order

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||i?86-*-linux-gnu
  Component|rtl-optimization|target

--- Comment #1 from Andrew Pinski  ---
Not many people care about x87.

[Bug c++/70403] A null pointer check removed with -O2 even with -fno-delete-null-pointer-checks

[thadula at ciena dot com]

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

--- Comment #12 from Hadula, Tomasz  ---
> The reduced testcase doesn't have the pattern you describe in
> the description.

Well, of course, I couldn't verify that for sure, because the reduced testcase
was so severely mutilated that I couldn't possibly use to generate a running
program. However when I was looking into the output produced by
-fdump-tree-optimized I could see that pNewSel_2 in  in CpSelect was not
tested for null.

> Compiling with -fsanitize=undefined would have found that bug.

I tried that earlier, but the whole executable is so heavy that I couldn't even
have it started in the realistic time. So sanitizing it during runtime is the
challenge that we keep working on, but not there yet. Static analysis would
work better for us.

Is there any option that could point out any undefined behavior and print it as
a warning? (e.g. -Wundefined ? /but under 4.9.2 it is not recognized option/)

Anyway thank you very much for your help. I'm so glad that it gave us
opportunity to put that bug to rest eventually. Right about the time I posted
the reduced testcase yesterday, we have found many more occurrences of that bug
in other places in the code involving different classes, but the pattern seems
to be the same. In the first preprocessed source I attached, you could find at
least one more. Hard to say was the original idea behind it, but looking at the
source control it seems to be there since beginning of time. It's like way over
a decade old bug.

I still don't understand though why - since "pCpId" was responsible for
undefined behavior - why did devirtualization pick on "pNewSel" (and also in
the original source: on "squelch")?

[Bug c/70250] Compilation hangs without optimization.

[brijesh.s.singh at gmail dot com]

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

--- Comment #3 from brijesh singh  ---
Here is output of gcc -v aaa.c:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.9.2-0ubuntu1~12.04'
--with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--with-system-zlib --disable-browser-plugin --enable-java-awt=gtk
--enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre
--enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64 --enable-multilib --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Ubuntu 4.9.2-0ubuntu1~12.04)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.9/cc1 -quiet -v -imultiarch
x86_64-linux-gnu aaa.c -quiet -dumpbase aaa.c -mtune=generic
-march=x86-64 -auxbase aaa -version -fstack-protector -Wformat
-Wformat-security -o /tmp/ccMOxVDk.s
GNU C (Ubuntu 4.9.2-0ubuntu1~12.04) version 4.9.2 (x86_64-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 5.0.2, MPFR version
3.1.0-p3, MPC version 0.9
warning: MPFR header version 3.1.0-p3 differs from library version 3.1.2-p3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-linux-gnu/4.9/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
GNU C (Ubuntu 4.9.2-0ubuntu1~12.04) version 4.9.2 (x86_64-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 5.0.2, MPFR version
3.1.0-p3, MPC version 0.9
warning: MPFR header version 3.1.0-p3 differs from library version 3.1.2-p3.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8ab345ab89e18e2c324c23088e474a42
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/ccgrld1U.o /tmp/ccMOxVDk.s
GNU assembler version 2.22 (x86_64-linux-gnu) using BFD version (GNU
Binutils for Ubuntu) 2.22
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.9/collect2 -plugin
/usr/lib/gcc/x86_64-linux-gnu/4.9/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccaY1Fpv.res
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s --sysroot=/ --build-id
--eh-frame-hdr -m elf_x86_64 --hash-style=gnu --as-needed
-dynamic-linker /lib64/ld-linux-x86-64.so.2 -z relro
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crti.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtbegin.o
-L/usr/lib/gcc/x86_64-linux-gnu/4.9
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu
-L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib
-L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/x86_64-linux-gnu
-L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/4.9/../../..
/tmp/ccgrld1U.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
--as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/x86_64-linux-gnu/4.9/crtend.o
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crtn.o


On Thu, Mar 31, 2016 at 2:57 PM, Brijesh Singh
 wrote:
> gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
> 

[Bug c++/70488] [6 Regression] ICE in tree.c:7345 triggered by warning of placement new too small on VLA

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Author: jakub
Date: Fri Apr  1 15:27:11 2016
New Revision: 234676

URL: https://gcc.gnu.org/viewcvs?rev=234676&root=gcc&view=rev
Log:
PR c++/70488
* init.c (warn_placement_new_too_small): Test whether
DECL_SIZE_UNIT or TYPE_SIZE_UNIT are integers that fit into uhwi.

* g++.dg/init/new47.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/init/new47.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/init.c
trunk/gcc/testsuite/ChangeLog

[Bug target/69890] FAIL: gcc.target/i386/chkp-* on x86_64-apple-darwin15

[ienkovich at gcc dot gnu.org]

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

--- Comment #10 from Ilya Enkovich  ---
Author: ienkovich
Date: Fri Apr  1 15:31:43 2016
New Revision: 234677

URL: https://gcc.gnu.org/viewcvs?rev=234677&root=gcc&view=rev
Log:
gcc/testsuite/

Backport from mainline r234666.
2016-04-01  Ilya Enkovich  

PR target/69890
* gcc.dg/strlenopt.h (memmove): New.
* gcc.target/i386/chkp-strlen-1.c: Include "../../gcc.dg/strlenopt.h"
instead of "string.h".
* gcc.target/i386/chkp-strlen-2.c: Likewise.
* gcc.target/i386/chkp-strlen-3.c: Likewise.
* gcc.target/i386/chkp-strlen-4.c: Likewise.
* gcc.target/i386/chkp-strlen-5.c: Likewise.
* gcc.target/i386/chkp-stropt-1.c: Likewise.
* gcc.target/i386/chkp-stropt-10.c: Likewise.
* gcc.target/i386/chkp-stropt-11.c: Likewise.
* gcc.target/i386/chkp-stropt-12.c: Likewise.
* gcc.target/i386/chkp-stropt-13.c: Likewise.
* gcc.target/i386/chkp-stropt-14.c: Likewise.
* gcc.target/i386/chkp-stropt-15.c: Likewise.
* gcc.target/i386/chkp-stropt-16.c: Likewise.
* gcc.target/i386/chkp-stropt-2.c: Likewise.
* gcc.target/i386/chkp-stropt-3.c: Likewise.
* gcc.target/i386/chkp-stropt-4.c: Likewise.
* gcc.target/i386/chkp-stropt-5.c: Likewise.
* gcc.target/i386/chkp-stropt-6.c: Likewise.
* gcc.target/i386/chkp-stropt-7.c: Likewise.
* gcc.target/i386/chkp-stropt-8.c: Likewise.
* gcc.target/i386/chkp-stropt-9.c: Likewise.

Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gcc.dg/strlenopt.h
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-strlen-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-strlen-2.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-strlen-3.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-strlen-4.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-strlen-5.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-10.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-11.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-12.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-13.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-14.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-15.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-16.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-2.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-3.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-4.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-5.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-6.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-7.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-8.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/chkp-stropt-9.c

[Bug target/69890] FAIL: gcc.target/i386/chkp-* on x86_64-apple-darwin15

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #11 from Ilya Enkovich  ---
Fixed in trunk and gcc-5-branch.

[Bug target/53440] [arm] generic thunk code fails for method which uses '...'

[ramana at gcc dot gnu.org]

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

--- Comment #7 from Ramana Radhakrishnan  ---
A patch to fix this for TARGET_32BIT is here.

https://gcc.gnu.org/ml/gcc-patches/2016-04/msg00060.html

[Bug target/70404] pr70174.c fails on s390x

[krebbel at gcc dot gnu.org]

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

--- Comment #5 from Andreas Krebbel  ---
Author: krebbel
Date: Fri Apr  1 15:35:54 2016
New Revision: 234678

URL: https://gcc.gnu.org/viewcvs?rev=234678&root=gcc&view=rev
Log:
PR70404 S/390: Fix insv expansion.

While the expander accepts general_operand as src operand the risbg
pattern only immediate_operand.  Unfortunately the expander called
force_reg only for VOIDmode constants missing things like
e.g. symbol_refs.  Fixed with the attached patch.

gcc/ChangeLog:

2016-04-01  Andreas Krebbel  

PR target/70404
* config/s390/s390.c (s390_expand_insv): Check for everything
constant instead of just VOIDmode stuff.


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

[Bug target/70404] pr70174.c fails on s390x

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug c++/70488] [6 Regression] ICE in tree.c:7345 triggered by warning of placement new too small on VLA

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
ICE fixed, I'll let Martin figure out what he meant with COMPONENT_REFs.

[Bug target/70465] [4.9/5/6/7 Regression] Poor code for x87 asm

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||b7.10110111 at gmail dot com

--- Comment #7 from Jakub Jelinek  ---
*** Bug 70504 has been marked as a duplicate of this bug. ***

[Bug target/70504] FLD, FLD, FXCH emitted instead of FLD, FLD in the needed order

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Dup.

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

[Bug c++/70501] [6 Regression] internal compiler error: in verify_ctor_sanity, at cp/constexpr.c:2249

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug libstdc++/70503] extern "C" functions in src/c++11/thread.cc are global in libstdc++.a

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-04-01
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Created attachment 38158
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38158&action=edit
Ensure std::thread helpers have internal linkage

This patch makes the functions static and adds a test that should fail to link.

[Bug middle-end/70457] ICE (segfault) in gimple_expand_builtin_pow on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
IMHO much better would be to call gimple_call_builtin_p (call, BUILT_IN_NORMAL)
(for non-internal functions) and only treat those as builtins if that function
returned true.  That checks both the number of arguments, roughly their types
etc.

[Bug middle-end/70457] ICE (segfault) in gimple_expand_builtin_pow on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
Ah, but gimple_call_combined_fn already performs this.
So perhaps all you need is the tree-inline.c part?

[Bug c++/70501] [6 Regression] internal compiler error: in verify_ctor_sanity, at cp/constexpr.c:2249

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Note that a patch for PR70307 I've just posted contains a more exhaustive
testcase: .

[Bug libstdc++/70503] [4.9/5/6 Regression] extern "C" functions in src/c++11/thread.cc are global in libstdc++.a

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||4.3.6
Summary|extern "C" functions in |[4.9/5/6 Regression] extern
   |src/c++11/thread.cc are |"C" functions in
   |global in libstdc++.a   |src/c++11/thread.cc are
   ||global in libstdc++.a
  Known to fail||4.4.7, 4.5.4, 4.6.4, 4.7.4,
   ||4.8.4, 4.9.3, 5.3.0, 6.0

--- Comment #2 from Jonathan Wakely  ---
The function execute_native_thread_routine appeared in gcc 4.4.0 (introduced by
r144007 where previously it used the reserved name __thread_proxy), so
including that name in libstdc++.a is a regression.

[Bug middle-end/70457] ICE (segfault) in gimple_expand_builtin_pow on powerpc64le-linux-gnu

[wschmidt at gcc dot gnu.org]

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

--- Comment #8 from Bill Schmidt  ---
The tree-inline part only shows up after fixing the part in
tree-ssa-math-opts.c, where the initial failure occurs.  The DECL is already
encoded as a BUILT_IN_POW by the time we get that far.

[Bug middle-end/70457] ICE (segfault) in gimple_expand_builtin_pow on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
I've missed the pass_optimize_widening_mul::execute in your patch, that is also
another spot where you'd want to call it.  But the sincos hunks should be safe
as is.