[Bug tree-optimization/67955] tree-dse does not use pointer info

[vries at gcc dot gnu.org]

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

--- Comment #6 from vries at gcc dot gnu.org ---
(In reply to vries from comment #4)
> For now, I'll do a bootstrap and reg-test to make sure it doesn't break
> anything.

Updated tentative patch passes bootstrap and reg-test

[Bug c++/67961] Incorrect type of meber of struct in error message

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to other+gcc from comment #0)
> where type of that rvalue variable is uint32_t not std::size_t.

There is no rvalue of type uint32_t. The type of the **lvalue** is uint32_t.

The rvalue is the temporary that gets created implicitly, which is of type
size_t.


FWIW clang doesn't mention rvalues, it just says there is no matching function
for the call because ...

prog.cc:4:6: note: candidate function not viable: no known conversion from
'std::uint32_t' (aka 'unsigned int') to 'std::size_t &' (aka 'unsigned long &')
for 1st argument

[Bug fortran/47469] Check whether arrayfunc_assign_needs_temporary misses TBP/PPC attributes

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
> Tobias' version is prettier! Does it apply without regressions?

Obviously the patch in comment 0 no longer applies.

Now finding 'gfc_expr_attr (expr2).pointer' prettier than
'expr2->symtree->n.sym->attr.pointer' is just a matter of taste (29 characters
compared to 35). For a newbie like the later is easier to understand than the
former.

BTW what should it be for 'value.function.esym'?

[Bug tree-optimization/67476] Add --param parloops-schedule=<static|dynamic|guided|auto|runtime>

[vries at gcc dot gnu.org]

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

--- Comment #14 from vries at gcc dot gnu.org ---
Author: vries
Date: Wed Oct 14 14:29:55 2015
New Revision: 228813

URL: https://gcc.gnu.org/viewcvs?rev=228813=gcc=rev
Log:
Handle simple latch in expand_omp_for_generic

2015-10-14  Tom de Vries  

backport from trunk:
2015-10-12  Tom de Vries  

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

Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/omp-low.c

[Bug tree-optimization/67476] Add --param parloops-schedule=<static|dynamic|guided|auto|runtime>

[vries at gcc dot gnu.org]

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

--- Comment #17 from vries at gcc dot gnu.org ---
Author: vries
Date: Wed Oct 14 14:30:41 2015
New Revision: 228817

URL: https://gcc.gnu.org/viewcvs?rev=228817=gcc=rev
Log:
Add param parloops-schedule

2015-10-14  Tom de Vries  

backport from trunk:
2015-10-13  Tom de Vries  

PR tree-optimization/67476
* doc/invoke.texi (@item parloops-schedule): New item.
* params.def (PARAM_PARLOOPS_SCHEDULE): New DEFPARAMENUM5.
* tree-parloops.c: Include params-enum.h.
(create_parallel_loop): Handle PARAM_PARLOOPS_SCHEDULE.

* testsuite/libgomp.c/autopar-3.c: New test.
* testsuite/libgomp.c/autopar-4.c: New test.
* testsuite/libgomp.c/autopar-5.c: New test.
* testsuite/libgomp.c/autopar-6.c: New test.
* testsuite/libgomp.c/autopar-7.c: New test.
* testsuite/libgomp.c/autopar-8.c: New test.

Added:
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/autopar-3.c
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/autopar-4.c
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/autopar-5.c
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/autopar-6.c
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/autopar-7.c
branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/autopar-8.c
Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/doc/invoke.texi
branches/gomp-4_0-branch/gcc/params.def
branches/gomp-4_0-branch/gcc/tree-parloops.c
branches/gomp-4_0-branch/libgomp/ChangeLog.gomp

[Bug tree-optimization/67476] Add --param parloops-schedule=<static|dynamic|guided|auto|runtime>

[vries at gcc dot gnu.org]

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

--- Comment #16 from vries at gcc dot gnu.org ---
Author: vries
Date: Wed Oct 14 14:30:19 2015
New Revision: 228815

URL: https://gcc.gnu.org/viewcvs?rev=228815=gcc=rev
Log:
Handle original loop tree in expand_omp_for_generic

2015-10-14  Tom de Vries  

backport from trunk:
2015-10-13  Tom de Vries  

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

Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/omp-low.c

[Bug tree-optimization/67476] Add --param parloops-schedule=<static|dynamic|guided|auto|runtime>

[vries at gcc dot gnu.org]

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

--- Comment #15 from vries at gcc dot gnu.org ---
Author: vries
Date: Wed Oct 14 14:30:05 2015
New Revision: 228814

URL: https://gcc.gnu.org/viewcvs?rev=228814=gcc=rev
Log:
Add missing phis in expand_omp_for_generic

2015-10-14  Tom de Vries  

backport from trunk:
2015-10-12  Tom de Vries  

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

Modified:
branches/gomp-4_0-branch/gcc/ChangeLog.gomp
branches/gomp-4_0-branch/gcc/omp-low.c

[Bug target/67963] -march=lakemont generates x87 instructions

[julia.koval at intel dot com]

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

--- Comment #3 from Yulia Koval  ---
Patch posted at:

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

The same test with this patch:

objdump -d test.o

test.o: file format elf32-i386


Disassembly of section .text:

 :
   0:   55  push   %ebp
   1:   89 e5   mov%esp,%ebp
   3:   a1 00 00 00 00  mov0x0,%eax
   8:   5d  pop%ebp
   9:   c3  ret

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[mrs at gcc dot gnu.org]

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

mrs at gcc dot gnu.org  changed:

   What|Removed |Added

 CC||mrs at gcc dot gnu.org

--- Comment #12 from mrs at gcc dot gnu.org  ---
Is this just a partial import from upstream?  If so, I think we should just
check it in and call the issue solved.

[Bug testsuite/67959] "width of 'code' exceeds its type" error in ssa-thread-13

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #3 from Jeffrey A. Law  ---
Should be fixed on trunk now.

[Bug target/67383] reload_cse_simplify_operands fails on ARMV7-M

[renlin at gcc dot gnu.org]

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

renlin at gcc dot gnu.org changed:

   What|Removed |Added

 CC||renlin at gcc dot gnu.org

--- Comment #5 from renlin at gcc dot gnu.org ---
(In reply to Vladimir Makarov from comment #4)
> I've tried to reproduce it on gcc-4.9 branch as of today but failed.  The
> problem with constraints and overlapped hard regs was probably fixed by
> backported patches.
> 
> Still I have another problem:
> 
> ../lib/mm/mm.c: In function ‘chunk_node’:
> ../lib/mm/mm.c:430:1: internal compiler error: in assign_by_spills, at
> lra-assigns.c:1357
> 0x853dd5 assign_by_spills
>
> /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/lra-assigns.c:1357
> 0x854617 lra_assign()
>
> /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/lra-assigns.c:1503
> 0x84de9c lra(_IO_FILE*)
> /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/lra.c:2388
> 0x80ca16 do_reload
> /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/ira.c:5474
> 0x80ca16 rest_of_handle_reload
> /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/ira.c:5615
> 0x80ca16 execute
> /home/cygnus/vmakarov/build1/gcc-4.9-branch/gcc/gcc/ira.c:5644
> 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 is in assigning a hard reg to reload pseudo 442 for insns
> 
>  Choosing alt 0 in insn 153:  (0) =  (1) %0  (2) r {*arm_adddi3}
>   Creating newreg=441, assigning class GENERAL_REGS to r441
>   Creating newreg=442 from oldreg=268, assigning class GENERAL_REGS to
> r442
>   153: {r441:DI=r441:DI+r442:DI;clobber cc:CC;}
>   REG_DEAD r268:DI
>   REG_UNUSED cc:CC
>   REG_EQUIV [sp:SI+0x10]
> Inserting insn reload before:
>   642: r441:DI=[sp:SI+0x8]
>   644: r442:DI=r268:DI
> Inserting insn reload after:
>   643: [sp:SI+0x10]=r441:DI
> 
> We canot use hard reg 0, 1, 2 as they live through insn 153:
> 
>  ...
>   153: {r272:DI=r268:DI+r159:DI;clobber cc:CC;}
>   REG_DEAD r268:DI
>   REG_UNUSED cc:CC
>   REG_EQUIV [sp:SI+0x10]
>   ...
>   159: call [`debug_printf'] argc:0x20
>   REG_DEAD r1:SI
>   REG_DEAD r0:SI
>   REG_DEAD r2:DI
> 
> Hard reg 7 (FP), 9 (thread), 10 (pic), 13 (sp), 15 (pc) are fixed.  So
> we have only one hole for DI value containing 2 regs (4, 5) and pair
> (4,5) is assigned to 441 and there are no regs for 442.


In this particular case, hard register 12 is free, and hard register 11 can be
spilled to accommodate this DImode pseudo register.

However, the target hook HARD_REGNO_MODE_OK rejects register pairs start from
odd number (11 in this case.) So find_hard_regno_for() failed.

I have found r209615 relaxes the target hook. In thumb2 mode, any register pair
is allowed. I have verified, it fix this ICE.


I will do a full regression test first, If no new issues, I will backport it to
branch 4.9

[Bug go/67968] New: go1: internal compiler error: in write_specific_type_functions, at go/gofrontend/types.cc:1812

[gong_su at hotmail dot com]

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

Bug ID: 67968
   Summary: go1: internal compiler error: in
write_specific_type_functions, at
go/gofrontend/types.cc:1812
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: gong_su at hotmail dot com
CC: cmang at google dot com
  Target Milestone: ---

Failure occurs when trying to compile Ethereum RPC API.

root@linux05:~/Downloads/go-ethereum# make geth
build/env.sh go install -v -ldflags '-X main.gitCommit
4813a39100dc8dc884b0a68ceae51c2c420f92af' ./cmd/geth
github.com/ethereum/go-ethereum/rpc/api
# github.com/ethereum/go-ethereum/rpc/api
go1: internal compiler error: in write_specific_type_functions, at
go/gofrontend/types.cc:1812
0x802473df Type::write_specific_type_functions(Gogo*, Named_type*,
std::__cxx11::basic_string
const&, Function_type*, std::__cxx11::basic_string const&, Function_type*)
../../src/gcc/go/gofrontend/types.cc:1812
0x80245b33 Type::specific_type_functions(Gogo*, Named_type*, Function_type*,
Function_type*, Named_object**, Named_object**)
../../src/gcc/go/gofrontend/types.cc:1791
0x8024639d Type::type_functions(Gogo*, Named_type*, Function_type*,
Function_type*, Named_object**, Named_object**)
../../src/gcc/go/gofrontend/types.cc:1668
0x8024eff7 Type::type_descriptor_constructor(Gogo*, int, Named_type*, Methods
const*, bool)
../../src/gcc/go/gofrontend/types.cc:2011
0x80250b1d Array_type::array_type_descriptor(Gogo*, Named_type*)
../../src/gcc/go/gofrontend/types.cc:6318
0x80248a33 Type::make_type_descriptor_var(Gogo*)
../../src/gcc/go/gofrontend/types.cc:1218
0x80248e05 Type::type_descriptor_pointer(Gogo*, Location)
../../src/gcc/go/gofrontend/types.cc:1156
0x801c8e6f Type_descriptor_expression::do_get_backend(Translate_context*)
../../src/gcc/go/gofrontend/expressions.cc:13400
0x801a8efd Interface_value_expression::do_get_backend(Translate_context*)
../../src/gcc/go/gofrontend/expressions.cc:14023
0x8021ef49 Temporary_statement::do_get_backend(Translate_context*)
../../src/gcc/go/gofrontend/statements.cc:470
0x801e8d27 Block::get_backend(Translate_context*)
../../src/gcc/go/gofrontend/gogo.cc:5811
0x8021ea51 Block_statement::do_get_backend(Translate_context*)
../../src/gcc/go/gofrontend/statements.cc:1802
0x801e8d27 Block::get_backend(Translate_context*)
../../src/gcc/go/gofrontend/gogo.cc:5811
0x8021ea51 Block_statement::do_get_backend(Translate_context*)
../../src/gcc/go/gofrontend/statements.cc:1802
0x801e8d27 Block::get_backend(Translate_context*)
../../src/gcc/go/gofrontend/gogo.cc:5811
0x801ea647 Function::build(Gogo*, Named_object*)
../../src/gcc/go/gofrontend/gogo.cc:5417
0x801ebd7d Named_object::get_backend(Gogo*, std::vector >&, std::vector >&,
std::vector >&)
../../src/gcc/go/gofrontend/gogo.cc:7136
0x801f514d Gogo::write_globals()
../../src/gcc/go/gofrontend/gogo.cc:1345
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Makefile:9: recipe for target 'geth' failed
make: *** [geth] Error 2

[Bug fortran/53800] [OOP] Wrong copy-in/copy-out when passing CLASS array to assumed-shape TYPE

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-14
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
> See http://j3-fortran.org/pipermail/j3/2012-June/005438.html
> and http://j3-fortran.org/pipermail/j3/2012-June/005445.html

The links are broken. At r228818 the output of the code in comment 0 is still

  42
  42

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

[vogt at linux dot vnet.ibm.com]

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

--- Comment #4 from Dominik Vogt  ---
Now this is the result of my efforts of reducing the original large test
program to a minimum.

---
struct s_t 
{ 
  unsigned f1: 8; 
  unsigned f2: 24; 
}; 
bool foo(int a, int **pp, s_t **pps, void *s, int **x) 
{ 
  s_t *ps = *pps; 
  int *gt; 
  int y; 
  int z; 

  __asm__ __volatile__ ("" : : : "0","1","2","3","6","7","14"); 
  unsigned i = **pp; 
  if (**pp >= 999 && **x < 77) 
{ 
  ps->f1 = **x; 
  ps->f2 = **pp; 
} 
  __asm__ __volatile__ ("" : : : "0","1","2","3","4","5","6","7","8"); 
  do { y &= *gt; } while (y != 0); 
  __asm__ __volatile__ ("" : : : "memory", "2","3","4","5"); 
  do { z &= *gt; } while (z != 0); 
  return i && x && ps && s; 
} 
---

Without having looked at the Rtl yet, I strongly suspect that the uninitialised
variables y and z trigger the problem.  Originally this was inlined code of a
function returning int or bool but without a return statement.  The __asm__
__volatile__ lines are replacements for functions calls to simplify the test. 
Whether the "stc" is removed or not seems to depend on which registers are
available and on how many variables are still in use.

See attached .tar.bz2 contains the test program, the assembler output and the
rtl output of -da.  If you need more information, just ask.

[Bug middle-end/67966] New: [6 regression] ICE in convert_move, at expr.c:282

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

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

Bug ID: 67966
   Summary: [6 regression] ICE in convert_move, at expr.c:282
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: build, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: hubicka at gcc dot gnu.org
  Target Milestone: ---
Target: ia64-*-*

This was broken by r228586.

../prev-gcc/xgcc -B../prev-gcc/ -B/usr/ia64-suse-linux/bin/
-B/usr/ia64-suse-linux/bin/ -B/usr/ia64-suse-linux/lib/ -isystem
/usr/ia64-suse-linux/include -isystem /usr/ia64-suse-linux/sys-include-c -g
-O2 -gtoggle  -gnatpg -gnata -W -Wall -nostdinc -I- -I. -Iada/generated -Iada
-I../../gcc/ada -I../../gcc/ada/gcc-interface ../../gcc/ada/eval_fat.adb -o
ada/eval_fat.o
+===GNAT BUG DETECTED==+   
| 6.0.0 20151014 (experimental) (ia64-suse-linux) GCC error:   |
| in convert_move, at expr.c:282   |
| Error detected around ../../gcc/ada/eval_fat.adb:191:21  |

[Bug testsuite/67959] "width of 'code' exceeds its type" error in ssa-thread-13

[law at gcc dot gnu.org]

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

--- Comment #2 from Jeffrey A. Law  ---
Author: law
Date: Wed Oct 14 17:04:04 2015
New Revision: 228819

URL: https://gcc.gnu.org/viewcvs?rev=228819=gcc=rev
Log:
[PATCH] [PR testsuite/67959]Minor cleanup for ssa-thread-13.c

PR testsuite/67959
* gcc.dg/tree-ssa/ssa-thread-13.c: Avoid bitfield assumptions.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/ssa-thread-13.c

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

[vogt at linux dot vnet.ibm.com]

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

--- Comment #5 from Dominik Vogt  ---
Created attachment 36509
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36509=edit
test program and debug output

test program and debug output

[Bug fortran/47469] Check whether arrayfunc_assign_needs_temporary misses TBP/PPC attributes

[mikael at gcc dot gnu.org]

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

--- Comment #4 from Mikael Morin  ---
(In reply to Dominique d'Humieres from comment #3)
> > Tobias' version is prettier! Does it apply without regressions?
> 
> Obviously the patch in comment 0 no longer applies.
> 
> Now finding 'gfc_expr_attr (expr2).pointer' prettier than
> 'expr2->symtree->n.sym->attr.pointer' is just a matter of taste (29
> characters compared to 35). For a newbie like the later is easier to
> understand than the former.
It isn't just a matter of taste.
when expr2 is a subreference (say obj%proc_ptr(...)), it's the pointerness of
the result of the proc_ptr interface that matters, not that of obj.

> 
> BTW what should it be for 'value.function.esym'?

Hmm, gfc_expr_attr should handle it gracefully.

[Bug c/67967] New: ICE in i386_pe_seh_unwind_emit

[tprince at computer dot org]

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

Bug ID: 67967
   Summary: ICE in i386_pe_seh_unwind_emit
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tprince at computer dot org
  Target Milestone: ---

Created attachment 36510
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36510=edit
C source

1st of many build failures on trunk:
$ /cygdrive/c/users/tim/tim/tim/src/gnu/gcc1/cyg64/gcc/xgcc -B/cygdrive/c/users
/tim/tim/tim/src/gnu/gcc1/cyg64/gcc/   -I../../../winsup/w32api/include -I../..
/../winsup/include -I../../../winsup/cygwin/include -g -O2 -DIN_GCC-W -Wall
 -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-proto
types -Wold-style-definition  -isystem ./include   -g -DIN_LIBGCC2 -fbuilding-l
ibgcc -fno-stack-protector   -I. -I../../gcc -I../../../libgcc -I../../../gcc -
I../../../include -I../../../libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -
DHAVE_CC_TLS -DUSE_EMUTLS -o _powitf2.o -MT _powitf2.o -MD -MP -MF _powitf2.dep
 -DL_powitf2 -c ../../../libgcc/libgcc2.c
../../../libgcc/libgcc2.c: In function ‘__powitf2’:
../../../libgcc/libgcc2.c:1851:1: internal compiler error: in
i386_pe_seh_unwind
_emit, at config/i386/winnt.c:1137
 }
 ^

unable to obtain pre-processed source

$ /cygdrive/c/users/tim/tim/tim/src/gnu/gcc1/cyg64/gcc/xgcc -v
Using built-in specs.
COLLECT_GCC=/cygdrive/c/users/tim/tim/tim/src/gnu/gcc1/cyg64/gcc/xgcc
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 --disable-__cxa_atexit --disable-bootstrap
Thread model: posix
gcc version 6.0.0 20151014 (experimental) (GCC)

[Bug c/67967] ICE in i386_pe_seh_unwind_emit

[tprince at computer dot org]

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

--- Comment #1 from tprince at computer dot org ---
Created attachment 36511
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36511=edit
include file

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

[wmi at google dot com]

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

--- Comment #6 from wmi at google dot com ---
(In reply to Dominik Vogt from comment #3)
> I think the Rtl in comment 1 ist correct.  Note that "i" is stored at
> 0x.xx00 and "j" is stored at 0x.00xx.  That is the
> reason for the rather confusing mask in insn 9.  Your test program compiles
> and runs fine for me.

I am not familiar with s390 assembly. please correct me if I am wrong:

This is the assembly generated for my testcase:
.globl _Z3fooP1A
.type   _Z3fooP1A, @function
_Z3fooP1A:
.LFB0:
larl%r5,.L3
mvi 0(%r2),3// move 0x.0003 to 0(%r2) 
l   %r1,.L4-.L3(%r5)// load 0xff00 to %r1
n   %r1,0(%r2)  // %r1 = %r1 & 0(%r2) =
0x. 
oill%r1,5   // %r1 = %r1 | 5 = 0x.0005
st  %r1,0(%r2)  // store 0x.0005 to 0(%r2)
br  %r14
.section.rodata
.align  8
.L3:
.L4:
.long   -16777216
.align  2
.previous

According to the asm sequence above, the result of a should be:
0x.0005, but the correct result should be 0x.0305,
right?

[Bug testsuite/67959] "width of 'code' exceeds its type" error in ssa-thread-13

[law at redhat dot com]

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

--- Comment #1 from Jeffrey A. Law  ---
Thomas, in the future it'd be helpful to indicate an actual target
configuration for those not as intimately familiar with the ARM targets :-)

I went through 3 before I stumbled on on that would show this failure.

I'll be checking in a fix momentarily.

[Bug c/67967] ICE in i386_pe_seh_unwind_emit

[tprince at computer dot org]

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

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

According to ChangeLog, ktietz is the one who modified this since it was last
working (verified on 26 Sept. 2015).  There are hundreds of failures pointing
to the same source line, between build and test suite.

[Bug c/67967] ICE in i386_pe_seh_unwind_emit

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
Actually, gcc can now handle misaligned stack for x86_64 and it emits 

{
  rtx unspec = gen_rtx_UNSPEC (mode, gen_rtvec (1, reg), UNSPEC_STOREU);
  insn = emit_insn (gen_rtx_SET (mem, unspec));
}

that is later decorated with:

add_reg_note (insn, REG_CFA_EXPRESSION, gen_rtx_SET (mem, reg));

So, i386_pe_seh_unwind_emit has to be updated to handle REG_CFA_EXPRESSION.

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

[vogt at linux dot vnet.ibm.com]

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

Dominik Vogt  changed:

   What|Removed |Added

 CC||vogt at linux dot vnet.ibm.com

--- Comment #3 from Dominik Vogt  ---
I think the Rtl in comment 1 ist correct.  Note that "i" is stored at
0x.xx00 and "j" is stored at 0x.00xx.  That is the
reason for the rather confusing mask in insn 9.  Your test program compiles and
runs fine for me.

[Bug fortran/67696] libbacktrace prints C++ demangled name for Fortran symbol

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
s/may/my/

[Bug fortran/67696] libbacktrace prints C++ demangled name for Fortran symbol

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed|2015-10-13 00:00:00 |2015-10-14
 Ever confirmed|0   |1

--- Comment #3 from Dominique d'Humieres  ---
> so seemingly target specific ?

I forgot to say that backtrace is useless on darwin, so I got may results with
gdb 7.10 and lldb 340.4.70/

[Bug tree-optimization/67476] Add --param parloops-schedule=<static|dynamic|guided|auto|runtime>

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #13 from vries at gcc dot gnu.org ---
patch series and test-cases committed, marking resolved-fixed.

[Bug c++/67960] New: Prefixing a function with [[deprecated]] produces multiple warnings

[chrisb2244 at gmail dot com]

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

Bug ID: 67960
   Summary: Prefixing a function with [[deprecated]] produces
multiple warnings
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chrisb2244 at gmail dot com
  Target Milestone: ---

The [[deprecated]] prefix for a function produces multiple warnings.

In v5.2.0, there are 3 warnings for the code

[[deprecated]] void doNothing(){}
int main(){
doNothing();
}

I am informed that in v4.9.2, only 2 warnings are emitted for the same code - 
http://stackoverflow.com/questions/33117030/when-using-deprecated-the-warning-is-given-3-times?noredirect=1#comment54048535_33117030

Replacing the body of main with

auto f = doNothing;
f();

reduces the output to 2 warnings in v5.2.0, and apparently 1 warning in 4.9.2


Bug 17729 (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17729) seems to be
about a similar issue (the same issue?) but there discusses the attribute
rather than a tag - I assume the tag is implemented in terms of the attribute
but am unsure hence a new bug report.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener  ---
(In reply to rsand...@gcc.gnu.org from comment #8)
> Actually, the problem seems to be that we're oscillating
> between forms.
> 
> The old fold-const.c folders converted sequences of sqrts
> and cbrts into a pow call while tree-ssa-math-opts.c goes
> the other way.  In that situation things were well-controlled:
> we did both transformations only once, in that order.
> Moving the fold-const.c folders to match.pd means that we
> try them many times and that ultimately they win.

Ah, I was worried about such cases.  The fold-const.c/builtins.c code
has two kinds of transforms - canonicalizations (producing for example
pow (x, 2) from x*x or like in this case pow from sqrt*cbrt) and
"simplifications" (well, transforms to "faster" implementations).
The canonicalizations are purely to catch more CSE and simplifications.

I wonder if we should have two "phases" of simplifications, first
aggressively canonicalize and later apply the optimizations.  We could
key this on a new GIMPLE state, PROP_gimple_XXX (can't figure out a good
acronym) and key patterns with it (like we have reload_completed on RTL).
The pass deciding it's time to "lower" stuff (rather than canonicalize)
would be cse_sincos (the pass doing the transform required
for the testcase).  Note that some patters in that pass might be moved
to match.pd instead so we can key PROP_gimple_XXX on the forwprop pass
preceeding cse_sincos (so we can transform all stmts at once).

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

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

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

--- Comment #7 from Ilya Enkovich  ---
(In reply to Pat Haugen from comment #6)
> 416.gamess now passes on powerpc64 as well.

Fixed then

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

[ienkovich at gcc dot gnu.org]

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

Ilya Enkovich  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Ilya Enkovich  ---
(In reply to James Almer from comment #9)
> Looks like it did. Thanks.

Fixed then

[Bug tree-optimization/67955] tree-dse does not use pointer info

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||alias, missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-14
 Ever confirmed|0   |1

--- Comment #3 from Richard Biener  ---
(In reply to vries from comment #2)
> (In reply to Richard Biener from comment #1)
> > The same points-to set results from
> > 
> > int *p = (int *)((char *) + 2);
> > 
> > or even
> > 
> > int *p =  + 1;
> > 
> 
> I see, I didn't realize that. But AFAICT, in both these cases, storing to *p
> is illegal (if 'a' is a scalar int).
> 
> > so you can't use points-to info that way (to derive a must-alias).
> 
> I see your point related to an array object, there pointers to different
> array elements would have identical points-to sets.
> 
> I wonder though: if we have a store '*p = 0', and the size of the store is
> the same as the size of the pointed-to object of pointer p, can't we
> conclude that  pointer p points to the start of the object?

Yes, for that special case we indeed can do that.  I wonder if it's worth
doing though ;)  Care to adjust stmt_kills_ref_p accordingly and instrument it
to see how many times during bootstrap this triggers?

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

[rsandifo at gcc dot gnu.org]

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

--- Comment #10 from rsandifo at gcc dot gnu.org  
---
(In reply to Richard Biener from comment #9)
> I wonder if we should have two "phases" of simplifications, first
> aggressively canonicalize and later apply the optimizations.  We could
> key this on a new GIMPLE state, PROP_gimple_XXX (can't figure out a good
> acronym) and key patterns with it (like we have reload_completed on RTL).
> The pass deciding it's time to "lower" stuff (rather than canonicalize)
> would be cse_sincos (the pass doing the transform required
> for the testcase).  Note that some patters in that pass might be moved
> to match.pd instead so we can key PROP_gimple_XXX on the forwprop pass
> preceeding cse_sincos (so we can transform all stmts at once).

OK, thanks for the pointer.  I'm giving that a go now.

[Bug c++/67961] New: Incorrect type of meber of struct in error message

[other+gcc at meresinski dot eu]

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

Bug ID: 67961
   Summary: Incorrect type of meber of struct in error message
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: other+gcc at meresinski dot eu
  Target Milestone: ---

Created attachment 36506
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36506=edit
Test case

Compiling following code produces incorrect error message:

#include 

void foo(std::size_t ) {
f = 5;
}

struct A {
uint32_t val;
};

int main() {
A a, *aptr = 
foo(aptr->val);
return 0;
}

g++ --std=c++11 foo.cpp gives error message:
error: invalid initialization of non-const reference of type ‘std::size_t& {aka
long unsigned int&}’ from an rvalue of type ‘std::size_t {aka long unsigned
int}’
  foo(aptr->val);
^
where type of that rvalue variable is uint32_t not std::size_t. I think I
should add that system is 64bit so std::size_t has 64 bits.

[Bug libfortran/48958] Add runtime diagnostics for SIZE intrinsic function

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #1 from Dominique d'Humieres  ---
PR20406 has been closed as WONTFIX, any reason to keep this PR opened?

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

[vogt at linux dot vnet.ibm.com]

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

--- Comment #7 from Dominik Vogt  ---
Almost.  Note the strange bit numbering on s390.  The highest order bit in any
operation always has the number 0, and the lowest order bit has the highest
number.  So the 8-bit-move instruction "mvi" stores a byte into *a (bit 0-7),
then the 32-bit-and instruction "n" reads *a as a 32 bit value.  The bits 0-7
are the highest order bits of the result, so the value read is actually
0x03xx (bits 0-7 have the value 0x03, the rest is random data).

(Actually, I couldn't read this assembly code right without the help of a
debugger.)

   # r2 contains the address a at start of function
  larl  %r5,.L3 
  mvi  0(%r2),3# b-byte store of value 3 to the *(a + 0) 
   #   -> memory at a: 03 ** ** ** ** ** ** ** 
  l  %r1,.L4-.L3(%r5)  # 32-bit-load 0xff00 to r1 

  n  %r1,0(%r2)# 32-bit "and" of *(a + 0) and $1, result 
   # stored in r1 -> 0x0300 

  oill  %r1,5  # 64-bit "or" of r1 with the immediate value 
   # 0x 0005 
   # r1 -> 0x0305
  st  %r1,0(%r2)   # 32-bit store or r1 to a 
   #   -> memory at a: 03 00 00 05 ** ** ** ** 
  br  %r14 
.L3: 
.L4: 
  .long  -16777216

[Bug c/67967] [5.2/6 Regression] ICE in i386_pe_seh_unwind_emit

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
A totaly untested, bit kind of obvious patch:

--cut here--
Index: config/i386/winnt.c
===
--- config/i386/winnt.c (revision 228818)
+++ config/i386/winnt.c (working copy)
@@ -1128,11 +1128,11 @@ i386_pe_seh_unwind_emit (FILE *asm_out_file, rtx_i
   switch (REG_NOTE_KIND (note))
{
case REG_FRAME_RELATED_EXPR:
+   case REG_CFA_EXPRESSION:
  pat = XEXP (note, 0);
  goto found;

case REG_CFA_DEF_CFA:
-   case REG_CFA_EXPRESSION:
  /* Only emitted with DRAP, which we disable.  */
  gcc_unreachable ();
  break;
--cut here--

Can you please check the above patch?

[Bug c/67967] [5.2/6 Regression] ICE in i386_pe_seh_unwind_emit

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-10-14
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Ever confirmed|0   |1

--- Comment #5 from Uroš Bizjak  ---
Created attachment 36513
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36513=edit
Alternative patch that avoids REG_CFA_EXPRESSION for aligned moves

I'm testing the above patch.

[Bug c/67967] [5.2/6 Regression] ICE in i386_pe_seh_unwind_emit

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||tkoenig at gcc dot gnu.org
   Target Milestone|--- |5.3
Summary|ICE in  |[5.2/6 Regression] ICE in
   |i386_pe_seh_unwind_emit |i386_pe_seh_unwind_emit

[Bug c/67967] [5.2/6 Regression] ICE in i386_pe_seh_unwind_emit

[uros at gcc dot gnu.org]

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

--- Comment #7 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Oct 14 22:30:04 2015
New Revision: 228830

URL: https://gcc.gnu.org/viewcvs?rev=228830=gcc=rev
Log:
PR target/67967
* config/i386/i386.c (ix86_emit_save_reg_using_mov): Do not add
REG_CFA_EXPRESSION to aligned SSE stores.


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

[Bug fortran/47469] Check whether arrayfunc_assign_needs_temporary misses TBP/PPC attributes

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
Well, this PR has been rotting for more than four years and a half. I was only
pointing to the fact that the initial patch no longer applies.

If you know what to do, please do so. If not, I don't see the point to keep it
open for  the next decade.

[Bug boehm-gc/66848] boehm-gc fails test suite on x86_64-apple-darwin15

[howarth.at.gcc at gmail dot com]

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

--- Comment #13 from Jack Howarth  ---
(In reply to m...@gcc.gnu.org from comment #12)
> Is this just a partial import from upstream?  If so, I think we should just
> check it in and call the issue solved.

   No, the patch shown is an ugly hack of reducing the alignment to 2 (or 1)
which merely suppresses the breakage of boehm-gc (and thus gcj) under the Apple
Clang 7.0 compiled libunwind.dylib on darwin15. The newer upstream boehm-gc
uses the same alignments as gcc's boehm-gc but doesn't suffer the test suite
failures.
   All I can say at the moment is that the bug seems to be alignment related.
However it is unclear to me if the bug actually lies in gcc's current boehm-gc
or whether the breakage really lies in the Apple Clang 7.0 optimizations to the
system unwinder and that the newer upstream boehm-gc merely makes the bug go
latent. Apple claims these new optimizations to the unwinder are valid but I
really doubt that the bug has been truly examined in depth to validate that .

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

[vogt at linux dot vnet.ibm.com]

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

--- Comment #9 from Dominik Vogt  ---
>   or  %r1,%r2 # 32-bit or r1 := r1 | r2 -> 0xXX00

This should be

  or  %r1,%r2 # 32-bit or r1 := r1 | r2 -> 0xXXYY
  

Sorry for the typo.

[Bug c++/67969] [concepts] bug with overloaded function when using constraints

[ryan.burn at gmail dot com]

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

--- Comment #1 from ryan.burn at gmail dot com ---
Reduced further:

emplate 
class NumericArray {};

template 
constexpr bool match_numeric_array = false;
template 
constexpr bool
match_numeric_array> =
true;
template 
concept bool cpt_NumericArrayContainer() {
  return match_numeric_array;
}

template 
concept bool cpt_NumericArray() {
  return requires{requires cpt_NumericArrayContainer()};
}


template 
requires !cpt_NumericArray() auto func(int, X) {}

template 
requires cpt_NumericArray() auto func(int, X) {}

int main() {
  NumericArray v5;
  func(0, v5);
}

[Bug libfortran/48958] Add runtime diagnostics for SIZE intrinsic function

[anlauf at gmx dot de]

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

Harald Anlauf  changed:

   What|Removed |Added

 CC||anlauf at gmx dot de

--- Comment #2 from Harald Anlauf  ---
There are a few inquiry functions (SIZE, SHAPE, (L,U)BOUND) where such
a diagnostic might be useful.  It could be hidden behind one of the
-fcheck options.

However:

Depending on the implementation, it might work only for ALLOCATABLE,
where there is no undefined allocation status.  For a POINTER, the
status could be undefined, and it is not possible to discover this.
(It is even nice to be able to find out what the last size was
before deallocating the target of the pointer...)

NAG does the following:

% cat pr48958.f90
!integer, allocatable :: a(:)
integer, pointer :: a(:)
print *, size (a)
end
% nagfor -C pr48958.f90 && ./a.out 
NAG Fortran Compiler Release 5.3.1(907)
[NAG Fortran Compiler normal termination]
Runtime Error: pr48958.f90, line 3: Reference to undefined POINTER A
Program terminated by fatal error
Abort

Not sure whether there are other compilers which can handle this.

[Bug c++/67969] New: [concepts] bug with overloaded function when using constraints

[ryan.burn at gmail dot com]

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

Bug ID: 67969
   Summary: [concepts] bug with overloaded function when using
constraints
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

Created attachment 36514
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36514=edit
code

The attached code contains these two functions

template  requires !Q() auto func(vtype, X) {}  

template  requires Q() auto func(vtype, X) {} 

I get an ambiguous overload when trying to call it, but one should be disabled.

[Bug c/67967] [5.2/6 Regression] ICE in i386_pe_seh_unwind_emit

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Wed Oct 14 21:18:19 2015
New Revision: 228826

URL: https://gcc.gnu.org/viewcvs?rev=228826=gcc=rev
Log:
PR target/67967
* config/i386/i386.c (ix86_emit_save_reg_using_mov): Do not add
REG_CFA_EXPRESSION to aligned SSE stores.


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

[Bug rtl-optimization/67443] [5/6 regression] DSE removes required store instruction

[vogt at linux dot vnet.ibm.com]

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

--- Comment #8 from Dominik Vogt  ---
Snippet of the assembly code from the test program posted in comment 4:

good compiler:
==

# r1 is 0x**XX (XX = value to store in the f1 field)
# r3 is the target address (ps)
# r9 is 0x**YY (YY = value to store in the f2 field)

  l   %r2,.L25-.L24(%r13) # r2 := (uint32)0xff00
  stc %r1,0(%r3)  # 8-bit-store *(char *)ps := (r1 & 0xff)
  # -> ps: XX ** ** **
  lr  %r1,%r9 # 32-bit-load r1 := r9 -> r1 = 0x**YY
  n   %r2,0(%r3)  # 32-bit-and r2 := r2 & *(uint32 *)ps
  # -> r2 = 0xXX00
  nilh%r1,255 # 16-bit-and of bits 32-47 of r1 with 0x00ff,
i.e.
  # it zeroes the top 8 bits -> r1 = 0x00YY 
  or  %r1,%r2 # 32-bit or r1 := r1 | r2 -> 0xXX00
  st  %r1,0(%r3)  # 32-bit store *(uint32)ps := r1
  # -> ps: XX YY YY YY

.L24:
.L25:
  .long   -16777216

bad compiler:
=

The stc instruction is missing, so the resulting structure has a bad value in
f1.

--

This is the modified program I used for debugging, compiled with

  $ g++ -O2 -march=z900 -fPIC -std=gnu++11 t67443.cxx

---
#include  

__attribute__ ((noinline)) bool f(void *s) { return s ? true : false; } 
int *gt; 
struct s_t 
{ 
  unsigned f1: 8; 
  unsigned f2: 24; 
}; 
__attribute__ ((noinline)) 
bool foo(int a, int **pp, s_t **pps, void *s, int **x) 
{ 
  s_t *ps = *pps; 

  if (!f(x)) 
return false; 
  unsigned i = **pp; 
  volatile register long r2 __asm__ ("r2") = 1; 
  if (**pp >= 999 && **x < 77) 
{ 
  ps->f1 = **x; 
  ps->f2 = **pp; 
} 
  f(s); 
  int y; 
  do { y &= *gt; } while (y != 0); 
  __asm__ __volatile__ ("" : : : "memory", "r2","r3","r4","r5"); 
  int z; 
  do { z &= *gt; } while (z != 0); 
  return i && x && ps && s; 
} 

int main(void) 
{ 
  int i1 = 999; 
  int *pi1 =  
  s_t st; 
  s_t *pst =  
  int x = 55; 
  int *px =  
  int t = 0; 

  gt =  
  foo(1, , , 0, ); 
  fprintf(stderr, "f1 %u, f2 %u\n", (unsigned int)st.f1, (unsigned int)st.f2); 
} 
---

This prints "55 999" for the good compiler (correct) and "255 999" for the bad
compiler (wrong).

[Bug tree-optimization/67955] tree-dse does not use pointer info

[vries at gcc dot gnu.org]

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

--- Comment #4 from vries at gcc dot gnu.org ---
Created attachment 36507
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36507=edit
Tentative patch

(In reply to Richard Biener from comment #3)
> (In reply to vries from comment #2)
> > I wonder though: if we have a store '*p = 0', and the size of the store is
> > the same as the size of the pointed-to object of pointer p, can't we
> > conclude that  pointer p points to the start of the object?
> 
> Yes, for that special case we indeed can do that.  I wonder if it's worth
> doing though ;)

I ran into this while working on the oacc kernels support. But indeed, I'm not
sure how useful this is going to be in general.

> Care to adjust stmt_kills_ref_p accordingly

Done in this tentative patch.

> and instrument it to see how many times during bootstrap this triggers?

For now, I'll do a bootstrap and reg-test to make sure it doesn't break
anything.

[Bug c++/67962] New: Optimization opportunity with conditional swap

[morwenn29 at hotmail dot fr]

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

Bug ID: 67962
   Summary: Optimization opportunity with conditional swap
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: morwenn29 at hotmail dot fr
  Target Milestone: ---

If have some algorithms that use an extensive number of conditional swaps like
this (a few hundreds I guess):

if (y < x)
{
std::swap(x, y);
}

I thought that such a construct could be optimized by the compiler, but it
appears that the following function is more performant with integers most of
the time:

void swap_if(int& x, int& y)
{
int dx = x;
int dy = y;
int tmp = x = std::min(dx, dy);
y ^= dx ^ tmp;
}

Would it be possible for g++ to recognize this kind of construct and optimize
it, at least for integer types? Reordering two values seems like something
common enough so that optimizing it could also benefit existing code.

As a side note, I hope that Bugzilla is he right place for this kind of
request. Sorry if it isn't.

[Bug tree-optimization/67962] Optimization opportunity with conditional swap to two MIN/MAX in phiopt

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-14
  Component|c++ |tree-optimization
Summary|Optimization opportunity|Optimization opportunity
   |with conditional swap   |with conditional swap to
   ||two MIN/MAX in phiopt
 Ever confirmed|0   |1
   Severity|minor   |enhancement

--- Comment #1 from Richard Biener  ---
We miss the opportunity to turn

  :
  if (y_5(D) < x_6(D))
goto ;
  else
goto ;

  :

  :
  # y_4 = PHI 
  # x_2 = PHI 

into

   y_4 = MAX (x_6, y_5);
   x_2 = MIN (x_6, y_5);

and further optimize MINMAX (ISTR that was suggested elsewhere).  phiopt only
considers a single min/max operation.

Now the question is whether the transform would be profitable in isolation.

[Bug fortran/47469] Check whether arrayfunc_assign_needs_temporary misses TBP/PPC attributes

[pault at gcc dot gnu.org]

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

--- Comment #2 from Paul Thomas  ---
(In reply to Dominique d'Humieres from comment #1)
> On trunk (6.0 r228753) this has been changed to
> 
>   /* Functions returning pointers or allocatables need temporaries.  */
>   c = expr2->value.function.esym
>   ? (expr2->value.function.esym->attr.pointer
>  || expr2->value.function.esym->attr.allocatable)
>   : (expr2->symtree->n.sym->attr.pointer
>  || expr2->symtree->n.sym->attr.allocatable);
>   if (c)
> return true;
> 
> Any point to keep this PR opened?

Tobias' version is prettier! Does it apply without regressions?

Cheers

Paul

[Bug tree-optimization/67955] tree-dse does not use pointer info

[vries at gcc dot gnu.org]

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

vries at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #36507|0   |1
is obsolete||

--- Comment #5 from vries at gcc dot gnu.org ---
Created attachment 36508
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36508=edit
Updated tentative patch

[Bug target/67963] New: -march=lakemont generates x87 instructions

[hjl.tools at gmail dot com]

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

Bug ID: 67963
   Summary: -march=lakemont generates x87 instructions
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: julia.koval at intel dot com, ubizjak at gmail dot com
  Target Milestone: ---

[hjl@gnu-6 gcc]$ cat x.c
float
foo (void)
{
  return 0;
}
[hjl@gnu-6 gcc]$ ./xgcc -B./ -march=lakemont -S x.c -m32
[hjl@gnu-6 gcc]$ cat x.s
.file   "x.c"
.text
.globl  foo
.type   foo, @function
foo:
.LFB0:
.cfi_startproc
pushl   %ebp
.cfi_def_cfa_offset 8
.cfi_offset 5, -8
movl%esp, %ebp
.cfi_def_cfa_register 5
fldz
popl%ebp
.cfi_restore 5
.cfi_def_cfa 4, 4
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 6.0.0 20151006 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 gcc]$ 

We should issue an error if -march=lakemont is used without -miacmu.

[Bug fortran/48997] Don't use allocatable arrays for function elimination

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #3 from Thomas Koenig  ---
Hi Dominique,

I am currently not working on this.

It is worth keeping around for partial implementation at least, if I can find
the time and/or somebody else starts working on the front end passes.

[Bug target/67963] -march=lakemont generates x87 instructions

[hjl.tools at gmail dot com]

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

--- Comment #1 from H.J. Lu  ---
(In reply to H.J. Lu from comment #0)
> We should issue an error if -march=lakemont is used without -miacmu.

We should issue an error if -march=lakemont is used without -mno-80387,
not without -miamcu.

[Bug c/67964] New: [4.9/5/6 Regression] Multiple attributes wrongly accepted without commas

[jsm28 at gcc dot gnu.org]

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

Bug ID: 67964
   Summary: [4.9/5/6 Regression] Multiple attributes wrongly
accepted without commas
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Keywords: accepts-invalid
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

GCC wrongly accepts:

extern int foo (void) __attribute__ ((const const));

Multiple attributes inside a single __attribute__ (()) should be required to be
separated by commas, so ((const, const)).  Bug introduced in 4.1 with the new C
parser.

[Bug target/67963] -march=lakemont generates x87 instructions

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
(In reply to H.J. Lu from comment #1)
> (In reply to H.J. Lu from comment #0)
> > We should issue an error if -march=lakemont is used without -miacmu.
> 
> We should issue an error if -march=lakemont is used without -mno-80387,
> not without -miamcu.

-march=lakemont should imply -mno-80387.

[Bug tree-optimization/67915] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Fixed.

[Bug c/67964] [4.9/5/6 Regression] Multiple attributes wrongly accepted without commas

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |4.9.4

[Bug c/67964] [4.9/5/6 Regression] Multiple attributes wrongly accepted without commas

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-10-14
   Target Milestone|4.9.4   |6.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  No need to fix on branches.

[Bug fortran/66534] Compilation error of gfortran building on YDL6.2

[textdirected at gmail dot com]

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

HEMMI, Shigeru  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX

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

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Wed Oct 14 12:54:03 2015
New Revision: 228809

URL: https://gcc.gnu.org/viewcvs?rev=228809=gcc=rev
Log:
PR tree-optimization/67815
* tree-ssa-reassoc.c (attempt_builtin_copysign): New function.
(reassociate_bb): Call it.

* gcc.dg/tree-ssa/reassoc-39.c: New test.
* gcc.dg/tree-ssa/reassoc-40.c: New test.
* gcc.dg/tree-ssa/reassoc-41.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-39.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-40.c
trunk/gcc/testsuite/gcc.dg/tree-ssa/reassoc-41.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-reassoc.c

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

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Done for GCC 6.

[Bug tree-optimization/67915] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Wed Oct 14 12:59:15 2015
New Revision: 228810

URL: https://gcc.gnu.org/viewcvs?rev=228810=gcc=rev
Log:
2015-10-14  Richard Biener  

PR tree-optimization/67915
* match.pd: Handle comparisons of addresses of STRING_CSTs.
* gimplify.c (gimplify_cond_expr): Fold the GIMPLE conds we build.
* tree-cfgcleanup.c (cleanup_control_expr_graph): Remove GENERIC
stmt folding in favor of GIMPLE one.

* gcc.dg/torture/pr67915.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr67915.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimplify.c
trunk/gcc/match.pd
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-cfgcleanup.c

[Bug tree-optimization/67949] Regression in GCC-6.0.0's optimizer

[ishiura-compiler at ml dot kwansei.ac.jp]

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

--- Comment #3 from Ishiura Lab Compiler Team  ---
We are very sorry that somehow we failed to do final check with the latest
trunk before submitting the report.

[Bug c++/67970] New: [concepts] variable template bug

[ryan.burn at gmail dot com]

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

Bug ID: 67970
   Summary: [concepts] variable template bug
   Product: gcc
   Version: unknown
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 should compile, but I get this error:

bug.cpp: In function ‘int main()’:
bug.cpp:29:13: error: the value of ‘match_numeric_array’ is not usable in a
constant expression
   func(0, v5);
 ^
bug.cpp:8:5: note: ‘match_numeric_array’ used in its own initializer
 match_numeric_array =
 ^
bug.cpp:29:13: error: ‘’ is not a constant expression
   func(0, v5);

///
template 
class NumericArray {};

template 
constexpr bool match_numeric_array = false;
template 
constexpr bool
match_numeric_array =
true;
template 
concept bool cpt_NumericArrayContainer() {
  return match_numeric_array;
}

template 
concept bool cpt_NumericArray() {
  return requires{requires cpt_NumericArrayContainer()};
}


template 
requires !cpt_NumericArray() auto func(int, X) {}

template 
requires cpt_NumericArray() auto func(int, X) {}

int main() {
  NumericArray v5;
  func(0, v5);
}
///

[Bug c++/67965] New: gcc (incorrectly) requires template keyword in non-dependent expression

[vanyacpp at gmail dot com]

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

Bug ID: 67965
   Summary: gcc (incorrectly) requires template keyword in
non-dependent expression
   Product: gcc
   Version: 5.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vanyacpp at gmail dot com
  Target Milestone: ---

I believe that in the following example "template" keyword is not required as
expression "f()" is not type dependent. It's a call to a function in current
instantiation and this can not be altered by any specialization.

class B
{
public:
template
T f() {
return T{};
}
};

template
class C
{
public:
B f()
{
return{};
}

C()
{
f().template f(); // here (!)
}
};

int main()
{
C p;
}

[Bug c++/67961] Incorrect type of meber of struct in error message

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
The diagnostic is correct.

Trying to pass uint32_t to a function taking size_t causes a conversion,
creating a temporary (i.e. rvalue) size_t, but a non-const reference cannot
bind to a temporary.

[Bug fortran/66534] Compilation error of gfortran building on YDL6.2

[textdirected at gmail dot com]

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

--- Comment #6 from HEMMI, Shigeru  ---
Thanks for the reply.

> Did you asked yellow dog linux for help?
No, YDL seems stopping maintenance/developing.

> IMO it would be more honest to close this PR as WONTFIX.
I closed this thread at your suggestion.

> Well, gfortran is built on a quite broad range of platforms without the 
> problem you report. 

My work is very much relying on gfortran.
I am using prebuilte gfortran binary (mingw-w64) mainly on Windows machine.
Almost all things going well.

Since gcc-5.2.0 gcc/g++ are built without problem on my outdated YDL machine,
so I expected gfortran is also well built on my YDL machine, but not.

Anyway, thank you very much for developing gfortran.

Best regards,