[Bug target/71286] New: 6.1.0: compiling djgpp programs with LTO emits "visibility attribute not supported in this configuration" warnings

[felix.von.s at posteo dot de]

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

Bug ID: 71286
   Summary: 6.1.0: compiling djgpp programs with LTO emits
"visibility attribute not supported in this
configuration" warnings
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix.von.s at posteo dot de
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: i686-pc-msdosdjgpp
 Build: x86_64-pc-linux-gnu

Compiling djgpp programs with LTO enabled makes gcc emit diagnostics like:

error: visibility attribute not supported in this configuration; ignored
[-Werror=attributes]

The source code doesn't even contain __attribute__((visibility(...))) anywhere,
however.

I believe a similar problem is worked around in the MinGW target by defining a
custom TARGET_ASM_ASSEMBLE_VISIBILITY.

(Also, getting LTO to work in the first place required me to apply this:)
--- configure
+++ configure
@@ -6177,7 +6177,7 @@
   # Among non-ELF, only Windows platforms support the lto-plugin so far.
   # Build it unless LTO was explicitly disabled.
   case $target in
-*-cygwin* | *-mingw*) build_lto_plugin=$enable_lto ;;
+*-cygwin* | *-mingw* | *djgpp*) build_lto_plugin=$enable_lto ;;
 *) ;;
   esac

(The comment needs updating too, by the way.)

Broken connect syscall invocation ?

[Artem Polyakov]

Hello,

I'm using the following version of GCC:
artpol@artpol-ThinkPad-T430 ~ $ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4
Copyright (C) 2013 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.

I'm facing the problem with the slurm compilation:
https://github.com/SchedMD/slurm
I'm building the master branch. And the problem I get is related to the 
following construction:
https://github.com/SchedMD/slurm/blob/master/src/slurmd/slurmd/req.c#L6171:L6172

The problem I see is that "connect" returns "+1" instead of "-1". And I can't 
reproduce this with the standalone code:
https://github.com/artpol84/poc/blob/master/linux-internals/syscalls/connect/cli_c1.c#L37

Here is what GDB shows for those 2 codes:

SLURM's req.c:
0x43e966 <_rpc_forward_data+326>lea0x2(%rax),%edx
0x43e969 <_rpc_forward_data+329>lea-0x80(%rbp),%rcx
0x43e96d <_rpc_forward_data+333>mov-0xc4(%rbp),%eax
0x43e973 <_rpc_forward_data+339>mov%rcx,%rsi
0x43e976 <_rpc_forward_data+342>mov%eax,%edi

0x43e978 <_rpc_forward_data+344>callq  0x4287e0 
# eax == -1

0x43e97d <_rpc_forward_data+349>shr$0x1f,%eax
# eax == 1

0x43e980 <_rpc_forward_data+352>movzbl %al,%eax
# eax == 1

0x43e983 <_rpc_forward_data+355>mov%eax,-0xc0(%rbp)
# (gdb) p $rbp
# $17 = (void *) 0x7fcb8e15ee60
# (gdb) p &rc
# $15 = (int *) 0x7fcb8e15eda0
# $rbp - 0xC0 == &rc

0x43e989 <_rpc_forward_data+361>cmpl   $0x0,-0xc0(%rbp)
# if comparison


Standalone program:

0x400863 mov%rcx,%rsi
0x400866 mov%eax,%edi
0x400868 callq  0x400690 
# eax == -1

0x40086d mov%eax,-0x94(%rbp)
# (gdb) p &rc
# $1 = (int *) 0x7fffdeac
# (gdb) p $rbp - 0x94
# $2 = (void *) 0x7fffdeac
# => we just move ( $eax == -1 ) to the rc.

0x400873 cmpl   $0x0,-0x94(%rbp)
0x40087a jns0x400888   

So for some reasons the code issued by compiler for equal codes is different. 
The compilation flags used was:

req.c:
gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../slurm  
-DLIBSLURM_SO=\"/lxc-data/sandbox/slurm/lib/libslurm.so\" -I../../..-g -O2 
-pthread -Wall -g -O0 -fno-strict-aliasing -MT req.o -MD -MP -MF .deps/req.Tpo 
-c -o req.o req.c

standalone (was trying to use the same flags):
gcc -g -O2 -pthread -Wall -g -O0 -fno-strict-aliasing -c -o cli_c1.o cli_c1.c

FIX that changes the situation in SLURM: if I apply attached patch to the SLURM 
sources that shightly changes C construction:
-   while ((rc = connect(fd, (struct sockaddr *)&sa, SUN_LEN(&sa)) < 0) &&
-  (errno == EINTR));
+
+   do {
+   rc = connect(fd, (struct sockaddr *)&sa, SUN_LEN(&sa));
+   } while( (rc < 0) && (errno == EINTR) );

I'm getting correct code:
0x43e971 <_rpc_forward_data+337>mov%eax,%edi
0x43e973 <_rpc_forward_data+339>callq  0x4287e0 
0x43e978 <_rpc_forward_data+344>mov%eax,-0xc0(%rbp)
0x43e97e <_rpc_forward_data+350>cmpl   $0x0,-0xc0(%rbp)



 
 
  
Best regards, Artem  Y. Polyakov 
HPC Engineer, Mellanox Ltd. 
​
 

Re: Broken connect syscall invocation ?

[Jonathan Wakely]

On 26/05/16 07:37 +, Artem Polyakov wrote:

Hello,

I'm using the following version of GCC:
artpol@artpol-ThinkPad-T430 ~ $ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4
Copyright (C) 2013 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.

I'm facing the problem with the slurm compilation:
https://github.com/SchedMD/slurm
I'm building the master branch. And the problem I get is related to the 
following construction:
https://github.com/SchedMD/slurm/blob/master/src/slurmd/slurmd/req.c#L6171:L6172

The problem I see is that "connect" returns "+1" instead of "-1". And I can't 
reproduce this with the standalone code:
https://github.com/artpol84/poc/blob/master/linux-internals/syscalls/connect/cli_c1.c#L37


Hi, this mailing list is used for automated email from our Bugzilla
database and not for reporting bugs.

If you think you've found a bug in GCC please report it using
Bugzilla, rather than mailing this list directly.

https://gcc.gnu.org/bugs/

For general help and support questions about GCC please use the
gcc-help mailing list.

https://gcc.gnu.org/lists.html

Re: Broken connect syscall invocation ?

[Artem Polyakov]

Thank you. Will move there.


Best regards, Artem Y. Polyakov
HPC Engineer, Mellanox Ltd.
​


От: Jonathan Wakely 
Отправлено: 26 мая 2016 г. 14:39:01
Кому: Artem Polyakov
Копия: gcc-bugs@gcc.gnu.org
Тема: Re: Broken connect syscall invocation ?

On 26/05/16 07:37 +, Artem Polyakov wrote:
>Hello,
>
>I'm using the following version of GCC:
>artpol@artpol-ThinkPad-T430 ~ $ gcc --version
>gcc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4
>Copyright (C) 2013 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.
>
>I'm facing the problem with the slurm compilation:
>https://github.com/SchedMD/slurm
>I'm building the master branch. And the problem I get is related to the 
>following construction:
>https://github.com/SchedMD/slurm/blob/master/src/slurmd/slurmd/req.c#L6171:L6172
>
>The problem I see is that "connect" returns "+1" instead of "-1". And I can't 
>reproduce this with the standalone code:
>https://github.com/artpol84/poc/blob/master/linux-internals/syscalls/connect/cli_c1.c#L37

Hi, this mailing list is used for automated email from our Bugzilla
database and not for reporting bugs.

If you think you've found a bug in GCC please report it using
Bugzilla, rather than mailing this list directly.

https://gcc.gnu.org/bugs/

For general help and support questions about GCC please use the
gcc-help mailing list.

https://gcc.gnu.org/lists.html

[Bug c/71287] New: Possibly broken invocation of connect (and maybe other) syscalls

[artpol84 at gmail dot com]

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

Bug ID: 71287
   Summary: Possibly broken invocation of connect (and maybe
other) syscalls
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: artpol84 at gmail dot com
  Target Milestone: ---

Created attachment 38570
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38570&action=edit
Change in SLURM sources that fixes the emmitted assembly code.

System type is Linux Mint 17.3. Was reproduced on RHEL 6.5 as well.

I'm facing the problem with the slurm compilation:
https://github.com/SchedMD/slurm
I'm building the master branch. And the problem I get is related to the
following construction:
https://github.com/SchedMD/slurm/blob/master/src/slurmd/slurmd/req.c#L6171:L6172

The problem I see is that "connect" returns "+1" instead of "-1". And I can't
reproduce this with the standalone code:
https://github.com/artpol84/poc/blob/master/linux-internals/syscalls/connect/cli_c1.c#L37

Here is what GDB shows for those 2 codes:

SLURM's req.c:
0x43e966 <_rpc_forward_data+326>lea0x2(%rax),%edx
0x43e969 <_rpc_forward_data+329>lea-0x80(%rbp),%rcx
0x43e96d <_rpc_forward_data+333>mov-0xc4(%rbp),%eax
0x43e973 <_rpc_forward_data+339>mov%rcx,%rsi
0x43e976 <_rpc_forward_data+342>mov%eax,%edi

0x43e978 <_rpc_forward_data+344>callq  0x4287e0 
# eax == -1

0x43e97d <_rpc_forward_data+349>shr$0x1f,%eax
# eax == 1

0x43e980 <_rpc_forward_data+352>movzbl %al,%eax
# eax == 1

0x43e983 <_rpc_forward_data+355>mov%eax,-0xc0(%rbp)
# (gdb) p $rbp
# $17 = (void *) 0x7fcb8e15ee60
# (gdb) p &rc
# $15 = (int *) 0x7fcb8e15eda0
# $rbp - 0xC0 == &rc

0x43e989 <_rpc_forward_data+361>cmpl   $0x0,-0xc0(%rbp)
# if comparison


Standalone program:

0x400863 mov%rcx,%rsi
0x400866 mov%eax,%edi
0x400868 callq  0x400690 
# eax == -1

0x40086d mov%eax,-0x94(%rbp)
# (gdb) p &rc
# $1 = (int *) 0x7fffdeac
# (gdb) p $rbp - 0x94
# $2 = (void *) 0x7fffdeac
# => we just move ( $eax == -1 ) to the rc.

0x400873 cmpl   $0x0,-0x94(%rbp)
0x40087a jns0x400888 

So for some reasons the code issued by compiler for equal codes is different.
The compilation flags used was:

req.c:
gcc -DHAVE_CONFIG_H -I. -I../../.. -I../../../slurm 
-DLIBSLURM_SO=\"/lxc-data/sandbox/slurm/lib/libslurm.so\" -I../../..-g -O2
-pthread -Wall -g -O0 -fno-strict-aliasing -MT req.o -MD -MP -MF .deps/req.Tpo
-c -o req.o req.c

standalone (was trying to use the same flags):
gcc -g -O2 -pthread -Wall -g -O0 -fno-strict-aliasing -c -o cli_c1.o cli_c1.c

FIX that changes the situation in SLURM: if I apply attached patch to the SLURM
sources that shightly changes C construction:
-   while ((rc = connect(fd, (struct sockaddr *)&sa, SUN_LEN(&sa)) < 0) &&
-  (errno == EINTR));
+
+   do {
+   rc = connect(fd, (struct sockaddr *)&sa, SUN_LEN(&sa));
+   } while( (rc < 0) && (errno == EINTR) );

I'm getting correct code:
0x43e971 <_rpc_forward_data+337>mov%eax,%edi
0x43e973 <_rpc_forward_data+339>callq  0x4287e0 
0x43e978 <_rpc_forward_data+344>mov%eax,-0xc0(%rbp)
0x43e97e <_rpc_forward_data+350>cmpl   $0x0,-0xc0(%rbp)

[Bug c++/71052] Use of Range Based For Loop in unsupported dialect results in malformed code

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  ---
See c++/68209

[Bug tree-optimization/71280] [7 Regression] ICE on gcc trunk on knl, wsm, ivb and bdw targets

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Author: jakub
Date: Thu May 26 09:29:28 2016
New Revision: 236767

URL: https://gcc.gnu.org/viewcvs?rev=236767&root=gcc&view=rev
Log:
PR tree-optimization/71280
* gcc.dg/pr71280.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr71280.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/71280] [7 Regression] ICE on gcc trunk on knl, wsm, ivb and bdw targets

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Fixed with PR71239 fix.

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

[Bug tree-optimization/71239] [7 Regression] ICE in operand_equal_p (fold-const.c:2769)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||anton.mitrokhin at phystech 
dot ed
   ||u

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

[Bug target/71281] ICE on gcc trunk on knl, wsm, ivb and bdw targets (tree-ssa-reassoc)

[anton.mitrokhin at phystech dot edu]

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

--- Comment #2 from Anton Mitrokhin  ---
Created attachment 38571
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38571&action=edit
Small reproducer

[Bug tree-optimization/71270] [7 Regression] fortran regression after fix SLP PR58135

[vekumar at gcc dot gnu.org]

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

--- Comment #2 from vekumar at gcc dot gnu.org ---
Looked at x86_64 gimple code for intrinsic_pack_1.f90.

After the SLP split we now vectorize at the place where we pass constant
arguments via a parameterstructure to _gfortran_pack call.  

Before
 parm.20D.3555.dtypeD.3497 = 297;
  # .MEM_242 = VDEF <.MEM_241>
  parm.20D.3555.dimD.3502[0].lboundD.3499 = 1;
  # .MEM_243 = VDEF <.MEM_242>
  parm.20D.3555.dimD.3502[0].uboundD.3500 = 9;
  # .MEM_244 = VDEF <.MEM_243>
  parm.20D.3555.dimD.3502[0].strideD.3498 = 1;
  # .MEM_245 = VDEF <.MEM_244>
  parm.20D.3555.dataD.3495 = &d_ri4D.3433[0];
  # .MEM_246 = VDEF <.MEM_245>
  parm.20D.3555.offsetD.3496 = -1;

After 
# .MEM_243 = VDEF <.MEM_1566>
parm.20D.3555.dimD.3502[0].uboundD.3500 = 9;
# .MEM_245 = VDEF <.MEM_243>
parm.20D.3555.dataD.3495 = &d_ri4D.3433[0];
# .MEM_992 = VDEF <.MEM_245>
MEM[(integer(kind=8)D.9 *)&parm.20D.3555 + 8B] = vect_cst__993;
# PT = anything
# ALIGN = 16, MISALIGN = 8
_984 = &parm.20D.3555.offsetD.3496 + 16;
# .MEM_983 = VDEF <.MEM_992>
MEM[(integer(kind=8)D.9 *)_984] = vect_cst__999;

vect_cst__993={-1,297}
vect_cst__999={1,1}

Other places looks similar. This looks like correct gimple. I am verifying the
gimple generated for arm big endian target.

[Bug c++/50436] Crash or hang on invalid template code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

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

[Bug c++/59804] C++ front-end checking ends in an infinite loop on erroneous code

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

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

--- Comment #2 from Paolo Carlini  ---
This is fixed.

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

[Bug tree-optimization/71288] New: [7 Regression] Time and memory hog during if-conversion at -O3

[asolokha at gmx dot com]

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

Bug ID: 71288
   Summary: [7 Regression] Time and memory hog during
if-conversion at -O3
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: compile-time-hog, memory-hog
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-7.0.0-alpha20160522 consumes lots of memory and time (indefinite time?)
when compiling the following testcase at -O3:

unsigned short int hb;
short int kr;

void
o8 (void)
{
  unsigned short int ov;

  while (hb < 1)
  {
if (hb != kr)
  hb = 0;
for (ov = 0; ov < 16; ++ov)
{
  kr = 0;
  hb -= ((hb != 0) ? (ov < hb) : 1);
}
  }
}

% timeout 15 x86_64-pc-linux-gnu-gcc-7.0.0-alpha20160522 -c -O3 -w gjpx2kcj.c
% echo $?
124

Strictly speaking, the testcase is not fully reduced. It is the minimal version
which still demonstrates the same hottest path in perf top as the original
program:

  26.77%  cc1   [.] (anonymous namespace)::pass_if_conversion::execute

[Bug c/71287] Possibly broken invocation of connect (and maybe other) syscalls

[artpol84 at gmail dot com]

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

--- Comment #1 from Artem Polyakov  ---
On RHEL where this was also observed compiler version is the following:

gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)

[Bug tree-optimization/71288] [7 Regression] Time and memory hog during if-conversion at -O3

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-26
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Markus Trippelsdorf  ---
Probably started with r236701.

#0  gimple_alloc_stat (code=code@entry=GIMPLE_ASSIGN, num_ops=num_ops@entry=3)
at ../../gcc/gcc/gimple.c:132
#1  0x008e3150 in gimple_copy (stmt=stmt@entry=0x7fff2a6deec8) at
../../gcc/gcc/gimple.c:1672
#2  0x00bdff50 in ifcvt_split_def_stmt (use_stmt=0x7fff2a6e0058,
def_stmt=0x7fff2a6deec8) at ../../gcc/gcc/tree-if-conv.c:2535
#3  ifcvt_repair_bool_pattern (bb=) at
../../gcc/gcc/tree-if-conv.c:2697
#4  tree_if_conversion (loop=) at
../../gcc/gcc/tree-if-conv.c:2856
#5  (anonymous namespace)::pass_if_conversion::execute (this=,
fun=) at ../../gcc/gcc/tree-if-conv.c:2939
#6  0x00aac683 in execute_one_pass (pass=pass@entry=0x1d8df30) at
../../gcc/gcc/passes.c:2344
#7  0x00aacc78 in execute_pass_list_1 (pass=0x1d8df30) at
../../gcc/gcc/passes.c:2428
#8  0x00aacc8a in execute_pass_list_1 (pass=0x1d8d920) at
../../gcc/gcc/passes.c:2429
#9  0x00aacc8a in execute_pass_list_1 (pass=0x1d8c6c0) at
../../gcc/gcc/passes.c:2429
#10 0x00aaccd5 in execute_pass_list (fn=,
pass=) at ../../gcc/gcc/passes.c:2439
#11 0x007a2944 in cgraph_node::expand (this=this@entry=0x771c2000)
at ../../gcc/gcc/cgraphunit.c:1983
#12 0x007a4267 in expand_all_functions () at
../../gcc/gcc/cgraphunit.c:2119
#13 symbol_table::compile (this=this@entry=0x770a50a8) at
../../gcc/gcc/cgraphunit.c:2475
#14 0x007a66a3 in symbol_table::compile (this=0x770a50a8) at
../../gcc/gcc/cgraphunit.c:2539
#15 symbol_table::finalize_compilation_unit (this=0x770a50a8) at
../../gcc/gcc/cgraphunit.c:2565
#16 0x00b73a68 in compile_file () at ../../gcc/gcc/toplev.c:488
#17 0x0060ef76 in do_compile () at ../../gcc/gcc/toplev.c:1987
#18 toplev::main (this=this@entry=0x7fffe260, argc=,
argc@entry=13, argv=, argv@entry=0x7fffe368) at
../../gcc/gcc/toplev.c:2095
#19 0x00611107 in main (argc=13, argv=0x7fffe368) at
../../gcc/gcc/main.c:39

[Bug c/71255] Implement #pragma may_alias

[mpolacek at gcc dot gnu.org]

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

--- Comment #13 from Marek Polacek  ---
I'd like to point out that the test case

struct sockaddr;
struct sockaddr *f();

struct __attribute__((may_alias)) sockaddr {};
struct sockaddr *f()
{
  return nullptr;
}

(from https://sourceware.org/bugzilla/show_bug.cgi?id=19622#c1)
no longer errors/ICEs and compiles fine with gcc6/trunk.  It used to ICE since
r222419 and the ICE was fixed in r234768.

But we still warn on

__attribute__((may_alias)) struct S s;
struct S { int i; } s2;

w.c:1:35: warning: ignoring attributes applied to ‘struct S’ after definition
[-Wattributes]
 __attribute__((may_alias)) struct S s;
   ^
So I suppose we still need the new pragma.

[Bug c/71255] Implement #pragma may_alias

[fw at gcc dot gnu.org]

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

--- Comment #14 from Florian Weimer  ---
I believe the equivalent C test case:

#include 

struct sockaddr;
struct sockaddr *f();

struct __attribute__((may_alias)) sockaddr {};
struct sockaddr *f()
{
  return NULL;
}

still does not work:

t.c:7:18: error: conflicting types for ‘f’
 struct sockaddr *f()
  ^
t.c:4:18: note: previous declaration of ‘f’ was here
 struct sockaddr *f();

[Bug target/71279] [6/7 Regression] ICE on trunk gcc with knl target

[ienkovich at gcc dot gnu.org]

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

--- Comment #3 from Ilya Enkovich  ---
This looks similar to PR70251 but this time transformation is performed in
folding.  Here is a description of applied transformation:

/* Convert A ? 0 : 1 to !A.  This prefers the use of NOT_EXPR 
   over COND_EXPR in cases such as floating point comparisons.  */

This doesn't work for boolean vectors with scalar mode.  So we should disable
transformation for vec_cond_expr or at least for boolean vectors with scalar
mode.

[Bug tree-optimization/71252] [7 Regression] ICE: verify_ssa failed : definition in block 7 does not dominate use in block 6

[rogero at howzatt dot demon.co.uk]

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

--- Comment #13 from Roger Orr  ---
The patch sadly does not appear to fix the (very similar looking) valgrind
compilation failure I posted in pr71269.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71269#c7

[Bug middle-end/71269] [7 Regression] segfault while compiling sqlite

[kugan at gcc dot gnu.org]

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

--- Comment #8 from kugan at gcc dot gnu.org ---
(In reply to Roger Orr from comment #7)
> I've got a very similar problem, building valgrind with trunk revision
> 236644:
> 
> m_mallocfree.c: In function 'sanity_check_malloc_arena':
> m_mallocfree.c:1055:13: internal compiler error: Segmentation fault
>  static void sanity_check_malloc_arena ( ArenaId aid )
>  ^
> 0xbac3df crash_signal
> ../../gcc/toplev.c:333
> 0xd46249 sort_by_operand_rank
> ../../gcc/tree-ssa-reassoc.c:530
> 0xd52d83 reassociate_bb
> ../../gcc/tree-ssa-reassoc.c:5268
> 0xd51027 reassociate_bb
> ../../gcc/tree-ssa-reassoc.c:5389
> 0xd53f7a do_reassoc
> ../../gcc/tree-ssa-reassoc.c:5503
> 0xd53f7a execute_reassoc
> ../../gcc/tree-ssa-reassoc.c:5590
> 0xd53f7a execute
> ../../gcc/tree-ssa-reassoc.c:5629
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> 
> I've uploaded the preprocessed input and compiler output.

This Looks like what is fixed in r236673. Can you attach a per-processed src
please.

[Bug middle-end/71269] [7 Regression] segfault while compiling sqlite

[trippels at gcc dot gnu.org]

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

--- Comment #9 from Markus Trippelsdorf  ---
(In reply to kugan from comment #8)
> (In reply to Roger Orr from comment #7)
> > I've got a very similar problem, building valgrind with trunk revision
> > 236644:
> > 
> > m_mallocfree.c: In function 'sanity_check_malloc_arena':
> > m_mallocfree.c:1055:13: internal compiler error: Segmentation fault
> >  static void sanity_check_malloc_arena ( ArenaId aid )
> >  ^
> > 0xbac3df crash_signal
> > ../../gcc/toplev.c:333
> > 0xd46249 sort_by_operand_rank
> > ../../gcc/tree-ssa-reassoc.c:530
> > 0xd52d83 reassociate_bb
> > ../../gcc/tree-ssa-reassoc.c:5268
> > 0xd51027 reassociate_bb
> > ../../gcc/tree-ssa-reassoc.c:5389
> > 0xd53f7a do_reassoc
> > ../../gcc/tree-ssa-reassoc.c:5503
> > 0xd53f7a execute_reassoc
> > ../../gcc/tree-ssa-reassoc.c:5590
> > 0xd53f7a execute
> > ../../gcc/tree-ssa-reassoc.c:5629
> > Please submit a full bug report,
> > with preprocessed source if appropriate.
> > Please include the complete backtrace with any bug report.
> > See  for instructions.
> > 
> > I've uploaded the preprocessed input and compiler output.
> 
> This Looks like what is fixed in r236673. Can you attach a per-processed src
> please.

It is already attached.

[Bug tree-optimization/71252] [7 Regression] ICE: verify_ssa failed : definition in block 7 does not dominate use in block 6

[kugan at gcc dot gnu.org]

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

--- Comment #14 from kugan at gcc dot gnu.org ---
(In reply to Roger Orr from comment #13)
> The patch sadly does not appear to fix the (very similar looking) valgrind
> compilation failure I posted in pr71269.
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71269#c7

That looks like what is fixed in r236673. If you still have the issue, could
you attach a preprocessed src to reproduce please.

[Bug middle-end/71269] [7 Regression] segfault while compiling sqlite

[kugan at gcc dot gnu.org]

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

--- Comment #10 from kugan at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #9)
> (In reply to kugan from comment #8)
> > (In reply to Roger Orr from comment #7)
> > > I've got a very similar problem, building valgrind with trunk revision
> > > 236644:
> > > 
> > > m_mallocfree.c: In function 'sanity_check_malloc_arena':
> > > m_mallocfree.c:1055:13: internal compiler error: Segmentation fault
> > >  static void sanity_check_malloc_arena ( ArenaId aid )
> > >  ^
> > > 0xbac3df crash_signal
> > > ../../gcc/toplev.c:333
> > > 0xd46249 sort_by_operand_rank
> > > ../../gcc/tree-ssa-reassoc.c:530
> > > 0xd52d83 reassociate_bb
> > > ../../gcc/tree-ssa-reassoc.c:5268
> > > 0xd51027 reassociate_bb
> > > ../../gcc/tree-ssa-reassoc.c:5389
> > > 0xd53f7a do_reassoc
> > > ../../gcc/tree-ssa-reassoc.c:5503
> > > 0xd53f7a execute_reassoc
> > > ../../gcc/tree-ssa-reassoc.c:5590
> > > 0xd53f7a execute
> > > ../../gcc/tree-ssa-reassoc.c:5629
> > > Please submit a full bug report,
> > > with preprocessed source if appropriate.
> > > Please include the complete backtrace with any bug report.
> > > See  for instructions.
> > > 
> > > I've uploaded the preprocessed input and compiler output.
> > 
> > This Looks like what is fixed in r236673. Can you attach a per-processed src
> > please.
> 
> It is already attached.

Sorry, I missed that.

on x86-64-linux-gnu, with the current trunk:
./build/gcc/cc1 -O2 m_mallocfree.i 
./build/gcc/cc1 -O3 m_mallocfree.i
are working. What command line did you use to ICE ?

[Bug middle-end/71269] [7 Regression] segfault while compiling sqlite

[trippels at gcc dot gnu.org]

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

--- Comment #11 from Markus Trippelsdorf  ---
 > Sorry, I missed that.
> 
> on x86-64-linux-gnu, with the current trunk:
> ./build/gcc/cc1 -O2 m_mallocfree.i 
> ./build/gcc/cc1 -O3 m_mallocfree.i
> are working. What command line did you use to ICE ?

See the other attachment ;)
I cannot reproduce the issue on current trunk.

[Bug middle-end/71269] [7 Regression] segfault while compiling sqlite

[kugan at gcc dot gnu.org]

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

--- Comment #12 from kugan at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #11)
>  > Sorry, I missed that.
> > 
> > on x86-64-linux-gnu, with the current trunk:
> > ./build/gcc/cc1 -O2 m_mallocfree.i 
> > ./build/gcc/cc1 -O3 m_mallocfree.i
> > are working. What command line did you use to ICE ?
> 
> See the other attachment ;)
> I cannot reproduce the issue on current trunk.

Thanks for checking. I need some sleep now :)

[Bug tree-optimization/71288] [7 Regression] Time and memory hog during if-conversion at -O3

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #2 from Markus Trippelsdorf  ---
Actually it started with r235808.

[Bug tree-optimization/71289] New: Fails to optimize unsigned mul overflow check 'A > -1 / B'

[amonakov at gcc dot gnu.org]

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

Bug ID: 71289
   Summary: Fails to optimize unsigned mul overflow check 'A > -1
/ B'
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
  Target Milestone: ---

If A and B are both unsigned, then 'A > -1 / B' is a nice predicate for
checking whether A*B would overflow. The compiler should be able to optimize
the otherwise-unused division to a multiplication followed by branch on
overflow.

I've tried to add the corresponding transform to match.pd, but it seems
something else needs to be wired up as well, because it doesn't trigger. What
am I missing? TIA.

diff --git a/gcc/match.pd b/gcc/match.pd
index e511e9a..83c02a8 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2582,6 +2582,16 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
&& types_match (TREE_TYPE (@0), TREE_TYPE (@1)))
(out (imagpart @2) { build_zero_cst (TREE_TYPE (@0)); }

+/* Simplify unsigned multiplication overflow check A > -1 / B to a builtin. 
*/
+(for cmp (gt le)
+ out (ne eq)
+ (simplify
+  (cmp @0 (trunc_div:s integer_all_onesp @1))
+  (if (TYPE_UNSIGNED (TREE_TYPE (@0))
+   && types_match (TREE_TYPE (@0), TREE_TYPE (@1)))
+   (out
+(imagpart (IFN_MUL_OVERFLOW @0 @1))
+{ build_zero_cst (TREE_TYPE (@0)); }

 /* Simplification of math builtins.  These rules must all be optimizations
as well as IL simplifications.  If there is a possibility that the new

[Bug sanitizer/61408] r205695 breaks packaging step of Firefox 24 ESR on Ubuntu Lucid building with ASan

[gk at torproject dot org]

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

Georg Koppen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #14 from Georg Koppen  ---
Works for me given that probably no one is still using 10.04 and Firefox ESR24.
Certainly we don't.

[Bug sanitizer/61475] Building Firefox with ASan is broken in the packaging step

[gk at torproject dot org]

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

Georg Koppen  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #9 from Georg Koppen  ---
We don't use any ESR24 anymore and no Lucid. Works for me.

[Bug c++/71283] -Wterminate is not described in "Options to Request or Suppress Warnings"

[egall at gwmail dot gwu.edu]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egall at gwmail dot gwu.edu

--- Comment #3 from Eric Gallager  ---
(In reply to Andrew Pinski from comment #2)
> That is because this is C++ only option.  It is listed under
> https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/C_002b_002b-Dialect-Options.
> html#C_002b_002b-Dialect-Options :
> 
> -Wno-terminate (C++ and Objective-C++ only)
> Disable the warning about a throw-expression that will immediately result in
> a call to terminate.
> 
> This is exact location for all other C++ only options are located.
> 
> So not a bug.

There are other C++-only options under "Options to Request or Suppress
Warnings".
For example:
* -Wc++11-compat
* -Wc++14-compat
* -Wconditionally-supported
* -Wno-conversion-null
* -Wzero-as-null-pointer-constant
* -Wsubobject-linkage
* -Wdelete-incomplete
* -Wuseless-cast
* -Wsized-deallocation
* -Wno-invalid-offsetof

It's kind of inconsistent whether C++-only warnings are listed here or there.

[Bug middle-end/71269] [7 Regression] segfault while compiling sqlite

[rogero at howzatt dot demon.co.uk]

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

--- Comment #13 from Roger Orr  ---
Ok, I'll try with trunk (I'd not noticed a relevant change had already been
submitted)

[Bug c++/71290] New: [6/7 Regression] Flexible array member is not diagnosed with -pedantic

[miyuki at gcc dot gnu.org]

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

Bug ID: 71290
   Summary: [6/7 Regression] Flexible array member is not
diagnosed with -pedantic
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: miyuki at gcc dot gnu.org
  Target Milestone: ---

We used to warn for:

$ cat test.cc 
struct S {
int i;
unsigned arr[];
};

$ /opt/gcc-5.3.0/bin/g++ test.cc -pedantic
test.cc:3:18: warning: ISO C++ forbids zero-size array 'arr' [-Wpedantic]
 unsigned arr[];

Starting with r231665 the warning is gone.

[Bug sanitizer/71291] New: Firefox with GCC reports stack-buffer-overflow but clang does not

[gk at torproject dot org]

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

Bug ID: 71291
   Summary: Firefox with GCC reports stack-buffer-overflow but
clang does not
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gk at torproject dot org
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: ---

Created attachment 38572
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38572&action=edit
Patch for building mozilla-central with GCC and ASan

I recently reported a bug to the Mozilla team about a reproducible stack buffer
overflow. To my surprise this ASan report only happens with GCC. Using
different clang versions is working fine. The Mozilla folks concluded this is a
GCC bug and closed the report as WORKSFORME.

I've tested with GCC 5.2.0/5.3.1 and with the latest code on gcc-6-branch
(which contains the latest ASan changes in GCC if I got that right) both
Firefox 45 ESR and latest mozilla-central. The ASan crash is always
reproducible for me.

STR:

1) Build Firefox with a .mozconfig file like:

. $topsrcdir/browser/config/mozconfig

export CFLAGS="-fsanitize=address -Dxmalloc=myxmalloc"
export CXXFLAGS="-fsanitize=address -Dxmalloc=myxmalloc"
# We need to add -ldl explicitely due to bug 1213698
export LDFLAGS="-fsanitize=address -ldl"

ac_add_options --enable-address-sanitizer
ac_add_options --disable-jemalloc
ac_add_options --disable-elf-hack

(if you build mozilla-central you need the attached asan.patch as well)

2) Go to http://lab.hakim.se/meny/ and move with the mouse to the left corner

3) The build crashes with a srack-buffer-overflow report.

[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not

[gk at torproject dot org]

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

--- Comment #1 from Georg Koppen  ---
I wonder if there are any good things I could do to debug this problem before
looking at the stack trace itself. Any ideas?

[Bug c/71255] Implement #pragma may_alias

[mpolacek at gcc dot gnu.org]

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

--- Comment #15 from Marek Polacek  ---
Yeah, only the C++ side was changed.  I think it's wrong that we reject the
testcase in Comment 14 in C (I have a fix for that).

But even with that fixed we still need the new #pragma because of the second
testcase in Comment 13, right?

[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
You haven't mentioned any details, like in which function it is, the exact
diagnostic you get, reference to the upstream bugreport, preprocessed source +
g++ command line for the problematic source file, ...

[Bug tree-optimization/71252] [7 Regression] ICE: verify_ssa failed : definition in block 7 does not dominate use in block 6

[rogero at howzatt dot demon.co.uk]

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

--- Comment #15 from Roger Orr  ---
Sorry for the noise; I'd not noticed there had been a relevant commit.
I'll re-check against trunk.

[Bug tree-optimization/71289] Fails to optimize unsigned mul overflow check 'A > -1 / B'

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
(In reply to Alexander Monakov from comment #0)
> I've tried to add the corresponding transform to match.pd, but it seems
> something else needs to be wired up as well, because it doesn't trigger.
> What am I missing? TIA.

What do the dumps look like? Gcc is likely to change things to -1 / B < A,
which you don't handle...

> +/* Simplify unsigned multiplication overflow check A > -1 / B to a builtin.
> */
> +(for cmp (gt le)
> + out (ne eq)
> + (simplify
> +  (cmp @0 (trunc_div:s integer_all_onesp @1))
> +  (if (TYPE_UNSIGNED (TREE_TYPE (@0))
> +   && types_match (TREE_TYPE (@0), TREE_TYPE (@1)))

types_match seems unnecessary here, it is mostly useful when we have some
CONVERT_EXPR, but trunc's arguments and result types have to match, same for
cmp arguments, so @0 and @1 should always have matching types.

> +   (out
> +(imagpart (IFN_MUL_OVERFLOW @0 @1))
> +{ build_zero_cst (TREE_TYPE (@0)); }

We probably need to disable such a transformation for vectors.

[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not

[gk at torproject dot org]

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

--- Comment #3 from Georg Koppen  ---
Created attachment 38573
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38573&action=edit
ASan stack trace

This is https://bugzilla.mozilla.org/show_bug.cgi?id=1268854 and attached is
the ASan stack trace to begin with.

[Bug bootstrap/71292] New: Bootstrap failure with segfault in tree-reassoc.c

[ktkachov at gcc dot gnu.org]

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

Bug ID: 71292
   Summary: Bootstrap failure with segfault in tree-reassoc.c
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
CC: kugan at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-none-linux-gnu

An aarch64-none-linux-gnu bootstrap with an in-tree mpfr fails with an ICE:
exp_2.i: In function ‘fn1’:
exp_2.i:4:6: internal compiler error: Segmentation fault
 void fn1() {
  ^~~
0xb1f8cf crash_signal
$SRC/gcc/toplev.c:333
0x89bcb9 bb_seq_addr
$SRC/gcc/gimple.h:1655
0x89bcb9 gsi_start_bb
$SRC/gcc/gimple-iterator.h:129
0x89bcb9 gsi_for_stmt(gimple*)
$SRC/gcc/gimple-iterator.c:617
0xcbbeba insert_stmt_after
$SRC/gcc/tree-ssa-reassoc.c:1323
0xcbd67a build_and_add_sum
$SRC/gcc/tree-ssa-reassoc.c:1392
0xcbf34f rewrite_expr_tree_parallel
$SRC/gcc/tree-ssa-reassoc.c:4128
0xcc8b95 reassociate_bb
$SRC/gcc/tree-ssa-reassoc.c:5339
0xcc8ad7 reassociate_bb
$SRC/gcc/tree-ssa-reassoc.c:5391
0xccb523 do_reassoc
$SRC/gcc/tree-ssa-reassoc.c:5505
0xccb523 execute_reassoc
$SRC/gcc/tree-ssa-reassoc.c:5592
0xccb523 execute
$SRC/gcc/tree-ssa-reassoc.c:5631
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

The reduced testcase for that reproducible with trunk at:
gcc version 7.0.0 20160526 
is:

unsigned long a;
long b, d;
int c;
void fn1() {
  unsigned long e = a + c;
  b = d + e + a + 8;
}

compile with -O2.
Compiling with -fno-tree-reassoc doesn't ICE

[Bug bootstrap/71292] Bootstrap failure with segfault in tree-reassoc.c

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P1
  Known to work||6.1.0
   Target Milestone|--- |7.0
  Known to fail||7.0

[Bug middle-end/71269] [7 Regression] segfault while compiling sqlite

[rogero at howzatt dot demon.co.uk]

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

--- Comment #14 from Roger Orr  ---
Confirmed: valgrind now builds successfully with revision 236769.

[Bug tree-optimization/71288] [7 Regression] Time and memory hog during if-conversion at -O3

[amker at gcc dot gnu.org]

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

--- Comment #3 from amker at gcc dot gnu.org ---
(In reply to Markus Trippelsdorf from comment #2)
> Actually it started with r235808.

Thanks for doing triage, I will look into this.

[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not

[gk at torproject dot org]

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

--- Comment #4 from Georg Koppen  ---
Created attachment 38574
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38574&action=edit
.ii file

Here comes the .ii file.

[Bug libgcc/71282] C,C++ function strpbrk arg 1 has wrong type on Raspian 4.1.19

[rayconnell at usa dot net]

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

--- Comment #2 from Raymond Connell  ---
Thanks for responding so quickly. Sorry for the false alarm. I have no excuse.
I should have looked at the C++ versions more closely.

RSC

-- Original Message --
Received: 11:16 PM EDT, 05/25/2016
From: "msebor at gcc dot gnu.org" 
To: rayconn...@usa.net
Subject: [Bug libgcc/71282] C,C++ function strpbrk arg 1 has wrong type on
Raspian 4.1.19

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
Unlike in C, in C++ there are two overloads of strpbrk (declared by GLIBC on
GNU/Linux):

  const char* strpbrk (const char*, const char*);

and

  char* strpbrk (char*, const char*);

The first one is used when the first argument is a const pointer and array,
as
in the test case, and the second one otherwise.  Since the first one returns
a
const char* which is not convertible to char*, the program is incorrect.

Unfortunately, the caret in the error makes this hard to see.  Current trunk
does only slightly better:

error: invalid conversion from ‘const char*’ to ‘char*’
[-fpermissive]
 char *pSpc = strpbrk(tstStr, " ");
  ~~~^

That might be worth raising a separate bug for (if one doesn't already
exist),
but this one is invalid.

[Bug tree-optimization/71270] [7 Regression] fortran regression after fix SLP PR58135

[vekumar at gcc dot gnu.org]

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

--- Comment #3 from vekumar at gcc dot gnu.org ---
Built armeb-none-linux-gnueabihf -with-cpu=cortex-a9 --with-fpu=neon-fp16
--with-float=hard

And compared gimple output from intrinsic_pack_1.f90.151t.slp1 before and after
my patch.

The difference is shown below and is similar to x86_64 dump. The gimple dump
after SLP looks correct to me. I think something in backend is causing the
issues.

Any thoughts?

Gimple SLP dumps.

Before

 # .MEM_1450 = VDEF <.MEM_1492>
  d_i1D.3585[0].vD.3582 = 1;
  # .MEM_1454 = VDEF <.MEM_1450>
  d_i1D.3585[1].vD.3582 = -1;
  # .MEM_1458 = VDEF <.MEM_1454>
  d_i1D.3585[2].vD.3582 = 2;
  # .MEM_1468 = VDEF <.MEM_1458>
  d_i1D.3585[3].vD.3582 = -2;
  # .MEM_1472 = VDEF <.MEM_1468>
  d_i1D.3585[4].vD.3582 = 3;
  # .MEM_1476 = VDEF <.MEM_1472>
  d_i1D.3585[5].vD.3582 = -3;
  # .MEM_1486 = VDEF <.MEM_1476>
  d_i1D.3585[6].vD.3582 = 4;
  # .MEM_1490 = VDEF <.MEM_1486>
  d_i1D.3585[7].vD.3582 = -4;
  # .MEM_1494 = VDEF <.MEM_1490>
  d_i1D.3585[8].vD.3582 = 5;


After 

  vect_cst__817 = { 1, 0, 1, 0 };
  vect_cst__873 = { 1, 0, 1, 0 };
  vect_cst__1413 = { 1, -1, 2, -2 };
  vect_cst__1461 = { 3, -3, 4, -4 };

  # .MEM_910 = VDEF <.MEM_1492>
  MEM[(integer(kind=1)D.3 *)&d_i1D.3585] = vect_cst__1413;
  # PT = anything
  # ALIGN = 4, MISALIGN = 0
  _918 = &d_i1D.3585[0].vD.3582 + 4;
  # .MEM_865 = VDEF <.MEM_910>
  MEM[(integer(kind=1)D.3 *)_918] = vect_cst__1461;
  # .MEM_1494 = VDEF <.MEM_865>
  d_i1D.3585[8].vD.3582 = 5;

Before 

 # .MEM_1388 = VDEF <.MEM_217>
  MEM[(logical(kind=1)D.7[9] *)&A.8D.3679][0] = 1;
  # .MEM_1393 = VDEF <.MEM_1388>
  MEM[(logical(kind=1)D.7[9] *)&A.8D.3679][1] = 0;
  # .MEM_1398 = VDEF <.MEM_1393>
  MEM[(logical(kind=1)D.7[9] *)&A.8D.3679][2] = 1;
  # .MEM_1409 = VDEF <.MEM_1398>
  MEM[(logical(kind=1)D.7[9] *)&A.8D.3679][3] = 0;
  # .MEM_1414 = VDEF <.MEM_1409>
  MEM[(logical(kind=1)D.7[9] *)&A.8D.3679][4] = 1;
  # .MEM_1419 = VDEF <.MEM_1414>
  MEM[(logical(kind=1)D.7[9] *)&A.8D.3679][5] = 0;
  # .MEM_1430 = VDEF <.MEM_1419>
  MEM[(logical(kind=1)D.7[9] *)&A.8D.3679][6] = 1;
  # .MEM_1435 = VDEF <.MEM_1430>
  MEM[(logical(kind=1)D.7[9] *)&A.8D.3679][7] = 0;
  # .MEM_1440 = VDEF <.MEM_1435>
  MEM[(logical(kind=1)D.7[9] *)&A.8D.3679][8] = 1;

After 

  # .MEM_825 = VDEF <.MEM_217>
  MEM[(logical(kind=1)D.7 *)&A.8D.3679] = vect_cst__817;
  # PT = anything
  # ALIGN = 4, MISALIGN = 0
  _769 = &MEM[(logical(kind=1)D.7[9] *)&A.8D.3679][0] + 4;
  # .MEM_777 = VDEF <.MEM_825>
  MEM[(logical(kind=1)D.7 *)_769] = vect_cst__873;
  # .MEM_1440 = VDEF <.MEM_777>
  MEM[(logical(kind=1)D.7[9] *)&A.8D.3679][8] = 1;

Before 

  # .MEM_1271 = VDEF <.MEM_264>
  MEM[(logical(kind=1)D.7[9] *)&A.23D.3720][0] = 1;
  # .MEM_1276 = VDEF <.MEM_1271>
  MEM[(logical(kind=1)D.7[9] *)&A.23D.3720][1] = 0;
  # .MEM_1281 = VDEF <.MEM_1276>
  MEM[(logical(kind=1)D.7[9] *)&A.23D.3720][2] = 1;
  # .MEM_1292 = VDEF <.MEM_1281>
  MEM[(logical(kind=1)D.7[9] *)&A.23D.3720][3] = 0;
  # .MEM_1297 = VDEF <.MEM_1292>
  MEM[(logical(kind=1)D.7[9] *)&A.23D.3720][4] = 1;
  # .MEM_1302 = VDEF <.MEM_1297>
  MEM[(logical(kind=1)D.7[9] *)&A.23D.3720][5] = 0;
  # .MEM_1313 = VDEF <.MEM_1302>
  MEM[(logical(kind=1)D.7[9] *)&A.23D.3720][6] = 1;
  # .MEM_1318 = VDEF <.MEM_1313>
  MEM[(logical(kind=1)D.7[9] *)&A.23D.3720][7] = 0;
  # .MEM_1323 = VDEF <.MEM_1318>
  MEM[(logical(kind=1)D.7[9] *)&A.23D.3720][8] = 1;

After 

 vect_cst__729 = { 1, 0, 1, 0 };
  vect_cst__721 = { 1, 0, 1, 0 };

  # .MEM_673 = VDEF <.MEM_264>
  MEM[(logical(kind=1)D.7 *)&A.23D.3720] = vect_cst__729;
  # PT = anything
  # ALIGN = 4, MISALIGN = 0
  _681 = &MEM[(logical(kind=1)D.7[9] *)&A.23D.3720][0] + 4;
  # .MEM_942 = VDEF <.MEM_673>
  MEM[(logical(kind=1)D.7 *)_681] = vect_cst__721;
  # .MEM_1323 = VDEF <.MEM_942>
  MEM[(logical(kind=1)D.7[9] *)&A.23D.3720][8] = 1;

[Bug target/52551] i686-interix3: winnt.c:400:8: error: ‘flag_writable_rel_rdata’ undeclared

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2013-02-25 00:00:00 |2016-05-26
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from David Malcolm  ---
Confirmed; I still see this with recent trunk (r236397 fwiw), with build = host
= x86_64-pc-linux-gnu, target = i686-pc-interix3.

[Bug sanitizer/71291] Firefox with GCC reports stack-buffer-overflow but clang does not

[gk at torproject dot org]

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

--- Comment #5 from Georg Koppen  ---
And that's the g++ command line:

/usr/bin/g++ -std=gnu++11 -o Unified_cpp_gfx_layers2.o -c
-I/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/dist/stl_wrappers
-I/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/dist/system_wrappers
-include /home/thomas/Arbeit/Tor/mozilla-central/config/gcc_hidden.h -DNDEBUG=1
-DTRIMMED=1 -DGOOGLE_PROTOBUF_NO_RTTI -DOS_POSIX=1 -DOS_LINUX=1
-DSTATIC_EXPORTABLE_JS_API -DMOZILLA_INTERNAL_API -DIMPL_LIBXUL
-I/home/thomas/Arbeit/Tor/mozilla-central/gfx/layers
-I/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/gfx/layers
-I/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/ipc/ipdl/_ipdlheaders
-I/home/thomas/Arbeit/Tor/mozilla-central/ipc/chromium/src
-I/home/thomas/Arbeit/Tor/mozilla-central/ipc/glue
-I/home/thomas/Arbeit/Tor/mozilla-central/docshell/base
-I/home/thomas/Arbeit/Tor/mozilla-central/layout/base
-I/home/thomas/Arbeit/Tor/mozilla-central/layout/generic
-I/home/thomas/Arbeit/Tor/mozilla-central/gfx/skia
-I/home/thomas/Arbeit/Tor/mozilla-central/gfx/skia/skia/include/config
-I/home/thomas/Arbeit/Tor/mozilla-central/gfx/skia/skia/include/core
-I/home/thomas/Arbeit/Tor/mozilla-central/gfx/skia/skia/include/gpu
-I/home/thomas/Arbeit/Tor/mozilla-central/gfx/skia/skia/include/utils
-I/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/dist/include 
-I/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/dist/include/nspr
-I/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/dist/include/nss
  -fPIC  -DMOZILLA_CLIENT -include
/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/mozilla-config.h
-MD -MP -MF .deps/Unified_cpp_gfx_layers2.o.pp  -Wall -Wc++11-compat
-Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith
-Wsign-compare -Wtype-limits -Wunreachable-code -Wwrite-strings -Wc++14-compat
-Wno-invalid-offsetof -Wno-error=maybe-uninitialized
-Wno-error=deprecated-declarations -Wno-error=array-bounds -fsanitize=address
-Dxmalloc=myxmalloc -fno-exceptions -fno-strict-aliasing -fno-rtti
-fno-exceptions -fno-math-errno -pthread -pipe  -g -freorder-blocks -Os
-fno-omit-frame-pointer  
-I/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/dist/include/cairo
-I/home/thomas/Arbeit/Tor/mozilla-central/widget/gtk/compat-gtk3 -pthread
-I/usr/include/gtk-3.0/unix-print -I/usr/include/gtk-3.0
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0
-I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include
-I/usr/include/gtk-3.0 -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo
-I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1
-I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/gdk-pixbuf-2.0
-I/usr/include/libpng16 -I/usr/include/glib-2.0
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -Wno-error=shadow 
/home/thomas/Arbeit/Tor/mozilla-central/obj-x86_64-pc-linux-gnu/gfx/layers/Unified_cpp_gfx_layers2.cpp

Let me know if you need something more or I could do something to help tracking
this down.

[Bug c++/71290] [6/7 Regression] Flexible array member is not diagnosed with -pedantic

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2016-05-26
 CC||msebor at gcc dot gnu.org
  Known to work||4.9.3, 5.3.0
 Ever confirmed|0   |1
  Known to fail||6.1.0, 7.0

--- Comment #1 from Martin Sebor  ---
Confirmed (the warning disappeared because GCC's internal representation of 
flexible arrays has changed and is now different than that of zero length
arrays).  But since flexible array members are GCC's extension to C++ a
pedantic warning is called for.  Let me look into adding one.

[Bug tree-optimization/71289] Fails to optimize unsigned mul overflow check 'A > -1 / B'

[amonakov at gcc dot gnu.org]

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

--- Comment #2 from Alexander Monakov  ---
> What do the dumps look like? Gcc is likely to change things to -1 / B < A, 
> which you don't handle...

The dumps didn't help much, but you're right that normally the order is
opposite, thanks (I didn't realize that when looking in the debugger the first
time).

I tried to take into account your comments. I also had to make the output more
complex because emitting bare internal functions doesn't work. It still ICEs
for

typedef unsigned v2si __attribute__((vector_size(8)));
v2si h(v2si a, v2si b)
{
  v2si m = {~0, ~0};
  return (a > m / b);
}

but before debugging that I'd like to know if this is the right approach in the
first place.

diff --git a/gcc/match.pd b/gcc/match.pd
index e511e9a..a7fbcf1 100644
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -2582,6 +2582,32 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
&& types_match (TREE_TYPE (@0), TREE_TYPE (@1)))
(out (imagpart @2) { build_zero_cst (TREE_TYPE (@0)); }

+/* Simplify unsigned multiplication overflow check -1 / A < B to a builtin. 
*/
+(for cmp (lt ge)
+ out (ne eq)
+ (simplify
+  (cmp (trunc_div:s integer_all_onesp @0) @1)
+  (if (TYPE_UNSIGNED (TREE_TYPE (@0))
+   && !VECTOR_INTEGER_TYPE_P (TREE_TYPE (@0)))
+   (out
+(imagpart { build_call_expr_internal_loc (UNKNOWN_LOCATION,
+ IFN_MUL_OVERFLOW,
+ build_complex_type (TREE_TYPE
(@0)),
+ 2, @0, @1); } )
+{ build_zero_cst (TREE_TYPE (@0)); }
+
+(for cmp (gt le)
+ out (ne eq)
+ (simplify
+  (cmp @0 (trunc_div:s integer_all_onesp @1))
+  (if (TYPE_UNSIGNED (TREE_TYPE (@0))
+   && !VECTOR_INTEGER_TYPE_P (TREE_TYPE (@0)))
+   (out
+(imagpart { build_call_expr_internal_loc (UNKNOWN_LOCATION,
+ IFN_MUL_OVERFLOW,
+ build_complex_type (TREE_TYPE
(@0)),
+ 2, @0, @1); } )
+{ build_zero_cst (TREE_TYPE (@0)); }

 /* Simplification of math builtins.  These rules must all be optimizations
as well as IL simplifications.  If there is a possibility that the new

[Bug tree-optimization/71261] [7 Regression] Trunk GCC hangs on knl and broadwell targets

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||amker at gcc dot gnu.org

--- Comment #15 from amker at gcc dot gnu.org ---
PR71288 looks similar to this one, also looping in ifcvt_repair_bool_pattern.

[Bug target/71293] New: [7 regression] test case gcc.dg/plugin/must-tail-call-2.c fails starting with r236514

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 71293
   Summary: [7 regression] test case
gcc.dg/plugin/must-tail-call-2.c fails starting with
r236514
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

From looking at the test results for other platforms this appears to be
specific to power.  It fails on both BE and LE.


Executing on host: /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c  
-fno-diagnostics-show-caret -fdiagnostics-color=never 
-fplugin=./must_tail_call_plugin.so -Wno-pedantic -S   -o must-tail-call-2.s   
(timeout = 300)
spawn /home/seurer/gcc/build/gcc-trunk/gcc/xgcc
-B/home/seurer/gcc/build/gcc-trunk/gcc/
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c
-fno-diagnostics-show-caret -fdiagnostics-color=never
-fplugin=./must_tail_call_plugin.so -Wno-pedantic -S -o must-tail-call-2.s
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c: In
function 'test_1':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c:17:10:
error: cannot tail-call: callee returns a structure
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c: In
function 'test_2_caller':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c:32:10:
error: cannot tail-call: inconsistent size of stack space allocated for
arguments which are passed in registers
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c: In
function 'test_3':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c:39:3:
error: cannot tail-call: target is not able to optimize the call into a sibling
call
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c: In
function 'test_4':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c:48:3:
error: cannot tail-call: nested function
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c: In
function 'test_5':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c:57:3:
error: cannot tail-call: target is not able to optimize the call into a sibling
call
compiler exited with status 1
output is:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c: In
function 'test_1':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c:17:10:
error: cannot tail-call: callee returns a structure
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c: In
function 'test_2_caller':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c:32:10:
error: cannot tail-call: inconsistent size of stack space allocated for
arguments which are passed in registers
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c: In
function 'test_3':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c:39:3:
error: cannot tail-call: target is not able to optimize the call into a sibling
call
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c: In
function 'test_4':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c:48:3:
error: cannot tail-call: nested function
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c: In
function 'test_5':
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c:57:3:
error: cannot tail-call: target is not able to optimize the call into a sibling
call

PASS: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so 
(test for errors, line 17)
FAIL: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so 
(test for errors, line 32)
FAIL: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so 
(test for errors, line 39)
PASS: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so 
(test for errors, line 48)
FAIL: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so 
(test for errors, line 57)
FAIL: gcc.dg/plugin/must-tail-call-2.c -fplugin=./must_tail_call_plugin.so
(test for excess errors)
Excess errors:
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c:32:10:
error: cannot tail-call: inconsistent size of stack space allocated for
arguments which are passed in registers
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c:39:3:
error: cannot tail-call: target is not able to optimize the call into a sibling
call
/home/seurer/gcc/gcc-trunk/gcc/testsuite/gcc.dg/plugin/must-tail-call-2.c:57:3:
error: cannot tail-call: target is not able to optimize the call into a sibling
call

[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section

[anatol.pomozov at gmail dot com]

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

--- Comment #5 from Anatol  ---
This bug has been reported by Arch Linux users.
https://bugs.archlinux.org/task/49284

It is a severe compiler issue that stop avr-gcc 6 from using. Consider changing
"Importance" status to blocker.

[Bug target/71294] New: [6/7 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[marxin at gcc dot gnu.org]

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

Bug ID: 71294
   Summary: [6/7 Regression] ICE in gen_add2_insn, at
optabs.c:4442 on powerpc64le-linux
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello.

Following code snippet fails with:
./xgcc -B. -O3 -fstack-protector ice2.ii
ice2.ii: In function ‘void fn1()’:
ice2.ii:51:1: internal compiler error: in gen_add2_insn, at optabs.c:4442
 }
 ^
0xc00edb gen_add2_insn(rtx_def*, rtx_def*)
../../gcc/optabs.c:4442
0xc768b4 gen_reload
../../gcc/reload1.c:8710
0xc7a35e emit_input_reload_insns
../../gcc/reload1.c:7664
0xc7b3bc do_input_reload
../../gcc/reload1.c:7950
0xc7b3bc emit_reload_insns
../../gcc/reload1.c:8142
0xc7dd69 reload_as_needed
../../gcc/reload1.c:4661
0xc81a7b reload(rtx_insn*, int)
../../gcc/reload1.c:1062
0xb39da2 do_reload
../../gcc/ira.c:5393
0xb39da2 execute
../../gcc/ira.c:5565

$ cat ice2.ii
class A;
template  class B {
public:
  _Tp val[m * n];
};
class C {
public:
  C(A);
};
struct D {
  D();
  unsigned long &operator[](int);
  unsigned long *p;
};
class A {
public:
  template  A(const B<_Tp, m, n> &, bool);
  int rows, cols;
  unsigned char *data;
  unsigned char *datastart;
  unsigned char *dataend;
  unsigned char *datalimit;
  D step;
};
template 
A::A(const B<_Tp, m, n> &p1, bool)
: rows(m), cols(n) {
  step[0] = cols * sizeof(_Tp);
  datastart = data = (unsigned char *)p1.val;
  datalimit = dataend = datastart + rows * step[0];
}
class F {
public:
  static void compute(C);
  template 
  static void compute(const B<_Tp, m, n> &, B<_Tp, nm, 1> &, B<_Tp, m, nm> &,
  B<_Tp, n, nm> &);
};
D::D() {}
unsigned long &D::operator[](int p1) { return p[p1]; }
template 
void F::compute(const B<_Tp, m, n> &, B<_Tp, nm, 1> &, B<_Tp, m, nm> &,
B<_Tp, n, nm> &p4) {
  A a(p4, false);
  compute(a);
}
void fn1() {
  B b, c, e;
  B d;
  F::compute(b, d, c, e);
}

gcc version 5.2.1 works fine.

Martin

[Bug c/71219] Warn about (struct S*)malloc(n) where n < sizeof(struct S)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-26
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
I agree.  There's additional background on this rule in the CERT C Coding
Standard guideline MEM35-C. Allocate sufficient memory for an object
(https://www.securecoding.cert.org/confluence/x/2wE)

Let me add it to the of list security-related issues to diagnose I've been
working on.

[Bug rtl-optimization/71295] New: [7 Regression] internal compiler error: in subreg_get_info, at rtlanal.c:3673 on arm

[ktkachov at gcc dot gnu.org]

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

Bug ID: 71295
   Summary: [7 Regression] internal compiler error: in
subreg_get_info, at rtlanal.c:3673 on arm
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ktkachov at gcc dot gnu.org
  Target Milestone: ---
Target: arm

extern void fn2 (long long);
int a;

void
fn1 ()
{
  long long b[3];
  a = 0;
  for (; a < 3; a++)
b[a] = 1;
  fn2 (b[1]);
}

ICEs for me on arm with -O3 -march=armv8-a -mfpu=neon-fp-armv8 -mfloat-abi=hard

mycrash.c: In function 'fn1':
mycrash.c:12:1: internal compiler error: in subreg_get_info, at rtlanal.c:3673
 }
 ^
0xa7b284 subreg_get_info(unsigned int, machine_mode, unsigned int,
machine_mode, subreg_info*)
$SRC/gcc/rtlanal.c:3673
0xa7b52c simplify_subreg_regno(unsigned int, machine_mode, unsigned int,
machine_mode)
$SRC/gcc/rtlanal.c:3808
0xa500cc simplifiable_subregs(subreg_shape const&)
$SRC/gcc/reginfo.c:1234
0xa501b8 record_subregs_of_mode
$SRC/gcc/reginfo.c:1295
0xa50434 init_subregs_of_mode()
$SRC/gcc/reginfo.c:1349
0x947656 init_costs
$SRC/gcc/ira-costs.c:2187
0x94c0a8 ira_set_pseudo_classes(bool, _IO_FILE*)
$SRC/gcc/ira-costs.c:2237
0x1121695 alloc_global_sched_pressure_data
$SRC/gcc/haifa-sched.c:7244
0x1121695 sched_init()
$SRC/gcc/haifa-sched.c:7394
0x1122a13 haifa_sched_init()
$SRC/gcc/haifa-sched.c:7406
0xa878f1 schedule_insns()
$SRC/gcc/sched-rgn.c:3504
0xa880a1 rest_of_handle_sched
$SRC/gcc/sched-rgn.c:3717
0xa880a1 execute
$SRC/gcc/sched-rgn.c:3825
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


Bisection shows it started with r236582 but that's a SLP vectorisation patch so
I suspect it's exposing a latent issue

[Bug rtl-optimization/71295] [7 Regression] internal compiler error: in subreg_get_info, at rtlanal.c:3673 on arm

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

  Known to work||6.1.0
   Target Milestone|--- |7.0
  Known to fail||7.0

[Bug rtl-optimization/71295] [7 Regression] internal compiler error: in subreg_get_info, at rtlanal.c:3673 on arm

[ktkachov at gcc dot gnu.org]

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

--- Comment #1 from ktkachov at gcc dot gnu.org ---
The function is trying to handle a V2DImode subreg of an EImode reg when it
ICEs.
From the dumps I think it's due to the instruction:
(insn 6 15 16 2 (set (subreg:V2DI (reg/v:EI 111 [ b ]) 0)
(const_vector:V2DI [
(const_int 1 [0x1])
(const_int 1 [0x1])
])) mycrash.c:10 861 {*neon_movv2di}
 (nil))

[Bug target/70668] nds32-elf toolchain fails to compile on OSX

[jasonwucj at gcc dot gnu.org]

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

Chung-Ju Wu  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jakub at gcc dot gnu.org,
   ||jasonwucj at gcc dot gnu.org,
   ||law at redhat dot com,
   ||rguenth at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jasonwucj at gcc dot 
gnu.org
   Target Milestone|--- |7.0

--- Comment #8 from Chung-Ju Wu  ---
(In reply to Segher Boessenkool from comment #7)
> Fixed on trunk, backports pending.

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

Thank you for the patch to fix this issue.
Sorry I was busy on other stuff and didn't notice your mail last month.
I appreciate Jeff to help approve the patch. :)

I think this patch is also OK for gcc-5 and gcc-6 branches.

By the way, I guess this issue also appears on gcc-4.9 branch.
But I am not sure whether 4.9 branch is closed or not.
Maybe we need some comments from release managers.

Jakub/Richard, would you give us some comments? :)

[Bug target/71294] [6/7 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Started with r230091 which enabled a vectorization, thus the bug looks latent:


Author: rguenth 
Date:   Tue Nov 10 09:43:54 2015 +

2015-11-10  Richard Biener  

PR tree-optimization/56118
* tree-vect-slp.c (vect_bb_vectorization_profitable_p): Make equal
cost favor vectorized version.

* gcc.target/i386/pr56118.c: New testcase.

[Bug c/71219] Warn about (struct S*)malloc(n) where n < sizeof(struct S)

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 CC||nsz at gcc dot gnu.org

--- Comment #2 from nsz at gcc dot gnu.org ---
note that casting the return value of malloc is an anti-pattern in c and
dangerous (unfortunately widespread due to c++).

this effectively turns the type-checker off, which is an especially bad idea on
a compiler that accepts implicitly declared function calls assuming int return
type.

[Bug middle-end/71296] New: missing warning on strcat appending to a non-string

[msebor at gcc dot gnu.org]

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

Bug ID: 71296
   Summary: missing warning on strcat appending to a non-string
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While testing a fix for bug 70988 I came across a class of problems that should
be easy to diagnose but aren't:

1) No warning is issued for calls to strcat where the first argument is an
initialized array of characters that's not a (nul-terminated) string.

2) No warning is issued for calls to strcat where the first argument points to
an uninitialized array.

I make the Component middle-end since that's where these things are diagnosed
by Object Size Checking but it seems that at least a subset of these problems
could be diagnosed even without optimization.

$ cat strcat.c && /build/gcc-6-branch/gcc/xgcc -B /build/gcc-6-branch/gcc -O2
-S -Wall -Wextra strcat.c 
extern inline __attribute__ ((always_inline, artificial)) char *
strcat (char *d, const char *s)
{
  return __builtin___strcat_chk (d, s, __builtin_object_size (d, 0));
}

void sink (const char*);

void test_nonstring (void)
{
  char a [2] = { 'a', 'b' };
  strcat (a, "c");// writing past the end
  sink (a);
}

void test_uninit (void)
{
  char a [2];
  strcat (a, "c");// uninitialized read, possible past the end write
  sink (a);
}

[Bug target/71294] [6/7 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
tree-dump of the problematic function:

;; Function void fn1() (_Z3fn1v, funcdef_no=6, decl_uid=2937, cgraph_uid=4,
symbol_order=4)

void fn1() ()
{
  struct A a;
  struct C D.3115;
  struct C D.3114;
  struct B e;
  long unsigned int _4;
  vector(2) long unsigned int vect_cst__5;
  long unsigned int _6;
  vector(2) long unsigned int vect_cst__20;

  :
  _6 = (long unsigned int) &e.val;
  vect_cst__20 = {_6, _6};
  _4 = (long unsigned int) &MEM[(void *)&e + 128B];
  vect_cst__5 = {_4, _4};
  MEM[(struct  &)&a] ={v} {CLOBBER};
  a.rows = 4;
  a.cols = 4;
  MEM[(struct  &)&a + 40] ={v} {CLOBBER};
  MEM[(unsigned char * *)&a + 8B] = vect_cst__20;
  MEM[(unsigned char * *)&a + 24B] = vect_cst__5;
  C::C (&D.3114, a);
  F::compute (D.3115);
  D.3114 ={v} {CLOBBER};
  a ={v} {CLOBBER};
  e ={v} {CLOBBER};
  return;

}

236r.ira:

(insn 13 29 33 2 (set (mem/c:V2DI (plus:DI (reg/f:DI 113 sfp)
(reg:DI 166)) [5 MEM[(unsigned char * *)&a + 8B]+0 S16 A64])
(vec_select:V2DI (reg:V2DI 163)
(parallel:V2DI [
(const_int 1 [0x1])
(const_int 0 [0])
]))) /tmp/ice2.ii:29 841 {*vsx_stxvd2x2_le_v2di}
 (expr_list:REG_DEAD (reg:DI 166)
(expr_list:REG_DEAD (reg:V2DI 163)
(nil

237r.reload:

Reloads for insn # 13
Reload 0: reload_in (DI) = (plus:DI (reg/f:DI 1 1)
(const_int 240 [0xf0]))
BASE_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0)
reload_in_reg: (plus:DI (reg/f:DI 1 1)
(const_int 240 [0xf0]))
reload_reg_rtx: (reg:DI 10 10)
Reload 1: BASE_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0), optional, can't
combine, secondary_reload_p
Reload 2: GENERAL_REGS, RELOAD_FOR_OPERAND_ADDRESS (opnum = 0), optional, can't
combine, secondary_reload_p
secondary_out_reload = 1

secondary_out_icode = reload_v2di_di_store
Reload 3: reload_out (V2DI) = (mem/c:V2DI (plus:DI (plus:DI (reg/f:DI 1 1)
(const_int 240
[0xf0]))
(reg:DI 9 9 [166])) [5
MEM[(unsigned char * *)&a + 8B]+0 S16 A64])
NO_REGS, RELOAD_FOR_OUTPUT (opnum = 0), optional
reload_out_reg: (mem/c:V2DI (plus:DI (plus:DI (reg/f:DI 1 1)
(const_int 240
[0xf0]))
(reg:DI 9 9 [166])) [5
MEM[(unsigned char * *)&a + 8B]
(crashes here)

[Bug target/71294] [6/7 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[marxin at gcc dot gnu.org]

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

--- Comment #3 from Martin Liška  ---
The issues can be debugged with a cross-compiler:
../configure --enable-languages=c,c++ --disable-bootstrap
--target=ppc64le-suse-linux

[Bug target/71297] New: ICE on invalid code in altivec_resolve_overloaded_builtin (rs6000-c.c:5106) on powerpc64le-linux

[marxin at gcc dot gnu.org]

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

Bug ID: 71297
   Summary: ICE on invalid code in
altivec_resolve_overloaded_builtin (rs6000-c.c:5106)
on powerpc64le-linux
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---

Following code snippet ICEs with a cross-compiler
../configure --enable-languages=c,c++ --disable-bootstrap
--target=ppc64le-suse-linux:

$ cat /tmp/ice3.c 
int main()
{
  __builtin_vec_st();
}

$ ./xgcc -B. /tmp/ice3.c 
/tmp/ice3.c: In function ‘main’:
/tmp/ice3.c:3:3: internal compiler error: Segmentation fault
   __builtin_vec_st();
   ^~~~
0xe4e584 crash_signal
../../gcc/toplev.c:333
0x787155 vec::operator[](unsigned int)
../../gcc/vec.h:727
0x8971b6 altivec_resolve_overloaded_builtin(unsigned int, tree_node*, void*)
../../gcc/config/rs6000/rs6000-c.c:5106
0x8484f4 resolve_overloaded_builtin(unsigned int, tree_node*, vec*)
../../gcc/c-family/c-common.c:11329
0x796e15 c_build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*)
../../gcc/c/c-typeck.c:3113
0x7da27d c_parser_postfix_expression_after_primary
../../gcc/c/c-parser.c:8307
0x7d9a57 c_parser_postfix_expression
../../gcc/c/c-parser.c:8123
0x7d5bfe c_parser_unary_expression
../../gcc/c/c-parser.c:6939
0x7d5077 c_parser_cast_expression
../../gcc/c/c-parser.c:6768
0x7d3d7d c_parser_binary_expression
../../gcc/c/c-parser.c:6577
0x7d3643 c_parser_conditional_expression
../../gcc/c/c-parser.c:6348
0x7d3353 c_parser_expr_no_commas
../../gcc/c/c-parser.c:6265
0x7daa33 c_parser_expression
../../gcc/c/c-parser.c:8449
0x7dac88 c_parser_expression_conv
../../gcc/c/c-parser.c:8482
0x7d1037 c_parser_statement_after_labels
../../gcc/c/c-parser.c:5284
0x7d03f1 c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:4858
0x7cfde2 c_parser_compound_statement
../../gcc/c/c-parser.c:4693
0x7caa3a c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2105
0x7c94ec c_parser_external_declaration
../../gcc/c/c-parser.c:1549
0x7c9043 c_parser_translation_unit
../../gcc/c/c-parser.c:1430

and very similar ICE:

$ cat /tmp/ice4.c 
int main()
{
  __builtin_vec_ld();
}

$ ./xgcc -B. /tmp/ice4.c 
/tmp/ice4.c: In function ‘main’:
/tmp/ice4.c:3:3: internal compiler error: Segmentation fault
   __builtin_vec_ld();
   ^~~~
0xe4e584 crash_signal
../../gcc/toplev.c:333
0x787155 vec::operator[](unsigned int)
../../gcc/vec.h:727
0x896c2c altivec_resolve_overloaded_builtin(unsigned int, tree_node*, void*)
../../gcc/config/rs6000/rs6000-c.c:5044
0x8484f4 resolve_overloaded_builtin(unsigned int, tree_node*, vec*)
../../gcc/c-family/c-common.c:11329
0x796e15 c_build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*)
../../gcc/c/c-typeck.c:3113
0x7da27d c_parser_postfix_expression_after_primary
../../gcc/c/c-parser.c:8307
0x7d9a57 c_parser_postfix_expression
../../gcc/c/c-parser.c:8123
0x7d5bfe c_parser_unary_expression
../../gcc/c/c-parser.c:6939
0x7d5077 c_parser_cast_expression
../../gcc/c/c-parser.c:6768
0x7d3d7d c_parser_binary_expression
../../gcc/c/c-parser.c:6577
0x7d3643 c_parser_conditional_expression
../../gcc/c/c-parser.c:6348
0x7d3353 c_parser_expr_no_commas
../../gcc/c/c-parser.c:6265
0x7daa33 c_parser_expression
../../gcc/c/c-parser.c:8449
0x7dac88 c_parser_expression_conv
../../gcc/c/c-parser.c:8482
0x7d1037 c_parser_statement_after_labels
../../gcc/c/c-parser.c:5284
0x7d03f1 c_parser_compound_statement_nostart
../../gcc/c/c-parser.c:4858
0x7cfde2 c_parser_compound_statement
../../gcc/c/c-parser.c:4693
0x7caa3a c_parser_declaration_or_fndef
../../gcc/c/c-parser.c:2105
0x7c94ec c_parser_external_declaration
../../gcc/c/c-parser.c:1549
0x7c9043 c_parser_translation_unit
../../gcc/c/c-parser.c:1430

Thanks

[Bug c++/71298] New: changes to libstdc++ breaks windows builds

[ralphengels at gmail dot com]

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

Bug ID: 71298
   Summary: changes to libstdc++ breaks windows builds
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ralphengels at gmail dot com
  Target Milestone: ---

gcc-6.1.0 libstdc++ cannot find stdlib.h on mingw-w64.
the change seems to have been cstdlib where the include was changed to
include_next.

[Bug rtl-optimization/71295] [7 Regression] internal compiler error: in subreg_get_info, at rtlanal.c:3673 on arm

[ktkachov at gcc dot gnu.org]

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

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Setting info->representable_p to false and returning on the condition that
GET_MODE_SIZE (ymode) + offset > GET_MODE_SIZE (xmode)
in that function fixes the ICE for me (though I haven't tested further) as 
record_subregs_of_mode consciously tries to call subreg_get_info on a V2DI
subreg of an EImode (24 byte size) reg at offset 16, which is not valid

[Bug tree-optimization/71299] New: [7 regression] test case gcc.dg/torture/pr69909.c fails with ICE starting with r236634

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 71299
   Summary: [7 regression] test case gcc.dg/torture/pr69909.c
fails with ICE starting with r236634
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

This fails on both BE and LE.

Here is one example of the six similar failures (with different compilation
options) for this test case:

Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/pr69909.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never-O0  -w  -lm-o
./pr69909.exe(timeout = 300)
spawn /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/pr69909.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -w -lm -o
./pr69909.exe
PASS: gcc.dg/torture/pr69909.c   -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/build/gcc-test2/gcc::/home/seurer/gcc/build/gcc-test2/gcc:/home/wschmidt/gcc/install/gcc-5_1/lib64
spawn [open ...]
PASS: gcc.dg/torture/pr69909.c   -O0  execution test
Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/pr69909.c 
-fno-diagnostics-show-caret -fdiagnostics-color=never-O1  -w  -lm-o
./pr69909.exe(timeout = 300)
spawn /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/pr69909.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -O1 -w -lm -o
./pr69909.exe
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/pr69909.c: In function
'foo':
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/pr69909.c:10:1: error:
definition in block 2 follows the use
for SSA_NAME: _13 in statement:
_3 = _13 * 2;
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.dg/torture/pr69909.c:10:1:
internal compiler error: verify_ssa failed
0x10b093b3 verify_ssa(bool, bool)
/home/seurer/gcc/gcc-test2/gcc/tree-ssa.c:1039
0x107853af execute_function_todo
/home/seurer/gcc/gcc-test2/gcc/passes.c:1971
0x10785fd3 do_per_function
/home/seurer/gcc/gcc-test2/gcc/passes.c:1648
0x107862ef execute_todo
/home/seurer/gcc/gcc-test2/gcc/passes.c:2016
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1

[Bug libstdc++/70762] FAIL: experimental/filesystem/operations/copy.cc execution test on x86_64-apple-darwin1*

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
Author: redi
Date: Thu May 26 17:18:13 2016
New Revision: 236786

URL: https://gcc.gnu.org/viewcvs?rev=236786&root=gcc&view=rev
Log:
libstdc++/70762 fix fallback implementation of nonexistent_path

Backport from mainline
2016-04-24  Jonathan Wakely  

PR libstdc++/70762
* testsuite/util/testsuite_fs.h (__gnu_test::nonexistent_path): Use
static counter to return a different path on every call.

Modified:
branches/gcc-6-branch/libstdc++-v3/ChangeLog
branches/gcc-6-branch/libstdc++-v3/testsuite/util/testsuite_fs.h

[Bug c++/71283] Inconsistent location for C++ warning options in the manual

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Keywords||easyhack
 Status|RESOLVED|NEW
   Last reconfirmed||2016-05-26
 CC||manu at gcc dot gnu.org
 Resolution|INVALID |---
Summary|-Wterminate is not  |Inconsistent location for
   |described in "Options to|C++ warning options in the
   |Request or Suppress |manual
   |Warnings"   |
 Ever confirmed|0   |1

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Eric Gallager from comment #3)
> There are other C++-only options under "Options to Request or Suppress
> Warnings".
> For example:
> * -Wc++11-compat
> * -Wc++14-compat
> * -Wconditionally-supported
> * -Wno-conversion-null
> * -Wzero-as-null-pointer-constant
> * -Wsubobject-linkage
> * -Wdelete-incomplete
> * -Wuseless-cast
> * -Wsized-deallocation
> * -Wno-invalid-offsetof
> 
> It's kind of inconsistent whether C++-only warnings are listed here or there.

The perfect solution would be to move the options documentation to the *.opt
files where they are defined and auto-generate the corresponding parts of the
*.texi files from the *.opt files. This way the documentation would be much
more consistent. This is similar to what we already do for target-hooks: see
gcc/target.def

That would be a very nice little project for a newbie.

The short-term solution is for someone to propose patches to move those to the
correct place:
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

[Bug target/71300] New: Vector ABI bug for some AVX vectorized variants

[andrew.n.senkevich at gmail dot com]

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

Bug ID: 71300
   Summary: Vector ABI bug for some AVX vectorized variants
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew.n.senkevich at gmail dot com
  Target Milestone: ---

Hi,

according with Vector ABI vectorized variant in AVX ISA of

#pragma omp declare simd notinbranch
void callee(double, double*);

expects ymm0 filled with 4 doubles and ymm1 filled with 4 double* values.

But really double* values are passed in xmm1 and xmm2, that leads to important
ABI issue.

-bash-4.2$ cat test.cc

#pragma omp declare simd notinbranch
extern void callee(double a, double* b);

#define VLEN 4

typedef double __attribute__((vector_size(8 * VLEN))) vec;
vec x, r;

int main()
{
for (int i = 0; i < VLEN; i++) x[i] = i;

#pragma omp simd
for (int i = 0; i < VLEN; i++) callee(x[i], &r[i]);

return (int)r[VLEN-1];
}

g++ -O1 -fopenmp -ffast-math test.cc -mavx -c

-bash-4.2$ objdump -d test.o

test.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   4c 8d 54 24 08  lea0x8(%rsp),%r10
   5:   48 83 e4 e0 and$0xffe0,%rsp
   9:   41 ff 72 f8 pushq  -0x8(%r10)
   d:   55  push   %rbp
   e:   48 89 e5mov%rsp,%rbp
  11:   41 52   push   %r10
  13:   48 83 ec 28 sub$0x28,%rsp
  17:   48 c7 05 00 00 00 00movq   $0x0,0x0(%rip)# 22 
  1e:   00 00 00 00
  22:   c5 fb 10 1d 00 00 00vmovsd 0x0(%rip),%xmm3# 2a 
  29:   00
  2a:   c5 fb 11 1d 00 00 00vmovsd %xmm3,0x0(%rip)# 32 
  31:   00
  32:   c5 fb 10 25 00 00 00vmovsd 0x0(%rip),%xmm4# 3a 
  39:   00
  3a:   c5 fb 11 25 00 00 00vmovsd %xmm4,0x0(%rip)# 42 
  41:   00
  42:   c5 fb 10 2d 00 00 00vmovsd 0x0(%rip),%xmm5# 4a 
  49:   00
  4a:   c5 fb 11 2d 00 00 00vmovsd %xmm5,0x0(%rip)# 52 
  51:   00
  52:   c5 fb 12 0d 00 00 00vmovddup 0x0(%rip),%xmm1# 5a

  59:   00
  5a:   c5 f9 28 3d 00 00 00vmovapd 0x0(%rip),%xmm7# 62 
  61:   00
  62:   c5 f8 29 7d d0  vmovaps %xmm7,-0x30(%rbp)
  67:   c5 f9 28 05 00 00 00vmovapd 0x0(%rip),%xmm0# 6f 
  6e:   00
  6f:   c5 f8 29 45 e0  vmovaps %xmm0,-0x20(%rbp)
  74:   c5 f1 d4 15 00 00 00vpaddq 0x0(%rip),%xmm1,%xmm2# 7c

  7b:   00
  7c:   c5 f1 d4 0d 00 00 00vpaddq 0x0(%rip),%xmm1,%xmm1# 84

  83:   00
  84:   c5 fd 28 45 d0  vmovapd -0x30(%rbp),%ymm0
  89:   e8 00 00 00 00  callq  8e 
  8e:   c5 fb 2c 05 00 00 00vcvttsd2si 0x0(%rip),%eax# 96

  95:   00
  96:   48 83 c4 28 add$0x28,%rsp
  9a:   41 5a   pop%r10
  9c:   5d  pop%rbp
  9d:   49 8d 62 f8 lea-0x8(%r10),%rsp
  a1:   c3  retq

[Bug libstdc++/70762] FAIL: experimental/filesystem/operations/copy.cc execution test on x86_64-apple-darwin1*

[redi at gcc dot gnu.org]

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

--- Comment #10 from Jonathan Wakely  ---
Author: redi
Date: Thu May 26 17:33:17 2016
New Revision: 236788

URL: https://gcc.gnu.org/viewcvs?rev=236788&root=gcc&view=rev
Log:
libstdc++/70762 fix fallback implementation of nonexistent_path

Backport from mainline
2016-04-24  Jonathan Wakely  

PR libstdc++/70762
* testsuite/util/testsuite_fs.h (__gnu_test::nonexistent_path): Use
static counter to return a different path on every call.

Modified:
branches/gcc-5-branch/libstdc++-v3/ChangeLog
branches/gcc-5-branch/libstdc++-v3/testsuite/util/testsuite_fs.h

[Bug rtl-optimization/71275] [7 regression] Performance drop after r235660 on x86-64 in 32-bit mode.

[amodra at gcc dot gnu.org]

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

--- Comment #4 from Alan Modra  ---
Author: amodra
Date: Thu May 26 17:38:36 2016
New Revision: 236789

URL: https://gcc.gnu.org/viewcvs?rev=236789&root=gcc&view=rev
Log:
ira.c bb_loop_depth

PR rtl-optimization/71275
* ira.c (ira): Call loop_optimizer_init to set up bb_loop_depth
for update_equiv_regs and combine_and_move_insns.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/ira.c

[Bug tree-optimization/71237] [7 regression] scev tests failing after pass reorganization

[andre.simoesdiasvieira at arm dot com]

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

--- Comment #1 from Andre Vieira  ---
So yes disabling LIM will make the tests "PASS". Though I couldnt find an
option to do this, I disabled the pass by changing passes.def, so that doesnt
sound like a good idea to test SCCP. 

However, it might be good to point out that at least for arm-none-eabi and
x86_64-pc-linux-gnu these tests are no longer testing SCCP, SCCP will not
change this code. I looked at the dumps and compared assembly of -O2 with and
without '-fno-tree-scev-cprop'.

On arm-none-eabi, it used to be IVOPTS that made the test pass, it would reuse
the same ivtmp for computing the address used by the memory dereference and the
a_p assignment. Now due to the reordering of LIM, it will no longer do this.

On x86_64 I see the following code coming out of the OPTIMIZED dump for the
scev-4.c case:

...
  :
  # ivtmp.10_14 = PHI <_24(3), ivtmp.10_25(4)>
  i_11 = (int) ivtmp.10_14;
  MEM[symbol: a, index: ivtmp.10_14, step: 8, offset: 4B] = 100;
  ivtmp.10_25 = ivtmp.10_14 + _24;
  i_22 = (int) ivtmp.10_25;
  if (i_22 <= 999)
goto ;
  else
goto ;

  :
  _2 = (sizetype) i_11;
  _3 = _2 * 8;
  _10 = _3 + 4;
  _1 = &a + _10;
  a_p = _1;
...

Now yes the scan-times &a will pass, but thats because the MEM is using
symbol:a instead of base: &a. Not sure this can be qualified as a proper PASS.
Disabling LIM here the same way I did before, that is removing the pass_lim
after pass_laddress and before pass_split_crit_edges generates the following
OPTIMIZED dump:

...
  :
  _16 = (sizetype) k_4(D);
  _15 = _16 * 8;
  _21 = _15 + 4;
  _22 = &a + _21;
  ivtmp.9_14 = (unsigned long) _22;

  :
  # i_11 = PHI 
  # ivtmp.9_13 = PHI 
  _1 = (int *) ivtmp.9_13;
  MEM[base: _1, offset: 0B] = 100;
  i_8 = k_4(D) + i_11;
  ivtmp.9_17 = ivtmp.9_13 + _15;
  if (i_8 <= 999)
goto ;
  else
goto ;

  :
  a_p = _1;
...

I prefer this output, since you loose the needless tailing address calculation.
I am not so sure the eventually generated assembly is better in this case
though. Ill add both as attachments.

[Bug rtl-optimization/71275] [7 regression] Performance drop after r235660 on x86-64 in 32-bit mode.

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

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

--- Comment #5 from Alan Modra  ---
Fixed

[Bug tree-optimization/71237] [7 regression] scev tests failing after pass reorganization

[andre.simoesdiasvieira at arm dot com]

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

--- Comment #2 from Andre Vieira  ---
Created attachment 38575
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38575&action=edit
Assembly with the changed passes.def removing one pass of lim

[Bug tree-optimization/71237] [7 regression] scev tests failing after pass reorganization

[andre.simoesdiasvieira at arm dot com]

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

--- Comment #3 from Andre Vieira  ---
Created attachment 38576
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38576&action=edit
Regular generation at -O2

[Bug c/71219] Warn about (struct S*)malloc(n) where n < sizeof(struct S)

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
That example is just taken straight from the WG14 document I linked to. Maybe
the compiler should also be able to presume that the allocation is intended for
struct S1 if you do:

struct S1 *p = malloc(sizeof(p));

but I wanted to suggest following exactly what the secure coding guidelines
require.

[Bug fortran/52393] I/O: "READ format" statement with parenthesed default-char-expr

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle  ---
Created attachment 38577
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38577&action=edit
Final patch, regression tested

I will submit this patch to list for approval.

[Bug libstdc++/71301] New: std::tuple move constructor

[glisse at gcc dot gnu.org]

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

Bug ID: 71301
   Summary: std::tuple move constructor
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ABI
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---

#include 
#include 
struct A { A(A&&)=delete; };
static_assert(std::is_trivially_move_constructible>::value);
static_assert(!std::is_move_constructible>::value);

Both assertions fail, the move constructor should be better constrained, and
trivial when it can be. But that breaks the ABI.

Discussion (in 3 parts in the archives):
https://gcc.gnu.org/ml/libstdc++/2016-04/msg00039.html
https://gcc.gnu.org/ml/libstdc++/2016-05/msg7.html
https://gcc.gnu.org/ml/libstdc++/2016-05/msg00050.html

[Bug c++/70106] [4.9/5 Regression][C++11 or above] adding parenthesis [cerr << (var)] cause error: invalid static_cast from type 'const size_t {aka const long unsigned int}' to type 'size_t& {aka long

[ppalka at gcc dot gnu.org]

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

--- Comment #7 from Patrick Palka  ---
Author: ppalka
Date: Thu May 26 18:17:43 2016
New Revision: 236792

URL: https://gcc.gnu.org/viewcvs?rev=236792&root=gcc&view=rev
Log:
Fix PR c++/70822 (bogus error with parenthesized SCOPE_REF)

gcc/cp/ChangeLog:

PR c++/70822
PR c++/70106
* cp-tree.h (REF_PARENTHESIZED_P): Make this flag apply to
SCOPE_REFs too.
* pt.c (tsubst_qualified_id): If REF_PARENTHESIZED_P is set
on the qualified_id then propagate it to the resulting
expression.
(do_auto_deduction): Check REF_PARENTHESIZED_P on SCOPE_REFs
too.
* semantics.c (force_paren_expr): If given a SCOPE_REF, just set
its REF_PARENTHESIZED_P flag.

gcc/testsuite/ChangeLog:

PR c++/70822
PR c++/70106
* g++.dg/cpp1y/auto-fn32.C: New test.
* g++.dg/cpp1y/paren4.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn32.C
trunk/gcc/testsuite/g++.dg/cpp1y/paren4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/71123] Namelist read failure on Windows

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #6 from Jerry DeLisle  ---
Kai,

If you have time, could you check this actually works on Windows before I close
it. It fixes my linux version of the bug.

Thanks,

Jerry

[Bug c++/70822] [6/7 Regression] bogus "error: lvalue required as unary ‘&’ operand" with C++14 parenthesized SCOPE_REF

[ppalka at gcc dot gnu.org]

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

--- Comment #2 from Patrick Palka  ---
Author: ppalka
Date: Thu May 26 18:17:43 2016
New Revision: 236792

URL: https://gcc.gnu.org/viewcvs?rev=236792&root=gcc&view=rev
Log:
Fix PR c++/70822 (bogus error with parenthesized SCOPE_REF)

gcc/cp/ChangeLog:

PR c++/70822
PR c++/70106
* cp-tree.h (REF_PARENTHESIZED_P): Make this flag apply to
SCOPE_REFs too.
* pt.c (tsubst_qualified_id): If REF_PARENTHESIZED_P is set
on the qualified_id then propagate it to the resulting
expression.
(do_auto_deduction): Check REF_PARENTHESIZED_P on SCOPE_REFs
too.
* semantics.c (force_paren_expr): If given a SCOPE_REF, just set
its REF_PARENTHESIZED_P flag.

gcc/testsuite/ChangeLog:

PR c++/70822
PR c++/70106
* g++.dg/cpp1y/auto-fn32.C: New test.
* g++.dg/cpp1y/paren4.C: New test.


Added:
trunk/gcc/testsuite/g++.dg/cpp1y/auto-fn32.C
trunk/gcc/testsuite/g++.dg/cpp1y/paren4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/cp-tree.h
trunk/gcc/cp/pt.c
trunk/gcc/cp/semantics.c
trunk/gcc/testsuite/ChangeLog

[Bug target/70668] nds32-elf toolchain fails to compile on OSX

[rguenther at suse dot de]

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

--- Comment #9 from rguenther at suse dot de  ---
On May 26, 2016 6:01:39 PM GMT+02:00, "jasonwucj at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70668
>
>Chung-Ju Wu  changed:
>
>   What|Removed |Added
>
> Status|NEW |ASSIGNED
>  CC||jakub at gcc dot gnu.org,
>||jasonwucj at gcc dot gnu.org,
>   ||law at redhat dot com,
>   ||rguenth at gcc dot gnu.org
>Assignee|unassigned at gcc dot gnu.org  |jasonwucj at gcc dot
>gnu.org
>   Target Milestone|--- |7.0
>
>--- Comment #8 from Chung-Ju Wu  ---
>(In reply to Segher Boessenkool from comment #7)
>> Fixed on trunk, backports pending.
>
>https://gcc.gnu.org/ml/gcc-patches/2016-04/msg01862.html
>
>Thank you for the patch to fix this issue.
>Sorry I was busy on other stuff and didn't notice your mail last month.
>I appreciate Jeff to help approve the patch. :)
>
>I think this patch is also OK for gcc-5 and gcc-6 branches.
>
>By the way, I guess this issue also appears on gcc-4.9 branch.
>But I am not sure whether 4.9 branch is closed or not.
>Maybe we need some comments from release managers.
>
>Jakub/Richard, would you give us some comments? :)

It's still open.  The gcc.Gnu.org main page states the status of active
branches.

[Bug target/71300] Vector ABI bug for some AVX vectorized variants

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
???
At least reading to 0.9.8 version of the ABI pdf, I see for YMM1 class:
  sizeof (bytes)  VLEN=2   VLEN=4VLEN=8VLEN=16
...
any-type *   4/8  1*MI128/ 1*MI128/  2*MI128/  4*MI128/
any-type (*)()1*MI128  2*MI128   4*MI128   8*MI128
...
double   81*MD128  1*MD256   2*MD256   4*MD256

The characteristic type is double in this function, therefore for YMM1 class
(letter c) this function is VLEN=4, which means the first argument is passed
in __m256d (holding 4 doubles) and the second argument is passed in a pair of
__m128i (each holding 2 pointers).
This is because AVX generally doesn't support 256-bit integer vector
operations.
If you look at YMM2 class instead, pointers are passed in __m256i instead (for
VLEN=4 and above).

[Bug bootstrap/70896] gcc4 ABI compatible bootstrap fails

[tulipawn at gmail dot com]

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

--- Comment #9 from PeteVine  ---
I've rerun the same `configure` command against gcc-7-20160522 source, only
with `---disable-bootstrap`, and all went fine. The latter issue is definitely
gone, not sure about the original one. If disabling bootstrap couldn't have
mattered, it must have been fixed behind the scenes too.

[Bug other/71268] [PATCH] Fix description of x86_64's -m32 option

[ismael at linux dot com]

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

Ismael Luceno  changed:

   What|Removed |Added

  Attachment #38558|0   |1
is obsolete||

--- Comment #2 from Ismael Luceno  ---
Created attachment 38578
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38578&action=edit
Reviewed version of the patch

[Bug c++/71166] [6/7 Regression] ICE with nested constexpr/initializer

[nathan at gcc dot gnu.org]

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

--- Comment #6 from Nathan Sidwell  ---
Adding an at_eof check into try_const fixes the testcase.  (also) Adding an
at_eof <= 1 assert into cxx_eval_outermost_constant_expr causes 261 new fails. 
Although many are obviously init & ctor related, they're a fairly widely
distributed bunch -- one is even abi name mangling. I don't see any a priori
reason as to why those calls to cxx_eval_outermost_constant_expr couldn't end
up evaluating a constexpr call.

[Bug tree-optimization/71289] Fails to optimize unsigned mul overflow check 'A > -1 / B'

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
I think genmatch can handle calls to internal functions, the issue is with
guessing the return type. Maybe we could have a specific heuristic for these
functions in the case where the type is not explicitly specified.

(for cmp (lt ge)
 out (ne eq)
 (simplify
  (cmp (trunc_div:s integer_all_onesp @1) @0)
  (if (TYPE_UNSIGNED (TREE_TYPE (@0)) 
   && !VECTOR_TYPE_P (TREE_TYPE (@0)))
   (with { tree cpx = build_complex_type (TREE_TYPE (@0)); }
(out 
 (imagpart (IFN_MUL_OVERFLOW:cpx @0 @1))
 { build_zero_cst (TREE_TYPE (@0)); })

(and the symmetric)

The approach seems fine to me.

[Bug middle-end/71296] missing warning on strcat appending to a non-string

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Another problem is with strcat appending to a buffer initialized using the
array notation like below where it also assumes it's starting at the beginning
of the buffer (and so only diagnoses writes in excess of its full size).

void f (void)
{
  {
char a [4] = { '1', '2', '3', '\0' };
strcat (a, "456");   // buffer overflow not diagnosed
sink (a);
  }
}

[Bug c++/71302] New: -Wzero-as-null-pointer-constant: misleading caret location for pointer in function call

[eugene.zelenko at gmail dot com]

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

Bug ID: 71302
   Summary: -Wzero-as-null-pointer-constant: misleading caret
location for pointer in function call
   Product: gcc
   Version: 6.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eugene.zelenko at gmail dot com
  Target Milestone: ---

Created attachment 38579
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38579&action=edit
Simple test case

-Wzero-as-null-pointer-constant incorrectly points to closing bracket instead
of actual argument which should take nullptr.

Same problem exists in 4.9 and 5.

[Bug middle-end/71303] New: missing strlen optimization for strings initialized via a braced-init-list

[msebor at gcc dot gnu.org]

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

Bug ID: 71303
   Summary: missing strlen optimization for strings initialized
via a braced-init-list
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

While continuing my exploration of tree-ssa-strlen.c I discovered that while
optimizes a strlen call when the argument is an array initialized using a
string (as in function f below), it doesn't optimize it when the argument is
initialized using the braced initializer-list (as in g below).  This is also
the root cause behind at least part of bug 71296.

(As a data point, Clang 3.8 emits optimal code for both functions in the test
case.)

$ cat strlen.c && /build/gcc-6-branch/gcc/xgcc -B /build/gcc-6-branch/gcc -O2
-S -Wall -Wextra -fdump-tree-optimized=/dev/stdout strlen.c 
int f (void)
{
  char s[] = "12345";
  return __builtin_strlen (s);
}

int g (void)
{
  char s[] = { '1', '2', '3', '4', '5', '\0' };
  return __builtin_strlen (s);
}

;; Function f (f, funcdef_no=0, decl_uid=1756, cgraph_uid=0, symbol_order=0)

f ()
{
  :
  return 5;

}



;; Function g (g, funcdef_no=1, decl_uid=1760, cgraph_uid=1, symbol_order=1)

g ()
{
  char s[6];
  long unsigned int _8;
  int _9;

  :
  s[0] = 49;
  s[1] = 50;
  s[2] = 51;
  s[3] = 52;
  s[4] = 53;
  s[5] = 0;
  _8 = __builtin_strlen (&s);
  _9 = (int) _8;
  s ={v} {CLOBBER};
  return _9;

}

[Bug bootstrap/71292] Bootstrap failure with segfault in tree-reassoc.c

[kugan at gcc dot gnu.org]

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

--- Comment #1 from kugan at gcc dot gnu.org ---
(In reply to ktkachov from comment #0)
> An aarch64-none-linux-gnu bootstrap with an in-tree mpfr fails with an ICE:
> exp_2.i: In function ‘fn1’:
> exp_2.i:4:6: internal compiler error: Segmentation fault
>  void fn1() {
>   ^~~
> 0xb1f8cf crash_signal
> $SRC/gcc/toplev.c:333
> 0x89bcb9 bb_seq_addr
> $SRC/gcc/gimple.h:1655
> 0x89bcb9 gsi_start_bb
> $SRC/gcc/gimple-iterator.h:129
> 0x89bcb9 gsi_for_stmt(gimple*)
> $SRC/gcc/gimple-iterator.c:617
> 0xcbbeba insert_stmt_after
> $SRC/gcc/tree-ssa-reassoc.c:1323
> 0xcbd67a build_and_add_sum
> $SRC/gcc/tree-ssa-reassoc.c:1392
> 0xcbf34f rewrite_expr_tree_parallel
> $SRC/gcc/tree-ssa-reassoc.c:4128
> 0xcc8b95 reassociate_bb
> $SRC/gcc/tree-ssa-reassoc.c:5339
> 0xcc8ad7 reassociate_bb
> $SRC/gcc/tree-ssa-reassoc.c:5391
> 0xccb523 do_reassoc
> $SRC/gcc/tree-ssa-reassoc.c:5505
> 0xccb523 execute_reassoc
> $SRC/gcc/tree-ssa-reassoc.c:5592
> 0xccb523 execute
> $SRC/gcc/tree-ssa-reassoc.c:5631
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See <http://gcc.gnu.org/bugs.html> for instructions.
> 
> The reduced testcase for that reproducible with trunk at:
> gcc version 7.0.0 20160526 
> is:
> 
> unsigned long a;
> long b, d;
> int c;
> void fn1() {
>   unsigned long e = a + c;
>   b = d + e + a + 8;
> }
> 
> compile with -O2.
> Compiling with -fno-tree-reassoc doesn't ICE

It looks like dup of PR71252.

does the patch at help? 
https://gcc.gnu.org/ml/gcc-patches/2016-05/msg02076.html

[Bug middle-end/71296] missing warning on strcat appending to a non-string

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Depends on||71303

--- Comment #2 from Martin Sebor  ---
I suspect the problem in the aggregate initialization case is due to bug 71303.
 With it fixed, this bug should be reduced to the missing warning appending to
an uninitialized array.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71303
[Bug 71303] missing strlen optimization for strings initialized via a
braced-init-list

[Bug target/71294] [6/7 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-26
 Ever confirmed|0   |1

--- Comment #4 from acsawdey at gcc dot gnu.org ---
I tested this with trunk 236751 and I see the ICE.

It does not fail if you add -mlra.

It also does not fail with -mcpu=power7.

[Bug target/71294] [6/7 Regression] ICE in gen_add2_insn, at optabs.c:4442 on powerpc64le-linux

[segher at gcc dot gnu.org]

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

--- Comment #5 from Segher Boessenkool  ---
It also fails on BE.  It needs -O3 -fstack-protector -mcpu=power8 to fail.

[Bug fortran/71156] PURE interface/definition inconsistency: accepts invalid, rejects valid

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-26
 Ever confirmed|0   |1

--- Comment #4 from Dominique d'Humieres  ---
Since there is a patch, I assume the PR is confirmed!-)

[Bug c++/71302] -Wzero-as-null-pointer-constant: misleading caret location for pointer in function call

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-05-26
 CC||manu at gcc dot gnu.org
 Depends on||43486
 Ever confirmed|0   |1

--- Comment #1 from Manuel López-Ibáñez  ---
I don't think this can be fixed without having locations for constants (or at
least for the arguments of function calls, thus fixing PR43486.)


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43486
[Bug 43486] Preserve variable-use locations

[Bug c++/57342] [C++11] Warning for narrowing conversion has ugly formatting for floating point number

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

   Last reconfirmed|2013-05-21 00:00:00 |2016-5-26
Version|4.9.0   |7.0

--- Comment #4 from Manuel López-Ibáñez  ---
(In reply to Paolo Carlini from comment #2)
> Maybe Manuel means PR33067, where we made some progress in caret-less times.
> In the meanwhile those examples are fixed, we shall fix this one too, of
> course.

Yes. Removing the %qE and printing instead the type to which we are narrowing
(like Clang does) would already be an improvement. Still broken in trunk.