[Bug testsuite/67948] New: xor-and.c needs updating after r228661

[thopre01 at gcc dot gnu.org]

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

Bug ID: 67948
   Summary: xor-and.c needs updating after r228661
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thopre01 at gcc dot gnu.org
  Target Milestone: ---
Target: arm-none-eabi

After r228661, gcc.target/arm/xor-and is nicely optimized from:

ldr r3, .L2
eorsr0, r3
lsrsr0, r0, #1
movsr3, #128
lslsr3, r3, #8
orrsr0, r3

to:

lsrsr3, r0, #1
ldr r0, .L2
eorsr0, r3

This means the dg-final { scan-assembler "orr" } in gcc.target/arm/xor-and no
longer PASSes. Since it's for the best, the testcase should be updated.

[Bug tree-optimization/67945] Testsuite failures starting with revision 228616

[thopre01 at gcc dot gnu.org]

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

Thomas Preud'homme  changed:

   What|Removed |Added

 CC||thopre01 at gcc dot gnu.org

--- Comment #1 from Thomas Preud'homme  ---
arm-none-eabi target also regressed on:

PASS->FAIL: gcc.dg/builtins-10.c (test for excess errors)

This is due to sqrt(pow(x,4.0)) != x*x not being folded correctly (other tests
are fine).

[Bug rtl-optimization/67814] cmp instruction register allocation error (x86)

[vtjnash at gmail dot com]

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

--- Comment #4 from Jameson  ---
I couldn't find any generic linux binaries for 5.2 (or 6) to test. The downlink
link from the download page to https://gcc.gnu.org/wiki/GFortranBinaries seems
to go to a non-existant site gfortran.com

I tested with the mingw64-gcc v5.2.0 compiler and, like you, was not able to
reproduce the issue (I had originally noticed the issue on mingw64-gcc). So it
seems like either the issue got resolved, or some other optimization is hiding
it (it was pretty sensitive to the set of flags passed to gcc in 4.9.1 and
5.1.1). Is there any chance the fix will be backported to the major binary
distribution channels such as Ubuntu?

[Bug tree-optimization/67947] New: wrong code at -O3 on x86_64-linux-gnu

[su at cs dot ucdavis.edu]

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

Bug ID: 67947
   Summary: wrong code at -O3 on x86_64-linux-gnu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: su at cs dot ucdavis.edu
  Target Milestone: ---

The current gcc trunk miscompiles the following code on x86_64-linux-gnu at -O3
in both 32-bit and 64-bit modes. 

This is a regression from 5.2.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 20151012 (experimental) [trunk revision 228712] (GCC) 
$ 
$ gcc-trunk -O2 small.c; ./a.out
0
0
0
$ gcc-5.2 -O3 small.c; ./a.out
0
0
0
$ 
$ gcc-trunk -O3 small.c
$ ./a.out
$ 


--


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

int a;

int
main (int argc, char* argv[])
{
  int j, k, b = 0;
  if (argc == 0) 
b = 1;
  for (j = 0; j < 3; j++)
for (k = 0; k < 1; k++)
  {
printf ("%d\n", 0);
if (b)
  for (k = -1; a;)
;
  }
  return 0; 
}

[Bug tree-optimization/67920] [6 Regression] wrong code with -O3

[jamrial at gmail dot com]

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

--- Comment #6 from James Almer  ---
Created attachment 36491
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36491&action=edit
-save-temps output for all three files

[Bug tree-optimization/67920] [6 Regression] wrong code with -O3

[jamrial at gmail dot com]

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

James Almer  changed:

   What|Removed |Added

  Component|rtl-optimization|tree-optimization

--- Comment #5 from James Almer  ---
This is a regression introduced by r228599.
I'm attaching the output of -save-temps for all three files, the good assembly
from r228598 (last good commit) and the bad assembly from r228599.

I can't generate a better or simpler testcase, sorry.

[Bug inline-asm/67944] GCC emits unnecessary push/pop for callee-save reads.

[alex.reinking at gmail dot com]

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

--- Comment #2 from Alex Reinking  ---
I expect it to return whatever is currently stored in ebx. Which it does, but
suboptimally. In my particular case, ebx is populated by a system call. I
wanted to put the inline assembly for retrieving that value in its own function
so I wouldn't have to remember the local register variable syntax.

The code I posted is simply a somehow minimal example of the anomalous assembly
generated. The question here is more "Why does gcc emit a push ebx; pop ebx?"
than "How should I retrieve whatever is currently in ebx?"

[Bug target/67946] New: Function multiversioning ICE

[evstupac at gmail dot com]

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

Bug ID: 67946
   Summary: Function multiversioning ICE
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: evstupac at gmail dot com
  Target Milestone: ---

The following test:

#include 

__m256 x, y, z;

__attribute__((target("avx")))
int bar()
{
  x = _mm256_add_ps (y, z);
  return 1;
}

__attribute__((target("default")))
int bar()
{
  return 2;
}

int
foobar()
{
  if (__builtin_cpu_supports ("avx"))
return bar();
  else
return 0;
}

__attribute__((target("sse3")))
int foo(int i)
{
  return foobar() + 1;
}

__attribute__((target("default")))
int foo(int i)
{
  return foobar() + 2;
}

ICE by:

gcc test.cpp -O3 -S -msse4.2 
test.cpp: In function 'int bar()':
test.cpp:8:27: internal compiler error: in expand_expr_real_2, at expr.c:9322
   x = _mm256_add_ps (y, z);
   ^ 
0x9e0445 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/export/users/gnutester/stability/svn/trunk/gcc/expr.c:9322
0x9cd8da expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/export/users/gnutester/stability/svn/trunk/gcc/expr.c:9523
0x9d7f62 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, tree_node*)
/export/users/gnutester/stability/svn/trunk/gcc/expr.c:5399
0x9da55d expand_assignment(tree_node*, tree_node*, bool)
/export/users/gnutester/stability/svn/trunk/gcc/expr.c:5171
0x8cb1de expand_gimple_stmt_1
/export/users/gnutester/stability/svn/trunk/gcc/cfgexpand.c:3581
0x8cb1de expand_gimple_stmt
/export/users/gnutester/stability/svn/trunk/gcc/cfgexpand.c:3677
0x8cd511 expand_gimple_basic_block
/export/users/gnutester/stability/svn/trunk/gcc/cfgexpand.c:5681
0x8d41f6 execute
/export/users/gnutester/stability/svn/trunk/gcc/cfgexpand.c:6293
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[rcopley at gmail dot com]

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

--- Comment #8 from R Copley  ---
Thanks. I've emailed the mingw-w64 list at
http://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public. (You expressed it
better but I hadn't seen your last comment.)

[Bug tree-optimization/67945] New: Testsuite failures starting with revision 228616

[pthaugen at gcc dot gnu.org]

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

Bug ID: 67945
   Summary: Testsuite failures starting with revision 228616
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pthaugen at gcc dot gnu.org
CC: bergner at gcc dot gnu.org, dje at gcc dot gnu.org,
rdsandiford at googlemail dot com
  Target Milestone: ---
  Host: powerpc64-unknown-linux-gnu
Target: powerpc64-unknown-linux-gnu
 Build: powerpc64-unknown-linux-gnu

Following tests started failing with r228616.

FAIL: gcc.target/powerpc/ppc-pow.c scan-assembler-times bl?[. ]+pow 1
FAIL: gcc.target/powerpc/ppc-pow.c scan-assembler-times fsqrt 3
FAIL: gcc.target/powerpc/pr46728-2.c scan-assembler-times fsqrt|xssqrtdp 4
FAIL: gcc.target/powerpc/pr46728-3.c scan-assembler-times sqrt 4
FAIL: gcc.target/powerpc/pr46728-5.c scan-assembler-times cbrt 2

[Bug target/65804] blackfin: Not support global frame pointer with -fno-omit-frame-pointer

[bernds at gcc dot gnu.org]

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

Bernd Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||bernds at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #3 from Bernd Schmidt  ---
This looks exactly like expected behaviour. Closing as not a bug.

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
The difference will probably be that when including libstdc++'s  this
happens before mingw's  is included:

// Make sure that POSIX printf/scanf functions are activated.  As
// libstdc++ depends on POSIX-definitions of those functions, we define
// it unconditionally.
#undef __USE_MINGW_ANSI_STDIO
#define __USE_MINGW_ANSI_STDIO 1

That alters what  declares, due to this in 

#if __USE_MINGW_ANSI_STDIO
/*
 * User has expressed a preference for C99 conformance...
 */

That causes printf to be a wrapper around __mingw_vprintf, rather than calling
the MSVCRT version:

__mingw_ovr
__attribute__((__format__ (gnu_printf, 1, 2))) __MINGW_ATTRIB_NONNULL(1)
int printf (const char *__format, ...)
{
  register int __retval;
  __builtin_va_list __local_argv; __builtin_va_start( __local_argv, __format );
  __retval = __mingw_vprintf( __format, __local_argv );
  __builtin_va_end( __local_argv );
  return __retval;
}

So the incorrect output seems to come from __mingw_vprintf.

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[rcopley at gmail dot com]

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

--- Comment #6 from R Copley  ---
Created attachment 36490
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36490&action=edit
hexfloat-bug-2b.ii (see Comment 4)

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[rcopley at gmail dot com]

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

--- Comment #5 from R Copley  ---
Created attachment 36489
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36489&action=edit
hexfloat-bug-2a.ii (see Comment 4)

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[rcopley at gmail dot com]

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

--- Comment #4 from R Copley  ---
That's what I understood to be the case. Nevertheless, with the toolchain I am
using (see above for version; same command-line etc.), I get the results below. 

Both testcases below give the correct results with g++-4.8 on Ubuntu (the idea
of installing 5.2 seems to confuse and infuriate the community there), so I
think I must report this to the MinGW-W64 maintainers instead. Thanks.

#include 
int main () { printf ("%a", 0x1.08p+0); }
// Preprocessed source: see attachment "hexfloat-bug-2a.ii"
// Output: 0x1.08p+0

#include 
int main () { printf /*sic*/ ("%a", 0x108p+0); }
// Preprocessed source: see attachment "hexfloat-bug-2b.ii"
// Output: 0x0p-63

[Bug inline-asm/67944] GCC emits unnecessary push/pop for callee-save reads.

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #1 from Segher Boessenkool  ---
You're returning an uninitialised variable.  What do you expect this
code to do?

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Libstdc++ has no implementation of printf, so ::printf and std::printf are
exactly the same function, with std::printf defined as:

namespace std
{
  using ::printf;
}

[Bug inline-asm/67944] New: GCC emits unnecessary push/pop for callee-save reads.

[alex.reinking at gmail dot com]

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

Bug ID: 67944
   Summary: GCC emits unnecessary push/pop for callee-save reads.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: inline-asm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alex.reinking at gmail dot com
  Target Milestone: ---

When trying to return the current value of a register in a function via a local
register variable, the compiler will emit a useless push/pop instruction as in 
the following example:

C code:

unsigned int readEBX(void) {
register unsigned int reg asm("ebx");
return reg;
}

Assembly:

readEBX():
mov  eax, ebx
push ebx
pop  ebx
ret

This same pattern occurs for all callee-save registers: ebx, esi, edi, ebp
The code is properly-optimized for: eax, ecx, edx, esp

See also my StackOverflow question: 
See also this Godbolt* result: https://goo.gl/bzgt4P

  * Try substituting different registers to compare

[Bug tree-optimization/67909] [6 Regression] 416.gamess in SPEC CPU 2006 is miscompiled

[pthaugen at gcc dot gnu.org]

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

Pat Haugen  changed:

   What|Removed |Added

 CC||pthaugen at gcc dot gnu.org

--- Comment #2 from Pat Haugen  ---
(In reply to H.J. Lu from comment #1)
> It was caused by r228599.

I am also seeing a failure on gamess on powerpc64 starting with that revision.
In my case it's a verification error (miscompare of the output).

[Bug c/67925] docs lie about being unable to inline function call before definition

[arkadiusz at drabczyk dot org]

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

--- Comment #6 from Arkadiusz Drabczyk  ---
Sorry, this code is wrong of course, value returned by factorial() must be used
to generate an actual code:

$ cat bug1.c
#include 
#include 

inline static int factorial(unsigned int i)
{
   if(i <= 1)
   {
  return 1;
   }
   return i * factorial(i - 1);
}

int main(void)
{
printf("%d\n", factorial(12));
exit(0);
}
$ cat bug1.s
.file   "bug1.c"
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "%d\n"
.section.text.startup,"ax",@progbits
.p2align 4,,15
.globl  main
.type   main, @function
main:
.LFB22:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
movl$1, %esi
movl$12, %eax
.p2align 4,,10
.p2align 3
.L2:
imull   %eax, %esi
subl$1, %eax
cmpl$1, %eax
jne .L2
movl$.LC0, %edi
xorl%eax, %eax
callprintf
xorl%edi, %edi
callexit
.cfi_endproc
.LFE22:
.size   main, .-main
.ident  "GCC: (GNU) 6.0.0 20151004 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug c/67925] docs lie about being unable to inline function call before definition

[arkadiusz at drabczyk dot org]

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

--- Comment #5 from Arkadiusz Drabczyk  ---
-Winline is mentioned in the next paragraph. The whole sentence I posted in the
first comment is:

"Some calls cannot be integrated for various reasons (in particular, calls that
precede the function's definition cannot be integrated, and neither can
recursive calls within the definition)."

I think it's completely wrong - recursive functions can also be inlined:

$ ./gcc --version
gcc (GCC) 6.0.0 20151004 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ cat bug1.c
#include 
#include 

inline static int factorial(unsigned int i)
{
   if(i <= 1)
   {
  return 1;
   }
   return i * factorial(i - 1);
}

int main(void)
{
factorial(12);
exit(0);
}
$ ./gcc bug1.c -O2 -S
$ cat bug1.s
.file   "bug1.c"
.section.text.startup,"ax",@progbits
.p2align 4,,15
.globl  main
.type   main, @function
main:
.LFB22:
.cfi_startproc
subq$8, %rsp
.cfi_def_cfa_offset 16
xorl%edi, %edi
callexit
.cfi_endproc
.LFE22:
.size   main, .-main
.ident  "GCC: (GNU) 6.0.0 20151004 (experimental)"
.section.note.GNU-stack,"",@progbits

I attach a suggested patch.

[Bug c/67925] docs lie about being unable to inline function call before definition

[arkadiusz at drabczyk dot org]

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

--- Comment #4 from Arkadiusz Drabczyk  ---
Created attachment 36488
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36488&action=edit
suggested patch

[Bug c++/67917] ICE in openssl-1.0.2d.tar.gz "/usr/include/openssl/bn.h:335:3: error: TYPE_CANONICAL is not compatible"

[guille at cal dot berkeley.edu]

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

Guille  changed:

   What|Removed |Added

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

--- Comment #2 from Guille  ---
Just tried it with latest 
gcc version 6.0.0 20151011 (experimental) (GCC) 
and it works.

[Bug fortran/67744] polymorphic associating entity is refused TBP invocation

[Bader at lrz dot de]

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

--- Comment #3 from Bader at lrz dot de  ---
The question on validity is not unjustified. The 2008 standard appears to be
not fully clear on this, but the current 2015 draft has the following amended
text in para 2 of section 8.1.3.3:
---
The associating entity itself is a variable, but if the selector is not a
definable variable, the associating entity is not definable and shall not be
defined or become undefined. If the selector is not permitted to appear in a
variable definition context (16.6.7), the associate name shall not appear in a
variable definition context.
---

The first sentence, I think, implies that my code example is valid.

Cheers
Reinhold

[Bug fortran/67744] polymorphic associating entity is refused TBP invocation

[Bader at lrz dot de]

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

--- Comment #2 from Bader at lrz dot de  ---
The question on validity is not unjustified. The 2008 standard appears to be
not fully clear on this, but the current 2015 draft has the following amended
text in para 2 of section 8.1.3.3:
---
The associating entity itself is a variable, but if the selector is not a
definable variable, the associating entity is not definable and shall not be
defined or become undefined. If the selector is not permitted to appear in a
variable definition context (16.6.7), the associate name shall not appear in a
variable definition context.
---

The first sentence, I think, implies that my code example is valid.

Cheers
Reinhold

[Bug c++/67943] Friend declaration applied to base class, leading to allowing access to protected base

[barry.revzin at gmail dot com]

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

--- Comment #1 from Barry Revzin  ---
Actually, according to [class.base.access], this is valid code. Unless CWG 472
gets adopted I guess. In any case, disregard - my bad.

[Bug c++/67943] New: Friend declaration applied to base class, leading to allowing access to protected base

[barry.revzin at gmail dot com]

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

Bug ID: 67943
   Summary: Friend declaration applied to base class, leading to
allowing access to protected base
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

gcc 5.2 compiles the following:

struct Base { };
struct Derived : protected Base { };
struct Derived2 : public Derived {
friend void test();
};

void test() {
Derived a;
Base* p = &a;
}

int main(){
test();
}

If you comment out the friend declaration in Derived2, which should be
irrelevant to the example, then gcc reports an error that Base is an
inaccessible base of Derived.

[Bug c++/67942] diagnose placement new buffer overflow

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

--- Comment #1 from Martin Sebor  ---
A patch capable of detecting and diagnosing a limited subset of such overflows
will be posted for review shortly.  The output of the patch for the example
program in the Description is as follows:

$ g++ -Wall  u.cpp
u.cpp: In function ‘void f(S*)’:
u.cpp:22:27: warning: placement new constructing a 16-byte object of type ‘S’
in a region of type ‘char [8]’ that is 8 bytes large
 S *t = new (buf) S (*s);

[Bug c++/67942] New: diagnose placement new buffer overflow

[msebor at gcc dot gnu.org]

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

Bug ID: 67942
   Summary: diagnose placement new buffer overflow
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

C++ placement new expression is known to be subject to buffer overflow flaws
(see for example [1]).  For instance, in the program below, the placement new
expression writes past the end of the local buffer buf.  In many cases of its
use (including the one below), GCC has sufficient information to detect and
diagnose such defects.  This bug tracks the proposed implementation of this
detection.

#include 

struct S {
int a [4];
} s;

void f (S *s) {
char buf [sizeof s];
S *t = new (buf) S (*s);

// ...
}

A New Class of Buffer Overflow Attacks, Kundu, A., Bertino, E., 31st
International Conference on Distributed Computing Systems (ICDCS), 2011
http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5961725

[Bug tree-optimization/67815] Optimize const1 * copysign (const2, y) into copysign (const1 * const2, y) if const1 > 0 or -copysign (const1 * const2, y) if const1 < 0

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Comment on attachment 36487
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36487
r2

I think for copysign we don't want/need the first_pass_instance guard, and
likely also not flag_unsafe_math_optimizations, we want only be able to
reassociate, which can_reassociate_p should already guarantee, and then what
Joseph talked about for inexact.

[Bug sanitizer/67941] New: calls on function pointer from a captureless lambda cause ubsan warning

[blaffablaffa at gmail dot com]

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

Bug ID: 67941
   Summary: calls on function pointer from a captureless lambda
cause ubsan warning
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: blaffablaffa 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: ---

Test program: int main(){ (+[](){})(); }
Compilation: -std=c++11 -fsanitize=null
Wrong output: :1:20: runtime error: member call on null pointer of type
'const struct __lambda0'
Expected: no warning at all.

Note: if the cast to a function pointer is not performed (remove the +), there
is no warning, probably because the capture is still used, although empty.

[Bug tree-optimization/67815] Optimize const1 * copysign (const2, y) into copysign (const1 * const2, y) if const1 > 0 or -copysign (const1 * const2, y) if const1 < 0

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
Created attachment 36487
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36487&action=edit
r2

Untested preliminary patch.  I'm not sure about the floating-point matter in
there.

[Bug target/67940] Wrong stack alignment adjustment

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from H.J. Lu  ---
Fixed.

[Bug target/67940] Wrong stack alignment adjustment

[hjl at gcc dot gnu.org]

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

--- Comment #2 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Oct 12 17:36:21 2015
New Revision: 228732

URL: https://gcc.gnu.org/viewcvs?rev=228732&root=gcc&view=rev
Log:
Correct x86 backend stack alignment adjustment

Add missing -1 in x86 backend stack alignment adjustment.  Trunk is OK
with ROUND_UP macro.

PR target/67940
* config/i386/i386.c (ix86_compute_frame_layout): Correct
stack alignment adjustment.
(ix86_expand_prologue): Likewise.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c

[Bug libgcc/59412] __fixunsdfDI triggers wrong inexact exceptions

[jsm28 at gcc dot gnu.org]

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

--- Comment #1 from Joseph S. Myers  ---
Note that in addition to spurious "inexact" exceptions, this division can cause
spurious "underflow" exceptions when converting tiny values to integer 0. 
Other spurious exceptions can occur in overflow cases, when only "invalid"
should be raised, and the signed conversions wrapping this function can fail to
raise "invalid" for some overflow cases.

[Bug target/67940] Wrong stack alignment adjustment

[ubizjak at gmail dot com]

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

--- Comment #1 from Uroš Bizjak  ---
This doesn't need a PR. Just commit the (pre-approved) obvious patch.

[Bug target/67940] New: Wrong stack alignment adjustment

[hjl.tools at gmail dot com]

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

Bug ID: 67940
   Summary: Wrong stack alignment adjustment
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ubizjak at gmail dot com
  Target Milestone: ---

On gcc-5-branch, i386 has

  if (stack_realign_fp)
offset = (offset + stack_alignment_needed) & -stack_alignment_needed;
...
 to pass verification of stack_pointer_offset at the end.  */
  m->fs.sp_offset = (m->fs.sp_offset + align_bytes) & -align_bytes;

-1 is missing.

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[rcopley at gmail dot com]

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

--- Comment #2 from R Copley  ---
Thanks Jonathan. It's clear enough from what I wrote that:

(1) The same kind of incorrect output is produced by (a) including  and
using std::printf, and (b) using iostreams and std::hexfloat;

(2) The correct output is produced by including  and using ::printf.

I think (but I am by no means certain!) that (by (2)) my C library works, and
(by (1)) there is a problem with GCC's standard library implementation.

[Bug fortran/67939] ICE on using data with negative substring range

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
$ echo $LANG
de_DE.UTF-8
$ echo $LC_ALL

$ cat z3.f90
program p
   character(8) :: x
   data x(3:1) /'abc'/
end


$ gfortran -g -O0 z3.f90
z3.f90:3:17:

data x(3:1) /'abc'/
 1
Warning: Initialization string starting at (1) was truncated to fit the
variable (-1/3)
f951: malloc.c:2369: sysmalloc: Assertion `(old_top == (((mbinptr) (((char *)
&((av)->bins[((1) - 1) * 2])) - __builtin_offsetof (struct malloc_chunk, fd
&& old_size == 0) || ((unsigned long) (old_size) >= (unsigned
long)__builtin_offsetof (struct ...

[Bug fortran/67939] New: ICE on using data with negative substring range

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 67939
   Summary: ICE on using data with negative substring range
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Depending on compiler options the following codes
show different reactions (sometimes with hanging process).
Depending on environment settings too (e.g. $LANG, $LC_ALL).
All suffer from a negative substring-range (length < -1).


$ cat z1.f90
program p
   character(100) :: x
   data x(998:99) /'ab'/
end


$ cat z2.f90
program p
   character(2) :: x
   data x(:-1) /'ab'/
end


$ gfortran -c z1.f90
z1.f90:3:20:

data x(998:99) /'ab'/
1
Warning: Initialization string starting at (1) was truncated to fit the
variable (-898/2)
f951: internal compiler error: Segmentation fault


$ gfortran -c z2.f90
z2.f90:3:17:

data x(:-1) /'ab'/
 1
Warning: Initialization string starting at (1) was truncated to fit the
variable (-1/2)
*** Error in `/usr/lib64/gcc/x86_64-suse-linux/5/f951': malloc(): memory
corruption (fast): 0x01c03420 ***


$ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize -c z2.f90
z2.f90:3:17:

data x(:-1) /'ab'/
 1
Warning: Initialization string starting at (1) was truncated to fit the
variable (-1/2)
*** Error in `/usr/lib64/gcc/x86_64-suse-linux/5/f951': corrupted double-linked
list: 0x036d5db0 ***

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #29 from Uroš Bizjak  ---
Backported to gcc-5 branch.

[Bug fortran/67938] ICE on using assumed rank character with some intrinsics

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #1 from Gerhard Steinmetz  
---
$ cat z1.f90
program p
   implicit none
   character(1) :: z(3)
   call s(z)
contains
   subroutine s(x)
  character(1) :: x(..)
  print *, lbound(x)
  print *, ubound(x)
   end subroutine
end

$ gfortran z1.f90
z1.f90:8:0:

   print *, lbound(x)
 1
internal compiler error: in gfc_conv_descriptor_dtype, at
fortran/trans-array.c:251

---

$ cat z1s.f90
program p
   implicit none
   character(77) :: z(33)
   call s(z)
contains
   subroutine s(x)
  character(77) :: x(..)
  print *, size(x)
   end subroutine
end

$ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize z1s.f90
$ a.out
   0

[Bug fortran/67938] New: ICE on using assumed rank character with some intrinsics

[gerhard.steinmetz.fort...@t-online.de]

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

Bug ID: 67938
   Summary: ICE on using assumed rank character with some
intrinsics
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gerhard.steinmetz.fort...@t-online.de
  Target Milestone: ---

Knowing that assumed rank is preliminary f2015, but :


$ cat z2.f90
program p
   implicit none
   character(1) :: z(3)
   call s(z)
contains
   subroutine s(x)
  character(1) :: x(..)
  print *, lbound(x, dim=1)
  print *, ubound(x, dim=1)
  print *, size(x, dim=1)
   end subroutine
end


$ gfortran -c z2.f90
z2.f90:8:0:

   print *, lbound(x, dim=1)
 1
internal compiler error: in gfc_get_descriptor_dimension, at
fortran/trans-array.c:281


$ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize z2.f90
z2.f90:8:0:

   print *, lbound(x, dim=1)
 1
internal compiler error: in gfc_conv_descriptor_dtype, at
fortran/trans-array.c:251

[Bug fortran/67885] ICE on using parameter array in block

[gerhard.steinmetz.fort...@t-online.de]

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

--- Comment #4 from Gerhard Steinmetz  
---
Deleting the dimension from parameter a (making it scalar)
lets examples z1.f90 and z5.f90 compile and run fine.


$ cat y1.f90
program p
   block
  real, parameter :: a = 1.0
  real :: x(2)
  x = a
  print *, x
  block
 print *, x
  end block
  print *, x
   end block
end

$ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize y1.f90
$ a.out
   1.   1.
   1.   1.
   1.   1.

---

$ cat y5.f90
program p
   block
  real, parameter :: a = 1.0
  real :: x(2)
  x = a
  print *, x
   end block
end

$ gfortran -g -O0 -Wall -fcheck=all -fno-frontend-optimize y5.f90
$ a.out
   1.   1.

[Bug target/66697] Feature request: -mstackrealign and force_align_arg_pointer for x86_64

[uros at gcc dot gnu.org]

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

--- Comment #28 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Oct 12 16:29:37 2015
New Revision: 228728

URL: https://gcc.gnu.org/viewcvs?rev=228728&root=gcc&view=rev
Log:
Backport from mainline
2015-10-08  H.J. Lu  

* config/i386/i386.c (ix86_compute_frame_layout): Round up the
SSE register save area to 16 bytes only if the incoming stack
boundary is no less than 16 bytes.

Backport from mainline
2015-10-07  Uros Bizjak  

PR target/66697
* config/i386/i386.c (ix86_option_override_internal): Always use
8-byte minimum stack boundary in 64-bit mode.
(ix86_compute_frame_layout): Remove assert on INCOMING_STACK_BOUNDARY.
(ix86_emit_save_reg_using_mov): Support unaligned SSE store.
Add a REG_CFA_EXPRESSION note if needed.
(ix86_emit_restore_sse_regs_using_mov): Support unaligned SSE load.
(ix86_handle_force_align_arg_pointer_attribute): New.
(ix86_minimum_incoming_stack_boundary): Remove TARGET_64BIT check.
(ix86_attribute_table): Set ix86_force_align_arg_pointer_string
with ix86_handle_force_align_arg_pointer_attribute.
* config/i386/i386.h (MIN_STACK_BOUNDARY): Set to BITS_PER_WORD.

testsuite/ChangeLog:

Backport from mainline
2015-10-07  Uros Bizjak  

PR target/66697
* gcc.target/i386/20060512-1.c: Remove ia32 requirement.
(PUSH, POP): New defines.
(sse2_test): Use PUSH and POP to misalign runtime stack.
* gcc.target/i386/20060512-2.c: Remove ia32 requirement.


Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c
branches/gcc-5-branch/gcc/config/i386/i386.h
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/20060512-1.c
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/20060512-2.c

[Bug middle-end/67912] [6 Regression] ICE in gen_lowpart_common, at emit-rtl.c:1399

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||danglin at gcc dot gnu.org

--- Comment #4 from John David Anglin  ---
Also seen with hppa-unknown-linux-gnu.

[Bug gcov-profile/67937] gcov gives wrong results when negative counts are involved

[Pidgeot18 at gmail dot com]

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

--- Comment #2 from Joshua Cranmer  ---
Created attachment 36486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36486&action=edit
test-case.gcno

And the corresponding .gcno file.

The testcase was minimized by bisecting the original .gcda/.gcno files by
dropping functions and seeing where my attempt to write a new implementation
that matched gcov's output failed. The attempt (I did several!) that failed
this time was using Boost graph library's hawick_circuits detector, which
matched the input incorrectly since this is double-counting loop edges if one
of them is negative.

[Bug gcov-profile/67937] gcov gives wrong results when negative counts are involved

[Pidgeot18 at gmail dot com]

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

--- Comment #1 from Joshua Cranmer  ---
Created attachment 36485
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36485&action=edit
test-case.gcda

(It's a 4.7 test case, but the file format can still be read with trunk gcov
the last I checked. Since the originating issue comes from "compile Firefox", I
haven't tried preparing .gcda/.gcno files from newer gcc).

[Bug gcov-profile/67937] New: gcov gives wrong results when negative counts are involved

[Pidgeot18 at gmail dot com]

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

Bug ID: 67937
   Summary: gcov gives wrong results when negative counts are
involved
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Pidgeot18 at gmail dot com
  Target Milestone: ---

This is hard to name correctly, since there's really a bigger bug here, and I'm
focusing on the lesser bug because it's easier for me to build a minimized test
case.

First the explanation: for whatever reason, sometimes gcov produces counts with
negative edges (that's a bug by itself). An minimized example of such a case
will be attached to the bug. In this scenario, the graph looks like this:

 1147 +-+ -42
   /->|B|--\
  +-+ +-+ +-+
/>|A|  V 1189 |D| \
| +-+ +-+ +-+ |
|  \->|C|--/  |
\ 0   +-+ 1189/
 \---/
  23

(This is a result of an optimized loop, I don't have the corresponding code on
hand, sorry :-( ).

In this scenario, the loop detection code finds the following loops:
D -> A -> B -> C -> D: loop count = 23
D -> A -> B -> D: loop count = -42
D -> A -> C -> D: loop count = 0
A -> B -> C -> D -> A: loop count = 42
A -> B -> D -> A: loop count = 0
B -> C -> D -> A -> B: loop count = 0
C -> D -> A -> B -> C: loop count = 0

The last four loops are finding permutations of the three simple loops, which
is wrong (of course, the fact that one edge has a count of -42 in the first
place is wrong in the first place.

[Bug fortran/67936] New: Off-by-one columns in caret

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 67936
   Summary: Off-by-one columns in caret
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

In gcc/testsuite/gfortran.dg/associate_5.f03, if we enable
-fdiagnostics-show-caret, we get this diagnostic (amongst others):

associate_5.f03:33:6:

   y = 5 ! { dg-error "variable definition context" }
  1
associate_5.f03:32:20:

 ASSOCIATE (y => x) ! { dg-error "variable definition context" }
2
Error: Associate-name ‘y’ can not appear in a variable definition
context (assignment) at (1) because its target at (2) can not, either

Note how the carets 1 and 2 appear one column before the "y" and the "x" that
they refer to; I would have expected them to be one column to the right,
directly under the "y" and "x".

Noticed when porting Fortran to use a new implementation of
diagnostic_show_locus; this seems to be a pre-existing bug in the Fortran FE;
am updating my printer to faithfully print the (apparently erroneous)
locations.

[Bug bootstrap/67931] [6 Regression] Gcc [trunk revision 228704] failed to profiledbootstrap on x86_64

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-12
 CC||hubicka at ucw dot cz
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
It was caused by r228703.

[Bug c++/67935] internal compiler error: Segmentation fault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
markus@x4 test % cat main.ii
typedef struct { template  void m_fn1(); } base_t;

markus@x4 test % g++ -c main.ii
main.ii:1:54: internal compiler error: tree check: expected tree that contains
‘decl with visibility’ structure, have ‘template_decl’ in determine_visibility,
at cp/decl2.c:2291
 typedef struct { template  void m_fn1(); } base_t;
  ^
0xef9b34 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/gcc/tree.c:9694
0x6b71db contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc/gcc/tree.h:2978
0x6b71db determine_visibility(tree_node*)
../../gcc/gcc/cp/decl2.c:2291
0x6baa87 reset_decl_linkage
../../gcc/gcc/cp/decl2.c:2665
0x6bac74 reset_type_linkage_2
../../gcc/gcc/cp/decl2.c:2693
0x61447d grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/gcc/cp/decl.c:10699
0x614fe6 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
../../gcc/gcc/cp/decl.c:4769
0x707390 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:18088
0x707f35 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:12007
0x703403 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:11881
0x7118a7 cp_parser_declaration
../../gcc/gcc/cp/parser.c:11778
0x70fe2a cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:11657
0x710149 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4174
0x710149 c_parse_file()
../../gcc/gcc/cp/parser.c:34695
0x85b752 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1064
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/66790] Invalid uninitialized register handling in REE

[derodat at adacore dot com]

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

--- Comment #43 from Pierre-Marie de Rodat  ---
(In reply to Bernd Schmidt from comment #42)
> I don't think that would actually help. Even if something is an actual
> incoming argument register, it may still be uninitialized by the caller.
Sure, but my understanding is that what matters in DF is what happens inside
the function, so we can assume arguments are always initialized.

Actually this makes sense in the context of REE as well: we have one
(artificial) def for arguments so since this def has no corresponding
instruction, REE will not be able to remove z-extensions reaching this def.

That being said, I failed to get the “is it really used for incoming arguments”
hard-reg predicate, so falling back to your proposal: I will followup on
gcc-patches@.

Thanks! :-)

[Bug c++/67934] [concepts] ICE when providing default function implementations using concepts

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
It is a stack overflow. Could be a dup of PR67595.

[Bug tree-optimization/66070] [GRAPHITE] cc1 gets killed by OOM killer

[spop at gcc dot gnu.org]

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

--- Comment #4 from Sebastian Pop  ---
r227572

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

[niqingliang2003 at gmail dot com]

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

Bug ID: 67935
   Summary: internal compiler error: Segmentation fault
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: niqingliang2003 at gmail dot com
  Target Milestone: ---

Created attachment 36484
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36484&action=edit
compiled with command: g++ -std=c++11 main.cpp

main.cpp is the smallest code for generating the compiling error.
compile command: g++ -std=c++11 main.cpp
platform: archlinux
gcc version: 5.2

error info:
internal compiler error: Segmentation fault
  void serialize(_T & o)

workaround 1:
change 'typedef struct { ... } base_t' to 'typedef struct xxx {...} base_t'

workaround 2:
move the '#include ' in the first line.


when change the 'array' to 'vector' (both header and declaration of 'p' in
base_t), result become:

internal compiler error: Segmentation fault
 typedef struct {
^

[Bug debug/67192] [6 Regression] Backward-goto in loop can get wrong line number

[arnez at linux dot vnet.ibm.com]

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

--- Comment #20 from Andreas Arnez  ---
Posted a patch that is not as ambitious as completely getting rid of
input_location, but also doesn't require a new function like
c_parser_peek_token_keep_input_location():

  https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01132.html

[Bug c++/67834] [5 Regression] Local references inside comdat groups

[danglin at gcc dot gnu.org]

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

--- Comment #4 from John David Anglin  ---
I suppose this is a package bug but it is present in a number
of packages:

static inline void handle_overflow_nop(void){}

class recv_packet_handler{
public:
  ...
private:
vrt_unpacker_type _vrt_unpacker;
size_t _header_offset_words32;
double _tick_rate, _samp_rate;
bool _queue_error_for_next_call;
size_t _alignment_faulure_threshold;
rx_metadata_t _queue_metadata;
struct xport_chan_props_type{
xport_chan_props_type(void):
packet_count(0),
handle_overflow(&handle_overflow_nop),
fc_update_window(0)
{}
get_buff_type get_buff;
issue_stream_cmd_type issue_stream_cmd;
size_t packet_count;
handle_overflow_type handle_overflow;
handle_flowctrl_type handle_flowctrl;
size_t fc_update_window;
};
...
};

Should there be a warning about a potential dangling reference?

[Bug c++/67934] New: [concepts] ICE when providing default function implementations using concepts

[michel.steuwer at gmail dot com]

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

Bug ID: 67934
   Summary: [concepts] ICE when providing default function
implementations using concepts
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michel.steuwer at gmail dot com
  Target Milestone: ---

Created attachment 36483
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36483&action=edit
Contains test case with preprocessed file.

The following code fails with an ICE:

===
#include 

template 
concept bool
JustEqualityComparable() {
  return requires(T a, T b) {
{ a == b } -> bool;
  };
}

template 
concept bool
JustInequalityComparable() {
  return requires(T a, T b) {
{ a != b } -> bool;
  };
}

bool operator==(const JustInequalityComparable& a1,
const JustInequalityComparable& a2) {
  return !(a1 != a2);
}

bool operator!=(const JustEqualityComparable& a1,
const JustEqualityComparable& a2) {
  return !(a1 == a2);
}

template 
  requires JustEqualityComparable()
bool useEq(T t1, T t2) {
  return t1 == t2;
}

struct A {
  int a;
};

bool operator==(const A& a1, const A& a2) {
  return a1.a == a2.a;
}

int main() {
  using namespace std;

  cout << boolalpha << useEq(A{4}, A{6}) << "\n";

  return 0;
}

===
~/bin/gcc/bin/g++ -std=c++1z -save-temps foo.cpp
g++: internal compiler error: Segmentation fault (program cc1plus)


Removing either the operator in line 19 or 24 makes the program compile.
Replacing the operator implemented with concepts in line 19 by a plain template
version makes the program compile as well.

[Bug tree-optimization/67476] Add --param parloops-schedule=

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org ---
Author: vries
Date: Mon Oct 12 14:14:11 2015
New Revision: 228717

URL: https://gcc.gnu.org/viewcvs?rev=228717&root=gcc&view=rev
Log:
Handle simple latch in expand_omp_for_generic

2015-10-12  Tom de Vries  

PR tree-optimization/67476
* omp-low.c (expand_omp_for_generic): Handle simple latch.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c

[Bug tree-optimization/67476] Add --param parloops-schedule=

[vries at gcc dot gnu.org]

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

--- Comment #10 from vries at gcc dot gnu.org ---
Author: vries
Date: Mon Oct 12 14:14:22 2015
New Revision: 228718

URL: https://gcc.gnu.org/viewcvs?rev=228718&root=gcc&view=rev
Log:
Add missing phis in expand_omp_for_generic

2015-10-12  Tom de Vries  

PR tree-optimization/67476
* omp-low.c (expand_omp_for_generic): Add missing phis.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/omp-low.c

[Bug fortran/67933] New: [4.9/5/Trunk Regression] ICE for array of a derived type with allocatable class in derived type object

[mandrew9 at vt dot edu]

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

Bug ID: 67933
   Summary: [4.9/5/Trunk Regression] ICE for array of a derived
type with allocatable class in derived type object
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mandrew9 at vt dot edu
  Target Milestone: ---

Created attachment 36482
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36482&action=edit
small test case (source code)

Description: 
Create a derived type object (list_t) that contains an array of a derived type
(wrapper_t). This derived type (wrapper_t) contains an allocatable class
(class_t). Whenever the object is referenced (as in Method), an ICE is thrown.
Replacing the allocatable class in the derived type (wrapper_t) with an
allocatable derived type or primitive type allows the module to compile.

test_mod.f95 (Also attached):

module test_mod
  implicit none

  type :: class_t
  end type class_t

  type :: wrapper_t
class(class_t), allocatable  :: class_var
!type(class_t), allocatable  :: class_var
!integer,   allocatable  :: class_id
  end type wrapper_t

  type :: list_t
type(wrapper_t) :: classes(10)
  contains
procedure :: Method
  end type list_t

contains
  subroutine Method(this)
class(list_t) :: this
  contains
! Do stuff
  end subroutine Method
end module test_mod

Compiler: gcc version 4.9.3/5/Trunk
System:   x86_64-redhat-linux

Command line: gfortran test_mod.f95
Output (with gcc 6.0.0 20151009 (experimental)): 
test_mod.f95:23:0:

 end module test_mod
1
internal compiler error: in gfc_conv_expr_descriptor, at
fortran/trans-array.c:6684
0x6aabeb gfc_conv_expr_descriptor(gfc_se*, gfc_expr*)
../../../packages/gcc_svn/gcc/fortran/trans-array.c:6684
0x6cf613 gfc_trans_pointer_assignment(gfc_expr*, gfc_expr*)
../../../packages/gcc_svn/gcc/fortran/trans-expr.c:7854
0x6cfd1e gfc_reset_vptr(stmtblock_t*, gfc_expr*)
../../../packages/gcc_svn/gcc/fortran/trans-expr.c:360
0x6fc495 gfc_trans_deallocate(gfc_code*)
../../../packages/gcc_svn/gcc/fortran/trans-stmt.c:6070
0x698937 trans_code
../../../packages/gcc_svn/gcc/fortran/trans.c:1802
0x6f1f63 gfc_trans_if_1
../../../packages/gcc_svn/gcc/fortran/trans-stmt.c:1106
0x6f821a gfc_trans_if(gfc_code*)
../../../packages/gcc_svn/gcc/fortran/trans-stmt.c:1137
0x698a27 trans_code
../../../packages/gcc_svn/gcc/fortran/trans.c:1740
0x6f9611 gfc_trans_simple_do
../../../packages/gcc_svn/gcc/fortran/trans-stmt.c:1671
0x6f9611 gfc_trans_do(gfc_code*, tree_node*)
../../../packages/gcc_svn/gcc/fortran/trans-stmt.c:1834
0x6989fa trans_code
../../../packages/gcc_svn/gcc/fortran/trans.c:1752
0x6bb963 gfc_generate_function_code(gfc_namespace*)
../../../packages/gcc_svn/gcc/fortran/trans-decl.c:5900
0x69bcc1 gfc_generate_module_code(gfc_namespace*)
../../../packages/gcc_svn/gcc/fortran/trans.c:2014
0x65554d translate_all_program_units
../../../packages/gcc_svn/gcc/fortran/parse.c:5533
0x65554d gfc_parse_file()
../../../packages/gcc_svn/gcc/fortran/parse.c:5752
0x695cf2 gfc_be_parse_file
../../../packages/gcc_svn/gcc/fortran/f95-lang.c:209
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

Configured with: ../../packages/gcc_svn/configure
--prefix=/l/mandrew9/Software/installs/gcc/gcc-trunk --with-cpu=generic
--build=x86_64-redhat-linux --enable-threads=posix --enable-checking=release
--enable-languages=fortran,c,c++ --disable-multilib

[Bug libstdc++/67932] Incorrect conversion to hexfloat

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
Your preprocessed source doesn't use std::hexfloat, so any problem comes from
std::printf, which is part of your C library not part of GCC.

[Bug target/67919] GCC Compiler failed with "gcc-5.2.0/gcc/expr.c:6529:1: internal compiler error: output_operand: invalid shift operand"

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target
Version|5.2.0   |4.6.0
   Severity|blocker |normal

--- Comment #2 from Andrew Pinski  ---
The problem is not with gcc 5.2 but rather with the 4.6 that is included with
your machine. Try building 4.7 and then build 5.2.

[Bug c++/51048] Class template inheritance doesn't work well with function-local types

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||rodrigc at gcc dot gnu.org

--- Comment #10 from Paolo Carlini  ---
*** Bug 67888 has been marked as a duplicate of this bug. ***

[Bug c++/67888] Compiling clang 3.7.0 results in is used but never defined

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #9 from Paolo Carlini  ---
Done. I'm resolving this one as Dup of c++/51048.

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

[Bug c++/51048] Class template inheritance doesn't work well with function-local types

[paolo at gcc dot gnu.org]

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

--- Comment #9 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Mon Oct 12 13:15:30 2015
New Revision: 228714

URL: https://gcc.gnu.org/viewcvs?rev=228714&root=gcc&view=rev
Log:
/cp
2015-10-12  Paolo Carlini  

Backport from mainline
2015-06-15  Paolo Carlini  

PR c++/51048
* decl2.c (no_linkage_error): Do not issue a permerror if the DECL
using a local type is pure virtual.

/testsuite
2015-10-12  Paolo Carlini  

Backport from mainline
2015-06-15  Paolo Carlini  

PR c++/51048
* g++.dg/cpp0x/local-type1.C: New.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/local-type1.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/decl2.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug libstdc++/67932] New: Incorrect conversion to hexfloat

[rcopley at gmail dot com]

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

Bug ID: 67932
   Summary: Incorrect conversion to hexfloat
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rcopley at gmail dot com
  Target Milestone: ---

Created attachment 36481
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36481&action=edit
Preprocessed source file that demonstrates incorrect conversion from
floating-point value to string in hexfloat format

In GCC 5.2, in C++11, converting a floating-point value to a string in
hexadecimal floating-point (hexfloat) format gives incorrect results. The same
incorrect results occur when using std::printf from  or using the
iostreams manipulator std::hexfloat. Using printf from  gives the
correct results (even in C++).

Output of gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=C:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/5.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-5.2.0/configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysroot=/c/mingw520/x86_64-520-posix-seh-rt_v4-rev0/mingw64
--with-gxx-include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared
--enable-static --disable-multilib
--enable-languages=c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes
--enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto
--enable-graphite --enable-checking=release --enable-fully-dynamic-string
--enable-version-specific-runtime-libs --disable-isl-version-check
--disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona
--with-tune=core2 --with-libiconv --with-system-zlib
--with-gmp=/c/mingw520/prerequisites/x86_64-w64-mingw32-static
--with-mpfr=/c/mingw520/prerequisites/x86_64-w64-mingw32-static
--with-mpc=/c/mingw520/prerequisites/x86_64-w64-mingw32-static
--with-isl=/c/mingw520/prerequisites/x86_64-w64-mingw32-static
--with-pkgversion='x86_64-posix-seh-rev0, Built by MinGW-W64 project'
--with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-I/c/mingw520/x86_64-520-posix-seh-rt_v4-rev0/mingw64/opt/include
-I/c/mingw520/prerequisites/x86_64-zlib-static/include
-I/c/mingw520/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2
-pipe -I/c/mingw520/x86_64-520-posix-seh-rt_v4-rev0/mingw64/opt/include
-I/c/mingw520/prerequisites/x86_64-zlib-static/include
-I/c/mingw520/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS=
LDFLAGS='-pipe -L/c/mingw520/x86_64-520-posix-seh-rt_v4-rev0/mingw64/opt/lib
-L/c/mingw520/prerequisites/x86_64-zlib-static/lib
-L/c/mingw520/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 5.2.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 

Complete command line that triggers the bug:
g++ -save-temps -std=c++11 -o hexfloat-bug.exe hexfloat-bug.cpp &&
hexfloat-bug.exe

Compiler output: none.

Preprocessed source file: see attached.

Expected program output:
1.0002e+000 0x1.1p+00x1.00p+0
1.0036e+000 0x1.00010p+00x1.00p+0
1.0568e+000 0x1.00100p+00x1.00p+0
1.9095e+000 0x1.01000p+00x1.00p+0
1.00145519e+000 0x1.1p+00x1.00p+0
1.02328306e+000 0x1.00010p+00x1.00p+0
1.37252903e+000 0x1.00100p+00x1.00p+0
1.000596046448e+000 0x1.01000p+00x1.01p+0
1.009536743164e+000 0x1.1p+00x1.10p+0
1.152587890625e+000 0x1.00010p+00x1.000100p+0

Actual program output:
1.0002e+000 0x8.0p-55   0x8p-55
1.0036e+000 0x8.0p-51   0x8p-51
1.0568e+000 0x8.0p-47   0x8p-47
1.9095e+000 0x8.0p-43   0x8p-43
1.00145519e+000 0x8.0p-39   0x8p-39
1.02328306e+000 0x8.0p-35   0x8p-35
1.37252903e+000 0x8.00800p-30x0p-63
1.000596046448e+000 0x8.08000p-30x0p-63
1.009536743164e+000 0x0.0p-55   0x0p-63
1.152587890625e+000 0x0.0p-55   0x0p-63

[Bug other/67552] [meta] x86 interrupt attribute

[hjl.tools at gmail dot com]

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

Bug 67850 Summary: Wrong call_used_regs used in aggregate_value_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67850

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug target/67850] Wrong call_used_regs used in aggregate_value_p

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.3

--- Comment #4 from H.J. Lu  ---
Fixed for 5.3 and 6. No plan to backpor it to 4.9.

[Bug ipa/67783] [4.9/5 Regression] quadratic time consumption in IPA inlining with -O1 and higher

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Mon Oct 12 12:26:02 2015
New Revision: 228710

URL: https://gcc.gnu.org/viewcvs?rev=228710&root=gcc&view=rev
Log:
2015-10-12  Richard Biener  

PR ipa/67783
* ipa-inline-analysis.c (estimate_function_body_sizes): Re-add
code that analyzes IVs on each stmt but in a cheaper way avoiding
quadratic behavior.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline-analysis.c

[Bug target/67850] Wrong call_used_regs used in aggregate_value_p

[hjl at gcc dot gnu.org]

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

--- Comment #3 from hjl at gcc dot gnu.org  ---
Author: hjl
Date: Mon Oct 12 12:26:09 2015
New Revision: 228711

URL: https://gcc.gnu.org/viewcvs?rev=228711&root=gcc&view=rev
Log:
Merge ix86_maybe_switch_abi with ix86_set_current_function

ix86_maybe_switch_abi is called to late during RTL expansion and we
use the stale information from compilation of the previous function.
aggregate_value_p uses call_used_regs.  aggregate_value_p is used by
IPA and return value optimization, which are called before
ix86_maybe_switch_abi is called.  This patch merges ix86_maybe_switch_abi
with ix86_set_current_function.

Backport from mainline:

PR target/67850
* config/i386/i386.c (ix86_maybe_switch_abi): Merged with ...
(ix86_set_current_function): This.
(TARGET_EXPAND_TO_RTL_HOOK): Removed.

Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/i386.c

[Bug c/67930] segmentation fault

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Marek Polacek  ---
You're trying to modify a string literal.  That's no-no.

[Bug bootstrap/67931] New: [6 Regression] Gcc [trunk revision 228704] failed to profiledbootstrap on x86_64

[hjl.tools at gmail dot com]

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

Bug ID: 67931
   Summary: [6 Regression] Gcc [trunk revision 228704] failed to
profiledbootstrap on x86_64
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

Gcc [trunk revision 228704] failed to profiledbootstrap on x86_64
when configured with

../src-trunk/configure \
 --prefix=/usr/6.0.0 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-libmpx
--with-build-config=bootstrap-lto --disable-werror --with-fpmath=sse
--enable-languages=c,c++,fortran,java,lto,objc

https://gcc.gnu.org/ml/gcc-regression/2015-10/msg00132.html:

0x732c0f symtab_node::verify()
../../src-trunk/gcc/symtab.c:1084
0x738bbc cgraph_node::verify_cgraph_nodes()
../../src-trunk/gcc/cgraph.c:3201
0x75b8db symbol_table::materialize_all_clones()
../../src-trunk/gcc/cgraphclones.c:1151
0x756304 symbol_table::compile()
../../src-trunk/gcc/cgraphunit.c:2431
0x63fda7 lto_main()
../../src-trunk/gcc/lto/lto.c:3292
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[7]: *** [/tmp/ccKzjD0G.ltrans2.ltrans.o] Error 1
make[7]: *** Waiting for unfinished jobs
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/local/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Makefile:2644: recipe for target 'build/genconstants' failed

Revision 228700 is OK.

[Bug c/67930] New: segmentation fault

[ka_bena at yahoo dot fr]

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

Bug ID: 67930
   Summary: segmentation fault
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ka_bena at yahoo dot fr
  Target Milestone: ---

# include 
# include 

void test ( char **A )
{
 *A[0] = 'a' ;
}

int main( void)
{
 char *b = "omega" ;

 test ( &b ) ;

 printf ( "b = %s \n" , b ) ;

 return 0 ;

}

/*
RESULTS::
Segmentation fault (core dumped)
Exited: 35584

 gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)
 gcc -std=gnu99 -omain_pointer.exe main_pointer.c ;
*/

[Bug target/67849] AVX512 Hitting upper-bank register on extract insn split

[afomin.mailbox at gmail dot com]

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

Alexander Fomin  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #4 from Alexander Fomin  ---
See messages above.

[Bug target/67849] AVX512 Hitting upper-bank register on extract insn split

[kyukhin at gcc dot gnu.org]

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

--- Comment #3 from Kirill Yukhin  ---
Author: kyukhin
Date: Mon Oct 12 11:03:56 2015
New Revision: 228709

URL: https://gcc.gnu.org/viewcvs?rev=228709&root=gcc&view=rev
Log:
PR target/67849
gcc/
* config/i386/sse.md (define_split vec_select/V8FI): Restrict
split for upper-bank registers when target does not support
AVX512VL.
(define_insn "vec_extract_lo_"): Restrict
split when target does not support AVX512VL.
gcc/testsuite/
* gcc.target/i386/pr67480.c: New test.


Added:
branches/gcc-5-branch/gcc/testsuite/gcc.target/i386/pr67480.c
Modified:
branches/gcc-5-branch/gcc/ChangeLog
branches/gcc-5-branch/gcc/config/i386/sse.md
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug target/67929] [4.9/5/6 Regression][arm] Wrong code for FP mult-by-power-of-2 + int conversion

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ktkachov at gcc dot 
gnu.org

--- Comment #1 from ktkachov at gcc dot gnu.org ---
I have a fix

[Bug target/67929] New: [4.9/5/6 Regression][arm] Wrong code for FP mult-by-power-of-2 + int conversion

[ktkachov at gcc dot gnu.org]

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

Bug ID: 67929
   Summary: [4.9/5/6 Regression][arm] Wrong code for FP
mult-by-power-of-2 + int conversion
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: arm*

Testcase:

int
foo (float a)
{
  return a * 4.9f;
}


int
main (void)
{
  if (foo (10.0f) != 49)
__builtin_abort ();

  return 0;
}

Compiled with -Ofast -mfpu=vfpv3 -mfloat-abi=hard -mcpu=cortex-a15 -fno-inline
aborts.

The problem is foo (10.0f) returns 40.
This is because the combine_vcvtf2i triggers where its predicate should have
rejected 4.9f

The vfp3_const_double_for_bits function in arm.c is too liberal and accepts any
FP constant that, when truncated, evaluates to a power of 2 FP constant.

[Bug c++/61362] g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2 does not compile lambda with template

[thibaut.lutz at googlemail dot com]

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

--- Comment #6 from Thibaut LUTZ  ---
My previous test cases still fails with 6.0.0 20151012 on linux64.
It passes with "-std=c++11".
Fails with "-std=c++14", "-std=c++17", "-std=c++1y".

Same error:
prog.cc: In instantiation of ‘struct S::’:
prog.cc:3:29:   required from here
prog.cc:3:10: internal compiler error: in tsubst_copy, at cp/pt.c:13708
   int f{[this](){return 42;}()};

[Bug rtl-optimization/67715] [6 Regression][ARM] ICE in cselib.c during reload_cse_regs

[renlin at gcc dot gnu.org]

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

renlin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||renlin at gcc dot gnu.org

--- Comment #2 from renlin at gcc dot gnu.org ---
I have check that this ICE has been fixed by the target patch here:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00609.html

It's exactly the same type of error. The patch has already been committed on
trunk as r228662.

[Bug libstdc++/63176] std::generate_canonical::digits>() generates 1.0f

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
Meh. Don't use generate_canonical then.

[Bug tree-optimization/66070] [GRAPHITE] cc1 gets killed by OOM killer

[steffen at hauihau dot de]

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

--- Comment #3 from Steffen Hau  ---
Could you please provide the corresponding revision which fixed the issue?

[Bug fortran/67779] Strange ordering with strings in extended object

[arjen.markus895 at gmail dot com]

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

--- Comment #7 from Arjen Markus  ---
Yes, I can confirm this - I also tried with the Intel Fortran compiler and that
sorts the integers and strings in the way one would expect.

[Bug c++/67928] New: Ambiguous call not diagnosed

[alexpolt at yandex dot ru]

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

Bug ID: 67928
   Summary: Ambiguous call not diagnosed
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexpolt at yandex dot ru
  Target Milestone: ---

In the following code the call to 'print' is not diagnosed as ambiguous. Clang
is ok.

void print() {}

template
void print( const T& arg1, const types&... args );

template
void print( const T& arg1, const types&... args ) {
print( args... );
}

template
void print( const T& arg1, const types&... args ) {
print( args... );
}


struct test { void to_string() const {} };

int main() {
print( test{}, 1 );
}

gcc version 5.2.0 (GCC-explorer-build)
Target: x86_64-linux-gnu
Options: -O2 -std=c++14 -Wall -pedantic
Link to godbolt: http://goo.gl/iBMNJK

[Bug tree-optimization/67908] gcc segfaults with -fstack-check (internal compiler error) / armv7 host and target

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|WAITING |NEW
  Component|middle-end  |tree-optimization

--- Comment #3 from Eric Botcazou  ---
> The distribution's compiler is built without debug symbols. I need to
> rebuild, which may take a while.

I'll try harder with a cross then.

> Here's the output of gdb in case it helps anyways:

At least it means that the problem won't occur on the mainline.

[Bug middle-end/67908] gcc segfaults with -fstack-check (internal compiler error) / armv7 host and target

[gcc-bugs at zahlenfresser dot de]

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

--- Comment #2 from Stefan Keller  ---
The distribution's compiler is built without debug symbols. I need to rebuild,
which may take a while.
Here's the output of gdb in case it helps anyways:

Reading symbols from
/usr/lib/gcc/armv7l-unknown-linux-gnueabihf/5.2.0/cc1...(no debugging symbols
found)...done.

Program received signal SIGSEGV, Segmentation fault.
0x006320b8 in ?? ()
(gdb) bt
#0  0x006320b8 in ?? ()
#1  0x00697a0c in
substitute_and_fold_dom_walker::before_dom_children(basic_block_def*) ()
#2  0x009c54ec in dom_walker::walk(basic_block_def*) ()
#3  0x00697438 in substitute_and_fold(tree_node* (*)(tree_node*), bool
(*)(gimple_stmt_iterator*), bool) ()
#4  0x0062971c in ?? ()
#5  0x00629f48 in ?? ()
#6  0x004cb2b4 in execute_one_pass(opt_pass*) ()
#7  0x004cb6ec in ?? ()
#8  0x004cb704 in ?? ()
#9  0x004cb744 in execute_pass_list(function*, opt_pass*) ()
#10 0x00271744 in cgraph_node::expand() ()
#11 0x00272b7c in ?? ()
#12 0x00274164 in symbol_table::finalize_compilation_unit() ()
#13 0x0018391c in c_write_global_declarations() ()
#14 0x00573900 in ?? ()
#15 0x0016d380 in toplev::main(int, char**) ()
#16 0x0016dfac in main ()

[Bug c++/67888] Compiling clang 3.7.0 results in is used but never defined

[jason at gcc dot gnu.org]

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

--- Comment #8 from Jason Merrill  ---
(In reply to Paolo Carlini from comment #7)
> I have no objections, the patch seems safe to backport. Jason, shall I go
> ahead if it regtests Ok on the branch?

Sure.

[Bug libstdc++/67922] std::unordered_map::clear should take time linear in the number of elements

[yegor.derevenets at gmail dot com]

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

--- Comment #2 from Yegor Derevenets  ---
> But then the issue is that clear () doesn't shrink the map.
No, the issue is that clear() touches all the buckets, instead of touching only
those containing the elements. libc++'s implementation does not shrink the map
(does not decrease the number of buckets), and is still fast. Actually, if in
libstdc++ you do m.erase(m.begin(), m.end()) instead of m.clear(), it will be
fast too.

#include 
#include 

int main() {
std::unordered_map m;
for (int i = 0; i < 100; ++i) {
m[i] = i;
}
std::cout << "Before clear(): " << m.bucket_count() << std::endl;
m.clear();
std::cout << "After clear(): " << m.bucket_count() << std::endl;
}

$ clang++-3.7 -stdlib=libstdc++ -O2 -std=c++11 test.cpp && time ./a.out
Before clear(): 1056323
After clear(): 1056323

real0m0.074s
user0m0.076s
sys 0m0.000s

$ clang++-3.7 -stdlib=libc++ -O2 -std=c++11 test.cpp && time ./a.out
Before clear(): 1646237
After clear(): 1646237

real0m0.102s
user0m0.080s
sys 0m0.016s

[Bug middle-end/67908] gcc segfaults with -fstack-check (internal compiler error) / armv7 host and target

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-10-12
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
I cannot reproduce with a cross.  Please run the cc1 command from within GDB:

/usr/lib/gcc/armv7l-unknown-linux-gnueabihf/5.2.0/cc1 -fpreprocessed test.i
-quiet -dumpbase test.c -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16
-mtls-dialect=gnu -auxbase-strip test.o -g -O2 -O3 -Wall -Wno-unused-result
-Wno-unused-variable -std=gnu99 -version -fstack-check=specific
-fstack-protector -ffast-math --param ssp-buffer-size=4 -o test.s

and post a backtrace.  And note that the implementation of -fstack-check on ARM
is suboptimal and buggy in the 4.x and 5.x compilers; there is a new one on the
mainline (future 6.x compilers).

[Bug c++/54367] [meta-bug] lambda expressions

[ville.voutilainen at gmail dot com]

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

Bug 58566 Summary: [c++11] ICE with invalid expression in lambda body
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58566

   What|Removed |Added

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

[Bug c++/58566] [c++11] ICE with invalid expression in lambda body

[ville.voutilainen at gmail dot com]

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

Ville Voutilainen  changed:

   What|Removed |Added

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

--- Comment #7 from Ville Voutilainen  ---
Fixed on trunk.

[Bug c++/58566] [c++11] ICE with invalid expression in lambda body

[ville at gcc dot gnu.org]

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

--- Comment #6 from ville at gcc dot gnu.org ---
Author: ville
Date: Mon Oct 12 08:55:19 2015
New Revision: 228706

URL: https://gcc.gnu.org/viewcvs?rev=228706&root=gcc&view=rev
Log:
PR c++/58566

/cp
2015-10-12  Ville Voutilainen  

PR c++/58566
* lambda.c (lambda_return_type): Return error_mark_node
instead of void_type_node for the error cases.

/testsuite
2015-10-12  Ville Voutilainen  

PR c++/58566
* g++.dg/cpp0x/lambda/lambda-58566.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-58566.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/lambda.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/67888] Compiling clang 3.7.0 results in is used but never defined

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #7 from Paolo Carlini  ---
I have no objections, the patch seems safe to backport. Jason, shall I go ahead
if it regtests Ok on the branch?

[Bug ipa/62051] [4.9/5/6 Regression] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively

[jason at gcc dot gnu.org]

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

--- Comment #9 from Jason Merrill  ---
Created attachment 36480
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36480&action=edit
visibility flag patch

Is this the sort of thing you had in mind?

[Bug ipa/67600] [5/6 Regression] Segfault when assigning only one char to ostreambuf_iterator compiled with -O2 or -O3

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #3 from Jan Hubicka  ---
Mine.

[Bug rtl-optimization/67864] [6 Regression] CSiBE size regression

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
No difference for x86 (but that may have been expected)

[Bug ipa/67056] [5/6 regression] Wrong code generated

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #13 from Jan Hubicka  ---
Will take a look.

[Bug ipa/66738] [5/6 Regression] optimizer bug related to exceptions and static symbols

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #5 from Jan Hubicka  ---
Mine

[Bug c/67925] docs lie about being unable to inline function call before definition

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Patches welcome ;)  I think refering to -Winline here might make most sense.