[Bug target/63783] [4.9/5 Regression] [SH] Miscompilation of boolean negation on SH4 using -O2

[olegendo at gcc dot gnu.org]

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

--- Comment #2 from Oleg Endo  ---
Thanks for tracing this down.  Yes, it looks like a sh_treg_combine bug.  I
will have a look at it, but probably only in 2 weeks from now.

[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0

[howarth at bromo dot med.uc.edu]

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

--- Comment #10 from howarth at bromo dot med.uc.edu ---
Regression testing on x86_64-apple-darwin14 at
https://gcc.gnu.org/ml/gcc-testresults/2014-11/msg00806.html.

[Bug bootstrap/63784] [5 Regression] profiledbootstrap failure with bootstrap-lto

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||markus at trippelsdorf dot net

--- Comment #4 from H.J. Lu  ---
This part:

@@ -4451,7 +4452,7 @@ _LT_EOF
   if $LD --help 2>&1 | $EGREP ': supported targets:.* elf' > /dev/null \
  && test "$tmp_diet" = no
   then
-tmp_addflag=
+tmp_addflag=' $pic_flag'
 tmp_sharedflag='-shared'
 case $cc_basename,$host_cpu in
 pgcc*)# Portland Group C compiler
@@ -5517,8 +5518,8 @@ if test "$_lt_caught_CXX_error" != yes; then
   # Check if GNU C++ uses GNU ld as the underlying linker, since the
   # archiving commands below assume that GNU ld is being used.
   if test "$with_gnu_ld" = yes; then
-_LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o
$lib'
-_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared -nostdlib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
$wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
+_LT_TAGVAR(archive_cmds, $1)='$CC $pic_flag -shared -nostdlib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
$wl$soname -o $lib'
+_LT_TAGVAR(archive_expsym_cmds, $1)='$CC $pic_flag -shared -nostdlib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
$wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'

 _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
 _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
in

https://gcc.gnu.org/ml/gcc-patches/2012-09/msg00991.html

may work here.

[Bug bootstrap/63784] [5 Regression] profiledbootstrap failure with bootstrap-lto

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu  ---
This part:

@@ -4451,7 +4452,7 @@ _LT_EOF
   if $LD --help 2>&1 | $EGREP ': supported targets:.* elf' > /dev/null \
  && test "$tmp_diet" = no
   then
-tmp_addflag=
+tmp_addflag=' $pic_flag'
 tmp_sharedflag='-shared'
 case $cc_basename,$host_cpu in
 pgcc*)# Portland Group C compiler
@@ -5517,8 +5518,8 @@ if test "$_lt_caught_CXX_error" != yes; then
   # Check if GNU C++ uses GNU ld as the underlying linker, since the
   # archiving commands below assume that GNU ld is being used.
   if test "$with_gnu_ld" = yes; then
-_LT_TAGVAR(archive_cmds, $1)='$CC -shared -nostdlib $predep_objects
$libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname $wl$soname -o
$lib'
-_LT_TAGVAR(archive_expsym_cmds, $1)='$CC -shared -nostdlib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
$wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
+_LT_TAGVAR(archive_cmds, $1)='$CC $pic_flag -shared -nostdlib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
$wl$soname -o $lib'
+_LT_TAGVAR(archive_expsym_cmds, $1)='$CC $pic_flag -shared -nostdlib
$predep_objects $libobjs $deplibs $postdep_objects $compiler_flags ${wl}-soname
$wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'

 _LT_TAGVAR(hardcode_libdir_flag_spec, $1)='${wl}-rpath ${wl}$libdir'
 _LT_TAGVAR(export_dynamic_flag_spec, $1)='${wl}--export-dynamic'
in

https://gcc.gnu.org/ml/gcc-patches/2012-09/msg00991.html

may work here.

[Bug bootstrap/63784] [5 Regression] profiledbootstrap failure with bootstrap-lto

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu  ---
We have a few choices:

1. Build libcc1 with LTO when GCC is configured with
"--with-build-config=bootstrap-lto".  Or
2. Teach libtool to always add -fPIC when linking shared
object to support static archive compiled with LTO.  Or 
3. Don't compile libiberty with LTO.

I tbink #2 is a better choice since the same thing may happen elsewhere.

[Bug bootstrap/63784] [5 Regression] profiledbootstrap failure with bootstrap-lto

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-09
   Target Milestone|--- |5.0
 Ever confirmed|0   |1

--- Comment #1 from H.J. Lu  ---
r216964 disables bootstrap for libcc1 which exposed 2 things:

1. libcc1 isn't compiled with LTO even when GCC is configured with
"--with-build-config=bootstrap-lto".  It may be intentional since
libcc1 is disabled for bootstrap.
2. -fPIC isn't used to created libcc1.so, which is OK, if
libcc1 is compiled with LTO which remembers PIC option.

libiberty is bootstrapped with LTO.  When libcc1 isn't compiled with LTO,
we are creating libcc1.so without -fPIC, which leads to linker failure
when linking libiberty.

[Bug bootstrap/63787] New: [5 Regression] profiledbootstrap failure with bootstrap-lto

[hjl.tools at gmail dot com]

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

Bug ID: 63787
   Summary: [5 Regression] profiledbootstrap failure with
bootstrap-lto
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: rguenth at gcc dot gnu.org

On Linux/x86-64, configured with

--prefix=/export/project/git/gcc-regression-bootstrap/master/217178/usr
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
MAKEINFO=/usr/bin/false --enable-languages=c,c++ --enable-bootstrap
--with-build-config=bootstrap-lto --disable-werror --disable-multilib
--disable-libcc1

r217178 caused:

/export/project/git/gcc-regression-bootstrap/master/217178/bld/./prev-gcc/xg++
-B/export/project/git/gcc-regression-bootstrap/master/217178/bld/./prev-gcc/
-B/export/project/git/gcc-regression-bootstrap/master/217178/usr/x86_64-unknown-linux-gnu/bin/
-nostdinc++
-B/export/project/git/gcc-regression-bootstrap/master/217178/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/export/project/git/gcc-regression-bootstrap/master/217178/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/export/project/git/gcc-regression-bootstrap/master/217178/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu

-I/export/project/git/gcc-regression-bootstrap/master/217178/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include
 -I/export/project/git/gcc-regression/gcc/libstdc++-v3/libsupc++
-L/export/project/git/gcc-regression-bootstrap/master/217178/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/export/project/git/gcc-regression-bootstrap/master/217178/bld/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
  -g -O2 -flto=jobserver -frandom-seed=1 -fprofile-use -DIN_GCC   
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-fno-common  -DHAVE_CONFIG_H -DGENERATOR_FILE -static-libstdc++ -static-libgcc 
-o build/genmatch \
build/genmatch.o ../libcpp/libcpp.a ../libiberty/libiberty.a build/errors.o
build/vec.o build/hash-table.o .././libiberty/libiberty.a  
/export/project/git/gcc-regression/gcc/gcc/genmatch.c: In function
\u2018get_operator\u2019:
/export/project/git/gcc-regression/gcc/gcc/genmatch.c:329:1: internal compiler
error: in get_string_length, at tree-ssa-strlen.c:428
 get_operator (const char *id)
 ^
0x10e9c2a get_string_length
/export/project/git/gcc-regression/gcc/gcc/tree-ssa-strlen.c:428
0x10eb4e8 handle_builtin_strlen
/export/project/git/gcc-regression/gcc/gcc/tree-ssa-strlen.c:910
0x10ef194 strlen_optimize_stmt
/export/project/git/gcc-regression/gcc/gcc/tree-ssa-strlen.c:1904
0x10ef194 strlen_dom_walker::before_dom_children(basic_block_def*)
/export/project/git/gcc-regression/gcc/gcc/tree-ssa-strlen.c:2109
0x17d9c4c dom_walker::walk(basic_block_def*)
/export/project/git/gcc-regression/gcc/gcc/domwalk.c:188
0x10e7c22 execute
/export/project/git/gcc-regression/gcc/gcc/tree-ssa-strlen.c:2182
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[4]: *** [/tmp/ccbyp8aP.ltrans12.ltrans.o] Error 1
make[4]: *** Waiting for unfinished jobs
lto-wrapper: fatal error: make returned 2 exit status
compilation terminated.
/usr/local/bin/ld: lto-wrapper failed
collect2: error: ld returned 1 exit status
make[3]: *** [build/genmatch] Error 1

with "make profiledbootstrap".

[Bug c++/63786] New: crash on argument pack in switch case

[rhainin1 at binghamton dot edu]

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

Bug ID: 63786
   Summary: crash on argument pack in switch case
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rhainin1 at binghamton dot edu

Created attachment 33924
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33924&action=edit
minimal code to reproduce

using "case Is:" where Is is an argument pack (invalid code) causes gcc to
crash.

gcc-4.9.2 configured with "--enable-languages=c,c++" on 64-bit Debian 7.4

I have also compiled with -Wall -Wextra -pedantic -g and tried -std=c++14, with
no difference.
$ g++ -std=c++11 expandcase.cpp 
expandcase.cpp: In instantiation of ‘int f(int) [with int ...Is = {1, 2, 3}]’:
expandcase.cpp:10:15:   required from here
expandcase.cpp:4:9: internal compiler error: unexpected expression ‘Is’ of kind
template_parm_index
 case Is:
 ^
0x66b440 cxx_eval_constant_expression
../../src/gcc/cp/semantics.c:9822
0x66cf16 cxx_eval_outermost_constant_expr
../../src/gcc/cp/semantics.c:9842
0x5a9d99 finish_case_label(unsigned int, tree_node*, tree_node*)
../../src/gcc/cp/decl.c:3190
0x5ce90c tsubst_expr
../../src/gcc/cp/pt.c:13675
0x5ce7e4 tsubst_expr
../../src/gcc/cp/pt.c:13443
0x5cee5d tsubst_expr
../../src/gcc/cp/pt.c:13648
0x5ce092 tsubst_expr
../../src/gcc/cp/pt.c:13668
0x5cee5d tsubst_expr
../../src/gcc/cp/pt.c:13648
0x5cdc12 instantiate_decl(tree_node*, int, bool)
../../src/gcc/cp/pt.c:19971
0x5e483b instantiate_pending_templates(int)
../../src/gcc/cp/pt.c:20087
0x5fd24f cp_write_global_declarations()
../../src/gcc/cp/decl2.c:4340

[Bug target/63783] [4.9/5 Regression] [SH] Miscompilation of boolean negation on SH4 using -O2

[kkojima at gcc dot gnu.org]

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

Kazumoto Kojima  changed:

   What|Removed |Added

 Target||sh*-*-*
 Status|UNCONFIRMED |NEW
  Known to work||4.8.3
   Keywords||wrong-code
   Last reconfirmed||2014-11-09
  Component|c   |target
 CC||kkojima at gcc dot gnu.org,
   ||olegendo at gcc dot gnu.org
 Ever confirmed|0   |1
Summary|gcc-4.9: Miscompilation of  |[4.9/5 Regression] [SH]
   |boolean negation on SH4 |Miscompilation of boolean
   |using -O2   |negation on SH4 using -O2
  Known to fail||4.9.0

--- Comment #1 from Kazumoto Kojima  ---
I'd like to add oleg to the CC list.
This is a 4.9/5.0 regression from 4.8.  4.8 compilers generate
the code like

tstr1,r1
movtr1

for condition = !decision_result and we get

notr1,r1

for it with 4.9 and the newer compilers.
It seems that sh_treg_combine phase added at 4.9 does this.

[Bug middle-end/62018] FAIL: gcc.dg/torture/ftrapv-1.c * execution test on x86_64-apple-darwin13

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|WAITING |NEW
 CC||fxcoudert at gcc dot gnu.org

--- Comment #7 from Francois-Xavier Coudert  ---
Here's a minimal reproducer:

int iaddv (int a, int b) { return a + b; }
int main (void)
{ volatile int x = iaddv (__INT_MAX__, 1); }


Compiled with gcc trunk (or 4.8 or 4.9) with option -ftrapv, it executes
without fault. If I do the same on a linux box, it traps (as it should).

However, on both the tree dumps are the same: i.e. I cannot see, from the dump
tree, where the trap checks and instructions should be. Richard, I am willing
to debug this, but don't know where to go after the above analysis.

[Bug tree-optimization/63785] New: [5.0 regression] FAIL: gfortran.dg/transfer_simplify_2.f90 -O0 (internal compiler error)

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

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

Bug ID: 63785
   Summary: [5.0 regression] FAIL:
gfortran.dg/transfer_simplify_2.f90   -O0  (internal
compiler error)
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: rguenther at suse dot de
Target: m68k-*-*

$ gcc/gfortran -Bgcc/ -Bm68k-linux/./libgfortran/
../gcc/testsuite/gfortran.dg/transfer_simplify_2.f90 -O2
-Bm68k-linux/./libgfortran/.libs -Lm68k-linux/./libgfortran/.libs
-Lm68k-linux/./libgfortran/.libs -lm -o ./transfer_simplify_2.exe
../gcc/testsuite/gfortran.dg/transfer_simplify_2.f90:92:0:

 if (any (z1 .ne. z2)) call abort ()
 ^
internal compiler error: Segmentation fault
0xa61e6f crash_signal
../../gcc/toplev.c:358
0x86d453 gimple_code
../../gcc/gimple.h:1412
0x86d453 is_gimple_assign
../../gcc/gimple.h:2124
0x86d453 gimple_simplify
/daten/aranym/gcc/test/Build/gcc/gimple-match.c:2536
0x872979 gimple_resimplify2
../../gcc/gimple-match-head.c:197
0x8672aa fold_stmt_1
../../gcc/gimple-fold.c:3071
0x89dee1 gimplify_modify_expr
../../gcc/gimplify.c:4682
0x891c12 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:7693
0x8953f6 gimplify_stmt(tree_node**, gimple_statement_base**)
../../gcc/gimplify.c:5434
0x897b20 gimplify_and_add
../../gcc/gimplify.c:397
0x897b20 internal_get_tmp_var
../../gcc/gimplify.c:542
0x890659 gimplify_expr(tree_node**, gimple_statement_base**,
gimple_statement_base**, bool (*)(tree_node*), int)
../../gcc/gimplify.c:8592
0x8a5dac force_gimple_operand_1(tree_node*, gimple_statement_base**, bool
(*)(tree_node*), tree_node*)
../../gcc/gimplify-me.c:93
0x8a5edf force_gimple_operand_gsi_1(gimple_stmt_iterator*, tree_node*, bool
(*)(tree_node*), tree_node*, bool, gsi_iterator_update)
../../gcc/gimplify-me.c:130
0xaa5e48 expand_complex_comparison
../../gcc/tree-complex.c:1392
0xaa5e48 expand_complex_operations_1
../../gcc/tree-complex.c:1613
0xaa5e48 tree_lower_complex
../../gcc/tree-complex.c:1656
0xaa6e41 tree_lower_complex
../../gcc/tree-complex.c:1631
0xaa6e41 execute
../../gcc/tree-complex.c:1692

d0eb9b3dcd3d5c6ff85aaff9753c187423aeb764 is the first bad commit
commit d0eb9b3dcd3d5c6ff85aaff9753c187423aeb764
Author: rguenth 
Date:   Thu Nov 6 09:07:39 2014 +

2014-11-06  Richard Biener  

* match.pd: Implement bitwise binary and unary simplifications
from tree-ssa-forwprop.c.

[Bug debug/43821] -feliminate-dwarf2-dups produces "no debug symbols in executable" warning from dsymutil

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |INVALID
  Known to fail||

--- Comment #4 from Francois-Xavier Coudert  ---
I don't see it at all with gcc 4.8, 4.9 and trunk on darwin14. Probably was a
bug in dsymutil (most likely)…

[Bug c++/56926] Crash (without ICE) while compiling Boost.Math

[andre at netzeband dot eu]

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

--- Comment #10 from Andre Netzeband  ---
Once again the question: The original error report is around 1,5 years old. I
can hardly believe that there has been absolutely no progress so far.

[Bug target/56542] complex number division underflow on darwin11 without -lm

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Francois-Xavier Coudert  ---
This is fixed in branches 4.8 and 4.9, as well as trunk.

[Bug bootstrap/63784] New: [5 Regression] profiledbootstrap failure with bootstrap-lto

[hjl.tools at gmail dot com]

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

Bug ID: 63784
   Summary: [5 Regression] profiledbootstrap failure with
bootstrap-lto
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: jakub at redhat dot com

On Linux/x86-64, configured with

--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld
MAKEINFO=/usr/bin/false --enable-languages=c,c++ --enable-bootstrap
--with-build-config=bootstrap-lto --disable-werror --disable-multilib

r216964 gave:

/bin/sh ./libtool --tag=CXX   --mode=link
/export/project/git/gcc-regression-bootstrap/master/216981/bld/./gcc/xg++
-B/export/project/git/gcc-regression-bootstrap/master/216981/bld/./gcc/
-nostdinc++ `if test -f
/export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags;
then /bin/sh
/export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/scripts/testsuite_flags
--build-includes; else echo -funconfigured-libstdc++-v3 ; fi`
-L/export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/src
-L/export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/export/project/git/gcc-regression-bootstrap/master/216981/bld/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/export/project/git/gcc-regression-bootstrap/master/216981/usr/x86_64-unknown-linux-gnu/bin/
-B/export/project/git/gcc-regression-bootstrap/master/216981/usr/x86_64-unknown-linux-gnu/lib/
-isystem
/export/project/git/gcc-regression-bootstrap/master/216981/usr/x86_64-unknown-linux-gnu/include
-isystem
/export/project/git/gcc-regression-bootstrap/master/216981/usr/x86_64-unknown-linux-gnu/sys-include
   -W -Wall  -fvisibility=hidden -g -O2 -D_GNU_SOURCE -module -export-symbols
/export/project/git/gcc-regression/gcc/libcc1/libcc1.sym  -Xcompiler
'-static-libstdc++' -Xcompiler '-static-libgcc' -o libcc1.la -rpath
/export/project/git/gcc-regression-bootstrap/master/216981/usr/lib/../lib64
findcomp.lo libcc1.lo names.lo callbacks.lo connection.lo marshall.lo 
-Wc,../libiberty/pic/libiberty.a 
/usr/local/bin/ld: /tmp/ccqqkUWo.ltrans0.ltrans.o: relocation R_X86_64_32S
against `prime_tab.lto_priv.2' can not be used when making a shared object;
recompile with -fPIC
/tmp/ccqqkUWo.ltrans0.ltrans.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status
make[3]: *** [libcc1.la] Error 1

when building with "make profiledbootstrap".

[Bug libobjc/63765] [5.0 Regression] libobjc testsuite failures on AIX caused by setting _XOPEN_SOURCE

[dje at gcc dot gnu.org]

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

--- Comment #5 from David Edelsohn  ---
If _XOPEN_SOURCE is removed from thr.c completely, the testsuite results revert
to 1 failure.

[Bug target/45486] [4.8 only] throw not being caught

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2014-11-08
 CC||fxcoudert at gcc dot gnu.org
   Target Milestone|--- |4.9.0
Summary|throw not being caught  |[4.8 only] throw not being
   ||caught
 Ever confirmed|0   |1

--- Comment #2 from Francois-Xavier Coudert  ---
This works on x86_64-apple-darwin64, both at -m32 and -m64, for g++ 4.9 and
trunk.

On 4.8, however, I get the following error, similar to the original report:

Before try block
Before throw_int.
terminate called after throwing an instance of 'int'
zsh: abort  ./a.out

with the following backtrace:

* thread #1: tid = 0x66658b, 0x7fff917e2282
libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread',
stop reason = signal SIGABRT
  * frame #0: 0x7fff917e2282 libsystem_kernel.dylib`__pthread_kill + 10
frame #1: 0x7fff8fc2d4c3 libsystem_pthread.dylib`pthread_kill + 90
frame #2: 0x7fff8e38bb73 libsystem_c.dylib`abort + 129
frame #3: 0x000199fb
libstdc++.6.dylib`__gnu_cxx::__verbose_terminate_handler() + 315
frame #4: 0x00017888 libstdc++.6.dylib`__cxxabiv1::__terminate(void
(*)()) + 8
frame #5: 0x000178d3 libstdc++.6.dylib`std::terminate() + 19
frame #6: 0x00017afe libstdc++.6.dylib`__cxa_throw + 94
frame #7: 0x000116b3 a.out`A::throw_int(this=) const +
51 at a.C:9
frame #8: 0x000116cd a.out`B::throw_int(this=0x7fff5fbff9bb) +
25 at a.C:20
frame #9: 0x00011559 a.out`main + 101 at a.C:31
frame #10: 0x00010fd8 a.out`_start + 230
frame #11: 0x00010ef1 a.out`start + 33

[Bug target/30517] Inefficient address calculation on i386

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Francois-Xavier Coudert  ---
Code generation has changed a lot since GCC 4.3. For example, we don't emit the
cltq's anymore, and the various cases look much more similar. I'm closing this.

[Bug target/31142] Build with "CC='gcc -pg'" fails

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Francois-Xavier Coudert  ---
This bug does not exist on current trunk, which bootstraps fine with CC='gcc
-pg'.
Closing as part of a clean-up effort :)

[Bug c/63783] New: gcc-4.9: Miscompilation of boolean negation on SH4 using -O2

[glaubitz at physik dot fu-berlin.de]

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

Bug ID: 63783
   Summary: gcc-4.9: Miscompilation of boolean negation on SH4
using -O2
   Product: gcc
   Version: 4.9.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de

Hello!

Recently we ran into linker issues on our SH4 buildds in Debian [1]. We
initially blamed the linker for the problem, but after some more investigation,
Michael Karcher was eventually able to track down the problem being a
regression in gcc [2].

When compiling the following code snippet with optimization -O2 enabled, the
assertation will fail but succeed without:

#include 

int decision_result;
int truecount = 0;
int val;

void buggy(int flag)
{
  int condition;
  if(flag == 0)
condition = val != 0;
  else
condition = !decision_result;
  if (condition)
  {
 truecount++;
  }
}

int main(void)
{
  decision_result = 1;
  buggy(1);
  assert(truecount == 0);
}

The issue did not arise with gcc-4.6, for example, so it appears to be a
regression with one of the later versions of gcc.

Cheers,
Adrian

> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=17553
> [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768574

[Bug target/42951] GCC pedwarns about use of static inline functions from system headers in extern inline functions

[fxcoudert at gcc dot gnu.org]

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

--- Comment #3 from Francois-Xavier Coudert  ---
*** Bug 47816 has been marked as a duplicate of this bug. ***

[Bug c/47816] GCC pedwarns about use of static inline functions from system headers in extern inline functions

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #3 from Francois-Xavier Coudert  ---
The Mac OS system headers don't trigger this issue anymore. The general problem
is still relevant, but it's already present in PR42951, so I'm closing as a
duplicate.

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

[Bug c/63782] New: avoid implicit declaration warning for incompatible builtin implicit declaration

[manu at gcc dot gnu.org]

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

Bug ID: 63782
   Summary: avoid implicit declaration warning for incompatible
builtin implicit declaration
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: manu at gcc dot gnu.org

void foo(char *str) {
  strcpy(str, "foo");
}

[t@ws-520 examples]$ clang-3.5 -c -Wall test.c
test.c:2:3: warning: implicitly declaring library function 'strcpy' with
type 'char *(char *, const char *)'
strcpy(str, "foo");
^
test.c:2:3: note: include the header  or explicitly provide a
declaration for 'strcpy'
1 warning generated.

$ gcc-5 -c -Wall test.c
test.c: In function ‘foo’:
test.c:2:3: warning: implicit declaration of function ‘strcpy’
[-Wimplicit-function-declaration]
   strcpy(str, "foo");
   ^
test.c:2:3: warning: incompatible implicit declaration of built-in function
‘strcpy’
test.c:2:3: note: include ‘’ or provide a declaration of ‘strcpy’

The first warning is superfluous if the second is given.

(from a talk by Samsung at LinuxCon Europe:
http://events.linuxfoundation.org/sites/events/files/slides/linuxcon-europe-2014-llvm.pdf)

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #12 from Francois-Xavier Coudert  ---
(In reply to howarth from comment #10)
> So the compiler will emit the ___cxa_tm_cleanup to resolve the undefined
> symbol in libitm?

Maybe I should be more explicit: ___cxa_tm_cleanup comes from libstdc++. It is
not an undefined reference, but a weak one.

1. If you compile/link C code with libitm, ___cxa_tm_cleanup is guaranteed not
to be called. Because it's a weak reference, it doesn't matter that it wouldn't
be found. No problem.

2. If you compile/link C++ code with libitm, the g++ driver will link in
libstdc++. So, when ___cxa_tm_cleanup gets called from libitm, the weak
reference will correctly call the symbol from libstdc++. No problem.


Given that Iain validates my analysis, let's close this one.

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[fxcoudert at gcc dot gnu.org]

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

--- Comment #11 from Francois-Xavier Coudert  ---
(In reply to howarth from comment #10)
> So the compiler will emit the ___cxa_tm_cleanup to resolve the undefined
> symbol in libitm?

No, that symbol is in libstdc++

[Bug c++/60886] poor parse error recovery for missing parenthesis in mem-initializer-list

[manu at gcc dot gnu.org]

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

--- Comment #1 from Manuel López-Ibáñez  ---
It seems Clang fans peruse GCC's bugzilla to showcase Clang vs GCC in their
talks. This exact example was used in a talk by Samsumg at LinuxCon Europe:

http://events.linuxfoundation.org/sites/events/files/slides/linuxcon-europe-2014-llvm.pdf

[Bug target/26553] PIC stubs vs regparm

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Francois-Xavier Coudert  ---
The compiler doesn't do that anymore, since at least 4.8. For example, in 4.8,
we emit this:

.text
.globl _g
_g:
pushl%ebp
movl%esp, %ebp
subl$8, %esp
movl$1, %eax
callL_f$stub
leave
ret
.section
__IMPORT,__jump_table,symbol_stubs,self_modifying_code+pure_instructions,5
L_f$stub:
.indirect_symbol _f
hlt ; hlt ; hlt ; hlt ; hlt
.subsections_via_symbols


and in trunk:


.text
.globl _g
_g:
LFB0:
pushl%ebp
LCFI0:
movl%esp, %ebp
LCFI1:
subl$8, %esp
call___x86.get_pc_thunk.ax
L1$pb:
movl$1, %eax
call_f
leave
LCFI2:
ret
LFE0:
.section __TEXT,__textcoal_nt,coalesced,pure_instructions
.weak_definition___x86.get_pc_thunk.ax
.private_extern___x86.get_pc_thunk.ax
___x86.get_pc_thunk.ax:
LFB1:
movl(%esp), %eax
ret
LFE1:
.section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support
EH_frame1:
.set L$set$0,LECIE1-LSCIE1
.long L$set$0
LSCIE1:
.long0
.byte0x1
.ascii "zR\0"
.byte0x1
.byte0x7c
.byte0x8
.byte0x1
.byte0x10
.byte0xc
.byte0x5
.byte0x4
.byte0x88
.byte0x1
.align 2
LECIE1:
LSFDE1:
.set L$set$1,LEFDE1-LASFDE1
.long L$set$1
LASFDE1:
.longLASFDE1-EH_frame1
.longLFB0-.
.set L$set$2,LFE0-LFB0
.long L$set$2
.byte0
.byte0x4
.set L$set$3,LCFI0-LFB0
.long L$set$3
.byte0xe
.byte0x8
.byte0x84
.byte0x2
.byte0x4
.set L$set$4,LCFI1-LCFI0
.long L$set$4
.byte0xd
.byte0x4
.byte0x4
.set L$set$5,LCFI2-LCFI1
.long L$set$5
.byte0xc4
.byte0xc
.byte0x5
.byte0x4
.align 2
LEFDE1:
LSFDE3:
.set L$set$6,LEFDE3-LASFDE3
.long L$set$6
LASFDE3:
.longLASFDE3-EH_frame1
.longLFB1-.
.set L$set$7,LFE1-LFB1
.long L$set$7
.byte0
.align 2
LEFDE3:
.subsections_via_symbols

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[howarth at bromo dot med.uc.edu]

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

--- Comment #10 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #9)
> (In reply to Francois-Xavier Coudert from comment #8)
> > As far as I understand, libitm is supposed to be used with either C or C++.
> > As such, it contains some C++ code which requires libstdc++, but doesn't
> > link to it by default. That way, if someone compiles C code with libitm, it
> > doesn't use need the C++ libitm code, and doesn't pull libstdc++. And when
> > one compiles C++ code, libstdc++ is linked in anyway, so it's no problem.
> > 
> > In short, I'm afraid I don't understand what you think the problem is :)
> > Do you have a "real" testcase that fails to link?
> 
> This is quite correct, as I pointed out to Jack before he opened the issue. 
> libitm weak links to the relevant symbols and uses them as required by the
> final program.

So the compiler will emit the ___cxa_tm_cleanup to resolve the undefined symbol
in libitm?

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[iains at gcc dot gnu.org]

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

--- Comment #9 from Iain Sandoe  ---
(In reply to Francois-Xavier Coudert from comment #8)
> As far as I understand, libitm is supposed to be used with either C or C++.
> As such, it contains some C++ code which requires libstdc++, but doesn't
> link to it by default. That way, if someone compiles C code with libitm, it
> doesn't use need the C++ libitm code, and doesn't pull libstdc++. And when
> one compiles C++ code, libstdc++ is linked in anyway, so it's no problem.
> 
> In short, I'm afraid I don't understand what you think the problem is :)
> Do you have a "real" testcase that fails to link?

This is quite correct, as I pointed out to Jack before he opened the issue. 
libitm weak links to the relevant symbols and uses them as required by the
final program.

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #8 from Francois-Xavier Coudert  ---
As far as I understand, libitm is supposed to be used with either C or C++. As
such, it contains some C++ code which requires libstdc++, but doesn't link to
it by default. That way, if someone compiles C code with libitm, it doesn't use
need the C++ libitm code, and doesn't pull libstdc++. And when one compiles C++
code, libstdc++ is linked in anyway, so it's no problem.

In short, I'm afraid I don't understand what you think the problem is :)
Do you have a "real" testcase that fails to link?

[Bug c++/63716] GCC Internal Error

[cordlandwehr at kde dot org]

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

--- Comment #4 from cordlandwehr at kde dot org ---
Thanks, I could workaround this problem by fiddling a little bit with includes.

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[howarth at bromo dot med.uc.edu]

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

--- Comment #7 from howarth at bromo dot med.uc.edu ---
(In reply to howarth from comment #6)
> Okay, I see the missing linkage on libstdc++ is intentional...
> 
> # Force link with C, not C++.  For now, while we're using C++ we don't
> # want or need libstdc++.
> libitm_la_DEPENDENCIES = $(libitm_version_dep)
> libitm_la_LINK = $(LINK) $(libitm_la_LDFLAGS)
> libitm_la_LDFLAGS = $(libitm_version_info) $(libitm_version_script)
> 

On reflection, if this were true shouldn't there be no undefined symbols from
libstdc++ present in the libitm shared library?

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[howarth at bromo dot med.uc.edu]

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

--- Comment #6 from howarth at bromo dot med.uc.edu ---
Okay, I see the missing linkage on libstdc++ is intentional...

# Force link with C, not C++.  For now, while we're using C++ we don't
# want or need libstdc++.
libitm_la_DEPENDENCIES = $(libitm_version_dep)
libitm_la_LINK = $(LINK) $(libitm_la_LDFLAGS)
libitm_la_LDFLAGS = $(libitm_version_info) $(libitm_version_script)

but it would be good to know what the impact of the undefined ___cxa_tm_cleanup
has on libitm and what we should do about it.

[Bug bootstrap/49275] --enable-build-with-cxx profiledbootstrap BOOT_CFLAGS="-g -O3" CFLAGS_FOR_TARGET="-g -O3" CXXFLAGS_FOR_TARGET="-g -O3" failure

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #4 from Francois-Xavier Coudert  ---
Closing as fixed, per the last comment

[Bug bootstrap/52226] Trunk fails to bootstrap on Mac OS X with option "--enable-libstdcxx-debug".

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #13 from Francois-Xavier Coudert  ---
I've just checked: current trunk bootstraps fine with --enable-libstdcxx-debug,
so this probably got fixed at some point. If you still see it, with a currently
supported version of GCC, please feel free to reopen the bug report and give
the necessary details.

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[howarth at bromo dot med.uc.edu]

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

--- Comment #5 from howarth at bromo dot med.uc.edu ---
The problematic code in eh_cpp.cc appears to be...

#if !defined (HAVE_ELF_STYLE_WEAKREF)
void *__cxa_allocate_exception (size_t) { return NULL; }
void __cxa_throw (void *, void *, void *) { return; }
void *__cxa_begin_catch (void *) { return NULL; }
void __cxa_end_catch (void) { return; }
void __cxa_tm_cleanup (void *, void *, unsigned int) { return; }
void _Unwind_DeleteException (_Unwind_Exception *) { return; }
#endif /* HAVE_ELF_STYLE_WEAKREF */
}

If I append

void __cxa_tm_cleanup (void *, void *, unsigned int) { return; }

after that the linkage succeeds using the xg++ compiler without unresolved
symbols

[Bug bootstrap/50229] [4.8/4.9/5 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux

[fxcoudert at gcc dot gnu.org]

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

--- Comment #22 from Francois-Xavier Coudert  ---
(In reply to Iain Sandoe from comment #21)
> in short (2) is very definitely "works for me"

For me too: I regularly build darwin-to-mingw-w64 cross compilers, with no
problem at all. But there were, apparently, problems with Canadian crosses
(comments by Ray Donnelly).

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[howarth at bromo dot med.uc.edu]

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

--- Comment #4 from howarth at bromo dot med.uc.edu ---
Attached bzip2 of eh_cpp.ii created using...

# /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/xg++
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/ -nostdinc++
-nostdinc++
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include/x86_64-apple-darwin13.4.0
-I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/include
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141107/libstdc++-v3/libsupc++
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141107/libstdc++-v3/include/backward
-I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141107/libstdc++-v3/testsuite/util
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/src
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/src/.libs
-L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/x86_64-apple-darwin13.4.0/libstdc++-v3/libsupc++/.libs
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/bin/
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/lib/ -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/include -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/sys-include -DHAVE_CONFIG_H -I.
-I../../../gcc-5.0-20141107/libitm
-I../../../gcc-5.0-20141107/libitm/config/x86
-I../../../gcc-5.0-20141107/libitm/config/posix
-I../../../gcc-5.0-20141107/libitm/config/generic
-I../../../gcc-5.0-20141107/libitm -mrtm -Wall -pthread -Werror -std=gnu++0x
-funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -g -O2 -MT eh_cpp.lo
-MD -MP -MF .deps/eh_cpp.Tpo -c ../../../gcc-5.0-20141107/libitm/eh_cpp.cc
-fno-common -DPIC -o .libs/eh_cpp.o --save-temps

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[howarth at bromo dot med.uc.edu]

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

--- Comment #3 from howarth at bromo dot med.uc.edu ---
Created attachment 33923
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33923&action=edit
bzip2 compressed eh_cpp.ii

[Bug bootstrap/50229] [4.8/4.9/5 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux

[iains at gcc dot gnu.org]

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

--- Comment #21 from Iain Sandoe  ---
(In reply to Francois-Xavier Coudert from comment #20)
> This PR appears to report two different issues:
>   1. cross-compiler targeting Darwin

cross-compilers targeting Darwin <= 9 are possible using odcctools.

For "the future"
I am working on a set of GCC patches and a GAS port that solves part of the
problem for newer cases.  I intend to post these before stage#1 ends (but time
is short - esp. with trunk trashed on darwin at the moment).

However the static linker remains an issue (I have a build of ld64-127.2 which
supports Darwin10, and ppc*) … however, this needs to be forward-ported to the
latest published sources for ld64 before it will support "current" Darwin.  

In any event, it would be the User's responsibility to obtain a suitable SDK
for the target - by downloading the appropriate Xcode and extracting the SDK as
needed.

in short: "can't be expected to work until there's a set of Darwin 'binutils'
supporting > darwin 9". (working on providing that).

>   2. cross-compiler hosted on Darwin

I do this all the time - it's possible to cross from x86_64-darwin12 ->
powerpc-darwin9, for example (assuming one has the relevant cctools and ld64,
and enough patience).

I have also built native-crosses [x86-64-darwin12=build powerpc-darwin8
host/target] for the record.

Darwin works just fine as a host for cross-compilers to Linux.

(building your own sysroot - in particular GLIBC can be a trial, but if you
make a sysroot from a standard distro, it's not hard).

in short (2) is very definitely "works for me"

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[howarth at bromo dot med.uc.edu]

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

--- Comment #2 from howarth at bromo dot med.uc.edu ---
The missing linkage on libstdc++ would be solved by making sure that the
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/xg++ compiler is used
to link libitm rather than the current
/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/xgcc.

[Bug other/28910] "Make install" leaves files owned by root in build directory

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Francois-Xavier Coudert  ---
Confirmed, by testing on x86_64-apple-darwin14, that current trunk doesn't
behave as bad as GCC-4.2 used to.

[Bug testsuite/28913] "make install" required before testing libgomp and gfortran

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #6 from Francois-Xavier Coudert  ---
I haven't seen that one in years. Indeed, I just did a clean rebuild, removed
all my previously installed stuff, and can confirm libgomp and gfortran test
suites run fine.

[Bug bootstrap/50229] [4.8/4.9/5 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2014-11-08
 Ever confirmed|0   |1

[Bug bootstrap/50229] [4.8/4.9/5 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #20 from Francois-Xavier Coudert  ---
This PR appears to report two different issues:
  1. cross-compiler targeting Darwin
  2. cross-compiler hosted on Darwin

The first one, as far as I know, simply doesn't work for recent darwin
versions, due to lack of compiler tools (cross assembler and linker). Is that
correct?

For the second, could someone post a clear and up-to-date example of when it
doesn't work?

[Bug libitm/63781] potential linkage issue with libitm.1.dylib

[howarth at bromo dot med.uc.edu]

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

--- Comment #1 from howarth at bromo dot med.uc.edu ---
Note that this is the only shared library in gcc trunk that produces undefined
symbols on darwin when "-undefined dynamic_lookup" is removed to expose them.

[Bug libitm/63781] New: potential linkage issue with libitm.1.dylib

[howarth at bromo dot med.uc.edu]

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

Bug ID: 63781
   Summary: potential linkage issue with libitm.1.dylib
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libitm
  Assignee: unassigned at gcc dot gnu.org
  Reporter: howarth at bromo dot med.uc.edu

Performing a test build of gcc trunk (with the patches from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63773) at r217238 with the
configure files modified using...

# hackish undefined symbol test
perl -pi.bak -e 's|\$\{wl\}-undefined \$\{wl\}dynamic_lookup||g'
boehm-gc/configure gcc/configure libatomic/configure libbacktrace/configure
libcilkrts/configure libffi/configure libgfortran/configure libgo/configure
libgomp/configure libitm/configure libjava/classpath/configure
libjava/configure libobjc/configure libquadmath/configure
libsanitizer/configure libssp/configure libstdc++-v3/configure libvtv/configure
lto-plugin/configure zlib/configure
perl -pi.bak -e 's|-undefined dynamic_lookup||g' boehm-gc/configure
gcc/configure libatomic/configure libbacktrace/configure libcilkrts/configure
libffi/configure libgfortran/configure libgo/configure libgomp/configure
libitm/configure libjava/classpath/configure libjava/configure
libobjc/configure libquadmath/configure libsanitizer/configure libssp/configure
libstdc++-v3/configure libvtv/configure lto-plugin/configure zlib/configure

to suppress the default libtool usage of "-undefined dynamic_lookup" and expose
undefined symbols, I found the failure...

# /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/bin/
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/lib/ -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/include -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/sys-include-dynamiclib  -o
.libs/libitm.1.dylib  .libs/aatree.o .libs/alloc.o .libs/alloc_c.o
.libs/alloc_cpp.o .libs/barrier.o .libs/beginend.o .libs/clone.o .libs/eh_cpp.o
.libs/local.o .libs/query.o .libs/retry.o .libs/rwlock.o .libs/useraction.o
.libs/util.o .libs/sjlj.o .libs/tls.o .libs/method-serial.o .libs/method-gl.o
.libs/method-ml.o .libs/x86_sse.o .libs/x86_avx.o-mrtm -pthread  
-install_name  /sw/lib/gcc5.0/lib/libitm.1.dylib -compatibility_version 2
-current_version 2.0 -Wl,-single_module
Undefined symbols for architecture x86_64:
  "operator delete[](void*)", referenced from:
  transaction clone for operator new[](unsigned long) in alloc_cpp.o
  transaction clone for operator delete[](void*) in alloc_cpp.o
  "operator delete[](void*, std::nothrow_t const&)", referenced from:
  _del_opvnt in alloc_cpp.o
  "operator delete(void*)", referenced from:
  transaction clone for operator new(unsigned long) in alloc_cpp.o
  transaction clone for operator delete(void*) in alloc_cpp.o
  "operator delete(void*, std::nothrow_t const&)", referenced from:
  _del_opnt in alloc_cpp.o
  "operator new[](unsigned long)", referenced from:
  transaction clone for operator new[](unsigned long) in alloc_cpp.o
  "operator new[](unsigned long, std::nothrow_t const&)", referenced from:
  transaction clone for operator new[](unsigned long, std::nothrow_t
const&) in alloc_cpp.o
  "operator new(unsigned long)", referenced from:
  transaction clone for operator new(unsigned long) in alloc_cpp.o
  "operator new(unsigned long, std::nothrow_t const&)", referenced from:
  transaction clone for operator new(unsigned long, std::nothrow_t const&)
in alloc_cpp.o
  "___cxa_allocate_exception", referenced from:
  __ITM_cxa_allocate_exception in eh_cpp.o
  "___cxa_begin_catch", referenced from:
  __ITM_cxa_begin_catch in eh_cpp.o
  "___cxa_end_catch", referenced from:
  __ITM_cxa_end_catch in eh_cpp.o
  "___cxa_throw", referenced from:
  __ITM_cxa_throw in eh_cpp.o
  "___cxa_tm_cleanup", referenced from:
  GTM::gtm_thread::revert_cpp_exceptions(GTM::gtm_transaction_cp*)  in
eh_cpp.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

All but one undefined symbols are suppressed by appending
"-L../libstdc++-v3/src -lstdc++" to the linkage...

# /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/xgcc
-B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./gcc/
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/bin/
-B/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/lib/ -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/include -isystem
/sw/lib/gcc5.0/x86_64-apple-darwin13.4.0/sys-include -dynamiclib -o
.libs/libitm.1.dylib .libs/aatree.o .libs/alloc.o .libs/alloc_c.o
.libs/alloc_cpp.o .libs/barrier.o .libs/beginend.o .libs/clone.o .libs/eh_cpp.o
.libs/local.o .libs/query.o .libs/retry.o .libs/rwlock.o .libs/useraction.o
.libs/util.o .libs/sjlj.o .libs/tls.o .libs/method-serial.o .libs/method-gl.o
.libs/method-ml.o .libs/x86_sse.o .li

[Bug target/43099] rethrowing leaks memory like a sieve

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

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

--- Comment #10 from Francois-Xavier Coudert  ---
Either this was in the Apple unwinder, or this got fixed at some point. Current
trunk on darwin14 does not give memory leaks for the testcase, neither at -m32
nor at -m64.

[Bug debug/35378] Bootstrap fails with BOOT_CFLAGS="-g -O0"

[fxcoudert at gcc dot gnu.org]

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

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||fxcoudert at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #3 from Francois-Xavier Coudert  ---
Current GCC trunk (with patches from PR63773) bootstraps fine on Mac OS 10.10
(OS X Yosemite) with:

make BOOT_CFLAGS="-g -O0" bootstrap

Sometime in the past 6 years, this got fixed.

[Bug middle-end/63761] [5 Regression] error: gimple_bb (stmt) is set to a wrong basic block

[thopre01 at gcc dot gnu.org]

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

--- Comment #3 from thopre01 at gcc dot gnu.org ---
I got a local patch that makes this code compile without error and I can build
gcc with this patch. I'm now going to run the testsuite, add some more comments
and try to make a reduced testcase.

[Bug c/52952] Wformat location info is bad (wrong column number)

[manu at gcc dot gnu.org]

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

--- Comment #36 from Manuel López-Ibáñez  ---
Latest patch: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00663.html

Joseph pointed out that it does not handle escape sequences. The only solution
I can think of is to open the file and re-parse the string. However, it doesn't
seem trivial to re-use libcpp to parse a string given as a char *. Any ideas
how to achieve this or a better alternative?

Escape sequences are too common to ignore in a first implementation.

[Bug c++/63736] gcc generated program with segfault on atomic exchange when the atomic variable is a member of a struct allocated with make_shared

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||4.9.2, 5.0
  Known to fail||4.8.2

--- Comment #4 from Jonathan Wakely  ---
I can reproduce it with 4.8.2 and can confirm it seems to be fixed in 4.9.0
(even when linking to the libatomic.so from 4.8.2)

#0  0x77dcc898 in libat_exchange_16_i1 (mptr=0x604028,
newval=, smodel=) at
../../../libatomic/exch_n.c:54
#1  0x004011b4 in std::atomic::exchange (this=0x604028,
__i=..., _m=std::memory_order_seq_cst) at /usr/include/c++/4.8.3/atomic:225
#2  0x0040 in PStruct::setMs (this=0x604028, ms=...) at
/var/tmp/atomic_of_struct_test.cpp:18
#3  0x00400fb1 in main () at /var/tmp/atomic_of_struct_test.cpp:39

[Bug libstdc++/63780] std::remquo returns wrong quotient

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
This is nothing to do with libstdc++:

int main() {
  int n;
  double x = 3419, m = 360;
  double y = __builtin_remainder(x, m);
  double z = __builtin_remquo(x, m, &n);
  __builtin_printf("result %.0f %.0f %d\n", y, z, n);
}

With optimisation GCC inlines its own definitions that give the right answer,
so this looks like a glibc bug.

[Bug target/57792] toplevel configure should enable "--with-sysroot="`xcrun --show-sdk-path`"" for darwin13 and later

[iains at gcc dot gnu.org]

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

--- Comment #20 from Iain Sandoe  ---

Unofficially (but after chatting with a couple of folks who know):

"It should be assumed that depending on /usr/{include,lib} is unreliable".

"The RightWay(™) for the system is deemed to be finding a suitable SDK root
from "wherever".  Yes, it's recognised that this is somewhat of a pain."

===

IMO we need to have a design that recognises that we (darwin support in GCC)
have different objectives from Xcode.

difference: #1 we support N-K (where N == host OS version, and K might be +/-
some number > 1).  This means that we want to be able to find SDKs for system
versions that might not be included in the "current" Xcode.  I don't like the
idea of shoe-horning those (extra SDKs) into Xcode just so that it can find
them - although I know folks already do that.

- note that -mmacosx-version-min= and MACOSX_DEPLOYMENT_TARGET can go some way
towards achieving part of those objectives - but it won't (for example) let you
build for powerpc-darwin9 from x86-86-darwin13 [something I *do* often do].

difference #2 (at least I) have an objective that one day - hopefully not too
far away, we will be able to cross-build for darwin ( > 9 ;) ) from other
platforms, e.g. Linux.

To that end I think we need a coherent design to cater for GCC's needs.

My initial suggestion is that we don't try to (ab-)use sysroot for this, but
instead add a --with-SDK-root= option that may be specified multiple times.  We
might eventually need the driver to try and find the best match for the SDK
given a User "-mmacosx-version-min" and maybe even (one day)
-mmacosx-version-max= ..

This should have fall-backs as follows:

  xcrun … where that's available
  /Developer/SDKs (Darwin <= 9)
  / - essentially 'hope for the best' with /usr/{include,lib}

I think there are adequate hooks in config/darwin-c.c to deal with this without
impacting any part of the compiler outside the port [but that's without having
tried it].



I tend to agree that developers have to be prepared to understand a little
about what their doing - but IMO the User of the compiler (someone just trying
to build her code) should not have to jump through hoops to achieve that - at
least for a host-native compile ;)

I know Mike is not a fan of new C/L options, so I'm open to counter-proposals.

[Bug sanitizer/62132] [5 Regression] FAIL: c-c++-common/asan/misalign-[12].c after r213807 on x86_64-apple-darwin13 with -m32

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe  ---
(In reply to Yury Gribov from comment #10)
> (In reply to Dominique d'Humieres from comment #9)
> > Per comments 6 and 7 I have tried
> > ...
> > but it does not fix the failures. What am I misunderstanding?
> 
> That wouldn't help because libsanitizer does not use -funwind-tables even if
> they are available.  I think the problem is in StackTrace::WillUseFastUnwind
> in libsanitizer/sanitizer_common/sanitizer_stacktrace.h.

Dominique,
in summary: as things stand (with the current asan) your first fix LGTM. 
However, you should post it for approval by an appropriate maintainer.

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

[howarth at bromo dot med.uc.edu]

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

--- Comment #7 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Francois-Xavier Coudert from comment #4)
> > (In reply to Dominique d'Humieres from comment #3)
> > > Does it means that 'id' should be replaced with 'instancetype' in failing
> > > tests? What about the gnu-runtime?
> > 
> > No, we need to make the compiler understand 'instancetype'.
> 
> sadly, we spend almost all our darwin (volunteer) time chasing fall-out from
> other patches and very little remains for working on new features :-(
> 
> I'd love to modernise the ObjC stuff - bearing in mind that the biggest
> killer there is that we don't support blocks in GCC (ObjC is essentially not
> much usable on darwin >= 11, without that).
> 
> on the TODO ..

If I remember correctly, the blocks issue is problematic because of the blocks
runtime's license, so that whole package would have to be reverse engineered to
be under GPLv3, no?

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

[howarth at bromo dot med.uc.edu]

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

--- Comment #6 from howarth at bromo dot med.uc.edu ---
(In reply to Iain Sandoe from comment #5)
> (In reply to Francois-Xavier Coudert from comment #4)
> > (In reply to Dominique d'Humieres from comment #3)
> > > Does it means that 'id' should be replaced with 'instancetype' in failing
> > > tests? What about the gnu-runtime?
> > 
> > No, we need to make the compiler understand 'instancetype'.
> 
> sadly, we spend almost all our darwin (volunteer) time chasing fall-out from
> other patches and very little remains for working on new features :-(
> 
> I'd love to modernise the ObjC stuff - bearing in mind that the biggest
> killer there is that we don't support blocks in GCC (ObjC is essentially not
> much usable on darwin >= 11, without that).
> 
> on the TODO ..

   Perhaps Iain can chime in on this. My recollection is that, while all of the
changes out of the Apple gcc branch from prior to the GPLv3 rupture were merged
in a few years ago, only limited attempts were made towards syncing with
further upstream changes. I think those mainly involved adapting to breakage
from system header changes. IMHO, it s pretty much a lost cause unless
resources are committed to attempt to match the feature set of the current
objective c in clang/llvm. I don't even know if Apple still attempts to
distinguish the objective c changes. I think it went from Objective C 2.0 to
Modern Objective C, no?
   Interestingly, if you scan the /usr/include/objc headers in Yosemite for
copyright changes only NSObjCRuntime.h and NSObject.h have 2012 copyrights with
the rest at 2007 or earlier. FYI, I believe this lists the changes in Modern
Objective C...

https://developer.apple.com/library/ios/releasenotes/ObjectiveC/ModernizationObjC/AdoptingModernObjective-C/AdoptingModernObjective-C.html

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe  ---
(In reply to Francois-Xavier Coudert from comment #4)
> (In reply to Dominique d'Humieres from comment #3)
> > Does it means that 'id' should be replaced with 'instancetype' in failing
> > tests? What about the gnu-runtime?
> 
> No, we need to make the compiler understand 'instancetype'.

sadly, we spend almost all our darwin (volunteer) time chasing fall-out from
other patches and very little remains for working on new features :-(

I'd love to modernise the ObjC stuff - bearing in mind that the biggest killer
there is that we don't support blocks in GCC (ObjC is essentially not much
usable on darwin >= 11, without that).

on the TODO ..

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

[fxcoudert at gcc dot gnu.org]

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

--- Comment #4 from Francois-Xavier Coudert  ---
(In reply to Dominique d'Humieres from comment #3)
> Does it means that 'id' should be replaced with 'instancetype' in failing
> tests? What about the gnu-runtime?

No, we need to make the compiler understand 'instancetype'.

[Bug target/63651] Lot of failures in obj(c|-c++) with yosemite

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
(In reply to Francois-Xavier Coudert from comment #2)
> > I suppose as a first approach, we could make it equivalent to id.
>
> Not really, apparently: the answer there gives a quite complete description
> (and quotes the official Apple docs): http://stackoverflow.com/a/14652187

Does it means that 'id' should be replaced with 'instancetype' in failing
tests? What about the gnu-runtime?

[Bug libstdc++/63780] std::remquo returns wrong quotient

[charles at karney dot com]

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

--- Comment #1 from Charles Karney  ---
Created attachment 33922
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33922&action=edit
Assembly file

[Bug libstdc++/63780] New: std::remquo returns wrong quotient

[charles at karney dot com]

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

Bug ID: 63780
   Summary: std::remquo returns wrong quotient
   Product: gcc
   Version: 4.8.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: charles at karney dot com

Created attachment 33921
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33921&action=edit
intermediate output from compiler

This code:

#include 
#include 

int main() {
  int n;
  double x = 3419, m = 360;
  double y = std::remainder(x, m);
  double z = std::remquo(x, m, &n);
  std::cout << "result " << y << " " << z << " " << n << "\n";
}

compiled with

g++ --std=c++11 -O0 -o remquo-bug remquo-bug.cpp && ./remquo-bug

produces

result 179 539 8

The correct output is produced by -O1

result 179 179 9

Here is the output from g++ -v

Using built-in specs.
COLLECT_GCC=/usr/bin/g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-linker-hash-style=gnu
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-initfini-array --enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-isl=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/isl-install
--with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140911/obj-x86_64-redhat-linux/cloog-install
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) 

Output from -save-temps attached

[Bug tree-optimization/63748] [4.9/5 Regression] wrong may be used uninitialized warning (abnormal edges)

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 CC||manu at gcc dot gnu.org
 Depends on||24639
Summary|[4.9/5 Regression] may be   |[4.9/5 Regression] wrong
   |used uninitialized warning  |may be used uninitialized
   |on variable definition with |warning (abnormal edges)
   |initializer |

--- Comment #5 from Manuel López-Ibáñez  ---
(In reply to Ulrich Weigand from comment #4)
> Huh?  No matter what, "buf" is in fact never used uninitialized in this
> function, and that should be trivial to see; the only use of "buf" occurs in
> line 17 immediately after the definition of "buf" in line 16, whether any
> longjmp is ever called or not.
> 
> Also, if any of the gotos in this function is removed, the warning
> disappears.  The problem seems to be related to some call-graph
> optimizations (note that the if (noside) check is partially redundant).

The problem arises because we create PHI nodes with default definitions of buf
for the basic block created by the gotos. For example:

;;   basic block 6, loop depth 0, count 0, freq 0, maybe hot
;;prev block 5, next block 7, flags: (NEW, REACHABLE)
;;pred:   3 (ABNORMAL)
;;8 (ABNORMAL)
;;   starting at line -1
  # argvec_2(ab) = PHI <[test.c:9:9] argvec_13(ab)(3), argvec_3(ab)(8)>
  # buf_5(ab) = PHI 
  # .MEM_9(ab) = PHI <.MEM_16(ab)(3), .MEM_25(ab)(8)>
  # .MEM_20(ab) = VDEF <.MEM_9(ab)>
  # USE = anything
  # CLB = anything
  ABNORMAL_DISPATCHER (0);
;;succ:   5 (ABNORMAL)

and no subsequent optimization is able to realize that those PHI nodes are
never used or to remove the edges as unreachable.

I think this is some issue with how the call-graph is built. A simplified
version of 015t.ssa:

test (intD.6 opD.1753, intD.6 nosideD.1754)
{
;;   basic block 2, loop depth 0, count 0, freq 0, maybe hot
;;pred:   ENTRY (FALLTHRU)
;;   starting at line 9
  [test.c:11:6] if (op_14(D) != 0)
goto ;
  else
goto ;

;;   basic block 3, loop depth 0, count 0, freq 0, maybe hot
;;pred:   2 (TRUE_VALUE)
;;   starting at line 13
  [test.c:13:16] # .MEM_16(ab) = VDEF <.MEM_15(D)>
  _17 = alloc_jmp_bufD.1750 ();
;;succ:   4 (FALLTHRU)
;;6 (ABNORMAL)

;;   basic block 4, loop depth 0, count 0, freq 0, maybe hot
;;pred:   3 (FALLTHRU)
;;   starting at line 13, discriminator 1
  [test.c:13:16] buf_19 = _17;
;;succ:   5 (FALLTHRU)

;;   basic block 5, loop depth 0, count 0, freq 0, maybe hot
;;pred:   4 (FALLTHRU)
;;6 (ABNORMAL)
;;   starting at line 14
  # buf_4(ab) = PHI <[test.c:13:16] buf_19(4), buf_5(ab)(6)>
  setjmpD.1749 (buf_4(ab));
  [test.c:16:10] if (noside_22(D) != 0)
goto  (nosideret);
  else
goto  (do_call_it);
;;succ:   11 (TRUE_VALUE)
;;7 (FALSE_VALUE)

;;   basic block 6, loop depth 0, count 0, freq 0, maybe hot
;;pred:   3 (ABNORMAL)
;;8 (ABNORMAL)
;;   starting at line -1
  # buf_5(ab) = PHI 
  ABNORMAL_DISPATCHER (0);
;;succ:   5 (ABNORMAL)

;;   basic block 7, loop depth 0, count 0, freq 0, maybe hot
;;pred:   5 (FALSE_VALUE)
;;10 (FALLTHRU)
;;   starting at line 21
  # buf_6(ab) = PHI 
do_call_itL.2:
  [test.c:21:10] if (noside_22(D) != 0)
goto  (nosideret);
  else
goto ;
;;succ:   11 (TRUE_VALUE)
;;8 (FALSE_VALUE)

;;   basic block 8, loop depth 0, count 0, freq 0, maybe hot
;;pred:   7 (FALSE_VALUE)
;;   starting at line 24
  _26 = fooD.1752 (argvec_3(ab));
;;succ:   9 (FALLTHRU)
;;6 (ABNORMAL)

;;   basic block 9, loop depth 0, count 0, freq 0, maybe hot
;;pred:   8 (FALLTHRU)
;;   starting at line 24, discriminator 1
  [test.c:24:14] _27 = _26;
  [test.c:24:14] goto ;
;;succ:   12 (FALLTHRU)

;;   basic block 10, loop depth 0, count 0, freq 0, maybe hot
;;pred:   2 (FALSE_VALUE)
;;   starting at line 27
  argvec_24 = allocaD.858 (1);
  [test.c:28:3] goto  (do_call_it);
;;succ:   7 (FALLTHRU)

;;   basic block 11, loop depth 0, count 0, freq 0, maybe hot
;;pred:   5 (TRUE_VALUE)
;;7 (TRUE_VALUE)
;;   starting at line 31
nosideretL.5:
  [test.c:31:10] _28 = 1;
;;succ:   12 (FALLTHRU)

;;   basic block 12, loop depth 0, count 0, freq 0, maybe hot
;;pred:   9 (FALLTHRU)
;;11 (FALLTHRU)
;;   starting at line -1
  # _7 = PHI <[test.c:24:14] _27(9), [test.c:31:10] _28(11)>
  return _7;
;;succ:   EXIT

}

which is more or less:


test (intD.6 opD.1753, intD.6 nosideD.1754)
{
bb1:
 if (op_14(D) != 0)
 {
 try {
 _17 = alloc_jmp_bufD.1750 (); 
 [test.c:13:16] buf_19 =

[Bug c++/54780] G++ does not find precompiled headers in some cases

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

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

--- Comment #6 from Manuel López-Ibáñez  ---
Thus, not a bug then, no?

[Bug other/346] gcc install clobbers files that it shouldn't touch

[manu at gcc dot gnu.org]

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

Manuel López-Ibáñez  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||manu at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #10 from Manuel López-Ibáñez  ---
I'll go ahead and close this as everything originally reported seems to have
been fixed. If there are further issues, a new bug should be opened with a
clear list of files clobbered. The most recent duplicate about this was about
-V not working and that got fixed.

[Bug target/44685] internal compiler error: in final_scan_insn, at final.c:2650 while compiling program with complex types

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||dcb314 at hotmail dot com

--- Comment #2 from David Binderman  ---
I am getting something similar on blackfin
when building linux kernel

arch/blackfin/kernel/setup.c: In function ‘setup_arch’:
arch/blackfin/kernel/setup.c:1110:1: error: could not split insn
 }
 ^
(jump_insn:TI 1747 1218 1222 126 (parallel [
(set (pc)
(if_then_else (ne (reg:SI 16 I0 [945])
(const_int 1 [0x1]))
(label_ref 1219)
(pc)))
(set (reg:SI 16 I0 [945])
(plus:SI (reg:SI 16 I0 [945])
(const_int -1 [0x])))
(unspec [
(const_int 0 [0])
] 10)
(clobber (reg:SI 0 R0))
]) arch/blackfin/kernel/setup.c:400 96 {loop_end}
 (expr_list:REG_UNUSED (reg:SI 0 R0)
(int_list:REG_BR_PROB 9550 (nil)))
 -> 1219)
arch/blackfin/kernel/setup.c:1110:1: internal compiler error: in
final_scan_insn, at final.c:2952

[Bug libstdc++/63776] [C++11] Regex collate matching not working

[gnu-org at bignm dot com]

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

--- Comment #3 from Tom Straub  ---
Hi Tim,

OOPS! The versions used were Boost REGEX 1.55.0 and ICU 52. Got the versions
mixed up in my head.

Tom

[Bug libstdc++/63776] [C++11] Regex collate matching not working

[gnu-org at bignm dot com]

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

--- Comment #2 from Tom Straub  ---
Hi Tim,

Okay, a program very similar to this using the Boost REGEX library and ICU 4.55
works just fine with this.

According to my understanding, the "char" data type and "std::string" classes
were specifically set up in C++11 to handle UTF-8 sequences.

The "sequence of bytes" are actually valid UNICODE characters. So, there should
be no problem, that is, if the std::regex_constants::collate flag is actually
working, since the application is using  and setting the std::locale to
"pt_BR.UTF-8" (which is supported on my box).

It is acting as if it is still in POSIX or C locale, since it doesn't recognize
the accented characters as "[:alpha:]" class.

Here is my G++ version:

$ g++ --version
g++ (GCC) 4.9.1
Copyright (C) 2014 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.

Tom

[Bug target/54232] For x86 PIC code, ebx should be spillable

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |5.0

--- Comment #5 from Uroš Bizjak  ---
.

[Bug target/63773] [meta-bug] Restoring darwin bootstrap for gcc 5.0

[howarth at bromo dot med.uc.edu]

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

--- Comment #9 from howarth at bromo dot med.uc.edu ---
(In reply to howarth from comment #8)

Successfully bootstrapped with same configure options at same revision on...

x86_64-apple-darwin11 against Xcode 4.6

[Bug libstdc++/63775] [C++11] Regex range with leading dash (-) not working

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

 CC||timshen at gcc dot gnu.org

--- Comment #1 from Tim Shen  ---
Ah, the current bracket expression implementation is too naive. I'll fix it.

Thanks for reporting :)

[Bug c++/63779] New: g++ 4.9 generates invalid object provoking a GOT relative relocation must reference a local symbol linker error on SunOS

[richard at netbsd dot org]

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

Bug ID: 63779
   Summary: g++ 4.9 generates invalid object provoking a GOT
relative relocation must reference a local symbol
linker error on SunOS
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard at netbsd dot org

I'm getting with gcc4.9.2 the following link error using the illumos native
/usr/bin/ld building libxul from firefox 31:

>ld: fatal: relocation error: R_386_GOTOFF: file 
>../../../content/media/MediaDecoderReader.o: symbol
 mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*): a GOT relative
relocation must reference a local symbol
>ld: fatal: relocation error: R_386_GOTOFF: file 
>../../../content/media/MediaDecoderReader.o: symbol 
>mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*): a GOT relative 
>relocation must reference a local symbol
>collect2: error: ld returned 1 exit status
/tmp/pkgsrc/devel/xulrunner31/work/mozilla-esr31/config/rules.mk:883: recipe
for target 'libxul.so' failed

The following is the code section (from content/media/MediaDecoderReader.cpp)
(slightly modified to show code is identical):

class VideoQueueMemoryFunctor : public nsDequeFunctor {
public:
  VideoQueueMemoryFunctor() : mSize(0) {}

  MOZ_DEFINE_MALLOC_SIZE_OF(MallocSizeOf);

  virtual void* operator()(void* aObject) {
const VideoData* v = static_cast(aObject);
mSize += v->SizeOfIncludingThis(MallocSizeOf);
return nullptr;
  }

  size_t mSize;
};


class AudioQueueMemoryFunctor : public nsDequeFunctor {
public:
  AudioQueueMemoryFunctor() : mSize(0) {}

  MOZ_DEFINE_MALLOC_SIZE_OF(MallocSizeOf);

  virtual void* operator()(void* aObject) {
const AudioData* v = static_cast(aObject);
mSize += v->SizeOfIncludingThis(MallocSizeOf);
return nullptr;
  }

  size_t mSize;
};


where MOZ_DEFINE_MALLOC_SIZE_OF is defined as (in
xpcom/base/nsIMemoryReporter.idl):

#define MOZ_DEFINE_MALLOC_SIZE_OF(fn) \
  static size_t fn(const void* aPtr)  \
  {   \
  MOZ_REPORT(aPtr);   \
  return moz_malloc_size_of(aPtr);\
  }

As one can see, the two classes are nearly identical.

but nm shows the following differences in the generated object :

richard@omnis:/home/richard/src/txul$ nm -C MediaDecoderReader.o.gcc49 |grep
MallocSizeOf
[161]| 0| 0|NOTY |GLOB |0|UNDEF 
|mozilla::AudioQueueMemoryFunctor::MallocSizeOf(const void*)
  
[_ZN7mozilla23AudioQueueMemoryFunctor12MallocSizeOfEPKv]
[149]| 0|34|FUNC |WEAK |2|90
|mozilla::VideoQueueMemoryFunctor::MallocSizeOf(const void*)
  
[_ZN7mozilla23VideoQueueMemoryFunctor12MallocSizeOfEPKv]

richard@omnis:/home/richard/src/txul$ nm -C MediaDecoderReader.o.gcc48 |grep
MallocSizeOf
[135]| 0|35|FUNC |WEAK |2|87
|mozilla::AudioQueueMemoryFunctor::MallocSizeOf(const void*)
  
[_ZN7mozilla23AudioQueueMemoryFunctor12MallocSizeOfEPKv]
[132]| 0|35|FUNC |WEAK |2|85
|mozilla::VideoQueueMemoryFunctor::MallocSizeOf(const void*)
  
[_ZN7mozilla23VideoQueueMemoryFunctor12MallocSizeOfEPKv]


or if you prefer gnm:
richard@omnis:/home/richard/src/txul$ gnm -C MediaDecoderReader.o.gcc49 |grep
MallocSizeOf
 U mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*)
 W mozilla::VideoQueueMemoryFunctor::MallocSizeOf(void const*)
richard@omnis:/home/richard/src/txul$ gnm -C MediaDecoderReader.o.gcc48 |grep
MallocSizeOf
 W mozilla::AudioQueueMemoryFunctor::MallocSizeOf(void const*)
 W mozilla::VideoQueueMemoryFunctor::MallocSizeOf(void const*)

I attach the .ii and .s temps for both gcc48 and gcc49

The primary build environment is on:
richard@omnis:/home/richard/src/txul$ uname -a
SunOS omnis 5.11 illumos-gate-c40eb28 i86pc i386 i86pc

and snippet from this pkgsrc trunk build with '-v':

Using built-in specs.
COLLECT_GCC=/opt/local/gcc49/bin/g++
Target: i386-sun-solaris2.11
Configured with: ../gcc-4.9.2/configure --enable-languages='c obj-c++ objc go
fortran c++' --enable-shared --enable-long-long
--with-local-prefix=/opt/local/gcc49 --enable-libssp --enable-threads=posix
--with-boot-ldflags='-static-libstdc++ -static-libgcc -Wl,-R/opt/local/lib '
--with-system-zlib --disable-nls --with-isl=/opt/local
--disable-isl-version-check --with-cloog=/opt/local --enable-__cxa_atexit
--with-gxx-include-dir=/opt/local/gcc49/include/c++/ --with-gnu-as
--with-as=/opt/local/bin/gas --without-gnu-l

[Bug other/61391] [5 Regression] ICE in execute_one_pass at -O3 and above

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

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

--- Comment #10 from Arseny Solokha  ---
Closing, then.

[Bug tree-optimization/63747] [5 regression] icf mis-compares switch gimple

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #8 from Eric Botcazou  ---
Martin, please use present tense in your Changelog entries, as specified by the
GNU Coding Standard:

* ipa-icf-gimple.c (func_checker::compare_gimple_switch): Add missing
checking for CASE_LOW and CASE_HIGH.

[Bug libstdc++/63776] [C++11] Regex collate matching not working

[timshen at gcc dot gnu.org]

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

Tim Shen  changed:

   What|Removed |Added

 CC||timshen at gcc dot gnu.org

--- Comment #1 from Tim Shen  ---
std::string s = "\"João Méroço\" ";

...is not what you want. It is not an decoded unicode string, but just "a
sequence of bytes":

std::string s = "\"João Méroço\" ";
for (const auto& it : s) {
std::cout << it << "\n";
}
...print:
"
J
o

�
o

M

�
r
o

�
o
"

<
e
m
a
i
l
@
i
s
p
.
c
o
m
>

I don't know much about unicode support status in the standard library. @Jon,
can you put a comment?