[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vehre at gmx dot de

--- Comment #7 from vries at gcc dot gnu.org ---
Andre,

given that you've added the POINTER_PLUS_EXPR test (and other code in the
condition) in the snippet from comment 5, can you take a look at this PR?

Thanks,
- Tom

[Bug c++/69005] [5/6 Regression] infinite(?) recursion in template instantiations

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Hmm, __and_ is supposed to shortcut, but the way I use it here doesn't take
advantage of that because _Invoke is always instantiated even when _NotSelf is
false.

Replacing is_same<_Invoke<...>, ...> with something that only evaluates the
decltype expression as needed should work.

[Bug c++/69005] [5/6 Regression] infinite(?) recursion in template instantiations

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
I'll try your suggestion first though.

In the real code we also use _Callable in the templated assignment operator,
where the argument can be deduced as the class type, but that can be done
differently too.

[Bug c/69037] New: arrays of constants as function arguments misinterpreted

[arigo at tunes dot org]

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

Bug ID: 69037
   Summary: arrays of constants as function arguments
misinterpreted
   Product: gcc
   Version: 5.3.1
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arigo at tunes dot org
  Target Milestone: ---

The following occurs in `gcc_5_branch` but not in the 5.3.0 release tag.

The C front-end misinterprets arrays of constants which are passed as function
arguments.  Example:

typedef const int array_t[3];
int allocate_with_allocator(array_t ar)
{
int a = ar[0];
int b = ar[1];
return a + b;
}

This produces two warnings on the lines defining `int a` and `int b`
("initialization makes integer from pointer without a cast") and outputs bogus
code (tested with `gcc -S -O2` on x86-64):

leal12(%rdi,%rdi), %eax
ret

Note that it works fine if we remove "const" from the example above.  In that
case, or on previous versions of gcc (up to and including 5.3.0), the code is
compiled without warning to:

movl4(%rdi), %eax
addl(%rdi), %eax
ret

Fwiw, this error is consistent with the argument "ar" being mistakenly
considered to be of type "array_t *" instead of "array_t".

[Bug other/69038] New: sparc64 compilation fails with error: unable to find a register to spill in class 'FP_REGS'

[thomas.petazz...@free-electrons.com]

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

Bug ID: 69038
   Summary: sparc64 compilation fails with error: unable to find a
register to spill in class 'FP_REGS'
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com
  Target Milestone: ---

Created attachment 37123
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37123&action=edit
Preprocessed source file

When building the libvips library with sparc64 gcc 5.3.0, the build fails with:

nohalo.cpp: In function 'void
vips_interpolate_nohalo_interpolate(VipsInterpolate*, void*, VipsRegion*,
double, double)':
nohalo.cpp:1571:1: error: unable to find a register to spill in class 'FP_REGS'
 }
 ^
nohalo.cpp:1571:1: error: this is the insn:
(insn 555 554 3791 8 (set (reg:DF 32 %f0)
(float:DF (reg:SI 1852 [ MEM[base: p_139, index: _138, offset: 0B]+-3
]))) nohalo.cpp:1463 155 {floatsidf2}
 (expr_list:REG_DEAD (reg:SI 1852 [ MEM[base: p_139, index: _138, offset:
0B]+-3 ])
(nil)))

This build failure happens at -O1, -O2, -Os, but not at -O0:

test@build:~/buildroot/output/build/libvips-7.42.2/libvips/resample$
/home/test/buildroot/output/host/usr/bin/sparc64-buildroot-linux-gnu-g++ -c -O0
 .libs/nohalo.c
test@build:~/buildroot/output/build/libvips-7.42.2/libvips/resample$
/home/test/buildroot/output/host/usr/bin/sparc64-buildroot-linux-gnu-g++ -c -O1
 .libs/nohalo.c
nohalo.cpp: In function 'void
vips_interpolate_nohalo_interpolate(VipsInterpolate*, void*, VipsRegion*,
double, double)':
nohalo.cpp:1571:1: error: unable to find a register to spill in class 'FP_REGS'
 }
 ^
nohalo.cpp:1571:1: error: this is the insn:
(insn 721 720 722 8 (set (reg:DF 32 %f0)
(float:DF (reg:SI 2281 [ MEM[base: p_139, index: _138, offset: 0B]+-3
]))) nohalo.cpp:1463 155 {floatsidf2}
 (expr_list:REG_DEAD (reg:SI 2281 [ MEM[base: p_139, index: _138, offset:
0B]+-3 ])
(nil)))
nohalo.cpp:1571: confused by earlier errors, bailing out
test@build:~/buildroot/output/build/libvips-7.42.2/libvips/resample$
/home/test/buildroot/output/host/usr/bin/sparc64-buildroot-linux-gnu-g++ -c -O2
 .libs/nohalo.c
nohalo.cpp: In function 'void
vips_interpolate_nohalo_interpolate(VipsInterpolate*, void*, VipsRegion*,
double, double)':
nohalo.cpp:1571:1: error: unable to find a register to spill in class 'FP_REGS'
 }
 ^
nohalo.cpp:1571:1: error: this is the insn:
(insn 837 773 775 8 (set (reg:DF 32 %f0)
(float:DF (reg:SI 2333 [ MEM[base: p_139, index: _5583, offset: 0B]+-3
]))) nohalo.cpp:1463 155 {floatsidf2}
 (expr_list:REG_DEAD (reg:SI 2333 [ MEM[base: p_139, index: _5583, offset:
0B]+-3 ])
(nil)))
nohalo.cpp:1571: confused by earlier errors, bailing out
test@build:~/buildroot/output/build/libvips-7.42.2/libvips/resample$
/home/test/buildroot/output/host/usr/bin/sparc64-buildroot-linux-gnu-g++ -c -Os
 .libs/nohalo.c
nohalo.cpp: In function 'void
vips_interpolate_nohalo_interpolate(VipsInterpolate*, void*, VipsRegion*,
double, double)':
nohalo.cpp:1571:1: error: unable to find a register to spill in class 'FP_REGS'
 }
 ^
nohalo.cpp:1571:1: error: this is the insn:
(insn 555 554 3791 8 (set (reg:DF 32 %f0)
(float:DF (reg:SI 1852 [ MEM[base: p_139, index: _138, offset: 0B]+-3
]))) nohalo.cpp:1463 155 {floatsidf2}
 (expr_list:REG_DEAD (reg:SI 1852 [ MEM[base: p_139, index: _138, offset:
0B]+-3 ])
(nil)))
nohalo.cpp:1571: confused by earlier errors, bailing out

In attachment, the pre-processed source file that allows to reproduce the
issue.

[Bug tree-optimization/69039] New: segfault with ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

Bug ID: 69039
   Summary: segfault with ftree-parallelize-loops=2
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Bootstrap with -ftree-parallelize-loops=2 by default (see PR68967) breaks here:
...
$ g++ ira-color.c -O2 -S -w -ftree-parallelize-loops=2
ira-color.c: In function void ira_color()�:
ira-color.c:113120:1: internal compiler error: Segmentation fault
 ira_color (void)
 ^

0xd6323f crash_signal
src/gcc/toplev.c:334
0xefe02b contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
src/gcc/tree.h:3110
0xefe02b may_propagate_copy(tree_node*, tree_node*)
src/gcc/tree-ssa-propagate.c:1396
0xda1200 gimple_merge_blocks
src/gcc/tree-cfg.c:1868
0x9056d5 merge_blocks(basic_block_def*, basic_block_def*)
src/gcc/cfghooks.c:774
0xdaa854 cleanup_tree_cfg_bb
src/gcc/tree-cfgcleanup.c:646
0xdab20c cleanup_tree_cfg_1
src/gcc/tree-cfgcleanup.c:712
0xdab20c cleanup_tree_cfg_noloop
src/gcc/tree-cfgcleanup.c:747
0xdab20c cleanup_tree_cfg()
src/gcc/tree-cfgcleanup.c:798
0xc1c1e1 execute_expand_omp
src/gcc/omp-low.c:13384
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
...

[Bug tree-optimization/69039] segfault with ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #1 from vries at gcc dot gnu.org ---
Created attachment 37124
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37124&action=edit
ira-color.c.tgz

[Bug c/69040] New: cris allmodconfig fails

[sudipm.mukherjee at gmail dot com]

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

Bug ID: 69040
   Summary: cris allmodconfig fails
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sudipm.mukherjee at gmail dot com
  Target Milestone: ---

Created attachment 37125
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37125&action=edit
the error output from gcc with -v

cris allmodconfig build fails with the error:

/home/sudip/linux-next/block/partitions/ldm.c: In function 'ldm_partition':
/home/sudip/linux-next/block/partitions/ldm.c:1567:1: internal compiler error:
in gen_reg_rtx, at emit-rtl.c:1027
 }
 ^
0x66ed1c gen_reg_rtx(machine_mode)
/opt/src/gcc/gcc/emit-rtl.c:1027
0x67ef7e copy_to_mode_reg(machine_mode, rtx_def*)
/opt/src/gcc/gcc/explow.c:610
0xaf787b gen_movdi(rtx_def*, rtx_def*)
/opt/src/gcc/gcc/config/cris/cris.md:503
0x6937f2 insn_gen_fn::operator()(rtx_def*, rtx_def*) const
/opt/src/gcc/gcc/recog.h:303
0x6937f2 emit_move_insn_1(rtx_def*, rtx_def*)
/opt/src/gcc/gcc/expr.c:3546
0x6971db gen_move_insn(rtx_def*, rtx_def*)
/opt/src/gcc/gcc/expr.c:3661
0x88258a gen_reload
/opt/src/gcc/gcc/reload1.c:8835
0x888516 emit_output_reload_insns
/opt/src/gcc/gcc/reload1.c:7859
0x888516 do_output_reload
/opt/src/gcc/gcc/reload1.c:8130
0x888516 emit_reload_insns
/opt/src/gcc/gcc/reload1.c:8198
0x888516 reload_as_needed
/opt/src/gcc/gcc/reload1.c:4708
0x88c2e7 reload(rtx_insn*, int)
/opt/src/gcc/gcc/reload1.c:1092
0x793455 do_reload
/opt/src/gcc/gcc/ira.c:5433
0x793455 execute
/opt/src/gcc/gcc/ira.c:5592

I am attaching the required files.

[Bug c/69040] cris allmodconfig fails

[sudipm.mukherjee at gmail dot com]

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

Sudip  changed:

   What|Removed |Added

 CC||sudipm.mukherjee at gmail dot 
com

--- Comment #1 from Sudip  ---
Created attachment 37126
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37126&action=edit
The processed file of ldm.c

The preprocessed .i file. Had to compress it as it was more than 1000kb and
could not be uploaded directly.

[Bug sanitizer/65112] [5 Regression] -fsanitized=thread Fortran program crashes at startup

[guillaume.sabouret at starqube dot com]

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

guillaume.sabouret at starqube dot com changed:

   What|Removed |Added

 CC||guillaume.sabouret@starqube
   ||.com

--- Comment #4 from guillaume.sabouret at starqube dot com ---
Oddly enough, I have the exact same problem in C++ (RHEL 6, gcc 5.2.0 compiled
from sources, using download_prerequisites for prerequisites and
--enable-languages=c,c++ --enable-lto as parameters to the configure script).

I have not been able to use TSAN since gcc 4.9.2. on our code base. It does
crash every time for even the simplest of programs (see below). I'd be curious
to know if somebody can reproduce it.

If I creste hello.cpp as
#include 
int main(){std::cout << "hello world!\n";return 0;}

and if I compile it as
g++-5.2.0 -fsanitize=thread hello.cpp

then running it gives a segmentation fault (stack looks a lot like the one
submitted here)

Program received signal SIGSEGV, Segmentation fault.
0x771a9824 in TraceAddEvent (addr=addr@entry=140737339075753,
typ=__tsan::EventTypeFuncEnter, fs=..., thr=thr@entry=0x76f2c880) at
../../../../gcc-5.2.0/libsanitizer/tsan/tsan_rtl.h:723
723   *evp = ev;
(gdb) bt
#0  0x771a9824 in TraceAddEvent (addr=addr@entry=140737339075753,
typ=__tsan::EventTypeFuncEnter, fs=..., thr=thr@entry=0x76f2c880) at
../../../../gcc-5.2.0/libsanitizer/tsan/tsan_rtl.h:723
#1  __tsan::FuncEntry (thr=thr@entry=0x76f2c880,
pc=pc@entry=140737339075753) at
../../../../gcc-5.2.0/libsanitizer/tsan/tsan_rtl.cc:913
#2  0x77161bf3 in ScopedInterceptor::ScopedInterceptor
(this=0x7fffdef0, thr=0x76f2c880, fname=,
pc=140737339075753) at
../../../../gcc-5.2.0/libsanitizer/tsan/tsan_interceptors.cc:191
#3  0x77175b52 in __interceptor___tls_get_addr (arg=0x771feb98) at
../../../../gcc-5.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:3871
#4  0x771a2ca9 in ScopedIgnoreInterceptors (this=)
at ../../../../gcc-5.2.0/libsanitizer/tsan/tsan_rtl.h:483
#5  __tsan::Initialize (thr=thr@entry=0x76f2c880) at
../../../../gcc-5.2.0/libsanitizer/tsan/tsan_rtl.cc:302
#6  0x77161be8 in ScopedInterceptor::ScopedInterceptor
(this=0x7fffdfd0, thr=0x76f2c880, fname=,
pc=140737337642886) at
../../../../gcc-5.2.0/libsanitizer/tsan/tsan_interceptors.cc:190
#7  0x771620ee in __interceptor___cxa_atexit (f=f@entry=0x77046570
,
arg=arg@entry=0x77135510 , 
dso=0x771351c0) at
../../../../gcc-5.2.0/libsanitizer/tsan/tsan_interceptors.cc:321
#8  0x77044f86 in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535) at
../../../../gcc-5.2.0/libstdc++-v3/src/c++11/compatibility-c++0x.cc:214
#9  _GLOBAL__sub_I_compatibility_c__0x.cc(void) () at
../../../../gcc-5.2.0/libstdc++-v3/src/c++11/compatibility-c++0x.cc:257
#10 0x00342f00e66f in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#11 0x00342f000b3a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#12 0x0001 in ?? ()
#13 0x7fffe37a in ?? ()
#14 0x in ?? ()

[Bug c/69037] arrays of constants as function arguments misinterpreted

[mikpelinux at gmail dot com]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #1 from Mikael Pettersson  ---
I can reproduce, regressed somewhere between r231665 (good) and r231919 (bad),
works on trunk.

[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target

[paul.hua.gm at gmail dot com]

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

--- Comment #10 from Paul Hua  ---
(In reply to Bernd Edlinger from comment #9)
> (In reply to Paul Hua from comment #8)
> > (In reply to Bernd Edlinger from comment #6)
> > > (In reply to Paul Hua from comment #5)
> > > > Created attachment 37115 [details]
> > > > building command
> > > 
> > > I'm unable to reproduce.
> > > What is your cross-compiler command line?
> > 
> 
> 
> and how exactly did you configure your cross compiler?

I'm compared the diff between your configure and mine, find something that my
configure specify the --with-build-time-tools=xxx. If don't specify the
--with-build-time-tools=xxx the gcc(both r225249 and r225260) can be build
successfully. This is the reason why you can't reproduce.

But, when specify the --with-build-time-tools=xxx the gcc r225249 can be build
successfully. The gcc r225260 failed, the error is same as above. 

The --with-build-time-tools=xxx is the binutils installed dir.

binutils cross-compiler configure with:

../../binutils-gdb_git_trunk/configure
--prefix=/home/xuchenghua/toolchain/cross-compiler/gcc-6.0.0
--build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=mipsel-redhat-linux-gnu

gcc cross-compiler configure with:

../../gcc_git_trunk/configure --prefix=/home/xuchenghua/gcc-trunk
--target=mipsel-redhat-linux --with-arch=mips64r2 --with-abi=32
--enable-threads=posix --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --disable-dssi --disable-multilib
--enable-languages=c --enable-shared
--with-build-time-tools=/home/xuchenghua/toolchain/cross-compiler/gcc-6.0.0/mipsel-redhat-linux-gnu/bin/

I'm sorry for wasted your time.

thanks.

[Bug target/69041] New: Unnecessary push/pop of caller-save register (ecx) on 32bit with vector intrinsics. Sometimes without the pop, clobbering ebp (callee-save)

[peter at cordes dot ca]

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

Bug ID: 69041
   Summary: Unnecessary push/pop of caller-save register (ecx) on
32bit with vector intrinsics.  Sometimes without the
pop, clobbering ebp (callee-save)
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Keywords: missed-optimization, wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: peter at cordes dot ca
  Target Milestone: ---
Target: i386-linux-gnu

gcc sometimes generates a totally unneeded push/pop of ecx in functions with
vector args.

One manifestation of this omitted the pop, leading to a clobber of the caller's
ebp.  IDK if that's possible for non-empty functions, so it might still just be
a performance bug in practice.

I've boiled this down to a tiny testcase:

#include 

__m256 add_pixdiff(__m256 c[2], __m256i a, __m256i b)
{
c[0] = _mm256_setzero_ps();
return c[0];
 }
void dummy(__m256 c[2], __m256i a, __m256i b) { }  // clobbers ebp!!
int dummy2(__m256 c[2], __m256i a, __m256i b) { return 0; }

Compile (on godbolt) with gcc 5.3 -x c -O2 -Wall -mavx2 -m32:
http://goo.gl/CkjU5y

Also reproduced with Ubuntu 15.10 5.2.1 20151010 (gcc /tmp/foo.c -O2 -m32
-mavx2 -S -o- makes near-identical code.)

add_pixdiff:
pushl   %ebp
vxorps  %xmm0, %xmm0, %xmm0
movl%esp, %ebp
pushl   %ecx
leal8(%ebp), %ecx   # other versions don't have this LEA
movl(%ecx), %eax
vmovaps %ymm0, (%eax)
popl%ecx
popl%ebp
ret
dummy:
pushl   %ebp
movl%esp, %ebp
pushl   %ecx
vzeroupper# why is this here?  we didn't do anything!
    AND NO MATCHING POP
leave   clobbers the caller's ebp with the pushed value of
ecx, but the esp=ebp part of leave cleans up after the mismatched push/pop
ret
dummy2:
pushl   %ebp
movl%esp, %ebp
pushl   %ecx
vzeroupper
xorl%eax, %eax
popl%ecx  # the return 0 version does pop ecx
popl%ebp
ret

When playing around with this, I saw some dependence on the order within the
file (http://goo.gl/wwH1r8):

#include 
__m256 dummy1(__m256 c[2], __m256i a, __m256i b) { }  
vxorps  %xmm0, %xmm0, %xmm0
ret

__m256 dummy2(__m256 c[2], __m256i a, __m256i b) { }
pushl   %ebp
movl%esp, %ebp
pushl   %ecx
popl%ecx
popl%ebp
ret


With more vector intrinsics inside the function (e.g. http://goo.gl/CWiQu9 semi
cut-down), you don't get a stack frame, but still a push/pop and lea. 
Obviously something is very wrong for 32bit targets.

[Bug c/69037] arrays of constants as function arguments misinterpreted

[mikpelinux at gmail dot com]

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

--- Comment #2 from Mikael Pettersson  ---
Started with r231722.

[Bug tree-optimization/69042] New: [6 regression] Missed optimization in ivopts

[ienkovich at gcc dot gnu.org]

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

Bug ID: 69042
   Summary: [6 regression] Missed optimization in ivopts
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ienkovich at gcc dot gnu.org
  Target Milestone: ---

Created attachment 37127
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37127&action=edit
Reproducer

Here is a reduced loop:

  for (i = 1; i < 64; i++) {
if (data[indexes[i]]) {
  j++;
} else {
  if (p (j))
return 0;
  j = 0;
}
  }

'i' is used for indexes access only.  Therefore it may be optimized out and
replaced with (indexes + i).  That's what GCC 5.3 actually does.  Here is a
GIMPLE for GCC 5.3 after ivopts:

  :
  # j_23 = PHI 
  # ivtmp.14_21 = PHI 
  _6 = (void *) ivtmp.14_21;
  _9 = MEM[base: _6, offset: 4B];
  _10 = (unsigned int) _9;
  _11 = _10 * 2;
  _13 = data_12(D) + _11;
  _14 = *_13;
  if (_14 != 0)
goto ;
  else
goto ;

  :
  j_15 = j_23 + 1;
  goto ;

  :
  _18 = p (j_23);
  if (_18 != 0)
goto ;
  else
goto ;

  :
  # j_2 = PHI 
  ivtmp.14_20 = ivtmp.14_21 + 4;
  if (ivtmp.14_20 != _1)
goto ;
  else
goto ;

  :
  goto ;

But GCC 6 doesn't do it starting from r230647 resulting in additional
address computation and increased registers pressure. Here is a GIMPLE
for GCC6 after ivopts:

  :
  # i_23 = PHI 
  # j_24 = PHI 
  _21 = (sizetype) i_23;
  _20 = _21 * 4;
  _9 = MEM[symbol: indexes, index: _20, offset: 0B];
  _10 = (unsigned int) _9;
  _11 = _10 * 2;
  _13 = data_12(D) + _11;
  _14 = *_13;
  if (_14 != 0)
goto ;
  else
goto ;

  :
  j_15 = j_24 + 1;
  goto ;

  :
  _18 = p (j_24);
  if (_18 != 0)
goto ;
  else
goto ;

  :
  # j_2 = PHI 
  i_16 = i_23 + 1;
  if (i_16 != 64)
goto ;
  else
goto ;

  :
  goto ;

Testcase was made on base of EEMBC cjpegv2 benchmarks whose loop
has a ~15% performance loss on Silvermont due to this issue.

In attached testcase I put __asm__ to emulate register pressure and
demonstrate resulting load in a regressed loop version for i386.

Here is how I build the test:

gcc -S -m32 -fPIE -pie -O2 test.c

Used compiler:

Target: x86_64-pc-linux-gnu
Configured with: /export/users/gnutester/stability/svn/trunk/configure
--with-arch=corei7 --with-cpu=corei7 --enable-clocale=gnu --with-system-zlib
--enable-shared --with-demangler-in-ld --enable-cloog-backend=isl
--with-fpmath=sse --with-pkgversion=Revision=231837
--prefix=/export/users/gnutester/stability/work/trunk/64/install
--enable-languages=c,c++,fortran,java,lto
Thread model: posix
gcc version 6.0.0 20151218 (experimental) (Revision=231837)

[Bug tree-optimization/69039] segfault with ftree-parallelize-loops=2

[miyuki at gcc dot gnu.org]

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

Mikhail Maltsev  changed:

   What|Removed |Added

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

--- Comment #2 from Mikhail Maltsev  ---
Reduced testcase:

$ cat ira-color.ii 
typedef unsigned long HARD_REG_SET[8];
int a;
HARD_REG_SET b;
bool c;
long d;
void fn1() {
  for (; a; a++) {
unsigned long *e = b;
e[0] |= d;
  }
  unsigned long *y = b;
  c = y[0];
}

$ cc1plus -O2 -ftree-parallelize-loops=2 ira-color.ii
ira-color.ii: In function 'void fn1()':
ira-color.ii:6:6: internal compiler error: Segmentation fault
 void fn1() {
  ^~~

0xcce74f crash_signal
/home/miyuki/gcc/src/gcc/toplev.c:334
0xe63c9b contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/miyuki/gcc/src/gcc/tree.h:3111
0xe63c9b may_propagate_copy(tree_node*, tree_node*)
/home/miyuki/gcc/src/gcc/tree-ssa-propagate.c:1396
0xd0ace9 gimple_merge_blocks
/home/miyuki/gcc/src/gcc/tree-cfg.c:1895
0x8f8eb5 merge_blocks(basic_block_def*, basic_block_def*)
/home/miyuki/gcc/src/gcc/cfghooks.c:774
0xd142b4 cleanup_tree_cfg_bb
/home/miyuki/gcc/src/gcc/tree-cfgcleanup.c:658
0xd14c56 cleanup_tree_cfg_1
/home/miyuki/gcc/src/gcc/tree-cfgcleanup.c:724
0xd14c56 cleanup_tree_cfg_noloop
/home/miyuki/gcc/src/gcc/tree-cfgcleanup.c:759
0xd14c56 cleanup_tree_cfg()
/home/miyuki/gcc/src/gcc/tree-cfgcleanup.c:810
0xbcb761 execute_expand_omp
/home/miyuki/gcc/src/gcc/omp-low.c:13384
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/69039] segfault with ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to Mikhail Maltsev from comment #2)
> Reduced testcase:
> 
> $ cat ira-color.ii 

Thanks.


Slightly further reduced:
...
unsigned int b;

unsigned int
fn1 (unsigned int d)
{
  int i;

  for (i = 0; i < 1000; i++)
b |= d;

  return b;
}
...

[Bug tree-optimization/65712] pthread_self prints wrong result when used with ucontext

[albertnetymk at gmail dot com]

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

--- Comment #2 from Albert Netymk  ---
@Andrew Pinski Could you provide the ref for const and pure attribute? It's not
mentioned in the
[spec](http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_self.html),
or the source code of
[glibc](https://github.com/lattera/glibc/blob/master/nptl/pthread_self.c)

[Bug fortran/69043] New: Trying to include a directory causes an infinite loop

[jim.macarthur at codethink dot co.uk]

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

Bug ID: 69043
   Summary: Trying to include a directory causes an infinite loop
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jim.macarthur at codethink dot co.uk
  Target Milestone: ---

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

Trying to include a directory, for example:

include '.'
include '/'

...causes the scanner to go into an infinite loop. Also reproduced on 4.8. I
have a fix for this which I'll send to the mailing list in due course.

Command line: gccinstall/bin/gfortran -Wall -Wextra
~/vanilla-gcc/gcc/gcc/testsuite/gfortran.dg/include_9.f

Output: None (goes into infinite loop immediately)

gfortran -v:
Using built-in specs.
COLLECT_GCC=gccinstall/bin/gfortran
COLLECT_LTO_WRAPPER=/home/jimmacarthur/vanilla-gcc/gccinstall/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure
--prefix=/home/jimmacarthur/vanilla-gcc/gccinstall --enable-languages=fortran :
(reconfigured) ../gcc/configure
--prefix=/home/jimmacarthur/vanilla-gcc/gccinstall --enable-languages=fortran :
(reconfigured) ../gcc/configure
--prefix=/home/jimmacarthur/vanilla-gcc/gccinstall --enable-languages=fortran
Thread model: posix
gcc version 6.0.0 20151224 (experimental) (GCC)

[Bug libstdc++/66338] std::forward_as_tuple() issue with single argument

[ville.voutilainen at gmail dot com]

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

--- Comment #7 from Ville Voutilainen  ---
Not so simple, still working on this.

[Bug ipa/69044] New: [6 regression] [CHKP] internal compiler error: in duplicate_thunk_for_node

[ienkovich at gcc dot gnu.org]

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

Bug ID: 69044
   Summary: [6 regression] [CHKP] internal compiler error: in
duplicate_thunk_for_node
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ienkovich at gcc dot gnu.org
  Target Milestone: ---

>cat test.i
int i;
int strncasecmp (char *p1, char *p2, long p3) { return 0; }
int special_command ()
{
  if (strncasecmp (0, 0, 0))
i++;
}
>gcc -O2 -fcheck-pointer-bounds -mmpx test.i
test.i:7:1: internal compiler error: in duplicate_thunk_for_node, at
cgraphclones.c:321
 }
 ^

0x8bd8e7 duplicate_thunk_for_node
/export/users/ienkovic/issues/mpx/gcc/gcc/cgraphclones.c:321
0x8bdb9a cgraph_edge::redirect_callee_duplicating_thunks(cgraph_node*)
/export/users/ienkovic/issues/mpx/gcc/gcc/cgraphclones.c:355
0x8be119 cgraph_node::create_clone(tree_node*, long, int, bool,
vec, bool, cgraph_node*, bitmap_head*)
/export/users/ienkovic/issues/mpx/gcc/gcc/cgraphclones.c:476
0x8be78c cgraph_node::create_virtual_clone(vec,
vec*, bitmap_head*, char const*)
/export/users/ienkovic/issues/mpx/gcc/gcc/cgraphclones.c:583
0x16aaece create_specialized_node
/export/users/ienkovic/issues/mpx/gcc/gcc/ipa-cp.c:3462
0x16ace05 decide_whether_version_node
/export/users/ienkovic/issues/mpx/gcc/gcc/ipa-cp.c:4381
0x16ad284 ipcp_decision_stage
/export/users/ienkovic/issues/mpx/gcc/gcc/ipa-cp.c:4493
0x16ad6aa ipcp_driver
/export/users/ienkovic/issues/mpx/gcc/gcc/ipa-cp.c:4607
0x16ad88a execute
/export/users/ienkovic/issues/mpx/gcc/gcc/ipa-cp.c:4697
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/69037] arrays of constants as function arguments misinterpreted

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |5.4

[Bug target/69040] cris allmodconfig fails

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Target||cris-linux-gnu
  Component|c   |target
   Severity|major   |normal

[Bug fortran/69011] [6 Regression] [OOP] ICE in gfc_advance_chain for ALLOCATE with SOURCE

[vehre at gcc dot gnu.org]

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

vehre at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |vehre at gcc dot gnu.org

--- Comment #8 from vehre at gcc dot gnu.org ---
Will take a lot as soon as possible.

[Bug target/69012] gcc-6.0.0 internal compiler error building libgfortran for mips64el target

[bernd.edlinger at hotmail dot de]

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

--- Comment #11 from Bernd Edlinger  ---
ok, now I see.  try this:

Index: gcc/config/mips/mips.c
===
--- gcc/config/mips/mips.c  (revision 231927)
+++ gcc/config/mips/mips.c  (working copy)
@@ -10347,8 +10347,6 @@ mips_compute_frame_info (void)
   memset (frame, 0, sizeof (*frame));
   size = get_frame_size ();

-  cfun->machine->global_pointer = mips_global_pointer ();
-
   /* The first two blocks contain the outgoing argument area and the $gp save
  slot.  This area isn't needed in leaf functions.  We can also skip it
  if we know that none of the called functions will use this space.
@@ -10377,6 +10375,17 @@ mips_compute_frame_info (void)
 }
   offset = frame->args_size + frame->cprestore_size;

+  /* MIPS16 code offsets the frame pointer by the size of the outgoing
+ arguments.  This tends to increase the chances of using unextended
+ instructions for local variables and incoming arguments.  */
+  if (TARGET_MIPS16)
+frame->hard_frame_pointer_offset = frame->args_size;
+
+  /* The function mips_global_pointer walks all insns and some depend
+ on the predicate function mips_cprestore_address_p, which uses
+ frame->args_size and frame->hard_frame_pointer_offset.  */
+  cfun->machine->global_pointer = mips_global_pointer ();
+
   /* Move above the local variables.  */
   frame->var_size = MIPS_STACK_ALIGN (size);
   offset += frame->var_size;
@@ -10520,12 +10529,6 @@ mips_compute_frame_info (void)
 frame->acc_save_offset = frame->acc_sp_offset - offset;
   if (frame->num_cop0_regs > 0)
 frame->cop0_save_offset = frame->cop0_sp_offset - offset;
-
-  /* MIPS16 code offsets the frame pointer by the size of the outgoing
- arguments.  This tends to increase the chances of using unextended
- instructions for local variables and incoming arguments.  */
-  if (TARGET_MIPS16)
-frame->hard_frame_pointer_offset = frame->args_size;
 }

 /* Return the style of GP load sequence that is being used for the

[Bug middle-end/69045] New: missing optimization: forward constant propagation of regular expressions

[shawn at churchofgit dot com]

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

Bug ID: 69045
   Summary: missing optimization: forward constant propagation of
regular expressions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shawn at churchofgit dot com
  Target Milestone: ---

C++11 regular expression support can be optimized with two levels of forward
constant propagationregexp compilation, and regexp execution on constant
strings. This would be a feature that could be useful in other languages as
well. Would require RE2 or TRE to linked.

[Bug libgomp/69046] New: gcc 6 libgomp trails clang 3.8 openmp in OpenMP 3.1 validation test

[howarth.at.gcc at gmail dot com]

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

Bug ID: 69046
   Summary: gcc 6 libgomp trails clang 3.8 openmp in OpenMP 3.1
validation test
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: howarth.at.gcc at gmail dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Current gcc trunk for 6.0svn trails Clang 3.8svn in the both the tests passed
and verified for '-fopenmp -O3' in the OpenMP3.1_Validation c test suite.

gcc 6.0svn

Summary:
S Number of tested Open MP constructs: 62
S Number of used tests:123
S Number of failed tests:  7
S Number of successful tests:  116
S + from this were verified:   95

Normal tests:
N Number of failed tests:  3
N + from this fail compilation:0
N + from this timed out0
N Number of successful tests:  59
N + from this were verified:   47

Orphaned tests:
O Number of failed tests:  4
O + from this fail compilation:0
O + from this timed out0
O Number of successful tests:  57
O + from this were verified:   48

clang 3.8svn (with https://llvm.org/bugs/show_bug.cgi?id=25820#c37 to solve PR
25820)

Summary:
S Number of tested Open MP constructs: 62
S Number of used tests:123
S Number of failed tests:  5
S Number of successful tests:  118
S + from this were verified:   112

Normal tests:
N Number of failed tests:  2
N + from this fail compilation:0
N + from this timed out0
N Number of successful tests:  60
N + from this were verified:   55

Orphaned tests:
O Number of failed tests:  3
O + from this fail compilation:0
O + from this timed out0
O Number of successful tests:  58
O + from this were verified:   57

On x86_64-apple-darwin15, I see two additional failures with gcc 6.0svn..

Testing for "omp_get_wtick":
Generating sources .. success
Compiling soures  success
Running test with 8 threads . failed 100% of the tests
+ orphaned mode:
Generating sources .. success
Compiling soures  success
Running test with 8 threads . failed 100% of the tests

and 17 less tests being verified compared to clang 3.8svn.

[Bug libgomp/69046] gcc 6 libgomp trails clang 3.8 openmp in OpenMP 3.1 validation test

[howarth.at.gcc at gmail dot com]

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

--- Comment #1 from Jack Howarth  ---
Created attachment 37129
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37129&action=edit
log of 'make ctest' using -fopenmp -O3 on x86_64-apple-darwin15

[Bug libgomp/69046] gcc 6 libgomp trails clang 3.8 openmp in OpenMP 3.1 validation test

[howarth.at.gcc at gmail dot com]

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

--- Comment #2 from Jack Howarth  ---
Created attachment 37130
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37130&action=edit
log of 'make ctest' using -fopenmp -O3 on x86_64-apple-darwin15

[Bug target/68772] Many -gstabs tests FAIL with Xcode 7 as

[mrs at gcc dot gnu.org]

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

--- Comment #5 from mrs at gcc dot gnu.org  ---
The work checked in above is unrelated to this PR.

[Bug libgomp/69046] gcc 6 libgomp trails clang 3.8 openmp in OpenMP 3.1 validation test

[howarth.at.gcc at gmail dot com]

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

--- Comment #3 from Jack Howarth  ---
The regressions in the OpenMP3.1_Validation c test suite verifications in gcc
6.0svn's results compared to clang 3.8svn's are...

--- clang-3.8-openmp-validation.log 2015-12-24 13:04:43.0 -0500
+++ gcc-6-openmp-validation.log 2015-12-24 13:04:12.0 -0500
@@ -15,11 +15,11 @@
 Testing for "omp_atomic":
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. and verified with 40%
certainty
 + orphaned mode:
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. and verified with 35%
certainty
 Testing for "omp_barrier":
 Generating sources .. success
 Compiling soures  success
@@ -31,19 +31,19 @@
 Testing for "omp_critical":
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. but might be lucky
 + orphaned mode:
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. but might be lucky
 Testing for "omp_flush":
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. but might be lucky
 + orphaned mode:
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. but might be lucky
 Testing for "omp_for_firstprivate":
 Generating sources .. success
 Compiling soures  success
@@ -59,7 +59,7 @@
 + orphaned mode:
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 90%
certainty
+Running test with 8 threads . success .. and verified with 100%
certainty
 Testing for "omp_for_ordered":
 Generating sources .. success
 Compiling soures  success
@@ -71,7 +71,7 @@
 Testing for "omp_for_private":
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 95%
certainty
+Running test with 8 threads . success .. and verified with 100%
certainty
 + orphaned mode:
 Generating sources .. success
 Compiling soures  success
@@ -127,11 +127,11 @@
 Testing for "omp_get_wtick":
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . failed 100% of the tests
 + orphaned mode:
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . failed 100% of the tests
 Testing for "omp_get_wtime":
 Generating sources .. success
 Compiling soures  success
@@ -151,11 +151,11 @@
 Testing for "omp_lock":
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. and verified with 40%
certainty
 + orphaned mode:
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. and verified with 40%
certainty
 Testing for "omp_master":
 Generating sources .. success
 Compiling soures  success
@@ -167,11 +167,11 @@
 Testing for "omp_nest_lock":
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. and verified with 30%
certainty
 + orphaned mode:
 Generating sources .. success
 Compiling soures  success
-Running test with 8 threads . success .. and verified with 100%
certainty
+Running test with 8 threads . success .. and verified with 40%
certainty
 Testing for "omp_parallel_copyin":
 Generating sources ..

[Bug tree-optimization/69039] [6 regression] segfault with ftree-parallelize-loops=2

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Target Milestone|--- |6.0
Summary|segfault with   |[6 regression] segfault
   |ftree-parallelize-loops=2   |with
   ||ftree-parallelize-loops=2

--- Comment #4 from vries at gcc dot gnu.org ---
Only fails with transform_to_exit_first_loop_alt. Marking as 6 regression.

[Bug rtl-optimization/69047] New: memcpy of 64-bit integer to 32-bit integer causes pointless stack operations on ARM

[x.fix at o2 dot pl]

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

Bug ID: 69047
   Summary: memcpy of 64-bit integer to 32-bit integer causes
pointless stack operations on ARM
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: x.fix at o2 dot pl
  Target Milestone: ---

Created attachment 37131
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37131&action=edit
d.c

When a function does memcpy to a local integer and returns it, pointless stack
operations are done (subtraction, and addition just after that).

Command line


arm-none-eabi-gcc -O3 -S -o- d.c

Output
==

Assembly code containing following function.

f:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 8
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
sub sp, sp, #8
add sp, sp, #8
@ sp needed
bx  lr
.size   f, .-f

Version information
===

Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-none-eabi/5.3.0/lto-wrapper
Target: arm-none-eabi
Configured with: /build/arm-none-eabi-gcc/src/gcc-5.3.0/configure
--target=arm-none-eabi --prefix=/usr --with-sysroot=/usr/arm-none-eabi
--with-native-system-header-dir=/include --libexecdir=/usr/lib
--enable-languages=c,c++ --enable-plugins --disable-decimal-float
--disable-libffi --disable-libgomp --disable-libmudflap --disable-libquadmath
--disable-libssp --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-threads --disable-tls --with-gnu-as --with-gnu-ld --with-system-zlib
--with-newlib --with-headers=/usr/arm-none-eabi/include
--with-python-dir=share/gcc-arm-none-eabi --with-gmp --with-mpfr --with-mpc
--with-isl --with-libelf --enable-gnu-indirect-function
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm'
--with-pkgversion='Arch Repository' --with-bugurl=https://bugs.archlinux.org/
--with-multilib-list=armv6-m,armv7-m,armv7e-m,armv7-r
Thread model: single
gcc version 5.3.0 (Arch Repository)

[Bug c/69037] [5 Regression] arrays of constants as function arguments misinterpreted

[mikpelinux at gmail dot com]

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

--- Comment #3 from Mikael Pettersson  ---
Trunk had the same regression, until r231374 fixed it.

[Bug target/66148] [6 regression] build/genpreds: Internal error: abort in choose_enum_order, at genpreds.c:1006

[glaubitz at physik dot fu-berlin.de]

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

John Paul Adrian Glaubitz  changed:

   What|Removed |Added

 CC||glaubitz at physik dot 
fu-berlin.d
   ||e

--- Comment #12 from John Paul Adrian Glaubitz  ---
Hi!

I am currently evaluating how gcc-6 is performing on the various Debian
architectures and it seems that alpha is affected by a suspicously similar
issue.

Full build log in here:

> https://buildd.debian.org/status/fetch.php?pkg=gcc-6&arch=alpha&ver=6-20151220-1&stamp=1450895752

Is the same problem or should I file a separate bug?

/«PKGBUILDDIR»/build/./prev-gcc/xg++ -B/«PKGBUILDDIR»/build/./prev-gcc/
-B/usr/alpha-linux-gnu/bin/ -nostdinc++
-B/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/src/.libs
-B/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/include/alpha-linux-gnu
 -I/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/include 
-I/«PKGBUILDDIR»/src/libstdc++-v3/libsupc++
-L/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/src/.libs
-L/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/libsupc++/.libs   -g
-O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror  
-DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc
-Wl,-z,relro -Wl,--no-relax -no-pie -o build/genpreds \
build/genpreds.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o
build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/hash-table.o
build/read-md.o build/errors.o .././libiberty/libiberty.a
/«PKGBUILDDIR»/build/./prev-gcc/xg++ -B/«PKGBUILDDIR»/build/./prev-gcc/
-B/usr/alpha-linux-gnu/bin/ -nostdinc++
-B/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/src/.libs
-B/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/include/alpha-linux-gnu
 -I/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/include 
-I/«PKGBUILDDIR»/src/libstdc++-v3/libsupc++
-L/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/src/.libs
-L/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/libsupc++/.libs   -g
-O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror  
-DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc
-Wl,-z,relro -Wl,--no-relax -no-pie -o build/genflags \
build/genflags.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o
build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/hash-table.o
build/read-md.o build/errors.o .././libiberty/libiberty.a
/«PKGBUILDDIR»/build/./prev-gcc/xg++ -B/«PKGBUILDDIR»/build/./prev-gcc/
-B/usr/alpha-linux-gnu/bin/ -nostdinc++
-B/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/src/.libs
-B/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/libsupc++/.libs 
-I/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/include/alpha-linux-gnu
 -I/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/include 
-I/«PKGBUILDDIR»/src/libstdc++-v3/libsupc++
-L/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/src/.libs
-L/«PKGBUILDDIR»/build/prev-alpha-linux-gnu/libstdc++-v3/libsupc++/.libs   -g
-O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror  
-DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc
-Wl,-z,relro -Wl,--no-relax -no-pie -o build/genconditions \
build/genconditions.o build/rtl.o build/read-rtl.o build/ggc-none.o
build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o
build/hash-table.o build/read-md.o build/errors.o .././libiberty/libiberty.a
build/genpreds -c ../../src/gcc/common.md ../../src/gcc/config/alpha/alpha.md >
tmp-constrs.h
build/genpreds: Internal error: abort in choose_enum_order, at genpreds.c:1016

[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info

[slyfox at inbox dot ru]

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

Sergei Trofimovich  changed:

   What|Removed |Added

 CC||slyfox at inbox dot ru

--- Comment #28 from Sergei Trofimovich  ---
(In reply to Eric Botcazou from comment #27)
> Thanks.  This seems to be a conjunction of several factors, the initial one
> being that the 4.8+ compiler generates (e.g for the reduced testcase at -O):
> 
> addl r14 = @ltoffx(_rtld_local#+15032385536), r1
> ;;
> ld8.mov r14 = [r14], _rtld_local#+15032385536
> 
> The huge number is not problematic per se, although it very likely runs
> afoul of some limitation/quirk here, since the value loaded from the GOT is
> truncated.
> 
> In fact it looks like the value loaded from the GOT is just the huge number,
> that is to say the value of _rtld_local has been zeroed during the
> relocation.
> 
> This may come from _rtld_local being in the .sdata section, in which case
> there is a relevant comment in sdata_symbolic_operand:
> 
>   /* Deny the stupid user trick of addressing outside the object.  Such
>things quickly result in GPREL22 relocation overflows.  Of course,
>they're also highly undefined.  From a pure pedant's point of view
>they deserve a slap on the wrist (such as provided by a relocation
>overflow), but that just leads to bugzilla noise.  */
> 
> In other words, the compiler skips the efficient @gprel relocation on
> purpose, only to generate the @ltoffx relocation, which doesn't work either
> here...

Hi Eric! I've poked this bug a bit more
and still don't understand what does this instruction mean:

ld8.mov r14 = [r14], _rtld_local#+15032385536

Where is '_rtld_local#+15032385536' offset expected to be used?

[Bug c/69037] [5 Regression] arrays of constants as function arguments misinterpreted

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-12-24
  Known to work||5.3.0
 Depends on||68668
 Ever confirmed|0   |1

--- Comment #4 from Andrew Pinski  ---
Confirmed then.  PR 68668 definitely looks like the correct fix too.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68668
[Bug 68668] [6 Regression] bogus error: invalid use of array with unspecified
bounds

[Bug tree-optimization/67842] Incorrect check in sese.h:bb_in_region

[hiraditya at msn dot com]

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

AK  changed:

   What|Removed |Added

 CC||hiraditya at msn dot com

--- Comment #1 from AK  ---
This check is irrelevant now. I'll put up a patch to remove this check.

[Bug c++/69048] New: [cilkplus] bug when spawning a function that returns a type with a destructor

[ryan.burn at gmail dot com]

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

Bug ID: 69048
   Summary: [cilkplus] bug when spawning a function that returns a
type with a destructor
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

The below code generates this ICE:

In function ‘’:
cc1plus: internal compiler error: in verify_gimple_stmt, at tree-cfg.c:4603
0xd2f403 verify_gimple_stmt
../../src-fix/gcc/tree-cfg.c:4603
0xd312b7 verify_gimple_in_seq_2
../../src-fix/gcc/tree-cfg.c:4718
0xd31238 verify_gimple_in_seq_2
../../src-fix/gcc/tree-cfg.c:4691
0xd31238 verify_gimple_in_seq_2
../../src-fix/gcc/tree-cfg.c:4691
0xd35ee1 verify_gimple_in_seq(gimple*)
../../src-fix/gcc/tree-cfg.c:4748
0xac3332 gimplify_body(tree_node*, bool)
../../src-fix/gcc/gimplify.c:11295
0xac36c6 gimplify_function_tree(tree_node*)
../../src-fix/gcc/gimplify.c:11383
0xd90df2 gimplify_all_functions
../../src-fix/gcc/tree-nested.c:3104
0xd90dd7 gimplify_all_functions
../../src-fix/gcc/tree-nested.c:3106
0xd991f6 lower_nested_functions(tree_node*)
../../src-fix/gcc/tree-nested.c:3123
0x944133 cgraph_node::analyze()
../../src-fix/gcc/cgraphunit.c:630
0x9478a9 analyze_functions
../../src-fix/gcc/cgraphunit.c:1079
0x9487b8 symbol_table::finalize_compilation_unit()
../../src-fix/gcc/cgraphunit.c:2519
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


/
struct A {  
  ~A() {}   
};  

A f() { 
  return {};
}   

int main() {
  _Cilk_spawn f();  
  return 0; 
}
/

[Bug c++/69005] [5/6 Regression] infinite(?) recursion in template instantiations

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Fri Dec 25 03:24:51 2015
New Revision: 231952

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

* call.c (add_template_candidate_real): Don't try to deduce X(X).

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/defaulted50.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/call.c

[Bug c++/69005] [5/6 Regression] infinite(?) recursion in template instantiations

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Not really a bug, but improved for 6.

[Bug c/69049] New: [avr] strange/unnecessary commands in compiled code

[night_ghost at ykoctpa dot ru]

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

Bug ID: 69049
   Summary: [avr] strange/unnecessary commands in compiled code
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: night_ghost at ykoctpa dot ru
  Target Milestone: ---

small code

void deepSleep(uint16_t milliseconds) {
uint32_t microseconds = milliseconds * 1000L;
uint16_t sleep_periods = (microseconds - watchdogTime_us) /
watchdogTime_us;

while (sleep_periods >= 512) {
  narcoleptic_sleep_down(WDTO_8S);
  sleep_periods -= 512;
}
if (sleep_periods & 256) narcoleptic_sleep_down(WDTO_4S); /* xxx */
}

compiled as (see comments)

void deepSleep(uint16_t milliseconds) {

uint32_t microseconds = milliseconds * 1000L;
2fb2:   9c 01   movwr18, r24
2fb4:   a8 ee   ldi r26, 0xE8   ; 232
2fb6:   b3 e0   ldi r27, 0x03   ; 3
2fb8:   0e 94 b8 33 call0x6770  ; 0x6770 <__umulhisi3>

uint16_t sleep_periods = (microseconds - watchdogTime_us) /
watchdogTime_us;
2fbc:   6c 19   sub r22, r12
2fbe:   7d 09   sbc r23, r13
2fc0:   8e 09   sbc r24, r14
2fc2:   9f 09   sbc r25, r15
2fc4:   a7 01   movwr20, r14
2fc6:   96 01   movwr18, r12
2fc8:   0e 94 71 33 call0x66e2  ; 0x66e2 <__udivmodsi4>
2fcc:   69 01   movwr12, r18 // r12r13 === sleep_periods,
is'nt it?

while (sleep_periods >= 512) {
//{ why GCC adds 0 before comparison?
2fce:   e1 2c   mov r14, r1
2fd0:   f1 2c   mov r15, r1
2fd2:   c7 01   movwr24, r14
2fd4:   8c 0d   add r24, r12
2fd6:   9d 1d   adc r25, r13
// carry NEVER can be set - r1===0
2fd8:   81 15   cp  r24, r1
//}
2fda:   92 40   sbcir25, 0x02   ; 2
2fdc:   70 f0   brcs.+28; 0x2ffa
<_Z9deepSleepj+0x6c>
  narcoleptic_sleep_down(WDTO_8S);
2fde:   89 e0   ldi r24, 0x09   ; 9
//{ why GCC saves unneeded LONG?
2fe0:   29 83   std Y+1, r18; 0x01
2fe2:   3a 83   std Y+2, r19; 0x02
2fe4:   4b 83   std Y+3, r20; 0x03
2fe6:   5c 83   std Y+4, r21; 0x04
//}
2fe8:   0e 94 c4 17 call0x2f88  ; 0x2f88
<_Z22narcoleptic_sleep_downh>
2fec:   62 e0   ldi r22, 0x02   ; 2
2fee:   f6 1a   sub r15, r22
//{ why GCC restores unneeded LONG?
2ff0:   5c 81   ldd r21, Y+4; 0x04
2ff2:   4b 81   ldd r20, Y+3; 0x03
2ff4:   3a 81   ldd r19, Y+2; 0x02
2ff6:   29 81   ldd r18, Y+1; 0x01
//}
2ff8:   ec cf   rjmp.-40; 0x2fd2
<_Z9deepSleepj+0x44>

//{ what the hell here? where such calculations in C code?
2ffa:   f9 01   movwr30, r18
2ffc:   ef 2f   mov r30, r31
2ffe:   ff 27   eor r31, r31
3000:   e6 95   lsr r30
3002:   60 e0   ldi r22, 0x00   ; 0
3004:   7e ef   ldi r23, 0xFE   ; 254
3006:   e6 9f   mul r30, r22
3008:   c0 01   movwr24, r0
300a:   e7 9f   mul r30, r23
300c:   90 0d   add r25, r0
300e:   f6 9f   mul r31, r22
3010:   90 0d   add r25, r0
3012:   11 24   eor r1, r1
3014:   82 0f   add r24, r18
3016:   93 1f   adc r25, r19
//}
  sleep_periods -= 512;
}

if (sleep_periods & 256) narcoleptic_sleep_down(WDTO_4S);
3018:   90 ff   sbrsr25, 0
301a:   0d c0   rjmp.+26; 0x3036
<_Z9deepSleepj+0xa8>
301c:   88 e0   ldi r24, 0x08   ; 8
}
//{ optimization on size but GCC generates 2nd epilogue to escape tail
recursion while simple CALL takes less memory
301e:   0f 90   pop r0
3020:   0f 90   pop r0
3022:   0f 90   pop r0
3024:   0f 90   pop r0
3026:   df 91   pop r29
3028:   cf 91   pop r28
302a:   ff 90   pop r15
302c:   ef 90   pop r14
302e:   df 90   pop r13
3030:   cf 90   pop r12
while (sleep_periods >= 512) {
  narcoleptic_sleep_down(WDTO_8S);
  sleep_periods -= 512;
}

if (sleep_periods & 256)

[Bug target/69049] [avr] strange/unnecessary commands in compiled code

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c   |target
   Severity|major   |normal

[Bug target/69041] Unnecessary push/pop of caller-save register (ecx) on 32bit with vector intrinsics. Sometimes without the pop, clobbering ebp (callee-save)

[peter at cordes dot ca]

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

Peter Cordes  changed:

   What|Removed |Added

 Target|i386-linux-gnu  |i386-linux-gnu,
   ||x86_64-linux-gnu

--- Comment #1 from Peter Cordes  ---
I noticed a similar (the same?) problem in 64bit mode: http://goo.gl/8B7O7T

typedef float __m512 __attribute__ ((vector_size (64)));

__m512 mul_broad(__m512 a, float b) {
asm(
//"vbroadcastss  %[scalar], %g[scalar]\n\t"
//"vmulps%g[scalar], %[vec], %[vec]\n\t"
  ""
: [vec] "+x" (a), [scalar] "+x" (b)
:
:
);
return a;
}


mul_broad(float __vector(16), float):
 push   %rbp
 mov%rsp,%rbp
 push   %r10
 pop%r10
 pop%rbp
 retq


An extremely similar function compiles fine:


__m512 mul_broad2(__m512 a, float b) {
__m512 tmpvec;
asm(
"vbroadcastss  %[scalar], %[tmpvec]\n\t"
"vmulps%[tmpvec], %[vec], %[vec]\n\t"
: [vec] "+x" (a), [tmpvec] "=x" (tmpvec)
: [scalar] "1" (b)
:
);

  return a;
}

mul_broad2(float __vector(16), float):
 vbroadcastss %xmm1,%zmm1
 vmulps %zmm1,%zmm0,%zmm0
 retq

[Bug other/69050] New: bsearch over unsorted array in unit_addrs_search

[tetra2005 at gmail dot com]

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

Bug ID: 69050
   Summary: bsearch over unsorted array in unit_addrs_search
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tetra2005 at gmail dot com
  Target Milestone: ---

Libbacktrace performs a bsearch with unit_addrs_search over address range
array. Prior to this list is qsorted with unit_addrs_compare. The algorithms in
these two functions are absolutely unrelated which in practice means that
address ranges are not sorted w.r.t. unit_addrs_search. In practice this may
cause latent bugs like inability to find an address range.

Note that this may be applicable to other bsearch calls although to now I've
only experienced errors for unit_addrs_search at runtime.