[Bug target/66509] the new clang-based assembler in Xcode 7 on 10.11 fails on the libjava/java/lang/reflect/natArray.cc file from FSF gcc 5.1 at -m32

[mrs at gcc dot gnu.org]

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

--- Comment #22 from mrs at gcc dot gnu.org  ---
Yes.  It cleanly applies to the 5 branch and the 4.9 branch.  Let me know how a
build and test cycle goes on both, and I propose to drop it into both.

[Bug tree-optimization/66733] [6 Regression] ICE at -Os and above on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-07-02
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0
Summary|ICE at -Os and above on |[6 Regression] ICE at -Os
   |x86_64-linux-gnu|and above on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Mine.  I've run into this issue (the CCP copy lattice not completely
propagated)
with some local changes.

[Bug target/66730] Optimizer seems to make incorrect assumptions about function alignment

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||x86_64-*-*
 Status|UNCONFIRMED |RESOLVED
  Component|c++ |target
  Known to work||4.9.2
 Resolution|--- |FIXED
  Known to fail||4.8.5

--- Comment #1 from Richard Biener  ---
Note that this seems to be fixed in GCC 4.9 and GCC 4.8 is no longer
maintained.

[Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-debug
 Target||ppc64le-*-*, x86_64-*-*
 CC||rsandifo at gcc dot gnu.org
Version|unknown |5.1.1
   Target Milestone|--- |5.2
Summary|CONST_WIDE_INT causes   |[5/6 Regression]
   |corrupted DWARF debug info  |CONST_WIDE_INT causes
   ||corrupted DWARF debug info

[Bug tree-optimization/66721] [6 regression] gcc.target/i386/pr61403.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-07-02
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Yes, this is know.  I thought we had a PR about this already but I can't find
it.

Mine.

[Bug tree-optimization/66720] gcc.dg/vect/pr48052.c FAILs

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
It misses at _least_

dg-require-effective-target vect_int_mult

(not sure if that also includes the required vect_int)

[Bug rtl-optimization/66626] [4.9/5/6 Regression] gcc.dg/torture/stackalign/non-local-goto-5.c segfaults w/ -mregparm=3

[ubizjak at gmail dot com]

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

--- Comment #14 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #8)
> (In reply to H.J. Lu from comment #7)
> > Created attachment 35882 [details]
> > A patch
> 
> Uhuh... it's correct. We want to limit regparm value with local_regparm.

Please note that for some reason this patch regressed gcc.target/i386/local.c
for 32bit targets.

[Bug tree-optimization/66719] gcc.dg/vect/bb-slp-32.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-07-02
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/bb-slp-32.c:10:11: note:
=== vect_slp_analyze_data_ref_dependences ===
/vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/vect/bb-slp-32.c:10:11: note:
not vectorized: unsupported unaligned load.*p_2(D)

so it doesn't consider vectorizing this, the XFAIL was removed with r222849:

-/* { dg-final { scan-tree-dump "vectorization is not profitable" "slp2" {
xfail  { vect_no_align && { ! vect_hw_misalign } } } } } */
+/* { dg-final { scan-tree-dump "vectorization is not profitable" "slp2" } } */

as fix for PR62283 where you reported the testcase now succeeding for
solaris-sparc (building the vector from scalars).

But then I have removed the alignment check in the SLP build machinery which
now no longer makes this path trigger.  So we again need the XFAIL.

[Bug tree-optimization/66719] gcc.dg/vect/bb-slp-32.c FAILs

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Thu Jul  2 08:38:42 2015
New Revision: 225303

URL: https://gcc.gnu.org/viewcvs?rev=225303&root=gcc&view=rev
Log:
2015-07-02  Richard Biener  

PR testsuite/66719
* gcc.dg/vect/bb-slp-32.c: Re-add XFAIL for targets not supporting
unaligned loads.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/vect/bb-slp-32.c

[Bug rtl-optimization/66626] [4.9/5/6 Regression] gcc.dg/torture/stackalign/non-local-goto-5.c segfaults w/ -mregparm=3

[ubizjak at gmail dot com]

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

--- Comment #15 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #14)
> > > Created attachment 35882 [details]
> > > A patch
> > 
> > Uhuh... it's correct. We want to limit regparm value with local_regparm.
> 
> Please note that for some reason this patch regressed
> gcc.target/i386/local.c for 32bit targets.

... which means that proposed patch is wrong. We want to *increase* regparm for
local functions as much as possible, even increasing specified regparm.

[Bug tree-optimization/66721] [6 regression] gcc.target/i386/pr61403.c FAILs

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #1)
> Yes, this is know.  I thought we had a PR about this already but I can't
> find it.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66510#c2

[Bug c++/66735] New: [C++14] lambda init-capture fails for const references

[fynjycfdby at gmail dot com]

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

Bug ID: 66735
   Summary: [C++14] lambda init-capture fails for const references
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fynjycfdby at gmail dot com
  Target Milestone: ---

This code fails to compile:

int main() {
int x = 0;
auto l = [&rx = static_cast(x)]() {};
}


The error message is:

test.cpp:3:14: error: binding 'const int' to reference of type 'int&' discards
qualifiers
 auto l = [&rx = static_cast(x)]() {


But according to [expr.prim.lambda]/11 rx should be captured as auto &rx =
static_cast(x), that is as const int&.

Tested on MacPorts g++-mp-5:

$ g++-mp-5 -v
Using built-in specs.
COLLECT_GCC=g++-mp-5
...
gcc version 5.1.0 (MacPorts gcc5 5.1.0_1)

[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[amker at gcc dot gnu.org]

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

--- Comment #2 from amker at gcc dot gnu.org ---
Hi,
I had a look of generated assembly.  The old code is as below:
.file   "20050830-1.c"
.machine power4
.section".toc","aw"
.section".text"
.section".toc","aw"
.LC0:
.quad   a
.section".text"
.align 2
.p2align 4,,15
.globl foo
.section".opd","aw"
.align 3
foo:
.quad   .L.foo,.TOC.@tocbase,0
.previous
.type   foo, @function
.L.foo:
cmpwi 7,3,511
ble 7,.L4
lis 9,0x
addis 8,2,.LC0@toc@ha   # gpr load fusion, type long
ld 8,.LC0@toc@l(8)
li 10,42
ori 9,9,0xff00
rldicl 9,9,0,32
add 9,3,9
cmpwi 7,9,256
addi 9,9,-256
rldicl 9,9,56,40
addi 9,9,1
mtctr 9
blt- 7,.L9
.p2align 5,,31
.L3:
sldi 9,3,2
addi 3,3,-256
extsw 3,3
stwx 10,8,9
bdnz .L3
.L4:
li 3,0
blr
.L9:
li 9,1
mtctr 9
b .L3
.long 0
.byte 0,0,0,0,0,0,0,0
.size   foo,.-.L.foo
.ident  "GCC: (GNU) 6.0.0 20150602 (experimental)"


And now it is as below
.file   "20050830-1.c"
.machine power4
.section".toc","aw"
.section".text"
.section".toc","aw"
.LC1:
.quad   a
.section".text"
.align 2
.p2align 4,,15
.globl foo
.section".opd","aw"
.align 3
foo:
.quad   .L.foo,.TOC.@tocbase,0
.previous
.type   foo, @function
.L.foo:
cmpwi 7,3,511
ble 7,.L4
addi 9,3,-512
addis 10,2,.LC1@toc@ha  # gpr load fusion, type long
ld 10,.LC1@toc@l(10)
rlwinm 9,9,0,0,23
subf 9,9,3
sldi 3,3,2
sldi 9,9,2
add 3,3,10
addi 9,9,-1024
add 9,9,10
li 10,42
.p2align 4,,15
.L3:
stw 10,0(3)
addi 3,3,-1024
cmpld 7,3,9
bne 7,.L3
.L4:
li 3,0
blr
.long 0
.byte 0,0,0,0,0,0,0,0
.size   foo,.-.L.foo
.ident  "GCC: (GNU) 6.0.0 20150627 (experimental)"

The difference is because IVOPT chooses arrary address IV and use it to
eliminate the old comparison.  That's why the bdn instruction isn't generated.

I am not good in ppc assembly code, but seems to me the code is improved since
there are one fewer instructions in loop now.

BTW, which instruction in old assembly's loop is the store instruction?

Thanks,
bin

[Bug c/66736] New: float rounding differences when using constant literal versus variable

[dhekir at gmail dot com]

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

Bug ID: 66736
   Summary: float rounding differences when using constant literal
versus variable
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dhekir at gmail dot com
  Target Milestone: ---

Calling function "log10f(3)" with a constant literal or via a variable, such as
"float f = 3; log10f(f)" gives different rounding results, which are incorrect
in the latter case.

Note that the bug is not about imprecision in the result, but inconsistency
between two statements which should be equivalent.

The difference only appears with no optimization flag or with -O0; activating
-O1 or greater makes the difference disappear.

It is especially annoying (although not forbidden) that the rounding
differences in this case do not respect usual order (i.e. changing the rounding
mode allows one to see that FE_DOWNWARD is larger than FE_TONEAREST in the
version using the variable).

This behavior has been observed in several GCCs, from 4.8.4 (Ubuntu) to 5.1.1
(Fedora), including a 5.0.0 compiled from trunk, and using different versions
of glibc (2.19, and also tried compiling 2.21). All of them produced the same
result.

Also, there are several constants for which this happen, but 3 would be one of
the most notable ones.

#include 
#include 

int main() {
  float r = log10f(3);
  printf("literal constant: %g (%a)\n", r, r);
  float x = 3;
  r = log10f(x);
  printf("with variable:%g (%a)\n", r, r);
  return 0;
}

[Bug c/66736] float rounding differences when using constant literal versus variable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
This means the math library implementation of log10f is not exact which isn't a
GCC bug.

[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[sch...@linux-m68k.org]

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

--- Comment #3 from Andreas Schwab  ---
stwx 10,8,9 -> *(int*)(r8+r9)=r10

[Bug testsuite/65944] [5/6 Regression] FAIL: g++.dg/lto/pr65276: undefined reference to std2::exception::~exception()

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #6 from Christophe Lyon  ---
Since this fix, I am observing this regression on arm* targets:
cp_lto_pr65276_1.o (symbol from plugin): In function `typeinfo for
std2::runtime_error':
(.text+0x0): multiple definition of `typeinfo name for std2::exception'
cp_lto_pr65276_0.o (symbol from plugin):(.text+0x0): first defined here
cp_lto_pr65276_1.o (symbol from plugin): In function `typeinfo for
std2::runtime_error':
(.text+0x0): multiple definition of `typeinfo for std2::exception'
cp_lto_pr65276_0.o (symbol from plugin):(.text+0x0): first defined here
collect2: error: ld returned 1 exit status

FAIL: g++.dg/lto/pr65276 cp_lto_pr65276_0.o-cp_lto_pr65276_1.o link, -flto -O0
-std=c++11

[Bug bootstrap/65988] Trying to compile GCC 5.1 in my (customized) Solaris 10/x86-64 fails with GMP errors

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org

--- Comment #6 from Manuel López-Ibáñez  ---
(In reply to Jesus Cea from comment #5)
> Could you possibly tell me how to do it and what the impact would be?

I think it should just work if you follow the instructions here:
https://gcc.gnu.org/wiki/InstallingGCC but using: GRAPHITE_LOOP_OPT=no

[Bug testsuite/65944] [5/6 Regression] FAIL: g++.dg/lto/pr65276: undefined reference to std2::exception::~exception()

[ubizjak at gmail dot com]

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

--- Comment #7 from Uroš Bizjak  ---
(In reply to Christophe Lyon from comment #6)
> Since this fix, I am observing this regression on arm* targets:

Please see

https://gcc.gnu.org/ml/gcc-patches/2015-06/msg01240.html

[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[amker at gcc dot gnu.org]

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

--- Comment #4 from amker at gcc dot gnu.org ---
(In reply to Andreas Schwab from comment #3)
> stwx 10,8,9 -> *(int*)(r8+r9)=r10

I am wondering how should we handle this failure.  Create a new doloop test and
change this one testing the optimization gcc does now?

Thanks,
bin

[Bug testsuite/66734] Many MPX tests are skipped

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
Since check_effective_target_mpx caches the result, if the first
MPX check fails, none of MPX tests will run.

[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[amker at gcc dot gnu.org]

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

--- Comment #5 from amker at gcc dot gnu.org ---
Hmm, (In reply to amker from comment #4)
> (In reply to Andreas Schwab from comment #3)
> > stwx 10,8,9 -> *(int*)(r8+r9)=r10
> 
> I am wondering how should we handle this failure.  Create a new doloop test
> and change this one testing the optimization gcc does now?
> 
> Thanks,
> bin

Hmm,
Actually, GCC shouldn't eliminate loop condition with address type candidate. 
Like on 32 bits powerpc, the loop can be further optimized with do-loop
structure:

foo:
cmpwi 7,3,511
ble- 7,.L4
addi 9,3,-256
lis 10,a@ha
cmpwi 7,9,256
addi 9,3,-512
srwi 9,9,8
la 10,a@l(10)
slwi 3,3,2
addi 9,9,1
add 3,3,10
mtctr 9
li 10,42
blt- 7,.L9
.L3:
stw 10,0(3)
addi 3,3,-1024
bdnz .L3
.L4:
li 3,0
blr
.L9:
li 9,1
mtctr 9
b .L3

Please correct me if I was wrong assuming same scenario on powerpc64 and
powerpc.

Thanks

[Bug driver/66737] New: ld: warning: -z bndplt ignored

[hjl.tools at gmail dot com]

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

Bug ID: 66737
   Summary: ld: warning: -z bndplt ignored
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: ienkovich at gcc dot gnu.org
  Target Milestone: ---

[hjl@gnu-6 gcc]$ cat x.c
int
main ()
{
  return 0;
}
[hjl@gnu-6 gcc]$ gcc -mmpx x.c -m32 -fcheck-pointer-bounds
/usr/local/bin/ld: warning: -z bndplt ignored.
[hjl@gnu-6 gcc]$ 

-z bndplt is only needed for x86-64 linker.

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #2 from vries at gcc dot gnu.org ---
Created attachment 35889
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35889&action=edit
Add testcase, no need to set --target_board=unix/-O2/-g

$ make -k -j5 check-target-libgomp RUNTESTFLAGS=c.exp=pr66714.c

...
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr66714.c
-DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 (internal compiler error)
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr66714.c
-DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 (test for excess errors)
UNRESOLVED: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr66714.c
-DACC_DEVICE_TYPE_host_nonshm=1 -DACC_MEM_SHARED=0 compilation failed to
produce executable
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr66714.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (internal compiler error)
FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr66714.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 (test for excess errors)
UNRESOLVED: libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr66714.c
-DACC_DEVICE_TYPE_host=1 -DACC_MEM_SHARED=1 compilation failed to produce
executable
...

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #3 from vries at gcc dot gnu.org ---
The cause of the SIGSEGV is that for loc fdata.5 in main._omp_fn.46
DECL_HAS_VALUE_EXPR_P (loc) is set, but DECL_VALUE_EXPR (loc) is NULL:
...
Program received signal SIGSEGV, Segmentation fault.
0x0092e8c9 in loc_list_from_tree (loc=0x0, want_address=0, context=0x0)
at /home/vries/gcc_versions/devel/gomp-4_0-branch/src/gcc/dwarf2out.c:1
1 switch (TREE_CODE (loc))
(gdb) up
#1  0x0092eeef in loc_list_from_tree (loc=0x75f03870,
want_address=0, context=0x0)
at /home/vries/gcc_versions/devel/gomp-4_0-branch/src/gcc/dwarf2out.c:14571
14571  want_address, context);
(gdb) l
14566   
14567   case PARM_DECL:
14568   case RESULT_DECL:
14569 if (DECL_HAS_VALUE_EXPR_P (loc))
14570   return loc_list_from_tree (DECL_VALUE_EXPR (loc),
14571  want_address, context);
14572 /* FALLTHRU */
14573   
14574   case FUNCTION_DECL:
14575 {
(gdb) call debug_generic_expr (loc)
fdata.5
(gdb) call current_function_name ()
$1 = 0x75efc190 "main._omp_fn.46"
...

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org ---
Created attachment 35890
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35890&action=edit
patch to detect problem earlier

Using this patch, we can trigger the problem earlier:
...
In file included from
src/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/pr66714.c:4:0:
src/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/atomic_capture-1.c:
In function ‘main._omp_fn.46’:
src/libgomp/testsuite/libgomp.oacc-c/../libgomp.oacc-c-c++-common/atomic_capture-1.c:853:9:
internal compiler error: in decl_value_expr_lookup, at tree.c:6773
0x11c902b decl_value_expr_lookup(tree_node*)
src/gcc/tree.c:6773
0xa43cae instantiate_expr
src/gcc/function.c:1851
0x11d914e walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set*))
src/gcc/tree.c:11132
0xa43e5f instantiate_decls_1
src/gcc/function.c:1874
0xa443d2 instantiate_decls
src/gcc/function.c:1922
0xa44874 instantiate_virtual_regs
src/gcc/function.c:1979
0xa448da execute
src/gcc/function.c:2015
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
...

The problem now also triggers without -g.

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #5 from vries at gcc dot gnu.org ---
Created attachment 35891
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35891&action=edit
Patch to make error more verbose

Using this patch, we get a more verbose error:
...
decl_value_expr_lookup could not find mapping for from 0x7fb78598a870 in
function main._omp_fn.46
from: fdata.5
...

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
Created attachment 35892
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35892&action=edit
patch to trace decl_value_expr_insert

Using this patch, we trace decl_value_expr_insert

[Bug c/66736] float rounding differences when using constant literal versus variable

[dhekir at gmail dot com]

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

--- Comment #2 from dhekir at gmail dot com ---
Isn't the library implementation of log10f used to compute the literal
constants generated in the assembly code? Would it then be a double precision
result that would be precomputed and rounded to single precision in this case?

Well, sorry for the noise, I compared the results with other compilers and,
even if the numerical results themselves were different, they were consistent
between precomputed constant literals and the underlying libc, therefore such
surprising situations do not arrive. I assumed that it was not intented in GCC
and so it would be useful to report it, but if it's not the same library
function used in both cases, that explains the issue.

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
Created attachment 35893
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35893&action=edit
Resulting trace.

The from that cannot be found:
...
decl_value_expr_lookup could not find mapping for from 0x7fb79849d870 in
function main._omp_fn.46
from: fdata.5
...

is indeed inserted at some point (though in a different function):
...
decl_value_expr_insert from 0x7fb79849d870 to 0x7fb798539cf8 in function main
from: fdata.5
to: *.omp_data_i->fdata.5
...

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #8 from vries at gcc dot gnu.org ---
Created attachment 35894
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35894&action=edit
patch to check overwrite

This patch checks whether hash element is accidentally overwritten by another.
The assert does not trigger.

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #9 from vries at gcc dot gnu.org ---
Created attachment 35895
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35895&action=edit
patch to trace garbage collection

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #10 from vries at gcc dot gnu.org ---
Created attachment 35896
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35896&action=edit
Updated trace

So the mapping we cannot find:
...
decl_value_expr_lookup could not find mapping for from 0x7fc0fe842870 in
function main._omp_fn.46
from: fdata.5
...

is set here:
...
decl_value_expr_insert from 0x7fc0fe842870 to 0x7fc0fe8decf8 in function main
from: fdata.5
to: *.omp_data_i->fdata.5
...

But then freed here:
...
Garbage collection freeing map entry with from 0x7fc0fe842870 and to
0x7fc0fe8decf8 in function main._omp_fn.25
...

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[alalaw01 at gcc dot gnu.org]

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

Bug 65946 Summary: Simple loop with if-statement not vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65946

   What|Removed |Added

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

[Bug middle-end/65946] Simple loop with if-statement not vectorized

[alalaw01 at gcc dot gnu.org]

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

alalaw01 at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Thu Jul 2 12:47:31 2015
New Revision: 225311

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

* tree-pass.h (make_pass_ch_vect): New.
* passes.def: Add pass_ch_vect just before pass_if_conversion.

* tree-ssa-loop-ch.c (ch_base, pass_ch_vect, pass_data_ch_vect,
pass_ch::process_loop_p, pass_ch_vect::process_loop_p,
make_pass_ch_vect): New.
(pass_ch): Extend ch_base.

(pass_ch::execute): Move all but loop_optimizer_init/finalize to...
(ch_base::copy_headers): ...here.

gcc/testsuite/:

* gcc.dg/vect/vect-strided-a-u16-i4.c (main1): Narrow scope of x,y,z,w.
* gcc.dg/vect/vect-ifcvt-11.c: New testcase.

[Bug rtl-optimization/66626] [4.9/5/6 Regression] gcc.dg/torture/stackalign/non-local-goto-5.c segfaults w/ -mregparm=3

[ubizjak at gmail dot com]

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

--- Comment #16 from Uroš Bizjak  ---
(In reply to H.J. Lu from comment #13)

> These simply won't work to together.  Since we must keep LRA, we
> should remove ix86_static_chain_on_stack.

... or LRA notes that static chain reg has just been loaded from stack (insn
32) and can be reused in all subsequent instructions (insn 14) and (insn 17).

[Bug rtl-optimization/66626] [4.9/5/6 Regression] gcc.dg/torture/stackalign/non-local-goto-5.c segfaults w/ -mregparm=3

[hjl.tools at gmail dot com]

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

--- Comment #17 from H.J. Lu  ---
non local goto, nested function and regparm == 3 are incompatible.  Is
that possible to detect non local goto is used inside ix86_function_regparm?

[Bug debug/66714] gomp4: libgomp.oacc-c-c++-common/atomic_capture-1.c -g ICE

[vries at gcc dot gnu.org]

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

--- Comment #11 from vries at gcc dot gnu.org ---
The test passes with:

/* { dg-additional-options "--param ggc-min-expand=10 --param
ggc-min-heapsize=10" } */

[Bug rtl-optimization/66626] [4.9/5/6 Regression] gcc.dg/torture/stackalign/non-local-goto-5.c segfaults w/ -mregparm=3

[ubizjak at gmail dot com]

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

--- Comment #18 from Uroš Bizjak  ---
(In reply to Uroš Bizjak from comment #16)
> (In reply to H.J. Lu from comment #13)
> 
> > These simply won't work to together.  Since we must keep LRA, we
> > should remove ix86_static_chain_on_stack.
> 
> ... or LRA notes that static chain reg has just been loaded from stack (insn
> 32) and can be reused in all subsequent instructions (insn 14) and (insn 17).

... or prevent fwprop to distribute static chain reg into its users and leave
it in a temporary.

[Bug c/66736] float rounding differences when using constant literal versus variable

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to dhekir from comment #2)
> Isn't the library implementation of log10f used to compute the literal
> constants generated in the assembly code? Would it then be a double
> precision result that would be precomputed and rounded to single precision
> in this case?

No, GCC uses the GMP / mpfr / mpc libraries to constant fold math functions.
The library implementation is for example not available when cross-compiling.

> Well, sorry for the noise, I compared the results with other compilers and,
> even if the numerical results themselves were different, they were
> consistent between precomputed constant literals and the underlying libc,
> therefore such surprising situations do not arrive. I assumed that it was
> not intented in GCC and so it would be useful to report it, but if it's not
> the same library function used in both cases, that explains the issue.

Yes, that explains it.  GCC produces exact results for constant folding.

Note that with other compilers you may fall into the trap of not executing
the library function in any case so I suggest to make the 'float r' variable
global and volatile.

[Bug tree-optimization/66738] New: [5/6 Regression] optimizer bug related to exceptions and static symbols

[doko at gcc dot gnu.org]

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

Bug ID: 66738
   Summary: [5/6 Regression] optimizer bug related to exceptions
and static symbols
   Product: gcc
   Version: 5.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at gcc dot gnu.org
  Target Milestone: ---

[forwarded from https://bugs.debian.org/788299]

seen with the gcc-5-branch 20150625 and trunk 20150610 (r224324)

$ g++-5 -g -O2 code.cpp && ./a.out 
Segmentation fault (core dumped)
$ g++-5 -g -O0 code.cpp && ./a.out 
terminate called after throwing an instance of 'MyException'
  what():  MyException: No!
Aborted (core dumped)
$ g++-4.9 -g -O2 code.cpp && ./a.out 
terminate called after throwing an instance of 'MyException'
  what():  MyException: No!
Aborted (core dumped)

$ cat code.cpp
#include 
#include 

class MyException : public std::exception
{
protected:
typedef std::exception Parent;

public:
MyException(const char* cStr): Parent(), m_reason(cStr) {
updateMessage();
}

virtual ~MyException() throw() {}

virtual const std::string& exceptionName() const {
return exceptionNameValue;
}

virtual const char* what() const throw() {
return m_exceptionMessage.c_str();
}

inline void updateMessage() {
m_exceptionMessage = exceptionName() + ": " + m_reason;
}

private:
std::string m_reason;
std::string m_exceptionMessage;
static const std::string exceptionNameValue;
};

const std::string MyException::exceptionNameValue("MyException");

int main() {
throw MyException("No!");
return 0;
}

[Bug tree-optimization/66739] New: [6 regression] FAIL: gcc.target/aarch64/subs.c scan-assembler subs\tw[0-9]

[sch...@linux-m68k.org]

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

Bug ID: 66739
   Summary: [6 regression] FAIL: gcc.target/aarch64/subs.c
scan-assembler subs\tw[0-9]
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*-*

$ gcc/xgcc -Bgcc/ ../gcc/testsuite/gcc.target/aarch64/subs.c -O2 -S -o subs.s
$ grep sub subs.s
.file   "subs.c"
sub w1, w0, w1
subsx1, x0, x1

[Bug tree-optimization/66739] [6 regression] FAIL: gcc.target/aarch64/subs.c scan-assembler subs\tw[0-9]

[sch...@linux-m68k.org]

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

--- Comment #1 from Andreas Schwab  ---
fd425e6293fb8306af74b3048352d97e1d67b922 is the first bad commit

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@225249
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug tree-optimization/66739] [6 regression] FAIL: gcc.target/aarch64/subs.c scan-assembler subs\tw[0-9]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-07-02
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
This is

  x = a - b;
  if (x != 0)

vs.

  if (a != b)

which we now more aggressively produce (the choice is not obvious and
we are missing the reverse transform).

The usual kind of action is to stick a single_use guard on the minus for

/* Transform comparisons of the form X - Y CMP 0 to X CMP Y.
   ??? The transformation is valid for the other operators if overflow
   is undefined for the type, but performing it here badly interacts
   with the transformation in fold_cond_expr_with_comparison which
   attempts to synthetize ABS_EXPR.  */
(for cmp (eq ne)
 (simplify
  (cmp (minus @0 @1) integer_zerop)
  (cmp @0 @1)))

but I really don't like that solution (it will cause SCCVN regressions).

value-numbering can also perform the reverse transform (though late
forwprop will kill that again).  I suppose we should look into
finding a more general solution for the forwprop issues from inside
forwprop.

[Bug c/66740] New: omp simd reduction miscompiles at -O3 with AVX (recent regression)

[tprince at computer dot org]

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

Bug ID: 66740
   Summary: omp simd reduction miscompiles at -O3 with AVX (recent
regression)
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tprince at computer dot org
  Target Milestone: ---

Created attachment 35897
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35897&action=edit
f2c include file

This regression is new in the last 2 weeks.
gcc -O3 -march=sandybridge -std=c99 -D__assume_aligned=  -fopenmp -c s115.c
is miscompiled (bad numerical results when run under test harness).
It is OK at -O2 or with -march=westmere, or with the omp directive disabled.
It doesn't vectorize without the omp directive.  It fails the same with
-march=haswell.
Similar versions using inner_product or Fortran dot_product are vectorizing
correctly without omp simd.

[Bug middle-end/66741] New: loops not fused nor vectorized

[aldot at gcc dot gnu.org]

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

Bug ID: 66741
   Summary: loops not fused nor vectorized
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aldot at gcc dot gnu.org
Blocks: 53947
  Target Milestone: ---

I would have hoped that the strcpy loop and &~0x20 loop would be fused,
perusing some masked store for the tolower.

$ cat > strcpy.c <
#include 
int main(void) {
char src[128], dest[128];
int n = read(0, &src, sizeof(src));
if (n < 1)
return 1;
src[n] = 0;
tolower_strcpy(dest, src);
write(2, dest, strlen(dest));
return 0;
}
#endif
EOF

gcc-5 -S strcpy.c -o strcpy.s -Ofast -fomit-frame-pointer
-minline-all-stringops -mstringop-strategy=unrolled_loop -mtune=ivybridge


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug c/66740] omp simd reduction miscompiles at -O3 with AVX (recent regression)

[tprince at computer dot org]

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

--- Comment #1 from tprince at computer dot org ---
Created attachment 35898
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35898&action=edit
C source

[Bug tree-optimization/66739] [6 regression] FAIL: gcc.target/aarch64/subs.c scan-assembler subs\tw[0-9]

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
This case is special in the sense that a - b on some targets already computes
a - b != 0 but we don't have any way to represent this on GIMPLE.  This
also only works when a - b is computed "close" to the comparison.

[Bug c/66740] omp simd reduction miscompiles at -O3 with AVX (recent regression)

[tprince at computer dot org]

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

--- Comment #2 from tprince at computer dot org ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc6.0/libexec/gcc/x86_64-unknown-cygwin/6.0.0/lt
o-wrapper.exe
Target: x86_64-unknown-cygwin
Configured with: ../configure --prefix=/usr/local/gcc6.0 --enable-languages='c
c
++ fortran' --enable-libgomp --enable-threads=posix --with-dwarf2
--without-libi
conv-prefix --without-libintl-prefix --with-system-zlib --disable-werror
--witho
ut-cloog --without-isl
Thread model: posix
gcc version 6.0.0 20150630 (experimental) (GCC)

[Bug c/66740] omp simd reduction miscompiles at -O3 with AVX (recent regression)

[tprince at computer dot org]

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

--- Comment #3 from tprince at computer dot org ---
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc6.0/libexec/gcc/x86_64-unknown-cygwin/6.0.0/lt
o-wrapper.exe
Target: x86_64-unknown-cygwin
Configured with: ../configure --prefix=/usr/local/gcc6.0 --enable-languages='c
c
++ fortran' --enable-libgomp --enable-threads=posix --with-dwarf2
--without-libi
conv-prefix --without-libintl-prefix --with-system-zlib --disable-werror
--witho
ut-cloog --without-isl
Thread model: posix
gcc version 6.0.0 20150630 (experimental) (GCC)

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-02
 CC||hubicka at gcc dot gnu.org,
   ||jamborm at gcc dot gnu.org
  Component|tree-optimization   |ipa
   Target Milestone|--- |5.2
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed (with the old libstdc++ ABI).  -O1 works.  We segfault in libgcc:

Program received signal SIGSEGV, Segmentation fault.
_Unwind_Resume (exc=exc@entry=0x0)
at /space/rguenther/tramp3d/trunk/libgcc/unwind.inc:229
229   if (exc->private_1 == 0)
(gdb) bt
#0  _Unwind_Resume (exc=exc@entry=0x0)
at /space/rguenther/tramp3d/trunk/libgcc/unwind.inc:229
#1  0x00400ad0 in main () at t.C:37

We optimize main to

Eh tree:
   1 cleanup
 3 cleanup land:{2,}

  :
  _3 = __cxa_allocate_exception (24);
  MEM[(struct MyException *)_3].D.12544._vptr.exception = &MEM[(void
*)&_ZTV11MyException + 16B];
  _7 = &MEM[(struct MyException *)_3].m_reason;
  std::basic_string::basic_string (_7, "No!", &D.13102);
;;succ:   3 [100.0%]  (FALLTHRU,EXECUTABLE)
;;4 (EH,EXECUTABLE)

  :
  D.13102 ={v} {CLOBBER};
  MEM[(struct _Alloc_hider *)_3 + 16B]._M_p = &MEM[(void
*)&_S_empty_rep_storage + 24B];
  __builtin_unreachable ();

:
  D.13102 ={v} {CLOBBER};
  _18 = &MEM[(struct MyException *)_3].D.12544;
  std::exception::~exception (_18);
  __builtin_eh_copy_values (1, 3);
  __cxa_free_exception (_3);
  _9 = __builtin_eh_pointer (1);
  __builtin_unwind_resume (_9);


but the std::string constructor doesn't throw and thus we run into the
__builtin_unreachable ().

t.C.068t.fixup_cfg4:  __builtin_unreachable ();

is where that appears.  It's from devirtualization:

ipa-prop: Discovered a virtual call to a known target (void
MyException::updateMessage()/143 -> void __builtin_unreachable()/264), for stmt
_8 = OBJ_TYPE_REF(_6;this_2(D)->3) (this_2(D));
t.C:25:37: note: converting indirect call in void MyException::updateMessage()
to direct call to void __builtin_unreachable()
Speculative indirect call void MyException::updateMessage()/143 => virtual
const string& MyException::exceptionName() const/265 has turned out to have
contradicting known target __builtin_unreachable

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

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
-fno-devirtualize fixes it.

[Bug c/66613] error in evaluationg cexp

[ka_bena at yahoo dot fr]

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

--- Comment #4 from BENAÏSSA  ---
Thank you for your mail.
Compile Flags:  -std=c99
-Warray-bounds
 -Wall
 -Wextra  
-Waddress
 -Wbad-function-cast
 -Wformat
 -Wformat-contains-nul
 -Wformat-extra-args
-Wformat-nonliteral
-Wformat-security
 -Wformat-zero-length
-Wmissing-format-attribute
 -Woverlength-strings
 -foptional-diags
-Woverlength-strings
 -malign-stringops-malign-stringops-lm-llquadmath
I work with windowsXP on Compaq 6720S.
I use gcc provided by gfortran.I hope that those informations can be useful.   
   Thank you A.BENAISSA.



 Le Lundi 22 juin 2015 11h50, rguenth at gcc dot gnu.org
 a écrit :


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

Richard Biener  changed:

          What    |Removed                    |Added

            Status|UNCONFIRMED                |WAITING
  Last reconfirmed|                            |2015-06-22
    Ever confirmed|0                          |1

--- Comment #3 from Richard Biener  ---
The issue could also be in gmp/mpfr/mpc or in the C library.

How did you compile (with what flags) anyway?

[Bug middle-end/66741] loops not fused nor vectorized

[aldot at gcc dot gnu.org]

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

--- Comment #1 from Bernhard Reutner-Fischer  ---
i.e. maybe something more along the lines of

$ cat <
#include 
#include 

void
sse_tolower_strcpy (const char *d, const char *s)
{

  __m128i ranges =
_mm_setr_epi8 ('A', 'Z', 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);

  __m128i *src = (__m128i *) s;
  __m128i *dst = (__m128i *) d;
  const __m128i diff = _mm_set1_epi8 (0x20);

  const uint8_t mode = _SIDD_UBYTE_OPS | _SIDD_CMP_RANGES | _SIDD_UNIT_MASK;

  for (;; src++, dst++)
{

  const __m128i chunk = _mm_loadu_si128 (src);
  if (_mm_cmpistrc (ranges, chunk, mode))
{

  const __m128i tmp1 = _mm_cmpistrm (ranges, chunk, mode);
  const __m128i mask = _mm_and_si128 (tmp1, diff);

  _mm_storeu_si128 (dst, _mm_xor_si128 (chunk, mask));
}

  if (_mm_cmpistrz (ranges, chunk, mode))
break;
}
}

#ifdef MAIN
#include 
#include 
int main(void) {
char src[128], dest[128];
int n = read(0, &src, sizeof(src));
if (n < 1)
 1;
src[n] = 0;
sse_tolower_strcpy(dest, src);
write(2, dest, strlen(dest));
return 0;
}
#endif
EOF

.file   ""
.section.text.unlikely,"ax",@progbits
.LCOLDB2:
.text
.LHOTB2:
.p2align 4,,15
.globl  sse_tolower_strcpy
.type   sse_tolower_strcpy, @function
sse_tolower_strcpy:
.LFB641:
.cfi_startproc
movdqa  .LC0(%rip), %xmm2
movdqa  .LC1(%rip), %xmm3
jmp .L4
.p2align 4,,10
.p2align 3
.L2:
pcmpistrm   $68, %xmm1, %xmm2
je  .L1
.L9:
addq$16, %rsi
addq$16, %rdi
.L4:
movdqu  (%rsi), %xmm1
pcmpistrm   $68, %xmm1, %xmm2
jnc .L2
pand%xmm3, %xmm0
pxor%xmm1, %xmm0
movups  %xmm0, (%rdi)
pcmpistrm   $68, %xmm1, %xmm2
jne .L9
.L1:
rep ret
.cfi_endproc
.LFE641:
.size   sse_tolower_strcpy, .-sse_tolower_strcpy
.section.text.unlikely
.LCOLDE2:
.text
.LHOTE2:
.section.rodata.cst16,"aM",@progbits,16
.align 16
.LC0:
.byte   65
.byte   90
.byte   0
.byte   0
.byte   0
.byte   0
.byte   0
.byte   0
.byte   0
.byte   0
.byte   0
.byte   0
.byte   0
.byte   0
.byte   0
.byte   0
.align 16
.LC1:
.quad   2314885530818453536
.quad   2314885530818453536
.ident  "GCC: (Debian 5.1.1-12) 5.1.1 20150622"
.section.note.GNU-stack,"",@progbits


This would be *much* smaller and supposedly is also faster:
   textdata bss dec hex filename
228   0   0 228  e4 comment0.o
153   0   0 153  99 comment1.o

[Bug c/66613] error in evaluationg cexp

[ka_bena at yahoo dot fr]

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

--- Comment #5 from BENAÏSSA  ---
Thank you for your mail.I do not know where is the error but after execution I
do not have the good result. anyway!
Compile Flags:

  -std=c99
-Warray-bounds
 -Wall
 -Wextra 

-Waddress
 -Wbad-function-cast
 -Wformat
 -Wformat-contains-nul
 -Wformat-extra-args
-Wformat-nonliteral
-Wformat-security
 -Wformat-zero-length
-Wmissing-format-attribute
 -Woverlength-strings
 -foptional-diags
-Woverlength-strings
 -malign-stringops

-malign-stringops

-lm

-llquadmath

I work with windowsXP on Compaq 6720S.

I use gcc provided by gfortran.

I hope that those informations can be useful.
 thank you A.BENAISSA 



 Le Dimanche 21 juin 2015 12h37, "michael.l...@uni-ulm.de"
 a écrit :


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

Michael Lehn  changed:

          What    |Removed                    |Added

                CC|                            |michael.l...@uni-ulm.de

--- Comment #1 from Michael Lehn  ---
> //> Terminated with exit code 0.

So were is the error?

[Bug middle-end/66741] loops not fused nor vectorized

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-02
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Loop fusion is not implemented also strcpy is expanded inline too late (during
RTL expansion) and thus the two loops are exposed too late for the place where
it would be implemented.

Same reason for not vectorizing __builtin_tolower - it's expanded too late.

[Bug middle-end/66741] loops not fused nor vectorized

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
I don't see where we inline-expand __builtin_tolower at all.

[Bug tree-optimization/66740] [6 Regression] omp simd reduction miscompiles at -O3 with AVX (recent regression)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||x86_64-*-*
  Component|c   |tree-optimization
   Target Milestone|--- |6.0
Summary|omp simd reduction  |[6 Regression] omp simd
   |miscompiles at -O3 with AVX |reduction miscompiles at
   |(recent regression) |-O3 with AVX (recent
   ||regression)

[Bug libstdc++/66742] New: abort on sorting list with custom compiler that is not stateless

[mdiluzio at feralinteractive dot com]

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

Bug ID: 66742
   Summary: abort on sorting list with custom compiler that is not
stateless
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mdiluzio at feralinteractive dot com
  Target Milestone: ---

Created attachment 35899
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35899&action=edit
main.ii

When using a custom defined allocator that contains state, sorting a list will
cause an abort.

This seems to be due to the __carry list in sort having a null allocator, that
then gets compared to the main list's allocator within splice in
_M_check_equal_allocators.

GCC information:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.9/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.9.2-10ubuntu13' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-vtable-verify
--enable-plugin --with-system-zlib --disable-browser-plugin
--enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++11' '-g'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.9/cc1plus -E -quiet -v -imultiarch
x86_64-linux-gnu -D_GNU_SOURCE main.cpp -mtune=generic -march=x86-64 -std=c++11
-Wall -Wextra -g -fworking-directory -fpch-preprocess -fstack-protector-strong
-Wformat-security -o main.ii
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/4.9"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.9
 /usr/include/x86_64-linux-gnu/c++/4.9
 /usr/include/c++/4.9/backward
 /usr/lib/gcc/x86_64-linux-gnu/4.9/include
 /usr/local/include
 /usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed
 /usr/include/x86_64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++11' '-g'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-linux-gnu/4.9/cc1plus -fpreprocessed main.ii -quiet
-dumpbase main.cpp -mtune=generic -march=x86-64 -auxbase main -g -Wall -Wextra
-std=c++11 -version -fstack-protector-strong -Wformat-security -o main.s
GNU C++ (Ubuntu 4.9.2-10ubuntu13) version 4.9.2 (x86_64-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version
3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Ubuntu 4.9.2-10ubuntu13) version 4.9.2 (x86_64-linux-gnu)
compiled by GNU C version 4.9.2, GMP version 6.0.0, MPFR version
3.1.2-p11, MPC version 1.0.3
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d311308152d93b993d290cf64f65ff6f
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++11' '-g'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 as -v --64 -o main.o main.s
GNU assembler version 2.25 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Ubuntu) 2.25
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/4.9/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-Wall' '-Wextra' '-std=c++11' '-g'
'-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-li

[Bug c++/61649] fixincludes update for solaris___restrict in sys/feature_tests.h on Illumos

[richard at netbsd dot org]

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

--- Comment #5 from Richard PALO  ---
kind reminder to push these two patches:
1) https://gcc.gnu.org/bugzilla/attachment.cgi?id=33031
2) and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61649#c1 (*)
* NB https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52168

I believe I already answered Jonathan's question in that since
only a [preceeding] line of context is being added, there is no
additional '#endif' to add.

BTW, this line of context is necessary anyway, because if either
Oracle Solaris or Illumos change this code section, for example by 
fixing it as gcc currently does here, it will prevent fixincl.x from
action which would actually *break* the file.

[Bug tree-optimization/37239] peeling last iteration of a <= loop

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||26163
  Known to fail||

--- Comment #4 from Andrew Pinski  ---
There is another case where this optimization can come into handy and shows up
in SPEC 2006.:

for (i = 1; i <= N; i++)
{
  ...
  if (i < N)
  {
...
  }
}

This is inside hammer's inner most loop.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k and 2k6 and 95)

[Bug tree-optimization/66119] [5/6 Regression] in optimization of avx-code

[jgreenhalgh at gcc dot gnu.org]

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

--- Comment #11 from James Greenhalgh  ---
There is a patch for this on the Mailing List. Jeff has approved the
code-changes and I need an Ack for the test-case (ping:
https://gcc.gnu.org/ml/gcc-patches/2015-06/msg02216.html ).

After that I'll backport it to GCC 5.1.1. Hopefully in time to not block the
release.

[Bug rtl-optimization/66706] Redundant bitmask instruction on x >> (n & 32)

[segher at gcc dot gnu.org]

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

--- Comment #2 from Segher Boessenkool  ---
Author: segher
Date: Thu Jul  2 16:27:11 2015
New Revision: 225344

URL: https://gcc.gnu.org/viewcvs?rev=225344&root=gcc&view=rev
Log:
PR rtl-optimization/66706
* combine.c (make_compound_operation): If an AND of SUBREG of
LSHIFTRT does not simplify, see if just the AND of SUBREG does.

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

[Bug rtl-optimization/66706] Redundant bitmask instruction on x >> (n & 32)

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #3 from Segher Boessenkool  ---
Fixed on trunk.

[Bug target/59767] __atomic_load_n with __ATOMIC_SEQ_CST should result in a memory barrier

[jamrial at gmail dot com]

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

James Almer  changed:

   What|Removed |Added

 CC||jamrial at gmail dot com

--- Comment #1 from James Almer  ---
This still happens with gcc 4.9 and gcc 5.

int foo(int *bar)
{
return *bar;
}

and

int foo(int *bar)
{
return __atomic_load_n(bar, __ATOMIC_SEQ_CST);
}

Generate the exact same assembly. The latter should add an mfence before the
mov instruction.

[Bug fortran/66545] ICE on using undefined parameter/variable values

[kargl at gcc dot gnu.org]

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

--- Comment #8 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Jul  2 17:02:10 2015
New Revision: 225348

URL: https://gcc.gnu.org/viewcvs?rev=225348&root=gcc&view=rev
Log:
2015-07-02  Steven G. Kargl   

PR fortran/66545
* primary.c (match_sym_complex_part): Do not dereference NULL pointer.

2015-07-02  Steven G. Kargl   

PR fortran/66545
* gfortran.dg/pr66545_1.f90: New test.
* gfortran.dg/pr66545_2.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr66545_1.f90
trunk/gcc/testsuite/gfortran.dg/pr66545_2.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/primary.c
trunk/gcc/testsuite/ChangeLog

[Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-07-02
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
(In reply to Ulrich Weigand from comment #1)
> A bit of debugging shows that what's going on here is this:
> 
> add_const_value_attribute is called with the following constant RTL:
> (const_wide_int 0x8000)
>
> The routine then does:
>  add_AT_wide (die, DW_AT_const_value,
>   std::make_pair (rtl, GET_MODE (rtl)));
> 
> Note that GET_MODE (rtl) is VOIDmode.  This apparently causes creation of a
> wide_int value with precision 0:
> { = {val = {0, -9223372036854775808, 2}, len = 2,
> precision = 0}
> 
> This seems already wrong, but doesn't quite explain the inconsistent output.

Yeah, wide_ints shouldn't have precision 0.  I think the later problems
do follow from that, although like you say there is probably a disconnect
between the way the DIEs are handled as well.

[Bug fortran/56520] Syntax error causes misleading message: "Invalid character in name"

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Thu Jul  2 17:29:04 2015
New Revision: 225349

URL: https://gcc.gnu.org/viewcvs?rev=225349&root=gcc&view=rev
Log:
2015-07-02  Steven G. Kargl  

PR fortran/56520
* match.c (gfc_match_name): Special case unary minus and plus.

2015-07-02  Steven G. Kargl  

PR fortran/56520
* gfortran.dg/pr56520.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr56520.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/66743] New: ICE on formerly working code

[webrown.cpp at gmail dot com]

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

Bug ID: 66743
   Summary: ICE on formerly working code
   Product: gcc
   Version: c++-concepts
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: webrown.cpp at gmail dot com
  Target Milestone: ---

This appears to be a recently introduced regression.  Although I'm using the
concepts branch, no concepts features are used to reproduce the problem.


Reduced test case:

template< class T >
struct
  type_is { using type = T; };

template< class T >
  using underlying_type = type_is<__underlying_type(T)>;

int
  main( )
{
  return 0;
}


Compiler version:
concepts-g++ (GCC) 6.0.0 20150702 (experimental)


Command line (numerous -W options elided):
concepts-g++ -Og -std=c++1z ... 


Diagnostic:

internal compiler error: tree check: expected record_type or union_type or
qual_union_type, have underlying_type in for_each_template_parm_r, at
cp/pt.c:8726

[Bug c++/66743] ICE on formerly working code

[webrown.cpp at gmail dot com]

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

--- Comment #1 from W E Brown  ---
Further reduced test case:

template< class T >
  using u_t = __underlying_type(T);

int  main( )  { }

[Bug debug/66728] [5/6 Regression] CONST_WIDE_INT causes corrupted DWARF debug info

[rsandifo at gcc dot gnu.org]

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

--- Comment #4 from rsandifo at gcc dot gnu.org  
---
Testing a patch.  It involves tightening the mode of the rtx returned
by rtl_for_decl_location, as well as new asserts, so some fallout is
likely...

[Bug preprocessor/53690] [C++11] \u0000 and \U00000000 are wrongly encoded as U+0001.

[paolo at gcc dot gnu.org]

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

--- Comment #10 from paolo at gcc dot gnu.org  ---
Author: paolo
Date: Thu Jul  2 18:54:41 2015
New Revision: 225353

URL: https://gcc.gnu.org/viewcvs?rev=225353&root=gcc&view=rev
Log:
/libcpp
2015-07-02  Paolo Carlini  

PR c++/53690
* charset.c (_cpp_valid_ucn): Add cppchar_t * parameter and change
return type to bool.  Fix encoding of \u and \U in C++.
(convert_ucn): Adjust call.
* lex.c (forms_identifier_p): Likewise.
* internal.h (_cpp_valid_ucn): Adjust declaration.

/gcc/testsuite
2015-07-02  Paolo Carlini  

PR c++/53690
* g++.dg/cpp/pr53690.C: New.

Added:
trunk/gcc/testsuite/g++.dg/cpp/pr53690.C
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libcpp/ChangeLog
trunk/libcpp/charset.c
trunk/libcpp/internal.h
trunk/libcpp/lex.c

[Bug preprocessor/53690] [C++11] \u0000 and \U00000000 are wrongly encoded as U+0001.

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.0

--- Comment #11 from Paolo Carlini  ---
Fixed.

[Bug tree-optimization/66729] Segfault starting with r224967

[meissner at gcc dot gnu.org]

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

Michael Meissner  changed:

   What|Removed |Added

 CC||meissner at gcc dot gnu.org

--- Comment #5 from Michael Meissner  ---
FWIW, I bootstrapped the compiler on the same system Pat is using internally,
and it worked (using the various configuration hacks I've developed over the
years).

[Bug c++/66743] [5/6 regression] ICE: tree check: expected record_type or union_type or qual_union_type, have underlying_type in for_each_template_parm_r, at cp/pt.c:8234

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-02
 CC||jason at gcc dot gnu.org,
   ||trippels at gcc dot gnu.org
  Known to work||4.9.3
Version|c++-concepts|6.0
Summary|ICE on formerly working |[5/6 regression] ICE: tree
   |code|check: expected record_type
   ||or union_type or
   ||qual_union_type, have
   ||underlying_type in
   ||for_each_template_parm_r,
   ||at cp/pt.c:8234
 Ever confirmed|0   |1
  Known to fail||5.0, 6.0

--- Comment #2 from Markus Trippelsdorf  ---
Started with r224331.

[Bug libstdc++/66742] abort on sorting list with custom compiler that is not stateless

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
Your definition of operator!= for the allocator test_alloc violates the
allocator requirements, which impose that != behaves the same as the negation
of == (see Table 28 — Allocator requirements, [allocator.requirements]). This
violates causes undefined behaviour. Therefore it seems to me as if this is an
invalid bug report.

[Bug fortran/66725] Issue with silent conversion int to char, ICE if int too large

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

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

--- Comment #2 from Gerhard Steinmetz  
---
A more extensive list of different cases :

   close (1, status=257)
   open (1, access=257)
   open (1, action=257)
   open (1, asynchronous=257)
   open (1, blank=257)
   open (1, delim=257)
   open (1, decimal=257)
   open (1, encoding=257)
   open (1, form=257)
   open (1, pad=257)
   open (1, position=257)
   open (1, round=257)
   open (1, sign=257)
   open (1, status=257)
   read (1, asynchronous=257)
   read (1, blank=257)
   read (1, delim=257)
   read (1, decimal=257)
   read (1, pad=257)
   read (1, round=257)
   read (1, sign=257)
   write (1, asynchronous=257)
   write (1, blank=257)
   write (1, delim=257)
   write (1, decimal=257)
   write (1, pad=257)
   write (1, round=257)
   write (1, sign=257)

[Bug bootstrap/66744] New: Bootstrap failure due to conflicting access() on i686-w64-mingw32

[MatthewS.Grochowalski at ge dot com]

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

Bug ID: 66744
   Summary: Bootstrap failure due to conflicting access() on
i686-w64-mingw32
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: MatthewS.Grochowalski at ge dot com
  Target Milestone: ---

Attempting to build trunk r225313 with --enable-languages=c,c++,ada
--enable-checking=release --disable-nls --disable-werror --disable-multilib
--build=i686-w64-mingw32 --host=i686-w64-mingw32
--with-gmp=/c/toolchain/prereqs --with-mpc=/c/toolchain/prereqs
--with-mpfr=/c/toolchain/prereqs --prefix=/c/toolchain/gcc-mingw
--target=i686-w64-mingw32 --disable-win32-registry --disable-shared
--with-sysroot=/c/toolchain/gcc-mingw --enable-version-specific-runtime-libs

Using gcc version 4.9.2 (i686-win32-dwarf-rev2, Built by MinGW-W64 project)

Stage1 fails with the following:
../../gcc/gcc/tree-sra.c:875:46: error: macro "access" requires 2 arguments,
but only 1 given
   struct access *access = new struct access ();
  ^
../../gcc/gcc/tree-sra.c:2410:46: error: macro "access" requires 2 arguments,
but only 1 given
   struct access *access = new struct access ();
  ^
Makefile:1071: recipe for target `tree-sra.o' failed
make[3]: *** [tree-sra.o] Error 1

It's conflicting with access macro definition in the mingw32-w64 C io.h header:
#ifdef __USE_MINGW_ACCESS
/*  Old versions of MSVCRT access() just ignored X_OK, while the version
shipped with Vista, returns an error code.  This will restore the
old behaviour  */
static inline int __mingw_access (const char *__fname, int __mode) {
  return  _access (__fname, __mode & ~X_OK);
}

#define access(__f,__m)  __mingw_access (__f, __m)
#endif

This appears to have been introduced by r223956.

[Bug fortran/52846] [F2008] Support submodules

[pault at gcc dot gnu.org]

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

--- Comment #5 from Paul Thomas  ---
Author: pault
Date: Thu Jul  2 20:39:56 2015
New Revision: 225354

URL: https://gcc.gnu.org/viewcvs?rev=225354&root=gcc&view=rev
Log:
2015-07-02  Paul Thomas  

PR fortran/52846
* decl.c (get_proc_name): Make a partially populated interface
symbol to carry the characteristics of a module procedure and
its result.
(variable_decl): Declarations of dummies or results in the
abreviated form of module procedure is an error.
(gfc_match_import): IMPORT is not permitted in the interface
declaration of module procedures.
(match_attr_spec): Submodule variables have implicit save
attribute for F2008 onwards.
(gfc_match_prefix): Add 'module' as the a prefix and set the
module_procedure attribute.
(gfc_match_formal_arglist): For a module procedure keep the
interface formal_arglist from the interface, match new the
formal arguments and then compare the number and names of each.
(gfc_match_procedure): Add case COMP_SUBMODULE.
(gfc_match_function_decl, gfc_match_subroutine_decl): Set the
module_procedure attribute.
(gfc_match_entry, gfc_match_end):  Add case COMP_SUBMODULE. If
attr abr_modproc_decl is set, switch the message accordingly
for subroutines and functions.
(gfc_match_submod_proc): New function to match the abbreviated
style of submodule declaration.
* gfortran.h : Add ST_SUBMODULE and ST_END_SUBMODULE. Add the
attribute bits 'used_in_submodule' and 'module_procedure'. Add
the bit field 'abr_modproc_decl' to gfc_symbol. Add prototypes
for 'gfc_copy_dummy_sym', 'gfc_check_dummy_characteristics' and
'gfc_check_result_characteristics'.
* interface.c : Add the prefix 'gfc_' to the names of functions
'check_dummy(result)_characteristics' and all their references.
* match.h : Add prototype for 'gfc_match_submod_proc' and
'gfc_match_submodule'.
(check_sym_interfaces): A module procedure is not an error in
a module procedure statment in a generic interface.
* module.c (gfc_match_submodule): New function. Add handling
for the 'module_procedure' attribute bit.
(gfc_use_module): Make sure that a submodule cannot use itself.
* parse.c (decode_statement): Set attr has_'import_set' for
the interface declaration of module procedures. Handle a match
occurring in 'gfc_match_submod_proc' and a match for
'submodule'.
(gfc_enclosing_unit): Include the state COMP_SUBMODULE.
(gfc_ascii_statement): Add END SUBMODULE.
(accept_statement): Add ST_SUBMODULE.
(parse_spec): Disallow statement functions in a submodule
specification part.
(parse_contained): Add ST_END_SUBMODULE and COMP_SUBMODULE
twice each.
(get_modproc_result): Copy the result symbol of the interface.
(parse_progunit): Call it.
(set_syms_host_assoc): Make symbols from the ancestor module
and submodules use associated, as required by the standard and
set all private components public. Module procedures 'external'
attribute bit is reset and the 'used_in_submodule' bit is set.
(parse_module): If this is a submodule, use the ancestor module
and submodules. Traverse the namespace, calling
'set_syms_host_assoc'. Add ST_END_SUBMODULE and COMP_SUBMODULE.
* parse.h : Add COMP_SUBMODULE.
* primary.c (match_variable): Add COMP_SUBMODULE.
* resolve.c (compare_fsyms): New function to compare the dummy
characteristics of a module procedure with its interface.
(resolve_fl_procedure): Compare the procedure, result and dummy
characteristics of a module_procedure with its interface, using
'compare_fsyms' for the dummy arguments.
* symbol.c (gfc_add_procedure): Suppress the check for existing
procedures in the case of a module procedure.
(gfc_add_explicit_interface): Skip checks that must fail for
module procedures.
(gfc_add_type): Allow a new type to be added to module
procedures, their results or their dummy arguments.
(gfc_copy_dummy_sym): New function to generate new dummy args
and copy the characteristics from the interface.
* trans-decl.c (gfc_sym_mangled_function_id): Module procedures
must always have their names mangled as if they are symbols
coming from a declaration in a module.
(gfc_get_symbol_decl): Add 'used_in_submodule' to the assert.
(gfc_finish_var_decl): Symbols with the 'used_in_submodule' bit
set are set DECL_EXTERNAL as if they were use associated.

2015-07-02  Paul Thomas  

PR fortran/52846
* gfortran.dg/submodule_1.f90: New test
* gfortran.dg/su

[Bug libstdc++/66742] abort on sorting list with custom compiler that is not stateless

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Indeed. Splicing lists has a precondition that l1.get_allocator() ==
l2.get_allocator(), and so we check:

  if (l1.get_allocator() != l2.get_allocator())
abort();

and obviously that fails for your invalid allocator type.

[Bug c++/66745] New: ice in check_unstripped_args

[dcb314 at hotmail dot com]

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

Bug ID: 66745
   Summary: ice in check_unstripped_args
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

gcc trunk dated 20150701, trying to compile the attached source code
with flags -g -std=c++11, does this

/usr/include/boost/python/detail/caller.hpp:194:43: internal compiler error: in
check_unstripped_args, at cp/pt.c:1039
 impl(F f, Policies p) : m_data(f,p) {}
   ^

[Bug c++/66745] ice in check_unstripped_args

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Created attachment 35900
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35900&action=edit
C++ source code, compressed with xz

[Bug bootstrap/66744] [6 Regression] Bootstrap failure due to conflicting access() on i686-w64-mingw32

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
Summary|Bootstrap failure due to|[6 Regression] Bootstrap
   |conflicting access() on |failure due to conflicting
   |i686-w64-mingw32|access() on
   ||i686-w64-mingw32

--- Comment #1 from Andrew Pinski  ---
This is most likely introduced by the change to C++11 by default.

[Bug tree-optimization/66729] Segfault starting with r224967

[pthaugen at gcc dot gnu.org]

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

--- Comment #6 from Pat Haugen  ---
(In reply to rsand...@gcc.gnu.org from comment #4)
> 
> Hmm, bootstrap succeeded for me on gcc110.  I used r225278, but I don't
> think anything significant changed between the two.

Mike Meissner and I ran various builds since he was not seeing any problem on
the same machine I was building on. From what I can tell, this is starting to
look like an issue when building with older compiler versions.

I can recreate the problem on machines with 4.3 and 4.4 versions of GCC as the
default distro compiler but if I modify my path so a 4.8 version of the
compiler is found first my bootstrap succeeds. Looks like gcc110 is a 4.7
distro compiler, and appears not an issue there.

[Bug fortran/66725] Issue with silent conversion int to char, ICE if int too large

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-02
 CC||kargl at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #3 from kargl at gcc dot gnu.org ---
It seems that a type check is missing for STATUS=some_entity.
With this diff (watch cut-n-paste tab corruption),

Index: io.c
===
--- io.c(revision 225348)
+++ io.c(working copy)
@@ -2071,6 +2071,12 @@ gfc_match_open (void)
   static const char *status[] = { "OLD", "NEW", "SCRATCH",
"REPLACE", "UNKNOWN", NULL };

+  if (open->status->ts.type != BT_CHARACTER)
+   {
+ gfc_error("scalar-default-char-expr required at %C");
+ goto cleanup;
+   } 
+
   if (!compare_to_allowed_values ("STATUS", status, NULL, NULL,
  open->status->value.character.string,
  "OPEN", warn))

I get

% gfc6 -o z aa.f90
aa.f90:2:23:

open (1, status=257)
   1
Error: scalar-default-char-expr required at (1)

I suspect the other TAGS need a similar check.

[Bug target/66746] New: Failure to compile #include with -miamcu

[thiago at kde dot org]

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

Bug ID: 66746
   Summary: Failure to compile #include  with -miamcu
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago at kde dot org
  Target Milestone: ---

Source code:
#include 

Compiling with:
  gcc -m32 -miamcu -c test.c

Produces a couple thousand errors, starting with:

/home/thiago/obj/gcc/gcc/include/ia32intrin.h:54:28: sorry, unimplemented: SSE
isn’t supported in Intel MCU psABI
 #pragma GCC target("sse4.2")
^
/home/thiago/obj/gcc/gcc/include/ia32intrin.h:61:46: sorry, unimplemented: SSE
isn’t supported in Intel MCU psABI
 __crc32b (unsigned int __C, unsigned char __V)
  ^

I don't want to use SSE, but x86intrin.h has useful intrinsics for instructions
from as early as the 8086 (like __ror[bwd]). This header should compile.

[Bug c++/66743] [5/6 regression] ICE: tree check: expected record_type or union_type or qual_union_type, have underlying_type in for_each_template_parm_r, at cp/pt.c:8234

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Fri Jul  3 00:45:43 2015
New Revision: 225366

URL: https://gcc.gnu.org/viewcvs?rev=225366&root=gcc&view=rev
Log:
PR c++/66743
* pt.c (for_each_template_parm_r) [UNDERLYING_TYPE]: Use
TYPE_VALUES_RAW rather than TYPE_FIELDS.

Added:
branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/alias-decl-51.C
Modified:
branches/gcc-5-branch/gcc/cp/ChangeLog
branches/gcc-5-branch/gcc/cp/pt.c

[Bug c++/66743] [5/6 regression] ICE: tree check: expected record_type or union_type or qual_union_type, have underlying_type in for_each_template_parm_r, at cp/pt.c:8234

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Author: jason
Date: Fri Jul  3 00:45:34 2015
New Revision: 225365

URL: https://gcc.gnu.org/viewcvs?rev=225365&root=gcc&view=rev
Log:
PR c++/66743
* pt.c (for_each_template_parm_r) [UNDERLYING_TYPE]: Use
TYPE_VALUES_RAW rather than TYPE_FIELDS.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-51.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug c/66747] New: The commit r225260 broke the builds of the mips-{mti,img}-linux-gnu tool chains.

[doug.gilmore at imgtec dot com]

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

Bug ID: 66747
   Summary: The commit r225260 broke the builds of the
mips-{mti,img}-linux-gnu tool chains.
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doug.gilmore at imgtec dot com
  Target Milestone: ---

The commit r225260 broke the builds of the mips-{mti,img}-linux-gnu tool
chains.

To reproduce the problem, configure the binutils build from the directory
/scratch/d/obj-mips-img-linux-gnu/binutils-gdb:


/scratch/d/src/binutils-gdb/configure
--prefix=/scratch/d/install-mips-img-linux-gnu --target=mips-img-linux-gnu
--with-sysroot=/scratch/d/install-mips-img-linux-gnu/sysroot
then run make and make install

Then configure the gcc build from the directory
/scratch/d/obj-mips-img-linux-gnu/initial_gcc:
/scratch/d/src/gcc/configure --prefix=/scratch/d/install-mips-img-linux-gnu
--disable-libssp --disable-libgomp --disable-libmudflap --disable-decimal-float
--with-mips-plt --target=mips-img-linux-gnu --enable-languages=c
--without-headers --disable-shared --disable-threads --disable-libquadmath
--disable-libatomic
running make fails with:

/scratch/d/obj-mips-img-linux-gnu/initial_gcc/./gcc/xgcc
-B/scratch/d/obj-mips-img-linux-gnu/initial_gcc/./gcc/
-B/scratch/d/install-mips-img-linux-gnu/mips-img-linux-gnu/bin/
-B/scratch/d/install-mips-img-linux-gnu/mips-img-linux-gnu/lib/ -isystem
/scratch/d/install-mips-img-linux-gnu/mips-img-linux-gnu/include -isystem
/scratch/d/install-mips-img-linux-gnu/mips-img-linux-gnu/sys-include-g -O2
-minterlink-mips16 -mips64r6 -O2 -g -O2 -minterlink-mips16 -DIN_GCC 
-DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include  -I. -I. -I../../../.././gcc -I/scratch/d/src/gcc/libgcc
-I/scratch/d/src/gcc/libgcc/. -I/scratch/d/src/gcc/libgcc/../gcc
-I/scratch/d/src/gcc/libgcc/../include   -g0  -finhibit-size-directive
-fno-inline -fno-exceptions -fno-zero-initialized-in-bss -fno-toplevel-reorder
-fno-tree-vectorize -fbuilding-libgcc -fno-stack-protector  -Dinhibit_libc -I.
-I. -I../../../.././gcc -I/scratch/d/src/gcc/libgcc
-I/scratch/d/src/gcc/libgcc/. -I/scratch/d/src/gcc/libgcc/../gcc
-I/scratch/d/src/gcc/libgcc/../include  -o crtbeginT.o -MT crtbeginT.o -MD -MP
-MF crtbeginT.dep  -c /scratch/d/src/gcc/libgcc/crtstuff.c -DCRT_BEGIN
-DCRTSTUFFT_O
/scratch/d/src/gcc/libgcc/crtstuff.c: In function 'frame_dummy':
/scratch/d/src/gcc/libgcc/crtstuff.c:490:1: error: unrecognizable insn:
 }
 ^
(insn 82 67 8 (sequence [
(jump_insn 7 67 66 (set (pc)
(if_then_else (eq (reg/f:SI 2 $2 [197])
(const_int 0 [0]))
(label_ref:SI 15)
(pc))) /scratch/d/src/gcc/libgcc/crtstuff.c:470 466
{*branch_equalitysi}
 (expr_list:REG_DEAD (reg/f:SI 2 $2 [197])
(int_list:REG_BR_PROB 3017 (nil)))
 -> 15)
(insn/f 66 7 8 (set (mem/c:DI (plus:SI (reg/f:SI 29 $sp)
(const_int 8 [0x8])) [5  S8 A64])
(reg:DI 31 $31)) 302 {*movdi_64bit}
 (expr_list:REG_FRAME_RELATED_EXPR (set/f (mem/c:DI (plus:SI
(reg/f:SI 29 $sp)
(const_int 8 [0x8])) [5  S8 A64])
(reg:DI 31 $31))
(nil)))
]) /scratch/d/src/gcc/libgcc/crtstuff.c:470 -1
 (nil))

We are working around the issue by reverting r225260.

[Bug c/50584] No warning for passing small array to C99 static array declarator

[sergei.ivn+bugzilla at gmail dot com]

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

Serg Iv  changed:

   What|Removed |Added

 CC||sergei.ivn+bugzilla at gmail 
dot c
   ||om

--- Comment #7 from Serg Iv  ---
Some excerpts from the C11 standard:

/-
If the keyword static also appears within the [ and ] of the array type
derivation, then for each call to the function, the value of the corresponding
actual argument shall provide access to the first element of an array with at
least as many elements as specified by the size expression.
\-

And another one:

/-
The following are all compatible function prototype declarators:
[..snip..]
void f(double a[restrict 3][5]);
void f(double a[restrict static 3][5]);

(Note that the last declaration also specifies that the argument corresponding
to a in any call to f must be a non-null pointer to the first of at least three
arrays of 5 doubles, which the others do not.)
\-

I'm not sure about warnings (the meaning of the word "shall" is unclear for
me), but IMO according to the standard null-pointers should issue an *error*.

[Bug target/37072] -mfancy-math-387 should be the default in FreeBSD

[gerald at gcc dot gnu.org]

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

--- Comment #3 from gerald at gcc dot gnu.org  ---
Author: gerald
Date: Fri Jul  3 01:35:18 2015
New Revision: 225367

URL: https://gcc.gnu.org/viewcvs?rev=225367&root=gcc&view=rev
Log:
PR target/37072
* doc/invoke.texi (i386 and x86-64 Options): -mno-fancy-math-387
is not actually the default on FreeBSD.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/doc/invoke.texi

[Bug c/50584] No warning for passing small array to C99 static array declarator

[sergei.ivn+bugzilla at gmail dot com]

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

--- Comment #8 from Serg Iv  ---
Forgot to say that C99 standard has the same sentences.

Useful links:

C99 draft http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf

C11 draft http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1570.pdf

[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[amker at gcc dot gnu.org]

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

amker at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-03
 Ever confirmed|0   |1

--- Comment #6 from amker at gcc dot gnu.org ---
This relates to cost computation on powerpc64.

[Bug tree-optimization/66612] [6 regression] FAIL: gcc.target/powerpc/20050830-1.c scan-assembler bdn

[amker at gcc dot gnu.org]

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

--- Comment #7 from amker at gcc dot gnu.org ---
On powerpc32, the address candidate doesn't have the period precision to
eliminate conditional iv.  That's why bdn is generated.
On powerpc64, the address candidate does have the period precision because the
address type is of 64bit now.

This reveals a missed-optimization in IVO.  Currently tree level IVO doesn't
know if the loop condition can be tranformed into low-overhead looping
structure (using doloop).  One exception is when the condition is a comparison
of the candidate IV against ZERO (Even in this case, it doesn't know how much
cost could be saved with doloop optimization, it just decrease the cost by a
provisional const).  

As for this case, the loop condition is (w_3(D) > 511), which could be
transformed to a comparison against ZERO in rtl level doloop optimization. 
Unfortunately, tree IVO knows nother about this.  It's also difficult to check
whether doloop is viable on GIMPLE, because there are many heuristics/fallouts
in RTL transformation.  

I consider this as another inconsistency issue between tree IVO and rtl loop
optimizers.  Another example is RTL unroller messes up induction variables
chosen by tree IVO.

I think we could XFAIL this on powerpc64 for now.  So what's your opinions?

Thanks.

[Bug target/66746] Failure to compile #include with -miamcu

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-03
 CC||hjl.tools at gmail dot com
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

[Bug target/66746] Failure to compile #include with -miamcu

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
A patch is posted at

https://gcc.gnu.org/ml/gcc-patches/2015-07/msg00174.html

[Bug c++/66743] [5/6 regression] ICE: tree check: expected record_type or union_type or qual_union_type, have underlying_type in for_each_template_parm_r, at cp/pt.c:8234

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #5 from Markus Trippelsdorf  ---
fixed

[Bug debug/66745] [6 Regression] ice in check_unstripped_args

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-07-03
 CC||trippels at gcc dot gnu.org
  Component|c++ |debug
Summary|ice in  |[6 Regression] ice in
   |check_unstripped_args   |check_unstripped_args
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
(gdb) p debug_tree(arg) 
  constant 128>  
unit size  constant 16>  
align 64 symtab -608120512 alias set -1 canonical type 0x7fffe0057348   
fields  
asm_written unsigned DI 
size
unit size
align 64 symtab -608120032 alias set -1 canonical type
0x7fffe00571f8> 
unsigned DI file
/home/dcb/rpmbuild/BUILD/ledger-720c03b139d251c53f9deef491f5953e2fdb97ca/src/py_account.cc
line 92 col 5264 size  unit size
align 64 offset_align 512   
offset   
bit offset  context  
chain 
DI file
/home/dcb/rpmbuild/BUILD/ledger-720c03b139d251c53f9deef491f5953e2fdb97ca/src/py_account.cc
line 92 col 5264 size  unit size
align 64 offset_align 512 offset  bit
offset  context >>
ptrmemfunc fn type 
pointer_to_this  reference_to_this
 chain >   
$11 = void  

(gdb) p  debug_tree(strip_typedefs(arg,0))  
  constant 128>  
unit size  constant 16>  
align 64 symtab 0 alias set -1 canonical type 0x7fffe0057348
fields  
unsigned DI 
size
unit size
align 64 symtab 0 alias set -1 canonical type 0x7fffe00571f8>   
unsigned DI file /usr/include/boost/type_traits/is_class.hpp line 109
col 147 size  unit size
align 64 offset_align 512   
offset   
bit offset  context  
chain 
DI file /usr/include/boost/type_traits/is_class.hpp line 109 col
147 size  unit size 
align 64 offset_align 512 offset  bit
offset  context >>
ptrmemfunc fn type 
chain > 
$12 = void