[Bug libfortran/67585] Retry system calls failing with EINTR

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from Janne Blomqvist  ---
(In reply to Dominique d'Humieres from comment #1)
> > libgfortran should retry system calls failing with EINTR, with the exception
> > of close(). Rationale and further reading e.g. at
> >  https://www.python.org/dev/peps/pep-0475/
> 
> I don't understand what is expected.

Don't worry, I know what needs to be done. I don't have time right now, so I
filed this PR so I don't forget about it. And of course, if somebody else gets
it done before I do it myself, all the better..

> The only place where EINTR is used is
> in raw_write file io/unix.c with a comment
> 
>   /* We must write in a loop since some systems don't restart system
>  calls in case of a signal.  */
> 
> For raw_read, the comment is
> 
>   /* For read we can't do I/O in a loop like raw_write does, because
>  that will break applications that wait for interactive I/O.  */

If you look back in the commit logs, I recall I wrote those comments myself..
FWIW, raw_write does it correctly, and while raw_read can't loop due to how
terminals handle short reads, it should still be fixed to handle EINTR. And
then there's all the other syscalls that can fail with EINTR.

[Bug bootstrap/67598] New: [6 Regression] Target powerpc-e500v2-linux-gnuspe failed to bootstrap

[asolokha at gmx dot com]

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

Bug ID: 67598
   Summary: [6 Regression] Target powerpc-e500v2-linux-gnuspe
failed to bootstrap
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

6.0.0-alpha20150913 snapshot fails to build for powerpc-e500v2-linux-gnuspe w/
the following:

build/genoutput gcc-6-20150913/gcc/common.md
gcc-6-20150913/gcc/config/rs6000/rs6000.md \
  insn-conditions.md > tmp-output.c
gcc-6-20150913/gcc/config/rs6000/vsx.md:1299: error: undefined machine-specific
constraint at this point: "Sr>,?"
gcc-6-20150913/gcc/config/rs6000/vsx.md:1299: note:  in operand 0
gcc-6-20150913/gcc/config/rs6000/vsx.md:1299: error: undefined machine-specific
constraint at this point: "Sa>"
gcc-6-20150913/gcc/config/rs6000/vsx.md:1299: note:  in operand 0
gcc-6-20150913/gcc/config/rs6000/vsx.md:1299: error: undefined machine-specific
constraint at this point: "Sr>,"
gcc-6-20150913/gcc/config/rs6000/vsx.md:1299: note:  in operand 1
gcc-6-20150913/gcc/config/rs6000/vsx.md:1299: error: undefined machine-specific
constraint at this point: "Sa>"
gcc-6-20150913/gcc/config/rs6000/vsx.md:1299: note:  in operand 1
gcc-6-20150913/gcc/config/rs6000/vsx.md:1299: error: undefined machine-specific
constraint at this point: "Sr>,"
gcc-6-20150913/gcc/config/rs6000/vsx.md:1299: note:  in operand 2
gcc-6-20150913/gcc/config/rs6000/vsx.md:1299: error: undefined machine-specific
constraint at this point: "Sa>"
gcc-6-20150913/gcc/config/rs6000/vsx.md:1299: note:  in operand 2
gcc-6-20150913/gcc/config/rs6000/vsx.md:1299: error: undefined machine-specific
constraint at this point: "Sr>,"
gcc-6-20150913/gcc/config/rs6000/vsx.md:1299: note:  in operand 3
gcc-6-20150913/gcc/config/rs6000/vsx.md:1299: error: undefined machine-specific
constraint at this point: "Sa>"
gcc-6-20150913/gcc/config/rs6000/vsx.md:1299: note:  in operand 3
gcc-6-20150913/gcc/config/rs6000/vsx.md:1310: error: undefined machine-specific
constraint at this point: "Sr>,?"
gcc-6-20150913/gcc/config/rs6000/vsx.md:1310: note:  in operand 0
gcc-6-20150913/gcc/config/rs6000/vsx.md:1310: error: undefined machine-specific
constraint at this point: "Sa>"
gcc-6-20150913/gcc/config/rs6000/vsx.md:1310: note:  in operand 0
gcc-6-20150913/gcc/config/rs6000/vsx.md:1310: error: undefined machine-specific
constraint at this point: "Sr>,"
gcc-6-20150913/gcc/config/rs6000/vsx.md:1310: note:  in operand 1
gcc-6-20150913/gcc/config/rs6000/vsx.md:1310: error: undefined machine-specific
constraint at this point: "Sa>"
gcc-6-20150913/gcc/config/rs6000/vsx.md:1310: note:  in operand 1
gcc-6-20150913/gcc/config/rs6000/vsx.md:1310: error: undefined machine-specific
constraint at this point: "Sr>,"
gcc-6-20150913/gcc/config/rs6000/vsx.md:1310: note:  in operand 2
gcc-6-20150913/gcc/config/rs6000/vsx.md:1310: error: undefined machine-specific
constraint at this point: "Sa>"
gcc-6-20150913/gcc/config/rs6000/vsx.md:1310: note:  in operand 2
gcc-6-20150913/gcc/config/rs6000/vsx.md:1310: error: undefined machine-specific
constraint at this point: "Sr>,"
gcc-6-20150913/gcc/config/rs6000/vsx.md:1310: note:  in operand 3
gcc-6-20150913/gcc/config/rs6000/vsx.md:1310: error: undefined machine-specific
constraint at this point: "Sa>"
gcc-6-20150913/gcc/config/rs6000/vsx.md:1310: note:  in operand 3
gcc-6-20150913/gcc/config/rs6000/vsx.md:2279: error: undefined machine-specific
constraint at this point: "Sa>"
gcc-6-20150913/gcc/config/rs6000/vsx.md:2279: note:  in operand 0
gcc-6-20150913/gcc/config/rs6000/vsx.md:2279: error: undefined machine-specific
constraint at this point: "Sa>"
gcc-6-20150913/gcc/config/rs6000/vsx.md:2279: note:  in operand 1
gcc-6-20150913/gcc/config/rs6000/vsx.md:2279: error: undefined machine-specific
constraint at this point: "Sa>"
gcc-6-20150913/gcc/config/rs6000/vsx.md:2279: note:  in operand 2
Makefile:2156: recipe for target 's-output' failed

I noticed that much VSX-related work have been done in this release cycle,
according to ChangeLog. The last versions that worked correctly for me were
5.1.0 and 6.0.0-alpha20150412 (of 5.1 branch and trunk, respectively), and
after that I've stopped doing my own weekly builds. I still have to find out
when the issue have started showing up, given that I now have half a year wide
window.

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

[kkojima at gcc dot gnu.org]

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

--- Comment #5 from Kazumoto Kojima  ---
(In reply to Oleg Endo from comment #4)
> Maybe FPSCR_STAT_REG should be in the clobber list, too?  Otherwise stores
> of FP exception bits etc (get_fpscr builtin) could be wrongly CSE'd across
> function calls... However, I don't know if this is a problem at the moment.

I'm not sure whether it's a problem or not ATM too.  The original
issue happens with the aggressive allocation by LRA.
If the scenario for FPSCR_MODES_REG is real, it could be seen
with the old RA already.

[Bug bootstrap/67597] New: [6 Regression] profiledbootstrap failure on ppc64le

[trippels at gcc dot gnu.org]

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

Bug ID: 67597
   Summary: [6 Regression] profiledbootstrap failure on ppc64le
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: trippels at gcc dot gnu.org
  Target Milestone: ---
  Host: powerpc64le-unknown-linux-gnu
Target: powerpc64le-unknown-linux-gnu
 Build: powerpc64le-unknown-linux-gnu

With:
 % ../gcc/configure --with-cpu=power8 --disable-libstdcxx-pch --disable-libvtv
--disable-libitm --disable-libcilkrts --disable-libssp --disable-libgomp
--disable-werror --enable-multilib --enable-languages=c,c++
 % make -j120 profiledbootstrap

I get during stageprofile (with the instrumented compiler):

trippels@gcc2-power8 libgcc % /home/trippels/gcc_build_dir_/./gcc/xgcc
-B/home/trippels/gcc_build_dir_/./gcc/
-B/usr/local/powerpc64le-unknown-linux-gnu/bin/
-B/usr/local/powerpc64le-unknown-linux-gnu/lib/ -isystem
/usr/local/powerpc64le-unknown-linux-gnu/include -isystem
/usr/local/powerpc64le-unknown-linux-gnu/sys-include-g -O2 -O2  -g -O2
-DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition  -isystem
./include   -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector   -fPIC -mlong-double-128
-mno-minimal-toc -I. -I. -I../.././gcc -I../../../gcc/libgcc
-I../../../gcc/libgcc/. -I../../../gcc/libgcc/../gcc
-I../../../gcc/libgcc/../include -I../../../gcc/libgcc/../libdecnumber/dpd
-I../../../gcc/libgcc/../libdecnumber -DHAVE_CC_TLS  -o unwind-dw2.o -MT
unwind-dw2.o -MD -MP -MF unwind-dw2.dep -fexceptions -c
../../../gcc/libgcc/unwind-dw2.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from ../../../gcc/libgcc/unwind-dw2.c:1694:0:
../../../gcc/libgcc/unwind.inc: In function ‘_Unwind_RaiseException’:
../../../gcc/libgcc/unwind.inc:136:1: internal compiler error: in
dwarf2out_frame_debug_expr, at dwarf2cfi.c:1901
 }
 ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c++/67595] concepts code causes segfault

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

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

--- Comment #1 from Markus Trippelsdorf  ---
Confirmed. It is a stack overflow.

Program received signal SIGSEGV, Segmentation fault.
[Switching to process 26351]
0x0078dd35 in cp_build_qualified_type_real
(type=type@entry=0x77296930, type_quals=type_quals@entry=0,
complain=complain@entry=3) at ../../gcc/gcc/cp/tree.c:1028
1028{
(gdb) bt
#0  0x0078dd35 in cp_build_qualified_type_real
(type=type@entry=0x77296930, type_quals=type_quals@entry=0,
complain=complain@entry=3)
at ../../gcc/gcc/cp/tree.c:1028
#1  0x005c859f in strip_top_quals (t=0x77296930) at
../../gcc/gcc/cp/call.c:1085
#2  standard_conversion (to=to@entry=0x77296930,
from=from@entry=0x770e01f8, expr=expr@entry=0x770dce70,
c_cast_p=c_cast_p@entry=false, flags=flags@entry=5)
at ../../gcc/gcc/cp/call.c:1109
#3  0x005d3124 in implicit_conversion (to=to@entry=0x77296930,
from=from@entry=0x770e01f8, expr=expr@entry=0x770dce70,
c_cast_p=c_cast_p@entry=false, 
flags=5, complain=complain@entry=0) at ../../gcc/gcc/cp/call.c:1803
#4  0x005d5633 in add_function_candidate
(candidates=candidates@entry=0x7bfff2e8, fn=fn@entry=0x7721c0e0,
ctype=ctype@entry=0x0, first_arg=, 
args=0x7fffdbc8, access_path=access_path@entry=0x0,
conversion_path=0x0, flags=, complain=0) at
../../gcc/gcc/cp/call.c:2120
#5  0x005d6d38 in add_candidates (fns=0x7700a160,
fns@entry=0x7700a360, first_arg=first_arg@entry=0x0,
args=args@entry=0x7fffdbc8, 
return_type=return_type@entry=0x0, explicit_targs=0x0, template_only=false,
conversion_path=0x0, access_path=0x0, flags=1, candidates=0x7bfff2e8,
complain=0)
at ../../gcc/gcc/cp/call.c:5326
#6  0x005d9374 in perform_overload_resolution
(fn=fn@entry=0x7700a360, args=0x7fffdbc8,
candidates=candidates@entry=0x7bfff2e8, 
any_viable_p=any_viable_p@entry=0x7bfff2e7, complain=complain@entry=0)
at ../../gcc/gcc/cp/call.c:4012
#7  0x005dbd1d in build_operator_new_call
(fnname=fnname@entry=0x770f4aa8, args=args@entry=0x7bfff578,
size=size@entry=0x7bfff398, 
cookie_size=cookie_size@entry=0x7bfff3a0,
size_check=size_check@entry=0x0, fn=fn@entry=0x7bfff450, complain=0) at
../../gcc/gcc/cp/call.c:4198
#8  0x007482f9 in build_new_1
(placement=placement@entry=0x7bfff578, type=,
type@entry=0x758a13f0, nelts=, nelts@entry=0x0, 
init=init@entry=0x7bfff580,
globally_qualified_p=globally_qualified_p@entry=false,
complain=complain@entry=0) at ../../gcc/gcc/cp/init.c:2636
#9  0x00749b83 in build_new (placement=placement@entry=0x7bfff578,
type=type@entry=0x758a13f0, nelts=,
init=init@entry=0x7bfff580, 
use_global_new=0, complain=complain@entry=0) at
../../gcc/gcc/cp/init.c:3098
#10 0x00645ed4 in tsubst_copy_and_build (t=t@entry=0x7fffdaffc460,
args=args@entry=0x7fffdaffbcc0, complain=, complain@entry=0, 
in_decl=in_decl@entry=0x0, function_p=function_p@entry=false,
integral_constant_expression_p=integral_constant_expression_p@entry=false) at
../../gcc/gcc/cp/pt.c:15628
#11 0x00636ce0 in tsubst_expr (t=0x7fffdaffc460,
args=args@entry=0x7fffdaffbcc0, complain=complain@entry=0,
in_decl=in_decl@entry=0x0, 
integral_constant_expression_p=integral_constant_expression_p@entry=false)
at ../../gcc/gcc/cp/pt.c:15044
#12 0x007fb67c in (anonymous namespace)::satisfy_expression_constraint
(complain=0, in_decl=0x0, args=0x7fffdaffbcc0, t=0x7fffdaffbfc0)
at ../../gcc/gcc/cp/constraint.cc:1727
#13 (anonymous namespace)::satisfy_constraint_1 (t=0x7fffdaffbfc0,
args=args@entry=0x7fffdaffbcc0, in_decl=0x0, complain=0) at
../../gcc/gcc/cp/constraint.cc:1901
#14 0x007fb866 in (anonymous namespace)::satisfy_conjunction
(complain=0, in_decl=0x0, args=0x7fffdaffbcc0, t=0x7fffdaffdf50) at
../../gcc/gcc/cp/constraint.cc:1856
#15 (anonymous namespace)::satisfy_constraint_1 (t=0x7fffdaffdf50,
args=args@entry=0x7fffdaffbcc0, in_decl=0x0, complain=0) at
../../gcc/gcc/cp/constraint.cc:1919
#16 0x007fb866 in (anonymous namespace)::satisfy_conjunction
(complain=0, in_decl=0x0, args=0x7fffdaffbcc0, t=0x7fffdaffdf78) at
../../gcc/gcc/cp/constraint.cc:1856
#17 (anonymous namespace)::satisfy_constraint_1 (t=0x7fffdaffdf78,
args=args@entry=0x7fffdaffbcc0, in_decl=0x0, complain=0) at
../../gcc/gcc/cp/constraint.cc:1919
#18 0x007fb866 in (anonymous namespace)::satisfy_conjunction
(complain=0, in_decl=0x0, args=0x7fffdaffbcc0, t=0x7fffdaffdfc8) at
../..

[Bug c++/67596] New: /usr/include/c++/4.7/bits/stl_list.h error

[thien.pham3i2 at gmail dot com]

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

Bug ID: 67596
   Summary: /usr/include/c++/4.7/bits/stl_list.h error
   Product: gcc
   Version: 4.4.7
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thien.pham3i2 at gmail dot com
  Target Milestone: ---

Created attachment 36340
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36340&action=edit
the error

Dear all,
I compiled the project but the project is error with error message:

[root@localhost Impinj_ltk]# make x86
mkdir -p ./bin
g++ \
-m32 -Wno-write-strings \
-Llib \
-Iinclude \
speedway_embedded_example.cpp \
-lltkcpp_x86 -lltkcppimpinj_x86 -lxml2_x86 \
-o bin/speedwayr_x86
lib/libltkcpp_x86.a(ltkcpp_connection_x86.o): In function
`std::list
>::_M_erase(std::_List_iterator)':
/usr/include/c++/4.7/bits/stl_list.h:1542: undefined reference to
`std::__detail::_List_node_base::_M_unhook()'
lib/libltkcpp_x86.a(ltkcpp_connection_x86.o): In function
`std::list
>::_M_insert(std::_List_iterator, LLRP::CMessage* const&)':
/usr/include/c++/4.7/bits/stl_list.h:1526: undefined reference to
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
lib/libltkcpp_x86.a(ltkcpp_typeregistry_x86.o): In function
`std::list >::_M_insert(std::_List_iterator,
LLRP::CTypeDescriptor const* const&)':
/usr/include/c++/4.7/bits/stl_list.h:1526: undefined reference to
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
lib/libltkcpp_x86.a(ltkcpp_genout_x86.o): In function
`std::list
>::_M_insert(std::_List_iterator, LLRP::CParameter*
const&)':
/usr/include/c++/4.7/bits/stl_list.h:1526: undefined reference to
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
lib/libltkcpp_x86.a(ltkcpp_genout_x86.o): In function
`std::list
>::_M_insert(std::_List_iterator, LLRP::CROSpec* const&)':
/usr/include/c++/4.7/bits/stl_list.h:1526: undefined reference to
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
lib/libltkcpp_x86.a(ltkcpp_genout_x86.o): In function
`std::list
>::_M_insert(std::_List_iterator, LLRP::CAccessSpec*
const&)':
/usr/include/c++/4.7/bits/stl_list.h:1526: undefined reference to
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
lib/libltkcpp_x86.a(ltkcpp_genout_x86.o):/usr/include/c++/4.7/bits/stl_list.h:1526:
more undefined references to
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
follow
lib/libltkcpp_x86.a(ltkcpp_element_x86.o): In function
`std::list
>::_M_erase(std::_List_iterator)':
/usr/include/c++/4.7/bits/stl_list.h:1542: undefined reference to
`std::__detail::_List_node_base::_M_unhook()'
lib/libltkcppimpinj_x86.a(impinj_ltkcpp_genout_x86.o): In function
`std::list
>::_M_insert(std::_List_iterator,
LLRP::CImpinjArrayVersion* const&)':
/usr/include/c++/4.7/bits/stl_list.h:1526: undefined reference to
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
lib/libltkcppimpinj_x86.a(impinj_ltkcpp_genout_x86.o): In function
`std::list
>::_M_insert(std::_List_iterator, LLRP::CC1G2Read* const&)':
/usr/include/c++/4.7/bits/stl_list.h:1526: undefined reference to
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
lib/libltkcppimpinj_x86.a(impinj_ltkcpp_genout_x86.o): In function
`std::list
>::_M_insert(std::_List_iterator,
LLRP::CImpinjTransitionZone* const&)':
/usr/include/c++/4.7/bits/stl_list.h:1526: undefined reference to
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
lib/libltkcppimpinj_x86.a(impinj_ltkcpp_genout_x86.o): In function
`std::list
>::_M_insert(std::_List_iterator, LLRP::CEPCData* const&)':
/usr/include/c++/4.7/bits/stl_list.h:1526: undefined reference to
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
lib/libltkcppimpinj_x86.a(impinj_ltkcpp_genout_x86.o): In function
`std::list
>::_M_insert(std::_List_iterator,
LLRP::CImpinjAntennaPolarizationCapability* const&)':
/usr/include/c++/4.7/bits/stl_list.h:1526: undefined reference to
`std::__detail::_List_node_base::_M_hook(std::__detail::_List_node_base*)'
collect2: ld returned 1 exit status
make: *** [bin/speedwayr_x86] Error 1

Could someone please help me fix this error ?
thanks and regards
Thieen

[Bug preprocessor/58397] Please add host_hooks for NetBSD to make precompiled headers work

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-16
   Host||*-*-netbsd*
 Ever confirmed|0   |1

--- Comment #4 from Jonathan Wakely  ---
Thanks for the patches. Please send them to gcc-patches for review rather than
attaching them here, as documented at:

https://gcc.gnu.org/contribute.html#patches

[Bug c++/67595] New: concepts code causes segfault

[ryan.burn at gmail dot com]

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

Bug ID: 67595
   Summary: concepts code causes segfault
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ryan.burn at gmail dot com
  Target Milestone: ---

Created attachment 36339
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36339&action=edit
code that reproduces segfault

The attached code causes a segfault with the latest version of gcc

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

result of compiling is:
g++: internal compiler error: Segmentation fault (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug libstdc++/65806] NetBSD's expects __STDC_LIMIT_MACROS and __STDC_CONSTANT_MACROS

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-16
 Ever confirmed|0   |1

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> Hmm, why doesn't GCC's own stdint.h solve this?

Because gcc/Makefile has:

# How to handle .
USE_GCC_STDINT = none

which is because gcc/config.gcc never sets it. Easy to fix ...

[Bug c++/67594] Bug on partial specialization? Incomplete type.

[vincent.lextrait at gmail dot com]

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

--- Comment #5 from Vincent  ---
Thanks Jonathan to take the time. I have to reread the manual... Apologies for
using bandwidth.

[Bug c++/67594] Bug on partial specialization? Incomplete type.

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
The primary template defines the default argument for the second parameter.

The C partial specialization is irrelevant, it isn't used.

The C specialization is identical to C because it uses the
default argument, so if you write it like that then it should be obvious the
code is wrong:

template  class C{};

template  class C{};   // unused

template <> class C : public C {};
  ^^^  ^^^

The base class matches the C specialization not the C
partial specialization because C is more specialized.

So the base class is the same type, and of course a type cannot derive from
itself.

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

[olegendo at gcc dot gnu.org]

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

--- Comment #4 from Oleg Endo  ---
Maybe FPSCR_STAT_REG should be in the clobber list, too?  Otherwise stores of
FP exception bits etc (get_fpscr builtin) could be wrongly CSE'd across
function calls... However, I don't know if this is a problem at the moment.

[Bug c++/67594] Bug on partial specialization? Incomplete type.

[vincent.lextrait at gmail dot com]

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

--- Comment #3 from Vincent  ---
Oh, I see. So the first partial specialization is not "preferred" over the
general template?

(In reply to Jonathan Wakely from comment #2)
> The partial specialization C uses the default template argument, so
> is identical to C, so you have tried to make it its own base class.

[Bug c++/67594] Bug on partial specialization? Incomplete type.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
The partial specialization C uses the default template argument, so is
identical to C, so you have tried to make it its own base class.

[Bug c++/67593] Partial specialization: "Template argument involves template parameters"

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-15
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
It still fails even like this:

template 
struct outer
{
static constexpr T t{};
template  struct inner {};
template  struct inner {};
};

[Bug c++/67594] Bug on partial specialization? Incomplete type.

[vincent.lextrait at gmail dot com]

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

--- Comment #1 from Vincent  ---
I've changed gcc version to 5.2, as 5.2 issues the same error.

[Bug bootstrap/67587] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
Ugh, never mind that, somehow I had the patch on there.  Either way,
confirmed again, and I'm on it.

[Bug c++/67594] New: Bug on partial specialization? Incomplete type.

[vincent.lextrait at gmail dot com]

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

Bug ID: 67594
   Summary: Bug on partial specialization? Incomplete type.
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent.lextrait at gmail dot com
  Target Milestone: ---

# 1 "foo.cpp"

# 1 ""

# 1 ""

# 1 "foo.cpp"

template  class C{};

template  class C{};

template <> class C: public C{};

C c;

When compiled with:

/usr/local/bin/gcc-4.9 -c foo.cpp

Issues:

foo.cpp:3:36: error: invalid use of incomplete type 'class C'
 template <> class C: public C{};
^
foo.cpp:3:19: error: declaration of 'class C'
 template <> class C: public C{};
   ^

I do not see anything incomplete there.
gcc version 4.9.2:

Using built-in specs.

COLLECT_GCC=/usr/local/bin/gcc-4.9

COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/4.9.2_1/libexec/gcc/x86_64-apple-darwin14.3.0/4.9.2/lto-wrapper

Target: x86_64-apple-darwin14.3.0

Configured with: ../configure --build=x86_64-apple-darwin14.3.0
--prefix=/usr/local/Cellar/gcc/4.9.2_1
--libdir=/usr/local/Cellar/gcc/4.9.2_1/lib/gcc/4.9
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-4.9
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-cloog=/usr/local/opt/cloog
--with-isl=/usr/local/opt/isl --with-system-zlib --enable-libstdcxx-time=yes
--enable-stage1-checking --enable-checking=release --enable-lto
--with-build-config=bootstrap-debug --disable-werror
--with-pkgversion='Homebrew gcc 4.9.2_1'
--with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin
--disable-nls --enable-multilib

Thread model: posix

gcc version 4.9.2 (Homebrew gcc 4.9.2_1)

[Bug bootstrap/67587] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

[segher at gcc dot gnu.org]

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

--- Comment #11 from Segher Boessenkool  ---
I can reproduce the ICE, with the testcase from #c10, with a compiler
built from trunk at 2015-09-10, so before the accused patch.

[Bug c++/67593] New: Partial specialization: "Template argument involves template parameters"

[colu...@gmx-topmail.de]

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

Bug ID: 67593
   Summary: Partial specialization: "Template argument involves
template parameters"
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: colu...@gmx-topmail.de
  Target Milestone: ---

template 
struct outer
{
template  struct inner {};
template  struct inner {};
};

This fails to compile, although the code is well-formed (in particular,
[temp.class.spec]/(8.1) and (8.2) are not violated); Apparently, GCC fails to
correctly distinguish nested levels of template parameters.

[Bug c++/67064] Register asm variable broken

[andres.tiraboschi at tallertechnologies dot com]

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

--- Comment #26 from Andrés Agustín Tiraboschi  ---
Hi, I've read the bug report and I've made a patch in order to fix it.
I've ran all the gcc tests and I have only one fail, but that fail is also
present in the original gcc. Anyway I've attached the test that fails.

[Bug c++/67064] Register asm variable broken

[andres.tiraboschi at tallertechnologies dot com]

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

--- Comment #25 from Andrés Agustín Tiraboschi  ---
Created attachment 36338
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36338&action=edit
The test that fails

[Bug c++/67064] Register asm variable broken

[andres.tiraboschi at tallertechnologies dot com]

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

Andrés Agustín Tiraboschi  
changed:

   What|Removed |Added

 CC||andres.tiraboschi@tallertec
   ||hnologies.com

--- Comment #24 from Andrés Agustín Tiraboschi  ---
Created attachment 36337
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36337&action=edit
The diff for the patch

[Bug bootstrap/67587] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

[trippels at gcc dot gnu.org]

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

--- Comment #10 from Markus Trippelsdorf  ---
Created attachment 36336
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36336&action=edit
testcase for x86_64

 % g++ -c -march=westmere -O2 -pipe -fprofile-use -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables tree-chrec.ii
../../gcc/gcc/tree-chrec.c: In function ‘tree_node* chrec_fold_plus(tree, tree,
tree)’:
../../gcc/gcc/tree-chrec.c:383:1: error: non-cold basic block 271 dominated by
a block in the cold partition (270)
../../gcc/gcc/tree-chrec.c:383:1: internal compiler error: verify_flow_info
failed
0x8d5a92 verify_flow_info()
../../gcc/gcc/cfghooks.c:262
0xbb8b99 execute_function_todo
../../gcc/gcc/passes.c:1963
0xbb9503 execute_todo
../../gcc/gcc/passes.c:2008
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug bootstrap/67587] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

[hjl.tools at gmail dot com]

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

--- Comment #9 from H.J. Lu  ---
(In reply to Segher Boessenkool from comment #8)
> Could you then reduce the testcase, or something?  Yes I know that is
> inconvenient to do with LTO.  It is also very inconvenient for me to
> set up an environment on x86-64, wait a few hours, and then see if it
> did or did not reproduce your problem.

I sent you a testcase via Google Drive.  Please let me know if you
can reproduce it.

[Bug target/67484] options-save.c sanitizer asan detects freed storage referenced heap-use-after-free

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target||x86
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2015-09-15
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |6.0
 Ever confirmed|0   |1

--- Comment #6 from Uroš Bizjak  ---
Patch at [1].

[1] https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01116.html

[Bug bootstrap/67587] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

[segher at gcc dot gnu.org]

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

--- Comment #8 from Segher Boessenkool  ---
Could you then reduce the testcase, or something?  Yes I know that is
inconvenient to do with LTO.  It is also very inconvenient for me to
set up an environment on x86-64, wait a few hours, and then see if it
did or did not reproduce your problem.

I did ask for the dump files before, there is a good chance this will
let me pinpoint the problem, and those should be easy to generate for
you.

[Bug c++/67592] New: A virtual member function declared constexpr fails to trigger a diagnostic

[andrey.vul at gmail dot com]

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

Bug ID: 67592
   Summary: A virtual member function declared constexpr fails to
trigger a diagnostic
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrey.vul at gmail dot com
  Target Milestone: ---

The test case

// begin test.cc
struct S {
constexpr virtual int f() { return 1; }
};
// end test.cc

fails to emit a diagnostic with invocation

g++-6.0.0-alpha20150830 -std=c++11 -Wall -Wextra -pedantic test.cc

C++11 and C++14 [dcl.constexpr]p3.1 state that a constexpr function shall not
be virtual.

[Bug bootstrap/67587] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

[hjl.tools at gmail dot com]

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

--- Comment #7 from H.J. Lu  ---
(In reply to Segher Boessenkool from comment #6)
> Do you have a .i file instead?  And .gcda I guess.

It failed during the final LTO link.  How does .i file help?

[Bug bootstrap/67587] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

[segher at gcc dot gnu.org]

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

--- Comment #6 from Segher Boessenkool  ---
Do you have a .i file instead?  And .gcda I guess.

[Bug c/67580] Improve error message on missing "struct" tag

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
Fixed.

[Bug c/67580] Improve error message on missing "struct" tag

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Author: mpolacek
Date: Tue Sep 15 17:19:11 2015
New Revision: 227803

URL: https://gcc.gnu.org/viewcvs?rev=227803&root=gcc&view=rev
Log:
PR c/67580
* c-decl.c (tag_exists_p): New function.
* c-parser.c (c_parser_declaration_or_fndef): Give a hint when
struct/union/enum keywords are missing.
* c-tree.h (tag_exists_p): Declare.

* gcc.dg/pr67580.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/pr67580.c
Modified:
trunk/gcc/c/ChangeLog
trunk/gcc/c/c-decl.c
trunk/gcc/c/c-parser.c
trunk/gcc/c/c-tree.h
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/47679] [4.9/5/6 Regression] Strange uninitialized warning after SRA

[law at gcc dot gnu.org]

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

--- Comment #24 from Jeffrey A. Law  ---
Author: law
Date: Tue Sep 15 17:03:49 2015
New Revision: 227801

URL: https://gcc.gnu.org/viewcvs?rev=227801&root=gcc&view=rev
Log:
[PATCH] More class-ification of DOM

PR tree-optimization/47679
* tree-ssa-dom.c (expr_hash_elt): Now a class with ctors/dtors,
methods and private members.
(avail_exprs_stack): Similarly.  Change type of global
from a pair of expr_hash_elt_t to the new class.
(expr_elt_hasher::hash): Corresponding changes.
(expr_elt_hasher::equal): Similarly.
(avail_expr_hash): Similarly.
(pass_dominator::execute): Similarly.
(dom_opt_dom_walker::thread_across_edge): Similarly.
(record_cond): Similarly.
(dom_opt_dom_walker::before_dom_children): Similarly.
(dom_opt_dom_walker::after_dom_children): Similarly.
(lookup_avail_expr): Likewise.
(initialize_hash_element): Now a expr_hash_elt constructor.
(initialize_hash_element_from_expr): Similarly.
(free_expr_hash_elt_contents): Now a dtor for class expr_hash_elt.
(free_expr_hash_elt): Call dtor for the element.
(remove_local_expressions_from_table): Now the "pop_to_marker"
method in the available_exprs_stack class.
(avail_expr_stack::record_expr): Method factored out.
(print_expr_hash_elt): Now a method in the expr_hash_elt class.
Fix formatting.
(hashable_expr_equal_p): Fix formatting.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-dom.c

[Bug bootstrap/67587] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

[trippels at gcc dot gnu.org]

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

--- Comment #5 from Markus Trippelsdorf  ---
 % ../gcc/configure --disable-libstdcxx-pch --disable-libvtv --disable-libitm
--disable-libcilkrts --disable-libssp --disable-libgomp --disable-werror
--disable-multilib --enable-languages=c,c++ --with-build-config="bootstrap-lto"
 % make -j80 profiledbootstrap

should be enough.

[Bug fortran/67588] module.c heap use after free

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-15
 CC||kargl at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from kargl at gcc dot gnu.org ---
Paul,

I think Vittorio is correct.  It appears you meant to free
a list, but you only free the head and then leak memory.

[Bug bootstrap/67587] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

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

--- Comment #4 from Segher Boessenkool  ---
Eww.  Could either of you send me instruction how to reproduce this,
and/or the relevant dump files (pro_and_epi and the one before, 239
and 235 currently)?

[Bug target/67591] ARM v8 Thumb IT blocks deprecated

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-15
 CC||ktkachov at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed.
This is the assembler warning about the ARMv8-A IT blocks when they contain
non-16 bit instructions.

The main culprits are the conditional compare patterns: *cmp_and and friends.

[Bug target/67591] New: ARM v8 Thumb IT blocks deprecated

[clyon at gcc dot gnu.org]

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

Bug ID: 67591
   Summary: ARM v8 Thumb IT blocks deprecated
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---
Target: ARM

Conditional compare patterns in the arm backend have not been adjusted for the
-mrestrict-it rules, which leads to gas warning messages such as:

IT blocks containing 32-bit Thumb instructions are deprecated in ARMv8.

For instance, it happens in
libstdc++/testsuite/21_strings/basic_string/allocator/char/minimal.cc
when GCC is configured:
--target arm-none-linux-gnueabihf
--with-mode thumb
--with-cpu cortex-a57
--with-fpu crypto-neon-fp-armv8

[Bug bootstrap/67587] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||segher at kernel dot 
crashing.org

--- Comment #3 from H.J. Lu  ---
It was caused by r227775.

[Bug fortran/66227] [OOP] EXTENDS_TYPE_OF n returns wrong result for polymorphic variable allocated to extended type

[patnel97269-gfortran at yahoo dot fr]

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

--- Comment #2 from patnel97269-gfortran at yahoo dot fr ---
Yes the first and third should be True as i understand.

[Bug go/67589] go-main: int main() while return NULL

[ian at airs dot com]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #1 from Ian Lance Taylor  ---
Thanks for the report.  This is already fixed on mainline.

[Bug libstdc++/67572] std::atomic, std::mutex and others are trivially copyable

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #1 from Jason Merrill  ---
This is related to core issue 1928 and paper N4148.

I think that places that test is_trivially_copyable should also check the
appropriate one of is_{copy,move}_{constructible,assignable}, since triviality
and callability are disjoint properties.

I also think that a class with no non-deleted copy/move ctor/op= shouldn't be
trivially copyable.

[Bug other/67590] New: libcc1 cannot find objdump when cross build native

[syq at debian dot org]

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

Bug ID: 67590
   Summary: libcc1 cannot find objdump when cross build native
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: syq at debian dot org
  Target Milestone: ---

The configure of libcc1 uses gcc_cv_objdump var when cross build native.
while it is not defined at all.

So we can use gcc/configure.ac one.

Index: gcc-5-5.2.1/src/libcc1/configure.ac
===
--- gcc-5-5.2.1.orig/src/libcc1/configure.ac
+++ gcc-5-5.2.1/src/libcc1/configure.ac
@@ -63,6 +63,31 @@ if test "$GXX" = yes; then
 fi
 AC_SUBST(libsuffix)

+# Figure out what objdump we will be using.
+AS_VAR_SET_IF(gcc_cv_objdump,, [
+if test -f $gcc_cv_binutils_srcdir/configure.in \
+ && test -f ../binutils/Makefile \
+ && test x$build = x$host; then
+   # Single tree build which includes binutils.
+   gcc_cv_objdump=../binutils/objdump$build_exeext
+elif test -x objdump$build_exeext; then
+   gcc_cv_objdump=./objdump$build_exeext
+elif ( set dummy $OBJDUMP_FOR_TARGET; test -x $[2] ); then
+gcc_cv_objdump="$OBJDUMP_FOR_TARGET"
+else
+AC_PATH_PROG(gcc_cv_objdump, $OBJDUMP_FOR_TARGET)
+fi])
+
+AC_MSG_CHECKING(what objdump to use)
+if test "$gcc_cv_objdump" = ../binutils/objdump$build_exeext; then
+   # Single tree build which includes binutils.
+   AC_MSG_RESULT(newly built objdump)
+elif test x$gcc_cv_objdump = x; then
+   AC_MSG_RESULT(not found)
+else
+   AC_MSG_RESULT($gcc_cv_objdump)
+fi
+
 dnl Test for -lsocket and -lnsl.  Copied from libgo/configure.ac.
 AC_CACHE_CHECK([for socket libraries], libcc1_cv_lib_sockets,
   [libcc1_cv_lib_sockets=

[Bug go/67589] New: go-main: int main() while return NULL

[syq at debian dot org]

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

Bug ID: 67589
   Summary: go-main: int main() while return NULL
   Product: gcc
   Version: 5.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: syq at debian dot org
CC: cmang at google dot com
  Target Milestone: ---

in libgo/runtime/go-main.c,

the main method is defined 

int main, while return NULL.

NULL in ppc64el is defined (void *)0, thus fails to build when cross build for
native.

While it doesn't fail when build with cross build and native build.

I use the same version of cross toolchain to cross build a native gcc.
Both of them are gcc 5.2.1-17 in Debian.


Index: gcc-5-5.2.1/src/libgo/runtime/go-main.c
===
--- gcc-5-5.2.1.orig/src/libgo/runtime/go-main.c
+++ gcc-5-5.2.1/src/libgo/runtime/go-main.c
@@ -38,7 +38,7 @@ main (int argc, char **argv)
   runtime_isarchive = false;

   if (runtime_isstarted)
-return NULL;
+return 0;
   runtime_isstarted = true;

   runtime_check ();

[Bug middle-end/67442] [5/6 Regression] GCC 5.2.0 on x86_64 creates invalid address on specific array index calculation through pointer

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #11 from Richard Biener  ---
Testing

@@ -6166,8 +6173,12 @@ extract_muldiv_1 (tree t, tree c, enum t
  && ((sign == UNSIGNED && tcode != MULT_EXPR) || sign == SIGNED))
overflow_p = true;
  if (!overflow_p)
-   return fold_build2 (tcode, ctype, fold_convert (ctype, op0),
-   wide_int_to_tree (ctype, mul));
+   {
+ mul = wide_int::from (mul, TYPE_PRECISION (ctype),
+   TYPE_SIGN (TREE_TYPE (op1)));
+ return fold_build2 (tcode, ctype, fold_convert (ctype, op0),
+ wide_int_to_tree (ctype, mul));
+   }
}

   /* If these operations "cancel" each other, we have the main

[Bug bootstrap/67587] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-15
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
Confirmed.

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

[kkojima at gcc dot gnu.org]

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

--- Comment #3 from Kazumoto Kojima  ---
I've wrongly cut&paste call_value_pcrel.  It's

(define_insn_and_split "call_value_pcrel"
  [(set (match_operand 0 "" "=rf")
(call (mem:SI (match_operand:SI 1 "symbol_ref_operand" ""))
  (match_operand 2 "" "")))
   (use (reg:SI FPSCR_MODES_REG))
   (use (reg:SI PIC_REG))
   (clobber (reg:SI PR_REG))
   (clobber (match_scratch:SI 3 "=&r"))]
   ...

I think that the last clobber should be

   (clobber (match_scratch:SI 3 "=&r"))]

i.e. the scratch register is early clobbered.  With that change,
it looks the wrong code go away.  I'll come up with the tested
patch for all similar *call_*pcrel insns.

[Bug tree-optimization/67470] [5 Regression] ICE at -O3 on x86_64-linux-gnu in compute_live_loop_exits, at tree-ssa-loop-manip.c:235

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[5/6 Regression] ICE at -O3 |[5 Regression] ICE at -O3
   |on x86_64-linux-gnu in  |on x86_64-linux-gnu in
   |compute_live_loop_exits, at |compute_live_loop_exits, at
   |tree-ssa-loop-manip.c:235   |tree-ssa-loop-manip.c:235

--- Comment #8 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/67470] [5 Regression] ICE at -O3 on x86_64-linux-gnu in compute_live_loop_exits, at tree-ssa-loop-manip.c:235

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[5/6 Regression] ICE at -O3 |[5 Regression] ICE at -O3
   |on x86_64-linux-gnu in  |on x86_64-linux-gnu in
   |compute_live_loop_exits, at |compute_live_loop_exits, at
   |tree-ssa-loop-manip.c:235   |tree-ssa-loop-manip.c:235

--- Comment #8 from Richard Biener  ---
Fixed on trunk sofar.

[Bug tree-optimization/67470] [5/6 Regression] ICE at -O3 on x86_64-linux-gnu in compute_live_loop_exits, at tree-ssa-loop-manip.c:235

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 15 14:10:10 2015
New Revision: 227797

URL: https://gcc.gnu.org/viewcvs?rev=227797&root=gcc&view=rev
Log:
2015-09-15  Richard Biener  

PR tree-optimization/67470
* tree-ssa-loop-im.c (execute_sm_if_changed): Preserve PHI
structure for PHI hoisting by inserting a forwarder block
if appropriate.

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

Added:
trunk/gcc/testsuite/gcc.dg/torture/pr67470.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-ssa-loop-im.c

[Bug c++/67582] typeof(*p) * fails when p is void *

[vegard.nossum at gmail dot com]

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

--- Comment #5 from Vegard Nossum  ---
(In reply to Jonathan Wakely from comment #4)
> But *p is not a valid expression, so you might as well ask for
> typeof(this is nonsense and not valid C++).
> 
> You also can't ask for sizeof(*p) for a void pointer.

The following bits from the standard draft seem to support what you say:

[basic.compound].3 "The type of a pointer to void or a pointer to an object
type is called an object pointer type. [ Note: A pointer to void does not have
a pointer-to-object type, however, because void is not an object type. — end
note ]"

[expr.unary.op].1 "The unary * operator performs indirection: the expression to
which it is applied shall be a pointer to an object type, or a pointer to a
function type and the result is an lvalue referring to the object or function
to which the expression points."

[Bug libfortran/67585] Retry system calls failing with EINTR

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2015-09-15
 Ever confirmed|0   |1

--- Comment #1 from Dominique d'Humieres  ---
> libgfortran should retry system calls failing with EINTR, with the exception
> of close(). Rationale and further reading e.g. at
>  https://www.python.org/dev/peps/pep-0475/

I don't understand what is expected. The only place where EINTR is used is in
raw_write file io/unix.c with a comment

  /* We must write in a loop since some systems don't restart system
 calls in case of a signal.  */

For raw_read, the comment is

  /* For read we can't do I/O in a loop like raw_write does, because
 that will break applications that wait for interactive I/O.  */

[Bug target/52144] ARM should support arm/thumb function attribute to permit different instruction sets in the same source

[chrbr at gcc dot gnu.org]

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

--- Comment #11 from chrbr at gcc dot gnu.org ---
Author: chrbr
Date: Tue Sep 15 13:43:17 2015
New Revision: 227795

URL: https://gcc.gnu.org/viewcvs?rev=227795&root=gcc&view=rev
Log:
2015-09-15  Christian Bruel  

PR target/52144
* config/arm/arm.c (arm_option_params_internal): Remove opts parameter.
* config/arm/arm-c.c (arm_cpu_builtins): Declare static.
Remove flags parameter.
* config/arm/arm.h (TARGET_32BIT_P, TARGET_ARM_QBIT_P)
(TARGET_ARM_SAT_P, TARGET_IDIV_P, TARGET_HAVE_LDREX_P)
(TARGET_HAVE_LDREXBH_P, TARGET_HAVE_LDREXD_P, TARGET_DSP_MULTIPLY_P)
(TARGET_ARM_FEATURE_LDREX_P, TARGET_INT_SIMD_P): Redefine macros
with...
(TARGET_ARM_SAT, TARGET_IDIV, TARGET_HAVE_LDREX)
(TARGET_HAVE_LDREXBH, TARGET_HAVE_LDREXD, TARGET_ARM_FEATURE_LDREX)
(TARGET_DSP_MULTIPLY, TARGET_INT_SIMD): Redefined macros.
* gcc/config/arm/arm-protos.h (arm_cpu_builtins): Remove declaration.


Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/arm/arm-c.c
trunk/gcc/config/arm/arm-protos.h
trunk/gcc/config/arm/arm.c
trunk/gcc/config/arm/arm.h

[Bug target/67484] options-save.c sanitizer asan detects freed storage referenced heap-use-after-free

[zeccav at gmail dot com]

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

--- Comment #5 from Vittorio Zecca  ---
Uros, I applied your patch and the sanitizer message disappeared.
Is this still an UNCONFIRMED bug?

[Bug fortran/67588] New: module.c heap use after free

[zeccav at gmail dot com]

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

Bug ID: 67588
   Summary: module.c heap use after free
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

Let us look at module.c:800 and next:

  use_list = module_list;
  for (; module_list->next; use_list = use_list->next)
{
  module_list = use_list->next;
  free (use_list);
}

The Asan sanitizer detects that after the first iteration use_list is freed,
you can see that by inspection. But in the for statement it is dereferenced.

So this loop is wrong.

Maybe it should be

for (; module_list->next; use_list = module_list)
{
  module_list = use_list->next;
  free (use_list);
}

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

[vries at gcc dot gnu.org]

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

--- Comment #7 from vries at gcc dot gnu.org ---
(In reply to vries from comment #6)
> Updated patch series:
> - https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00938.html
> - https://gcc.gnu.org/ml/gcc-patches/2015-09/msg00940.html

FTR, bootstrap and reg-test of this patch series on x86_64 succeeded.

[Bug bootstrap/67587] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf  changed:

   What|Removed |Added

 CC||trippels at gcc dot gnu.org

--- Comment #1 from Markus Trippelsdorf  ---
This is the actual error:
gcc/tree-sra.c:3145:1: error: non-cold basic block 40 dominated by a block in
the cold partition (39)

[Bug middle-end/67563] [5 Regression] verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||6.0
Summary|[5/6 Regression]|[5 Regression]
   |verify_flow_info failed |verify_flow_info failed
  Known to fail|6.0 |

--- Comment #5 from Richard Biener  ---
Fixed on trunk sofar.

[Bug middle-end/67563] [5 Regression] verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 15 12:37:19 2015
New Revision: 227788

URL: https://gcc.gnu.org/viewcvs?rev=227788&root=gcc&view=rev
Log:
2015-09-15  Richard Biener  

PR middle-end/67563
* gimple-fold.c (gimplify_and_update_call_from_tree): Do not
transfer EH info from old to new stmt.
(replace_call_with_value): Likewise.
(replace_call_with_call_and_fold): Likewise.
(gimple_fold_builtin_memory_op): Likewise.
(gimple_fold_builtin_memset): Likewise.
(gimple_fold_builtin_stpcpy): Likewise.
(gimple_fold_call): Likewise.

* gcc.dg/pr67563.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr67563.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-fold.c
trunk/gcc/testsuite/ChangeLog

[Bug bootstrap/67587] [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
   Target Milestone|--- |6.0

[Bug bootstrap/67587] New: [6 Regression] profiledbootstrap failure with --with-build-config=bootstrap-lto

[hjl.tools at gmail dot com]

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

Bug ID: 67587
   Summary: [6 Regression] profiledbootstrap failure with
--with-build-config=bootstrap-lto
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

On Linux/x86-64, r227776 gave

0x70c1dc verify_flow_info()
../../src-trunk/gcc/cfghooks.c:262
0xc2b973 execute_function_todo
../../src-trunk/gcc/passes.c:1963
0xc29f81 do_per_function
../../src-trunk/gcc/passes.c:1642
0xc2a3e3 execute_todo
../../src-trunk/gcc/passes.c:2008
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[7]: *** [/tmp/cc5jCGdl.ltrans17.ltrans.o] Error 1
make[7]: *** Waiting for unfinished jobs
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/local/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
../../src-trunk/gcc/cp/Make-lang.in:100: recipe for target 'cc1plus' failed
make[6]: *** [cc1plus] Error 1

when configured with --with-build-config=bootstrap-lto.

[Bug libstdc++/65142] std::random_device Ignores Read Return Code

[rguenther at suse dot de]

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

--- Comment #10 from rguenther at suse dot de  ---
On Tue, 15 Sep 2015, redi at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65142
> 
> --- Comment #8 from Jonathan Wakely  ---
> (In reply to Richard Biener from comment #7)
> > If the user controls how the random file is opened (non-blocking or 
> > blocking)
> 
> They don't.
> 
> > then the behavior (whether to re-try on EINTR or short reads) should be
> > controlled by that choice.  Starting to throw on users that don't expect 
> > that
> > would be bad.
> 
> The function is specified to throw on error by the standard.

Well, the question is what is an "error" then.  The need to wait
(as you say we open blocking) isn't in my view.  Getting EINTRed
while waiting neither.  Getting a fatal error from the read yes.

[Bug c++/67582] typeof(*p) * fails when p is void *

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Vegard Nossum from comment #3)
> (In reply to Jonathan Wakely from comment #1)
> > You can't dereference a void*, so why do you expect to be able to get the
> > type of an invalid expression?
> 
> I was under the impression that the expression was not actually evaluated,
> but that only the *type* of the expression was evaluated.

But *p is not a valid expression, so you might as well ask for
typeof(this is nonsense and not valid C++).

You also can't ask for sizeof(*p) for a void pointer.

[Bug libstdc++/65142] std::random_device Ignores Read Return Code

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #8)
> (In reply to Richard Biener from comment #7)
> > If the user controls how the random file is opened (non-blocking or 
> > blocking)
> 
> They don't.

To be clear, it's always opened blocking with std::fopen(fname, "rb")

New proposed patch at https://gcc.gnu.org/ml/gcc-patches/2015-09/msg01050.html

[Bug libstdc++/65142] std::random_device Ignores Read Return Code

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #7)
> If the user controls how the random file is opened (non-blocking or blocking)

They don't.

> then the behavior (whether to re-try on EINTR or short reads) should be
> controlled by that choice.  Starting to throw on users that don't expect that
> would be bad.

The function is specified to throw on error by the standard.

[Bug target/67573] [SH] wrong code generated for libstdc++-v3/src/c++11/cxx11-shim_facets.cc at -mlra

[kkojima at gcc dot gnu.org]

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

--- Comment #2 from Kazumoto Kojima  ---
It seems that LRA allocates r7 for the scratch reg at

(define_insn_and_split "call_value_pcrel"
  [(set (match_operand 0 "" "=rf")
(call (mem:SI (match_operand:SI 1 "symbol_ref_operand" ""))
  (match_operand 2 "" "")))
   (use (reg:SI FPSCR_MODES_REG))
   (use (reg:SI PIC_REG))
   (clobber (reg:SI PR_REG))
   (use (match_scratch:SI 3 "=r"))]

in the problematic case and the insn

(call_insn 208 207 209 22 (parallel [
(set (reg:SI 0 r0)
(call (mem:SI (symbol_ref:SI
("_ZNKSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE4copyEPwjj") [flags
0x41]  ) [0 copy S4 A32])
(const_int 0 [0])))
(use (reg:SI 154 fpscr0))
(use (reg:SI 12 r12))
(clobber (reg:SI 146 pr))
(clobber (reg:SI 7 r7 [357]))
]) fa.cc:484 322 {call_value_pcrel}
 (expr_list:REG_EH_REGION (const_int 4 [0x4])
(expr_list:REG_CALL_DECL (symbol_ref:SI
("_ZNKSt7__cxx1112basic_stringIwSt11char_traitsIwESaIwEE4copyEPwjj") [flags
0x41]  )
(nil)))
(expr_list:SI (use (reg:SI 4 r4))
(expr_list:SI (use (reg:SI 5 r5))
(expr_list:SI (use (reg:SI 6 r6))
(expr_list:SI (use (reg:SI 7 r7))
(nil))

made the following passes confused.

[Bug c/67580] Improve error message on missing "struct" tag

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |6.0

--- Comment #2 from Marek Polacek  ---
I'll need either tweak lookup_tag or introduce some new function -- lookup_tag
issues the "defined as wrong kind of tag" error.  But otherwise I think this is
doable.

[Bug target/67484] options-save.c sanitizer asan detects freed storage referenced heap-use-after-free

[ubizjak at gmail dot com]

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

--- Comment #4 from Uroš Bizjak  ---
Patch in testing:

--cut here--
Index: config/i386/i386.c
===
--- config/i386/i386.c  (revision 22)
+++ config/i386/i386.c  (working copy)
@@ -5080,12 +5080,14 @@ ix86_valid_target_attribute_tree (tree args,
   /* If we are using the default tune= or arch=, undo the string assigned,
 and use the default.  */
   if (option_strings[IX86_FUNCTION_SPECIFIC_ARCH])
-   opts->x_ix86_arch_string = option_strings[IX86_FUNCTION_SPECIFIC_ARCH];
+   opts->x_ix86_arch_string
+ = xstrdup (option_strings[IX86_FUNCTION_SPECIFIC_ARCH]);
   else if (!orig_arch_specified)
opts->x_ix86_arch_string = NULL;

   if (option_strings[IX86_FUNCTION_SPECIFIC_TUNE])
-   opts->x_ix86_tune_string = option_strings[IX86_FUNCTION_SPECIFIC_TUNE];
+   opts->x_ix86_tune_string
+ = xstrdup (option_strings[IX86_FUNCTION_SPECIFIC_TUNE]);
   else if (orig_tune_defaulted)
opts->x_ix86_tune_string = NULL;

--cut here--

[Bug libstdc++/65142] std::random_device Ignores Read Return Code

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener  ---
If the user controls how the random file is opened (non-blocking or blocking)
then the behavior (whether to re-try on EINTR or short reads) should be
controlled by that choice.  Starting to throw on users that don't expect that
would be bad.

[Bug target/67586] New: xtensa: ICE with -Os -g -fno-builtin-malloc in dwarf2out_var_location, at dwarf2out.c:22380

[jcmvbkbc at gcc dot gnu.org]

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

Bug ID: 67586
   Summary: xtensa: ICE with -Os -g -fno-builtin-malloc in
dwarf2out_var_location, at dwarf2out.c:22380
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jcmvbkbc at gcc dot gnu.org
  Target Milestone: ---

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

$ cc1 -Os mallocbug1.i -g -fno-builtin-malloc
 main
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>   
 
Assembling functions:
 main
mallocbug1.i: In function ‘main’:
mallocbug1.i:30:1: internal compiler error: in dwarf2out_var_location, at
dwarf2out.c:22380
 }
 ^
0x6fdff4 dwarf2out_var_location
../../gcc/gcc/dwarf2out.c:22376
0x779879 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/gcc/final.c:2385
0x77a4ec final(rtx_insn*, _IO_FILE*, int)
../../gcc/gcc/final.c:2058
0x77b6c9 rest_of_handle_final
../../gcc/gcc/final.c:4449
0x77b6c9 execute
../../gcc/gcc/final.c:4524


$ xtensa-test_kc705-linux-gcc -v 
Using built-in specs.
COLLECT_GCC=../build-xtensa-call0/root/bin/xtensa-test_kc705-linux-gcc
COLLECT_LTO_WRAPPER=/home/jcmvbkbc/ws/tensilica/gcc/build-xtensa-call0/root/libexec/gcc/xtensa-test_kc705-linux/6.0.0/lto-wrapper
Target: xtensa-test_kc705-linux
Configured with: ../gcc/configure
--prefix=/home/jcmvbkbc/ws/tensilica/gcc/build-xtensa-call0/root
--target=xtensa-test_kc705-linux --disable-shared --disable-libssp
--disable-libisl --enable-languages=c,c++ --enable-debug --enable-tls
Thread model: posix
gcc version 6.0.0 20150910 (experimental) (GCC) 

Configured for CALL0 ABI.

[Bug libfortran/67585] New: Retry system calls failing with EINTR

[jb at gcc dot gnu.org]

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

Bug ID: 67585
   Summary: Retry system calls failing with EINTR
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb at gcc dot gnu.org
  Target Milestone: ---

libgfortran should retry system calls failing with EINTR, with the exception of
close(). Rationale and further reading e.g. at 
https://www.python.org/dev/peps/pep-0475/

[Bug c++/67582] typeof(*p) * fails when p is void *

[vegard.nossum at gmail dot com]

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

--- Comment #3 from Vegard Nossum  ---
(In reply to Jonathan Wakely from comment #1)
> You can't dereference a void*, so why do you expect to be able to get the
> type of an invalid expression?

I was under the impression that the expression was not actually evaluated, but
that only the *type* of the expression was evaluated.

For example, I would also expect this to work even though x has not been
initialised (which should otherwise be UB when dereferenced):

int *x;
typeof(*x) y;

Similarly, I would also expect the usual

#define ARRAY_SIZE(x) (sizeof(x) / sizeof(*x))

to return 0 when passed a zero-length array. Or is that invalid too?

[Bug c++/65218] [C++11] Complicated diagnostic of erroneous range expression over a pointer type

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-15
 Ever confirmed|0   |1

[Bug c++/67584] Compilation is fine if an undeclared identifier is used in a for range-based loop, and lsh has the same name as rhs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Probably another symptom of Bug 54430, just a particularly nasty variation of
it.

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

[Bug c++/54430] [C++11] For-Loop: Scope of iterating variable begins too early

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 CC||tony at becrux dot com

--- Comment #7 from Jonathan Wakely  ---
*** Bug 67584 has been marked as a duplicate of this bug. ***

[Bug c++/67584] Compilation is fine if an undeclared identifier is used in a for range-based loop, and lsh has the same name as rhs

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2015-09-15
 Ever confirmed|0   |1

[Bug target/67484] options-save.c sanitizer asan detects freed storage referenced heap-use-after-free

[ubizjak at gmail dot com]

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

--- Comment #3 from Uroš Bizjak  ---
(In reply to Vittorio Zecca from comment #0)

> //to make happy the sanitizer I commented out the for loop in i386.c lines

  /* Save the current options unless we are validating options for
 #pragma.  */
  t = build_target_option_node (opts);

  opts->x_ix86_arch_string = orig_arch_string;
  opts->x_ix86_tune_string = orig_tune_string;
  opts_set->x_ix86_fpmath = orig_fpmath_set;

  /* Free up memory allocated to hold the strings */
  for (i = 0; i < IX86_FUNCTION_SPECIFIC_MAX; i++)
free (option_strings[i]);

Indeed.  We saved current options in build_target_option_node, where only
*pointers* to strings were saved. We should not free the memory, pointed by the
saved pointer.

[Bug c++/67584] New: Compilation is fine if an undeclared identifier is used in a for range-based loop, and lsh has the same name as rhs

[tony at becrux dot com]

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

Bug ID: 67584
   Summary: Compilation is fine if an undeclared identifier is
used in a for range-based loop, and lsh has the same
name as rhs
   Product: gcc
   Version: 5.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tony at becrux dot com
  Target Milestone: ---

GCC does not fail in compiling the following code:

#include 

class A : public std::vector< int >
{
public:
  A(int x) : std::vector< int >(x) { }
};

int main(int, char **)
{
  for (A v : v)
  {

  }

  return 0;
}

"A" class has been declared just to "trick" the vector behavior (i.e. remove
the explicit constructor) and fool the compiler.

Command-line used for compilation:

g++ -v -save-temps -std=c++11 -Wall -Wextra -pedantic -o for_bug.exe
for_bug.cpp

No warning is generated.

I've tested 5.2 too, and older version of GCC (4.8 and 4.7 series), the result
is always the same (using an online compiler).

Clang and ICC behave correctly, i.e. compilation fails cause "v" is an
undeclared identifier (using an online compiler).

GCC version used for test is 5.1.0, MinGW-w64, Windows 7 64 bit. The produced
executable crashes during execution.

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=C:/i686-510-win32-sjlj-rt_v4/bin/../libexec/gcc/i686-w64-mingw32/5.1.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../../../src/gcc-5.1.0/configure --host=i686-w64-mingw32
--build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32
--with-sysroot=/home/Tony/mingw-gcc-5.1.0/i686-510-win32-sjlj-rt_v4/mingw32
--with-gxx-include-dir=/mingw32/i686-w64-mingw32/include/c++ --enable-shared
--enable-static --disable-multilib --enable-languages=c,c++,lto
--enable-libstdcxx-time=yes --enable-threads=win32 --enable-libgomp
--enable-libatomic --enable-lto --enable-graphite --enable-checking=release
--enable-fully-dynamic-string --enable-version-specific-runtime-libs
--enable-sjlj-exceptions --disable-isl-version-check --disable-libstdcxx-pch
--disable-libstdcxx-debug --disable-bootstrap --disable-rpath
--disable-win32-registry --disable-nls --disable-werror --disable-symvers
--with-gnu-as --with-gnu-ld --with-arch=i686 --with-tune=i686 --with-libiconv
--with-system-zlib
--with-gmp=/home/Tony/mingw-gcc-5.1.0/prerequisites/i686-w64-mingw32-static
--with-mpfr=/home/Tony/mingw-gcc-5.1.0/prerequisites/i686-w64-mingw32-static
--with-mpc=/home/Tony/mingw-gcc-5.1.0/prerequisites/i686-w64-mingw32-static
--with-isl=/home/Tony/mingw-gcc-5.1.0/prerequisites/i686-w64-mingw32-static
--with-pkgversion='i686-win32-sjlj, Built by Antonio Di Monaco'
--with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-march=i686 -mtune=i686 -mthreads
-I/home/Tony/mingw-gcc-5.1.0/i686-510-win32-sjlj-rt_v4/mingw32/opt/include
-I/home/Tony/mingw-gcc-5.1.0/prerequisites/i686-zlib-static/include
-I/home/Tony/mingw-gcc-5.1.0/prerequisites/i686-w64-mingw32-static/include'
CXXFLAGS='-O2 -pipe -march=i686 -mtune=i686 -mthreads
-I/home/Tony/mingw-gcc-5.1.0/i686-510-win32-sjlj-rt_v4/mingw32/opt/include
-I/home/Tony/mingw-gcc-5.1.0/prerequisites/i686-zlib-static/include
-I/home/Tony/mingw-gcc-5.1.0/prerequisites/i686-w64-mingw32-static/include'
CPPFLAGS= LDFLAGS='-pipe
-L/home/Tony/mingw-gcc-5.1.0/i686-510-win32-sjlj-rt_v4/mingw32/opt/lib
-L/home/Tony/mingw-gcc-5.1.0/prerequisites/i686-zlib-static/lib
-L/home/Tony/mingw-gcc-5.1.0/prerequisites/i686-w64-mingw32-static/lib
-Wl,--large-address-aware'
Thread model: win32
gcc version 5.1.0 (i686-win32-sjlj, Built by Antonio Di Monaco) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-Wall' '-Wextra'
'-Wpedantic' '-o' 'for_bug.exe' '-shared-libgcc' '-mtune=i686' '-march=i686'

C:/i686-510-win32-sjlj-rt_v4/bin/../libexec/gcc/i686-w64-mingw32/5.1.0/cc1plus.exe
-E -quiet -v -iprefix
C:/i686-510-win32-sjlj-rt_v4/bin/../lib/gcc/i686-w64-mingw32/5.1.0/
-U_REENTRANT for_bug.cpp -mtune=i686 -march=i686 -std=c++11 -Wall -Wextra
-Wpedantic -fpch-preprocess -o for_bug.ii
ignoring duplicate directory
"C:/i686-510-win32-sjlj-rt_v4/lib/gcc/../../lib/gcc/i686-w64-mingw32/5.1.0/include"
ignoring nonexistent directory
"C:/msys32/home/Tony/mingw-gcc-5.1.0/i686-510-win32-sjlj-rt_v4/mingw32C:/msys32/mingw32/lib/gcc/i686-w64-mingw32/5.1.0/../../../../include"
ignoring duplicate directory
"C:/i686-510-win32-sjlj-rt_v4/lib/gcc/../../lib/gcc/i686-w64-mingw32/5.1.0/include-fixed"
ignoring duplicate directory
"C:/i686-510-win32-sjlj-rt_v4/lib/gcc/../../lib/gcc/i686-w64-mingw32/5.1.0/../../../../i686-w64-mingw32/include"
ignoring nonexistent directory
"C:/msys32/home/Tony/mingw-gcc-5.1.0/i686-510-win32-sjlj-rt_v4/mingw32/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 C:/i686-510-win32-sjlj-rt_v4/bin/../lib/gcc/i686-w64-mingw32/5.1.0/include

C:/i68

[Bug testsuite/67583] New: libstdc++-v3/testsuite/27_io/basic_stringbuf/seekoff/char/1.cc:92 erroneous call to sputn

[zeccav at gmail dot com]

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

Bug ID: 67583
   Summary: libstdc++-v3/testsuite/27_io/basic_stringbuf/seekoff/c
har/1.cc:92 erroneous call to sputn
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

libstdc++-v3/testsuite/27_io/basic_stringbuf/seekoff/char/1.cc:92

strmsz_2 = strb_01.sputn(" ravi shankar meets carlos santana in LoHa", 90);

is erroneous, in my opinion, because it tries to transfer 90 bytes
while the string contains 43 characters, including null.

[Bug c++/67582] typeof(*p) * fails when p is void *

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(If it works in C I would suggest that's a bug in the C compiler, but that's
for the C front end maintainers to decide)

[Bug c++/67582] typeof(*p) * fails when p is void *

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
You can't dereference a void*, so why do you expect to be able to get the type
of an invalid expression?

[Bug tree-optimization/67470] [5/6 Regression] ICE at -O3 on x86_64-linux-gnu in compute_live_loop_exits, at tree-ssa-loop-manip.c:235

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
g_40 = PHI <0B(9), &a(6)>
  invariant up to level 1, cost 21.

pretmp_42 = g_40 == 0B;
  invariant up to level 1, cost 22.

but we're only moving pretmp_42, not g_40.  The PHI is controlled by
if (f_16(D) != 0).  But when applying stmt movement we are faced with
g_40 = PHI <0B(9), &a(6)> turned into

:
# g_40 = PHI <0B(26), &a(21), &a(22), 0B(25)>

whoops.  That's because predicated store-motion already messed up the
CFG without ensuring we have forwarder blocks that at least preserve
the existing PHI node structure.

This is a latent issue.

[Bug c++/67582] New: typeof(*p) * fails when p is void *

[vegard.nossum at gmail dot com]

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

Bug ID: 67582
   Summary: typeof(*p) * fails when p is void *
   Product: gcc
   Version: 4.8.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vegard.nossum at gmail dot com
  Target Milestone: ---

$ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04) 4.8.4

$ cat voidptr 
void foo(void *p)
{
typeof(*p) *x;
}

I'd expect this to work as if 'x' was declared 'void *x' (which is legal). It
works in C, but not in C++:

$ gcc -x c -c - < voidptr && echo success
success

$ gcc -x c++ -c - < voidptr
: In function ‘int foo(void*)’:
:3:10: error: ‘void*’ is not a pointer-to-object type
:3:15: error: invalid type in declaration before ‘;’ token

[Bug middle-end/67563] [5/6 Regression] verify_flow_info failed

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
Ok, so we are somewhat inconsistent in whether fold_stmt () performs EH
transfer
from old to new stmts (even on the 4.9 branch).  What triggers here is that
the new replace_call_with_value does it while update_call_from_tree does not
(we're replacing with a NOP).  Then the inliner does (through versioning):

  if (maybe_clean_or_replace_eh_stmt (old_stmt,
  new_stmt))
gimple_purge_dead_eh_edges (
  BASIC_BLOCK_FOR_FN (cfun, first));

but we already transfered EH info so maybe_clean_or_replace_eh_stmt returns
false.  Other callers of fold_stmt like tree-ssa-forwprop.c or the SSA
propagators
expect the same (not transfered EH info).  Testing whether never doing that
from fold_stmt works out ...

[Bug c++/67571] Error: open CFI at the end of file; missing .cfi_endproc directive

[werner at beroux dot com]

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

--- Comment #8 from werner at beroux dot com ---
Tried to build the exact same just on newer gcc and nothing else should have
changed, and it failed.

I'll try to build on older gcc as well.

[Bug c++/67581] [6 Regression] ICE on transparent union with -g enabled on x86_64-linux-gnu (verify_type failed)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ice-checking
 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |6.0
Summary|ICE on transparent union|[6 Regression] ICE on
   |with -g enabled on  |transparent union with -g
   |x86_64-linux-gnu|enabled on x86_64-linux-gnu
   |(verify_type failed)|(verify_type failed)

[Bug lto/67568] lto-streamer-in.c sanitizer runtime error: load of value 255, which is not a valid value for type 'bool'

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Tue Sep 15 08:00:30 2015
New Revision: 227779

URL: https://gcc.gnu.org/viewcvs?rev=227779&root=gcc&view=rev
Log:
2015-09-15  Richard Biener  

PR lto/67568
* lto-streamer.h (lto_location_cache::current_sysp): Properly
initialize.
* lto-streamer-out.c (clear_line_info): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/lto-streamer-out.c
trunk/gcc/lto-streamer.h

[Bug lto/67568] lto-streamer-in.c sanitizer runtime error: load of value 255, which is not a valid value for type 'bool'

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Should be fixed now.

[Bug target/67484] options-save.c sanitizer asan detects freed storage referenced heap-use-after-free

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 CC||g...@the-meissners.org

--- Comment #2 from Uroš Bizjak  ---
CC author.